On Mon, 2004-02-09 at 12:42, makl@tigris.org wrote:
> G:\repos>svn ci -m "" wc2
> svn: Commit failed (details follow):
> svn: Out of date: 'dir1' in transaction '4'
> Deleting wc2\dir1
>
> G:\repos>svn up wc2
> A wc2\dir1\file2
> Updated to revision 2.
Here's the problem: the update added file2 to the directory which was
already scheduled for deletion. But it *didn't* add file2 to the copied
directory (the one scheduled for addition-with-history.)
>
> G:\repos>svn ci -m "" wc2
> Deleting wc2\dir1
> Adding wc2\dir2
> Adding wc2\dir2\file1
Yup, see, it only added what was explicitly scheduled for addition.
First it tells the repository: "copy revision 1 of dir1 to dir2". The
repository does that, so now the commit transaction's dir2 has nothing
but file1 in it. Then 'file1' is linked into the transaction again (a
redundant but harmless action.).
The copied directory in the repository has zero knowledge of file2:
it's not in the copy-source (rev 1 of dir1), nor was it committed from
the working copy, because it never got scheduled for addition.
Hm, I think this is a known problem/limitation with libsvn_wc. In a
perfect world, I suppose the 'svn update' would have noticed that it was
adding a file to a directory scheduled for deletion, and then "follow"
some sort of link to the directory scheduled for addition, so the file
can be added there as well. At the moment, our entries file has no such
forward-link, so it can't be done. This is basically a side-effect of
the fact that the working copy doesn't have a concept of "true move".
It only has delete + add-with-history.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 9 21:11:28 2004