p4 changes #2018/09/27,#now is working, but I want to know the change in certain directory like //A/B
p4 changes #2018/09/27,#now //AA/B... and
p4 changes //AA/B... #2018/09/27,#now are not working, only returns all the changes from the beginning.
It's one parameter:
p4 changes //AA/B/...#2018/09/27,#now
If you pass it as two separate parameters, first you'll get all changes matching the first one, then all changes matching the second. What you want is all changes that match the entire set of restrictions.
Related
I am trying to merge a file.
I have the main branch and another branch B that was branched from main.
Both branches have changes. The main branch was merged to B at some point; but the merge on B was undid directly afterwards. After some more changes on both branches I'm trying to merge again but perforce selects the incorrect base file revision from the main branch.
I need to be able to select the common base file manually so that it will do the merge correctly. Unfortunately I was unable to find any way of doing this. If anyone knows how to resolve this, that would be much appreciated.
If the merge was undone via the p4 undo command, you should be able to redo it with a regular merge operation by setting the dm.integ.undo configurable:
(p4 help undoc)
dm.integ.undo 0 Enable re-integration of undone changes
With that configurable enabled, the "credit" granted by each integration is considered to be nullified by an "undo" operation, making each previously merged revision eligible for a merge as if it had never been merged previously. (The default behavior is for the undo to be considered the same as an edit, so that it's combined with unmerged changes, but previously merged changes aren't re-merged.)
If that's not an option, the best solution is to use the -f flag. Specify the exact range of changes you want to merge, along with the -f flag, and the revision immediately before that range will be used as the base. E.g.:
p4 integ -f main/...#100,400 B/...
will use main/...#99 as the base for the resolve(s).
Suppose we have a single text file in 2 branches:
//depot/work/branch1/file.txt
//depot/work/branch2/file.txt
We also have a central source file here that both branches depend on.
//depot/work/ImportantFile.txt
I make local edits to ImportantFile.txt and branch1/file.txt, but I also want to duplicate those edits to branch2/file.txt because ImportantFile.txt now expects all branches of file.txt to conform to a certain specification. As far as I know I have only 2 options, neither of which are ideal:
Manually make the same edits on both files and submit both changes in a single changelist. The problem with this, is that I would like P4 history to know that these files are still 100% integrated, but the history will show that they were edited independently.
Only make edits to branch1/file.txt, submit just this file as well as ImportantFile.txt in one changelist, then immediately integrate the change to branch2/file.txt in a 2nd changelist. Now the problem is that I've broken the build for a minute or two until branch2/file.txt gets the required changes.
How can I edit a file, and directly integrate those edits to another file before I submit those edits to the first file?
First off: you may already know this (and have had to make peace with it for reasons beyond your control) but:
ImportantFile.txt should not be outside of your branching structure. If your versioned files depend on it, it needs to be versioned itself, and that means it needs to exist independently in each branch, because branches are a part of your versioning scheme. Alternatively, maybe file.txt should not be branched, if it's required that it be identical in all branches at all times -- why branch something that's not allowed to diverge? But I suspect that just branching everything is the better solution.
Now for the workaround. (If you can't fix the root cause as described above, you've probably got a lot of this sort of thing in your future.)
p4 copy //depot/work/ImportantFile.txt //depot/work/NotABranch/ImportantFile.txt
p4 copy //depot/work/branch1/file.txt //depot/work/NotABranch/file.txt
p4 submit -d "Not a branch! (wink)"
Make your edits in //depot/work/NotABranch and submit them. Nothing is broken because, as stated, this is not a branch, and so it's exempt from whatever policy it is that forces all branches to move in lockstep. Now you can do:
p4 integ //depot/work/NotABranch/ImportantFile.txt //depot/work/ImportantFile.txt
p4 integ //depot/work/NotABranch/file.txt //depot/work/branch1/file.txt
p4 integ //depot/work/NotABranch/file.txt //depot/work/branch2/file.txt
p4 resolve
p4 submit
The merge history shows that both branches of file.txt were pure merges from a single common source, and so future integrations between the two should recognize that they don't need to be re-merged.
I need to list all changelists of a steam between two revisions.
p4 changes command can list all changelists that we submitted into a branch in between two revisions.
p4 changes //depot/stream/...#from_revision,to_revision
While this command works great, it will only show changelist that were directly submitted into that branch. Changelists that were merged/integrated from other branches will be missing.
p4 changes command does offer a -i option to include integrated changelist.
p4 changes -i //depot/stream/...#from_revision,to_revision
However, it seems that -i option and revision specifier does not work well together, as I get revision outside of the range. To be more precise, revisions prior to from_revision are not correctly excluded while, strangely enough, revision after to_revision are as expected filtered out !
Any help appreciated on this issue !
Thanks !
If you want changes across all streams within a specific range, leave off the filespec: p4 changes #from_change,to_change
When you use the "-i" option it shows you contributing changes (via integration) to the changes in the range that you specified. The contributing changes are not restricted by the specified range, since that would usually defeat the purpose -- e.g. if changes were integrated from //depot/source/... to //depot/target/... and you run p4 changes -i //depot/target/..., the entire point of the "-i" option is to show you the //depot/source/... changes that fall outside of the //depot/target/... specification, so the file spec is not applied to the source changes discovered by -i. The exact same logic applies regardless of whether there is a revision specifier attached to the file argument.
If you want to get changes that contribute to a particular range but you want to further restrict the contributing changes, the best option is post-processing -- run p4 changes -i and then sort/limit the output to include changes from the range you're interested in.
Here's our situation:
We copied the contents of stream A, which was change to our security infrastructure up into main.
Then we merged the contents down into stream B.
Then we made some other non-related changes in stream B.
Then we realized the changes from stream A weren't working as well as we thought and we decided to back it out to be safe.
We backed out the revision that included the updates from stream A.
This had the effect of deleting some of the files and changing others.
We tested without the stream A changes, and everything worked.
Meanwhile, the developers made a couple of small changes in stream A and we are ready to merge stream A back into stream B.
The problem is, we can copy up to main, but we can't get those changes back down into stream B, as the "remove stream A" changes are newer. We want all the changes we previously backed out back in, as well as the new changes.
Is there any way to do this without resorting to a tremendous manual effort to either manually copy or manually merge everything?
Thanks.
Start by running p4 changes -i #n,n where n is the changelist number of the merge from main to B that contained the A changes you backed out. That gives you a list of changes, the first of which is n itself, and the rest are the changes in main that you will need to re-merge to B. However, you can't use 'p4 merge' to re-merge, but instead will have to use 'p4 integ -f'.
For example, say n is 1000:
p4 changes -i #1000,1000
Change 1000 ...
Change 994 ...
Change 991 ...
Change 866 ...
This tells you that you have to re-merge 866, 991, and 994 from main to B. If you weren't cherrypicking, you can assume that these are contiguous changes in main and that you can use 866 thru 994 as a revision range:
p4 integ -f -r -S //stream/B #866,994
p4 resolve
p4 submit
(This integ command example assumes that //stream/main is the parent of //stream/B. And you have to be in a //stream/B workspace to do this, of course. And for best results, you probably want to make sure your workspace is completely synced and that you have no open files before running the integ.)
I'm not familiar with Perforce streams, but traditionally Perforce does not have any special notion of backouts. Backing out a change simply creates an inverse changeset.
Therefore, to reapply a backed-out change, you should be able to just back out the backout.
You can always backout your backed out changelist. This way you'll get to the point where the first changes were made.
Bear in mind that all files history is saved so all changes are supposed to be easily recovered in situations like yours.
Your most recent change is the delete, so it wouldn't re-add the file as its already opened for delete. Run a p4 revert on that file, and then do a p4 add, it worked for me.
Is there any easy way to exclude a specific changelist from p4 sync?
I want to sync up my code, but I don't want to fetch the changes from changelist #1337
Like: p4 sync //depot/source/... - //depot/source/...#1337?
The best way to accomplish this is just sync to head, and then use the 'Back out submitted changelist' function in P4V ('Submitted' pane, right-click the undesired changelist, select 'Back out submitted changelist').
This will create a new pending changelist in your workspace with the undesired changes removed.
It is possible by syncing to a range and using two commands to "skip" the changelist.
p4 sync //depot/source/... - //depot/source/...#0,#1337
p4 sync //depot/source/... - //depot/source/...#1337,#head
Note: you may have to specify the changelist on either side of the one you want to skip - not sure if the range is inclusive.
HTH,
Dennis
Ok this should work depending on what you want to do. Man I really miss git :(
If you simply want to sync and temporarily ignore a changelist you can do what the first reply said and back out the change list. Just remember to not check that change list in unless you want to wipe out the ignored changelist for the branch. However this approach will not work if you need to make changes to files that exist in the ignored changelist.
If you need to work with the same files from the ignored changelist you can do the following. One thing to note however, is that the ignored changelist will be pulled out of the remote branch until you are ok with them being in your code. (there is one other option but requires someone else to do something)
If you want to ignore a change list, and not get rid of it completely but simply be able to work on your code with it off to the side, the following will work.
Back out the changelist as previously stated.
Submit the backed out changelist to wipe out the changes in the remote branch. (don't worry)
Now do another back out but this time back out the chagelist created by the previous back out and shelve it. This back out of the back out will be a pending change list that is basically a copy of the one you wanted to ignore. Once its shelved you can go about your work, even in the same files. The down side is that now the ignored changelist only exist on your work space and its up to you to submit it or decide what to do with it at some point.
You can keep the ignored change list shelved until you know what you want to do with it. If, after you work on your code, you want to re integrate that chagelist and merge it with yours you can simply unshelf it and resolve conflicts.
So the (other option)
You could do the above with help from another dev with a perforce account (perhaps the one who's changelist you want to ignore) in this case you could have them back out the changelist and submit, then you could sync, then they could back out their back out. In this case the remote branch would not need to stay in weird state while you worked on your code. The big downside is, that you would have to do this every time you wanted to sync.
A better option would be branching before an issue like this arrises but that is not as easy or light weight in perforce as it is in git.
Hope one of these options help or spark a finale and perfect solution from some one else.