When working with local repository copies, the following situation
occurs (with the latest CVS 1.10.8.1 version as picked up via anon-cvs):
1. The repository was copied from the remote site to the local site
2. The working directory was checked out from the local site
3. Some files in the top-level of the working directory are edited
4. Some files in sub-directories of the working directory are edited
5. A commit has to be performed to the original repository, so
a "cvs -d <path-to-original-repository> commit ..." is used from the
top-level.
The effect now is that CVS _DOES_ pick up all modified files for creating the
file list for the log message (I can see it in the editor on the CVS: lines),
but the commit _DOES NOT_ pick them up. Only the files from all subdirectories
are comitted. All top-level files still are untouched. If I now perform
exactly the same commit command again, the remaining modified files are _NOW_
picked up and comitted.
I poked around in the source and found a few places were CVS checks such
situations (especially in recurse.c). The source comments also have a few
hints about this nasty behaviour. But I've not really found the code location
which is definitely responsible for this behaviour.
So, I've the following questions to the CVS gurus:
1. What is the real intention behind this nasty and IMHO inconsistent
behaviour for "cvs commit", when the global option -d is used? The code
comments speak about spurious conflicts and such things at one position and
at the same time questions the behaviour at other positions.
2. I want to workaround this nasty behaviour by forcing CVS to always
pick up also files in the top-level on "cvs -d ... commit". Where is
_exactly_ the piece of code which controls this. Please don't say "just
look in commit.c and recurse.c". I've already fiddled around with CVS'
internals here. But I still was unable to force CVS to always pick up all
files. So, which piece of code has to be patched?
Please sched some light on this problem. Thanks.
Greetings,
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
