Re: Assumption added between 1.11.9 and 1.11.16 ?

[Adrian Pepper]

> From bug-cvs-bounces+arpepper=math.uwaterloo.ca@gnu.org Mon Sep  6 03:36:02 
> 2004
> To: Adrian Pepper <arpepper@cs.uwaterloo.ca>
> From: "Mark D. Baushke" <mdb@cvshome.org>
> Date: Mon, 06 Sep 2004 00:34:18 -0700
> Cc: bug-cvs@gnu.org
> Subject: Re: Assumption added between 1.11.9 and 1.11.16 ? 
> 
> Hi Adrian,
> 
> My recollection is that the change you are mentioned was added to
> deal with symlinks in the cvsroot path. I believe you will find
> the root of the thread that discussed here:
> 
>     http://lists.gnu.org/archive/html/bug-cvs/2003-09/msg00168.html
> 
> If you have a 'better' solution than the current use of xgetwd(), please
> feel free to forward a patch. I doubt it will be fixed without one as
> most folks apparently do not run their repositories with the same
> permissions you are using.
> 
> That said, I have not considered the logic path closely recently, but
> you may want to consider the use of CVSROOT/config using a
> LockDir=/path/name to see if that will help you. You could give
> different permissions to the LockDir than the normal repository and may
> find more joy in it.

If there was such a natural place to have lockdirs, it presumably might
be a natural place to put the repositories, too.  Finding such a "third
party" location for students repositories (perhaps a temp-type dir
subject to same quota restrictions) seems like a possible solution, but
it is still accommodating an essentially unannounced change in
behaviour of software.  But I guess your statement means that it's when
the repository functions as  a lock dir that determining the path
matters (and is done).

We have always had symlinks to the repositories, and I wonder if users
had run into the necessity to reference via the real path.
For historical reasons, ~user/.cvsroot and $HOME were both the
real path, even though one could argue that a symlinked version
should be used instead ( /u/arpepper -> /u5/arpepper ) so I suppose
that was working as much by luck as by judgement.  Or perhaps by
tradition.

(Note around here we use "absolute path" to mean "real path", so I may
occasionally slip up and say "absolute".  But I can see that "absolute"
can mean merely mean "starting with /").

>       -- Mark
> 
> PS: It is "Labor Day" today in the US, don't assume anyone in the US
> will be doing much e-mail...

Reading the thread, it looks like the correct solution would have been
to implement a good version of realpath as part of cvs, rather than a
dubious one using chdir and getcwd.

It is not necessary to be able to read (as opposed to merely search,
i.e.  traverse) all elements of a given path in order to determine the
(strictly-speaking an) equivalent real path, so long as you are given,
or can infer by getcwd, an absolute (i.e. root-relative) path to begin
with.  Sorry I missed making that/this observation back in September.
Which revision implemented the change, and how would I find that out
for myself?

Users (instructors) are now agitating to put back 1.11.9, which, of
course, you would say was extremely inadvisable.

It sure seems to me like this was a feature change.

Reading some of the old messages, it looks like it was planned to have
1.12 use a "canonicalize" function to do this?  Did that happen? Does
that handle more search-only paths?  If so, why not have 1.11 use that
function?  Hmm.  Scanning the 1.12 source it isn't obvious to me that
any such function was used.  I should test 1.12, too, but if the
courses began using that, then they'd be potentially subject to even
more unexpected changes.

We have a program and corresponding routines we use around here
(called, surprisingly enough "absolute"), but straight off, looking
at the function definition it uses an output buffer of undeclared
size...


Adrian Pepper
arpepper@cs.uwaterloo.ca