I know, I know -- it's been a long time. But I finally freed up a few
cycles to look at your bug.
> In any case, here's select parts of my bash history that affects
> svn. I'll try to be complete but skipping typos, ls and such:
>
> ./svnadmin create ~/svn
> < created some files in a directory >
> svnadmin import file:///home/scode/svn .
> mkdir co
> cd co
> svn co file:///home/scode/svn
> cd svn/
> vim README
> svn commit
> svn move directory directory_newname
> svn commit
> rm -rf directory
> svn cp directory_newname alpha1
> svn commit
> svn status
> svn update
> svn log directory_newname/
> svn log alpha1
> cd directory_newname/
> vim aFile.txt
> svn commit -m 'Added a line of text'
> vim secondfile
> svn commit -m 'added file'
> svn add secondfile
> svn commit -m 'added file'
> cd ..
> svn cp directory_newname alpha2
> svn commit
>
> And this is where I got the error message. I tried commiting multiples
> times etc. Then I did that revert, and another svn copy followed by a
> svn commit completed successfully.
In a previous mail of yours, you said you were getting the following
message:
Adding alpha2
Adding alpha2/aFile.txt
svn_error: #21053 : <General filesystem error>
Commit failed (details follow):
svn_error: #21053 : <General filesystem error>
add_file `alpha2/aFile.txt': got copy_path, but no copy_rev
Now, this bug I know Ben fixed recently. However, now I'm getting:
subversion/libsvn_client/commit.c:685
svn_error: #21084 : <Transaction is out of date>
Commit failed (details follow):
subversion/libsvn_ra_local/commit_editor.c:112
svn_error: #21084 : <Transaction is out of date>
out of date: `alpha2/aFile.txt' in txn `8'
And reverting, re-copying, and re-committing doesn't change anything
(well, except the txn number increments by 1 each time). And
technically speaking, the error is correct -- the specific state of
my working copy is technically bound to clash with stuff. Why?
Well, here is the `svn st -v' before the copy:
_ 4 4 cmpilato .
_ 4 2 cmpilato ./README
_ 4 4 cmpilato ./alpha1
_ 4 4 cmpilato ./alpha1/aFile.txt
_ 4 3 cmpilato ./directory_newname
_ 5 5 cmpilato ./directory_newname/aFile.txt
_ 6 6 cmpilato ./directory_newname/secondfile
And afterward:
_ 4 4 cmpilato .
_ 4 2 cmpilato ./README
_ 4 4 cmpilato ./alpha1
_ 4 4 cmpilato ./alpha1/aFile.txt
A + - 3 cmpilato ./alpha2
_ + - 5 cmpilato ./alpha2/aFile.txt
_ + - 6 cmpilato ./alpha2/secondfile
_ 4 3 cmpilato ./directory_newname
_ 5 5 cmpilato ./directory_newname/aFile.txt
_ 6 6 cmpilato ./directory_newname/secondfile
Now, while it isn't shown above, the "copyfrom revisions" of alpha2,
alpha2/aFile.txt, and alpha2/secondfile are 4, 5, and 6 respectively.
Under the hood, the fact that the files in alpha2 have different
revisions than alpha2 itself means that during the commit, they are
each copied individually in addition to the copy of alpha2 itself.
That is, we see these operations:
copy revision 4 of directory_newname to alpha2
copy revisoin 5 of directory_newname/aFile.txt to alpha2/alFile.txt
copy revisoin 6 of directory_newname/secondfile to alpha2/secondfile
Those additional copies are conflicting with themselves (please don't
ask me to explain it right now...I'm sleepy). Note that if you insert
an `update' before the `copy; commit', it should all work. Why?
Well, after the update everything in the tree is at revision 6, so the
commit's copy operation is a single non-conflicting step:
copy revision 6 of directory_newname to alpha2
Anyway. All that to say that your original bug is, I believe, fixed,
but your particular use-case still highlights some places where
Subversion could stand improvement.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 21 08:17:14 2002