rir has asked for the wisdom of the Perl Monks concerning the following question:

I have casually used source code control systems in traditional unixy ways. I am very much a beginner as an CVS administrator.

I have learned how projects can grow out of the offhand directory structures that I put them in.

One pearl of wisdom I have discovered: Mixing source files into your product directory does not scale up. Once you start having generated objects there is an artificial need to separate the two types of files.

I am planning the following directory tree for a project and would like to have the feedback of the knowledgeable monks. This basic structure seems applicable to many projects. My nomenclature is very tentative. 

project/            -- The CVS Module name
        Makefile
        misc/       -- snippets unused in project
        src/        -- all the source
        precious/   -- degenerate generated source objects
        edited/     -- source hand edited from precious
        tmp/        -- use unless $ENV{TMPDIR}
        objects/    -- intermediate objects
        project/    -- the finished product

[download]
Tmp, objects and project all can be ignored by CVS. What is the best way to ignore these?

Project/src contains most everything. In my current project it has: 

    Bin   -- in developers PATH and part of source
    Src   -- source code
    Data  -- demo data, test data, and testings expected state data
    Def   -- meta-definitions and templates for code generation
    Doc   -- User, design and programmer documentation
    Test  -- Test programs

[download]
Should Project/Src/Src be a separate directory or should it's contents be moved up into Project/Src?

Precious and edited may not be necessary. They are a work around for the kludge of semi-generated source. In this case I am generating simplistic screen files from my data structures, these files need to be reworked by hand for final layout. The reworked files are placed in edited. Make will generate new versions of precious objects in a tmp directory. If there is any change, the edited version may need to be re-edited and the precious object replaced. Make will die with instructions on what needs doing.

For further reading see directory structure, directory change and mirroring and a CVS intro.

Replies are listed 'Best First'.
Re: CVS Directory Structure
by joe++ (Friar) on Feb 20, 2003 at 10:23 UTC
    Hi rir,

    Not sure if your question is about (a) CVS or (b) the communis opinio about the most appropriate directory structure for your projects.

    In case A. I would recommend to look into the .cvsignore file, which specifies which files and directories to ignore (add the .cvsignore file itself to CVS, however!).

    In case B. I guess that the first two links from your "further reading" provide lots of suggestions...

    --
    Cheers, Joe

[reply]
[d/l]
      Thanks.

      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.

[reply]
        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 MeTM.

        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

[reply]

Back to Seekers of Perl Wisdom