[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Feature request: directory attachments

From: Steve Soule
Subject: Feature request: directory attachments
Date: Sun, 02 May 2004 16:30:14 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1

I would like a feature added to cvs that lets you specify that a module is attached as a subdirectory of a directory. This feature would mostly make the modules file unnecessary. Here's how I think it could work:

If a directory contains a file with the name ".cvsattachments", its contents should be parsed as a list of modules that should be checked out in that directory when the parent directory is checked out. This is just what the ampersand module feature provides, except that cvs update would know about it too since the information would be in the directory instead of in the modules file where update can't make sense of it.

The ".cvsattachments" file could be versioned just like any other file, and if the user did "cvs update -d", and the new .cvsattachments file specified a subdirectory that wasn't there before, update could grab the appropriate module just like checkout does now with ampersand modules.

The format of the .cvsattachments file could be a sequence of lines, each of which is a subdirectory name followed by a module name. The module name should be in absolute URL format so that it can be in a separate repository. Is there a URL format for cvs module names? If not, someone should create one.

This feature would work almost exactly the same as subversion's svn:externals directory property, only with the data stored in a file instead of metadata.

There are several reasons why I think a per-directory attachments file is better than the existing modules file functionality:

1.  Every cvs component would know about the structure, not just checkout.

2. The module containment information is stored in the affected directories instead of in a repository-wide modules file.

3. The module containment information is associated with the module instead of with the repository.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]