Is there a way to see all changed files in p4v without out having to trawl through the directory tree in the workspace view?
I am much more familiar with git and I am essentially looking for git status at the top level of a repository. I want to be able to see this in p4v rather than the p4 command line tool which most search results seem to turn up.
If you're using Perforce's standard "check out" workflow, all the changed files are always in your pending changelist(s) in the right hand pane.
If you're modifying files without checking them out (note that this negates many of Perforce's benefits relative to git), use the "Reconcile offline work" feature to do a git status-like scan of the local tree. https://www.perforce.com/manuals/p4v/Content/P4V/using.offline.html
Related
I do not want to go "Get Revision" > "Force". Because half of my stuff is already downloaded. I don't want to overwrite what I already have. P4V Can clearly see that what is in the depot and what is local is completely different. How can I get Perforce to retrieve the files I do not have, and ignore the ones I already do?
Select your workspace root, go to File > Open Command Window Here, and run:
p4 clean
This will scan your workspace and force-sync everything that's different or missing, as well as deleting unadded files. Note that if you have local work that isn't in a changelist, this will irrevocably erase it. If you only want to "clean" files that are edited/present but out of date (and disregard added/deleted files), do p4 clean -e instead. If you want to preview the operation before doing it for real, do p4 clean -n.
I think you can do the equivalent via the "Reconcile Offline Work" tool in P4V, but it may require additional manual steps.
To make working with Perforce easier, try to avoid modifying files in your workspace that are read-only -- if you want to remove a file from your workspace, use "remove from workspace" in P4V rather than manually deleting it, etc. Perforce is able to make file operations very fast by virtue of knowing what's in your workspace and not having to re-check it each time, but you eliminate that benefit when you mess with your workspace manually.
Instead of p4 clean, you could do:
reconcile offline work on root of workspace then a pop-up saying that you deleted some files and it is going to delete them from Depot of the server as well make sure you added to default or new changelist or whatever. Accept.
Go to changelist and right-click press revert files to bring back the deleted/missing files.
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".
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.
Suppose you open a file for branch to another place (without submitting), and then reopen it for add and make some edits. I would like to diff this edited version against its branch source in a script.
p4 diff2 is no good because one of the versions is in the client.
p4 diff is no good because it can only diff against the "corresponding" version of the file in the depot, which a branched unsubmitted file doesn't have yet.
Is there a way, or is the only option to just grab the two files and diff them using a third-party tool?
Sadly, you're on the money here, you'd need to use a third party diff tool to do this because, as you rightly pointed out, until you've submitted the initial integration to the depot, it doesn't have a copy against which to diff. If you go down this route you'd obviously not be able to access files directly in the depot though, you'd need to have both files on the client PC and specify their paths explicity.
ninesided is correct that you need to have both files on the client PC.
But there are shortcuts:
If you're using P4V, choose "Diff Against..." from the context or Tools menu. For 1st Path, choose the old location and select "Latest Revision'. For 2nd path, choose the new location and select "Workspace revision on local disk".
The work of selecting the paths can be made easier if you can get both files to appear in the same pane and Ctrl-click to multi-select. e.g. use the Workspace tree pane or open the source file for edit temporarily in order to get it listed in the Pending files pane.
P4V accomplishes this by running 'p4 print -o' on the depot file to create a temporary file on the client PC, then passing that temporary file to the diff application. If you need a textual diff, you can either configure P4V to run a textual diffing application, or run p4 print -o and diff yourself.