info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emptydir change from version 1.11


From: Larry Jones
Subject: Re: Emptydir change from version 1.11
Date: Mon, 17 Mar 2003 11:10:17 -0500 (EST)

Jens Altfelder writes:
> 
> it seems that starting from version 1.11.1, directories which don't
> exist on the server (which will be e.g. generated when using a line like
> 
> "ModuleA -d DirA/DirB/DirC/DirD   DirInRepos"
> 
> in the Modules file) no longer have the "Repository" file in the "CVS"
> directory point to the "$CVSROOT/CVSROOT/Emptydir" directory, but
> instead to the "$CVSROOT" directory itself.

That is not correct.  To understand what's going on, let's look at two
slightly more complicated module definitions:

        ModuleA -d DirA/DirB                    RepoX/RepoY
        ModuleB -d DirA/DirB/DirC/DirD/DirE     RepoX/RepoY

Now, when you checkout ModuleA, the CVS/Repository file in DirA points
to $CVSROOT/RepoX and DirA/DirB points to $CVSROOT/RepoX/RepoY.  I hope
everyone agrees that that makes sense and is the right thing to do. 
Under the old scheme, DirA pointed to Emptydir instead and that caused
no end of confusion since people expected it to be mapped to the
corresponding repository directory.

The problem is that the mapping for ModuleB is not so obvious.  What the
current scheme does is:

        DirA                            $CVSROOT/Emptydir
        DirA/DirB                       $CVSROOT/Emptydir
        DirA/DirB/DirC                  $CVSROOT/.
        DirA/DirB/DirC/DirD             $CVSROOT/Repox
        DirA/DirB/DirC/DirD/DirE        $CVSROOT/Repox/RepoY

That is, it proceeds bottom-up matching working directories to
repository directories until it hits the root of the repository, at
which time it starts mapping to Emptydir.  The first two and last two
mappings seem quite sensible to me, only the middle mapping (to the
repository root directory) seems questionable.  Does anyone disagree? 
The change to implement this (which Mark posted) mainly consisted of
removing special-case code in favor of more general code that already
existed.  This mapping simply happens to be what that existing code did;
I didn't see any clear need to change it.  If others do, I'm open to a
patch to change this particular case, provided it doesn't break anything
else.

-Larry Jones

Whatever it is, it's driving me crazy! -- Calvin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]