On Wed, Apr 16, 2014 at 01:06:53PM -0700, Rick H wrote: > Good afternoon, > > I have a question, as I'm new to Git and would like to understand > how to do what I need to do in the best possible way. > > I'm working for a fairly large company using a commericial source > control system that has been around for a long time (ClearCase). We > have a partner company in another country who is going to work on a > small project for us. This company uses Git. > > Rather than take the time to train them on ClearCase, we'd like to > set something up where I can access their Git server to import our > initial source from ClearCase to get them going. The plan moving > forward would be for me to import their changes into ClearCase and > also get our local changes into their Git repository. > > I've got the source in ClearCase on my local machine, and I've > installed Git and have access to the remote server. I tried to clone > an empty Git repository to my local machine, but Git won't let me > put the clone in the same directory where the ClearCase source lives > on my local machine. > > How would you suggest I do this?
I'm in a similar situation at work at the moment, though with
different VCSs. This is a rough description of how we've been
handling it so far:
There are two repos:
- repoA <- where we work
- repoB <- where the customer works
We do our work on repoA:trunk and at the end of a sprint we tag what
we have. At that point we also create an integration branch for the
coming sprint (repoA:ibN, e.g. repoA:ib4). It'll look something like
this:
repoA:trunk ---*---*---*---*---*---*
\
repoA:ibN \---
In repoB we don't work on trunk, the only branch we ever touch is a
long lived integration branch repoB:integration, which was created at
changeset where we did the initial export of the code that we then
checked into repoA:
repoB:trunk ---*---*---*---*---*---*
\
repoB:integration \---
Now comes the interesting bit, the merging. We've agreed on the
following:
I. On Wednesday morning we may merge our changes into repoB:integration
II. On Wednesday afternoon the customer may merge their changes into
repoB:integration
The first merge, our changes into repoB:integration, is performed by
us and comprises the following steps:
1. Bring changes from repoB:integration -> repoA:ibN
2. Merge repoA:ibN -> repoA:trunk
3. Merge repoA:trunk -> repoA:ibN
4. Bring changes to repoA:ibN -> repoB:integration
After this repoA:trunk, repoA:ibN, and repoB:integration should all
contain the same code.
The second merge, their changes into repoB:integration, is performed
by the customer and is a normal merge:
1. Merge from repoB:integration -> repoB:trunk
2. Merge from repoB:trunk -> repoB:integration
After this repoB:trunk and repoB:integration should contain the same
code.
I hope this is an understable description, and that it helps.
/M
--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: [email protected] jabber: [email protected]
twitter: magthe http://therning.org/magnus
What gets measured, gets done.
-- Tom Peters
pgpPFF0llDNmd.pgp
Description: PGP signature
