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.
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.
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 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.
I am trying to write a bash script to do a task, I have done pretty well so far, and have it working to an extent, but I want to set it up so it's distributable to other people, and will be opening it up as open source, so I want to start doing things the "conventional" way. Unfortunately I'm not all that sure what the conventional way is.
Ideally I want a link to an in depth online resource that discusses this and surrounding topics in depth, but I'm having difficulty finding keywords that will locate this on google.
At the start of my script I set a bunch of global variables that store the names of the dirs that it will be accessing, this means that I can modify the dir's quickly, but this is programming shortcuts, not user shortcuts, I can't tell the users that they have to fiddle with this stuff. Also, I need for individual users' settings not to get wiped out on every upgrade.
Questions:
Name of settings folder: ~/.foo/ -- this is well and good, but how do I keep my working copy and my development copy separate? tweek the reference in the source of the dev version?
If my program needs to maintain and update library of data (gps tracklog data in this case) where should this directory be? the user will need to access some of this data, but it's mostly for internal use. I personally work in cygwin, and I like to keep this data on separate drive, so the path is wierd, I suspect many users could find this. for a default however I'm thinking ~/gpsdata/ -- would this be normal, or should I hard code a system that ask the user at first run where to put it, and stores this in the settings folder? whatever happens I'm going ot have to store the directory reference in a file in the settings folder.
The program needs a data "inbox" that is a folder that the user can dump files, then run the script to process these files. I was thinking ~/gpsdata/in/ ?? though there will always be an option to add a file or folder to the command line to use that as well (it processed files all locations listed, including the "inbox")
Where should the script its self go? it's already smart enough that it can create all of it's ancillary/settings files (once I figure out the "correct" directory) if run with "./foo --setup" I could shove it in /usr/bin/ or /bin or ~/.foo/bin (and add that to the path) what's normal?
I need to store login details for a web service that it will connect to (using curl -u if it matters) plan on including a setting whereby it asks for a username and password every execution, but it currently stores it plane text in a file in ~/.foo/ -- I know, this is not good. The webservice (osm.org) does support oauth, but I have no idea how to get curl to use it -- getting curl to speak to the service in the first place was a hack. Is there a simple way to do a really basic encryption on a file like this to deter idiots armed with notepad?
Sorry for the list of questions, I believe they are closely related enough for a single post. This is all stuff that stabbing at, but would like clarification/confirmation over.
Name of settings folder: ~/.foo/ -- this is well and good, but how do I keep my working copy and my development copy separate?
Have a default of ~/.foo, and an option (for example --config-directory) that you can use to override the default while developing.
If my program needs to maintain and update library of data (gps tracklog data in this case) where should this directory be?
If your script is running under a normal user account, this will have to be somewhere in the user's home directory; elsewhere, you'll have no write permissions. Perhaps ~/.foo/tracklog or something? Again, add a command line option, and also an option in the configuration file, to override this.
I'm not a fan of your ~/gpsdata default; I don't want my home directory cluttered with all sorts of directories that programs created without my consent. You see this happen on Windows a lot, and it's really annoying. (Saved games in My Documents? Get out of here!)
The program needs a data "inbox" that is a folder that the user can dump files, then run the script to process these files. I was thinking ~/gpsdata/in/ ?
As stated above, I'd prefer ~/.foo/inbox. Also with command-line option and configuration file option to change this.
But do you really need an inbox? If the user needs to run the script manually over some files, it might be better just to accept those file names on the command line. They could just be processed wherever, without having to move them to a "magic" location.
Where should the script its self go?
This is usually up to the packaging system of the particular OS you're running on. When installing from source, /usr/local/bin is a sensible default that won't interfere with package managers.
Is there a simple way to do a really basic encryption on a file like this to deter idiots armed with notepad?
Yes, there is. But it's better not to, because it creates a false sense of security. Without a master password or something, secure storage is not possible! Pidgin, for example, explicitly stores passwords in plain text, so that users won't make any false assumptions about their passwords being stored "securely". So it's best just to store them in plain text, complain if the file is world-readable, and add a clear note to the manual to warn the user what's going on.
Bottom line: don't try to reinvent the wheel. There have been thousands of scripts and programs that faced the same issues; most of them ended up adopting the same conventions, and for good reasons. Look at what they do, and mimic them instead of reinventing the wheel.
You can start with the Filesystem Hierarchy Standard. I'm not sure how well followed it is, but it does provide some guidance. In general, I try to use the following:
$HOME/.foo/ is used for user-specific settings - it is hidden
$PREFIX/etc/foo/ is for system-wide configuration
$PREFIX/foo/bin/ is for system-wide binaries
sym-links from $PREFIX/foo/bin are added to $PREFIX/bin/ for ease of use
$PREFIX/foo/var/ is where variable data would live - this is where your input spools and log files would live
$PREFIX should default to /opt/foo even though almost everyone seems to plop stuff in /usr/local by default (thanks GNU!). If someone wants to install the package in their home directory, then substitute $HOME for $PREFIX. At least that is my take on how this should all work.
Can I rename a folder in Perforce from //depot/FooBar/ to //depot/Foobar/?
I've tried this by renaming from //depot/FooBar/ to //depot/Temp/ to //Depot/Foobar/ but the end result ends up the same as //depot/FooBar/.
Once it is in Perforce, the case remains set. As mentioned by Johan you can obliterate, set the name up correctly, and add it in again. However, there is a slight gotcha....
If anyone else (running Windows) has already synced the wrong-cased version, then when they sync again the right one, it will not change the case on their PC. This is a peculiarity of the Windows file system acknowledging case but still being fundamentally case-independent.
If a number of users have synced, and it is not convenient to get them to remove-from-client too (and blasting the folders from their machines), then you can resort to a dark and dirty Perforce technique called "Checkpoint surgery". It's not for the fainthearted, but you do this:
Stop your server, take a checkpoint.
Using your favourite text editor that can handle multi-megabyte files, search & replace all occurances of the old case name with the new. You could of course use a script too.
Replay your checkpoint file to recreate the Perforce database meta data.
Restart your server.
This will affect all user client specs transparently, and so when they sync they will get the right case as if by magic.
It sounds hairy, but I've had to do it before and as long as you take care, backup, do a trial run etc, then all should be OK.
Maybe not needed anymore, but here's the official Perforce HowTo about changing file cases on Windows and Unix: http://answers.perforce.com/articles/KB/3448/?q=change+file+case
I'm not sure about directories, but we've had this problem with files. To fix it, we have to delete the file, submit that change, then p4 add the file with the correct case and submit the second change. Once that's done, unix users who have sync'ed the incorrect-case file have to p4 sync, then physically delete the file (because p4 won't update the case) and then p4 sync -f the file.
Our server is on Windows, so that might make a difference.
I guess it treats files and folders the same.
For files:
It depends (on whether you have a Windows or Unix server). We have this problem with our Windows perforce server (which versions our Java code), where very occasionally someone will check in a file with a case problem (this then causes compile errors because it's Java). The only way to fix this is to obliterate the file and resubmit it with the correct case.
I think you should remove the Perforce Cache, so that your modification can be shown.
You can rename with ABC rename to abc_TMP, then abc_TMP rename to abc, then clear cache.
Setps to clear cache:
Open windows user home folder (on windows7 ==> C:\Users\)
Locate the folder called ".p4qt"
Rename the folder to "old.p4qt"
Launch Perforce, now everything works!
NOTE: these steps will rest your default setting.
The question is over 3 years old, but I ran into an issue like this while doing a Subversion import into Perforce and figured the info I got could be useful to some. It's similar to the obliterate method, but helps you retain history. You use the duplicate command that may not have been available back then to retain the history. The process basically being:
Duplicate to temporary location.
Obliterate the location you just duplicated.
Duplicate from the temporary location to the renamed case location.
Obliterate the temporary location.
Through this you retain the history of file changes, but get them all in the new path as well. Unfortunately there will be no history of the path case change, but that seems to be unavoidable. Similar to other methods mentioned here, users will need to either manually rename the directories in their workspace or delete and re-sync to get the new path name.
Also, P4V caches the paths it shows in the tree so after doing this it may still show up as the old name. a p4 dirs command however will show the new case.