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

Anthony Towns aj at azure.humbug.org.au
Wed Nov 24 06:34:36 UTC 2004

David Roundy wrote:
> On Tue, Nov 23, 2004 at 01:32:12PM +1000, Anthony Towns wrote:
>>The one thing I'll mention though (given I don't think I mentioned it in 
>>the first place...) is that the nice part about the "syncing" model is 
>>that you no longer need to keep any mention of "patch A5" around after 
>>it's been superseded by "patch A5.1".
> Yes, but the cost is that you can lose data when syncing, which makes it
> inherently dangerous, and if it is also confusing, that's very bad, and my
> suspicion is that it *would* be confusing.

Ah, that's a good point. If stuff's going to happen automatically, a
much better result would be converting "A1, A2" to "[A1], A2, A1.1'"
anyway (where [x] denotes "hidden/not applied, but still available") --
that way it's clear what the changes to your repository actually are. So
colour me convinced.

>>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)

> Of course it would be essential that you be allowed to somehow see the
> hidden patch, perhaps with a command line flag.  It's also (as I mentioned)
> not entirely clear when exactly the patch would be hidden, and when it
> would show up.  For example, if you run
> darcs changes --to-tag foo
> and there was a change in tag foo that later got hidden, presumably that
> change would be displayed.  Similarly, on pull and push it's not clear
> when hidden changes should be prompted for.

The only difference would be what happens if you do:

	darcs init
	darcs pull
	darcs unpull -p Y
	# is X present now or not?

I think you could reasonably argue either behaviour is obvious and
correct, given the whole idea is that X was essentially unrecorded out
of existance anyway.

>>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.

>>    # hackhack
>>    darcs amend-record -p 'A1'
>>    darcs unrollback -p 'A[23]'
>>    # hack 4...

> Argh, I don't think I like this usage scenario.  I'd rather put emphasis on
> "safe" commands, and by definition, safe commands leave history behind.

> First, either you're misunderstanding rollback, or imagining "fixing" it in
> a way that is different from what I'm imagining.

I don't see why I can't be doing both...

> 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. :(

> So the order looks messed up (since A1.1 happens after A2 and A3), but
> you've accomplished roughly the same goal, without erasing any history.  If
> you want to erase history (i.e. be unsafe), you could get by with the
> existing unrecord, although you might need to unrecord both A2 and A3 to
> "get at" A1.

Right, so I guess what I'm asking for is an unsafe pull; but that's
probably not something I actually want...

> 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...

>>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...

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

>>Or unrecord it then record it again later?
> Are you referring to my "unrecord --safe" idea, which would be sort of a
> better rollback? In this case you could just "unrecord --safe" the unrecord
> patch... 

It sounds like you could then have:

      darcs record (creates A1)
      darcs amend-record --safe (creates A1.1, which hides A1)
      darcs unrecord --safe (creates A5, which hides A1.1,
                             making A1 visible again)

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

[edit foo
aj at azure.humbug.org.au**20041123101234]  < > {
hunk ./foo 12
+hello wold
[edit foo (corrected spelling - 2004/11/23 12:34:48)
aj at azure.humbug.org.au**20041123123448]  < > {
* [edit foo
* aj at azure.humbug.org.au**20041123101234]
hunk ./foo 12
+hello, world!

In which case you have "darcs unrecord" which deletes a patch, and
"darcs hide" which inverts a patch in the working directory, and adds
the appropriate info to patches/pending. So, scenarios might be:

   edit; darcs unrecord; darcs record
   edit; darcs hide; darcs record
   darcs hide; darcs record

Hrm. You could do "safe rollbacks" then by saying:

   darcs hide -p A3; darcs hide -p A2
   # hack as though A2 and A3 were never applied
   darcs revert
   # revert the hiding of A2 and A3
   darcs record

I think I think that'd be useful, but I'm not sure. :)

Sorry if I'm going completely off track :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 155 bytes
Desc: OpenPGP digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20041124/d47137de/attachment.pgp 

More information about the darcs-users mailing list