[darcs-devel] splitting and merging patches

Fri Mar 15 20:12:36 UTC 2013

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