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. _______________________________________________ Info-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/info-cvs
