[ On Thursday, March 16, 2000 at 23:11:55 (-0600), Michael Gersten wrote: ]
> Subject: Synchronizing across multiple repositories: An idea...
>
> But why the constant copy?
>
> CVS stores all the information about where the repository is in CVS/.
>
> Why not permit multiple repository directories, CVS/, CVS1/, CVS2/,
> etc.
I thought of something similar to that once too, and even experimented
with it by writing a script that could implement a "swap" of the CVS
administrative directories.
It worked OK, but in the end it didn't give *me* any real benefits --
you can't copy the actual version history this way -- only the chunks of
changes.
With simultaneous support for multiple repositories as you suggest it
might make it easier to at least be able to examine the log messages
from CVS1/ while checking changes into CVS/2, etc. (and thus it would be
possible to write a wrapper that could automate this).
I suppose it could also be of some benefit to someone working in an
environment where connectivity to the main repository is only
occasional.
It might be the best solution for those who want to be able to track
intermediate changes while working on a larger change where only the
final result will be checked into the official repository. Currently I
do know some people who use RCS or SCCS locally to do this. It's sort
of like having really and truly private developer "branches"....
I have to wonder though if this kind of feature is general enough to
consider. I.e. just how hard is it to copy files from one workspace to
another? Is my original experiment with simply swapping the contents of
the CVS admin directories sufficient to achieve the desired effect? Is
it better to copy the source files or the CVS admin files?
> In any event, how hard would it be to add a left side of "-r<n>" for
> repository n (I don't think that option is take, I can't think of ever
> using it)?
Well, wandering off into the blue sky of speculation I would make the
following comments:
I'm not sure it's a good idea to totally abstract the identification of
the remote repository with an index number like that.
I'd also like to see the proliferation of administrative directories
completely avoided -- i.e. stuff everything to do with optional
repositories into one "CVS" directory.
Perhaps if '-d' were simply extended to optionally take just the
hostname of the desired repository, in which case it would examine all
of the optional CVS/Root* files and choose the matching one for the
current operation.
There should maybe be an option to switch the default repository between
those currently in use.
The obvious way to introduce a "new" repository to an existing directory
would be to simply do so by making a checkout with a different CVSROOT
add that new CVSROOT as an optional repository for the workspace. This
would upset anyone who uses 'cvs -d newrepo checkout' expecting it to
globally change the current repository.
There are some major issues to think much harder on of course. The
first that comes to mind is how to handle cases where different
sub-directories in a given workspace are using different optional
repositories, etc. There's already some related uglyness in the way CVS
currently behaves, so adding even more isn't very appealing.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
