Just to save me from re-inventing the wheel, can you forward me the "swap the admin
directories" scripts?
Thanks.
Michael
"Greg A. Woods" wrote:
>
> [ 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]>
