[±¤°í] Á¾·®Á¦ ºÀÅõ Àý¾àÇü ¾ÐÃྲ·¹±âÅë ¼Ò°³
¢¹ ¿øÄ¡¾ÊÀº Á¤º¸¿´´Ù¸é Á¤ÁßÈ÷ »ç°ú µå¸®¸ç, ¼ö½Å °ÅºÎ¸¦ ÇØÁÖ½Ã¸é ´ÙÀ½ºÎÅÍ´Â ¸ÞÀÏÀÌ ¹ß¼ÛµÇÁö ¾ÊÀ» °ÍÀÔ´Ï´Ù.¢¹ ¸ÞÀÏŬ¶óÀ̾ðÆ®ÀÇ ÇÊÅÍ ±â´ÉÀ» ÀÌ¿ëÇÏ¿© [±¤°í] ¹®±¸¸¦ ÇÊÅ͸µÇÏ¸é ¸ðµç ±¤°í ¸ÞÀÏÀ» ÀÚµ¿À¸·Î Â÷´ÜÇÏ½Ç ¼ö ÀÖ½À´Ï´Ù. ¼ö½Å°ÅºÎ ___ 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: using head revision in branch after add on branch
[ On Saturday, February 2, 2002 at 09:14:40 (+0100), C. Wienberg wrote: ] > Subject: Re: using head revision in branch after add on branch > > You can only check them in into _one_ module. Of course -- that's about the only way you'll ever make any kind of change management system make sense! > If we have one module for common stuff and one with specialties, that go > into the same directory, we have a problem. Huh? Nope. Not a problem. The source modules are each checked out into their own working directories. Your build system combines them into the common target directory. -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[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: using head revision in branch after add on branch
Hi Greg, > It all depends on where you make the changes, now doesn't it. If you > make them in the working directory then you can just check them in. > ...you wouldn't need to use 'cvs export'... You can only check them in into _one_ module. If we have one module for common stuff and one with specialties, that go into the same directory, we have a problem. You could export from one module and check out from the other, but you could not check out from two repositories into one local directory of the sandbox - the CVS/repository-files would collide. Also, I found no way to get CVS into an override mode, so checking out from different modules would result in "...is in the way"-errors. Generally, this may sound like bad directory design, so here's some backgroud info: We are building our project on top of a product, the CoreMedia CMS. Our main branch contains the stuff from the product and general adaptions, every branch specific settings for our 4 subprojects. E.g. there may be directories containing property files that have been adapted identically for all projects (head), as well as properties that are diffrent for each project (branch). It's quite comfortable to check out, you can run everything in your sandbox, works excellent besides my problem mentioned. Obviously, we can not change the directory structure. Also, we're on the last 14 days of the project, and I will not redesign our setup now. I might do it differently, next project, though. So: Has Anyone any Idea, how to solve my original problem ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
