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.
Related
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.
In our CI flow, we accept a shelved changelist and run the tests against it.
In order to avoid users changing the content of the changelist during the compilation/tests, we duplicate the changelist and run all tests on the copy + submit the copied changelist.
In order to avoid this complicated work, we would like to know if a shelved changelist was modified since the CI was triggered by the time our automation submit it after the tests finish.
We saw that there is a "date" field that should contain the last-modified date but changes in files are not affecting it.
Do you know a good and fast way to check when a shelved changelist was last modified without running complicated diff commands?
Thanks in advance!
If you fstat the files in the shelved change you can get some stats about them that should be useful, like the md5 checksum and the local modtime. As long as you can store these somewhere that should be a faster way of validating than re-running all the tests.
Let's say I have a project under //depot/MyProject. At changelist 1001, this project took a major change in direction, changing everything about it. At changelist 2001, it got p4 deleted. The depot is now at change 3000.
I'd like to restore //depot/MyProject back to its state at changelist 1000. Specifically, I'd like the revision history to record the fact that change 3001 is an integration of change 1000 - i.e. the last version of this project before the major change.
Can Perforce do this at all? Or do I have to rename it into something like //depot/MyProjectOriginal, because //depot/MyProject is now tainted with all those deleted revisions?
(the naive attempt to p4 integrate //depot/MyProject/...#1000 //depot/MyProject/... fails with an "all revision(s) already integrated" message)
You cannot force the integration.
You have two options: you can create a branch using changelist 1000 as the base; or sync to changelist 1000, check out all files, and then submit (a.k.a rolling back).
Option 1
If you do want the history of your changes between 1001-3000 (i.e. a fresh start from changelist 1000) then this is the better option. Using P4V, create a new branchspec and then perform an integrate from your current project to the new branch at changelist 1000. This will be submitted as changelist 3001, when you compare differences between revisions, you will not see of the changes between 1001-3000.
In the P4 visualizer this will appear as a new branch creation at 1000.
Option 2
Sync to changelist 1000, check out all files, and then submit. There should not be any conflicts to resolve. This will be submitted as changelist 3001, however when you review history you will see the everything.
I hope this makes sense, any questions, please ask.
I don't believe that you can integrate files on top of one another like that. I think that you have two options.
If you are willing to move the files, you can do a
p4 integ //depot/MyProject/...#1000 //depot/MyOriginal/Project/...
and that will integrate MyProject at changelist 1000 to the new location.
If you'd like to keep the project at the same place, you can do that as well. It's really easiest in p4v - you can right click on the folder in workspace or depot view and choose "rollback...". In the subsequent dialog, you can then pick a changelist (or date, revision, etc) to roll the folder back to. In your case, I think that you would choose changelist 1000. Stick the files into a new pending changelist (I think that this is always good practice). You can then run a preveiw (to see what would happen), save the contents to a new changelist (so that you can inspect file contents before submitting), or just go for broke and pull the trigger and submit (I generally wouldn't recommend this).
HTH
Just do:
p4 copy //depot/MyProject/...#1000 //depot/MyProject/...
This also make a nice revision graph.
Though there is an accepted answer and plenty of other solutions, none of them works for me coz I need to rollback a large directory (with GBs of data)
Here is the way I used, which works fine for huge directory:
(Suggested to do in a new and clean workspace, though not strictly required)
Assuming the directory to rollback is //depot/foo/bar and you want to rollback to changelist 1234
Make sure no one is locking any files, and make sure the directory you are trying to rollback exists in your client spec
p4 copy -v //depot/foo/bar/...#1234 //depot/foo/bar/...
p4 submit
p4 copy -v is the meat of the solution. It tells Perforce server to perform virtual copy, which means Perforce copies the files but not actually in your workspace. This avoid huge data transfer for file content (when copying and when submitting). In my case, by using "rollback" in P4V (which is doing non-virtual copy), it took over an hour just for copy, and over an hour for submit for my folder. With virtual copy, whole process took me around 1 minute.
The most important thing is, it keep a sensible history. You can see your files being updated and rolled back, and all previous history exists.
use
p4 integrate -f //depot/MyProject/...#1000 //depot/MyProject/...
The -f flag means force an integration even if they have already been integrated.
From http://www.perforce.com/perforce/doc.current/manuals/cmdref/integrate.html
I'm rather new to perforce, but have quite a bit of other VCS experience...
Imagine this:
You submit changes (changelist 1)
A colleague submits changes on the same branch, accidentally overwriting your changes. (changelist 2)
I tried integrating (which P4V refuses to do since it's already integrated) and looked around for a way to just generate a patch that I could apply, but couldn't find anything.
For now, I will check out the versions in question and use an external merge tool, but it would be great to know if perforce supports this somehow.
Is there a way using the perforce tools (preferably in P4V) to reapply changelist 1?
You can't reapply changelist 1, but you can reapply changelist 2.
Sync to changelist 1.
Check out the file(s). P4V will warn you that, "You do not have the latest revision of the file.", and ask you if you want to get the latest. Ignore the warning by clicking the "Don't Get Latest" button.
Now sync to the head revision (I'm assuming changelist 2 corresponds to the head revision). The file(s) will now need to be resolved, which you (or your colleague) can do, properly this time, without clobbering the changes you made in changelist 1.
Probably the easiest way is to retrieve the changes from changelist 1 (//depot/...#1,#1) and then going through the normal resolve/merge+submit song and dance.
Using P4V 2009.2.
I have used P4Win in the past, but this is a new setup for me.
The problem is that the files I have checked out disappear from the changelists, so I cannot check them in.
To reproduce:
Check out a file, make a change to it.
Go to the 'pending changelist' tab.
There will be a + sign on the default changelist.
Click on the plus, or on the changelist line, the plus will disappear, there will be nothing in the changelist.
Try to check the file in by right-click on the file itself, the changelist dialog will show up but NO files are listed.
You can transfer the file to a new changelist, the same thing happens.
Looking at the file in the 'checked out by' window does correctly show the changelist number & description.
It sometimes happens to me, and what I normally do is change workspace and then change back again. Not sure if there is an easier way to get it to realise the files are checked out.
the only thing I can imagine is that you are looking at a different client workspace. Notice that the "Pending Changes" tab has a filter on the top, where you can separately filter for folder/files, user and workspace. Maybe the filter is set to something so that it doesn't match the client workspace where you have actually checked out the file.
Good luck,
Henrik
You may get this if the perforce server has not been upgraded. Old versions of P4D have this error: http://kb.perforce.com/article/1167/opened-files-missing-in-default-changelist
If that is not an option, use p4Win.
I agree with jhwist,sounds like your looking at a different client spec.
P4V is a bit confusing on this front, IMO and I personally prefer P4 Win but to check, open up a command prompt and type p4 changes -s pending -c YOURCLIENTSPEC - chances are that the changes you think you have aren't in your current clientspec
This can happen sometimes and in my experience it is a refresh issue with p4v. Often simply closing the pending tab or reopening p4v solves the problem.
In my case, the pending List has over 4000 files, (due to eclipse created so many files after mvn tasks) so none of them are shown. I created a different pending list, then cleared all contents, then moved the files to the new change list. Then it is appearing in the new change list.
Modify the file directly in the correctly mapped client folder (i.e. your current workspace). You will see the changelist for sure. As jhwist mentioned clear filters if any and choose your current workspace (since you may have many)