cmpilato@collab.net writes:
> We should simply NOT set the revision of an added file to '0' in the
> entries file -- the fact that the entry is scheduled for
> addition/replacement *itself* is enough to know that the revision
> field for that entry is bogus, so we don't need to change it to '0'.
> By not changing it to '0', we are able to preserve that revision
> number so that revert can work properly.
>
> Say I have a directory 'A' at revision 5. In directory 'A' is a file,
> 'foo', which I edit and commit. Now 'A' is still at revision 5, but
> 'A/foo' is at 6. Now, I 'svn rm A/foo', and 'svn add A/foo'. In the
> current code, 'A/foo' would have a revision of 0. This sucks. The
> right way would leave the revision untouched, so that when I 'svn
> revert A/foo' the revision number remains intact, and we aren't lying
> about what revision of 'foo' we have after the revert.
To add to what Mike is saying:
A simple rule is, as long as the text-base is preserved, the revision
number should also be preserved (with other "schedule" flags, such as
`added' or `deleted' telling libsvn_wc whether or not to use that
revision number).
-K
---------------------------------------------------------------------
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:36:48 2006