info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Best practices for initial import and versioning


From: Wirun, Corey
Subject: RE: Best practices for initial import and versioning
Date: Thu, 20 Oct 2005 22:08:37 -0500

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:address@hidden 
Sent: Thursday, 20 October, 2005 17:06
To: Wirun, Corey; address@hidden
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: 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.
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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]