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

Anthony Towns 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
> this.

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[23]'
     # hackhack
     darcs amend-record -p 'A1'
     darcs unrollback -p 'A[23]'
     # hack 4...

The way I imagine that scenario is having my revision history look like:

After hacking/record A3:
      A1, A2, A3
                ^ repository

After rollback:
      A1, A2, A3
         ^ repository

After hacking/amend-record:
      A1.1, A2, A3
           ^ repository

After unrollback:
      A1.1, A2, A3
                  ^ repository

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)

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/20041123/9d5011da/attachment.pgp 


More information about the darcs-users mailing list