Branko Čibej <brane@xbc.nu> writes:
> >Cmpilato, please share your wisdom. Does dir_delta need to be tweaked
> >to send deletes before adds? If so, will this screw anything else up?
> >
>
> $ cd /some/wc
> $ svn mv B tmp
> $ svn mv A B
> $ svn mv tmp A
> $ svn ci
> ...
> $ cd /another/wc
> $ svn up
>
>
> Just throwing a spaner in the works,
The 'svn mv tmp A' command above wouldn't work right now anyway. As a
general rule in our wc library, if 'tmp' is already scheduled for
addition, you can't do a copy (another schedule-for-addition).
Here's the comment at the bottom of libsvn_wc/copy.c:
/*
Rabbinic Commentary
Q: Why can't we 'svn cp' something that we just copied?
i.e. 'svn cp foo foo2; svn cp foo2 foo3"
A: It leads to inconsistencies.
In the example above, foo2 has no associated repository URL,
because it hasn't been committed yet. But suppose foo3 simply
inherited foo's URL (i.e. foo3 'pointed' to foo as a copy
ancestor by virtue of transitivity.)
For one, this is not what the user would expect. That's
certainly not what the user typed! Second, suppose that the
user did a commit between the two 'svn cp' commands. Now foo3
really *would* point to foo2, but without that commit, it
pointed to foo. Ugly inconsistency, and the user has no idea
that foo3's ancestor would be different in each case.
And even if somehow we *could* make foo3 point to foo2 before
foo2 existed in the repository... what's to prevent a user from
committing foo3 first? That would break.
*/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:02 2006