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

Re: Tree conflicts with local replacements and deletes

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2006-09-28 21:18:19 CEST

Erik Huelsmann wrote:
> Before 1.4.0, it wasn't possible to schedule replace-with-history
> items in a working copy. Starting 1.4.0, that has become possible
> (without breaking the working copy).
> Before then, updates involving local deletes (deletes and
> replace-without-history) would not obstruct an update, even when
> content changes were received for the now-deleted item.
> With 1.4.0, updates for replaced-with-history items report a 'Checksum
> mismatch' error. This error comes from the fact that the client is
> incorporating changes to the old file into a file with a completely
> different identity.
> The effect observed with 1.4.0 and replace-with-history items, tells
> me we should have been treating replaced and deleted items receiving
> updates as obstructions.

Well, there are two independent issues here, and I'd prefer not to
conflate them.

1) Absolutely, we should be treating replaced and deleted items the
    same way with respect to this scenario. (I can only hope we all
    agree with this -- seems pretty straightforward to me.)

2) What's up for discussion is just what that behavior is. Today, we
    apply text-deltas to the schedule-delete item's text-base. Surely
    we can do the same thing for schedule-replace items -- we *do* still
    have their text-base around, right, so that you can revert your
    replacement? But is that the right behavior? Should we instead
    flag a conflict on the item, because, after all, if I commit, I
    will be committing the deletion (or replacement) of something other
    than what I actually had when I scheduled that deletion?

C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Thu Sep 28 21:18:33 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.