On Friday 31 October 2003 1:58 pm, Ben Collins-Sussman wrote:
[I said:]
> > If I do the following ...
...
> > svn mv dir dir2
> > svn commit -m 'moved dir to dir2'
> >
> > ... then the last operation fails with this output:
> >
> > Deleting dir
> > svn: Transaction is out of date
> > svn: Commit failed (details follow):
> > svn: out of date: 'dir' in transaction '3'
> >
> > Is this really reasonable?
>
> For now, yes, this is expected. If you had run 'svn up' before
> attempting to commit, it would have worked.
>
> The problem is that 'svn mv' == 'svn cp; svn rm'. And one of our two
> rules of directory versioning is "you cannot delete something that is
> out of date." The commit had no problem adding 'dir2' as a copy of
> 'dir', but because 'dir' was not at HEAD, the server refused to delete
> it.
Note that I asked whether it's *reasonable*, not whether it's
*expected*. :-) I don't think the answers to the two questions
are the same.
How difficult would the following be? (I'm guessing that the
answer is "altogether too difficult".) In txn_body_commit,
before giving up because a txn is out of date, check to see
whether the two revisions are "the same" (i.e., nothing has
changed between them). If they aren't, then we report
SVN_ERR_FS_TXN_OUT_OF_DATE as at present. But
if they're the same, then we allow everything to go ahead.
We must be able (in principle) to tell whether anything has
changed, because otherwise "svn status" wouldn't work.
It naively looks to me as if svn_fs_contents_changed will
determine this.
Doubtless I'm being *very* naive here. Enlighten me ...
--
Gareth McCaughan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 31 23:17:32 2003