I'm a software engineer that uses git professionally but haven't tried using perforce until today. I searched about branch in perforce but I noticed that most of the informations that I found were all made by just using the branch in GUI then it creates a new folder (ie. /depot/MAIN/ to /depot/DEV/)
Is this how it works? What's the standards in naming the branches? Is it all caps?
Thanks
Branch names do not have to be in upper case only.
To create a new branch you can use the 'p4 integrate' command.
You can also use 'p4 copy' or 'p4 populate', depending on whether you want to exactly copy the source, or do the branch and submit in one action.
More information about branching is located here:
https://www.perforce.com/perforce//manuals/p4guide/chapter.codelines.html
If you're used to git branches you might like Perforce streams and the p4 switch command, which works a lot like git branch. For example:
p4 switch -c dev
stashes your current work, creates a new branch called dev based on your current branch, and switches to it. To bring your current work into the new branch, add the -r flag.
At its core streams really use the same concepts as "classic" (unmanaged) inter-file branching, and there are things you can do with Perforce's branching model that you can't with git's, but if you want something that feels more or less like git the switch command abstracts away a lot of the commands you'd have to learn otherwise.
Related
Let's say I have a file //depot/Project/com/company/project/SomeClass.java that is labeled with name "version-1.0.0". Suddenly I need to revert back to that label to create a bugfix release. I update to it and then make changes to the SomeClass.java.
Now this is the part I don't understand. How do I submit the fixed SomeClass.java to Perforce without overwriting any newer revision of the source tree? With Mercurial or Git I would have a branch that has the fixed source and I would just create the bugfix build from there. But now I have no idea where I should put the fixed file.
You've got essentially the same choices in Perforce as you do in those other systems, although the terminology is a bit different.
The simple solution is to make your change to SomeClass.java, and then make a new label, called "version-1.0.1", which tags the new version of SomeClass.java rather than the old one, but otherwise is identical to the version-1.0.1 label:
p4 sync //...#version-1.0.0
p4 edit SomeClass.java
p4 submit -d Fixed_that_nasty_bug
p4 label version-1.0.1
p4 labelsync -l version-1.0.1
Alternately, you can also make a branch in Perforce, and you can use your label as the basis for making that branch.
So you could do something like:
p4 integrate //depot/Project/...#version-1.0.0 //depot/rel-1.0.1/Project/...
Then you can make your change to //depot/rel-1.0.1/Project/.../SomeClass.java, and submit it back to the rel-1.0.1 branch.
If this is your first time thinking about things like development branches, release branches, etc., can I suggest having a read of http://www.perforce.com/perforce/conferences/us/2005/presentations/Wingerd.pdf or picking up a copy of Laura Wingerd's Practical Perforce and reading the chapter on "the mainline model"?
I wish to check my changes into a different branch than the files were check out from. All the files there are the same “version” in each branch, Perforce should know this from tracking the integrations that have been done. (So no merging need to be done)
According to the Perforce Blog, the p4 move -f command will move your edit from one branch to the other. From the blog
This can be a real lifesaver if (as I did a few weeks ago) you start working on a fix in your mainline, and then decide that it needs to go into your release branch instead. Previously you would have needed to save a copy of your work, revert it, open the files in the release branch, and copy your edits back in manually — now you just “p4 move -f main/… rel/…” and all your edits go where you need them.
This is a new feature added in version 2010.1 (this year I believe) so that's probably why tech support didn't know about it.
Use "p4 move" if you have version 2009.1 or later. Just move to the new branch and revert from the old branch.
I just got an answer from support#perforce.com
You cannot check files into a branch
that they weren't checked out from.
You need to open those other files for
edit and copy your changed files over.
(I am now beginning to understand why pressure is building up from some the programmer I work with to to move to Mercurial)
(I am a new perforce user, but have used lots of other source code control systems in the past.)
We use a change list to check-in each bug fix; the change list comment includes the bug ID therefore it is easy to track when a bug fix has been checked into a branch.
However I can’t see an easy way to find all branches a given bug fix has been merged into, or to find all bug fixes that have been merged into a given branch.
As far as I can tell perforce does not track all the branches a change list have been merged into. As I understand it, when a merge is done in perforce the history is not copied into the target branch so the only history in the target in the comment on the change list the merge was done into.
What am I missing?
Perforce tracks where revisions of a file have been integrated, but it doesn't automatically propagate check-in comments with your bug-tracking metadata.
Given a changelist on a particular branch, you can tell whether Perforce thinks the changelist has been integrated by asking Perforce to integrate the changelist. (I'm using "branch" in the more traditional source-control sense, to mean a particular branch of the source code tree, rather than in the specific Perforce sense to mean the path of integration between these two source code trees.) Let's say you've been working in //source/project/trunk/... and you have a changelist #1234 that you'd like to check whether it's been integrated into your release branch //source/project/rel/.... Create a client that maps //source/project/rel/... and execute:
$ p4 integrate -n //source/project/trunk/...#1234,1234 //source/project/rel/...
If Perforce tells you "All revision(s) already integrated.", changelist #1234 has been integrated, and that bugfix ought to be available on the release branch. If Perforce lists files that have changed, those files have not been integrated. (It's also possible for some files in a changelist to be integrated and not others, which may make for some interesting problems.)
This doesn't scale especially well -- you need to check each bugfix on each branch you care about, though it does lend itself to automation.
You can use the "unsupported" Perforce command interchanges to get a quick idea of what changelists have not been integrated from one branch into another. (In Perforce parlance, "unsupported" means something like "might not work the same in the next revision, but we think it could be useful so we'll release it anyway".) To see what changelists haven't been integrated from our example trunk to release branches, execute:
$ p4 interchanges //source/project/trunk/... //source/project/rel/...
Change 1236 on 2010/10/10 by user#client 'Fixed some bug you don't care about'
Change 1235 on 2010/10/09 by user#other_client 'Fixed some other random bug'
In this example, I haven't listed changelist #1234 because it's already been integrated into the release branch. One problem I've experienced using interchanges is it'll list every newer revision after an unintegrated change, even if the newer revisions themselves have been integrated, so if you're cherry-picking revisions for a release branch you may see changelists listed again. I use interchanges as a first pass to get a rough idea of what I need to integrate, then look at integrate to get a better idea of what's really missing.
(Perforce also supports a similar concept of "jobs", that let one attach particular fixes to particular changelists, but my organization doesn't use them so I don't know how well they work or whether they are propagated automatically on integration.)
Problem: 2 projects shared trunk and were updating some of the same files. Now one project needs to be released, so a new branch was created from a checkpoint before the projects started.
I have a list of just my changelist numbers from the mainline. Using that I can generate a list changed files and diff output using a script with a series of 'p4 describe #' commands.
Can I reformat that output and apply it to the new branch somehow?
Response to the title: "Is it possible to create a patch using a set of changelists?"
Yes.
p4 diff2 -u //path_to_your_sources/...#cln_minus_1 //path_to_your_sources/...#cln > /tmp/cln.patch.
You can then use /tmp/cln.patch as input to the patch utility. Here, 'cln' is the submitted change list number that you want to create a patch for.
I've just spent two hours struggling with this. Using cygwin patch, I had to munge the paths until they were recognised.
In the end, the magic incantation looked like this (broken across lines):
p4 diff2 -u //depot/foo/main/...#100003 //depot/foo/main/...#100000 |
sed 's#//depot/#E:/Source/#g' |
sed '/^+++\|---/s#/#\\#g' |
patch
That is:
Use p4 diff2 to get a unified diff (-u) of part of the depot between the two revisions that I care about. The second changelist is the one before the first one I want, otherwise it's not included in the diff.
Use sed to change the //depot/ to E:/Source/, which is where my workspace lives.
Change forward slashes to double backslashes (this seems to make it work).
Pipe the results through patch.
Cygwin patch is smart enough to check files out of Perforce, but I'm not sure how to get it to do it silently. It prompts with Get file 'e:\Source\foo\whatever' from Perforce with lock?.
This is with p4 version 2010.1, a fairly recent installation of Cygwin, running on PowerShell.
Oh, and after this, patch wrote out Unix-style line endings, so I used u2d to fix those up.
Perforce will let you cherry-pick changelists for integration, which may be easier than trying to generate and apply a patch. Perforce will keep track of what revisions you've integrated where, which may make future integrations easier.
Let's assume you used to have one trunk:
//depot/mycode/trunk
And you checked in all of your changes there. You branched trunk at some point in the past to:
//depot/mycode/rel
And you have a list of changelists on trunk to merge. From a client spec that maps rel, integrate each changelist:
p4 integrate //depot/mycode/trunk/...#1234,1234 //depot/mycode/rel/...
where 1234 is the changelist number. Resolve after each integration. You may also wish to build, test, and commit your integrations at various checkpoints during your integration, if you can identify good points to do so. (Perforce can handle multiple integrations per commit, but if you make a mistake you'll need to revert to the last version checked in and redo the intermediate integrations and resolves.)
p4 describe -S -du <CL number>
is the shorter and most concise command, in my opinion.
We were working on a design, and for that we created the skeleton of the classes in our main branch. Now, we are starting to code, and for that we got a new branch. So, it would be nice if I can move all the new files in the main branch into the new branch. However, I cannot check them in yet. So, is it possible to integrate the checked out changelist? Thanks.
The Perforce support web site explains how to do this: Perforce Knowledge Base: Branching work in progress. It would be nicer if it was a single step that didn't require running eight different commands.
Since release 2013.1, the way to branch work in progress is to shelve the work and unshelve it on the branch. In detail:
Shelve your outstanding changes:
$ p4 shelve ...
Change 182535 created with 10 open file(s).
Shelving files for change 182535.
edit //info.ravenbrook.com/project/mps/master/code/arenavm.c#26
# etc.
Unshelve them on the branch (using the -b option, which maps the file name through a branch specification):
$ p4 unshelve -b mps/branch/2013-06-05/diag -s 182535
... //info.ravenbrook.com/project/mps/branch/2013-06-05/diag/code/arenavm.c - must resolve //info.ravenbrook.com/project/mps/master/code/arenavm.c#=182535 before submitting
# etc.
Resolve any merges resulting from the unshelve, using p4 resolve -as to quickly do the "safe" ones, and then doing the rest with p4 resolve as usual.
$ p4 resolve -as
//gdr-peewit/info.ravenbrook.com/project/mps/branch/2013-06-05/diag/code/arenavm.c - copy from //info.ravenbrook.com/project/mps/master/code/arenavm.c
# etc.
$ p4 resolve
No file(s) to resolve.
(The example output is from a real use case I ran just now.)
I never found a way to do that within perforce, but you can at least partially automate it.
Usually when I had to do something like that I'd check out the files in the branch I want to move things to, then use WinMerge to diff the branches and copy the changes over. Once that's done you can revert the changes in the original branch and check them in in the new branch.
It's not the best solution (no automatic checkout/add/delete of files on the new branch), but was the fastest method I came up with.
Not really.
You can of course simply open the files for edit in the new branch, and manually copy the changed files from the workspace of your main branch to the new branch's workspace. This is probably the easiest way if it just a few files.
Here are a few scripts that can be handy if a larger number of files are involved.
E.g., with the P4Shelf script you can create an archive of all your changed files, and later automatically open them in any branch with the changes restored.
Also, check out some other nifty scripts for Perforce by Jim Tilander.
To rephrase Gareth Rees' answer above in simple terms,
p4 unshelve -b target_branchspec -s changelist
:)
The easy answer is - no you can't. A quick perusal of the Perforce docs didn't come up with a ready cite for this, unfortunately, but in my experience any attempt to pull the rug out from under the Perforce server will result in your changes being lost which will leave you an unhappy camper.
Make a back up, create a new work area on the new branch, and re-apply your changes, perhaps using the diff/merge strategy outlined in Herms answer.