Re: partitioning cvsroot into dev, qa and pdc areas..

[Mark D. Baushke]

Kevin Duffey <address@hidden> writes:

> Been using CVS for some time via sourceforge, but now
> I am instructed to figure out how to develop our
> security model and such with CVS as we move our code
> to CVS internally.
> 
> I did the usual:
> 
> cvs -d /usr/local/repository init
> 
> did the chgrp, chmod stuff, etc.
> 
> Now, the IT team figures we should put files below the
> root starting off with project name, then below each
> project section it off for qa, dev, pdc's, etc. Below
> each of these groups, put all the stuff related to
> each section, such as the version of the project,
> shared code areas, etc. However, shared code, for
> example, may be needed across projects, so it seems
> unfitting to put it under each project.
> 
> My thought was the opposite. Make a /dev, /qa, /pdc,
> etc below the cvs root (/usr/local/repository). Below
> each of these, put the projects, shared code, etc. The
> idea here is that we are using our single CVS server
> for several departments, including documents,
> management, product coordinators, dev, qa, and so
> forth. I personally think sectioning it off into
> individual departments first, then below that putting
> specific department data is the way to go.
> 
> However, there is IT's take on this which is, below
> /dev, /qa and /pdc, we'll have the same project names
> and below those the same versions. Therefore, we are
> duplicating the /department/project/version path under
> each department.
> 
> Ok, so two questions to ask in regards to this. First,
> the main issue I am having is that I have created
> /usr/local/repository/dev/myproject. In Eclipse, my
> IDE of choice, I can connect to the cvs repository no
> problem. In my repository view, I can see HEAD, below
> that CVSROOT, dev, qa, pdc and so forth. If I expand
> the dev dir, I see myproject just fine. My problem is,
> I am starting off a new project in CVS below the /dev
> sub folder. I want to add in the files to CVS for the
> first time. Eclipse provides a Check out as feature
> that allows you to check out a project into a new
> Eclipse IDE project folder and work on it from there.
> However, my connection string is basically:
> 
> :extssh:address@hidden:/usr/local/repository.

Note that cvsnt supports :extssh: as a type, but that the cvshome.org
version of cvs does not use that method of encoding the use of ssh
as the transport. Also, Eclipse, being a windows-only front-end for
cvsnt is not something I have any experience using.
 
> Below that is CVSROOT.

Yes, this relates to the cvs init command you gave previously.
CVSROOT is a module and dev is a module of this repository.

> So how do I start a project
> that is at /dev/project-name in CVS that is able to be
> worked against on my local machine?

Is project the same as module in the Eclipse world view?

> I can't name the
> project dev/project-name. I tried adding
> /usr/local/repository/dev as the cvs location, but it
> says it can't find CVSROOT (as expected), so how do I
> dive one sub-folder below the root location to get to
> my projects?

If you are trying to use 

 cvs -d :extssh:address@hidden:/usr/local/repository/dev/project-name init

as the root or your new cvs instance, then you will likely get confused
by having a CVSROOT higher up in the tree. This is a bad idea and I
would recommend against proceeding in this manner.

> Not sure if I am asking this right, so
> I'll try another way just in case, I basically need to
> keep all projects for dev below a cvs root dir of
> /dev. But in the IDE, the project is not named
> /dev/project-name, it is just project-name. When you
> try to access the cvs /dev/project-name from CVS, how
> do you do this in the IDE (or for that matter, winCVS
> or anything else) so that you can directly access the
> project in the IDE and its commits get committed to
> the /repository/dev/project-name project and not the
> /repository/dev folder in cvs?

Your IDE tool does not sound as flexible as you may wish. Perhaps
you should direct your questions to an Eclipse support list? There
is also a support list for cvsnt over on the www.cvsnt.org page.

> Second, does it seem logical to do it in this manner
> as opposed to:
> 
> /repository/project-1/dev
> /repository/project-2/dev
> /repository/project-3/dev
> /repository/project-1/qa
> /repository/project-2/qa
> /repository/project-3/qa

The oranization of modules in a cvs repository always seems
logical to the organziation that creates it. For anyone
else it is probably closer to a nightmare. :-)

Seriously, if you have administrative reasons to keep
them separate, then put them in separate trees with a
separate CVSROOT each and let them be managed by each
departement.

If you can live and play together nicely, then just give
each department its own top-level module (or set of
top-level modules) and them them work in their own
world view without let or hinderance.
 
> Also, in regards to this, it seems to me that setting
> user/group permissions based on the
> /<department>/project approach as opposed to
> /project/<department> will be much better and more
> controllable. 

If you have a separate CVSROOT for each department, then you could make
the parent directory that owns it only allow group membership of the
department do anything with their repository. So, yes, it is more
flexible with regard to permissions.

> I need to get confirmation on this
> specific issue as well, because while both result in
> the same number of files (folders, project files,
> etc), adding a new QA engineer to the QA group that is
> matched to the /repository/qa folder, as opposed to
> having to set up the QA group to every new project
> using the /repository/<department>/project/qa
> approach, just seems to make more sense. I suppose
> since projects aren't added all that often, and simply
> adding a new engineer to QA will automatically make
> her available to all projects with the QA group
> matched to it is fine, it just seems to be more
> maintenance.

That is indeed the tradeoff. More work to manage the CVSROOT and
administrate multiple repositories or more work to make sure that
the departments do not abuse the resources of another department.

> Sorry, another question to ask..
> 
> As part of what I asked earlier, we are trying to
> figure out the best directory structure for our CVS
> projects. I am more concerned with the development
> structure as I am a developer. But in general my
> question is, how have some of you structured your
> corporate cvs repositories in terms of development and
> possibly departmental directory structures?

I have seen a number of variations here. Most common is
to have a single repository with top-level modules based
on function rather than departments. Departments tend to
change in the organization over time, so they are a really
bad way to organize things for future expansion.

There are always some departments that have their own special security
requirements, so those tend to sit on their own server for the
department in question and be separately managed and NOT allow the
entire company to login to it. For example, letting Sales checkout
the latest design specification for a new product that will not be
ready to sell for another two years is a bad idea. You will find that
the salesman may leak your future plans to your customers who in turn
may leak them to your competitors. So, it is often useful for
the R&D engineering folks to have their own repository for 
specification documents.

> Namely, we will have documentation (from our docs
> department), dev, qa, pdc (product coordinator),
> management and others all wanting to
> add/read/modify/etc to cvs.

This is probably not a bad thing for the most part.

> As I had posted earlier, I personally think adding
> each department to the root of the repository is best.

If you know that your departmental structure will remain fixed for the
next five or ten years, then this is a fine idea. If you think you
may see more departments or a re-alignment of some existing departments
then it may not be the best way to go.

> There are of course the options of creating multiple
> repositories, perhaps that is better?

Possibly. Typically that is only useful if you have security
concerns on checkout. You can fairly easily restrict checkin
to only authorized users.

> Ideally, the
> PDC, QA, DOC and DEV teams will be working on the same
> projects and versions (different versions no doubt).
> For this email, I'll regard / as the cvs root dir
> where the cvs init command with the -d argument points
> to. My thought is:
> 
> /dev
> /qa
> /pdc
> /doc
> /mngt
> 
> and so forth.
> 
> Each department could manage thier own structures
> (probably IT doing any admin level work though).
> 
> But for dev, I was thinking:
> 
> /dev/<project name>
> 
> below each project:
> 
> /<project name>/version <x.x.x.x format>

CVS is designed to manage versions. Do you really
need/want to have the filesystem do this redundantly
for you? If so, why?

> For each version we would have whatever is related to
> the given project at that time.

This is called a cvs tag.

> Using VSS we used to keep a single ongoing trunk and
> label it as we worked on versions. This proved to be a
> pain in the arse to grab any specific branch easily,
> especially for newbie users. I personally like this
> idea as it keeps the dir structure cleaner with less
> cluttered directories and doesn't duplicate code. But
> with 250GB of hd storage and a multi-TB farm at our
> disposal, space is not an issue. Performance, of
> course is an issue. If using multiple version dirs
> like this would hurt performance, please let me.

Using NTFS or some other filesystem? There are too many
variables to give you a hint on performance. Make some
tests yourself and see what you get.

> So, given the above, does this make sense? Also, at
> least for dev, we plan to have a /dev/shared dir
> somewhere, where we will store shared source, such as
> libraries we use across projects.
> 
> Please let me know if the above looks ok, or if there
> are better ways to do this. A co-worker suggested
> using sym-links to present a "view" of a repository,
> but I am not at all familiar with how this would be
> done. I know what sym-links are, I just think another
> goal is to keep it as simple as possible without
> overly complicating things for the IT staff that will
> be maintaining this.
> 
> If there are other ways in which some of you may
> maintain your cvs repository for your company, please
> explain how you manage it, set up the dirs, etc.

See above.

        -- Mark