>--- Forwarded mail from [EMAIL PROTECTED]
>I want to take a poll with regards to the following issue:
>"cvs add" must specially handle empty directory hierarchies such that no CVS
>admin subdirectories are created within them. (I've tried to be as unbiased
>with this statement as I can).
>Please answer with "strongly disagree", "disagree", "neutral", "agree",
>"strongly agree" and provide a _detailed_ explanation.
>--- End of forwarded message from [EMAIL PROTECTED]
I strongly disagree. Here's why:
Given a repository with the following structure:
$CVSROOT
common
include
c
src
app1
data
src
app2
data
src
And the following module database:
app1-base -d app1 src/app1
app1-common -d app1/common -l common
app1-includes -d app1/common/include common/include
app1 -a app1-base app1-includes
app2-base -d app2 src/app2
app2-common -d app2/common -l common
app2-includes -d app2/common/include common/include
app2 -a app2-base app2-common app2-includes
One of the requirements of this architecture is to share header files
across multiple projects. (Such a project would also contain libraries
that are shared among applications, which I've pruned for simplicity.)
When performing a "cvs checkout app1" this will produce a sandbox of the
following structure, with the intended mapping to the repository above as
shown (which matches today's behavior of CVS):
app1 ($CVSROOT/src/app1)
common ($CVSROOT/common)
include ($CVSROOT/common/include)
c ($CVSROOT/common/include/c)
data ($CVSROOT/src/app1/data)
src ($CVSROOT)src/app1/src)
Now suppose the app1, common, and include directories are devoid of files
(i.e., they contain only directories). The figure above is modified as
follows, when CVS admin directories are omitted:
app1
common
include
c ($CVSROOT/common/include/c)
data ($CVSROOT/src/app1/data)
src ($CVSROOT)src/app1/src)
In the event that files are added later under CVS control in the empty
directories, then the proposed "cvs add" behavior that scans upward for
CVS control files will perform the following mapping:
app1 (???)
common (???)
include (???)
c ($CVSROOT/common/include/c)
data ($CVSROOT/src/app1/data)
src ($CVSROOT)src/app1/src)
Note that the mapping from sandbox to repository in the above example
differs from the one that was intended in the first example. Several
of the directories have unpredictable mappings to the repository, which
depend on prior checkout history and indeed may not have any valid mappings.
This is a problem when the user wants to add a new file to a directory
that presently contains no files.
Now suppose someone works around the problem by placing a .cvsignore,v file
in the $CVSROOT/src/app1 directory. A subsequent "cvs checkout app1" produces
the following:
app1 ($CVSROOT/src/app1)
common ($CVSROOT/src/app1/common)
include ($CVSROOT/src/app1/common/include)
c ($CVSROOT/common/include/c)
data ($CVSROOT/src/app1/data)
src ($CVSROOT)src/app1/src)
Again, this is not the intended mapping of sandbox directories to the
repository.
And in fact a future commit of files added to the common and include
directories will create unwanted directories in the repository and place
those files in those directories so that subsequent checkouts of the app2
module will have incorrect results.
For example, suppose a README file is added and committed to the include
directory, as shown:
app1 ($CVSROOT/src/app1)
common ($CVSROOT/src/app1/common)
include ($CVSROOT/src/app1/common/include)
README ($CVSROOT/src/app1/common/include/README,v)
c ($CVSROOT/common/include/c)
data ($CVSROOT/src/app1/data)
src ($CVSROOT)src/app1/src)
The repository is modified as follows:
$CVSROOT
common
include
c
src
app1
common
include
README,v
data
src
app2
data
src
A subsequent checkout of app2 produces this sandbox:
app2 ($CVSROOT/src/app2)
common ($CVSROOT/src/app2/common)
include ($CVSROOT/src/app2/common/include)
c ($CVSROOT/common/include/c)
data ($CVSROOT/src/app1/data)
src ($CVSROOT)src/app2/src)
However, after adding and committing the README file, the intended structure
of the repository is this:
$CVSROOT
common
include
README,v
c
src
app1
data
src
app2
data
src
And a subsequent checkout of app2 is intended to produce this:
app2 ($CVSROOT/src/app2)
common ($CVSROOT/common)
include ($CVSROOT/common/include)
README ($CVSROOT/common/include/README,v)
c ($CVSROOT/common/include/c)
data ($CVSROOT/src/app2/data)
src ($CVSROOT)src/app2/src)
