[Top][All Lists]

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

Re: CVS questions

From: Hector Santos
Subject: Re: CVS questions
Date: Wed, 29 Oct 2008 13:11:20 -0400
User-agent: Thunderbird (Windows/20070326)

Bulgrien, Kevin wrote:
I had explored the ideas of using branches and tags but quite frankly, it was very confusing so to be on the safe side, I simply cloned the 6.3 (\CVSROOT\WC6\) repository to \CVSROOT\WC7 and
checked out WC7.

Wildcat!  I used to run a BBS for a local university in the late 80's...
I used Wildcat.  Talk about a blast from the past.  I would have had no
idea it was still around.


You probably used the DOS version. In 96, the Windows/Internet version was released, made a big blast in the emerging internet world as one of the first integrated hosting system, but as we all know, the free WEB world did not help it or other commercial systems. However fortunately, it survived in the corporate world. The Business Support Model is still fundamental. When your doctor files an insurance claim on your behalf, the odds are very good, somewhere in the network loop, there are wildcat! file exchange servers collecting all the claims. Strangest thing, we are getting bothered more and more with the free hobbiest world again - something is happening out there. Its getting harder? Two much they have to put together? Who knows. <g>


Anyway, thanks for your input there.

I'm not sure why branching is confusing.  It's very simple.

   cd /home/kbulgrien/tmp
   mkdir repository sandbox6
   cvs -d /home/kbulgrien/tmp/repository init
   cd sandbox6
   cvs -d /home/kbulgrien/tmp/repository co .
   echo "this is version 6" >source.txt
   cvs add source.txt
   cvs commit -m "v6 example" source.txt
   echo "v6.3
   echo "v6.3" >source.txt
   cvs commit -m "v6.3" source.txt
   cvs tag v6_3
   cvs tag v7_0_BEGIN
   cvs tag -b v7_0_DEVEL
   cd /home/kbulgrien/tmp
   mkdir sandbox7
   cd sandbox7
   cvs -d /home/kbulgrien/tmp/repository co -r v7_0_DEVEL .
   echo "this is the first v7 change
   echo "this is the first v7 change" >source.txt
   cvs commit -m "add v7 feature"

   /home/kbulgrien/tmp/sandbox6 contains your version 6 sources
   and sandbox7 contains your version 7 sources.  From either
   sandbox, though, you can check the differences to each other.
   For example:
cd /home/kbulgrien/tmp/sandbox7
   cvs diff -r v6_3

See what I mean. Not so simple. <g>

Seriously, it all does seems simple. But there seems to be many things to watch for. I explored and it was just too confusing where you will need helper batch files or frontends to do things like above. No way I would of figured out the above. Nonetheless, I appreciate the example. I am saving it so I can study it line by line.

   Keeping up with the two sources is now quite easy.

   I won't go into merging.  You could either use built in merge
   facilities of CVS, or you could even just use the differences
   and manually merge things.

This is what I was somewhat referring to - merging related issues. IMO, a very confusing aspect of CVS.

My questions:

I had been working on WC7, making all my changes for the newer compiler, etc, and now I am written to commit this.

1) How should I "tag" this, what switches should I use? do I use a Branch?

The branch from 6 to 7 is made one time... other than at the point
of the branch, you tag like you always did.  As for making the branch
I always make a normal tag that shows where the branch was made and
a branch tag so that it is much easier to see differences to the
branch point - very helpful when merging changes back and forth.


Which leads me to my 2nd question:

2) Is there a "enhanced" version of CVS that allows for two different "trunks" per se?

The branch checkout acts as its own "trunk" per se.  I have a hard time
visualizing what you think a dual trunk would look like.  As far as SVN
or other version controls systems go... I would think it quite obvious
that it would be a lot more difficult / time consuming to completely
change your version control system than to learn how to use branching,
even if switching over appeared/was trivial.

Right, I agree, which is why I have not made the jump to SVN or CVSNT for that matter. I have to understand the problem first. :-)

I have no idea what "trunk" means, so I extrapolating from my readings and I really don't see a definitive answer. The common thing I see is that it appears CVS only supports 1 trunk while others have supported this idea in some better way.

I'm not all sure what that means, but based on CVS readings, all branches are temporary with the eventual idea that they will be merged into a single trunk. That was still confusing, as I see some "indications" that a BRANCH can begin a new "product version" that will never be merged into some older "trunk" but a new "branch trunk" per se.

So as you see, it sounds simple, but I am probably wrong and I'm confused <g>

Overall, I was thinking ideally of having a single repository where I can "STAMP" it v6.3 and begin a new "V7.0" and from that point on, a new 5-10 years development cycle begins with 2-3 developers. But the v6.3 version would still have a life for maintenance and any changes made to it would not conflict with v7.0, however, the possibility is known that there might be a Common Hot Fix to v7.0 that applies to v6.3 as well.

So after exploring all that by keeping/working with a test CVSROOT\WC6 copy, I guess I didn't know all the CVS commands to do this, like your batch file.

So I ended up (and I do feel more comfortable this way), making a copy of CVSROOT\WC6 to CVSROOT\WC7 and having two separare checkout concepts and deal with any duplicate work, which in reality will probably be less and less an issue as time goes on.


Hector Santos, CTO

reply via email to

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