Re: sync repositories

[Eric Siegerman]

On Fri, Aug 09, 2002 at 10:48:04AM -0700, Mike Ayers wrote:
> >>I have to sync two CVS repositories located on two non-
> >>connected networks.  (yep, this means tape/CDROM transports,
> >>I know it sounds silly).

This was discussed a couple of months ago, and a few approaches
were offered.

Now we have to do the same thing.  Not full synchronization,
actually -- every revision, log message, and tag replicated.  All
we really need is that two sites be able to work on the same
modules without stepping on each others' feet, and without being
able to share a CVS repo.

(We have to do it this way for political reasons, so digression
into why we "shouldn't" have to, or technical suggestions on how
to reduce it to a single repo, would NOT be helpful, i.e. I
already know about ssh.  I'm going to suggest BitKeeper, but I
very much doubt they'll go for it.  In short, I'm probably stuck
with disconnected CVS, whether I like it or not.  Bleah.)

So I'm wondering whether anyone managed to turn that old thread
into a concrete solution.



If not, I'd appreciate comments on the approach I suggested back
then -- actually a modification to something Paul Sander had
described.  Paul pointed out that my suggestion didn't meet the
original poster's needs.  True enough, and presumably because of
that, no further discussion of it took place ... but it does
appear to meet our, less stringent, needs; so a critique of it
from that perspective would be helpful.

Here's the original proposal:

On Mon, 19 Aug 2002 11:47:15 -0700, I wrote:
> On Fri, Aug 09, 2002 at 12:50:06PM -0700, Paul Sander wrote:
> > Each site owns its own trunk.  Each site creates a branch that is used for
> > importing from the other site(s); these branches map to the trunk(s) at the
> > remote site(s).  No local commits are permitted on the import branches.
> > Each site keeps a list of branches to export to the other site(s), and
> > tracks the latest exported versions on each export branch.
> > 
> > To send an update from a remote site, the latest exported versions table and
> > the export branch table are consulted, and all versions that have never
> > before been exported are packaged up and sent (and the tables are updated
> > as needed).  Tags are also sent out in an appropriate manner.
> > 
> > To receive an update, the received versions are checked into the import
> > branch(es) as needed, and the tags are translated accordingly.
> 
> I just had an eeevil thought.  You're gonna cringe, I know, but
> bear with me :-)
> 
> On system A, use a version of CVS which stores its metadata in
> subdirectories called "CVS_A"; on System B, store the metadata in
> "CVS_B".
> 
> Now, on System A, CVS won't recognize System B's metadata; it'll
> revision-control CVS_B/Entries etc. like any other files.  And
> vice versa.  Thus, one should just be able to keep ping-ponging a
> single sandbox back and forth between the two systems (via email,
> FTP, sneaker-net, whatever), and each system will use its own
> metadata to stash the new revisions in the right place.
> 
> The systems in question had better have the same line-ending
> conventions, of course...
> 
> Does anyone know whether CVS can still withstand having CVSADM
> and friends defined to different values, or has "CVS" gotten
> hard-coded anywhere?  (I know of one place; the ign_default
> string in src/ignore.c.  That'd have to have "CVS" removed, and
> CVSADM added dynamically to the default ignore list.)

And my answers to the criticisms Paul made at the time:
  - "I thought the idea here was to propogate version histories
    between multiple repositories, not to keep multiple sandboxes
    in synch.  The method you propose does the latter..."

    As mentioned above, true, but in our case that's enough.  I
    think.  Are there reasons it isn't, that I'm not seeing?


  - "... and doesn't accomodate local changes to both sandboxes.
    It also provides no means to transfer other stuff such as RCS
    states and tags."
    
    Every resync involves getting a tarball from the remote site,
    importing it to the remote-site branch, and then merging from
    there to the trunk.  That should handle local changes to both
    sandboxes.
    
    It should also handle the only RCS state I care about, i.e.
    "dead" :-)

    As I mentioned, I don't care about replicating tags.


Thanks in advance.

--

|  | /\
|-_|/  >   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".