[darcs-devel] splitting and merging patches

[David Leuschner]

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