Michael Price <email@example.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
Committed revision N.
Michael's working copy now has foo/bar at revision N and foo at some
Next another user Philip does
$ svn mkdir foo/zig
$ svn ci
Committed revision N+1.
Finally Michael tries
$ svn rm 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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Dec 2 03:29:28 2002