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.
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'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.
Here's a frequent situation: You have about thirty files checked out into a specific pending change-list. After working on those files, and before submitting them, you needed to move them to a folder (external to deposits, so a simple "Integrate" wouldn't be suitable).
Using the "Show In - Explorer" option, you'll get a lot of window popped-up. And that's just painful (and sometimes, the system just cannot open all of them).
So, question is, is there a simple way to copy-paste multiple files from a change-list without doing it individually?
You can do this with a custom tool.
In P4V, open the custom tools manager via the Tools->Manage Custom Tools... menu item
Click New->Tool... to open the Add Custom Tool dialog and enter these parameters (xcopy isn't the ideal app for this, but I'll talk about that later1)
alt text http://img202.imageshack.us/img202/6678/p4editcustomtool.png
Now you will be able to select all the files in your change list, right click on them, and a new item will be available in the context menu Copy selected files to another location..."
alt text http://img97.imageshack.us/img97/4003/p4vcustomtoolincontextm.png
An input box will appear, asking you where you wish to copy the files.
alt text http://img132.imageshack.us/img132/7612/p4locationprompt.png
Click OK and the files will be copied to the location you entered in the input dialog. Maybe...
1There are some problems with xcopy:
the target directory must already exist
it doesn't seem to work if the path contains spaces
if the process fails, you're process list will fill up with a bunch of instances of xcopy.exe that are stuck trying to do who knows what
the custom tool will no longer work if the previous condition occurs
I tried robocopy also, which would be perfect if there was a way to pass it the source directory, but P4V custom tool editor doesn't provide the parent directory as a parameter. Ideally, you should write your own file copy utility, if this is really important to you. It wouldn't require that much effort.
Lastly, the P4V custom tool editor offers a file browser, but not a folder browser, and the latter is what you really need for a tool such as this.
So, play around with the custom tool thing. You might be able to come up with an answer to your problem.
I know you want to do these things outside of Perforce, but the best I can think of is if you create another workspace specifically for exporting files. You can sync your Perforce workspace to contain only the files in a particular changelist.
In this workspace, try giving the files in your changelist, after it is submitted, a particular label. If you sync your workspace to this label, it will delete every file that does not have this label based on this Perforce page. (do Find for label in that page)
p4 sync #label_name
This involves Perforce, but it does provide a way to get only the files you want.
I believe you can also accomplish this only using changelist numbers, but it may be more complicated. I'm not 100% sure this works
p4 sync #none
p4 sync #changelist,#changelist
I think this will sync files only in this changelist.
Using P4V 2009.2.
I have used P4Win in the past, but this is a new setup for me.
The problem is that the files I have checked out disappear from the changelists, so I cannot check them in.
To reproduce:
Check out a file, make a change to it.
Go to the 'pending changelist' tab.
There will be a + sign on the default changelist.
Click on the plus, or on the changelist line, the plus will disappear, there will be nothing in the changelist.
Try to check the file in by right-click on the file itself, the changelist dialog will show up but NO files are listed.
You can transfer the file to a new changelist, the same thing happens.
Looking at the file in the 'checked out by' window does correctly show the changelist number & description.
It sometimes happens to me, and what I normally do is change workspace and then change back again. Not sure if there is an easier way to get it to realise the files are checked out.
the only thing I can imagine is that you are looking at a different client workspace. Notice that the "Pending Changes" tab has a filter on the top, where you can separately filter for folder/files, user and workspace. Maybe the filter is set to something so that it doesn't match the client workspace where you have actually checked out the file.
Good luck,
Henrik
You may get this if the perforce server has not been upgraded. Old versions of P4D have this error: http://kb.perforce.com/article/1167/opened-files-missing-in-default-changelist
If that is not an option, use p4Win.
I agree with jhwist,sounds like your looking at a different client spec.
P4V is a bit confusing on this front, IMO and I personally prefer P4 Win but to check, open up a command prompt and type p4 changes -s pending -c YOURCLIENTSPEC - chances are that the changes you think you have aren't in your current clientspec
This can happen sometimes and in my experience it is a refresh issue with p4v. Often simply closing the pending tab or reopening p4v solves the problem.
In my case, the pending List has over 4000 files, (due to eclipse created so many files after mvn tasks) so none of them are shown. I created a different pending list, then cleared all contents, then moved the files to the new change list. Then it is appearing in the new change list.
Modify the file directly in the correctly mapped client folder (i.e. your current workspace). You will see the changelist for sure. As jhwist mentioned clear filters if any and choose your current workspace (since you may have many)
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.