Pierre Asselin <[EMAIL PROTECTED]> wrote in message news:<b1fdre$ick$[EMAIL PROTECTED]>... > In <[EMAIL PROTECTED]> [EMAIL PROTECTED] >(Phil Radcliffe) writes: > > >[ ... ] > >- if I cd into c:\tmp mkdir a directory called test1 and then do cvs > >checkout -d test test-corem then everything is fine - I get the > >expected files in c:\tmp\test1 and c:\tmp\test1\workflows > > Right. You should check out into an empty directory. > > > >- if however I cd into c:\tmp mkdir a directory test2, cd into test2 > >and mkdir a directory called workflows, the cd backup upto c:\tmp and > >issue cvs checkout -d test2 test-corem then I dont get the files in > >the workflows directory. > > Correct. Don't create the directory hierarchy, let cvs do it. You're taking > a chance even when you create the top-level test2/ directory. > > > Another warning, just in case I'm guessing correctly what you were going > to try next: If you plan to check out several modules like test-corem > and prod-corem to one and the same corem/ working directory, that won't > work! It is a fundamental limitation of cvs that all the files in a > sandbox directory must come from the same repository directory. If you > can't change your plans to live with that, you need a different tool. > Possibly Meta-CVS. (Kaz, is there a Windows client?)
Meta-CVS runs on Windows in the Cygwin environment. Obviously, you need to install the CVS package and it doesn't hurt to have some kind of text editor. ;) I have Cygwin binaries on the web page; to use these you just unpack the tarball relative to the root directory, and it sticks things in a few places in usr/local/*. Meta-CVS won't *quite* solve the above problem, however; that is to say, it also has the limitation that a directory comes from one repository (and you bet that checkout tests for this and refuses to check out over an existing sandbox). However, a Meta-CVS sandbox has an administrative file only at the top level. What this means is that inside *subdirectories* of the sandbox, you can check out other Meta-CVS sandboxes. A MCVS directory will be created at that level, and when you type mcvs commands at that level, or lower, the search for the MCVS directory will terminate there, because it proceeds from leaf to root. So what I'm saying is that your mcvs actions in the nested sandbox will be ``scoped'' to that sandbox. Files from the enclosing sandbox will appear to be local files that are not known to the enclosed sandbox. This trick is not possible in CVS, because it sticks admin directories at every level. However, you could patch CVS to rename those admin directories; the you could switch the context via some environment variable to say whether you want to talk to the nested CVS checkout or the enclosing one. Checking out into an existing local tree is fine in Meta-CVS by the way, with a few caveats: if some local files conflict, you are taken to an interactive error handler which lets you clobber the local files, or leave them alone (so they effectively become working edits relative to the repo). While this is superior to emitting ``move blah.c out of the way'' and aborting, it's not fine-grained enough. There is a TODO item to give the user the option of going through the conflicting files one by one and choose which way to clobber. If someone wants this badly enough, and know Lisp well, it's probably one hour away. Patches welcome. Speaking of nested sandboxes, I have vague plans to steal a Subversion feature: namely storing module definitions as special items in the mapping file. Module definitions would cause the recursive checking out of specified modules under specified directory names. It would not be implemented as a special property on a directory object, because Meta-CVS does not represent directory objects. However, modules could be simply represented as special items. Right now the only items are :FILE and :SYMLINK. This would add a third mapping item called :MODULE with its own properties. Modules would have to be handled specially on renaming; this is potentially a very tricky issue. You can't hard link to directories, but a workaround might be to check out the submodule under a cryptic directory in the MCVS directory, and then plant that submodule into your tree as a symbolic link to that thing. This way, for instance, if you do an update, and someone has removed a module, Meta-CVS doesn't have to blow that module away. It just blows away the symbolic link. This makes messy problems go away; because one sandbox doesn't really have the jurisdiction, so to speak, to blow away another. The ``mcvs purge'' command could be extended to hunt down submodules that are not symlinked from your sandbox and remove them, putting control into the user's hands. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
