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

[Aaron Bentley]

On Thu, 2004-01-15 at 11:24, Tom Lord wrote:

>     > 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.

Okay, I can certainly be tag the milestones more clearly, and mark
everything that belongs together.

> 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

[snip]

> 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).

Small steps that can stand alone.  That makes sense to me.  I believe
every revision should compile cleanly too, whether or not the program
works.

> 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.

Yes, and that's how I've tried to do it.  But what you're doing is
determining what the branches are after the fact.

It seems that microbranching has some important advantages.  With a
single merge, anyone can get all my error handling stuff, without
getting my "changes --link" stuff.

Just yesterday I said "One of the best ways to get people to do what you
want is to make it really easy".  I'm going to think about what would
make microbranching so easy that everyone would do it.  It might be
easier to work backwards-- some form of commit that takes a branch as
the argument, then commits the changes to both the current tree and the
specified branches.

> 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).

Agreed.  Small stand-alone changes are preferable.

Aaron
-- 
Aaron Bentley
Director of Technology
PanoMetrics, Inc.