--- Pierre Asselin [EMAIL PROTECTED] wrote:
Steve Ebersole [EMAIL PROTECTED] 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.
Please please remove me from the distribution list.
Does any one know how to get off the distribution list. Thanks.
Van
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Mark
Sent: 06 February 2002 14:20
To: [EMAIL PROTECTED]
Subject: Re: Developer
Van Ung wrote:
Please please remove me from the distribution list.
Does any one know how to get off the distribution list. Thanks.
...
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Follow the
On Wed, Feb 06, 2002 at 06:20:16AM -0800, Mark wrote:
[Lot's of good stuff, up until:]
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
Steve Ebersole [EMAIL PROTECTED] 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
I've found that is you plan to make a 'disturbing' change, it's best to
do that in a branch - get it working and merge it in. The idea is that
the HEAD branch *must* always build (at least after a short period
(hours max) of instability). So multiple dev branches for big
collaborative
Thanks for the reply. I performed the search you mentioned and found the
following message
http://ccvs.cvshome.org/servlets/ReadMsg?msgId=5846listName=info ).
However, that message also sugessts searching on submit/assemble which
seems to imply I did not find the one you intended.
Anyway,
If someone is making huge, disruptive changes to the project, then it
certainly is best to spawn a branch and bite the bullet with a nasty merge.
Or, better yet, spawn a branch for continuing work and put the disruptive
change on HEAD; that way you can control the depth of your branches if
there
--- Forwarded mail from [EMAIL PROTECTED]
Thanks for the reply. I performed the search you mentioned and found the
following message
http://ccvs.cvshome.org/servlets/ReadMsg?msgId=5846listName=info ).
However, that message also sugessts searching on submit/assemble which
seems to imply I did
Oops, my previous post referred to a script that collects a bill of
material, which was omitted. Here's one that I quickly threw together,
updated for CVS v1.10 and later. Its command line lists directories in
which bills of materials are gathered, with recursive descent. If no
command line
We are using CVS to store Java source code. Currently, all developers in
the project are directly commiting against HEAD. We would like (as much as
possible) to keep HEAD in a stable state and so would like to start using
branches to create a dev environment.
Is this better approached by
Another approach that doesn't require developers to perform as many merges
is to implement a hand-off procedure that declares certain versions as
eligible for the build. This can be as simple as applying tags, or it could
be more complicated. That way, the developers and the builders can share
12 matches
Mail list logo
