RE: CVS questions

[Bulgrien, Kevin]

I see the script has a few obvious errors.  I've snipped the
offending lines from the quote below.  I snagged the script
from my shell history, but didn't clean it up quite enough. 

> >    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" >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" >source.txt
> >    cvs commit -m "add v7 feature"

<snip>

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

I'd venture to say its not CVS, but revision control in general.  You
would face exactly the same issues in whatever revision control tool
you decided to use.
 
> >> 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.

Look at the graphic here:

http://www.akhphd.au.dk/~bertho/cvsgraph/#example

The trunk is all the main line development with file revisions in the
form 1.x.  See how it kind of looks tree-ish (albeit the picture shows
only branches on one side of the tree?  The various branches all branch
off of the trunk or other branches.

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

There are at least two main philosophies about branching out there...

Some feel that trunk should always be used for current development,
while others feel that new development should be done on branches so
that there is a natural review when new development is merged to a
stable trunk.  The example I showed you put new 7.x development on a
branch.  I am not implying that is what you should do, its just what
came to mind first.

We could have just as easily tagged trunk with a 7.x tag, and at what
ever juncture we needed to patch 6.x, made a branch there.  That might
be more what you had in mind.  Here is one alternative sequence that
keeps 7.x on trunk.

   cd /home/kbulgrien/tmp
   mkdir repository current
   cvs -d /home/kbulgrien/tmp/repository init
   cd current
   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" >>source.txt
   cvs commit -m "v6.3" source.txt
   cvs tag v6_3
   cvs tag v7_0_BEGIN
   echo "this is the first v7 change" >>source.txt
   cvs commit -m "add v7 feature"

   Some time later we want to patch 6.3, so at that time we do this:

   cd /home/kbulgrien/tmp
   mkdir patched6_3
   cd patched6_3
   cvs -d /home/kbulgrien/tmp/repository co -r v6_3 .
   cvs tag -b v6_3_BRANCH
   cvs update -r v6_3_BRANCH
   echo "first 6.3 patch" >>source.txt
   cvs commit -m "6.3 patch 1" source.txt
   cvs tag v6_3_p1

Your sandboxes are now:

   .
   |-- current
   |   `-- CVSROOT
   `-- patched6_3
       `-- CVSROOT

You can still compare stuff back and forth.  Here is a scenario where we
decide we want the patches in 7.x

  cd /home/kbulgrien/tmp/patched6_3
  echo "v6.3 patch 2" >>source.txt
  cvs commit -m "Second v6.3 patch" source.txt
  cvs tag v6_3_p2

Ok, merge all the patches in source.txt back into 7.x:

  cd /home/kbulgrien/tmp/current
  cvs update -j v6_3_p2 source.txt

Now our v7.x file looks like this:

this is version 6
v6.3
<<<<<<< source.txt
this is the first v7 change
=======
first 6.3 patch
v6.3 patch 2
>>>>>>> 1.2.2.2

CVS merged the stuff together, but we need to decide what to keep and what
not to keep...  The fixup might be as simple as removing the conflict
markers or, it could be we need to manually integrate the changes based on
what we know about the code.  In this case, I'll edit the file this way.

this is version 6
v6.3
this is the first v7 change
first 6.3 patch
v6.3 patch 2

I sometimes find the CVS merge hard to remember how to use since I don't
use it often.  In this case, using a common repository is still a boon.
This time lets make a few changes on 7.x and then backport one of them
down to 6.x

  cd /home/kbulgrien/tmp/current

  <Edit the file to look like this>

this is version 6
v6.3
this is the first v7 change
first 6.3 patch
This is the second v7 change
v6.3 patch 2

Commit it.

  cd /home/kbulgrien/tmp/current
  cvs commit -m "second v7 change" source.txt
  cvs tag v7_1

Edit again.

this is version 6
This is the third v7 change
v6.3
this is the first v7 change
first 6.3 patch
This is the second v7 change
v6.3 patch 2

Commit it.

  cd /home/kbulgrien/tmp/current
  cvs commit -m "second v7 change" source.txt
  cvs tag v7_2

Later, we decide we want the v7_2 changes to source.txt in v6_3_p3.  You
can use CVS sort of like we did before, or you can use patching tools like
patch, etc., or a graphical merge tool to compare the two projects an merge
changes.  I'll use *nix patch because is is easier to show in text.

Method 1:

  cd /home/kbulgrien/tmp/patched6_3
  cvs rdiff -u -r v7_1 -r v7_2 >patchfile

Now patchfile contains:

Index: ./source.txt
diff -u ./source.txt:1.4 ./source.txt:1.5
--- ./source.txt:1.4    Wed Oct 29 13:48:54 2008
+++ ./source.txt        Wed Oct 29 13:51:18 2008
@@ -1,4 +1,5 @@
 this is version 6
+this is the third v7 change
 v6.3
 this is the first v7 change
 first 6.3 patch

This is easily to merge into our v6.3x source.txt file.  I'll use *nix
and leave Windows conversion as an exercise to the reader.  patch
isn't very Windowsy.  In practicality I'd use WinMerge or a similar
tool instead.

  cd /home/kbulgrien/tmp/patched6_3
  patch source.txt patchfile
  rm -f patchfile

Now, our source.txt on the 6.3 branch looks like:

this is version 6
this is the third v7 change
v6.3
first 6.3 patch
v6.3 patch 2

We could have just as easily have done it the CVS way.  First, we'll
blow away the changes we made with patch (since we didn't commit them
above.

  cd /home/kbulgrien/tmp/patched6_3
  rm -f source.txt
  cvs update

Now, re-apply the v7_2 change using only a CVS command:

Method 2:

  cd /home/kbulgrien/tmp/patched6_3
  cvs update -j v7_1 -j v7_2 source.txt

The results are the same, but we didn't have to muck around with a
third party tool:

this is version 6
this is the third v7 change
v6.3
first 6.3 patch
v6.3 patch 2

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

Seriously, this is easy.  We are talking less than ten commands, and they
are all given.  It is far more awkward to develop with separate
repositories if you want to keep changes synced between the two.

So... if you're maintaining two separate repositories... and still think
it is "too hard" to change, why would you ask on the list for another way?
At some point asking the question but not wanting to take time to learn is
wasting somebody's time, eh?  We all have jobs too.   If you figure this
out, it will help you for all time...  8.x, 9.x ...  Pay now, reap
benefits continually.

By the way, before I wrote this, I didn't have experience using update -j
as I have rarely had to merge.  I just knew it existed.  The point?  I
took time to learn to answer your question.  Your turn... :-)

---
Kevin R. Bulgrien
Design and Development Engineer

This email message is for the sole use of the intended recipient(s) and may 
contain General Dynamics SATCOM Technologies confidential or privileged 
information.  Any unauthorized review, use, disclosure or distribution is 
prohibited.  If you are not an intended recipient, please contact the sender by 
reply email and destroy all copies of the original message.