7

Where I work uses a Perforce environment but we are not allowed to check in until our features are completed and ready to be tested. I need to be able to do local commits because at times I have had upwards of 50 files checked out for a week without any versioning on my changes.

Git fits my purpose, but I am not sure how to set it up to best integrate with the rest of my environment.

My goals are:

  • When working on a feature I would like to be able to completely ignore Perforce and edit and commit as much as i please (in Git).
  • Before submitting a feature, I need to be able to go into P4V or P4Win to diff the files and make sure everything is up to date, and after testing I would like all my changes to be in a single commit.

It seems like creating a git repository at the root directory of my local workspace would work, but I have some issues...

  1. There are a massive amount of files in this repository and at least with the initial commit git is crawling.
  2. I need to be able to easily update the git repository when I "get latest" from Perforce
  3. I don't want to have to deal with checking out every file in Perforce before I edit it, nor do I want to have to do a Force Sync in Perforce because their are writable files that aren't checked out.

Can anyone give me some tips about this? I've been looking at submodules in git as a way to potentially reduce the size of the git repo as there are a lot of portions of the perforce repo that I don't need versioning on.

Sky
  • 71
  • 1
  • If Mercurial is an option I would recommend the [Perfarce](http://mercurial.selenic.com/wiki/PerfarceExtension) plugin. – rjnilsson Feb 28 '11 at 18:44

5 Answers5

1

I am currently using exactly this workflow and it's pretty great

For corporate reasons I can't use the git-p4 commands, but I've got a git repo living inside my client workspace directory. Our setup has configuration-code-only checked in to source control, with the rest of the dev setup stored in a ZIP. Thus I never reconcile on the workspace root anyway, which has the added bonus of not needing to explicitly ignore .git.

Addressing your points:

  1. The initial commit can be expected to be...well, not the speediest. It's not cloning an existing repo, it's building one up from scratch.

  2. Occasionally I'll save+commit what I'm working on,

    git checkout master && p4 sync && git add --all . && git commit -mupdate && git checkout feature-branch

    and then continue to hack. Merges tend to be much smoother in Git than in Perforce so usually you won't have to break focus because of conflicts. @p4mataway told me that they're working on merging better, though, so that'll be neat to see.

  3. I turned on the 'allwrite' workspace option (don't keep unedited files read-only) and when I'm ready to check something in, I'll merge that branch down to master and then Reconcile in P4V. I'd do that from the command-line too but, corporate reasons again. Long story.

Git has been tremendously useful to me when dealing with features that involve multiple changes to the same file, as tends to happen with long-pending changes - typically database schema changes that require our application's database to be reset and we don't want to do that on the test servers right now because QA are in the middle of scenarios. The longer a changelist stays around, the more likely some unrelated work is to touch one of the same files, and being able to branch locally keeps the changes from getting stuck together. That feature alone is enough to make this whole setup entirely worthwhile.

Disclaimer - I don't intend to keep this Git repo around forever. Once some of the Corporate Reasons are resolved with an upcoming server upgrade I'll be able to use some very shiny Perforce features that our current environment doesn't support.

gws
  • 459
  • 1
  • 7
  • 16
1

You should go with git-p4. This answer might be helpful as well.

Community
  • 1
  • 1
jhwist
  • 15,201
  • 3
  • 40
  • 47
  • Does git-p4 work like git-svn (essentially replacing svn), or does it just coordinate between them so that I could view the change lists in P4V and submit through that instead? – Sky Feb 28 '11 at 00:52
  • And another question, with git-p4 can I keep a local history of many small changelists while my commits to Perforce are just in one monolithic changelist? – Sky Feb 28 '11 at 00:52
  • And another problem with this is that it looks like it requires having the git repo in a separate place on the hard disk, which might be fine for the code but wouldn't work for script/asset files. – Sky Feb 28 '11 at 00:59
0

I do the same thing at work with StarTeam and git. I'm not familiar with perforce syntax, but the concepts should match.

First of all, the initial git commit is always slow. After that, it might take 5-10 seconds to scan changed files for staging, but the commit should happen nearly instantaneously most of the time. For context, our code base has approximately 50,000 versioned files.

I keep master synced up with StarTeam, but don't do any development work directly in it. I do a git checkout master, then do a StarTeam update, then a git add and commit.

Then for my work, I make a new branch, do all my work in there, do another StarTeam update in master, and merge my feature branch back into master before committing to StarTeam. Thus, StarTeam check ins and outs are all done in master, and development is always done in other branches, which keeps the StarTeam updates clean.

This mixed approach has some other nice benefits, like being able to put partial work on hold for a while for code reviews, field issues, or whatever. I currently have 5 git branches in various states of use. It's also real nice for putting in temporary debugging code.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
  • Same question as above, not sure what the Stack Overflow etiquette is on this, but I figure you won't get notified if I don't reply here, so here's the question again: Yes, I have tried this, but there is the difficulty with this of keeping p4 and git in sync. P4 likes to check out anything I touch, while Git really doesn't care what I change until its time to commit. How do I integrate the two so that all the files aren't read-only and so that when I switch branches in Git, P4 releases the checked out files (or even better, shelves them)? – Sky Feb 28 '11 at 00:51
  • And this is the post for it http://stackoverflow.com/questions/6591744/using-git-locally-then-merging-and-checking-into-starteam – orkoden Aug 22 '12 at 13:35
0

Here's a crude solution. After you sync from p4, Do a git init in that directory, add all the files and commit them. Do your work completely ignoring git and then add and commit them back into p4.

This and some related things were discussion in this question.

Community
  • 1
  • 1
Noufal Ibrahim
  • 71,383
  • 13
  • 135
  • 169
  • Yes, I have tried this, but there is the difficulty with this of keeping p4 and git in sync. P4 likes to check out anything I touch, while Git really doesn't care what I change until its time to commit. How do I integrate the two so that all the files aren't read-only and so that when I switch branches in Git, P4 releases the checked out files (or even better, shelves them)? – Sky Feb 28 '11 at 00:50
  • No, P4 will mess up your synced revision, it will tell you ,everything is changed. Use git-p4 instead. – Matej 'Yin' Gagyi Jan 13 '17 at 13:24
0

As you are using P4V anyway, I would recommend you to at least try the relatively new offline support option. It allows you to most of what you're asking for (except for using Git).

rjnilsson
  • 2,343
  • 15
  • 20