Re: sync repositories
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
Re: sync repositories
On Thu, 10 Oct 2002, Eric Siegerman wrote: 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.) In Meta-CVS, you can track third party code on any branch quite easily. This has nothing to do with CVS vendor branching; it is not based on the cvs import command. Here is the rundown: cd snapshot mcvs grab -r branch-name module-name # We now have a working copy checked out to branch-name. # The changes that will bring the snapshot into the branch look # like ordinary local edits that can be diffed, modified and # committed. mcvs ci # commit; third-party snapshot is now in the branch mcvs sw # switch to main trunk mcvs merge branch-name # merge the branch mcvs ci # commit, done I would give each time their own repository, and have them use a branch to track code snapshots from the other team. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sync repositories
I have been working on a pair of Ant tasks that support merging code from N number of sub-development groups with their own source trees into the main branch of a cvs repository. How the remote sources are being stored is irrelevant to my custom Ant tasks. (In my case the other team is using the ENVY repository built into VAJ.) From an overall standpoint it is important that the entire ant build script has some way of obtaining the external source tree from each external sub-development group and updating each external sub-development group's SCM repository. I am more than happy to share the workload of developing the ant tasks with another developer outside my company. In fact I would like to submit the new tasks to the Jakarta project when they are complete. The vast majority of the work is already done but there is still several days of work to be done before the tasks are complete. Unfortunately I only have time to work on the tasks during short stints between iterations of the main project my group is working on. Be warned that writting custom ant tasks as well as understanding the tricky details of the problem that pop up is not for the faint of heart. Its not rocket science, but it is a bit tricky. I expect anyone new to the problem will take a day or more just to become aclimated to everything that is going on. Rather than regurgitate all the nasty details I ask that you browse the archives of the cvs (and cvsnt) user and ant development lists for my postings. They are all made under this email address:([EMAIL PROTECTED];[EMAIL PROTECTED]) or [EMAIL PROTECTED] If there is a better way to do all of this without writing custom ant tasks please let me know! James Lee Carpenter Software Engineer Household Technical Services 6602 Convoy Court San Diego, CA 92111 ph: 858-609-2461 email: [EMAIL PROTECTED] Eric Siegerman To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Sent by:Subject: Re: sync repositories [EMAIL PROTECTED] g 10/10/2002 12:57 PM 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
Re: sync repositories
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.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Anyone who swims with the current will reach the big music steamship; whoever swims against the current will perhaps reach the source. - Paul Schneider-Esleben ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sync repositories
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, and doesn't accomodate local changes to both sandboxes. It also provides no means to transfer other stuff such as RCS states and tags. --- Forwarded mail from [EMAIL PROTECTED] 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.) --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sync repositories
On Mon, Aug 19, 2002 at 12:12:45PM -0700, Paul Sander wrote: 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, and doesn't accomodate local changes to both sandboxes. It also provides no means to transfer other stuff such as RCS states and tags. Oops, you're right! But it syncs them between two disconnected repo's, which makes it a partial solution -- perhaps good enough for some folks. It doesn't sync tags or intermediate revisions. Re. local changes to both sandboxes: why not? If you mean by this a file that's been changed in both places, the merge from branch to trunk (after propagating the changes to the other repo) will handle that. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Anyone who swims with the current will reach the big music steamship; whoever swims against the current will perhaps reach the source. - Paul Schneider-Esleben ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: sync repositories
Hello all, I've been following this discussion with some interest, as I have more or less the same problem as mr Verhoeven. It seems, though, that there is no real solution to this problem without planning ahead before you get into trouble with the two separate repositories? I kinda liked the idea of making a branch out of one of the two repositories, but I'm wondering how that would work internally (in the repository files) as what I'm carrying around on a CD is not a set of diffs, but a tarball of the repository itself. For the moment, I have more than one repository on the same machine (I actually have four of them), one of which is read/write, the rest is read-only. This basically means I keep the repositories from the other sites in tact, read-only and I check out the latest version of the off- site repository in another working directory specifying a the CVSROOT of one of the read-only repositories. It leaves the use of the off-site version optional to the project manager. It works pretty well: I keep the revision history of all of the repositories, I don't touch the repositories themselves and I have access to all versions of all projects. All I have to do to update one of the sites is overwrite the copies of the other repositories with new ones. I would be interested in a solution keeping only one repository, and I could start carrying diffs around in stead of repositories, but for the moment, this solution seems to be the best one for me - and might be an idea for mr Verhoeven as well.. Greetz! Ronald Landheer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Sander Sent: Friday, August 09, 2002 11:02 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: sync repositories --- Forwarded mail from [EMAIL PROTECTED] 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. Interesting approach. With some scripting, it could actually work... Of course it will work. You have no faith! ;-) Geez, it sounds like a CVS-based (partial) implementation of your old EMFS thingie :-) This design is way better than EMFS, actually. It keeps the original changes at each site on separate branches, so they're easier track and isolate if necessary. EMFS allows the definitive sources to get out of synch with the remote copies, which can't happen with a versioning system (provided the branch mastership conventions are enforced strictly). --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sync repositories
I have to sync two CVS repositories located on two non- connected networks. (yep, this means tape/CDROM transports, I know it sounds silly). I was wondering if there is a better way than creating incremental tar files on both sides and applying them on the other side. Luckily, the chances that two persons from the two sites are working on the same file are minimal, but I would like to prevent possible sync errors if it occurs. Silly or not, I'm going to have to do the same thing in a week or so -- and it will probably become a regular part of our CM process. In certain industries, the need for private, disjunct networks is an unbending fact of life. I haven't come up with a solid plan for this that I liked yet, but I'll watch the list to see if anyone has a good existing method, and I'll share whatever I come with in-house... -Mark Z ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sync repositories
Zieg, Mark 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). I was wondering if there is a better way than creating incremental tar files on both sides and applying them on the other side. Luckily, the chances that two persons from the two sites are working on the same file are minimal, but I would like to prevent possible sync errors if it occurs. If you MUST do this (and it is almost certain that you do not need to, but that's another story), then please examine two messages from the archives of this list entitled How I repaired my repository dated 30Jun02 - my summary of how I repaired a corrupt repository from a good sandbox and Eric Siegerman's additional suggestions. In your case, it becomes How to sync your repository, the restored archive is your repository to be updated, and the preserved sandbox is your sandbox created from the other repository. Note that there is significant potential for disaster. Note that you will have to do this again, in the other direction. Note that CVS was not designed for multiple repository operation. Note that this is generally a bad idea. Is a pattern emerging here? Silly or not, I'm going to have to do the same thing in a week or so -- and it will probably become a regular part of our CM process. In certain industries, the need for private, disjunct networks is an unbending fact of life. We can categorize these industries as industries which do not understand computer security, and yes, we'll be stuck with them for some time to come. I haven't come up with a solid plan for this that I liked yet, but I'll watch the list to see if anyone has a good existing method, and I'll share whatever I come with in-house... As much as I discourage doing this, I am interested in whatever you settle on. /|/|ike ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: sync repositories
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
RE: sync repositories
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
Re: sync repositories
Zieg, Mark wrote: 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 Nope. I was thinking of DoD, that's why I wrote almost. The DoD leads the list of industries that don't understand digital security. (And no, I'm not thumbing my nose at you for working there) 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 suspect you won't find one, since, as mentioned before, this is fundamentally bad practice with a simple solution - single repository operation. (A real solution for this is mindbogglingly complicated, due to all the special cases that can arise). I know that the subject comes up a lot, but I've never seen anyone come back with a solid answer. I think most of the solutions that get implemented are painful but workable ones like the one I suggested, or the one you outline below. 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. Sounds good. However, you aren't stretching, you're redefining. Please keep in mind that CVS will only be a component in a system of your own design. 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. That should work OK, but you will have to shutdown the slave during synchronization and force update (and possible merge) of all slave clients when you bring it back up. (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?) Almost certainly not, perhaps someone else is more inspired than I. The one thing I think might help would be per-file branches, which I mention below. 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 | | WHOOT! WHOOT! WHOOT! Danger, Will Robinson! Are you ABSOLUTELY CERTAIN that the person merging the databases will be able to merge the files? If not, you're either going to have to shuttle developers into and out of the RepoA location (with both repos down in the meantime), or prepare for long periods of broken trees. Another thing that you could do here would be per-file branches, only for files that have conflicts like this. So your file would now history like: foo.c | | \ | \ | \ | \ | \ | \ \/ _| trunk diff_branch_2002_08_09 - foo.c @ 1.3 | foo.c @ 1.3.1.1 foo.c - 1.4 | | foo.c - 1.3.1.2 (alpha mod) foo.c - 1.5 | foo.c - 1.6 | | foo.c - 1.3.1.3 (bravo mod) foo.c - 1.7 | | / | / | / | / | / | / | V foo.c - 1.8 (merged) With this, you still have a viable archive (provided foo.c isn't the file that everything else depends on), and may be able to overwrite RepoB with this and proceed for the next cycle while the foo.c developers do the merge. Structuring your files to minimize simultaneous alternate location development will pay off big here. copy RepoA to
Re: sync repositories
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. Interesting approach. With some scripting, it could actually work... Geez, it sounds like a CVS-based (partial) implementation of your old EMFS thingie :-) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Anyone who swims with the current will reach the big music steamship; whoever swims against the current will perhaps reach the source. - Paul Schneider-Esleben ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sync repositories
--- Forwarded mail from [EMAIL PROTECTED] 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. Interesting approach. With some scripting, it could actually work... Of course it will work. You have no faith! ;-) Geez, it sounds like a CVS-based (partial) implementation of your old EMFS thingie :-) This design is way better than EMFS, actually. It keeps the original changes at each site on separate branches, so they're easier track and isolate if necessary. EMFS allows the definitive sources to get out of synch with the remote copies, which can't happen with a versioning system (provided the branch mastership conventions are enforced strictly). --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
