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.
Related
I have this revision graph from perforce and I am baffled how we managed to produce this graph. The part I find most puzzling is the part with the red square around it with revision 6 of row 2 being merged twice. The first time revision 6 is merged to revision 8 but with revision 11, I have never seen two revisions merged at the same time from separate branches. The second time revision 6 is merged like a normal merge but this file has been renamed for some time now so I don't know why the delete would suddenly get merged again. Can anyone explain the scenarios under which this can happen?
The top two rows are our trunk, the first row is our current trunk, the second row is the file before it was renamed, and the bottom row is a branch, we have many branches with the same strange merges in this branch.
A lot depends on how revision #6 was created. If you select revision 6, and open the "integrations" tab in the details pane, you can click on the source(s) of the integration(s) to reveal them in the graph.
A delete on top of a delete suggests that this file was re-added (under the old name) in some other branch, and then something unusual happened with that file that entailed the creation of an extra revision on the trunk for record-keeping purposes. The relationship between that revision and revision #12 of the "new" file may be significant -- it looks like there are effectively 5 different file variants sharing 2 different names in this history graph, and maybe there are additional variants that we can't see here.
You may also be able to get some information by clicking on the specific revision you're curious about (#10 on the bottom?) and reading the changelist description.
In general, a merge operation will propagate whatever has happened in the source that has not yet happened in the target. It does this by setting up a resolve, and in some cases the choices made during a resolve operation may negate some part of the changes made in the source and target (although the default option, where possible, will be to preserve and combine both). So the final outcome of a merge depends on its inputs, and what happened during the resolve, and the inputs in turn may be influenced by merges from elsewhere (and resolve choices made as a consequence of those merges), and so on.
Note also that not every arrow you see in a revision graph is the result of a merge -- copy has its own semantics, and a forced integrate via p4 integ -f has its own as well. (This is where reading the changelist description is useful -- hopefully the author of the change will have left some record there as to what their intent was and anything unusual they might have done, which can shortcut a lot of tedious forensic work.)
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.
I maintain a family of branches, .../base/..., .../base-staging/..., .../base-production/.... Changes are usually made in base, reviewed, and then integrated out to base-staging and eventually base-production. Before an integration, I typically do a p4 interchanges to confirm that only expected changes will be carried forward.
Usually this works. But sometimes p4 integrate pulls over files and changes not listed by p4 interchanges. By my understanding, that shouldn't happen! What am I misunderstanding?
Details:
Ancient history:
create .../base/...
p4 integrate base/... base-staging/...
p4 integrate base/... base-production/...
make changes in .../base/... and submit
p4 interchanges base/... base-staging/...
review and approve
p4 integrate base/... base-staging/...
whoah! what are all these other listed files???
review: real changes, made well before my interchanges command, but not mentioned therein
I'm going to assume we're talking about a relatively recent server release -- on older releases "interchanges" will indeed match exactly what "integrate" lists, but in newer releases they diverge a bit in order to address the subtly different common use cases of the two commands.
One of the functions of "integrate" is to record history that ensures that future integrates behave in a predictable fashion. In some edge cases that means opening a file for integrate even though no actual changes need to be propagated to the target, so that it can be recorded that the file is up to date. A very simple example: make a change in A, ignore from A to B, merge from B to C, now merge A to C. Your expectation will typically be that integration is "transitive" such that if A->B reports nothing to do and B->C reports nothing to do then A->C will report nothing to do; if the B->C merge skips the change because it was an "ignore", though, then the A->C merge has no record that the B->C merge was ever even attempted, and it will propagate the change, violating the expectation of transitivity.
"Interchanges", however, does not record any history, and it is usually desirable for it to limit its scope to report only source changes that are not present in the target. It's therefore tuned to produce a smaller set of changes than you might get by running "integrate". The changes that are excluded from "interchanges" but included by "integrate" are typically going to be ones that do not strictly require merging, but that will probably make it easier to merge the "required" changes if they're included as well.
Using the "-Rs" flag on "integrate" will cause it to mimic the "interchanges" behavior and select the absolute minimum set of source revisions. It's briefly described in this old blog post from when it was introduced:
http://www.perforce.com/blog/101206/p4-integ-3-exciting-things-afoot
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 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.