[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: update and revert bugs [PATCH]

From: <cmpilato_at_collab.net>
Date: 2001-11-05 18:29:58 CET

[resending, this time to the whole list...doh!]

> The problem is that the revert command does not remove the
> revision="0" line from the .svn/entries file. It looks like
> fold_entry() should do this but modify_flags does not contain
> SVN_WC__ENTRY_MODIFY_REVISION. It looks like revert_admin_things()
> should be setting it, how about:
> * subversion/libsvn_wc/adm_ops: revert_admin_things(): restore the
> revision when reverting a replaced file.
> Index: subversion/libsvn_wc/adm_ops.c
> ===================================================================
> --- subversion/libsvn_wc/.svn/text-base/adm_ops.c Sat Nov 3 17:29:27 2001
> +++ subversion/libsvn_wc/adm_ops.c Mon Nov 5 15:24:30 2001
> @@ -825,6 +825,10 @@
> *modify_flags |= SVN_WC__ENTRY_MODIFY_TEXT_TIME;
> entry->text_time = tstamp;
> }
> +
> + /* Restore the revison if reverting a replaced file. */
> + if (entry->schedule == svn_wc_schedule_replace)
> + *modify_flags |= SVN_WC__ENTRY_MODIFY_REVISION;
> }
> if (entry->conflicted)

This might fix the bug in your particular case, but it's not
completely accurate. The problem here is that your fix assumes that
a the file that got replaced was at the same revision as it's parent
directory. This assumption simply cannot be made.

The correct solution, however, does require your patch (as well as
several other changes).

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.

I'll add the above comments to the issue.

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

This is an archived mail posted to the Subversion Dev mailing list.