Bugzilla – Full Text Bug Listing
| Summary: | [Merge] CVS substituted keywords treated as conflicts | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Michael Smith <msmith> | ||||||
| Component: | CVS | Assignee: | platform-cvs-inbox <platform-cvs-inbox> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | aegges, asampaleanu, bjeong, dberindei, dev, ed.burnette, fs, ganesh.jung.extern, info, jan.gentsch, kubak, Matthias.Striegl, michael.knox, Michael.Valenta, nils.gotzhein, olexiyb, pwebster, rlatta, robert.zumwalt, stanio | ||||||
| Version: | 2.1 | Keywords: | helpwanted | ||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | stalebug | ||||||||
| Attachments: |
|
||||||||
|
Description
Michael Smith
Branches And Keyword Expansion - Natural Enemies. All the CVS doc says that you should turn off keyword expansion when merging. We should support/force the -kk option on our update commands. *** Bug 28616 has been marked as a duplicate of this bug. *** *** Bug 37211 has been marked as a duplicate of this bug. *** Not for 3.0. Another possibility is to have ignore filters for text compares. *** Bug 64308 has been marked as a duplicate of this bug. *** I looked a the code a little. It doesn't seem to be a matter of simply
sticking a -kk option somewhere. Wouldn't this code in
CVSMergeSubscriber.compareWithRemote need to be changed to compare the two
files to see if they only differed by keywords and ignore it/mark it as merged
if so?
if (remoteBytes != null
&& localBytes != null
&& local.exists()
&& !ResourceSyncInfo.getRevision(remoteBytes).equals
(ResourceSyncInfo.getRevision(localBytes))
&& contentFilter.select(getSyncInfo(resource),
Policy.subMonitorFor(monitor, 100))) {
// The contents are equals so mark the file as merged
internalMerged(resource);
}
I imagine there's something similar in the Synchronize view but I couldn't
find it.
Ed, I think you are right. Although I can conceive of solutions that involve forcing -kk for text files only (can't do it for the whole project as it would override -kb as well), in the end, such solutions wind up being more complicated then just modifying the local comparison as you suggest. Not for 3.1 There is currently no plan to address this item. Why is there no plan to address this issue? The false conflicts add quite a lot of noise to the sync view during a merge and potentially hide true conflicts. Sure, one could mark as merged all of the offending files, but it would be quite a pain. The problem is that the fix is not trivial and we just don't have the manpower to address it. Sad to hear that this is so difficult to resolve, but as it is, the sync view during a branch merge is half useless - for all "conflicting" files, you have to open the file, check if it's just a keyword diff, and mark as merged as appropriate. When you're talking about tens of files with these conflicts, it's a significant productivity loss. > When you're talking about tens of files with these conflicts, it's
> a significant productivity loss.
+1 on that. We've had some projects eschew $Id$ altogether because of this problem.
I am happy to see that this problem has been reported. I have been struggling with the issue for sometime now. It's more like hundreds of files in false conflicts with my project, and it's surely a pain. I think I have a very simple solution to this problem. As I understand it, cvs itself is very well capable of working around the false conflicts with keyword substitution during a merge. See the cvs manual at http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_5.html#SEC64 Since when using the option "Perform the merge into the local workspace" the merge is effectively performed by cvs itself (and not by the eclipse plugin), it should be no problem to just pass a -kk option along with the cvs merge command. With this in mind, I had gained some hope when I searched the CVS preferences panels (Eclipse 3.1.2) and in the Team->CVS, Tab "Files and Folders" panel I found the "Default text mode" option. I selected "ASCII with keyword compression (-kk)" there, after which I performed the merge again, but it did not change anything. Looking at the CVS console output, I saw that the keyword substitution option "-kk" is not passed along with the cvs command at all. Apparently it is applied only to the commit command. Concluding, a solution very simple to implement could be to offer the user an additional option for selecting the keyword substitution mode. This should be located in the "Team-->CVS-->Synchronize/Compare" preferences panel, and the option should be appended only to cvs update commands. The result would be that a correct handling of keywords would be available at least when "performing the merge into the local workspace". After all, when dealing with hundreds of files, this option is the preferred one anyway. This situation is a bit more complicated then that. Eclipse supports both the standard server side merge and a client side merge (both headless and GUI based). What you suggest would help the server side case and shouldn't be hard to do. However, client side merges and manual merges would need custom handling. Michael, this is exactly what I meant: If at least one of the several ways of doing a merge in Eclipse would handle the keyword conflicts correctly, then this would already be a great improvement over the current status, where this is not handled at all. And again: When you want to merge branches with hundreds of files (I'm currently working in a project with over 3000 source files) then the manual and "client side" merge in Eclipse is not a sensible option anyway. To be more precise: Implementing the correct handling of keywords during merges is easy to implement for exactly that case where it makes most sense: during a merge of a large number of files (because usually one would use the server side merge here.) One more (trivial, but helpful) thing -- don't know why I didn't think of that earlier: Of course one can perform a "server side merge" with correct keyword conflicts handling independently from Eclipse: Just go to the relevant project directory in your Eclipse workspace and use your command line cvs (should be no problem under Windows, U**x and MacOS) to issue the appropriate cvs command directly -- after all, for the "server side merge" Eclipse itself does just that: cvs update -kk -j "common_base_version" -j "branch_name" -d -P . I have just tried it out and (of course) it works flawlessly. After issuing a "Refresh" command in Eclipses Navigator view you are done. Only "real" conflicts are marked with the conflicts markers, file headers with keywords are left in the -kk state (not substituted) and therefore remain unmarked. Reopening. The -kk addition to the merge should be straightforward. I'm not sure when we'll have time to get to it though. This seems like a fairly straight forward change if someone in the community wanted to provide a patch;-) It would be nice if some kind of warning could be supplied to the user in case the CVS server is version 1.11, where specifying -kk option could damage the binary files. We'll investigate this for 3.3. We do not plan on addressing this issue in 3.3. Hmm, I was going to ask why not do it for 3.3, but since we've switched to SVN the issue is moot for us. *** Bug 175088 has been marked as a duplicate of this bug. *** +1 for this issue. Major PITA when dealing with large projects in an environment that has multiple development streams (in our case - 4). Added my vote for this issue. I am wondering why this bug ist still open after more than six (!) years. Is there any secret workaround? Added my vote. PLEASE fix this. It make merging large projects so hard. +1 for this issue. All our source files have cvs ident Created attachment 163174 [details] use option -kk for merging into local workspace if possible This patch will add the option -kk to the update command if "Perform the merge into the local workspace" is selected (see comment #16 and #19). To be on the safe side this option is only added if the CVS server version is 1.12.2 or higher. (In reply to comment #30) > Created an attachment (id=163174) [details] > use option -kk for merging into local workspace if possible > > This patch will add the option -kk to the update command if "Perform the merge > into the local workspace" is selected (see comment #16 and #19). To be on the > safe side this option is only added if the CVS server version is 1.12.2 or > higher. We use 1.11.23 version. Is any specific reason to have 1.12.2 server validation? (In reply to comment #31) > We use 1.11.23 version. Is any specific reason to have 1.12.2 server > validation? Versions prior to 1.12.2 did overwrite whatever keyword expansion mode CVS would normally have used. In particular, this is a problem if the mode had been `-kb' for a binary file. This could cause corrupted binary files. Created attachment 163818 [details]
Avoid conflicts in Sync Preview
Here is a second patch that will prevent conflicts in the Sync Preview due to substituted CSV keywords.
This patch can be applied independently of the first patch.
Axel, I have tried second patch and it does not work for me. Can you give use case that you cover by your second patch? (In reply to comment #34) > Axel, > > I have tried second patch and it does not work for me. > Can you give use case that you cover by your second patch? Consider the following use case: - you added some code in file1 in HEAD - then you backported this particular code to file1 in a BRANCH, so HEAD and BRANCH version of file1 are identical again - you want to merge the complete BRANCH back into HEAD => you will get a conflict in file1 because you are using the CVS keyword $Id$ in file1 (remember that $Id$ includes the CVS version number that is now different because of the backport) My patch will ensure that CVS keywords are ignored when the difference between HEAD and BRANCH version is determined. However, if there are additional changes apart from the CSV keywords you will still get a conflict. I did not address this problem yet. I am waiting for some feedback from some Eclipse CVS developers before I will proceed. I see. I was using different use case. Checkout some branch. Do modification in file. Team/Synchronize with repository or compare with latest from branch. Is it possible do not show different in compare viewer for cvs_ident? -- Olexiy (In reply to comment #36) > I see. I was using different use case. > Checkout some branch. Do modification in file. Team/Synchronize with repository > or compare with latest from branch. > Is it possible do not show different in compare viewer for cvs_ident? > > -- > Olexiy I would like to do this. Unfortunately, I don't know yet where the difference is calculated :( Do you know about http://scratsh.wordpress.com/2009/06/09/eclipse-3-5-plug-in-spy-and-menus/ Alt+Shift+F1 and Alt+Shift+F2 helps a lot (In reply to comment #36) Please Address this bug.. I have over 1200 files with $ID: $ $Name: $ $Version: $ etc.. and that's not the entirety of the code base, more are added every day and this is a nightmare! This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |