[Top][All Lists]

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

Upcoming dynamic CVSADM patch - 1 workspace >1 repositories for each fil

From: Andy Glew
Subject: Upcoming dynamic CVSADM patch - 1 workspace >1 repositories for each file
Date: Mon, 28 Oct 2002 15:43:04 -0800 (PST)

I originally posted this to the newsgroup, but it appears to be oneway.
Pardon if this is a repost.

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

	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

	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 that, do

    cd ..
    rm -rf foo             // remove the import tree
    cvs -d repo2 co foo    // checkout a workspace tree

If you have checked in the CVS.repo1 files as above,
you will then have a workspace tree that contains two
sets of CVSADM files: one, the plain old "CVS" files,
that corresponds to repo2, and the other, CVS.repo1,
that corresponds to the original repository repo1.
You can then use the CVSADM command line option
or environment variable to indicate which repository to use.

Usage Model

After having created a workspace linked to two or more repositories
as above, typically work with one (the default CVS) more often,
and occasionally check into the other (CVS.repo1, etc.).
Conversely for propagating updates.

     It would be nice if cvs ci could be directed to 
     check into all repositories in one command.

     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.

   cvs co logically applies to one repo at a time
   ditto cvs tag, etc. 

   RCS Keywords

   The use of RCS keywords such as Header (within dollar signs)
   is nice, because it makes files identify themselves and makes
   it possible to trace them.

   Unfortunately, RCS keywords cause gratuitous diff problems in CVS,
   particular when doing things that involve copying files between
   branches.  Also, RCS keywords can cause unnecessary recompiles
   in make, as when a file is modified, builds, checked in
   and gets rebuilt because the RCS keyword changed, even though
   none of the file did.

   The dynamic CVSADM feature increases the frequency of this 
   happening, since every time you bounce from one repository
   to another a keyword induced diff will occur.

   Grudging recommendation: remove RCS keywords.
      It'll make your builds faster and give you less CVS hassle.

   WISH for CVS:
   	I wish CVS could be directed to ignore diffs in the

   WISH about avoiding unnecessary remakes
 	Reserved checkouts tetatively updating a version number
	would not have the make problem.


Coding and Testing

The existing CVS testsuite,, was extended
to know about the CVSADM environment variable.
The entire test is rerun with an alternative CVSADM setting.
The command line option is not separately tested,
although was tested by hand.

Briefly, the code changes were fairly easy, because
#define macros were already used for the strings.
	#define CVSADM "CVS"
was changed to
	#define CVSADM get_CVSADM()
and a function
        char* get_CVSADM() 
that returned a static string was defined.

	ISSUE: returning a static string is bad form.
	In C++ would have returned a string by value.

The appropriate changes to the command line and environment variable
setup were made.
I haven't changed the texinfo yet, but will soon.

Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
reply via email to

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