Re: Upcoming dynamic CVSADM patch - 1 workspace >1 repositories for each file

[Eric Siegerman]

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 (N>2)-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.        address@hidden
|  |  /
The acronym for "the powers that be" differs by only one letter
from that for "the pointy-haired boss".