I've performed integration (p4 integrate) and then resolved conflicts in all files (p4 resolve ...). After that I noticed that one conflict could be resolved better by providing additional edits.
I want Perforce to think that the additional edits (after p4 edit file/in/question and vim file/in/question) are part of resolution, not an separate edit.
How can achieve this using p4 command line tool?
If you do p4 edit and make the edits, they will be part of the same atomic changelist and the same revision.
(It is possible to make the edits in such a way as to have them not get propagated back to the source on a reverse integrate, by "hiding" them in the merge, but you probably don't want to do this because it likely means you'll end up re-resolving the conflict later.)
Related
Our perforce project has exclusive lock on, so we can't checkout files other people have checked out. Is there a way to bypass checking out the files and shelve the local changes directly?
I've tried using "p4 reconcile" and "p4 print" with no luck.
I don't think it's possible to do this (at least not without circumventing the +l protection, which is possible on some server configurations), since shelve only operates on open files.
The idea of exclusive-open (+l) files is that because it's not possible to merge them, you never want someone making changes that are based on anything other than the latest version (including whatever version someone is currently working on). So making a shelf of a +l file would go against the intent of that (since your shelf would be based on the current depot revision and would not include the other user's changes).
If this is a file where it does make sense to modify it concurrently, it probably should not have the +l type. IMO the +l type should be used sparingly or never. You can ensure that you will not need to resolve changes by using a normal p4 lock, which allows other users to open and shelve the file at any time but not to submit it until the lock is released; figuring out how to resolve and submit after you've submitted your changes will be their problem.
If you don't have control over whether this file uses +l and you need to get your changes onto the server, my recommendation would be to branch the file (+l doesn't prevent that, even though it probably ought to) and submit/shelve your change to the branch.
I have a file on another branch which contain a change I would like to integrate. But it contains other changes too which I don't want to integrate yet.
How can I integrate the file only partially?
I first integrated and resolved the file as usual, then I did a "p4 edit" on the file after that to remove the changes I don't want to go in yet. "p4 opened" said that the file is opened for edit, so I thought the commit will submitted as an edit not an integration. I was wrong! It still updated the integration history! So if I attempt to integrate the rest of the changes later the perforce will say "all revisions integrated", and the only way to resolve the problem is integrating by disregarding the integration history, which is painful to resolve.
How can I avoid this next time?
EDIT:
To clarify I mean there are multiple changes in a single revision of file and I want to integrate only a part of it.
(edited to reflect that the question is about partially integrating a revision, not integrating a single revision of a file)
Since a revision is the smallest atom of change in Perforce's metadata, you won't be able to record that a subset of a revision was integrated -- and since you don't want to record that the entire revision was integrated (thereby "ignoring" the rest of the revision for future integrations), rather than doing this as an integrate, I'd do it as an edit:
p4 edit target
p4 print -o theirs source#n
p4 print -o base source#n-1
p4 merge3 base theirs target > target
rm base theirs
(edit target)
p4 submit
Another option would be to initially open the file for integrate and then clear the resolve record by reverting (use the -k flag to keep local changes) and reopening for edit:
p4 integrate source#n,n target
p4 resolve
p4 revert -k target
p4 edit target
In general if there are multiple independent changes you're making to a file such that you might want to be able to cherry-pick and/or track them independently at a later date, submitting them as independent changelists will make that much much much easier. Shelving can help with this if you realize only after making a big change that it'd make more sense as a series of smaller changes -- shelve your big change, revert some parts, submit the smaller change, then unshelve the big change and continue.
I have an uncommitted changelist which contains a new file. I've integrated another file in (and I can see that operation in p4 resolved) but now I've changed my mind and want to remove the integration.
I could just revert the file and start over but it seems like there should be a better way. There could be other integrations that I want to preserve, for example.
Can I remove a specific pending integration without reverting the whole file?
I am not sure there is a way, because it is seems the granularity of Perforce is at the file level.
To preserve the content of your file, you could use
p4 revert -k [file]
p4 edit [file]
If necessary you could then integrate/merge and resolve with accept yours.
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.
in perforce, i have a pending list with some changed files. now i want to revert to the base, but without loosing my changes, so i want to back them up somewhere. like saving the DIFFs of each file. at a later time, i want to restore those changes and continue my work.
is this possible? if so, how?
thanks!
there is no need for external tools at all, assuming you are on a unix machine (or have a proper cygwin setup under Windows, haven't tested it.) The only caveat is that Perforce's p4 diff produces an output that is slightly incompatible with patch, therefore you need it to point to your unix diff-command. In your client-root you can do
P4DIFF=/usr/bin/diff p4 diff -du > pending-changes.patch
optional (if you want to revert the open files from the command-line, otherwise use p4v):
p4 revert `p4 opened|awk -F\# '{print $1}'`
Later you would open the files for edit (can be automated by extracting the affected files from the patchfile pending-changes.patch and then:
patch < pending-patches
Depending on your path-layout in your client-root, you have to use the -p#num option of patch to get the patch applied cleanly.
You should be able to do a shelve. It's a way of saving a changelist for future editing. The link below is a Python add-in for Perforce that implements shelve. Also, I know that Practical Perforce has a couple of ways to shelve current changes without an external script. I don't have the book in front of me but I'll try to update this question tonight when I do.
http://public.perforce.com/wiki/P4_Shelve
Linked to from P4Shelve, is P4tar which looks very useful, and does the operations on the client, rather than branching on the server.
Certainly I'll be looking into doing similar things soon.
See also this question:
Sending my changelist to someone else without checking in.
It's basically the same thing.
Create a branch of these files in some appropriate location
Check out the branch versions of the files you have edited
Copy the edited files over from the trunk and submit them
Revert the files on the trunk
Now you've got those "diffs" you wanted safely archived. When your ready to apply those changes later on, just integrate them back into the trunk.
This is what the Python script, that Brett mentioned, does. This is the way to do it manually without any special tools.