[darcs-devel] splitting and merging patches

Ganesh Sittampalam ganesh at earth.li
Tue Mar 19 22:20:55 UTC 2013


Hi David,

The idea of history rewriting patches is something we've vaguely thought
about for a while. We were unsure about whether having "patches for
patches" was overkill and wouldn't get out of hand.

We recently became aware of a similar feature being developed in
Mercurial (http://mercurial.selenic.com/wiki/ChangesetEvolution) which
seemed quite convincing.

I think there's some more design to go through, but at least for me I
think it's something we should definitely do.

Cheers,

Ganesh


On 15/03/2013 20:12, David Leuschner wrote:
> Hello to all,
> 
> I've got some more unstructured, naive ideas.  Those ideas might be
> just rants, but the problems and use-cases I'm thinking abour are real
> and  those problems are reasons why tools other than Darcs sometimes
> work better in teams: because their model is easier.  We know how to
> avoid or cope with all situations I'm describing but still they arise
> especially with new team members that don't have many years of
> experience with the Darcs model.
> 
> We keep all of our ideas in our "private" public Darcs Trello because
> I neither want to spam this mailinglist or the tracker or official
> Darcs Trello nor can I spend much time working on and discussing all
> those ideas.  So it's more or less just a documentation of those
> points where Darcs is getting in the way of productive development for
> us at factis research.  It's also just the few negative parts: 95% of
> our Darcs experience is great.
> 
> I'm writing to this thread because I've just commented on an issue
> that is more or less similar to "splitting and merging" or "patch
> groups" or "tags":
> 
> https://trello.com/card/history-rewriting-patches/51098501825caeb428000288/13
> 
> Cheers,
> 
>    David
> 
> On Thu, Mar 14, 2013 at 8:42 AM, David Leuschner
> <david.leuschner at gmail.com> wrote:
>> Hello,
>>
>> I think this might have something to do with the splitting/merging
>> idea.  I think there's more to it and there might be a general concept
>> missing in Darcs that makes it hard for us to manage patches when
>> preparing releases.
>>
>> Recently I learned that many people using Git create short-lived
>> branches to work on a single feature committing several changes in
>> that branch.  When the feature is ready the branch is merged to the
>> main line.   With Darcs we don't need a branch for that.  We can have
>> Patch A0, A1, A2 and A3 where A0 is the initial feature implementation
>> and A1 depends on A0 and fixes some stuff and A2 depends on A1, and so
>> on.  In the same branch/repository we can have B0 to B3 and I can work
>> on feature A or B and if I'm unsure im B breaks anything I can still
>> remove all B patches and keep all my A patches or the other way
>> around.  That's great!
>>
>> We have about 200 patches a month with about 2-10 patches per feature
>> and a lot of small patches (added script, improved test output, ...)
>> nobody cares about when preparing releases. The patches for one
>> feature typically depend on the previous patch and improve that
>> feature.  When I'm not working on the feature I don't really care how
>> the "feature patch history" looks like and who changed what.  I just
>> want the feature in my working/testing/release branch or I want to get
>> rid of it - because it breaks something or I want to check if there's
>> a bad interaction between two features.  This would be really easy
>> with Darcs if I could treat all those 10 feature patches as one patch.
>>  What also happens to me is that I have 8 out of 10 patches for the
>> feature and don't realize that I'm missing some fixes and then I'm
>> reporting bugs that have already been fixed just because I didn't
>> realize that some patches I don't have in my testing repository belong
>> to the feature.  Naming conventions can help, but some kind of
>> "grouping" or "ungrouping" of patches would help even more.
>> Especially if pulling the first feature patch A0 and not pulling A1
>> would lead to a informational message such as "Note, there's a patch
>> group "feature foo" that contains the patch A0 you are pulling but
>> also A1,A2,A3 which you don't have."
>>
>> There's another Darcs concept that is not working for us and could be
>> used to implement patch groups: Tags.  We don't use tags at all.  We
>> clone repositories and use push/pull to see which patches are missing
>> or which additional patches we have in our working directories
>> compared to a released version.  One problem with tags is that they
>> get in the way.  I want tags but I don't want them to behave like
>> patches.  I'd like to know, that a tag exists even if I don't have all
>> patches from the tag. I'd then like to pull all patches I need for a
>> specific tag or I'd like to unpull all patches that a specific tag
>> doesn't depend on.  I'd like use tags to switch to a different branch
>> in the same repository.  It's not a solution to create a new
>> repository for the branch because it might take 15 minutes to build
>> the program from scratch so I want to do all that in the same
>> directory where I already have many build products.
>>
>> If tags would some 'tag patches' I could use them to refer to a state
>> of my repository or to a group of related patches.  It would be great
>> if these groups could be changed in a way that I get notified if I'm
>> testing feature A and I've got A0-A2 and somebody adds A3 and adds A3
>> to the group 'A' and I don't have A3 (but I told Darcs I want to have
>> group A in my repository).
>>
>> That's just some very raw ideas.  Maybe they're useful!
>>
>> Cheers,
>>
>>    David
>>
>>
>>
>> On Wed, Mar 13, 2013 at 11:33 PM, Ben Franksen <ben.franksen at online.de> wrote:
>>> Ganesh Sittampalam wrote:
>>>> On 11/03/2013 22:09, Sebastian Fischer wrote:
>>>>> factis research would like to be able to split and merge patches that
>>>>> other patches depend on. To explain why is a bit complicated so I have
>>>>> put a motivating dialog online: https://gist.github.com/sebfisch/5136973
>>>>>
>>>>> Would you be willing to include split and/or merge commands into Darcs
>>>>> if I implement them? Are there better ways to achieve the desired
>>>>> effect? Can rebase be used for this?
>>>>
>>>> I've only got a bit of time tonight, but will try to respond in more
>>>> detail in the next couple of days.
>>>
>>> I am looking forward to that!
>>>
>>>> The short answer (from my point of view) is we should either have these
>>>> commands, or have a nice easy way to do this with other commands; and
>>>> yes I think rebase can be used for this, or at least it would be the
>>>> foundation for doing this.
>>>
>>> I agree; "split" largely overlaps with what I proposed recently under the
>>> name "dissolving a patch".
>>>
>>>> As a another starting point, are you already aware of amend-unrecord?
>>>
>>> I was not aware of amend-unrecord; nice addition. If I do 'darcs help amend-
>>> unrecord' I get a detailed explanation of the alias, but it's not in the
>>> manual (the manual does mention the --unrecord option to amend-record).
>>>
>>> Cheers
>>> Ben
>>> --
>>> Ben Franksen
>>> ()  ascii ribbon campaign - against html e-mail
>>> /\  www.asciiribbon.org   - against proprietary attachments
>>>
>>> _______________________________________________
>>> darcs-devel mailing list
>>> darcs-devel at darcs.net
>>> http://lists.osuosl.org/mailman/listinfo/darcs-devel
> _______________________________________________
> darcs-devel mailing list
> darcs-devel at darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel
> 



More information about the darcs-devel mailing list