How can I take changes from a file that I have in my depot and apply it to a file in my current workspace.
Consider the following scenario.
I have a branch A where I have submitted some changes to files a1, a2 and a3. The change number associated for this submission is 123.
Now I am in another branch B that I am currently working on. I have to take the changes of file A/a1 that I made as a part of change number 123 and apply it to B/a1.
I tried using perforce-integrate, but I am not able to make it work.
To propagate all of change 123 from A to B:
p4 integ A/...#123,123 B/...
p4 resolve -am
p4 resolve # (if needed)
p4 submit
To propagate ONLY a1#123,123:
p4 integ A/a1#123,123 B/a1
p4 resolve -am
p4 resolve # (if needed)
p4 submit
If any part of this does not work, an error message will be displayed indicating what you need to correct in order to make it work.
Related
The command p4 changes -m1 //path/to/your/project/...#have to get the current changelist, as shown by this solution, works great until we have a commit that reverts the commit immediately before it.
For example, if I have the following setup:
4 - CL#3 was reverted and submitted here
3 - Somebody submitted this CL
2 - <= Current workspace is here
1
0
I run p4 changes -m1 //path/to/your/project/...#have, I get 2 as expected
I then sync to 4 and run the command again, but I still get 2. I assume this is because there is no new file locally and perforce still thinks I am on 2 when I should be on 4.
This is an issue because it breaks some scripts that run on new CLs that are coming in. Is it possible to either ignore such CLs or adjust the command in some way to know that are on 4 even though there are no file changes (because 4 is a revert of 3)?
Reproducing your setup by adding a file in change 3 and then deleting it in change 4, we can indeed see that changes -m1 #have returns change 2:
Sams-MacBook-Pro:test samwise$ p4 changes
Change 4 on 2023/01/26 by samwise#samwise-dvcs-1517552832 'delete ola'
Change 3 on 2023/01/26 by samwise#samwise-dvcs-1517552832 'add ola'
Change 2 on 2023/01/26 by samwise#samwise-dvcs-1517552832 'add bar'
Change 1 on 2023/01/26 by samwise#samwise-dvcs-1517552832 'add foo'
Sams-MacBook-Pro:test samwise$ p4 sync #4
#4 - file(s) up-to-date.
Sams-MacBook-Pro:test samwise$ p4 changes -m1 "#have"
Change 2 on 2023/01/26 by samwise#samwise-dvcs-1517552832 'add bar'
This is because changes -m1 #have is just returning the maximum change among those returned by p4 files #have:
Sams-MacBook-Pro:test samwise$ p4 files "#have"
//stream/main/test/bar#1 - add change 2 (text)
//stream/main/test/foo#1 - add change 1 (text)
We do not have any file belonging to change 4, because change 4 consists solely of deleted revisions, which by definition are never synced to the workspace.
Sams-MacBook-Pro:test samwise$ p4 files #=4
//stream/main/test/ola#2 - delete change 4 (text)
When we sync to change 4, we don't get ola#2, we get ola#none, exactly as if we'd synced to change 2 (or any change where ola does not exist as a non-deleted file):
Sams-MacBook-Pro:test samwise$ p4 sync #4
#4 - file(s) up-to-date.
Sams-MacBook-Pro:test samwise$ p4 sync #2
#2 - file(s) up-to-date.
Sams-MacBook-Pro:test samwise$ p4 have ola
ola - file(s) not on client.
At this point it's actually equally correct to say that we're synced to either change 2 or change 4, since either will give us the same set of files. In fact, if we diff the depot at those two changelists, we can see that those two points in time are effectively identical:
Sams-MacBook-Pro:test samwise$ p4 diff2 -q ...#2 ...#4
...#2 - no differing files.
If we want to divine change 4 from our current sync state rather than just the effectively identical change 2, the p4 cstat command is a useful tool -- this will iterate through all the changes for which our workspace contains all revisions up to that point:
Sams-MacBook-Pro:test samwise$ p4 cstat
... change 1
... status have
... change 2
... status have
... change 4
... status have
Since we have all changes up thru 4 according to p4 cstat, that is likely to be the best answer to the question "what change am I synced to?"
P4 version... Proxy version: P4P/LINUX26X86_64/2013.2/821990 (2014/04/08)
Let's say I made a bunch of changes and some adds, all in the default CL, then "p4 submit"ted them . Let's say the CL generated was 12345. Then I realized that I forgot a file, made that change, submitted it and that CL is 12346. After all this is done, someone wants me to duplicate that work on another branch. Would have been nice if I shelved the changes that are in 12345 and 12346 but I didn't.
Is there a way to create a new changelist that = 12345 + 12346, which is something that I can shelve and then bring into that other branch ?
Thanks!
Technically you can do this with shelves and a lot of manual work, but what you're describing is what p4 integrate is for.
p4 integ source_branch/...#12345,12346 target_branch/...
p4 resolve -am
The change to target_branch (which consists of everything you did in changes 12345 thru 12346 on source_branch) is now pending in your workspace -- you can either p4 shelve it or just p4 submit it directly.
I have made several checkins using perforce. I have no realized that all of them are unnecessary. I would like to revert all the changes for the last x revisions in the working directory, update the version number, and check in.
I am familiar with Mercurial. The way that I would it for that would be:
$ hg revert -r last_good_changeset .
$ edit version-number.txt
$ hg ci
Is there a way to do something similar in perforce?
In Perforce, a revert refers to restoring a file to the state it was in before it was checked out. What you're looking to do is back out a submitted changelist. This Perforce KB article has a few methods to do what you're trying to do, depending on your particular circumstance.
For example, if you have revisions #1 - #6 of a particular file, and you want to roll back to revision #3, you'd do this:
p4 sync myfilename#3
p4 edit myfilename
p4 sync myfilename
You're telling Perforce to get revision #3 from the depot, check it out for edit, then try to sync it back up to #head (the latest version in the depot). Since the file is checked out from an earlier revision, Perforce schedules a resolve so you need to tell it what you want to do with the file: accept the version in the depot, accept your local changes, or try to merge the two. You'll want to tell Perforce to accept the local version (or in Perforce parlance "yours"):
p4 resolve -ay myfilename
Now that it's resolved, you can submit it with:
p4 submit
If you have a series of files you want to do this with (for example, you've edited a bunch of files in a given directory and have checked them all in together several times, and you want to back out all of those), you can use changelist syntax as well. For example, if you want to roll everything back in a given directory to changelist 123, you can do this:
p4 sync //depot/some/path/*#123
p4 edit //depot/some/path/*
p4 sync //depot/some/path/*
p4 resolve -ay //depot/some/path/*
p4 submit
This will work for any revision modifier (see p4 help revisions for alternate methods of specifying the version you want).
The rollback function is specifically designed to do this. It goes back to a certain date/time or change list # and reverts all changes in the window you give it.
Simply right click on the file in question (P4V obviously) and select rollback. It will bring up this box. Not sure how to execute from command line...Ill see if I can figure it out and add that info.
I have submitted one file in perforce, and changes submitted by other user got reverted in merge.
Changes were not conflicting.
Is their a way, I can get that user's changes back. Means revert the revert.
Also how to submit a changelist again with new changelist number?
In order to revert a file (fall back to its previous version) you simply sync the previous version and submit that again.
For a single file the procedure goes like this:
# sync file at old revision (#3 in this example)
p4 sync //depot/file#3
# mark the file for edit
p4 edit //depot/file
# make perforce aware that something has to be merged
p4 sync //depot/file
# resolve (i.e. throw away the head revision changes and save those from #3)
p4 resolve -ay
p4 submit
If you have a changelist with several files (and not only edits, but also deletes & adds) the rollback is a bit more difficult.
See also this question.
Here's a smart script for that purpose and more info.
The 2nd part of your question I did not understand.
Submitting a change again with a new changelist number doesn't make sense, since a changelist contains diffs. If it was submitted once, then the diffs are already in the depot, so you can't submit the same diffs again.
I am facing an issue of merging due to bad scm practices followed. I gave a build off of a perforce branch when the latest changelist # was, lets say, 1000. Now after the dev team has submitted many more changelists the latest changelist # is 1050. Issue is that smoke test on the build failed and now I fixed it and submitted a changelist # 1051.
My question is there a way to somehow merge the change made in 1051 into 1000. Or in other words create a build with all the changes upto changelist # 1000 and including only changelist # 1051 as well.
I hope I was able to explain the issue in a way that makes sense.
P.S: I know the concept of Main, Release, and Dev branches. Somehow now I am in this mess of giving a build off of the dev branch and looking for a solution.
One way is to create another branch, as in:
p4 integ //depot/build/branch/...#1000 //depot/bugfix/branch/...
p4 submit
p4 integ //depot/build/branch/...#=1051 //depot/bugfix/branch/...
p4 resolve
p4 submit
Now build //depot/bugfix/branch and give that to your test team.
Try
p4 sync //depot/branchname/... #1000
p4 sync //depot/branchname/... #1051,#1051
This tells perforce, sync the workspace to changelist 1000. Then 2 says sync all files from changelist 1051 to 1051, basically it means only sync the changes that are in changelist 1051. You can use p4v as well
Right click on //depot/branchname and Get Revision, then type in 1000 as the changelist.
In the submitted tab on the right, right click on 1051, Get Revision. Click tha add button to add //depot/branchname, type in 1051 as the changelist, and then check the "only get files listed in this changelist" checkbox.