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
Attachment:
signature.asc
Description: This is a digitally signed message part.
