Setting up my own personal repository on P4V

Question

I'm new to source control. I'm working on a team right now, and we're using Perforce (the GUI version P4V). I'm connected to my team's repository, and after I know I have something working, I commit new files or my changes to the repository.

This is all good and dandy, but I don't want to commit things too often to their repository. They run frequent builds using all these files, and I find it's better to commit things to it when they're completed and working correctly, rather than incrementally along the way.

My problem: I find that I often screw something up in a file and have no idea what I screwed up. It would be fantastic if I could just revert to an earlier working version of said file. However, with the way I'm using my team's source control, this isn't possible. I'd like to set up my own local version of my team's source control that I can commit things to far more frequently (but they wouldn't all actually see). I want it to be identical, but my commits are only for my personal use (and thus wouldn't mess up their build if they weren't perfect).

I basically want a clone of the repository where I can check stuff in for my personal use before checking it in to their repository.

How can I do this? I have to admit, I'm finding using source control a little confusing.

Answer 1

Branches do work, just create a branch somewhere in the depot, then check your changes in there. When you are ready, integrate from your branch back to the main branch.

In addition, if you can wait a couple months(or so), true private branches are coming to perforce. They call it p4sandbox

Answer 2

To completely answer your question... Use branches!!

That said here are the rules of the road!

1. First rule - Check in early - Check in often..
2. Second rule - See rule one!

I can totally relate to you, I was (years ago) very frustrated by this so let me help you out. Let's assume for a minute we have the following data structure

//depot/shared_project/...

So if I understand you you are all working out of this tree and you want your own sandbox to be able to implement the rules I've laid out.. What if we do this??

Let's add some order to this chaos. We are going to insert a couple trees into this to end up with

//depot/shared_project/dev/...
//depot/shared_project/release/...

Then as a new member who comes along the branch from dev and to their own sandbox checkin, and go nuts. When they are ready the merge their changes back into dev. When dev is ready to be released we integrate this over to release.. This keeps sanity amongst the developers and allows everyone to capitalize on benefits. So how do we get there.

Actions

1. Send an email out saying everyone check-in there code on Friday evening. We will be rearranging stuff and client specs will need to be modified a bit come monday. You don't have to do this but it will keep it simple.

2. Come friday evening.. Verify everyone has checked in everything..

p4 opened -a //depot/shared_project/...

1. Make sure your client spec includes the full tree //depot/shared_project/...

2. Let's move the tree structure..

p4 edit //depot/shared_project/...
p4 move //depot/shared_project/... //depot/shared_project/dev/...
p4 submit -d "Small move to a real dev environment" //depot/shared_project/...

Now that that is done let's talk about workflow (How do you use this..)

1. Create our personal branch..

p4 integ //depot/shared_project/dev/... //depot/shared_project/casey_dev/...

1. Make changes check in non-functional code etc..

2. Get it ready and merge it back in and resolve conflicts.

p4 integ //depot/shared_project/casey_dev/... //depot/shared_project/dev/...
p4 resolve

1. Submit!!

Hope that Helps

Answer 3

This is more problematic with centralised version control systems, such as Perforce, SVN, etc, because there isn't much of a concept of a personal, private branch.

The best solution is to suck it it up, and check your changes in to a public, but separate branch - or try and find other solutions such as manage your files with git locally and regularly check your files into perforce, but that path is painful, and requires expert knowledge of both version control systems.

Perforce is fairly good at merging, at least, so you should be able to use a branch reasonably comfortably and merge that into the main codeline as often as you like. Your personal history, however, will be visible. There is no way around that with your choice of version control