Corey, Well that's only one way to use CC of course, I've used it a little and I know you don't have to do things that way (because I didn't) - I didn't get into the rational unified process enough to be sure if it's the way they recommend or not.
Certainly in CC when each developer is assigned some work you create a view on the repository for them - but that is not a branch. The nearest equivalent in CVS is to create a work space for each developer (sandpit) by doing "cvs co modulename". A checkout in CVS does not equate at all to a checkout in ClearCase - it's much more like "create view". My opinions on how to use CVS are rather clouded by the fact I use CVSNT (free, GPL, runs on Linux, Solaris, HPUX, Mac and Windows too). CVSNT supports many additions to the basic CVS which I use a lot. Our company uses CVS for maintaining many legacy applications for our customers and we do main development / next gen development on Trunk, and when a release is nearing - create the "maint v1" branch - then v2 continues on Trunk, and v1 on branch. When ready to start testing, create a "promotion level" (like a branch but different) called "test1" etc etc up to "prod1" CVSNT supports ACL's on branches and versioned keyword expansion and locking options so on the Trunk we can use reserved (developers only) and on Prod we can use unreserved (release staff only). CVSNT also supports change management (defect tracking integration) so each change is stored with a related issue/bug number and changes can be "promoted" (or merged) using that number. CVSNT also supports commit id's - but they are more useful for internal reasons than business reasons. A commit id is unique for each transaction whereas a defect/issue does not - so when you merege issue 100 from maint1 to test1 it can take 5 or 10 actual changes at once. There's 300 pages of this in that book I mentioned ;) Regards, Arthur -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wirun, Corey Sent: Friday, October 21, 2005 4:09 AM To: [email protected] Subject: RE: Best practices for initial import and versioning Andrew, Yes, I realized that this was a CVS list. I was just using wincvs as the tool in front of CVS. It's still how best to use CVS which is what I was soliciting advice on. Next time, I won't even mention wincvs ;) I come from the Rational Clearcase world. In the Clearcase world, we always have a main branch (i.e. the trunk) and we create branches off the trunk for development. Each developer would have their own branch, actually. We work off our branches and when we are done, we one-at-a-time, merge to the trunk, throw down a label (aka tag), and release from that label. I appreciated your insight on how the files are stored - that it is the tip of the trunk. That appears to poke a big hole in my release-only-from-trunk scenario. So much for trying to make CVS work like Clearcase... In a nutshell (until I get a book), what would you suggest is the best way (most efficient use of branches and tags) to be able to segregate development for a release from previous releases. A straight linear trunk - tagged with your releases? It sounds like branches are not necessarily a good thing - over time. Then why use them (in CVS)? Thanks for your reply. Corey. -----Original Message----- From: Arthur Barrett [mailto:[EMAIL PROTECTED] Sent: Thursday, 20 October, 2005 17:06 To: Wirun, Corey; [email protected] Subject: RE: Best practices for initial import and versioning Corey, This is not the correct list for WinCVS. The CvsGUI list is here: http://groups.yahoo.com/subscribe/cvsgui Your question is a mixture of process and cvs fundamentals - so there is not necessarily a "correct" answer - however if you are new to CVS/WinCVS then you may be better asking a more concise question such as "how do you organise development, test and release"? Different CVS servers also have different features which will also affect the type of decisions you can make. If you are using WinCVS then I suppose there is a chance you are also using CVSNT server (on Windows or Linux), in that case please direct y our questions to the CVSNT list: http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt or news://news.cvsnt.org/support.cvsnt I'd recommend the book "All About CVS" but that's because I wrote some of it: http://march-hare.com/cvsnt/features/book/ >From your description it looks like you are thinking of doing your development on branches and having the releases all on the trunk. I know some people like this method - but I don't, and besides there is only ever one complete copy of your file stored in CVS, and that is the tip of the Trunk - so if you development is all occurring on branches then each update/commit will have significant cost (when you have 10 years of versions stored). Finally you've mentioned a lot of version numbers in your post - which are maybe just for illustration - however don't get too caught up on version numbers since they are largely arbitrary. Regards, Arthur Barrett -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wirun, Corey Sent: Friday, 21 October 2005 8:15 AM To: [email protected] Subject: Best practices for initial import and versioning Hi All, I have a question for you on the best practices way to set up the initial import of a module and how branching/merging 'should' be done with respect to a release. Please bear with me as I describe what I do: I initially import a source tree using wincvs. I set a Vendor and Release tag. Again using wincvs, I checkout the module using the vendor branch. Looking at a single file, I see a 1.1 revision and the vendor branch off it with a release tag. Under the vendor branch, I have an initial 1.1.1.1 revision of my file. All my 1.1.1.1 revisions are now local. I make my edits and I commit the changes. I now have 1.1.1.2 revisions of the files. Say this is the candidate for a release. I want to now merge to the main trunk and lay down a RELEASE tag. The problem/question is should I merge to new revisions under the 1.1 revision? This is where I need some guidance. Should I merge the branch files to ultimately get a revision 1.2 that I can tag with a RELEASE label? After the edits on the (vendor) branch, I updated the local files based on the '1.1' revision (cvs update -P -d -r 1.1). I couldn't think of any other way to get the trunk files...? So how should the merge be done from my branch to the trunk? I thought I might want to get a series of 1.2 revisions, which I would then lay down a new RELEASE label, but is this reasonable? Every time I release, should/can it be from trunk revisions? What do other people do? I'm concerned because of the way I brought down the main trunk revisions. '1.1' shows as not only the revision, but the sticky tag, which can't be good for the merge. Thanks for any advice!! Corey. ----- Corey MJ Wirun home office: 403 720-3699 fax: 403 720-3699 (shared line, voice call ahead!) "Anything will fly with 10KLbs of thrust. Landing? That's a different story." - power does not mean capability. This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify the sender and permanently delete the original copy and any copy of any e-mail, and any printout thereof. This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email, and any attachments thereto, is strictly prohibited. If you receive this email in error please immediately notify the sender and permanently delete the original copy and any copy of any e-mail, and any printout thereof. _______________________________________________ Info-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/info-cvs _______________________________________________ Info-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/info-cvs
