How do I move a folder to completely different Perforce depot on a completely different server but preserving history and changes?
Splitting and merging portions of Perforce depots from separate servers can be done, but you will need the assistance of Perforce technical support, so contact them!
A substantially simpler solution is to retain the two separate servers, and use a Remote Depot definition so that you can access the files in Server A from client workspaces connected to server B. That way, your users mostly see things as though there was a single server, when in fact there are multiple servers.
You don't really need the help of perforce tech support. If you have administrators, you may need them to set up a target depot and/or provide access, but the basic task is performed using functions available to the general user. 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) repeat for all subsequent changelists in order until done. 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 be preserved - 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.
Related
One question i have, After creating a stream from classic depot(consider it as main branch) we will be working on stream (mainline stream). If suppose when some developer is not aware that streams are in and made check-ins in classic depot mian branch and if we want to get those changes from classic deport to respective mainline 'stream' is it possible ?
If suppose when some developer is not aware that streams are in and made check-ins in classic depot mian branch```
Use p4 protect to remove write access to your main branch if you don't want people submitting to it. That's much easier than trying to relocate changes that went to a place they should never have gone to.
Generally speaking, though, if a change is made on the wrong branch/stream, the easiest thing is to merge it to the right one. You can also undo it on the original stream 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 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'.
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.
Can user have private area on Perforce server ?
This area will be used by user to check-in code/files for which exact target branch is undecided.
Also this area wont be shared, so this code is not visible to any other user other than himself. Not visible to other users should be preferred but not a must to have.
At our company, we have a Sandboxes portion of the depot, with individual users having directories underneath that. It doesn't use any permissions or anything technical from Perforce to enforce this, but it is generally understood that a user's sandbox area is just for that use, liable to have broken or partial code, and shouldn't be relied upon for anything (or even to exist in the same form from one day to the next).
We also have some sandboxes for specific projects that show up once in a while. It might make other users curious, depending on how the sandbox was named, but the same general idea applies to them - just with a few more users working in the area, so a little bit less likely to arbitrarily change.
One benefit of this is the ability to tell another user that they can pull some changes made in a sandbox, or look at them for ideas, if desired. You would lose that possibility with restrictive permissions.
Assuming you are the admin (or know the admin) of the Perforce server, you can use the protections table of Perforce to accomplish that. With the help of the manual, what you need to do is
Set up the branches (if they don't exist yet)
Give the user all rights on his branch (list, read, write).
If you want to prohibit branching off of that location, specify the =branch right.
For all other users, you'd deny those rights (i.e. =read, =write).
I want to add that this protection table could grow pretty big (depending on the number of Perforce users you have) and you need to be sure that the benefit is worth the hazzle.
Sorry if I've misunderstood the question, but I think the functionality you require is called "Shelving".
In P4V, you can right-click on your pending changelist and select "Shelve". This has the effect of "checking in" in the sense that your code is safely held on the server, but it's unlike checking-in because your code doesn't go into any branch of your project.
Normally other users won't see the contents of your shelves, but, depending on permissions, it is possible for one user to browse another's workspace and see his shelved files. Even so, it will be clear to them that they're looking at shelved files.