Community
Participate
Working Groups
when a new revision of a file was checked in to CVS that had no changes to the one locally, I got a conflict reported, but no file showed up in the Sync browser. The status line said (1 conflict, no incoming changes, no outgoing changes, no new resources.), but I could not identify the file. Eventually, by elimination, I hunted it down to a file that turned out to be identical in the local workspace to the remote revision, but the remote one was a revision later. Not a very serious bug, but an annoying one...
Just to confirm this bug - I see the same thing here. Cheers, Dave.
This is because "compare file contents" is on by default in the sync view. If you uncheck the option "e.g. it's in the drop down menu of the synchronize view) the conflict will appear. For future, it would be nice to automatically turn off the option if the sync view is empty *but* there are actually timestamp changes. Won't be in 2.1 though. I also changed the title of the bug.
Not sure if this (Jean's analysis) is the most desirable behaviour. If you sync on the offending file exclusively, you get the message "Workspace resources are same as remote" or somesuch, which is ideal as you can then replace the file with the CVS version, or commit it if you really want to. My gripe with the behaviour in the original report was that there is a difference between the browser and the status line that was far from obvious, which wasted the users time analysing why. Personally I would prefer it that if "content comparison" is on, for the identical file to be dropped from the comparison list, or maybe put into a separate bucket where the user can decide whether they want the files replaced or committed.
This is now handled properly in compare (i.e. the file does not show up in the compare or the status line).
