I don't understand what you mean by add the .cvsignore file itself to CVS. The CVS docs indicate that .cvsignore files are just for sandbox-side use. This seems much less clean than using something like the cvsignore file in the repository. However the docs don't show how to use cvsignore to ignore a pathname. The docs imply that you use cvsignore to ignore patterns matching on the basename.

The links I gave don't say much beyond I use this directory structure, not much in the way of justification, experiences or alternatives. Likewise O'Reilly's Applying RCS and SCCS, by Bolinger & Bronson. Most of the version control texts I've seen related to compiled code.

Perhaps in learning one lesson I suspect there are more hidden traps where none exist. Maybe this wheel is just round and it matters not its size, bearings, material, width, tread shape, tread material, balance, toe in, camber, heat limits, maximum speed rating, maximum load rating, wear rating etc.

Well... I have to admit that I have not really looked too much into the one and only one valid way of organising your project directories, but I guess I'm a little bit pragmatic about this issue.

What I meant with add the .cvsignore file itself to CVS is to put the .cvsignore file in the top of the working directory (AKA sandbox in CVS terminology), and check this one in to the CVS repository, so changes to what I want to ignore are tracked by CVS as well. No rocket science, but Works For Me^TM.

While we are at this, if you want to be really flexible with directories and moving files around, CVS has many shortcomings. Maybe then you should look into one of the alternatives, like subversion (still in early development), bitkeeper (licensing issues?) or the Rational products (costing $$'s).

--
Cheers, Joe

I looked into other version control systems a while back. For an open source project it seemed to come down to rcs, sccs, cvs and subversion. Since subversion was then unreleased, cvs was a clear choice. Subversion's promises sounded really good though.

It is due to my lack of knowledge and the inflexibility of cvs that I asked my questions in the first place. The idea is not to find the one and only one valid way but to understand the trade-offs involved in the various alternatives.

For instance moving all target, intermediate and scratch directories up out of the CVS tree simplifies versioning. But would that create a bad first impression by over flowing its expected namespace when folk create a workspace? I suspect so.

I restructured my project not long ago. Having learned a bit the hard way I am looking at doing it again now. I'd like to learn a bit the medium way.

Now I have hundreds of files. When I have lots more will it still be as easy to restructure my repository? Should I not be concerned to plan ahead?

Did I misunderstand the docs? .cvsignore files only effect the user's workspace, not everyones view of the repository.

I don't find your responses too satisfying -- they seem to reflect an offhand attitude to the subject. I realize this could come from vast experience and great knowledge of version control systems but your posts don't impart enough to me to know this.

Thank you again for your kindness in trying to help.