Re: Developer branches
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 changes, as doing so merely delays and componds what you > created the branches to avoid. I'll disagree with this, somewhat: in particular the "or isolating developers so that there changes won't impact other's changes". "Parallel development" is useful not only for conflicting functionality, but also changes that have broad but limited impact. That sounds like an oxymoron, but what I mean is a change that involves editing a lot of files, but in a way that doesn't necessarily conflict (on a textual basis[1]) with other concurrent development. It may result in the build being broken (either compiler time or run/test time) for a long while, and if you don't branch, you have two possibilities: 1. The developer doing the big change does commits. 2. The developer doesn't do commits. For case 1, everybody else is screwed. No good. For case 2, the developer is screwed, because she can't use CVS for her own work, and thus is left with foo.c.20020131, foo.c.good, foo.c.orig sitting around in her sandbox. Testing on other platforms is painful, because you have to copy stuff by hand (always forgetting parts of it, and wasting time re-inventing fixes), rather just going to the other box and doing a 'cvs update -r branch_tag'. I'm sure that others here can come up with more annoyances. Neither choice is satisfactory. Branching requires more work/responsibility on the part of the developers on the branch, and on the release manager (or whatever you call the person responsible for managing your repository). Therefore, one needs to decide whether the extra work is justified by the benefits of branching in each instance. The key point, I think, is that you can't, in general, avoid the effort of merging and resolving conflicts. What branches can give you is the ability to control when that effort has to be made. While mostly (I think) the best answer to "when?" is "now", sometimes it's better to delay it. Steve [1] If it conflicts semantically, then it wasn't designed correctly, but that kind of issue is independent of branching choices. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Developer branches
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 link above, go to the bottom of the page, and read the directions. -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Developer branches
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 branches
--- 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. 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
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Developer branches
--- 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. 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
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Developer branches
"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 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! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Developer branches
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 arguments are given, the present working directory is assumed.
The output is a list of 4-tuples: CVSROOT, path to RCS file relative to
CVSROOT, path to working file, RCS revision number. I tend to ignore the
CVSROOT field because for me it always points to the same repository.
The fields are tab-separated.
>--- Forwarded mail from [EMAIL PROTECTED]
>However, I can discuss the details of the relevant algorithms. Below is a
>script that creates a bill of materials for a checked out work area. It
>scans the CVS (1.3) state and writes a list of entries for each file under
>CVS control. Each entry is a single line with three fields, separated by
>tabs. The entries include a path (relative to $CVSROOT) to the RCS file,
>a path (relative to the root of the work area) to the working file, and
>the version number. The whole process revolves around lists like this.
>By the way, the RCS file paths should be unique; this is important if you
>wish to track changes made in the modules database.
>--- End of forwarded message from [EMAIL PROTECTED]
#!/bin/sh
sep="/"
cvsname="CVS"
entname="Entries"
repname="Repository"
rootname="Root"
vsuff=",v"
if [ $# = 0 ]
then
set -- .
fi
for x in "$@"
do
find "$x" -type d -a ! -name "$cvsname" -print
done |
while read dir
do
cvs="${dir}${sep}${cvsname}"
if [ -d "$cvs" ]
then
entfile="${cvs}${sep}${entname}"
repfile="${cvs}${sep}${repname}"
rootfile="${cvs}${sep}${rootname}"
root=`cat "$rootfile"`
rep=`cat "$repfile"`
awk '
BEGIN {
FS = "/"
OFS = " " # tab
}
$1 == "" { print root, rep sep $2 suf, dir sep $2, $3 }
' "dir=$dir" "root=$root" "rep=$rep" "sep=$sep" "suf=$vsuff" "$entfile"
fi
done
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Developer branches
>--- 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=5846&listName=info ). >However, that message also sugessts searching on "submit/assemble" which >seems to imply I did not find the one you intended. >[...] >What was the jist of the "hand-off" process you were mentioning in the above >archived message? >--- End of forwarded message from [EMAIL PROTECTED] There have actually been quite a number of discussions about it over the years. Here are a couple of messages that convey most of the substance. +++ Date: Fri, 1 Nov 96 21:07:39 PST From: [EMAIL PROTECTED] (Paul Sander) Message-Id: <[EMAIL PROTECTED]> >How do most CVS users control what goes into each official build? The >usual approach is that the developers somehow indicate which files they >want to go into the build, and then the build engineer uses that info to >check out the hierarchy, compile, and tag the revisions of all files >used in that build. The method I implemented at a previous employer used a baseline+delta mechanism to compute a bill of materials that drove the checkout. The build's predecessor's bill of material was used as a starting point. Developers provided a list of deltas (filenames plus revision numbers, or filenames plus deletion flags, which were collected automatically by a tool that I provided). The order of submissions of deltas was retained. The deltas then amended the bill of materials and the result was checked out. If the build broke, a delta was removed from the list, the bill of materials was recomputed, and the build was repeated. (There are several algorithms for selecting which delta(s) to remove in the event of a failure, so we were able to automate the process.) >It seems like this could be done with RCS states or symbolic names. Is >there a standard procedure or does everyone do it differently? Are >there some good models I could follow? >Also, if you use symbolic names and do weekly builds, do you end up with >extremely long log info? Do you occasionally clean these up? Tagging all of the sources can lead to long info eventually. In the method above, I put the bills of materials and delta lists under version control and tagged them at the end of the build. This simplified and sped up a number of things: - Compute the differences between builds and produce changelogs from the developers' commit comments. - Get documentation for new features that were stored as comments with the deltas. - Subsequent checkouts of previous releases sped up because the bill of materials could drive RCS directly, saving CVS' overhead. (This is safe under Unix due to the way that RCS manipulates its files and how the Unix filesystem works. It had no impact on the integrity of the repository even during concurrent commits.) - It was easy to identify all of the tags for any module without scanning the entire repository. - It provided an effective workaround for the module database non-versioning problem. +++ Date: Tue, 5 Nov 96 16:01:48 PST From: [EMAIL PROTECTED] (Paul Sander) Message-Id: <[EMAIL PROTECTED]> > Is the work you described below in the public domain ?. If so could you >point me to it ?. I'm afraid it's not. The tools contained a lot of proprietary stuff that had to do with internal security, integration with the local defect tracking system, etc. I doubt it would be that useful even if I could give it to you. However, I can discuss the details of the relevant algorithms. Below is a script that creates a bill of materials for a checked out work area. It scans the CVS (1.3) state and writes a list of entries for each file under CVS control. Each entry is a single line with three fields, separated by tabs. The entries include a path (relative to $CVSROOT) to the RCS file, a path (relative to the root of the work area) to the working file, and the version number. The whole process revolves around lists like this. By the way, the RCS file paths should be unique; this is important if you wish to track changes made in the modules database. The handoff process is a two-step procedure. The first step (called "submit") is done by the developers in which they generate a delta, which is little more than a bill of materials for a few files. The second step (called "gather") is done by the integrators in which the deltas are applied to the predecessor's bill of materials, or the order of their submission. The result is a comprehensive list of the desired sources for the new build. The basic algorithm for the submit step is to run a script like the one below in a work area. The output of the script is given a serial number, and stored in a secure area. Embellishments include allowing the developer to list specific files to include in the delta, to make recursive descents optional, verify that the source files are committe
Re: Developer branches
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 are a lot of such changes coming. On the other hand, divorcing the "eligible for build" concept from the HEAD is also a huge win, because then you begin to enable an environment that assures a 100% success rate for the nightly builds. The reason for this is because employing a better change control method provides better immunity from garbage commits that tend to happen at the last minute. --- Forwarded mail from [EMAIL PROTECTED] 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 changes is the method that seems to work best for me. Paul Sander wrote: >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 >the same branch and yet still have some recourse if someone commits garbage. > >Check the info-cvs archives for "submit/assemble" for discussion of one >successful method that doesn't rely on tags. > >--- Forwarded mail from [EMAIL PROTECTED] > >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 creating a single DEV branch or creating >seperate dev branches for each individual developer? What are people's >experiences with either approach? > >--- End of forwarded message from [EMAIL PROTECTED] --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Developer branches
Thanks for the reply. I performed the search you mentioned and found the following message http://ccvs.cvshome.org/servlets/ReadMsg?msgId=5846&listName=info ). However, that message also sugessts searching on "submit/assemble" which seems to imply I did not find the one you intended. Anyway, the message I did find was also posted by you and I totally agreed with what you were saying. Especially: is exactly what we are trying to accomplish. I was tagged as the build script writer (we are using Ant which is a great java-based alternative to make); 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. This is my first project using CVS (and actually the first for everyone on the team) and I was lucky enough to also be tagged as the CVS admin. So my experience here is extremely limited and the learning curve pretty steep. But after reading the docs, I had been leaning towards a single branch tagged as DEV on which all developers would perform their work. However, I have been starting to realize that branching is really just delaying the point at which these "inconsistencies" will be discovered, and then putting all the effort of correcting them on the release manager who is responsible for moving things from the branches to the trunck. 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. 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. What was the jist of the "hand-off" process you were mentioning in the above archived message? Maybe we just need to add an additional role of "second-level" tester to 2-3 people's plates and have them determine whether things are ready for build and tag/merge things appropriately. "Paul Sander" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]... > 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 > the same branch and yet still have some recourse if someone commits garbage. > > Check the info-cvs archives for "submit/assemble" for discussion of one > successful method that doesn't rely on tags. > > --- Forwarded mail from [EMAIL PROTECTED] > > 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 creating a single DEV branch or creating > seperate dev branches for each individual developer? What are people's > experiences with either approach? > > --- End of forwarded message from [EMAIL PROTECTED] > > ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Developer branches
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 changes is the method that seems to work best for me. Paul Sander wrote: >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 >the same branch and yet still have some recourse if someone commits garbage. > >Check the info-cvs archives for "submit/assemble" for discussion of one >successful method that doesn't rely on tags. > >--- Forwarded mail from [EMAIL PROTECTED] > >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 creating a single DEV branch or creating >seperate dev branches for each individual developer? What are people's >experiences with either approach? > >--- End of forwarded message from [EMAIL PROTECTED] > > >___ >Info-cvs mailing list >[EMAIL PROTECTED] >http://mail.gnu.org/mailman/listinfo/info-cvs > ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Developer branches
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 the same branch and yet still have some recourse if someone commits garbage. Check the info-cvs archives for "submit/assemble" for discussion of one successful method that doesn't rely on tags. --- Forwarded mail from [EMAIL PROTECTED] 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 creating a single DEV branch or creating seperate dev branches for each individual developer? What are people's experiences with either approach? --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Developer branches
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 creating a single DEV branch or creating seperate dev branches for each individual developer? What are people's experiences with either approach? Thanks for responses. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
