RE: Need help organizing a CVS tree. (Summary at the end)

[Teala Spitzbarth]

Terry,

You seem to have some fundamentals about cvs a little blurred.
What you are trying to do is fairly complex - your email is an
interesting jigsaw puzzle.

I don't know about your issue with cvs co -d, but fundamentally what you
are trying to do by making a 'directory' in the source tree indicative
of a "branch" (containing code specific to a given customer) seems a bit
unusual to me.  You also make a statment that modules result in
undesirable 'sticky tags' - this is a false statement.  What produces a
sticky tag on files in a given working copy is doing a cvs co (or
update)-r <tag> (or a branch, which internally to cvs is also a kind of
tag).

Your source layout challenges are somewhat similar to ours,
we have cross-platform source (gets built on WinNT, Linux & solaris).
All the code lives in one module and we handle different releases
through branches of that one module.  Our makefiles determine what is
going to get built on a given platform I.e. we have linux makefiles,
solaris makefiles & if def's within the code, that control how to build
properly on the given OS environment.  My quick sense of what you need
to do is ideally 
move back to this kind of a 'Trunk' with customers specific branches per
release off of that Trunk (and then you have the regularly scheduled
forrays into 'merge-land' when you have to merge code back from the
customer specific branches to the main trunk).   Or if you can't get
linux and unix building together in one source base, then go to having a
linux module and a unix module, with branches for the specific customer
versions.

I really dunno about this cvs co -d thang to baby your developers into
knowing what customer branch they are working on.  
Note there are ways to devise commit-info scripts that can check what
branch you are making a commit into.  You can lock branches this way -
or in your case you could put out a warning to the developer about what
branch (and any more sophisticated customer mapping you want to display)
they are about to check into.

I work up in Scotts Valley if you want to talk on the phone, we could
have a natter sometime about this stuff and it might be more productive.

Cheers,
Teala

-----Original Message-----
From: Terry Spafford [mailto:address@hidden
Sent: Wednesday, February 20, 2002 3:59 PM
To: info-cvs
Subject: Need help organizing a CVS tree. (Summary at the end)


As I mentionned in my previous email (with another question), I've 
recently been put in charge of reorganizing my company's code management

system. I have a clean slate to work with (ie I don't have to worry 
about saving the old code history, just the new stuff), but I have a 
tonne of code to pour through and organize.

Just to give you a bit of background, my company primarily makes Air 
Traffic Messaging systems for aviation authorities around the world. 
Each of our customers has a mix of the various subsystems we offer all 
on one box (usually an Alpha though we're migrating to Linux as well).

After much debate among our developers, we decided that trying to keep 
all of our customers in synch with the same code was a lost cause, so 
we've got code drift between our customers that we have to handle. It 
also means that we don't have to worry about merging customer code with 
eachother or with the Bleeding edge code.

We also concluded that even though we are not going to keep the 
customer's in synch, we still want to be able to easily diff between 
code Customer A has with code Customer B has or with our new 
Developement Code (our Bleeding Edge code). Ideally we would also like 
to be able to compare the Linux version of a system with the Unix 
version of a system.

Basically, for example, we have the following:

System_A ( Linux Version)
System_A ( Unix Version )

System_B (Linux Ver)
System_B (Unix Ver)

All 4 versions are different and are Bleeding Edge.

Cust_1 has a Linux box with System_A and System_B installed
Cust_2 also has a Linux box, but only with System_A installed (and a 
slightly different version then what Cust_1 has )
Cust_3 has a Unix box with only System_A installed.

We also want to be able to easily check out all the code a customer has 
on their machine without having to chase down other sources to remind us

that say Cust_1 has both System_A and System_B installed.


After rereading the docs on the CVSHOME website hundreds of time, 
performing many experiments and redesigning my organization plans many 
times, I came up with the following method:

The CVS Tree is organized as follows:
$CVSROOT
     |
     - - - > (Operating System)
                      |  (This indicates a subdirectory)
                      - - - > (System)
                                 \  (Note this indicates a branch)
                                  - - - > (Customer code)

This forces us to break our code up by operating system, making it 
difficult to do diffs of versions of our code across OS's, but otherwise

it meets most of our requirements.

To checkout all the code a customer has on their machine, we can just
        cvs co -b (Customer Code) (Operating System)

To get a particular subsystem a customer has it's:
        cvs co -b (Customer Code) (Operating System)/(System)

etc...


I'm not comfortable with this setup however (If I was I wouldn't be 
bugging you with it now would I? :)

For one thing, unless you specify a directory to check out into ( cvs co

-d (new_dir), all the code ends up looking like the same directory tree 
structure. (OS)/(System). Since we do a lot of work on shared machines, 
this can be a major problem at times as people may not realize the code 
they are manipulating is the code they are expecting. (At least not 
until I get them into the habit of cvs status'ing stuff). As long as I 
can get the -d flag to work on a cvs co from a remote repository though 
this won't be a big deal.

The main concern I have, is bleeding edge code (ie the code at the head 
of the Trunk). In all the scripts I've made for others to use the CVS 
tree with, I had to set up a special flag so that the script could 
handle code from the Trunk, but I am not comfortable using the flags, 
and in some cases  this is dangerous.

In particular, commiting changes has become a small nightmare for me.

I've discovered that commit -r (branchname) works great, since it aborts

if the code isn't all uptodate for (branchname). (We don't want people 
commiting changes into another branch without first making sure they 
update it).

Commiting to the trunk though is the source of my concerns. I can't 
simply do a cvs commit command because if there is changed code from 
other branches in that area, it will commit those changes to those 
branches as well as the files for the trunk.

I briefly examined Modules, and they sort've seemed to do what I want, 
but they left behind sticky tags that made commit's messy.

Earlier today, I thought I was on to something with the Vendor tag I 
used when importing code. I noticed that if you checked out under the 
vender tag and commited changes, the changes also applied to the Trunk 
code as far as I could tell. Sadly the reverse wasn't true, or else it 
would work great; namely code checked out with no tags did not make 
changes to vender tagged code when commited.

If I was certain that everyone would always use the scripts I've 
developed, then I wouldn't be as concerned. But I already know that at 
least 1 other developer besides myself will be using the straight cvs 
commands right off the bat, and others will migrate to the cvs 
commandline instead of the scripts as time goes by; so by planning for 
that now, I'm hoping to keep this from becoming too much of a nightmare.

Summary

Basically, to try and boil my ramblings down to some more concise 
points, I'm wondering the following:

1. Given the way our code is broken up right now, can anyone think of 
possible ways I could try to improve my design? (In particular, I would 
love to squeeze the operating systems back together so we could diff 
between Linux and Unix easier).

2. Is there a flag or something I can pass in with CVS commit so that 
when I am commiting changes to the Trunk, it will abort if any of the 
code belongs to a Branch.

2b. Actually, is there a tag I can always call with -r that will always 
point to the head of the trunk and that works with all the basic CVS 
commands that allow -r ?

3. And of course, just to reiterate the problem that brought me to this 
list in the first place, is there a way to specify what directory code 
will be checked out into on a local machine when you have a remote 
repository? Using cvs co -d is giving me errors. (See my other message 
for more details)


Thank you in advance for any advice you give me.

-- 
Terry Spafford
Software Engineer
Global Weather Dynamics Inc
Monterey, California, USA
address@hidden
www.gwdi.com


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