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