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
Description: PGP signature