info-cvs
[Top][All Lists]
Advanced

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

RE: sync repositories


From: Paul Sander
Subject: RE: sync repositories
Date: Fri, 9 Aug 2002 12:50:06 -0700

There has been a fair amount of discussion about this topic in the past,
and I believe that someone has a working implementation that follows this
model:

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.

Note that all sites must perform periodic cross-merges to keep their sources
synchronized, but that is the same in practice as having features branches
in a single repository.

--- Forwarded mail from address@hidden

> > 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
did)...

http://mail.gnu.org/pipermail/info-cvs/2002-July/029157.html
http://mail.gnu.org/pipermail/info-cvs/2002-July/029158.html

> 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.)

RepoA
-------------
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
              |
              V

...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.

--- End of forwarded message from address@hidden




reply via email to

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