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.
Related
in Perforce I go to the Stream Graph every morning to bring updates from parent stream to my feature stream. I always see a red arrow going from my feature stream to the parent. This marks that there are changes in my stream that the parent is missing, so that's normal.
Today that red arrow is gone and in history I can't see anyone merging my branch to the parent (And no one would have any reason to do so since the feature just started development and had some minor changes merged with no actual functionality yet)
I closed Perforce and re-opened it but the arrow is still gone, I fear I messed something up somehow.
Any ideas/suggestions/things I can check?
The hypothesis is that there is a change in your feature branch which has not been merged to the parent but which is not being shown in the stream graph. Let's look at some of the tools we have in Perforce to prove or disprove this hypothesis.
The very easiest thing to check is: what happens if you do a merge from the feature stream to the parent? Run a merge in "preview" mode -- does it say that there are files to merge? If so, then we know that merge is doing the expected thing, but the stream graph is out of date with it. This could be the result of the stream having been edited recently in a way that temporarily invalidated the cached merge status (see this article for more discussion).
Let's suppose that merge agrees with the stream graph. The next tool is to make your hypothesis more specific: identify a particular changelist that should require merging. The most recent changelist on your feature branch should be a good candidate. Open one of the files in that changelist in Revision Graph, and look for arrows between it and the parent stream. Is there:
any kind of arrow from that revision back to the parent stream?
a "copy" arrow from the parent stream overwriting that revision?
either of the above but indirectly via some other stream?
If there's none of the above, and the file still doesn't require a merge, check the stream definitions. Is that file in a share path, or is it isolated from the parent? Are the options set to globally block or allow merges from this stream to the parent?
I found what was causing this behavior, somehow the checkbox to allow merging to parent was unchecked. I did not do this so I'm not sure how it changed, I will ask the team if someone changed it since I got no message about it.
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.
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.
We are investigating a workflow in Perforce where we create a new temporary branch for every feature project. When projects are stable, they're integrated back into our main branch. Down the line, we would like to remove old project branches from the repository. However I believe this will also delete all revision history for the files modified in the branch. Is it possible to integrate the revision history from the project branches into the main branch?
One solution that I've considered is to manually integrate each individual checkin when merging code back into the main branch. This does not seem like the right approach.
The revision histories as stored against the branch they are applied to, so it is not possible to merge from one to the other. Your idea about integrating each changelist from the project branch will work, but is also a pain as you have pointed out.
I've made extensive use of branching over the years and I can't remember a case where we wished we'd had the branch revision history in the main line or even looked at the branch revision history after the branch was merged back into the main line.
You'll have the revision histories available (though not directly) for a while after a merge and (ideally) anything you check in to the main development branch should pass all the unit tests so the chances of it breaking should be minimised.
First of all, why do you want to remove the branches from the repository? Are you noticing having multiple branches to affecting performance (or expecting it to)? For each 'temporary' branch are you taking an entire copy of the main line? Also why do you consider these branches 'temporary', I would argue if they are for a feature then they are not and should be preserved.
A few articles to read:
- P4 KB Sparse Branching
- P4 Blog: Perforce Anti-Patterns Over-Branching
I believe, without knowing more information, that you could: use sparse branching, make these 'temporary' branches permanent, and if you really have a need for a temporary branch create a private working branch for each of your developers.