[darcs-users] Different approach for "incoherent" patches

David Roundy droundy at abridgegame.org
Thu Nov 25 14:14:47 UTC 2004

On Wed, Nov 24, 2004 at 04:34:36PM +1000, Anthony Towns wrote:
> David Roundy wrote:
> >>I don't understand what you mean by "hide" exactly... How would you 
> >>represent this in the inventory? Have one copy of the patch, and a 
> >>second copy of the patch inverted?
> >It would be represented more like the "depends" listing that every patch
> >has.  It would just be a list of patch IDs (not contents).  Then when darcs
> >goes to display changes, it would not print any changes that are listed
> >on any other patch (or perhaps self-listed?) as a hidden patch.
> So, if you had "A1, A2", then amend-recorded A1 to A1.1, you'd have
> "[A1], A2, A1.1"; which would result in the same repository as if you
> just had "A2, A1.1"?
> So, X<hides: Y> is "X" if Y's not present, but it's "Y^-1' ; X" if Y is
> present? (ie, the inverse of Y, commuted past whatever patches were in
> between Y and X)

No, I wasn't thinking that X<hides: Y> would imply the inverse of Y, but
rather that X depends on Y.  One could have hiding be independent of
dependency, but I think in the usage scenarios I imagine X would also
depend on Y.

> >>Heh. So, how about this usage scenario:
> >>   # hack 1
> >>   darcs record -p 'A1'
> >>   # hack 2
> >>   darcs record -p 'A2'
> >>   # hack 3
> >>   darcs record -p 'A3'
> >>   # err, wait a minute, I need to look at A1 again
> >>   darcs rollback -p 'A[23]'
> So, my inclination here is that I want to go back to exactly where I
> was, even if A2/A3 are completely unrelated. But being able to do an
> amend-record of a patch that's not the most recent is pretty cool, and
> not something I'd even considered.

Right, and not only is it pretty cool, but it's already implemented! :) The
only catch would be if A2 or A3 depended on A1.

> >In this scenario, presumably A2 and A3 both depend on A1, since otherwise
> >we wouldn't need any rolling back or rolling forwards, we could just
> >amend-record A1 straight off.  If this is the case (A2 and A3 don't commute
> >with A1), we can't simply amend-record --unsafe -p A1.  However, if my
> >hiding idea is implemented, we could do
> >
> >darcs amend-record --safe -p A1
> >
> >without rolling back A2 or A3.
> So, I was considering A2 and A3 just to be essentially independent, but
> distracting. So I wanted them out of the way for convenience, but they
> could've stayed around if necessary; whatever. What happens, though, if
> "A1" contains "addfile foo, addfile bah"; A2 and A3 edit foo; and the
> point of amending A1 to A1.1 is to correct bah's name to bar? Hrm, at 
> the moment, it just says "Skipping depended-upon patch: A1. Cancelling 
> amend since no patch was selected."
> So, I guess this means you're saying hiding should do nothing; just 
> change what gets displayed in "darcs changes"; which means if A1.1 
> amends A1; it has to specifically undo any changes from A1 that weren't 
> needed, and depend upon A1 to ensure that the changes were made in the 
> first place. Having a changelog read:
> Wed Nov 24 16:20:52 EST 2004  aj at azure.humbug.org.au
>   * create foo.c
> Wed Nov 24 16:20:39 EST 2004  aj at azure.humbug.org.au
>   * edit foo.c
> Wed Nov 24 16:20:24 EST 2004  aj at azure.humbug.org.au
>   * edit foo.c
> would certainly seem confusing and weird. :(

Right, that's what I was imagining, and in this scenario it's definitely
confusing and weird.  It's starting to make me think that we really would
need to be careful implementing a "hiding" idea.  :(

> >Rollback creates and records an "inverse" patch for an earlier change.
> >There are various reasons why this is ugly.  The most noteable is that the
> >rollback patch, being precisely the inverse of the original patch, can't
> >have any attached comments.  There are also implementation issues that keep
> >you from rolling back a patch that has been tagged.
> >
> >Really the existing rollback is pretty much orthogonal to the "hiding"
> >concept, since the primary use for hiding that I envision is grouping
> >related patches together.  In this context, the mother patch would both
> >hide and depend on all its children.
> Doesn't hiding imply applying the inverse too though? If you make the 
> inversing implicit (ie, hiding a patch implies applying its inverse), 
> then you could have "rollback" create a new patch, with a description, 
> that hides the patch it's rolling back, and doesn't do anything else 
> (ie, has no actual body). That seems like it'd work sensibly...

See above (that I didn't want hiding to imply inverse), so rollback would
need to actually include the inverse patch.  An implied inverse would be
very bad for the ease of writing the commutation routines for "hiding"

> >>Hrm, what happens if you hide a patch, then want to unhide it?
> >I don't imagine this would be possible, but hopefully wouldn't be necesary,
> >since you should always be able to turn on your X-ray vision and see all
> >the hidden patches.
> I'd think it'd be a safe bet that for anything you let people do,
> there'll be someone who'll decide they want to undo it. Still, there's
> always unrecord...

True, but sometimes there are things that they can't undo (and they have to
live with that).  But yeah, it does seem like a "show" patch might be
helpful... although it's terribly ugly.  :( And as you say, there's always

> Hrm, the possibility of having a patch called "add secret security 
> flaws" be hidden, but still applied doesn't seem particularly nice. :-/

Indeed, the whole concept of hiding patches is a bit fishy, since you
*have* to be able to find out what *really* happened.  Of course, since
we'd need an --x-ray-vision feature anyways to see the hidden patches, the
"secret security flaws" wouldn't remain secret very long, one would hope.

Another concern is how repository browsing (e.g. annotate and darcs.cgi)
would work in the presense of hidden patches.  It sounds like a bit of a
nightmare.  Perhaps what we really want is something more like a "group
patches" feature that actually, physically, groups multiple patches into a
single patch (while maintaining their separate identities within that
patch).  This would be pretty in some ways, but would require some
interesting aerobics to deal with inventories and suchlike.

> Would it be plausible/interesting/insane/whatever to make this be an
> actual patch, rather than a dependency?

It would indeed solve some user-interface issues.  In particular, it would
avoid the trouble of adding an interface to record/etc to specify hiding
patches.  If I had done this with dependencies, I think things would have
been better, except that then "tag" patches would perhaps need to be dealt
with differently.

Making hide a primitive patch type would obviously mean that unhide would
be allowed.

I think the real question is whether we can come up with a consistent
definition of a "hidden" patch, which will allow change, annotate,
darcs.cgi (via annotate), etc to all give a consistent picture of the
change history, in a way that won't confuse anyone.  Well, not confusing
*anyone* is perhaps too much to ask, but at least we should try to keep the
confusion to a minimum.
David Roundy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20041125/747821f3/attachment.pgp 

More information about the darcs-users mailing list