I am using perforce with Siemens TIA software. I would like to disable the ability for a file to be checked out by more than one person at a time since the files being used are binary and therefore the merge tools don't work all too well for multiple updates.
In perforce lingo you want to the make the file exclusive, or +l. If you are using the visual application p4v, you can check out the file, right click and then go "Change Filetype...". You can do the same thing on the command line:
p4 edit -t binary+l //somepath/somefile
which can include wild cards if you want to modify a bunch of files. The deeper solution is to use the p4 typemap command so you can tell perforce to understand your extension as always being binary and exclusive.
There are some workflow challenges with making a file exclusive. Imagine user A checks out the file exclusive but then goes home and is sick the next day? User B can't check out the file to do the work while user A is a away and you need an administrator to either unlock user A's computer or to revert the check out. User B can edit the file in "non-exclusive mode" by using the command line:
p4 edit -t binary //somepath/somefile_someone_else_has_exclusive
And then check it in, but now user A is going to have a mess on their hands when they do get back in and they want to check in.
See the "Locking files" section of the p4 resolve documentation - and note what you'll be losing if you do this.
Related
If I have a workspace open in P4V and I switch workspaces is there a way to notify or detect that the switch has happened externally?
The workspace contains an editor and needs to checkout files to modify them. I'm worried that a switch via P4V would leave the editor unaware that the files are now from a different stream.
I would rather have a way to detect this in the editor rather than having to notify from P4V if possible.
Thanks,
Alex
Are you saying your editor checks out the files automatically? That's common, so you're not on your own. What editor is it, if I may ask?
Do you know how your editor talks to Perforce? Am I right thinking that it issues p4.exe (the cmdline tool) commands, e.g. p4 edit? (The other way would be using one of the P4 APIs, e.g. p4java or p4python.) If so, the p4 edit commands already do not respect the P4V workspace setting. The p4.exe cmdline tool will work with the p4 workspace specified in one of six ways. To always use the right client,
have a P4CONFIG file specifying P4CLIENT=[client name] in the root of each of your workspaces
change the p4 integration of your editor in such a way that the p4 edit command will always be run effectively from within the given workspace (in the sense of CWD); you can use the -d switch for this, e.g. when checking out C:\workspaces\wksp1\foo\bar\baz.c you would call p4 -d C:\workspaces\wksp1\foo\bar edit C:\workspaces\wksp1\foo\bar\baz.c.
If the user is using a new workspace, they will also be working with a different set of files, so there's hopefully not much chance for confusion there. (Unless they've made multiple workspaces with the same Root, in which case they're doing their very best to shoot off their own kneecaps.)
If they've switched streams within the current workspace, you can detect this with a command like "p4 info", "p4 client -o", or "p4 stream -o".
How can i get list of files and the differences (with color highlighting) from a changelist so that I can send it for peer review.
I tried in windows cmd p4 describe #changelist however it just shows the list of files opened in the changelist.
[Update] I could find p4 diff and it gives the differences in all the changelists in a command prompt.
I was hoping for a batch file which could input a changelist number as parameter and generate a code review which i can share over email.
sorry, I am new to perforce and don't know what to lookup so I have'nt tried anything.
I see you're trying to send changes to your peers for review, and you're interested in things like color highlighting of changes, etc.
Don't try to build a code review system from scratch, yourself.
Instead, start with a code review system that is already built; there are a number of them already out there, both free and commercial.
You can start with something like Perforce Swarm, or P4Web, or the Perforce review daemon, all of which are included with Perforce, and you can just ask your sysadmin to install them.
Or there are plenty of other fine code review tools for Perforce that you can find.
But building a tool from scratch is a big project, and you probably have many other better things to do.
p4 describe #change
Should print out the diffs of the files, in a format you can control with the -d<flags> option.
the -s option turns off those diffs.
If you want a tool to review pre-commit changes, you could use ReviewBoard which we set up a one point. post-review can take local changes and post them for review.
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.
So I have some resource files I use for unit testing that I don't want changed (otherwise the unit tests will break).
Is there a way to lock these files using p4v without checking out the file?
I do not have admin rights btw.
If you are willing to check the files out, it's pretty easy to solve. Just open the files for edit, and then lock them. As long as you keep them open and locked, they should be safe - though I believe an admin could forcibly unlock them.
You can always create a second workspace for locking them if you don't want to clutter up your main one.
There are two solutions that could work without needing to check the file out / locking it.
Using P4 Permissions you can assign read access to the files or directory in the depot. Everyone will still be able read the files, which is essential for their work, however no-one without the correct permissions will be allowed to submit. Read more about the p4 protect command in manual.
Write a P4 Trigger that checks for the files the files on pre-submit, if found reject the changelist. Read more about the p4 triggers command in the manual.
To do both of these, you will need help from your friendly superuser/administrator. Option 1 is by far the best solution as triggers can slow your server down if you have too many or them doing too much. It will up-to you administrator if they want to add the permission to the protect table.
Note: Permissions/Protect as synonymous, like Workspace/Client.