Re: Suggestions for merging system?
On Wed, Dec 06, 2000 at 07:55:51AM -0600, Richard Cobbe wrote: > is going to cause a lot of conflicts. (We could avoid these by being > clever with tags and doing many separate merge commands, but that's rather > a hassle.) In addition, this makes it very difficult to continue > development on that "branch" should it become necessary at a later time. It's more of a hassle not to, isn't it? This is what I do: cvs up # on a branch cvs tag merge_from_branch_foo_to_trunk_3 cvs up -A # onto main branch cvs up -kk -j merge_from_branch_foo_to_trunk_2 -j merge_from_branch_foo_to_trunk_3 # check for conflicts, necessary testing, etc cvs commit -m "Merged changes from branch_foo from _2 to _3" If I'm feeling paranoid, I'll do pre and post tags on the main trunk as well so I can back out any changes, but it's rare that I need to do that. Heck, in some cases, I've done 30 or so merges like that before shutting down a branch. Granted, the further away the two branches get, the more likely that you'll see conflicts, but it's rarely that bad unless you start renaming files and stuff. > The other alternative, of course, is retiring the trunk, and doing all > subsequent development on the branch. That's pretty ugly; it makes life > difficult for new folks trying to check out a copy of the repository for > the first time; and I'd like to avoid it if I can. It's not that difficult to add "-r branch" to "cvs co". > So, I'd like to recommend swapping the two: the trunk should be our main > development effort, and the branch our bugfix area. However, the fact that > the currently-stable version of our software will be on branches makes it > somewhat more difficult to get a copy of the software for building a bugfix Well, *someone* has to be on a branch. Either the main one or the bug fix version (if not both). One thing I do a lot is keep 2-3 different copies of the source code checked out. Main branch in one directory, and one or two old branches for bug fixes (and merging as mentioned above). It's not like they have to be in the same top level directory (at least if your build procedure is done well). So rather than doing check outs, I just change directories, do a cvs up (just to make sure) and then get to work. > release, especially if the various subdirectories have branched > independently, as we now have to worry about making sure each directory was > checked out from the right branch. (Unfortunately, doing each of the Hint: Don't let developers branch on just some directories. Since you have a single project, have the developers branch the entire thing, even if they are only going to be changing one file out of 1000. It's a simple rule that does help keep things straight. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Suggestions for merging system?
One point I forgot to mention in my previous post: I wrote: > When a new branch is to be created (when development on a > new release is to begin) the current newest branch is > merged to the trunk, then the new branch is created off > the trunk. What I forgot to mention was that since no development is occurring on the trunk this merge is pretty much guaranteed to be without conflicts, barring accidental commits to the trunk, (which you can roll back prior to attempting the merge anyway.) -- steve __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Suggestions for merging system?
Richard Cobbe wrote: > Greetings, all. > > I'm trying to come up with a better model for managing merges and branches > than that which we currently use with our CVS repository at work. > > First, a brief description of the structure of our working area. We're > working on a single software system which consists of a number of > executables and shared libraries. The source code for each of these > binaries is stored in a separate directory in a large tree. The entire > tree is administered by CVS. > > All of the documentation I've read (both the Cederqvist and the Fogel book) > seems to assume that the trunk is for active development, and side branches > are primarily for fitting bugfixes into previously-released versions of the > software system. At work, we do this the other way. Now, cvs can > obviously merge in both directions, but there are some difficulties with > our current set-up. > > After we complete a release, we can shut down bugfixing on the previous > release, retiring that branch. Since, however, that branch is in fact the > trunk, we have to "retire" this "branch" by merging the current state of > the active branch onto the trunk. This will work, but if we've done any > prior merges from the trunk to the branch, then merging the other direction > is going to cause a lot of conflicts. (We could avoid these by being > clever with tags and doing many separate merge commands, but that's rather > a hassle.) In addition, this makes it very difficult to continue > development on that "branch" should it become necessary at a later time. > > The other alternative, of course, is retiring the trunk, and doing all > subsequent development on the branch. That's pretty ugly; it makes life > difficult for new folks trying to check out a copy of the repository for > the first time; and I'd like to avoid it if I can. > > So, I'd like to recommend swapping the two: the trunk should be our main > development effort, and the branch our bugfix area. However, the fact that > the currently-stable version of our software will be on branches makes it > somewhat more difficult to get a copy of the software for building a bugfix > release, especially if the various subdirectories have branched > independently, as we now have to worry about making sure each directory was > checked out from the right branch. (Unfortunately, doing each of the > branches at the root of the project wouldn't really help, especially since > many of the branches would be rooted at unstable points in various > subdirectories.) > > Has anyone found a successful way to handle this situation? I'd like to > preserve the ability of individual developers to branch their sub-projects > as necessary. > > Now, we could create a shell script to do the necessary cvs checkout and > update commands separately in each directory, place this script under CVS's > control, and have the developers update the script whenever we do a > branch. This is the only possible solution I've been able to find, and I'm > still hoping there's a better alternative. > > I'd greatly appreciate any suggestions and advice. > > Thanks in advance, > > Richard Richard, I am in the process of migrating from CMVision to CVS for a major project. I have written conversion routines so that I maintain all versions, dates, and history. Now I am working on a user interface program for the developers to use. The following is extracted from a System Change Request (SCR) form that I wrote for the migration that details what I am doing for the developers to interface with CVS and it may give you some ideas: ._._._._._._._._._._._._._._._._._._._._. USER INTERFACE: All baseline changes will be tracked to SCRs. Branching will be used as the centerpiece of the development environment that enables multiple developers to work on the same or different parts of the software at the same time. Changes will be tested using the branch tags with the branch being merged to the main after testing is complete. The cvs front-end program will create cvs_stage work areas by SCR and will execute the cvs commands for the developers. When a developer wants to begin work on a SCR, the worker will enter the SCR number. If the number is of an active SCR a cvs_stage directory will be created under the user's home directory of SCR. Developers will use the interface program to "checkout" or "fetch" files for the SCR. The program will use the cvs rtag command to create a branch for any file being checked out for edit. (Note that CVS does not actually mark the file in the repository as being checked out). Files being "fetched" will not have a branch made and will be set to read only. The program will make the branch in the repository using: cvs rtag -b -r HEAD SCRb path/filename HEAD is the tag that CM applies to the latest functional set of files on the repository. SCRb is the descriptive name of the developer's branch (note the "b" to denote a branch). The progr
Re: Suggestions for merging system?
Richard Cobbe wrote that he wanted suggestions about merging... I can tell you what we do, and you can see if it might make sense for you. We do all development and bugfixes on branches. We don't really use the trunk for any development at all. We have "official" branches that everybody knows about, essentially one branch per release. Bugfixes for old releases go on the branch for the old release. Developers are free to create their own branches if they wish to isolate themselves for a while from the rest of the organization, but if their code is to see the light of day, they have to eventually merge it into one of the active "official" branches. In practice, the developers rarely create their own branches it seems. When a new branch is to be created (when development on a new release is to begin) the current newest branch is merged to the trunk, then the new branch is created off the trunk. Lots of tagging and record keeping is done just to keep things straight. (Yes it's a hassle, but necessary, there's no avoiding it, so just take your time and tag it.) Typically we have 2 active branches at any given time, sometimes 3, sometimes just 1. Probably the toughest problem we run into is that occasionally stuff fails to get merged up from older branches to newer branches. "cvs rdiff -s" can catch some of this, (find files on old branches which have been modified since a new branch was created, but which have not yet been modified at all on the new branch, and therefore, must not have been merged.) This problem is probably an artifact of our rather loose development model, in which it is each developer's responsibiltiy to merge his code changes forward. (we do that 'cause there's so much code, no one person could hope to be able to merge it all and sensibly resolve the conflicts.) One person *can* go thru the motions of the merge, at least to see what a full-repository merge *would* do, in order to catch things that developers forgot to merge...) Well, that's one way it can be done, we've done it that way for the last 3 years or so. Hope it helps. -- steve __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Suggestions for merging system?
Greetings, all. I'm trying to come up with a better model for managing merges and branches than that which we currently use with our CVS repository at work. First, a brief description of the structure of our working area. We're working on a single software system which consists of a number of executables and shared libraries. The source code for each of these binaries is stored in a separate directory in a large tree. The entire tree is administered by CVS. All of the documentation I've read (both the Cederqvist and the Fogel book) seems to assume that the trunk is for active development, and side branches are primarily for fitting bugfixes into previously-released versions of the software system. At work, we do this the other way. Now, cvs can obviously merge in both directions, but there are some difficulties with our current set-up. After we complete a release, we can shut down bugfixing on the previous release, retiring that branch. Since, however, that branch is in fact the trunk, we have to "retire" this "branch" by merging the current state of the active branch onto the trunk. This will work, but if we've done any prior merges from the trunk to the branch, then merging the other direction is going to cause a lot of conflicts. (We could avoid these by being clever with tags and doing many separate merge commands, but that's rather a hassle.) In addition, this makes it very difficult to continue development on that "branch" should it become necessary at a later time. The other alternative, of course, is retiring the trunk, and doing all subsequent development on the branch. That's pretty ugly; it makes life difficult for new folks trying to check out a copy of the repository for the first time; and I'd like to avoid it if I can. So, I'd like to recommend swapping the two: the trunk should be our main development effort, and the branch our bugfix area. However, the fact that the currently-stable version of our software will be on branches makes it somewhat more difficult to get a copy of the software for building a bugfix release, especially if the various subdirectories have branched independently, as we now have to worry about making sure each directory was checked out from the right branch. (Unfortunately, doing each of the branches at the root of the project wouldn't really help, especially since many of the branches would be rooted at unstable points in various subdirectories.) Has anyone found a successful way to handle this situation? I'd like to preserve the ability of individual developers to branch their sub-projects as necessary. Now, we could create a shell script to do the necessary cvs checkout and update commands separately in each directory, place this script under CVS's control, and have the developers update the script whenever we do a branch. This is the only possible solution I've been able to find, and I'm still hoping there's a better alternative. I'd greatly appreciate any suggestions and advice. Thanks in advance, Richard ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
