Re: [Gnu-arch-users] Re-linking to revlib implemented

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > Robert Collins wrote: [....]

    >> I note you are doing many different things in the one branch. This is
    >> bad, as it means I can't cleanly get deltas relating to <foo> from you.
    >> I can only get single changesets, and once conflicts start (due to style
    >> differences etc), it becomes harder and harder to merge it all cleanly.

    >> In other words, branch more.

    > So there might be an error-handling branch, a diff-speedups branch, a 
    > no-pristines branch, etc?  Do I keep my own integration branch and 
    > star-merge them into it? 

That's certainly an option.  The best reason to do things that way on
a project of this scale (i.e., fairly small) is if it helps you work
-- if you personally find it convenient.

I'm not _entirely_ of the same opinion as Robert: I think you can do
more than one thing in a single version and still be reasonable to
merge from.   I wouldn't just apply the blanket judgement "bad" to
multi-purpose development branches.

What I find that I really appreciate when people have multi-purpose
development branches is if they work in manageable increments, making
correctness preserving or enhancing changes, with clearly marked
milestones.

For example, let's suppose that you are going to work on better error
handling and also on a new --link-grandly option to several commands.
This would be good:

        patch-1         start on --link-grandly
        patch-2         more --link-grandly
        patch-3         fix --link-grandly bug
        --------------------------------------------------
        patch-5         better error handling in pfs-dav.c
        --------------------------------------------------
        patch-6         more --link-grandly
        patch-7         still more --link-grandly
        patch-8         star-merge from tom
        --------------------------------------------------
        patch-9         better error handling in archive.c
        patch-10        fix bug in last patch
        patch-11        better error handling in pfs-ftp.c
        --------------------------------------------------
        patch-12        --link-grandly finished

provided that at the points I've drawn the lines your code compiles
cleanly, passes tests, and would be reasonable to release.  For
example, I wouldn't care if the version was badly broken in patch-1
and patch-2 -- I would care that that was fixed in patch-3 before
"changing topics" from --link-grandly to error handling.   I'd also
care that patch-5, for example, even though it's not the entire error
handling work, is useful in and of itself (rather than just a
half-completed step that leaves the code in an odd state).

When I merge from something like that I tend to look at the log
summaries, group related patches just as shown by the dashed lines,
and star-merge (and commit) in exactly those increments.

The ideal way such a merge proceeds is that "----" points mark good
units of review in the sense that I can see (from the code) what they
try to do, whether they do it, and whether I can spot how it will
break anything.

Even if all of, say, the --link-grandly work were on one branch by
itself -- even so, it'd be nice to have it break up into reviewable
chunks that way (if it's a large enough change overall).

Maintaining a multi-topic version just takes a certain amount of
discipline, that's all.  For example, this would be an extreme example
of _not_ so good:



        patch-1         start on --link-grandly (not useful yet)
        --------------------------------------------------
        patch-2         do some error handling work (breaks replay)
        --------------------------------------------------
        patch-3         more --link-grandly
        patch-4         fix --link-grandly bug
        --------------------------------------------------
        patch-5         better error handling in pfs-dav.c
        --------------------------------------------------
        patch-7         start on the tla half-baked command
                        and --link-grandly progress
        --------------------------------------------------
        patch-8         better error handling in archive.c
        --------------------------------------------------
        patch-9         fix huge bug in patch-2
        --------------------------------------------------
        patch-10        make things compile again
        --------------------------------------------------
        patch-11        fix replay
        patch-12        revert the half-baked comand
        --------------------------------------------------
        patch-13        star-merge from tom


There's nothing I could do when merging a version like that other than 

        a) cherry-pick like crazy
     or b) take everything up to patch-13 all at once
           and hope for the best

neither of which is desirable.

(To be clear, there's a spectrum between the "very good" example and
the "_not_ so good" example.   Perfection isn't imperative -- just
keep in mind how it looks from a gatekeeper perspective.)

It's really _easy_ to wind up with a messy version like the "_not_ so
good" example if you aren't using separate branches for stuff.  If you
wind up in such a state, a helpful thing to do is to spare your
upstream gatekeeper the work of cherrypicking from you by doing that
work yourself.  You could make separate error-handling and
--link-grandly branches at this point and cherry-pick into them.  Or
if you are confident of it, you could make a new integration branch
and cherry-pick everything into that: but in a better order and
committing in sane increments.

If the project were a bit more complex then rigorous branching would
be more important.  We'd also, in that case, be more formal about
having a gatekeeper tree that could be doing integration testing of
the various development branches continuously.

-t