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.
Related
I use Perforce to manage a project that contains some binary files (Excel, Word and Visio diagram files).
I'd like to know the safe way to update my local version of such files from the latest version available on Perforce, without corrupting/damaging/overriding the local changes. (Local changes are made locally and not submitted to Perforce yet)
Locks don't seem to solve the problem because it helps only in concurrent submission of files.
p4 reconcile to make sure that any local changes are correctly reflected in your pending changelist(s).
p4 sync as normal. Opened files will not be overwritten by a p4 sync.
If you're following the standard Perforce workflow of always opening files for edit before you modify them (i.e. you never override the "read-only" flag on your local files), you can skip step 1 and just sync at any time without fear.
p4 resolve to handle any files that have been modified both locally and in the depot.
Note that Perforce's built-in merge logic will only handle text files, and so resolve will by default offer only a binary yours/theirs choice for binary files (at will overwrite your local changes, and ay will ignore the depot changes). If you have a merge tool that can handle your binary format, you can do:
p4 set P4MERGE=your_merge_tool
p4 resolve -t
m
to invoke your merge tool as part of the resolve process. See the documentation on the P4MERGE variable for more information how this tool will be called (you may need to wrap it in a script if it doesn't follow the base theirs yours merged calling convention): https://www.perforce.com/manuals/v17.1/cmdref/Content/CmdRef/P4MERGE.html
I've looked at this similar question but I'm still fairly lost. I have one file which I want to be a part of multiple changelists. I seem to remember that doing this involves creating multiple clients, but that's stumping me, too. I can create a client just fine, but I can't figure out how to "check out" that client and start creating a separate CL in that client, one that is independent from the CLs I have started in my original client.
Any help would be hugely appreciated!
(It's also worth mentioning that I'm working on a source control system that's forked from perforce, not exactly perforce).
One file can only be part of multiple submitted changelists if each changelist has a different revision -- e.g. if you add a file to the depot its revision #1 is in one changelist, when you edit it and submit that its revision #2 is in another changelist, and so on. Same file, different revisions.
One file can be part of multiple pending changelists at the same time (all derived from the same revision) if each changelist is on a different client. If you're creating different clients on one machine, make sure that each has its own unique client root, since you'll want to have unique copies of the file(s) on your local machine. Then you don't need to do anything special to open the file; each client is independent of the others. Just "p4 sync" and "p4 edit" the same way you did on your first client. (Make sure to use P4CLIENT or the equivalent to specify which client you're using at any given time; P4CONFIG files make this easier by associating a P4CLIENT setting with a particular working direcotory.) The only difference you'll see is an informational message from "p4 edit" that the file is already open by another client. Creating changelists works the same way as it always does; run "p4 change" to create a pending change, "p4 reopen -c change" to move files around between changes.
There is also shelving, which is similar in some ways to having multiple pending changelists on different clients (except that the changelists are all stored on the server rather than in a bunch of different client workspaces) but if you happen to be using a very old version of Perforce (or something similar to it) that's probably not an option.
At work, we use a version control system called Perforce. Bizarrely, it makes all the files downloaded from the repo readonly. It then demands you tell it (p4 open) whenever you want to edit any one of them. This is tedious, and really interrupts my concentration--I just want to edit a file on my computer, not think about version control.
Is it possible to have a less intrusive workflow? I'd like to edit files on my computer as I see fit. Then when I'm done, group and title them into a commit/changelist.
You can totally control this workflow.
Here's what to do:
Change your client options to specify "allwrite"
re-sync your files and they are all now left writable
Edit files as you wish
When you are ready to submit, run 'p4 reconcile'. It will figure out what files you have edited, what files you have added, what files you have deleted.
Submit your changes
As you say, edit your files on your computer as you see fit. Then, when you are done, group and title them into a changelist and submit them.
Here's some docs for the "allwrite" option: http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_client.html
If you work in Visual Studio, then I would highly recommend checking out P4VS. I think that would resolve most, if not all, of the issues you're having with the workflow.
You could also use the "Allwrite" option in your workspace, which will leave all files writable. If you go this route, you'll still need to mark the files for edit and group them into a changelist to a submit, but it won't interrupt you while you're programming.
I'm a very fresh user of Perfoce, so please be patient!
I am trying to create a commit (I understand it that in Perforce it is called a changelist) of the files which have been changed. It sort of happens automatically in other VC systems, but there seems to be no easy way of doing it in p4... The problem is (maybe) that I'm not editing the files by hand, the files are generated (please don't ask me why do I have to check in the generated files...) so the whole directory tree is getting removed and then copied over with the new files. But Perforce acts as if nothing happened. In both my workspace and the depot it displays the updated files, but when someone will check them out on another machine, the files will be of the previous version.
I'm fine with doing it either through GUI or through the command line. I'd prefer the command line, because that would spare me the trouble in the long run, but it doesn't seem like it should be much hassle either way.
In other words, let's say, this is the workflow I'm used to from SVN or Git:
Run status to see what changed.
Stage / add to commit what you want to be in the next revision.
Commit and send it to the versioning server.
What I'm not able to do is the "stage" phase - because the changes are not discovered automatically.
EDIT
Ah, I think, I figured it out: reconciliation was what I needed... well, I guess if you don't marry, this word would hardly ever happen in your vocabulary :)
It appears that the proper command is reconcile. Also, as Bryan Pendleton suggested there should be status, but I must have an older version of Perforces, which doesn't have this command. This command is also available from context menu in either depot or workspace panels of Perforce graphical interface, when you click on the modified file.
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.