Tree conflicts with local replacements and deletes

[Erik Huelsmann <eh...@gmail.com>]

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.

I'd like to change the update behaviour to the above.

Comments?

bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Tree conflicts with local replacements and deletes

["C. Michael Pilato" <cm...@collab.net>]

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 <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand