Perforce Workflow – Best Practices and Guidelines

perforcesvnworkflows

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?

Best Answer

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 xyz.java 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).

Related Topic