I'm new at using Perforce and I am faced with a dilemma. I am working on two different projects and I'm trying to figure out if there is any way to separate the revision numbers between them.
The setup is something like this:
Depot 1 stores Project 1 and I use Workspace 1 to work on it
Depot 2 stores Project 2 and I use Workspace 2 to work on it
However, they don't have separate changelist numbers (when looking under history) and this is a little confusing (working with different people on them as well). The same revision number goes up whenever I submit from either of the projects.
Is there any way to have separate the revision counters for the two projects?
Edit: On closer examination, the revisions are separate for the actual files, is this an issue with how Perforce shows the changelist(?) number when switching between depots?
The files in the different projects each have their own history, and each file has its own revision numbers, while there are also repository-wide ways to refer to instants of time in the overall repository, such as by date and by change number.
Try looking at 'p4 help files', 'p4 help revisions' and 'p4 help filelog' to get an introduction to the various techniques.
Also install P4V and get comfortable with using tools like Time-Lapse View, the Revision Graph, and Folder Diff, as these are very important when comparing different work among different projects in your repository.
Lastly, labels can help you associate logical mnemonic names with particular sets of revisions, so look into 'p4 help label' and 'p4 help tag'.
Related
I am working in a project. We use both clearcase and perforce.
As we are working on differnet builds, In clearcase we create a label for each release. Say for release "X", we create a clearcase case "Label X". Label X is having all the latest files with respect to release "X". When we finish another release say "Y", we create another label say "Label Y". Label "Y" is again having all the files for release "Y". But at any point of time we can go back to "Label X" .It means all the files will be reverted back to "Label X".
Can we do same thing in perforce? Can we create a label in perforce so at any point of time, we can go to that label which will give the files as in that label timeline.
Perforce also provide an interesting guide "Migration Planning Guide: IBM Rational ClearCase to Perforce", and mention that p4 label is not the only alternative:
Label Strategies
Both ClearCase and Perforce provide labels, which identify the versions of files that constitute a baseline. For many ClearCase users, labels are mandatory. Applying labels is time-consuming, often accounting for 30 percent or more of the time associated with creating
stable builds.
In Perforce, labels are just one way of reproducing baselines. Changelists accomplish the same goal in ways that are less taxing on the build process and faster and easier to reference than a label.
Each Perforce check-in generates a unique changelist number that reflects the state of the repository at a point in time. Any changelist can be used to describe the state
of every file in the repository, even though it affects only a small subset of the repository.
This is an oversimplication since a typical config spec is several lines or more.
Branches in Perforce are represented as directories, making it easy to combine branches and changelist numbers to represent a baseline.
Alternately, labels can refer to changelist numbers limited to an identified scope in the server, where the scope is typically a particular branch.
Yes, you can create labels in perforce.
Use p4 label to create a label specification, and then use p4 tag to tag files with a label.
You can learn more about labels in the user guide.
Imagine you have the following setup:
//depot/source/sourcefile.cpp
//depot/build/product.exe
At 8am, you check in sourcefile.cpp (now revision 2, in change list 100). The build machine starts building and at 9am, the build machine checks in product.exe, revision 2 in change list 104. Cool. Sadly, you may not have noticed, but at 8:15, someone checked in revision 3 of sourcefile.cpp in change list 103.
What are your options? If you just record the change list of the source (100) and product (104), you can sync your whole project to source and then sync further the contents of change list 104. This process is somewhat manual - you have to record two numbers and do a two step operation.
You can make a label, but sadly, labels don't allow multiple revisions so you it's not really workable.
Finally, at some point after you check in revision 104, you can create a branch. This is basically a metadata copy of the revisions you are interested in so that you can do a one click sync in the future. You can lock the branch to prevent changes.
p4 integ //depot/source/...#102 //depot/milestone1/source/...
p4 integ //depot/build/...#104 //depot/milestone1/build/...
Geeky details - you can configure files in perforce to hold a limited number of revision - for instance you might only want the last 16 revisions of product.exe. (Change the filetype to +S16). If you (or someone else does this), you the first two procedures will eventually fail because the revision has been deleted due to too many revisions. If you use the branch, your product.exe won't age out.
Is there a way to determine if two differences between two versions of a file belong to same or different changelist ?
If not, then would it be a good practice to mention the changelist numbers in the comments when the changes are made ?
I'm not quite sure what you're asking, but the visual client has a Time-Lapse View for a file that will tell you which revision introduced a particular change, and you can scrub that back through revisions as well to find out earlier changes if needed.
After deleting my Svn repo by accident the other day I wanted to try something else and I have chosen Perforce as my current versioning tool testing ground. It is going great and I am liking what am seeing in Perforce.
Here is my problem. I have submitted my files to my Perforce server and then used my client pcs to grab those projects from the master Perforce server. Now all works great except that I realized that it is possible to use more than a single "depot" in Perforce, and it makes sense to me that I should just move some of those projects to another depot fpr the sake of organization and and maybe for security reasons inn case.
I have been looking for some answers, and I have found couple of them however I am unable to produce any intended results thus I am looking for some expert advice here.
One of the pages I have tried is this one
http://kb.perforce.com/article/24/renaming-depot-directories
Seems to offer a solution, however I have not been able to move files from one depot to another depot that is on the same server process. The examples in the page works fine for moving some folder to a folder in the same depot. The example seems to demonstrate moving to another folder under the same depot.
So I am looking for a reasonable and safe way to move my master Perforce depot folders to another depot that is on the same server, and naturally without loosing any work.
Here is what I am wanting
-- Current
//Depot-A
-->folder1
-->folder2
-- I want
//Depot-A
-->folder1
//Depot-B
-->folder2
thanks
Moving files between different depots is no different than moving files between folders within the same depot, with the exception that the target depot must already exist. Using your example, and assuming "Depot-B" doesn't exist yet, to move "folder2" from "Depot-A" to "Depot-B", you would simply do this:
p4 depot Depot-B
p4 edit //Depot-A/folder2/...
p4 move //Depot-A/folder2/... //Depot-B/folder2/...
p4 submit
Here's what I would do (in a nutshell): If you open a P4V session and select the submitted changelists tab, you can filter this set to show only the changes that relate to the section you want to move. This is the change set you will duplicate on the new depot (or even server) that you want to populate. The idea is that you are unraveling the archive files on one side and winding them up in the identical way at the destination. So the process is simply (1) syncing to the first changelist, (2) integrating that set across to the new location, (3) checking that set in, and (4) proceed to the next changelist. Obviously this can be scripted. I am currently in the process of working a script up in python, but any decent scripting language with Perforce function libraries will work. A couple of complications: The changelists will be sequentially the same as the originals, but the original times will not - they will be "current". And of course if there are labels, you'll need to map that out in the new location if you want them preserved.
I don't think additional depots add much in the way of security. Multiple depot scenarios primarily arise in very large installation.
The primary benefit of additional depots is that you can gain more control over the disk space layout of your server, for example if your repository is too large to fit onto a single filesystem and you need to expand it to use multiple filesystems. A secondary reason to create additional depots is if you have to have depots of specialized types; for example if you wish to create a Streams depot to use the Perforce Streams feature.
For a scenario such as the one you describe, having all your files under Depot A is probably fine for the foreseeable future.
I'm trying to understand if I must use a changelist when I checkout a file?
I'm consider to use Perforce (haven't tried it yet). My question refers to its methodology.
There's a default changelist where things go if you don't specifically choose another changelist for it, but it has limitations like not being able to shelve files. If you're spending a significant amount of time on a change, it's usually very useful to create a numbered changelist with your eventual submit message right away. It's also handy to put temporary changes you don't intend to submit into their own changelist. It's a similar workflow to the way people use multiple local branches in a DVCS.
I tried to merge some work that a developer did in a working branch to a stable branch. The files a, b, and c had been changed by at least a dozen changesets since the common ancestor of STABLE and HEAD branches were separated.
I expected that since this developer changed five lines in each of file a, b, and c, that when I integrated from the HEAD to the STABLE branch, I would get his changes in my pending changset, which I could then review and commit.
Instead, it seems that it has taken every change that happened to file A, since the two were branched, and applied all of those changes that also existed in my colleague's working copy.
In other words, there seems to be no record in a perforce changeset, of what my colleague actually changed, versus what the file before contained.
If I browse the submitted changesets, I can see the difference between my colleague's version of the file, and the immediately preceding version. But then, that does not, it seems, determine what goes into the merge.
Doesn't a changeset mean, "a set of changes made between rev X and revision X+1 of a file"?
Can anybody help me understand what it means to "integrate a changeset" when in fact, what it seems is that Perforce doesn't track changes, it tracks files.
It is entirely possible that I am doing everything wrong, and would appreciate any pointer as to how it is that you can can merge accurately and safely between Perforce working branches and stable branches, without stuff that you don't want to get integrated to the stable branch getting integrated. It seems that no matter how simple the changes that actually get made in the product, the merge does not actually work for me.
Perforce does save changes to text files as deltas (binary files get saved in their entirety every time a change is submitted). It sounds like you're not properly restricting the revision range during your integration.
You say the working branch has "...been changed by at least a dozen changesets since the ...branches were separated." Let's call them changelists 1-12. If I understand you correctly you are trying to integrate the modifications made in just one of those changelists, not all of them.
During a simple integration operation Perforce will assume you want to integrate all of the changes that have been submitted since the branch was made. If you only want a subset of these changes, you have to specify a revision range. So, if you just want to integrate the changes that occurred between changelist 11 and 12, you would specify that revision range as shown in the screen capture. (Note: the revision range is inclusive, so specifying a range of 11-12, as I do in this screen shot will actually include changes in changelists 11 and 12. If you just want to integrate the changes made in changelist 12, enter 12 in both fields of the revision range.)
Just be aware that the inevitable conflicts that arise may be difficult to resolve, depending upon how far the branches have diverged and the nature of the changes.
Could you be more specific on how you did the integration? My guess is that you probably have integrated all the changes up to that changelist instead of just that changelist only. If so all you need to do is to specify the same changelist as both the upper and lower limit of the integration.
It's very easy to do in the visual client, but I'm not sure of the exact command line switch you need to use.