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