[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] < > {
hide-patch
* [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:
amend-record:
edit; darcs unrecord; darcs record
safe-amend-record:
edit; darcs hide; darcs record
safe-unpull/rollback:
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 :)
Cheers,
aj
-------------- 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