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: Russ Sherk
Subject: Re: Best practices for initial import and versioning
Date: Fri, 21 Oct 2005 09:22:52 -0400

Corey,

Have a look at this http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_5.html#SEC54.  It gives good overview of branching and merging.

I personally find it less painful if development is done on the trunk and releases are branched for maintinance.  This way, the merge-backs are fewer when main development is going on.  You will have to merge fixes from the maintinance branches to the main trunk after a release but this is less of a headache because these are generally smaller and easiser to manage than merging all the changes that would be made on a development branch.

--Russ

On 10/21/05, Arthur Barrett <address@hidden> wrote:
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: info-cvs-bounces+arthur.barrett=address@hidden
[mailto: address@hidden] On
Behalf Of Wirun, Corey
Sent: Friday, October 21, 2005 4:09 AM
To: address@hidden
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: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: info-cvs-bounces+arthur.barrett=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.


_______________________________________________
Info-cvs mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/info-cvs


_______________________________________________
Info-cvs mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/info-cvs


reply via email to

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