Re: cvs has problems using LockDir when CVSROOT holds a symlink

[Derek Robert Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry Jones wrote:

|Derek Robert Price writes [quoting Mark]:
|
|>| It is also interesting that the RCS File: is 'more correct' in the
|>|1.12.x version as it uses the symlink name rather than the canonical
|>|name as a prefix in the path to the RCS,v filename.
|>
|>I'm not sure I agree that this is more correct, actually.
|
|
|I'm quite sure that I disagree.  Anything visible to the user should use
|the user's specified path.  A bit of syntactical cleaning up (like
|removing extra slashes, /./, etc.) is OK, but not expanding symlinks.


Well, having the RCS archive contain the last symlink to a root the file
was written with may be a little better in that it gets this correct in
more cases.  I suspect that an RCS file should have the canonical root
and then any CVS command that prints out the value of the RCS filename
should sub in the user specified root.

|>Actually, running sanity.sh with a -l argument appears to do this on
|>1.12.x.  I didn't recall leaving that hack there.
|
|
|-l tests where the last component of the specified repository is a
|symlink; it might also be useful to test the case where the symlink
|appears at a higher level in the path.


Did you want both tested, or would you consider it sufficient to test a
single symlinked root with multiple symlinks in the path?  Perhaps
multiple indirections?  Since the current code never refers to xgetcwd
but builds the path as it walks it, I thought a single link sufficient,
but I suppose I may have missed something.

|>|I am all for centralizing code that need not be duplicated and
|>|maintained in multiple filesubr.c versions.
|
|
|I think we need to rethink the organization of filesubr.c -- there is a
|lot of duplicated code that should be consolidated.


This is fair enough.  I like the idea of moving as much as possible into
portable GNULIB-style always-use or AC_REPLACE_FUNC replacement
functions.  That should be possible for most of the type of thing I
recall being in filesubr.c but I haven't been through it in awhile.  I
know I've had to move a function or two from there to src/subr.c in the
past, I think because I misplaced the function in filesubr.c originally,
though.

I just scanned GNULIB for a few of the functions I found in filesubr.c.
It looks like there is a copy-file module and the GNULIB file-type
module, which converts a struct stat into a readable english string
depends only on <sys/types.h> and <sys/stat.h> to do its type
determination, so we should be able to depend on the same features since
we are following their C89 requirements.

GNULIB also has a mkdir module we've already adopted but which looks
like we might want to import a fresh copy of.

Once we have mkdir, I expect the make_directories fuction (like mkdir
- -p) won't need to be system specific anymore.  The same goes for
mkdir_if_needed.

For chmod, there's the "modechange" GNULIB module.  For rename, the
GNULIB "rename" module.

For unlink, my man page says that unlink conforms to the SVr4, SVID,
POSIX, X/OPEN, & 4.3BSD specifications.  Larry, can you tell me if this
is a function we can count on?  If we can I think that will take care of
unlink_file_dir and deep_remove_dir.

I'm not sure about block_read, but if we figure it out, xcmp should fall
in line.

xreadlink has a GNULIB module of the same name and we've already been
discussing coreutils "canonicalize.c" for xresolvepath.

last_component has a corresponding "basename" GNULIB module.

I'm not sure what to do about get_homedir, but, in theory at least,
strcat_filename_onto_homedir could be replaced with GNULIB's path-concat
module, though I've never really called GNULIB on their VMS support yet,
so we might have to work with them a bit on this one.  I think some
weird handling of homedir + path concatenation on VMS was the
inspiration for this function.

For expand-wild, we'd have a choice between fnmatch-gnu (wildcard
matching with GNU extensions) or fnmatch-posix (the POSIX version).  The
GNU version of fnmatch includes an optional FNM_CASEFOLD option to
ignore case, which would take care of cvs_casecmp.

And that's it.  It looks like we could take care of most of these just
with the GNULIB replacements.  It is worth noting that someone will
probably need to ensure that the CVS error function is moved to ccvs/lib
and made compatible with the GNULIB API before we can do all of this (it
is possible that we could do most of it).  I've been putting off
incorporation of several GNULIB modules which depend on the GNULIB error
module because the GNULIB error only prints to stderr and I haven't had
time to verify that CVS's error.c will do the right thing in all cases
where it might be called by GNULIB modules.  I think there are at least
some existing issues in error with attempting to allocate memory when
called because one of the memory allocation routines couldn't allocate
memory that should be dealt with while we are at it, but it looks like
the GNULIB error suffers from the same limitation and though this would
be nice, it probably isn't vital.

Derek

- --
~                *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
- --
Since English is a mess, it maps well onto the problem space,
which is also a mess, which we call reality.

   - Larry Wall
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/ce0wLD1OTBfyMaQRAkDDAKDKfM5p6LESB6MlzrTe1lco4zSrbACdETyR
JrIMtFuoIHb0GdSP+tJZhro=
=i77E
-----END PGP SIGNATURE-----