Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So, we have just migrated from SVN to Perforce.

I'm having a little trouble trying to figure out the best workflow.

For Subversion, I did the following (via TortoiseSVN):

  1. Check out repo
  2. Do work
  3. Update repo
  4. Resolve conflicts, if any.
  5. Commit my code.
  6. Do work..

What is the best approach for P4? I know that you must open files for edit before actually editing them. With this in mind I am currently doing the following (via P4V):

  1. Sync to head
  2. Open entire project for editing
  3. Do work
  4. Revert unchanged files
  5. Submit i.e. commit pending changes.
  6. Open entire project for edit, again.
  7. Do work..

Is this a practical approach? or is there one that is more in tune with Perforce best practices?

share|improve this question
If your SVN flow suits you and your organization, why not using it and opening the files as needed? I see no value in opening all of them to just then abort the edition. – AProgrammer Feb 1 '13 at 15:33
You see this problem is that I don't know what files i'll be editing at check out time. – conor Feb 1 '13 at 15:50
what's the problem with opening them when needed? (We are using P4 and I know nobody which has a problem with that). – AProgrammer Feb 1 '13 at 16:15
Vim has a plugin that prompts me to check out from perforce when I start editing a file. I know other programmer's editors have similar plugins. Something to consider if you have trouble tracking that extra step. – Karl Bielefeldt Feb 1 '13 at 19:26
up vote 5 down vote accepted

Your step two of "Open entire project for editing" may contribute less than clear communication in the team.

One of the important aspects of working as a team is communication. Perforce can show who has a file opened in a change set. If I am working on a file and I see someone else also editing the file, this is of potential interest to me - we may have a collision.

On the other hand, if I am only checking out files that I need to open as I need them, my team mates will not be as confused about what I am working on (I'm not potentially touching every file in the project).

Furthermore, consider that the server is also maintaining the information on what every client spec has checked out. By opening all the files in large projects this will tax the server a bit more (probably not much more, but it is still some).

Opening every file limits the use of the 'p4 opened' command.

It is one thing to see all "you are the only one to check out this file" checks in your pending changelist. It is quite another to see every file also checked out by other people.

As you get used to perforce, you will get to the point where every time you start working on a file, you check it out first.

Once you check out the files, ideally you would place these open files in a named change list rather than leaving this in the default change list. This is again to aid in communication between team members ("you've got open in a change list named 'fix abc bug'"). This also facilitates working on two things at once by grouping the files in different change lists as you need them.

In p4v this is done by right clicking on the files and selecting 'move to another changelist'.

Unless you lock the files (there are pros and cons to this), you may need to resolve conflicts in the submit too - but you will know before you submit that you need to merge, and the server won't let you do the checkin of the changelist (this is an atomic operation). This will show up with a question mark in the file icon.

A more 'advanced' p4 concept is that of jobs within p4. These integrate with mylyn within eclipse as tasks.

With a job, one would associate changelists to a job. You can then go back to look at a job and see what changes were checked into fix this particular item.

Furthermore, with p4 defect tracking gateway one can link p4 to your favorite bug tracking system. This will link p4 jobs to bugs so that changes to one show up in the other (including p4 changelist checkins against jobs being described in the defect tracking system).

I've seen a huge bug tracking database built on top of p4 jobs.

You might find the p4 tutorials a useful resource.

Do check out look at p4 sandbox - it is interesting and you may find the private local branching (think DVCS) to fit how you work (and you can get the repository on a thumb drive and work off line).

share|improve this answer
Great answer, thanks. – conor Feb 3 '13 at 17:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.