Re: CVS questions

Hector Santos <[email protected]>
Newsgroups gmane.comp.version-control.cvs.general
Organization Santronics Software, Inc.
Message-ID <[email protected]>
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.

<sidebar>

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>

</sidebar>

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.

Ok.

>> 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.


-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.