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

David Roundy droundy at abridgegame.org
Tue Nov 23 13:05:52 UTC 2004

On Tue, Nov 23, 2004 at 01:32:12PM +1000, Anthony Towns wrote:
> David Roundy wrote:
> >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".

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.

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

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.

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

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.

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.  This would introduce a new patch named A1,
but with a different date (or perhaps it would be named A1.1, if we let
amend-record get a new name).  In any case, I'll call the new patch A1.1.
So the scenario would now be

# 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
# hackhack
darcs amend-record --safe -p 'A1'

And the final repository would hold

A1, A2, A3, A1.1(hides A1)

And changes would list

A1.1 (most recent)

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.

> >(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?

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.

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

> 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... which is something you can't do with rollback, since the rollback
patch doesn't have a unique ID.
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/20041123/80806883/attachment.pgp 

More information about the darcs-users mailing list