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

Hi Dave,

if you've found an inconsistency in Subversion, this is highly interesting
information! The typescript you've attached is certainly useful. But (I'm
sorry to nitpick more) there is a lot of noise in the file and even after
scanning for minutes I have not spotted anything unusual except the final
checksum error.

You've already put a lot of effort in this, and I can certainly translate
your typescript myself. But Stefan would have to do the same, and others
too. So, if you still have more time to spare and are willing to do so, it
would be very helpful if you could distill the reproduction into a runnable
script, that, for added bonus, is as minimal as you can get it while still
producing the error every time.

I have attached a test script blueprint that I use to write my tests. Where
it says "# ACTUAL TEST" you can simply start hacking svn add,commit,... I've
included a few basic examples there for you to get started easily.

This test script creates a new temp folder under /tmp and creates a
repository and a working copy all inside, and does a cd into the working
copy ('cd "$WC"'). All you do is write your svn commands, then run it. It
uses simple file:/// URLs to access the repository, so it cuts out all
network and authentication issues. So if you get valid commands to fail
there, it's definitely Subversion's fault.

BTW, I usually have just one large working copy of all branches in a small
test like this, unless I want to test the checkout command. But if you need
them, there are also examples of creating more working copies in there.

When you're done testing it, run your script like
 ./my_test >my_test.output 2>&1
and attach both test script and the output file.

For illustration I've done just that.

Oh, and, it would be sufficient to write the test up to the point where, as
you say:

>> 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!

No need to try to resolve that any further in the test, as this alone would
be catastrophic enough ;)

So, if you can spare more time on this issue, we would very much appreciate
your effort!

Many thanks,
~Neels

On 08/19/2011 12:02 AM, David Wallace wrote:
> 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!