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. [EMAIL PROTECTED] | | / The acronym for "the powers that be" differs by only one letter from that for "the pointy-haired boss". _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs