[Top][All Lists]

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

Re: problems with cvs checkout -d on xp

From: Kaz Kylheku
Subject: Re: problems with cvs checkout -d on xp
Date: 1 Feb 2003 18:51:49 -0800

Pierre Asselin <address@hidden> wrote in message news:<address@hidden>...
> In <address@hidden> address@hidden (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.

reply via email to

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