[darcs-users] "replace" patch type (was: bug or inconsistency in darcs replace)

[David Roundy]

On Sat, Mar 27, 2004 at 09:01:51PM +0100, Marnix Klooster wrote:
> Kevin Smith wrote on the dangers of the "replace" patch type:
> 
> > But probably my biggest concern is that the change extends unbounded 
> > through time and space. A "replace" that does exactly what I want in my 
> > repo today might do something unexpected and unwanted in a different 
> > repo, or at some point in the future.
> > 
> > You consider that a "feature", because it will automatically "fix" uses 
> > of the old name in other code. I consider it a problem, because it is 
> > too unpredictable and may break code in strange ways.
> > 
> > It is a powerful tool, but a dangerous one. I am concerned about handing 
> > this loaded gun to everyone without proper warnings, training, and 
> > safety mechanisms. RCS systems should (IMHO) do whatever they can to 
> > keep your code safe and avoid surprising you.
> 
> While experimenting with 'modular patch types' (see my recent e-mail) I
> realized that there are actually two different kinds of 'replace':
>  - replace now: replace every current occurrence of X that are visible
>                 in the current context (i.e., the current set of
>                 patches in my repository).
>  - replace always: replace every occurrence of X in any patch that will
>                    ever be in the context of this patch.
> (Invent better names please.)
> 
> What darcs now has is the 'replace always' version, which is both useful
> and dangerous.

As I said to Kevin, "always" is misleading.  What it really means is "when
merging this patch with another, replace every occurence of X."  But the
only case in which a patch will "always" get merged with every other patch
is if that patch is on a branch all its own and is never brought into the
main development trunk.

> What Kevin wants is just a 'replace now' patch.  Which is actually not
> really different from a hunk patch, so I don't think it would really add
> something.  Or would it?

Well, it wouldn't commute with any hunk containing either the original or
final tokens, but could commute with replaces of other tokens.  This would
mean that it would commute *less* than the corresponding hunk patch (since
it would still be nonlocal), and have conflicts more often (assuming hunk
patches are more common than replaces).  I suppose you might want this,
since it would be even "safer" than hunk patches, assuming you never pay
attention when merging unless a conflict happens.

But on the whole, I don't think this sort of a patch would be helpful.
-- 
David Roundy
http://www.abridgegame.org