Is there a way, with TortoiseCVS, to see what has changed in the repository since the last CVS update?
I am used to Eclipse's synchronize function. But now I want to view differences in a directory that isn't an eclipse project.
I could check out the project somewhere else and use any diff tool. But that's ugly.
The command line version of cvs provides the '-n' option for this purpose. From the cvs manual:
Do not change any files. Attempt to execute the `cvs_command', but only to issue reports; do not remove, update, or merge any existing
files, or create any new files.
Note that CVS will not necessarily produce exactly the same output as without `-n'. In some cases the output will be the same, but in
other cases CVS will skip some of the processing that would have been
required to produce the exact same output.
The option is also available in Tortoise: Choose "CVS Update Special" from the context menu. In the dialog check the box "Simulate Update" (it's on a separate tab in newer version of Tortoise).
However, I find the feature to be of limited usefulness, due to it's cryptic output and low level of integration (e.g. it's not possible to click on a file and actually view the diff's).
Related
I am using mercurial via tortoiseHg (windows) as a source control management tool.
I am used to merge using beyond a compare. Today, I have to perform a very complex merge and I just discovered a new feature (my client was updated some days ago) that is extremely annoying.
When I have a conflit and ask Mercurial to take the "other" file and keep the original in a .orig file, the .orig is added with <<<<<<< local and >>>>>>> other, but more than this, the other part is merged into the original one !!!
The two parts are then unaligned and it's impossible to guarantee that the merge is OK because you have to review it line by line with no help from the comparision tool. (see screen below).
http://s13.postimg.org/yor6gno47/Untitled.jpg
I want to disable this feature, but so far, I am unable to do it. Thanks so much for help as this is furthermore blocking my work.
Regards.
The launching of a specific merge tool isn't something Mercurial controls. It does, however, have a robust mechanism for Merge Tool Configuration that allows you to provide a preference order and it will use the first one it can find. The builders of various Mercurial installation packages (ubuntu, etc.) and tools that include Mercurial (TortoiseHG, etc.) all provide their own Merge tool configuration preference list.
Either the old merge tool configuration list you had not longer points to Beyond Compare at the right location (upgraded BC and the directory name changed, etc.) or you got a new merge tool configuration list when you updated some software that included mercurial. Either way that page on MergeToolConfiguration will help you find your preference list in your hgrc files and update or correct it.
Tl;Dr: this isn't a "new" feature it's your new installation being less tailored for your system than your old one. Maybe find who packaged that one and copy the merge tool config.
There are often conflicts in the Xcode project file (Project.xcodeproj/project.pbxproj) when merging branches (I'm using git). Sometimes it's easy, but at times I end up with a corrupt project file and have to revert. In the worst case I have to fix up the project file manually in a second commit (which can be squashed with the previous) by dragging in files etc.
Does anyone have tips for how to handle merge conflicts in big and complex files like the Xcode project file?
EDIT-- Some related questions:
Git and pbxproj
Should I merge .pbxproj files with git using merge=union?
RESOURCES:
http://www.alphaworks.ibm.com/tech/xmldiffmerge
http://www2.informatik.hu-berlin.de/~obecker/XSLT/#merge
http://tdm.berlios.de/3dm/doc/thesis.pdf
http://www.cs.hut.fi/~ctl/3dm/
http://el4j.svn.sourceforge.net/viewvc/el4j/trunk/el4j/framework/modules/xml_merge/
Break your projects up into smaller, more logical libraries/packages. Massive projects are regularly the sign of a bad design, like the object that does way too much or is way too large.
Design for easy rebuilding -- this also helps if you're writing programs which must be built by multiple tools or IDEs. Many of my 'projects' can be reconstructed by adding one directory.
Remove extraneous build phases. Example: I've removed the "Copy Headers" build phase from all projects. Explicitly include the specific files via the include directive.
Use xcconfig files wherever possible. This also reduces the number of changes you must make when updating your builds. xcconfig files define a collection of build settings, and support #include. Of course, you then delete the (majority of) user defined settings from each project and target when you define the xcconfig to use.
For target dependencies: create targets which perform logical operations, rather than physical operations. This is usually a shell script target or aggregate target. For example: "build dependencies", "run all unit tests", "build all", "clean all". then you do not have to maintain every dependency change every step of a way - it's like using references.
Define a common "Source Tree" for your code, and a second for 3rd party sources.
There are external build tools available. This may be an option for you (at least, for some of your targets).
At this point, a xcodeproj will be much simpler. It will require fewer changes, and be very easy to reconstruct. You can go much further with these concepts to further reduce the complexity of your projects and builds.
You might want to try https://github.com/simonwagner/mergepbx/
It is a script that will help you to merge Xcode project files correctly. Note that it is still alpha.
Disclaimer: I am the author of mergepbx.
The best way I have found is to instruct Git to treat the .pbxproj file as a binary. This prevents messy merges.
Add this to your .gitatributes file:
*.pbxproj -crlf -diff -merge
To compare two Xcode projects open open FileMerge (open xcode and select Xcode (from the manu pane) --> Open developer tools --> FileMerge).
now click "left" button and open xcode project main directory.
click "right" button and open xcode project main directory to compare.
Now click "merge" button!
Thats it!
Another option to consider which may help to reduce the number of times you experience the problem. To explain, I'll call the branch that team members' branches come from the "develop" branch.
Have a convention in your team that when the project file is modified, the changes (along with any other changes required to ensure the build integrity) are committed in a separate commit. That commit is then cherry picked onto the develop branch. Other team members who plan to modify the project file in their branch can then either cherry pick into their branch or rebase their branch on the latest develop. This approach requires communication across the team and some discipline. As I said, it won't always be possible; on some projects it might help a lot and on some projects it might not.
In IntelliJ, I can have different change lists so that I can put certain files that I never want to commit into a different change list, and I won't be prompted to commit those files unless I select that change list. For example, certain database configuration files, eclipse project files etc., I want to rarely or never commit.
Is there a way to do this using Subversion in Eclipse? I haven't been able to find it so I have to uncheck the files I don't want to commit every time. Note that I can't use svn:ignore because these files are, and should be, in the repository.
You can do this in the Synchronize view. Click the Show Change Sets button. You can then add changed files to change sets (and create new change sets) from the right-click menu.
While the notion of change set of change list is not directly supported by subversion, one possibility would be to use SVN in conjunction with Mylyn.
You could set each group of files to a different task and see if subclipse allows you to commit only one or several tasks through Mylyn.
I have not tested that configuration directly, but it is worth a try.
An option like (see Mylyn Wiki):
Automatically create and manage with task context - Enables automatic change set management. Change sets will be created automatically so that you can commit or update only resources that are in a task's context.
sounds promising.
Change Sets in eclipse (subclipse plugin) does not work too well. If you close the project and reopen it, then either your change sets disappear or all the files you've previously assigned to a change set are now unassigned. SVN:ignore does not work if it happens to be a directory but you want to track files which inside the directory (don't ask how this happens - difficult to explain). IntelliJ change list is much better.
How about putting those files on svn:ignore list?
(set the files to exclude as values of svn:ignore property)
They will be just excluded from versioning so that they never get
commited and any changes to these files will be ignored by subversion.
If you get the TeamCity plugin you can have a more advanced Synchronize view than normal in eclipse.
Or just keep using IDEA......
Me and my friend using flex builder (eclipse based) with subclipse for a project.
Before committing I always update but sometimes I could not commit because of conflicts. Then I use Team->Synchronize with Repository and it shows at the right side latest from repository and at the left side the my current working copy. It has a button to copy from all non-conflicts from right to left (from latest repository to my working copy). But there are still conflicting lines.
Sometimes I just want to copy from left to right but there is no button for that (I mean overwriting repository file lines with my lines). After copying non-conflicting parts from right to left I just want to commit left side (I want to overwrite and commit my final file to repository). I cannot commit because of these conflict issues. Then my friend can use Replace With-> Latest from Repository command to get latest overwrited version.
Subclipse documentation is weak I could not find any good guide on the Internet. Could you explain subclipse conflict resolution step by step for a dummy like me? A video showing the steps, or an alien technology to fix it quickly will be fine. Are there any better (easier) solution for source control for eclipse?
(I use subclipse 1.4)
Yes, you are right. There is no button for that. in the Diff View(Side-by-Side View) the items in red are in conflict. They can not be automatically merged. You must review the item in conflict and manually resolve it by copying/editing the block of code that is in conflict.
After committing to or updating from repository(Synchronize with Repository) you'll see in the Console view that some items are in conflict. When you take a look at that file in Package you'll see 3 files right next to your original file:
myfile.txt (original file)
myfile.txt.mine
myfile.txt.r3293
myfile.txt.r3501
Right-click your original file then select Team -> Edit Conflict. In the Diff View provided, edit the file on the left-side to match the final result you want. (i.e. You may want to keep some of your changes and copy over new update from the revision in SVN, discard all changes and only keep your changes, etc.) After you are done, save the file. Right click your original file again then select Team -> Mark Resovled.
You will see that the addition 3 files disappear. You can now "safely" commit your work.
There is no easy way to do this since SVN can't decide what's the best option when such conflict arise.
I know this thread is old, but if someone is looking for an updated answer, my experience can help.
I'm using subclipse 1.8. Right-clicking on the original file and selecting "Mark Resolved...", you'll have several options, among others, take the local file or the base file as the correct version. You can save time with these options.
I can't find "Mark Resolved" so instead I clicked "Mark as Merged" after manually deleting the generated files.
Do the following steps:
Copy your latest working updates to a safe place.
Select the file which has conflicts..right click > select replace with>>Select Latest from Repository.
Then go back to your saved working copy and manually replace the current file contents (which has been overwritten in above step) with yours.
Then from team select Commit...
This way conflicts should be resolved and you saved your latest updates to SVN Repository.
I'm pretty used to how to do CVS merges in Eclipse, and I'm otherwise happy with the way that both Subclipse and Subversive work with the SVN repository, but I'm not quite sure how to do merges properly.
When I do a merge, it seems to want to stick the merged files in a seperate directory in my project rather than overwriting the old files that are to be replaced in the merge, as I am used to in CVS.
The question is not particular to either Subclipse or Subversive.
Thanks for the help!
Merging an entire branch into trunk
Inspect the Branch project history to determine the version from which the branch was taken
by default Eclipse Team "History" only shows the past 25 revisions so you will have to click the button in that view labeled "Show All"
when you say "Show All" it will take you back past the branch date and show you all the history for trunk as well so you'll have to search for your comment where you branched
NOTE: if you use Tortise SVN for this same task (navigate to the branch and select "Show Log") it will show you only the branch history so you can tell exactly where the branch began
So now I know that 82517 was the first version ID of the branch history. So all versions of the branch past 82517 have changes that I want to merge into trunk
Now go to the "trunk" project in your Eclipse workspace and select "right click - Team - Merge"
The default view is the 1 url merge
select the URL of the branch from which you are merging
under Revisions select "All"
press OK
This will take you to the "Team Synchronizing" perspective (if it doesn't you should go there yourself) in order to resolve conflicts (see below)
Re-Merging more branch changes into trunk
Insepct the trunk project history to determine the last time you merged into trunk (you should have commented this)
for the sake of argument let's say this version was 82517
So now I know that any version greater than 82517 in the branch needs to be merged into trunk
Now go to the "trunk" project in your Eclipse workspace and select "right click - Team - Merge"
The default view is the 1 url merge
select the URL of the branch from which you are merging
under Revisions select "Revisions" radio button and click "Browse"
this will open up a list of the latest 25 branch revisions
select all the revisions with a number greater than 82517
press OK (you should see the revision list in the input field beside the radio button)
press OK
This will take you to the "Team Synchronizing" perspective (if it doesn't you should go there yourself) in order to resolve conflicts (see below)
Resolving Conflicts
You should be at the "Team Synchronizing" perspective. This will look like any regular synchronization for commit purposes where you see files that are new and files that have conflicts.
For every file where you see a conflict choose "right click - Edit Conflicts" (do not double click the file, it will bring up the commit diff version tool, this is VERY different)
if you see stuff like "<<<<<<< .working" or ">>>>>>> .merge-right.r84513" then you are in the wrong editing mode
once you have resolved all the conflicts in that file, tell the file to "mark as merged"
once all the files are free of conflicts you can then synchronize your Eclipse project and commit the files to SVN
I typically check out both branches and then use the compare to each other option which does a synchronize-like compare of the two source trees. After integrating the changes into one branch, you can recommit back to the repository.
Use Eclipse integration, it works perfectly fine.
The main change from CVS, is that you only merge deltas from a branch, ie changes from one revision to another.
That is to say you have to track the correct start revision somehow (unless you have svn 1.5 merge history)
If you got that right, it's only up to you to get the changes right with the compare editor.
Firstly, if you are seeing ">>>>>" and such in your files when you view them in Eclipse, this probably means that you are not looking at the file with the proper compare editor. Try right-clicking on the file in the Project view or Synchronize view and selecting "Edit Conflicts" to bring up a compare editor that will show you the conflicting regions graphically rather than as text. Note that the compare editor that comes up for "Edit Conflicts" is different from the one that you get when you just doubleclick on a file in the Synchronize view -- the doublieclick compare editor shows the differences between your current file and the way it existed when you last checked it out or updated it, while the Edit Conflicts compare dialog shows the differences between two sources of changes (for instance, the changes you merged versus the changes that existed in your workspace before you merged).
Secondly, you may wish to be aware of a bug in some versions of the Eclipse subversive plugin which causes all files that accepted merge changes to be incorrectly marked as having conflicts. This bug has been fixed, but a lot of people don't seem to have updated to get the fix yet. Further details here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=312585
Remember that with svn reverting a modified tree to a clean state is fairly easy. Simply have a clean workspace on the merge destination branch and run the merge command to import the modifications from the merge source branch, then synchronize your workspace and you will get your usual eclipse comparison window showing all the merge modified files and the conflicts.
If for some reason you can't solve the conflicts you can svn revert on the project and go back to a clean state, otherwise you do the merge in place and once you are done you can commit. Note that you don't have to commit, once you are done handling the conflicts you can also return to the dev view, verify that the code compiles, run your unit tests, whatever and then synchronize again and commit (once the conflict are locally resolved they won't come back)
last time I looked, when you use subclipse merge command it will overwrite the merged file (using conflict markers to show conflicting areas) and put the original left and right side of the merge in the same place. it shouldn't put anything in different directories.
As a rule of thumb, it is best to commit all merge modifications in a single commit and to only have the merge modifications in the commit so that you can rollback the merge later if needed.
openCollabNet's merge tool for subclipse is pretty neat. There are many merging types available and the merging I just performed with it when seamlessly. I recommend it.
The one thing that syncrhonize view in eclipse lacks is check-in capability. In Team synchronization view I can view all my changes and resolve conflicts, so it would be rather intuitive to check-in right there instead of going back to java view and do check-in.
I would advise not trying to use Eclipse's plugins as your primary access to Subversion.
If you are developing on Windows, TortoiseSVN is the best program that I have seen for Subversion access. Explore to the directory of which you wish to merge, right click on it and use the Tortoise SVN merge option. Assuming a non-interactive merge, once you get conflicts, you'll have to go through each conflicted file and edit the conflicts before marking them as resolved. For this process I recommend a program called KDiff3, which shows your local repository copy (what was stored in the .svn before the merge), your local copy (including any changes), and the copy coming from the repository, and allows you to easily see (and even hand-modify if needed) the result of the merging. It also handles a bunch of minor conflicts automatically.
KDiff3 is portable, TortoiseSVN is a windows shell extension, so if you're using another environment, I would try to just use SVN to merge. But that would be much more of a pain :)
I landed here because I was looking for a way to merge in an external merge editor (KDIFF3) but start the merge from eclipse. I wasn't satisfied with the answers provided above. So here is ho to configure kdiff3 as merge and diff editor for SVN in eclipse:
go to Windows -> Preferences → Team -> SVN -> Diff Viewer
Add a new config (add button):
Extension or mimetype: * - if you wish you can specify different mimetypes for different editors, I didn't need that thus the alquantor.
Diff:
Program path C:\Program Files\KDiff3\kdiff3.exe (or wherever you have your merge editor - sry for the windows path, feel free to add a linux version in the comments or edit this answer.)
Arguments:
${base} ${mine} ${theirs}
Merge:
Program path C:\Program Files\KDiff3\kdiff3.exe
Arguments:
${base} ${mine} ${theirs} -o ${merged}
This will probably work as well for other merge editors, but with a different argument syntax (figure it out an let us know :) ).
The usage is as usual (team->edit conflicts) for merging and compare->foo for the diff view.
Cheers