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