In perforce I have a repository in depot. I want to make a copy of this repo under tasks or streams. Speaking with git terminology - to make a fork. How can I make it? I have a write-access to a repo in depot.
Since I might confuse perforce terms, I will show with screenshot examples:
Under depot I have several folders like this:
I want to copy one of the folders under depot and paste it under streams as shown on here:
I'll give two different answers, neither of which uses the word "repo" or "fork" since those aren't terms in Perforce and they could mean two different things ("repo" could be a "depot" or a "server" -- the confusion is compounded by the fact that people sometimes say "depot" to mean "server" if their server only has one depot):
To branch a path //depot/thing from your classic depot depot into a new stream on the same server:
Create a new stream depot: p4 depot -t stream streams
Create a new stream: p4 stream //streams/thing
Populate the stream from //depot: p4 populate //depot/thing/... //streams/thing/...
To clone that path from your shared server into a mainline stream on a new personal server:
p4 clone -f //depot/thing/...
(The p4 clone command automatically creates a stream depot, a mainline stream, and a client workspace on your personal server that will be created in the current working directory -- you should run this someplace outside of the client workspace that you use on the shared server.)
I just create a new depot in the GUI and then add a new stream (again from GUI) make it a top level stream and then it asks if you want to branch an existing stream across. Select the depot/stream you need to fork and then it will copy that into your new stream.
Related
Recently I started working at a new place and my company uses Perforce as their source control.
From what I saw, my team members are working on a task and when they finish the task they just submit the files. In case they need to stop working on the current task and move to another one, they shelve the files and move to the different task. This means, there is a shelve per task, but there is no way to view local history of things that were done as part of the task. This results large changes at every submit, and it is not possible to easily return to a working state as part of the current task.
In the past, I have been working with git. With git, I would commit very often and I was able to easily view the history of the changes I have done, even in the short term.
For example, before renaming a variable I would always commit, and then if something gets messed up, I would just revert it without even thinking and trying to dive into debugging of what is wrong. As well, when developing a feature and having basic things that work, I would commit so I would just be able to easily return to that state.
What I started to do is manually copy the files I am working on to a local git repo and then commit things over there, and then copy them back to perforce before submitting them. This is definitely a bad idea.
I am aware to the fact the git and perforce are fundamentally different, and I wanted to know what is the recommended way to work when working on a large task at perforce without accidentally destroying my work during the development.
I am working on a gigantic project, and working with git-p4 and syncing all the changes is impossible. As well, I tried to look at: Perforce equivalent of git local commit but it still means there is a shelve saved for each state I want to save, which is not very convenient.
The standard way of doing this in Perforce is to use a branch; unlike shelves, branches maintain full version history of everything. There are three basic approaches to consider:
Create a single personal dev branch that you stabilize all your changes in before merging them back to the mainline branch. After everything has been stabilized and merged from your dev branch to the mainline, your dev branch can be updated to the latest mainline state and you have a "clean" basis for your next batch of changes.
Create a new task branch (or task stream if you're using streams) per major change. This can be a bit heavyweight if you have a lot of files in a "classic" branching model, but if you're using task streams, you can unload the task stream after the task is done to prune the unchanged branched files from the active depot history (similar to what happens when you squash a branch in git).
Create a personal server via p4 clone. This is the most git-like model -- you instantiate an entire new server on your local machine, where you can create all the branches you want with no impact on the shared server. When your changes are ready, you p4 push them back to the shared server. p4 fetch is used to pull newer changes from the shared server and "rebase" your local changes onto them if required.
I've usually opted for the first approach; the main potential drawback to it is that if you have multiple major destabilizing changes in flight at the same time, it's hard to isolate them from each other in a single branch, but in practice this is a situation that hasn't come up very often for me.
My project is somewhere in the order of 100 GB per stream, with an additional 60 GB added to each workspace for local local cache files.
Rather than downloading and rebuilding from the depot every time I need a workspace for a new stream, is there a way to copy a workspace I already have downloaded and set up, then have Perforce recognize it as part of a different stream?
Where your first workspace is clientA rooted at /home/clientA and your new workspace is going to be clientB, do:
cp -r /home/clientA/ /home/clientB/
p4 set P4CLIENT=clientB # or use P4CONFIG files
p4 client -t clientA
p4 sync -k #clientA
p4 clean
Now you have clientB set up as a copy of clientA -- the sync -k command tells the server "sync everything that clientA has but don't send me the actual files, just pretend that I synced them." The p4 clean command should be a no-op, but if you somehow messed up the copy or you had open files in clientA or something, this will fix it by forcing a re-sync of the files that are wrong.
Now that you've done that you can do:
p4 switch STREAMNAME
which will switch you to a different stream, syncing only the files that are different. Many people just have a single workspace and use p4 switch to hop between streams; it automatically stashes your work in progress and everything, and you conserve local disk space by not having multiple copies of everything. (A good case for having multiple workspaces would be if you have the space to spare and you don't want to rebuild those 60GB of cache files each time your workspace contents change...)
Is it possible to create a link between two perforce repositories, kind of like symbolic links in linux.
Example:
//depot/mydir/A# -> //depot/mydir/B/
So when you try to sync //depot/mydir/A, you will sync //depot/mydir/B/...
Or integrate, or so on.
I am not sure if such thing is possible. I will really appreciate some input on this matter.
Thanks!
Remote depots might be what you're looking for:
http://answers.perforce.com/articles/KB_Article/Using-Remote-Depots
A remote depot allows you to map part of the namespace of one server into a top-level depot in another server. You might create a remote depot called "B" on your server that maps to "//depot/mydir/B" on the remote server; then when you sync //B/... you're actually syncing //depot/mydir/B/... from the other server.
I am just assuming that simple lock on the branch will lock the branch ? . will that suffice
Or is there any other special procedure to lock the branch . Please let me know if I need
Anything to do apart from just click on lock .
The owner, admins, and superusers can lock Streams in Perforce with a button click yes. When modifying a stream there is a box under the advanced tab: "Locked (only the stream owner can edit stream settings)" and another: "Submitting files to the stream restricted to stream owner"
Ok so its two clicks...these two combined effectively lock a stream for all other users.
I believe the only way to "lock" a branch in Perforce would be via the Permissions Table. This can be viewed via the admin gui (separate install) or via p4 protect on the command line. p4 protect is an admin/super user only item I believe
I need to copy a depot from one Perforce server to another. The file revision history needs to be intact but the user information and workspace information can not be copied to the new server.
I've tried a standard checkpoint creation and restore procedure, but if there exist users or workspaces with the same name on both servers, the source server will overwrite this info on the destination server. This is pretty bad if those user accounts and workspaces do not have exactly identical details.
The goal of this sort of operation is to allow two separate, disconnected groups to view a versioned source tree with revision history. Updates would be single directional with one group developing and one just viewing. Each group's network is completely enclosed, no outside connections of any kind.
Any ideas would be appreciated, i've been busting my brains on this one for a while.
EDIT:
Ultimately my solution was to install an intermediate Perforce server on the same machine as my source server. Using that I could do a standard backup/restore from the source server to the intermediate server and then delete all unwanted meta data in the intermediate server before backing up from the intermediate server to the final destination server. Pretty complicated but it got the job done and it can all be done programatically in Windows Power Shell.
There are a few ways, but I think you are going about this one the hard way.
Continue to do what you are doing, but delete the db.user, db.view(I think) and db.group. Then when you start the perforce server, it will create these, but they will be empty, which will make it hard for anyone to log in. So you'll have to create users/groups. I'm not sure if you can take those db files from another server and copy them in, never tried that.
The MUCH easier way, make a replica. http://www.perforce.com/perforce/r10.2/manuals/p4sag/10_replication.html Make sure you look at the p4d -M flag to make sure it's a read only replica. I assume you have a USB drive or something to move between networks, so you can just issue a p4 pull onto the USB drive, then move the drive, and either run it off the USB, or issue another p4 pull, pulling to a final server. Never tried this, but with some work it should be possible, you'll have to run a server off the USB to issue the final p4 pull.
You could take a look at perforce git fusion, and make some git clones.
You could also look at remote depots. Basically you create a new depot on your destination server, and point it at a depot on your source server. This works if you have a fast connection between the 2 servers. Protections are handled by the destination server, as to who has access to that new depot. The source server can be set up to share it out as read only to the destination server. Here is some info
http://answers.perforce.com/articles/KB_Article/Creating-A-Remote-Depot
Just make sure you test it during a slow period, as it can slow down the destination server. I tried it from 2 remote locations, both on the east coast US, and it was acceptable, but not too useful. If both servers are in the same building it would be fine.