After re-reading the question and my answer, I realized I answered the wrong
quesion. However, my argument holds even if the "common" tree is completely
empty of source files (e.g. right after a project is created). After doing a
checkout, if the CVS admin directories are not created then adds store the
new source files in the wrong place, under the app1 tree after creating
unwanted directories.
This can be worked around by creating .cvsignore files, of course. But
it's an annoying workaround because it requires me to use a feature I
don't otherwise need or want.
But since a workaround is available (however rediculous), I'm willing to
change my opinion from "strongly disagree" to "disagree".
>--- Forwarded mail from [EMAIL PROTECTED]
>>--- 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)
>--- End of forwarded message from [EMAIL PROTECTED]
