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 [EMAIL PROTECTED] > > 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
