[Top][All Lists]

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

RE: sync repositories

From: Zieg, Mark
Subject: RE: sync repositories
Date: Fri, 09 Aug 2002 15:15:10 -0400

> > I have to sync two CVS repositories located on two non-
> > connected networks.  
> If you MUST do this (and it is almost certain that you do
> not need to, but that's another story)

I assume that you've never had to develop under DOD-enforced contract
requirements, or you wouldn't have written that.  Anyway, the justification
for the requirement is irrelevant; take it as a given that such requirements
do exist from time to time.  Treat it as an additional challenge on which to
flex your creativity :-)

> Please examine two messages from the archives of this
> list entitled "How I repaired my repository" 

Here are the links, for anyone who had trouble finding the archives (I

> Note that CVS was not designed for multiple repository operation.

Duly noted.  For the record, does anyone have a suggestion for an
open-source CM tool which _is_ designed for use in this manner?  Again,
assuming that the repositories must be on physically disjunct networks, such
that any synchronization would have to be via hand-ported media in
human-readable format (ie, diff patches on CD-R, etc).

I don't debate that this is stretching the intended functionality of CVS,
but I would nonetheless prefer finding a way to use an open-source CM tool
such as CVS than rely on a proprietary commercial vendor "solution".

I'm still working on a satisfactory algorithm for this, but my current
thinking bends toward a classic master-slave synchronization effort, ie
treat one repository as the "master" (main trunk) as the other as a slave
("branch").  Then all we have to do is merge the branch back into the main
trunk, then re-spawn a fresh copy of the master to start a new branch.

(Although I'm using the term "branch", I'm not currently planning to make
use of actual CVS branches...should I?  Is there room for an efficient
optimization by using that feature?)

This visualizes my approach:

(RepoA and RepoB are Repositories on Networks NetA and NetB.)

foo.c @  1.1
foo.c -> 1.2
foo.c -> 1.3

>>> copy RepoA to RepoB
    | \
    |   \
    |     \
    |       \
    |         \
    |           \
    \/           _|

RepoA           RepoB
-------------   ------------
foo.c @  1.3  | foo.c @  1.3
foo.c -> 1.4  |
              | foo.c -> 1.4 (alpha mod)
foo.c -> 1.5  |
foo.c -> 1.6  |
              | foo.c -> 1.5 (bravo mod)
foo.c -> 1.7  |

>>> time to sync changes!

              | collect all diffs
              |    to all files
              |    (2 diffs for foo.c),
             <--  transport to RepoA
foreach file, |
foreach diff, |
apply & comm. |
foo.c -> 1.8  |
foo.c -> 1.9  |
foo.c now has |
  alpha and   |
  bravo mods  |
>>> copy RepoA to RepoB
    | \
    |   \
    |     \
    |       \
    |         \
    |           \
    \/           _|

RepoA           RepoB
-------------   ------------
foo.c @  1.9  | foo.c @  1.9

...of course, this is of less help to Piet, who already has split
repositories, and may or may not have a common base version from which to
apply a "merge".  However, I have the advantage of having not yet split my
development, so I still have a chance to plan things out and initialize the
sets accordingly...

I haven't worked out the mechanics of extracting the diffs, but with a bit
of Perl and what-not it shouldn't be difficult to preserve log messages.  I
thought about trying to override the author/date attributes of the diffs,
but even if that were feasible and convenient, it would be a little weird if
"rev 1.8" seemed to be datestamped before "1.7"...therefore, I'll probably
just append the original (RepoB) author and date onto the log message as
each diff is re-applied.

Comments vigorously solicited!

Mark Zieg

reply via email to

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