Re: [tlug] Open-source repository question

["Stephen J. Turnbull" <turnbull@example.com>]

Combining two subthreads.

Curt Sampson writes:
 > On 2009-07-23 12:32 +0900 (Thu), Jon Povey wrote:

 > > This sounds like you are making a good argument for why branches are 
 > > useful. You create a branch in the VCS for this, other people check it 
 > > out and you work on it together for a while; if you don't like it, you 
 > > go back go trunk. If you do like it, you merge it back in. You can 
 > > involve other people without great pain.
 > 
 > Except for the fact that they're currently working in the trunk and so,
 > to work with this, they need to stop, commit, switch to the branch, and
 > work there instead. But if everybody does this, what was the point of the
 > branch, anyway, except to make more work when it comes time to merge back
 > into the trunk?

Some projects are more or less democratic (or should I say
"inertial"?), and as I saw in somebody's .sig "most people's code
should be reindented ... say, 6 feet downward"[1].  For one or both of
those reasons, in many projects most variations will not get merged on
the first iteration.  Still (as my professor of Economic History wrote
on my term paper), often "the germ of an interesting idea" is there,
and it makes sense to save them in a form that can be easily rebased.

 > (Or, if you frequently want to throw away reasonably large amounts
 > of work, you may want to re-think how you develop software.)

Have you discussed this idea with Fred Brooks? ;-)

Seriously, that's assuming you have the power to make that choice,
other than by throwing away your whole participation in the project.


Footnotes: 
[1]  Do I repeat myself?  Very well, then, I repeat myself.  I am
senile, and contain few original thoughts.  Pace, Walt!


Curt Sampson writes:
 > On 2009-07-23 14:16 +0900 (Thu), Stephen J. Turnbull wrote:
 > 
 > > Sure, but "cheap branching is good" doesn't depend on "merging is
 > > (nearly) free".  It depends on "those who don't have history are
 > > doomed to repeat the bad parts and forget the good parts".
 > 
 > Well, I think that's true whether or not you have history. How often
 > does one really look at it?

I spend a fair amount of time looking at very recent history, and I
prefer it to come in coherent chunks (ie, don't mix a bunch of
spelling fixes with improved markup for docs with a feature in the C
code with a bugfix in the Lisp).  The commits don't have to be in
parallel, they can be sequential, ie one branch -- but most people
seem to schedule like a perverse hyperthreading CPU.

I also do some time bisecting.  This is more effective if the commit
granularity is fine.

Finally, I do look at old history occasionally when analyzing defects
or new features.

 > >  > Well, yeah. I call that a "checkout." :-) 
 > > 
 > > Why not record it?  With really cheap branching, it can be done in the
 > > background without you noticing it unless you want to.
 > 
 > I would generally prefer not to record every little change because that
 > a) gives me more commits to look through should I decide to go back and
 > look at something, and b) may give me revisions that don't build and
 > test cleanly.

(a) can be handled by filtering on merge commits (assuming a
reasonable workflow, but it's not that hard to do with the
branch/merge support all the dVCSes provide).  (b) is actually very
tractable with cheap branching.  You have a vampires-only branch (or
maybe it should be called "commit-only" :-) which triggers a buildbot.
When the buildbot says OK (which may involve a number of builds), you
pull the commits that have passed.  More commits may have occurred
concurrently.  (We actually do this on the cheap, we just let the
vampires branch sit for a couple days, figuring that if there's a
build problem somebody will kvetch.)

 > > Sure.  So?  Cheap branches make [involving others] easy to do.
 > 
 > Actually, putting it on a branch makes it more difficult, because then
 > you have to get other people to switch to the branch, rather than just
 > getting the changes in what they're working on at the moment.

Maybe.  I don't test patches, unless somebody says "pretty please" or
I'm *really* interested in the patch.  I do test branches, because
it's so easy to do.  I've also participated in, or been on the
periphery, of highly decentralized development communities (Arch,
SXEmacs) where people really do communicate via branches.  I found
Edward's link to github's git-graph thingie less than convincing,
myself, but you can probably find some projects there with very active
"interbreeding".  And Launchpad is pushing hard in the direction of
communication by branch (which is now the recommended platform and
workflow for the Mailman project, although it only has one really
active developer at the moment :-).

 > >  > And the cost of going back, not by a VCS revert command but by
 > >  > painfully undoing what you've done, is just part of the risk.
 > > 
 > > What's wrong with going back via VCS revert?  (As long as that doesn't
 > > mean deleting history, of course.)
 > 
 > If you introduce changes into the mainline and decide you don't like
 > them later, you can't just revert to a previous revision,

Actually, looms, queues, and stacks make this possible, although it's
not that hard to just re-rebase the relevant branches if you're just
pretty religious about feature branching.  Pit-spitting (reverse
cherrypicking) is sometimes the method of choice here.

 > > Again, "forcing" is something that management should do, not the VCS.
 > 
 > I agree with that. I'm not trying to say that cheap branching is
 > unnecessary for everyone, here, just that there are ways of software
 > development where it's not particularly necessary.

Sure, as long as you acknowledge that those ways aren't available to
everybody.  Your first post you said "don't say it can't be done
because I've done it," which is perhaps more contentious than you
really meant it.