On Wed, Aug 17, 2011 at 11:38:57PM +0000, David Wallace wrote:
> I just described my experience inadvertently creating an inconsistent
> state between two working copies of the same branch while trying to
> resolve tree conflicts over at:
> http://stackoverflow.com/questions/767763/svn-how-to-resolve-new-tree-conflicts-when-file-is-added-on-two-branches/7100512#7100512
> To make this more self-contained, I'll repeat the key text here:
>
> (1): I had added some files while working on my initial branch,
> branch1; (2) I created a new branch, branch2 for further development,
> branching it off from the trunk and then merging in my changes from
> branch1 (3) A co-worker had copied my mods from branch1 to his own
> branch, added further mods, and then merged back to the trunk; (4) I
> now wanted to merge the latest changes from trunk into my current
> working branch, branch2. This is with svn 1.6.17.
>
> The merge had tree conflicts with the new files, and I wanted the new
> version from the trunk where they differed, so from a clean copy of
> branch2, I did an svn delete of the conflicting files, committed these
> branch2 changes (thus creating a temporary version of branch2 without
> the files in question), and then did my merge from the trunk. I did
> this because I wanted the history to match the trunk version so that I
> wouldn't have more problems later when trying to merge back to trunk.
>
> Merge went fine, I got the trunk version of the files, svn st shows
> all ok, and then I hit more tree conflicts while trying to commit the
> changes, between the delete I had done earlier and the add from the
> merge.
>
> Did an svn resolve of the conflicts in favor of my working copy
> (which now had the trunk version of the files), and got it to commit.
> All should be good, right?
>
> Well, no. An update of another copy of branch2 resulted in the old
> version of the files (pre-trunk merge). So now I have two different
> working copies of branch2, supposedly updated to the same version,
> with two different versions of the files, and both insisting that they
> are fully up to date!
>
> Checking out a clean copy of branch2 resulted in
> the old (pre-trunk) version of the files. I manually update these to
> the trunk version and commit the changes, go back to my first working
> copy (from which I had submitted the trunk changes originally), try to
> update it, and now get a checksum error on the files in question.
>
> Blow the directory in question away, get a new version via update, and
> finally I have what should be a good version of branch2 with the trunk
> changes. I hope.
>
> Further notes: Our standard working practice is that all merges
> except merges from the trunk are done with a specific range of
> revision numbers, getting the relevant revisions via svn log
> -stop-on-copy on the appropriate branch. This applied to my merge
> from branch1 to branch2, my co-worker's merge from my branch1 to his
> branch, and his merge from his branch back to the trunk, but not to my
> merges from the trunk described above. I'm not sure if this matters,
> but I report it here in case it makes a difference when trying to
> reproduce the problem.
Hi David,
you've provided a long explanation of a problem which is very complicated
and very hard to reproduce remotely. I am also not sure which part of
Subversion's behaviour you consider a bug. There are certainly annoying
problems in the situations you describe but where do you think the fault
lies with Subversion exactly?
Long prose is not an effective medium for communicating problem reports
and reproduction recipes via email. Prose lacks detail and is ambiguous.
Prose works well when talking to someone next to you who can ask questions
back, look at your screen, and maybe even try out some things on your
computer. But it is very hard for recipients of email to guess what
really happened on your computer. So if you consider your email a bug
report then please follow the guidelines on this page:
http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs
Apart from clearly explaining what you consider a bug, please provide a
full command line transcript of the situation you are describing.
Even better would be a full reproduction script starting off with an
empty repository and running a sequence of commands that trigger the problem.
The time you spend on this will be worth it. Thanks!
Received on 2011-08-18 12:18:40 CEST