Branch topology [was Re: Post 0.6.0 releases.]

[John Darrington]

     Here is the branching model that I was envisioning maintaining at
     Savannah:
     
             - A bug fix branch for whatever is the current released
               version.
     
             - An active development branch that contains whatever is
               targeted to appear in the next released version of
               PSPP.
     
             - Additional experimental branches as necessary for
               public and possibly collaborative long-term development
               of big features that aren't ready for the active
               development branch yet, one per feature.  For example,
               I'm assuming that the new output subsystem will be
               developed this way.  Eventually these branches get
               merged back into the active development branch, if the
               experiment is successful, and then discarded (although
               the Git history shows that the branch was merged and
               retains the branch history; that is, no information is
               lost).
     
     Maybe my vision for as-needed experimental branches is really the
     same as your proposed branch #3?

It sounds similar, if not identical.  What you don't make explicit, is
the relationships between the branches.  As I see it, each of your
branches listed above, must be the parent of the subsequent item, but
I'm not sure if that's what you had in mind.

     In addition, I'll probably have half a dozen or so branches in
     various stages of development going locally on my development
     machine at any given time.  Over at Nicira, I've probably had as
     many as a dozen.  Git makes it trivial to create, merge, and
     discard branches, so it's my habit to use one per feature that
     I'm working on.  It appears that many Git users work this way.

I don't know if this concept fits the git paradigm, but I think of
branches as nothing more than "big" change sets.  If a developer
thinks it's useful to create his change set in separate activities,
then it's logical for him to branch it.  However, I'd like that all
such branches are at least visible to other developers, even if
they're not ready for general consumption.  That way, it avoids
duplication of work, avoids (at least some) later merge conflicts and
keeps developers pulling in the same direction.

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

signature.asc
Description: Digital signature