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:s...@elego.de]
> Sent: Thursday, August 18, 2011 3:16 AM
> To: David Wallace
> Cc: dev@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!
#!/usr/bin/env bash
## TO MAKE THIS RUN YOUR CUSTOM COMPILED SVN, two simple options:
## 1. Adjust your PATH to point at your custom installed location:
## export PATH="$HOME/prefix/svn_trunk/bin:$PATH"
## OR
## 2. Uncomment the four lines below to use aliases into your
## built source tree. The next line is the only line you should
## need to adjust.
# SVNDIR=/path/to/built_subversion_source_tree
# function svn() { "$SVNDIR/subversion/svn/svn" "$@"; }
# function svnserve() { "$SVNDIR/subversion/svnserve/svnserve" "$@"; }
# function svnadmin() { "$SVNDIR/subversion/svnadmin/svnadmin" "$@"; }
set -e
svn --version
BASE="`mktemp -d /tmp/svntest.XXX`"
echo "BASE = $BASE"
REPOS="$BASE/repos"
WC="$BASE/wc"
URL="file://$REPOS"
svnadmin create "$REPOS"
# enable all revprop changes
cat > "$REPOS/hooks/pre-revprop-change" <<EOF
#!/usr/bin/env sh
exit 0
EOF
chmod a+x "$REPOS/hooks/pre-revprop-change"
svn co -q "$URL" "$WC"
set +e
set -x
cd "$WC"
## ACTUAL TEST
# create basic structure in repos
svn mkdir trunk branches
svn commit -mm
# create a file in trunk
cat > trunk/file <<END
line1
line2
line3
END
svn add trunk/file
svn commit -mm trunk
# create a file in trunk
cat > trunk/file <<END
line1
line2
line3 modified!
END
svn ci -mm
#...
# while in a working copy, we can use '^/' (here making a branch)
svn copy -m "branch one" ^/trunk ^/branches/br1
# if you want a separate checkout of it:
WC_BR1="$BASE/br1"
svn checkout "$URL/branches/br1" "$WC_BR1"
cd "$WC_BR1"
ls
# but technically the branch now also exists in the "big" working copy
cd "$WC"
svn update
#...
# if you need another separate working copy...
WC_TRUNK="$BASE/trunk"
svn checkout "$URL/trunk" "$WC_TRUNK"
cd "$WC_TRUNK"
#...
## END
set +x
echo "BASE = $BASE"
svn, version 1.7.0-dev (under development) compiled Aug 13 2011, 23:01:21 Copyright (C) 2011 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme BASE = /tmp/svntest.WEj + cd /tmp/svntest.WEj/wc + svn mkdir trunk branches A trunk A branches + svn commit -mm Adding branches Adding trunk Committed revision 1. + cat + svn add trunk/file A trunk/file + svn commit -mm trunk Adding trunk/file Transmitting file data . Committed revision 2. + cat + svn ci -mm Sending trunk/file Transmitting file data . Committed revision 3. + svn copy -m 'branch one' '^/trunk' '^/branches/br1' Committed revision 4. + WC_BR1=/tmp/svntest.WEj/br1 + svn checkout file:///tmp/svntest.WEj/repos/branches/br1 /tmp/svntest.WEj/br1 A /tmp/svntest.WEj/br1/file Checked out revision 4. + cd /tmp/svntest.WEj/br1 + ls file + cd /tmp/svntest.WEj/wc + svn update Updating '.': A branches/br1 A branches/br1/file Updated to revision 4. + WC_TRUNK=/tmp/svntest.WEj/trunk + svn checkout file:///tmp/svntest.WEj/repos/trunk /tmp/svntest.WEj/trunk A /tmp/svntest.WEj/trunk/file Checked out revision 4. + cd /tmp/svntest.WEj/trunk + set +x BASE = /tmp/svntest.WEj
signature.asc
Description: OpenPGP digital signature
