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

Re: Error during commit (bug or my incompetence?)

From: <cmpilato_at_collab.net>
Date: 2002-07-21 08:15:38 CEST

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

   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:

   svn_error: #21084 : <Transaction is out of date>
     Commit failed (details follow):
   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

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.