I know this may sound silly but it seems that, my version of TortoiseSVN is unable to resolve conflicts even for text files. I've followed the manual to the letter (By selectingEdit Conflicts the resolving the conflict via Winmerge, and then, selecting Resolved), but when I viewed the text file, the conflict markers are still there. Is this the expected result? I may be missing something here, but I was expecting the conflict markers to be removed after I did the steps the the previous statement. I thought it maybe winmerge not properly saving, so i tried to upgrade it, but to no avail. I also tried using Araxis merge but also no luck. I think I'm just missing something here but what?
BTW the ff. are the versions of my programs
TortoiseSVN
TortoiseSVN 1.6.7, Build 18415 - 32 Bit , 2010/01/22 17:55:06
Subversion 1.6.9,
apr 1.3.8
apr-utils 1.3.9
neon 0.29.3
OpenSSL 0.9.8k 25 Mar 2009
zlib 1.2.3
WinMerge
Winmerge Version 2.12.4.0
This the configuration for Winmerge in my TortoiseSVN
[WinmergePath] -e -x -ub -dl %bname -dr %yname %base %mine
Did you try it with TortoiseMerge (the merge program included with TortoiseSVN)? In TortoiseMerge, be sure to save first, then click Resolved inside TortoiseMerge.
I've had this happen with my .cs files. There are times when I have to delete the directory contents and update my side again. Even when it meant that I would have to re-apply some of my changes. Like saving anything you are working on, doing intermittent updates will ensure that you have little work to redo should something fail.
Related
I opened VSCode and was presented with a notification that there was a conflict between two versions of a file. I followed the prompts and got a side-by-side comparison of two versions. I clicked the button that accepts the newer version, believing that VSCode had correctly inferred which version was newer. It had not, and I lost a significant number of changes to the file. Is there a cached copy of the other version anywhere?
Thank you!
ps - I seem to have failed to actually commit the changes in git as well. Not sure how that happened.
After searching through the VSCode appdata, I concluded that it wasn't likely that there was a copy. I found a copy of the bytecode (.pyc file) and used uncompyle6 to get an approximate copy of the version of the .py file I needed to recover. Was able to manually merge from there.
I was flummoxed by this one too. The answer is that you can restore the old version by hitting undo until before the change was made.
Yesterday, I decided I wanted to upload all of my old crappy work. It is back when I was just starting programming and just wanted to show people it. I have never used git (very bad decision in my part) and created a repository. I downloaded the windows client and the egit eclipse plugin. I used the egit plugin but it just moved everything to a Oder and made it a local repository. I then used the windows client to submit a commit. It was taking a while so I left it on and went to sleep. I woke up this morning and everything was deleted except the folder names, .gitignore files and .project files from eclipse. Is there anyway I can get this old work back.
Thanks!
At the root folder of your project, run gitk from the Git Bash and you'll see your changes.
I have found a solution here: https://www.quora.com/Git-revision-control/How-do-I-retrieve-added-files-but-not-committed-from-a-reset?share=1
Basically you can retrieve the files from blobs but you have to do this one by one. I am writing a program to do so automatically now.
Is there any other easier way though?
If so, I would be glad to know.
Edit: Oh my I completely forgot about the previous versions tab on Windows. I'm just doing that.
Thanks!
I came in today and saw a bunch of sources listed as
filename.pl 1.1 1.1
instead of
filename.pl 1.1
in my Eclipse project Navigator.
Trying to commit it gives me, for example:
cvs commit: sticky tag '1.1' for file 'filename.pl' is not a branch
Without resorting to swearing and smashing my work desk, how can I get rid of the sticky tags, I dont think I want to branch every bloody source file when I have to do commits, we're not using version control for any real project management, just to sync between devs, and certainly dont have time to do CVS/SVN/what-have-you maintenance every bleeding month.
Was CVS configured to resort to this ball ache by default? Can it be reverted?
I don't care if it has to be wiped and redone it's a recent deployment anyway, any and all suggestions much welcome!
EDIT I have now noticed that on another machine configured with my CVS username it is proper and I see only untagged sources, how can I do this for my Eclipse, described above? I will also check whether I have those files listed as binary or ascii on both machines.
Find all files with the name "Entries". Find in files the text "//T". It will be files with "stycky revision"
example
/ NodeFinder.java/1.6/Tue Nov 12 05:23:32 2013//
/ OrHtmlGenerator.java/1.103/Wed Dec 4 09:22:02 2013//T1.103
/ PopupTextSearchWindow.java/1.3/Mon Oct 15 11:07:27 2012//
/ PropertyListener.java/1.1/Tue Sep 29 12:57:38 2009//
Believe I had the same problem. It drove me crazy as I couldn't see what caused it or why it started.
In eclipse open Preferences... and then select:
Team > CVS > Ext Connection Method
Change from "Use an external program to connect" to "Use another connection method to connect".
I have a (bad) habit of sometimes clicking the Restore Defaults button or random preferences sections. I probably did that, forgot about it and had that annoying problem for weeks.
I'm a Mac user. That may be part of the problem. Don't know if the external program is configured the same on all platforms (or even exists).
In Eclipse Preferences > Team > File Contents on the machine in question I had .cgi set as binary and on my home setup the default, ASCII, for .cgi files, as soon as I checked some sources from my home setup the machine in question recognised next time I tried to update that the files are completely different now and were locked with that sticky label.
To restore it I had to remove the whole project, disconnect, delete CVS metadata, change my settings to ASCII for .cgi and checkout again from the repo, solid as a rock since.
We have files that should be executable, and are happily executable in git, but then editing and committing the file from Eclipse on Windows results in the file mode being changed to remove executability.
This happens regardless of whether core.filemode is set to true or false.
Basically egit seems to be too naive for our purposes (breaking file permissions is the problem, but it also doesn't seem to support git-svn) so we're using msysgit instead - we have to manually refresh in Eclipse after switching branches etc, but that's a small enough sacrifice compared to it breaking our code.
There are recent fixes for the filemode problems post 1.2, e.g. use the nightly build.
I am setting up a project that will be shared among several programmers at my organization. We are using git--to which I am a newcomer. The project directory includes symbolic links to documentation directories that should not be under version control. I want to maintain the symlinks under version control as symlinks, rather than having them dereferenced and all of the content of the symlinked directory placed under version control.
I find that the git command line tool behave the way I want: git add -A. However if I try to use the Eclipse version of git, eGit, to add all the currently unversioned files, using Team->Track on the project context menu, eGit wants to add every file in the symlinked directories. Is there a way to tell eGit that, no, these are really symlinks, and should not be dereferenced?
Our problem was discussed in this: Eclipse Community Forums Thread
It looks like currently the Linux native lstat support is not too easy to make portable. The Least Common Denominator paradigm that they have for programming Eclipse in Java make it harder to do Linux or Mac native stuff. (read: *cough* Windows doesn't support symlinks *cough*).
The good news is:
It seems possible, but they'd need to code it in a way that complies to their 'Write Once Test Everywhere' programming standards. I feel that it's important to have some native stat and lstat support on Linux when using EGit because of this problem, as well as Eclipse bug #346079.
Simply having EGit installed causes slowdowns & IDE freezes when doing a Git Refresh :-(
The bad news is:
These two bugs are stopping me from using EGit for the majority of my git commands. The user experience makes EGit unusable for me. It would be really nice to be able to use EGit within Eclipse so that Mylyn User Stories & Tasks could be tied to feature branches automatically. It would also be great to have the automatic commit message template features. This would make putting the current task & status in the commit message a breeze.
This is bugging me almost enough that I'm ready to see if it's possible to make some scripts to query Eclipse / Mylyn for the current commit message template output, and do the git commit from the commandline using this. I'm not sure how automatic per-user-story feature branch creation would work though.
Until these problems get fixed, I'm sure a lot of EGit users will not be happy :-(
We suffered from this problem cluttering up the commit screen no end, and occasionally causing someone to forget to include a file they had created.
The solution we came up with was to manually edit the .gitignore files to include the paths where the linked files would appear when the symlinks were dereferenced:
/ProjectHomeFolder/.gitignore
Since we were working in the Play Framework we also edited the following ignores:
/ProjectHomeFolder/conf/.gitignore
/ProjectHomeFolder/public/.gitignore
We simply added
/ModuleName for each of the modules that were symlinked and now egit ignores them properly, for completeness here is the full contents of my root .gitignore file, that sits in the root directory of the project:
/.project
/.classpath
/.gitignore
/eclipse
/tmp
/crud
/.git
/.settings
/modules
/conf
/betterlogs-1.0
/chronostamp-0.1
/logisimayml-1.5
/betterlogs-1.0
/sass-1.1
/deadbolt-1.4.2
/jquery-1.0
/log4play-0.5
/messages-1.1.1
/navigation-0.1
/jqueryui-1.0
/scaffold-0.1
/table-1.2
/tabularasa-0.2