Re: Developer branches

[Pierre Asselin]

"Steve Ebersole" <address@hidden> writes:

>we have,
>as of yet, been unable to perform a successful build precisely because
>everyone is checking in code which does not compile with work of other
>developers.

They must be committing single files.  Tell them to commit wholesale
("cvs commit" from the top-level directory, no other arguments).
They will get a complaint from cvs that their sources aren't up to
date and that they should please run "cvs update" first.  Once they do
*that*, they have all the changes made by the others and they can
attempt a make --er, Ant-- to see if that builds.  If not, fix it and
commit only when it works.

So the sequence goes like this:

    cvs commit  --darn, out of date
    cvs update
    Ant         --darn, won't build
    (fix conflicts)
    Ant         --success
    cvs commit

On a hyperactive repository you might find yourself unable to keep
up:  somebody always commits another change while you're fixing
the mess after the update, so by the time your build completes
you're still out of date and have to update again, then fix, etc.

Frankly I doubt that a team of six can commit that often, but if
it happens you can start creating development branches.  One branch
per feature/subproject/whatever, not one branch per developer.
You want to keep *some* of that update-fixit madness, that's the
joy of concurrent development!  Seriously.  If you coordinate your
work just a little, the productivity boost is well worth the trouble.

If you do create development branches, you end up using the trunk for
integration.  You still have to make sure each branch builds cleanly
before attempting a merge, but you have a litle bit more flexibility:
you can put a branch on feature freeze without slowing the other
branches.  When a branch looks good (it had better build!) you can
merge it to the trunk and deal with conflicts (the integration work).


>...
>However, I don't think I really liked the idea of tags to perform this step
>because it is either adding responsibilities back on the developers to tag
>their code which is ready for build release (which the idea alone of them
>making that decision scares me) or back onto the release manager to
>determine what is eligible for release to build.

No, no.  When you tag from a sandbox, the tag is applied to the
versions *as of your last commit*.  If you've made changes without
committing them, the tag misses them --it has to, the changes aren't
in the repository.  I go back to your statement,

>we have, as of yet, been unable to perform a successful build

That is an anomaly.  Committed code should build, mostly.  It can
crash at run-time, but it should build.  How do you know it will
build?  because you built it before committing  --automated test,
no reason to skip it.


>We are a team of 6 and the
>project is huge, so adding any substantial additional work to one person's
>plate could be detrimental.

One of you has to play release manager.  It can be any one of you,
maybe even on a rotating basis, and with collegial input from the
whole team.

Once you reach a milestone, the release manager tags it and starts
a QA branch.  The QA branch is reserved for bug fixes (including
build failures, in extreme cases).  No new features.  When the QA
branch looks really good, you tag it and you ship what you just
tagged.  You also merge the bug fixes from the branch to the trunk.

And don't tag or branch individual files, you'll get a mess.  Tag
the whole project.

--
Pierre Asselin
Westminster, Colorado


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----