[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Developer branches

From: Mark
Subject: Re: Developer branches
Date: Wed, 6 Feb 2002 06:20:16 -0800 (PST)

--- Pierre Asselin <address@hidden> wrote:
> "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

 I prefer this process:

1- cvs update (whole workarea, even files they didn't change)
2- (if any conflicts from the last update, resolve and return to step 1)
3- ant/make
4- (if any compile issues, resolve and return to step 1)
5- (if changed files in this process, do the oldfashion outdated step of unit
testing prior to commt, then return to step 1)
6- cvs commit (whole workarea)

sure it may take a bit longer that just commiting your particular changed file,
but each of those steps will need to be done at some point, and the complexity
of each delayed step snowballs as individual developers determine they only
need to do the commit step on the files they changed. Its better if everyone
follows the process. (its better even still if a design phase actually happens
and everyone one is working off the same blue print, but that is likely
out-of-scope of this discussion)

They above process is alot easier than creating branches. branches are for
parallel development (ie. conflicting software requirements/functionality) not
for resolving/preventing compile issues or isolating developers work so their
changes won't impact others changes, as doing so merely delays and componds
what you created the branches to avoid. (What happens after 2 months of
everyone changing their owned branched copy of


Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]