RE: Best practices for initial import and versioning

[Arthur Barrett]

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: address@hidden
[mailto:address@hidden On
Behalf Of Wirun, Corey
Sent: Friday, 21 October 2005 8:15 AM
To: address@hidden
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.