You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Michael Price <mp...@atl.lmco.com> on 2002/12/02 01:28:12 UTC
bug
Anyone else seeing this?
$ ~/tmp> dir
$ ~/tmp> svnadmin create repo
$ ~/tmp> svn co file:///`pwd`/repo wc
Checked out revision 0.
$ ~/tmp> dir
total 4
drwx------ 7 mprice mprice 512 Dec 1 20:21 repo/
drwx------ 3 mprice mprice 512 Dec 1 20:22 wc/
$ ~/tmp> cd wc
$ ~/tmp/wc> dir
$ ~/tmp/wc> svn mkdir dir1
A dir1
$ ~/tmp/wc> svn commit -m "new dir1"
Adding dir1
Committed revision 1.
$ ~/tmp/wc> cd dir1
$ ~/tmp/wc/dir1> echo "file" > file1
$ ~/tmp/wc/dir1> svn add file1
A file1
$ ~/tmp/wc/dir1> svn commit -m "file1"
Adding dir1/file1
Transmitting file data .
Committed revision 2.
$ ~/tmp/wc/dir1> echo "other" > file2
$ ~/tmp/wc/dir1> svn add file2
A file2
$ ~/tmp/wc/dir1> svn rm file1
D file1
$ ~/tmp/wc/dir1> svn commit -m "remove file1 - add file2"
Deleting dir1/file1
Adding dir1/file2
Transmitting file data .
Committed revision 3.
$ ~/tmp/wc/dir1> dir
total 2
-rw------- 1 mprice mprice 6 Dec 1 20:23 file2
$ ~/tmp/wc/dir1> cd ..
$ ~/tmp/wc> dir
total 2
drwx------ 3 mprice mprice 512 Dec 1 20:24 dir1/
$ ~/tmp/wc> svn mkdir dir2
A dir2
$ ~/tmp/wc> svn commit -m "new dir2"
Adding dir2
Committed revision 4.
$ ~/tmp/wc> svn mv dir1 dir2
A dir2/dir1
D dir1/file2
D dir1
$ ~/tmp/wc> svn commit -m "mv dir1 dir2"
Deleting dir1
svn: Transaction is out of date
svn: Commit failed (details follow):
svn: out of date: `dir1' in txn `5'
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug
Posted by Ben Collins-Sussman <su...@collab.net>.
Michael Price <mp...@atl.lmco.com> writes:
> Philip Martin writes:
> > Well, you have to run update before committing, but exactly when you
> > do it is up to you.
>
> Guess I've been using CVS too long. With CVS if you are the only person
> committing to a given repository then no update is needed before a
> commit. Its going to take me a little time to get used to having my
> working copy be out of date through only my own actions.
The joy of versioning directories. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug
Posted by Michael Price <mp...@atl.lmco.com>.
Philip Martin writes:
> Well, you have to run update before committing, but exactly when you
> do it is up to you.
Guess I've been using CVS too long. With CVS if you are the only person
committing to a given repository then no update is needed before a
commit. Its going to take me a little time to get used to having my
working copy be out of date through only my own actions.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug
Posted by Philip Martin <ph...@codematters.co.uk>.
Michael Price <mp...@atl.lmco.com> writes:
> Philip Martin writes:
> > When one commits an item (a file or sub-directory) in an otherwise
> > unchanged directory, the version of that directory in the working copy
> > does not change, and so it becomes out-of-date with respect to the
> > repository. One may add an item to an out-of-date directory, provided
> > it does not conflict with an item in HEAD, and one may delete an item
> > from an out-of-date directory provided the deleted item is up-to-date.
> > One cannot delete, or set properties on, an out-of-date directory.
>
> Oh. So the correct way to do what I wanted was to copy/update/delete
> rather than move (which is just copy/delete).
Well, you have to run update before committing, but exactly when you
do it is up to you.
As you other mail indicates the out-of-date detection doesn't always
work, I've rasied issue 1017. Also, looking at the code it appears
that in the some places where out-of-date detection "works" it's not
reliable (see the issue for details) so we may need to rework this
feature.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug
Posted by Michael Price <mp...@atl.lmco.com>.
Philip Martin writes:
> When one commits an item (a file or sub-directory) in an otherwise
> unchanged directory, the version of that directory in the working copy
> does not change, and so it becomes out-of-date with respect to the
> repository. One may add an item to an out-of-date directory, provided
> it does not conflict with an item in HEAD, and one may delete an item
> from an out-of-date directory provided the deleted item is up-to-date.
> One cannot delete, or set properties on, an out-of-date directory.
Oh. So the correct way to do what I wanted was to copy/update/delete
rather than move (which is just copy/delete).
I feel enlightened.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug
Posted by Philip Martin <ph...@codematters.co.uk>.
Michael Price <mp...@atl.lmco.com> writes:
[snip commits that make "dir1" out-of-date]
> Committed revision 4.
> $ ~/tmp/wc> svn mv dir1 dir2
> A dir2/dir1
> D dir1/file2
> D dir1
> $ ~/tmp/wc> svn commit -m "mv dir1 dir2"
> Deleting dir1
> svn: Transaction is out of date
> svn: Commit failed (details follow):
> svn: out of date: `dir1' in txn `5'
This is the way Subversion is designed to work when handling a mixed
revision working copy. Is this becoming a FAQ?
When one commits an item (a file or sub-directory) in an otherwise
unchanged directory, the version of that directory in the working copy
does not change, and so it becomes out-of-date with respect to the
repository. One may add an item to an out-of-date directory, provided
it does not conflict with an item in HEAD, and one may delete an item
from an out-of-date directory provided the deleted item is up-to-date.
One cannot delete, or set properties on, an out-of-date directory.
Consider a user Michael doing
$ svn mkdir foo/bar
$ svn ci
Adding foo/bar
Committed revision N.
Michael's working copy now has foo/bar at revision N and foo at some
revision M<=N.
Next another user Philip does
$ svn mkdir foo/zig
$ svn ci
Adding foo/zig
Committed revision N+1.
Finally Michael tries
$ svn rm foo
D foo/bar
D foo
$ svn ci
Transaction out of date
If Michael's commit is allowed to succeed, it will delete Philip's new
foo/zig without Michael ever being aware that such an item existed.
Note that the problem occurs whenever Michael fails to update after
Philip's commit, in particular it will still occur if we reverse
commits N and N+1 so that foo/zig is created before foo/bar.
The rules for handling out-of-date working copies are to some extent
arbitrary, they could be stricter (not allowing adds in out-of-date
directory say) or they could be more relaxed (allowing deletes of an
out-of-date directory say). At present, the rules that have been
chosen lead to the behaviour that you observe.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org