RE: Developer branches

[Van Ung]

Please please remove me from the distribution list.

Does any one know how to get off the distribution list.  Thanks.

Van

-----Original Message-----
From: address@hidden [mailto:address@hidden Behalf Of
Mark
Sent: 06 February 2002 14:20
To: address@hidden
Subject: Re: Developer branches



--- 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 build.me
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 file.java)

Mark

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs