Derek Robert Price <[EMAIL PROTECTED]> writes: > You already pointed out the solution yourself: > > local1 &local2 > local2 &local3 > local3 -d dir1 modules1/dir1 > > And so on. Next time, please RTFM <http://cvshome.org/docs/manual>.
Sorry, I read the document carefully but the structure of my modules is so complex that the 'ampersand' alias is not usable in my 'real life' situation. OK your example works well. With only one module and one directory. Why the ampersand is not enough for me ? Because, the project having that issue uses many modules like the following example can give you a short guess: my-dir1 -d local1/local2/local3/dir1 module1/dir1 my-dir2 -d local1/local2/local3/dir2 module1/dir2 my-dir3 -d local1/local2/dir3 module1/dir3 my-dir4 -d local1/local2/local4/dir4 module1/dir4 So I'm stuck. The way to work around the local mapping decided by CVS is to organize better the modules on the server... (to avoid the update -d side-effect <<get complete 'module1' content in 'local3', 'local2' and 'local4'>>) But I personnally think that the following module description my-dir1 -d local1/local2/local3/dir1 module1/dir1 should create a working copy with local1/CVS/Repository = CVSROOT/Emptydir local1/local2/CVS/Repository = CVSROOT/Emptydir local1/local2/local3/CVS/Repository = CVSROOT/Emptydir local1/local2/local3/dir1/CVS/Repository = module1/dir1 (and not strange things like '.' in local2 and 'module1' in local3) Is there any piece of "internals" documentation that explain how (and why) CVS decides to map a working copy directory on a module ? I'm really curious to understand that mechanism better. And eventually to know why 1.11 and 1.11.1p1 releases work differently. Best regards, -- Yves Martin _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs