[darcs-users] Coalescing patches

Florent Becker florent.becker at ens-lyon.org
Fri Sep 25 13:07:05 UTC 2009


Nik Trevallyn-Jones wrote:

> Hi Florent,
> 
> Thanks for your input.
> 
> Florent Becker wrote:
>> Nik <darcs <at> babel.homelinux.net> writes:
>>
>>   
>> I'm not too fan of that idea, since it means making darcs' patch theory
>> more complex, while we all praise its simplicity.
> 
> That's disappointing. I was fairly confident that the idea wouldn't add
> much (or inded any) to darcs' patch theory. I thought that it was just a
> management operation (hold a number of patches as a single entity in the
> repo) rather than a patch theoretic operation.
> 
> Is it possible for you to outline briefly why this operation would
> impact the patch theory? Or failing that, point me towards some more
> in-depth documentation that would explain it. From what I've read on the
> website, I couldn't see any impact on the patch theory, I'm sorry.
> 
> Are you saying that to implement such a new type of patch would make the
> patch theory more complex?
> 
Yes, what I'm afraid of is that we would get some new objects into the patch 
theory, which means adding a new layer onto it. Right now, darcs' strengths 
come from the fact that it really manipulates only one kind of objects, 
patches (two if you count repos). That's why I'd like to see if we can 
implement the same user-visible behaviour by having current-darcs patches 
plus some UI magic. The "idea I'm not too fan of" is not enabling the 
workflow you are talking about, but blessing it into darcs' internals if we 
can avoid it.

>>  What you can do is name all your
>> small-scale patches with some keyword such as [minute] or [draft]. Then
>> whenever you want to work at coarse scale, you use --match "not name
>> [minute]" together with --dont-prompt-for-deps (ie, you put that in the
>> _darcs/preferences of the coarse repo). This has the result of letting
>> you select the "real" patches, while hiding the detail patches.
>>   
> 
> I will test doing it this way.

Please tell me how it goes, i have never tried using --dont-prompt-for-deps 
that way (at least in a systematic way).

>> With the current implementation, there is the slight drawback that you
>> cannot see the detail of the small patches (hitting 'v' in patch
>> selection shows nothing). All you need to make that drawback go away is
>> to add a "show this patch dependencies" action in patch selection.
>>
>> I think that this allows to have your coalesced patches with only UI
>> logic and no changes in darcs' core.
>>   
> 
> When you say "with only UI logic", are you referring to changes to the
> "push" and "pull" commands that would automatically perform the tasks
> required to coalesce?
> 
> So if I'm understanding you correctly, you are suggesting modifying the
> pull and push commands to recognise the coalesce (or unify or whatever)
> option that:
> 
> * adds a keyword such as "fine" to the names of the fine-grained patches
> being coalesced;
> * ensures that the receiving repo has the "not match [fine]" in the
> preferences;
> * adds an additional patch to the course repo that depends on all the
> fine patches that have just been pushed;
> 
> So now if a user views the coarse repo, then patches with the "fine"
> keyword are hidden; and the coalescing patches are visible and have
> useful names that the user can pull.
> 
> I must admit this is the structure within the repo that I originally
> considered. I thought people wouldn't like it, so I suggested the new
> patch type because it was a conceptually cleaner solution.
> 
I'd like to dig in that direction. I think there's a way to do that in a 
reasonnably clean manner using metadata on the patches. My conceptual 
cleanliness would be that what's at the metadata level, stays at the 
metadata level.

> Q: I presume that because the coalescing patch depends on the
> fine-grained patches, darcs will stop or at least try to stop users from
> accidentally obliterating one of the fine-grained patches that the
> coalescing patch depends on?

That's the tricky question. You can have two semantics.
Suppose at the fine level, you have patches A B and C. At the coarse level, 
you have AB = [A B] and AC = [A C]. You unpull --coarse AB. Should darcs:

-Fail to commute A and C and tell "you cannot unpull AB because of fine-
level dependencies". 

-Unpull AC and A. This is what you get if you use unpull --no-deps -a --
patch "my branch". So, if you want that semantic, all you need is a bunch of 
aliases/defaults for giving the right options to pull/unpull, and add the 
right metadata at record time.

> 
> Q: Is there some way to avoid overlaps between user-selected names and
> the "fine" keyword?
> 
Not yet. On the other hand, some other proposed features (for instance my 
dependencies from tests idea) depend on some way to tag patches with various 
meta-data. Once such a move is made, avoiding overlap is trivial.

> Q: Would all of this be easier if darcs made spontaneous branches more
> corporeal - ie, the information about a spontaneous branch were stored
> somewhere other than in the patch name?
> 

If we had such tag, you could add a 'branch' tag, and have it be somehow 
controlled by darcs (for instance, nag you before you add a new branch, so 
that you don't do it by mistyping an existing branch name).

With these clean meta-datas, I think your idea can be implemented in a 
conceptually clean way: when working at coarse level, positive commands (all 
the ones that end up doing apply) add --dont-prompt-for-dependencies for 
patches with the fine tag. Negative commands (the ones that end up 
unrecording) add --no-deps for the same patches. Seems reasonably orthogonal 
to me. (amend-record is disabled at the coarse level: it is at the 
intersection of positive and negative commands).

Thanks for coming up with that idea.

Florent



More information about the darcs-users mailing list