[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: CVS branching -> Git branching model

On Fri, 10 Feb 2012 05:18:58 -0800, Kurt Zeilenga <kurt@OpenLDAP.org> wrote: 
On Feb 1, 2012, at 9:26 AM, Hallvard B Furuseth wrote:


Oh well, sorry about the abandonware stuff.  Getting back to the
more prosaic subject,


First, whether to use a back-port or a forward-port model has nothing
to do with git(1) v. cvs(1).  Both revision control systems support
both models.


Yesno.  The difference is partly that Git supports consistent branches,
but more that it suppors sane merges. Which makes it more of a win than 
in CVS to arrange things so we can use merge or fast-forward instead of
cherry-picking.


(...)

I do think it'd be better to do more coding
in a branch off RE24 than off master - except stuff intended for
RE25 in the first place.


The back-port model is generally better in my opinion.  It
effectively eliminates the risk of regression that is high in any
forward port model.
If you say so, but why port to/from master instead of a branch off RE24? 
Porting between more different code bases introduces more risk.  We
don't have an active RE25 to port back from or forward to.  Currently
master is just RE24 + some code which will someday in the future be used 
after cleaning it up and maybe still porting it (and other things) to
whatever RE25 will look like.


Your suggestion will lead to regressions and hence, IMO, bad.  It's
also messy, time consuming, and error prone from a release engineering 
stand-point.

It is important for the release engineer to control what goes into
release branches.  If you code off the release branch, then the
release engineer has to be involved early and frequently.


Er, I may have left out the RE24 branch itself:-( I tried to keep
excessive branches out of the suggestion, that got a bit too far.

I'd certainly prefer to code in a branch off RE24 and not in RE24
itself.  An in any case to revert stuff which gets into that branch but
can not be released (yet).  Or at least wrap that in #ifdef LDAP_DEVEL.

Then the release engineer can hopefully just fast-forward or merge into
RE24, but he doesn't have to.  And we'd hopefully learn discipline
enough to not just throw half-finished stuff into it.  That's for the
current master branch.

I don't see what's messy about that.  It'd be messy if people put code
there just "get more eyes on it" as in master today, then this branch
would turn into just what master has been at times:  A branch with a
bunch of as-yet unreleased code which someone someday might finish.
And having two different branches like that would indeed be messier.
As far as branching is concerned, my only recommendation is to avoid 'feature' > specific development branches in the main repo. Instead, personal (but shared) > repos can be used. If appropriate, we can even host these on openldap.org. 

IIRC there's always been a fair amount of code in master just sitting
there unfinished.  Commit messages like "this is a preliminary code
drop", and then maybe sometime later it gets finished.  If people will
be content to keep such things in separate repositories, fine.  That's
a lot easier with Git than with CVS.

But if the author wants to push it to the main repo to get more eyes on
testers for the code, which IIRC was one reason for keeping the current
arrangement, then I'd much rather see it in a feature branch.

(Also I assumed merging feature branches would also tend to be easier
than porting between branches, but I haven't tried that myself yet.)

In any case, two branches (maint and hotfix) off RE24 is the main
thing I'd like, feature branches seem less important.


(...) It might be nice to archive these (and the old non-release
CVS branches) once they are no longer in use, just to reduce the
noise.  Personally, I prefer not to archive old release branches
(as I find them useful long after they are closed).


Renaming to refs/archive/<heads,tags>/* reduces the noise but still
keeps them in the repo.  I think
git config --add remote.origin.fetch 'refs/archive/*:refs/archive/*' 
will get those symbols in addition to the rest.


But, in general, I advocate leaving well enough alone... especially
if it not helping our release engineers (or worse, will cause release
engineering pain).


Actually helping out with that was one thing I hoped this would do.

--
Hallvard