Re: concurrent development, two repositories

[Pierre Asselin]

Jeffery Lin <address@hidden> wrote:

> I am part of a software project that involves two development
> teams working on the same code base. The MAJOR catch is that these
> two teams (for legal, corporate, and whatever reasons beyond my
> control) cannot share the same CVS repository.

That's pretty stoopid if you ask me.  Either this code is
super-secret or it is cleared for sharing.  If it is cleared
for sharing it wouldn't be that hard to set up a dedicated
CVS server in a DMZ for the exclusive use of that project.
Bah.


> So we develop
> separately, then every few weeks they send us a "patch" and I have
> to merge the two code bases.

Hmmm, let me think about this.  Do you ever send patches
back to them, or is this mostly one-way ?  Do they use CVS
too or do they just wing it ?

If the patches are one way you could have them send full tarballs
instead of patches so you can import them to your vendor branch.
You then merge the imports to your trunk as for any third-party
source.  They see only their codeline and you get to see both,
until you send them *your* patch and they decide to merge it.  At
that point your next import will have lots of vacuous conflicts
with the same text on the same side of the conflict, which you will
have to resolve by hand.  Tedious but easy.


> What I currently do is put their code on a branch then use the
> Eclipse Synchronization view to compare our trunk to the branch.
> Usually there are about 1,000 differences, and I go through each
> one manually to decide whether we need the change merged into the
> trunk.

I know nothing about Eclipse, so I can't help much here.
What happens to the deltas you choose not to merge ?  If they
never get merged it means that your two codelines are slowly
diverging.  Keeping track of this is going to become worse
and worse.


> Is there an easier way to do this?!

Maybe.  It depends what revision control they use at their
end.  Do you want to treat both sites symmetrically ?


-- 
pa at panix dot com