[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Resoving tree conflicts results in inconsistent state between two working copies of same branch

From: David Wallace <dave_at_bluepearlsoftware.com>
Date: Thu, 18 Aug 2011 22:02:45 +0000

Ok, I've attached a filtered typescript in which I was able to reproduce the problem, using a subtree in our repository as if it was the full repository. I don't have a full reproduction script, because that would require me to (1) set up a new repository and (2) parse the output from svn log to get the proper range of revision numbers to attach to subsequent commands. But this typescript should be pretty easy to follow manually.

I trust that my comments in the script should illustrate why I think the behavior is a major bug, but to summarize:
1) I have created a scenario following a fairly normal workflow, in which I have checked in changes from a working directory which Subversion then reports as being up to date with the repository, when in fact some of the changes have not actually hit the repository, and
2) Subsequent changes to the file in question from another working directory cause updates on my original working directory to fail with a checksum error, potentially causing loss of data from any subsequent work I may have done in that working directory, thinking it was properly up to date.

Data integrity is a pretty important part of any source code control system: the promise is that your data is safe once you check it in to the repository. This scenario represents a violation of that promise.

Dave Wallace
-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Thursday, August 18, 2011 3:16 AM
To: David Wallace
Cc: dev_at_subversion.apache.org
Subject: Re: Resoving tree conflicts results in inconsistent state between two working copies of same branch

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-19 00:05:01 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.