[darcs-users] Different approach for "incoherent" patches
aj at azure.humbug.org.au
Tue Nov 23 03:32:12 UTC 2004
David Roundy wrote:
>>Rather than trying to make patch A5.1 "supersede" patch A5, a different
>>approach might be to make A's and B's repositories "sync".
> I find this approach a bit scary, but your analysis of the usage scenario
> seems useful, and gives me a different idea as to how one might deal with
Cool, that was pretty much the hoped for outcome :)
> Perhaps all we need here is a "subsumes" attribute (which needs a better
> name), which would allow one patch to "hide" another.
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".
> This has been
> discussed before, in the context of patch grouping, and definitely strikes
> me as a good idea. If we allowed one patch to hide another (or more than
> one other) patch from darcs changes, pull, etc, then we wouldn't need to
> remove the old patch at all.
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?
> The addition of a "subsumes" attribute might also (in combination with
> amend-record) allow us to either clean up or remove the "rollback" command,
> which is one of the more confusing commands. A nicer version of "rollback"
> could be used as a --safe unrecord. For example, we could perhaps make the
> rollback patch hide not only the rolled-back patch, but also itself, which
> might be a bit *too* subtle, but would have the advantage of behaving like
> a "safe" unrecord that could be pulled. Of course, it couldn'tq hide itself
> *too* well, or you wouldn't be able to pull it... :)
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'
darcs amend-record -p 'A1'
darcs unrollback -p 'A'
# hack 4...
The way I imagine that scenario is having my revision history look like:
After hacking/record A3:
A1, A2, A3
A1, A2, A3
A1.1, A2, A3
A1.1, A2, A3
Hrm. Which I guess means that I'd (personally, ideally) rather a "darcs
get" from this repository invoked before the unrollback to get all three
patches. Obviously that's different behaviour to what would happen if
you used "unrecord".
You could have a _darcs/rollback_inventory that contained (A3^-1,
A2^-1), I guess, and have that work. (That's kinda more for the
"multiple unrevert" case than the "safe pull/amend-|unrecord" case though)
> (Obviously the "hiding" would require some thought in its definition.)
So, how is "hiding" different to what rollback already does? Could you
get away with just making rolledback patches not get displayed in "darcs
changes", or get listed in a separate "rolled back:" section, or need
some --display-rolledback-patches option?
Hrm, what happens if you hide a patch, then want to unhide it? Or
unrecord it then record it again later?
(Oh, whooops, I didn't realise rerecord's name had already changed)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 155 bytes
Desc: OpenPGP digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20041123/9d5011da/attachment.pgp
More information about the darcs-users