[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [RFC] Using git-p4 on project with branches
From:       Simon Hausmann <simon () lst ! de>
Date:       2008-08-24 10:36:32
Message-ID: 200808241236.38387.simon () lst ! de
[Download RAW message or body]

On Monday 18 August 2008 11:26:27 Tor Arvid Lund wrote:
> Hi!
>
> I really appreciate the work that is done with allowing us poor souls
> stuck with perforce at work to use git via git-p4. But I'm wondering
> how to make it work when there are several branches on the perforce
> server.
>
> Say, for instance, that I have this setup:
>
> //depot/old/path/to/projectX
> //depot/new/path/to/projectX_Devel_Branch
> //depot/new/path/to/projectX_Release_1.2_Branch
> //depot/new/path/to/projectOther
>
> It would be really nice, if I were able to make a projectX.git
> repository with the 'old', 'devel' and '1.2' branches. It seems that
> the --detect-branches argument to P4Sync wants me to enter
> //depot/new/path/to as the root path, and detect p4 branchspecs from
> there. That works poorly for me, since it would also include
> projectOther, which I don't want. It would also not include the 'old'
> branch.
>
> I have looked briefly at the git-p4 code, but don't know it very well
> yet. Anyway, I suspect this functionality is not implemented... I
> might try to do this myself, and if anybody has ideas on how to get
> started, it would be much appreciated.

I can try to explain the way we import multiple branches into one git 
repository where I work. Our setup is based on a few assumptions on the layout 
of the perforce depot.

The components in our depot paths begin with the project, followed by the name 
of the branch:

//depot/project/main
//depot/project/4.4
//depot/project/4.4.1
//depot/project/4.5
//depot/project/research/foobar

4.4 is branched off of main, 4.4.1 is branched off of 4.4, 4.5 and 
research/foobar are branched off of main again.

Based on this structure we also have branch mappings stored on the perforce 
server. They were originally introduced for convenience being able to run p4 
integrate with few arguments. Now they are also used for the git import:

4.4branch:

//depot/project/main/...    //depot/project/4.4/...

(same for 4.5, 4.4.1, etc.)

Based on this git-p4 imports changes:

1) git-p4 is aware of //depot/project as general prefix for all branches.

2) Based on the p4 branch mappings retrieved from the server it is easy to 
determine that the 'research/foobar' component in the 
//depot/project/research/foobar/somedir/somefile.c path of a file change 
represents the name of the branch.

3) Based on the branch mapping git-p4 knows that for example 4.4 is based on 
main. When the first change in the 4.4 branch is imported git-p4 assumes that 
last change number in //depot/qt/main that is less than $currentChangeNumber
represents the "parent" of the branch.

This approach has served us quite well, and I like that that doesn't require 
any separate configuration files or extra state information. However I 
understand that it requires discipline on the use of Perforce and the way 
projects are branched.

From your description I understand that you are using a very different 
structure. I think what may work well for you would be an approach where you 
specify a mapping from depot path to git branch manually in a configuration 
file, and changes git-p4 to read such a file.

> To support submitting changelists back to perforce, it would probably
> need some configuration (to determine which path to submit to in
> perforce)... Like:
>
> [git-p4 "branches"]
>         old = //depot/old/path/to/projectX
>         devel = //depot/new/path/to/projectX_Devel_Branch
>         1.2 = //depot/new/path/to/projectX_Release_1.2_Branch
>
> Well, I guess I'm just wondering if this is something anybody but me
> would like to have? Or if there is another/better way to go about
> doing it...

Submitting changes back to Perforce with git-p4 submit is actually a very 
simple thing, and thanks to Perforce's knowledge of everything on the client 
side there is no need to set up any configuration.

1) Based on the [git-p4: depot-paths...] field in the commit log it is easy to 
determine the depot path.
2) Using the p4 where command git-p4 can find out where in your p4 client view 
the branch resides.
3) Changes are applied in that checkout (along with p4 edit commands) and the 
change can be submitted to perforce.
4) Afterwards an import from Perforce is started and the changes just 
submitted appear in the import with the same patch-ids as the local commits, 
so git rebase will replace your local commits with the imported changes.


I hope this helps a bit with the git-p4 understanding :)


Simon

["signature.asc" (application/pgp-signature)]
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[prev in list] [next in list] [prev in thread] [next in thread]