RE: Upcoming dynamic CVSADM patch - 1 workspace 1 repositories for each file
Hi, would this also solve the following problem? I maintain a software library, part of which is public domain, part is private. I do have the private files in separate subdirectories. In the near future, the public part of the CVS archive will go on sourceforge or savannah. I obviously don't want the private part to be on there (even if it would be possible to set access permissions). I thought that one possible solution for this is to have the subdirectories use a different CVS archive, which this patch could presumably do. Right or wrong? Or is there a simpler way (that doesn't need the patch)? Thanks a lot, Kris Thielemans (kris.thielemans at ic.ac.uk) Imaging Research Solutions Ltd Cyclotron Building Hammersmith Hospital Du Cane Road London W12 ONN, United Kingdom web site address: http://www.irsl.org/~kris ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Upcoming dynamic CVSADM patch - 1 workspace 1 repositories for each file
On Wed, Oct 30, 2002 at 03:05:48PM -, Kris Thielemans wrote: I maintain a software library, part of which is public domain, part is private. [the public parts will soon move to sourceforge; private parts must remain in a local repo] I thought that one possible solution for this is to have the subdirectories use a different CVS archive Yes. which this patch could presumably do. Right or wrong? Or is there a simpler way (that doesn't need the patch)? The dynamic-CVSADM patch doesn't apply to your situation; it addresses a different (though somewhat similar-looking) issue. I'm pretty sure you can get away with stitching together your sandbox out of directories that are backed by different repo's: sandbox/ is backed by some directory on Sourceforge sandbox/private/ is backed by some directory within your local repo (pretty sure means that I think I once did that kind of thing, but can't recall for sure). If this does indeed work, you can set it up by doing the right cvs co commands in the right places. (But you'll have to do so by hand, or script it yourself; I imagine that it goes beyond what you can express in CVSROOT/modules.) After that, CVS commands should just work, recursing as usual and hitting the two repo's as appropriate. Failing that, you can always stitch the sandbox together using symlinks instead; but then you'll have to issue twice any CVS command that's supposed to apply to both the public and private halves of your sandbox. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The acronym for the powers that be differs by only one letter from that for the pointy-haired boss. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Upcoming dynamic CVSADM patch - 1 workspace 1 repositories for each file
On Mon, Oct 28, 2002 at 03:43:04PM -0800, Andy Glew wrote: I originally posted this to the newsgroup fa.info-cvs, but it appears to be oneway. Pardon if this is a repost. [It isn't. But only the (sparsely-tagged) HTML was readable in my plain-text mail client; the text version was all run together on one line.] This enhancement allows the CVSADM directory to be specified. In priority order, from lowest to highest: Yes, please! This will help greatly with my current disconnected-repo situation. default CVS environment variable CVSADM --CVSADM command line argument. That last includes .cvsrc support, I hope. WISH? / DESIRABLE FEATURE? It would be nice if cvs ci could be directed to check into all repositories in one command. That's trivially shell-scriptable: for cvsadm in CVS*; do # Note that -d cvsroot-override is not required cvs --CVSADM $cvsadm ci done So why bother including it in CVS proper? (N.B: both the script and the built-in implementation require some naming convention for cvsadm subdirectories, so that doesn't offer any reason to choose one approach over the other.) WISH? / DESIRABLE FEATURE? It might be nice if cvs update could check out from all repositories and automatically merge. After all, the separate repositories are really just a differet physical implementation of branches. If all == 2, perhaps. But again, isn't that also scriptable easily enough? For more than two repo's, I think this would be overwhelmingly confusing -- though no more or less so than an (N2)-way merge between conventional CVS branches. I've often enough found myself with the task of merging N divergent versions of the same stuff (source trees, contact lists, whatever). I've almost(?) always ended up simplifying the problem to a series of two-way merges, by: - picking by visual inspection one version that looks closest to the desired final state, and designating that as good - going through the other versions, one at a time, doing a merge between that and the good one I think that, unless most or all of the merges end up being trivial, this is the only way to keep such a task manageable. Reserved checkouts tetatively updating a version number would not have the make problem. Well, if there were reserved checkouts in the first place :-) For all my objections to the wish list, I think the basic idea could be really useful in some unfortunate situations -- like the one on my current project. Andy, I could really use those patches, if they're in any shape to distribute. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The acronym for the powers that be differs by only one letter from that for the pointy-haired boss. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Upcoming dynamic CVSADM patch - 1 workspace 1 repositories for each file
I originally posted this to the newsgroup fa.info-cvs, but it appears to be oneway.Pardon if this is a repost.BRIEF
=
I invite discussion of a patch that I have made
to CVS, but not yet released, that provides what
I call "dynamic CVSADM" - the ability to specify
via command line or environment variable the name
of the CVSADM directory that links the workspace
to the repository.
In particular, this allows a single workspace
to be linked to two or more CVS repositories,
and checkins and updates to be made to both
constantly.
cvs ci
will use the repository specified in w/CVS
cvs --CVSADM CVS.alternative ci
will use the repository specified in w/CVS.alternative
I explain more below, in the HOWTO I have written to accompany it.
I've asked about this on the list before,
and have wanted this for years.
I have hacked it with scripts in the past,
but finally I got frustrated enough to
modify the CVS C source. It was
an extremely clean modification.
I haven't noticed any gotchas in coding or
using it.
I am using this for my own personal libraries
that I use both at work (with work CVS repository)
and at home. I plan to use it for a while and,
if happy enough, to make it available to others.
Dynamic CVSADM plus multiple repositories
=
CVS hack
Written by Andy Glew circa October 24, 2002.
What the workspace CVSADM directory is
--
The CVSADM directory lives in each directory of the workspace, and
links the workspace to the repository. By default it is called CVS,
and contains files such as CVS/Root, CVS/Repository, and CVS/Entries,
and possibly other files.
This enhancement allows the CVSADM directory to be specified.
In priority order, from lowest to highest:
default "CVS"
environment variable "CVSADM"
--CVSADM command line argument.
This allows a given workspace to be linked to more than one CVS repository.
Why you would want that will be explained below.
Briefly, if in a workspace w, with two CVSADM directories
- the default w/CVS, and an alternative, w/CVS.alternative
E.g.
cvs update
will use the repository specified in w/CVS
cvs --CVSADM CVS.alternative
will use the repository specified in w/CVS.alternative
Why would you want 1 Workspace : Multiple Repositories?
---
It frequently arises that a particular piece of source code lives in
two (or more) repositories. Typically this happens because of
political or organizational boundaries: one project or company may
want to have control over all the source code in the libraries it
uses, and so may want to place those libraries in its repository,
while the libraries may have an official "home" somewhere else.
Similarly, the library may not want to see all the various
project tags, etc.
E.g. I (Andy Glew) have a large library of personal tools, libag. I
like using these on projects at work. However, my employer (AMD) wants
to keep its own copy of the source for the libraries - it does not
want to check them out from my repository, on my home computer.
Conversely, I want to be able to propagate updates from my home system
to the projects using the libraries.
By arranging for two linking CVSADM directories in a workspace,
I can choose which repository I wish to check in.
Other Ways to do the Same Thing
---
If you don't "synchronize" two repositories often, a combination of
import, export, and so-called vendor branches may work. However, my
experience has shown that this is inconvenient; I often forget to
update one of the repositories, leading to divergences.
You can manually copy, rename, or symlink the CVSADM directory
"CVS" inside and between workspaces. This is prone to error;
it is better to integrate.
How to Arrange for a Workspace Linked to Multiple Repositories?
---
(0) As mentioned above, you can manually copy and symlink CVSADM directories.
(1) If you have a library foo in repo1, and you want to check it into repo2:
cvs -d repo1 --CVSADM CVS.repo1 co foo
this will give you CVSADM directories linked
cd foo
cvs -d repo2 import foo foo-from-repo1 foo-from-repo1--DATE
The import command will place the module in repo2.
Checking in the alternate CVS.repo1 files?
--
You may be surprised that it imports the CVSADM files,
such as CVS.repo1/{Root,Repository,Entries}.
You can direct import not to import the CVS.repo1 files
by using the CVSIGNORE environment variable
or the -I (ignore) option to import.
However, it is actually quite useful to check the CVS.repo1
files into repo2. It basically documents where the original
source comes from, and allows other checkouts from repo2
to propagate their changes back to repo1.
The import does not check out the files from repo2.
To do
