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: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe               http://therning.org/magnus

What gets measured, gets done.
     -- Tom Peters

Attachment: pgpPFF0llDNmd.pgp
Description: PGP signature

Reply via email to