Mail Archives: cygwin/2000/11/02/22:05:52
Weiqi Gao wrote:
>
> Hi,
>
> Is there are definitive resolution to the problems
> mentioned in this post from 20 Sept 2000:
> http://sources.redhat.com/ml/cygwin/2000-09/msg00714.html
> and its predecessors.
Yes. The latest release of cvs (as of Monday, Oct 30) fixed this
problem. See:
http://sources.redhat.com/ml/cygwin/2000-09/msg00745.html
for further details on the bug, and the following two messages for
details on the fix:
http://sources.redhat.com/ml/cygwin/2000-10/msg01533.html
http://sources.redhat.com/ml/cygwin/2000-10/msg01560.html
>
> I just installed the latest Cygwin release, and tried
> to set up a CVS repository on a shared drive (NTFS).
Okay, the original complaint concerned CVS repositories hosted on FAT
drives. Shared drives on a different computer (without running
:pserver:) were not the issue. However, I *think* the fix for
FAT-hosted repositories will also fix SMB-hosted repositories.
The problem was that the earlier CVS program used gdbm's emulation of
"ndbm-style" databases. Now, ndbm-style databases consist of two files
"foo.pag" and "foo.dir" which must remain in sync, but have different
contents. GDBM normally uses only a single file "foo". When running in
"ndbm-mode", it creates "foo.pag" with the same contents as "foo", but
also *HARDLINKS* "foo.dir" to "foo.pag".
HARDLINKS work when the drive is NTFS (NT Win2K only). When the drive
is FAT (OS=NT or W2K only) hardlinks are emulated with a copy (but this
doesn't solve the problem; the timestamps are different so you couldn't
host a repository on FAT drives even under NT/W2K). However, on FAT
Win9x, hardlinks always fail. So, the creation of "foo.pag" (or
.#1029.pag) fails. I imagine that hardlink also works unpredictably on
shared drives, regardless of the host OS or filesystem.
So, in the past, you could only host a repository on NTFS, non-shared,
OS=NT/W2K. *Everything* else failed for one reason or another, because
of the hardlink/filecopy thing.
The new cvs uses gdbm (mostly) in its native mode -- without ndbm
dual-file emulation. One file. Not two files to keep in sync, no
hardlinks, filecopies, nada, nothing. (*) This fixes the problem on FAT
drives for NT/W2K; it has been reported that it fixes the problem on
Win9x. I think it will also fix the problem on shared drives, since it
eliminates the likely failure point: hardlinks are not used/required.
(*) One minor, niggling point. gdbm database "foo" is stored in the
file "foo". However, since the CVSROOT directory already contains a
file called "modules" but we also need a database called "modules" -- I
decided to explicitly call the database "modules.db". For consistency,
even though there is no conflicting "val-tags" file, the "val-tags"
database is similarly named "val-tags.db".
> I encountered the "Permission" problem on a ".#1036"
> file, just as mentioned in the posts.
>
> My questions are:
> 1) Could this be actually a permission problem? (I
> was logged in to NT not as an administrator. I have
> full permission to CVSROOT. I can do a cvs init on my
> C drive without any problems. I have the problem when
> I do cvs init on a shared drive, which is also NTFS.)
I don't think it's a permission problem. Explanation above.
>
> 2) If the failures are mere linking errors, would
> manually copy the files solve the problem?
No. The file access times must also remain identical always.
> 3) Is the problem a init time only problem? Would
> similar problems pop up six months from now, when I
> had a couple hundred files imported and modified and
> committed, and tagged, etc.?
No, unfortunately. modules.db (or modules.pag + modules.dir) and
val-tags.db (or val-tags.pag + val-tags.dir) are recreated everytime you
add/remove a module-alias in the "modules" textfile, or use a cvs
command with a '-r tagname' option. However, if you can get it to work
*once*, then you've proved that the currently understood bugs have been
fixed, as far as your configuration is concerned.
Noone can guarantee that another bug will not crop up. However, the
val-tags database can be completely deleted from an existing repository
with no ill-effects; the only thing stored there is a fast-lookup-table
which duplicates information stored in the rcs-style ,v files, anyway.
The modules.db is just a fast-lookup-table duplicating the information
stored in the "modules" flat-text file. So both, IMO, can be deleted
and recreated in a working CVS repository with no ill effects.
--Chuck
cygwin CVS maintainer
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -