Synchronizing Projects Across Two CVS Repositories?

pavlos asks: "In a few days, part of our development team is going to a remote site to integrate our product with the customer's hardware. We can't move the whole team over there, so during the integration phase both the remote team and the team staying at home will need to commit changes to the software. An encrypted connection to the remote site exists, but is slow and unreliable. The remote team will be taking a Linux CVS server with them as an autonomous solution." The problems occur when it comes time to merge the changes made at the remote site with changes at the central office. What are the best ways to merge changes from a single project from two different CVS repositories?

"We can periodically back up the remote CVS repository using rsync. However, what we would really like is the following behaviour:

1. Each of the local and remote teams work with their own CVS servers. Only the one at the office is backed up.
2. Automatically, when one team commits a change, it is checked out from that CVS repository and committed to the other CVS repository.
3. If the previous step generates a conflict, the developers are asked to merge manually.

Any ideas? Has anyone used CVS in such a manner? Are there any scripts out there which can automate this process?"

Your best investment of time and money

[Anonymous Coward]

will be to get that link up and running, and use CVS in a more "normal" fashion. CVS doesn't handle splitting and re-merging repositories. I image there is a hack or two out there that tries to solve this problem, but why not spend a few bucks and solve the link problem directly? At a minimum, make it a dialup modem, and check out cvsq, which queues your commits:

http://www.volny.cz/v.slavik/lt/cvsq.html [volny.cz]

my 2 cents.

I don't know a whole hell of a lot about CVS...

[Goldberg's Pants]

But surely an easier solution would be a wireless link to the main CVS respository? Maybe I'm way off base here but I think to have two seperate repositories would be a nightmare.

But then what the hell do I know. Not a lot, but I'm just giving the layman (AKA braindead) perspective.

---

How about branching?

[A nonymous Coward]

I've never done this, and I'm too lazy to try it out for you; thus, YMMV :-)

How about putting the remote work on a separate branch? The remote site sends their diffs back to HQ periodically (mail gets thru after a while, eh?). HQ updates their copy of the remote branch, uses the standard CVS capabilities to merge back into the main branch, and sends the latest main branch diffs back to the remote site. The remote site updates the main branch from the tarball, and (here's the part I am not sure of) updates their own branch from the main branch.

I have never updated a branch from the head, but I don't see why it wouldn't work.

The key is that each site never diddles the other's branch except when they receive diffs. It seems so simple and opbvious to me that I'm probably missing something...

--

cvsq

[embobo]

Sounds like cvsq [volny.cz] might solve your problem. cvsq was mentioned in a previous ask /. where a user was connected intermittently.

Now, cvsq does not use 2 repositories. It seems you have preconcluded that you need 2 cvs respositories. Rather than forcing a solution to have 2 repositories I suggest analyzing the problem a little more at a higher to determine the requirements.

Perhaps this will help

[Mignon]

I haven't had a chance to try this out myself, but you may want to look into something called CVSup [polstra.com]

Re:cvsq

[pavlos]

Thank you and the previous poster for your useful suggestion.

Indeed, we do not need two repositories. We need to avoid the developers sitting idle while trying to either update or commit.

Assuming the repository is at HQ, a solution that pulls all the updates from HQ slowly and then allows the remote developers to apply them quickly would solve the update problem.

A solution that stores commits and sends them to HQ would solve the commit problem. We will start looking into cvsq as you suggested.

Pavlos

How about VCS::CVS module?

[Alex Farber]

http://savage.net.au/Perl.html#VCS::CVS

Why two repositories?

[SecretAsianMan]

An encrypted connection to the remote site exists, but is slow and unreliable

So? You're just storing source in the repository, right? Unless it's <= a 9600bps modem, you shouldn't have a problem. Even if your project is huge, only the initial checkouts are going to need that much bandwidth or uptime.

If the connection is so bad that you cannot access your remote repository, then maybe you should think about ways to improve the connection. That would seem like a more elegant approach.


--
SecretAsianMan (54.5% Slashdot pure)

Re:Why two repositories?

[musicmaker]

Well.. having used CVS extensively both localy and on Sourceforge, I have to say that using CVS remotely seems to have many problems, speed just being one of them.. Broken pipe when commiting a large number of files, or trying to update a directory with a large number of files. The number of times I have had to fiddle around with my CVS files for my sourceforge project is scary.
It seems to be better using the -z flags, but it's still a pain in the but.