In Perforce, what is a "shelved" file? What is the purpose of shelving a file that is open for edit in the workspace?
From the Perforce documentation:
Shelving is the process of temporarily
storing work in progress on a Perforce
Server without submitting a
changelist. Shelving is useful when
you need to perform multiple
development tasks (such as
interruptions from higher-priority
work, testing across multiple
platforms) on the same set of files,
or share files for code review before
committing your work to the depot.
The p4 shelve command creates,
modifies, or discards shelved files in
a pending changelist. Shelved files
persist in the depot until they are
discarded (by means of p4 shelve -d)
or replaced by subsequent p4 shelve
commands.
After shelving files, you can revert
or modify them in your client
workspace, and restore the shelved
versions of those files to your
workspace with the p4 unshelve
command. While files are shelved,
other users can unshelve the shelved
files into their own workspaces, or
into other client workspaces.
Files that have been shelved can also
be accessed with the p4 diff, p4
diff2, p4 files, and p4 print
commands, using the revision specifier
#=change, where change is the pending
changelist number.
If no arguments are specified, p4
shelve creates a new changelist, adds
files from the user's default
changelist, and (after the user
completes a form similar to that used
by p4 submit), shelves the specified
files into the depot. If a file
pattern is given, p4 shelve shelves
only the files that match the pattern.
Related
We are using the following P4 command for snapshot versioning.
p4 changes -m1 /path/to/files/...#have
I noticed that the above command doesn't capture CLs of deleted files if the CL is the head CL.
So it ends up having two artifacts with the same version but different files.
I was wondering how we can cover this edge case?
This is an artifact of the fact that deleted files aren't synced to the client and will therefore never be included in #have.
If possible, the best way to address this IMO is to capture the changelist at the time you sync to the head revision. Do:
p4 changes -m1 -ssubmitted /path/to/files/...
and then use that changelist to do:
p4 sync /path/to/files/...#CHANGE
Since submitted changelists are immutable (outside of edge cases like obliterate and +S files) you now have a guarantee that anyone else syncing to that same path#change will get the same set of revisions that's in your workspace.
Note that the p4 changes command will capture changelists with deleted revisions, even if those revisions are then skipped by the p4 sync!
Suppose I've made some changes to a bunch of files and sent the changelist for review. The review may take up to 24 hours. During that time I might need to edit some of the files in the changelist, but when review is over, I'll need to be able to get back to the version of the file in the approved changelist. What options do I currently have to do that in Perforce?
One option that comes to mind is stashing the files and then reverting when needed, but in this way I'll lose the changes done on top of the stashed versions.
I've read about using task streams, is it something that can help me handle that situation?
I assume that the files have been shelved in the changelist for review (as opposed to emailing them off or using some other review mechanism). If so, I'd move the open files to another changelist:
p4 change
p4 reopen -c (new change) (files)
and continue working on them. The shelved versions of the files will stay in the old changelist.
If you need to go back to the old changelist, shelve your new changelist:
p4 shelve -c (new change)
and then revert your open files (they should be safe in the new shelved changelist now) and unshelve the old changelist to keep working from that point:
p4 revert (files)
p4 unshelve -s (old change)
There are lots of variations on this you could do, such as reverting and starting over from scratch rather than building your newer changes on top of the changes that are currently under review. If you do that, you'll need to merge the changes later, but Perforce will track all of that automatically and prompt you when it's time (as long as you're using Perforce commands to sync/revert/unshelve/etc -- if you start making your own backups and restoring them manually all bets are off because Perforce doesn't know what your edits are based on any more and can't guide you through the merge process intelligently).
I have a changelist #1234 which I shelved from destop1. It has 5 files but I want to add another file to it say 6.c. The problem is when I do p4 edit -c 1234 6.c from desktop2, p4 errors out something like change 1234 belongs desktop1. desktop1 and desktop2 are different workspaces under same user.
How to release changelist 1234 and let me allow to do this?
One approach is to create a second changelist: using the desktop2 workspace, do 'p4 unshelve -s 1234' which will unshelve all the files into your second workspace in the default changelist. Then do 'p4 edit 6.c' on desktop2 and make your changes. Then do 'p4 shelve' and create a new shelved changelist (it will have a different changelist number).
The advantage of this approach is that you still have the first changelist in case you decide that you preferred the first version.
You can test the one changelist, then test the other, and decide which one you want to keep.
When you're all ready, you can submit the changelist you decided that you like, and delete the changelist that you decided not to keep.
what is the process to rename the files in depot without getting any conflicts?
Is there any way either in p4 or command line?
Yes, but the method depends on the version of Perforce you're running. Here's how to do it from the command line (this is copied from the output of "p4 help rename").
In release 2009.1 and higher, you can use 'p4 move' to move or
rename files. Perforce clients prior to release 2009.1 do not
support 'p4 move'. However, files in older clients can be
renamed by branching one file to another and deleting the
original file. For example:
p4 integrate fromFile toFile
p4 delete fromFile
p4 submit
For further information, see the help for the individual commands.
Note: Files renamed in this way are treated as branched files
rather than moved files in subsequent operations.
I accidentally submitted a wrong changelist to my perforce server. I then backed out that changelist using the "backout changelist" option. But, these two changes appear in the history of all those affected files that they were once deleted and then added back again.
I want to be able to delete the history from perforce server of these two changelists. Is it possible. Can it be done via some Perforce administrator command.
EDIT: I have seen p4 change -d -f which can delete a changelist but this requires to use p4 obliterate on the files which were there in the changelist. Does this mean that I have to obliterate all the files which were affected by the changelist. This doesnt seem a viable solution for me as I do not want to delete those files. Should I only obliterate those specific two revisions of the files due to the two submitted changelists?
Your perforce administrator could call p4 obliterate to completely wipe out files, revisions and history.
But I'd strongly advise not to do so. It's a perfectly normal thing to rollback files/changes and to see the history of it.
In case you still decide to use p4 obliterate make sure you call it without the "-y" option first (preview) and then (if the output of what perforce says will happen is ok) call the same command with the "-y" option (to actually perform the obliterate).
If you call p4 obliterate with a file revision (e.g. p4 obliterate //depot/dir/file#5) then only the changes and history of that revision will be removed leaving all previous revisions and history intact. You can also obliterate a revision range.