According to the docs for fstat, an action for a file can be one of: add, edit, delete, branch, move/add, move/delete, integrate, import, purge, or archive.
Is it ever possible for a file in my workspace to have multiple actions at the same time?
While you sometimes can perform multiple actions on a file (e.g. do p4 integrate/p4 move/p4 copy on a file followed by a p4 edit on it), p4 fstat will list only one action field.
Related
Does perforce track the time and date at which changes were made to changelists? For example, updating the description text, or shelving different revisions of files into the changelist? And if so, can this information be accessed using p4 command line?
p4 changes -t will include information about the creation time of the changelist, but not the update. p4 describe doesn't seem to include any flags related to time. p4 fstat can show time information about the files in a changelist, but not the changelist itself.
No, changelists are not versioned objects (not even in the spec depot, annoyingly). The only ways to track changes to changelists are to go under the covers, e.g.:
Scrape information from the journal file (this requires some understanding of Perforce's db schema)
Add triggers on each command that might update a changelist in the ways you want to track (this requires exhaustive understanding of Perforce's command API so you don't "miss" anything that you need to trigger on).
Suppose we have a single text file in 2 branches:
//depot/work/branch1/file.txt
//depot/work/branch2/file.txt
We also have a central source file here that both branches depend on.
//depot/work/ImportantFile.txt
I make local edits to ImportantFile.txt and branch1/file.txt, but I also want to duplicate those edits to branch2/file.txt because ImportantFile.txt now expects all branches of file.txt to conform to a certain specification. As far as I know I have only 2 options, neither of which are ideal:
Manually make the same edits on both files and submit both changes in a single changelist. The problem with this, is that I would like P4 history to know that these files are still 100% integrated, but the history will show that they were edited independently.
Only make edits to branch1/file.txt, submit just this file as well as ImportantFile.txt in one changelist, then immediately integrate the change to branch2/file.txt in a 2nd changelist. Now the problem is that I've broken the build for a minute or two until branch2/file.txt gets the required changes.
How can I edit a file, and directly integrate those edits to another file before I submit those edits to the first file?
First off: you may already know this (and have had to make peace with it for reasons beyond your control) but:
ImportantFile.txt should not be outside of your branching structure. If your versioned files depend on it, it needs to be versioned itself, and that means it needs to exist independently in each branch, because branches are a part of your versioning scheme. Alternatively, maybe file.txt should not be branched, if it's required that it be identical in all branches at all times -- why branch something that's not allowed to diverge? But I suspect that just branching everything is the better solution.
Now for the workaround. (If you can't fix the root cause as described above, you've probably got a lot of this sort of thing in your future.)
p4 copy //depot/work/ImportantFile.txt //depot/work/NotABranch/ImportantFile.txt
p4 copy //depot/work/branch1/file.txt //depot/work/NotABranch/file.txt
p4 submit -d "Not a branch! (wink)"
Make your edits in //depot/work/NotABranch and submit them. Nothing is broken because, as stated, this is not a branch, and so it's exempt from whatever policy it is that forces all branches to move in lockstep. Now you can do:
p4 integ //depot/work/NotABranch/ImportantFile.txt //depot/work/ImportantFile.txt
p4 integ //depot/work/NotABranch/file.txt //depot/work/branch1/file.txt
p4 integ //depot/work/NotABranch/file.txt //depot/work/branch2/file.txt
p4 resolve
p4 submit
The merge history shows that both branches of file.txt were pure merges from a single common source, and so future integrations between the two should recognize that they don't need to be re-merged.
I have a file which has gotten too large, and should be refactored into two smaller files. What's the best way to do this in Perforce such that the relationship to the original file is maintained?
I'm adding two new files, and deleting the original in this case, but I would expect there to be some general solution to this problem.
I think the simplest case would be to add one new file which contains a subset of the content of the original, and delete that content from the original file, but leave it in place (it's trivial to delete it later anyway).
It would be nicest if the operation could be done in a single changelist to avoid any checkins which would break the build.
This can't be done in a single checking, but it can certainly be done without "breaking the build". Let's say you want to split bigFile.cs into smallFile1.cs and smallFile2.cs. First integrate the big file into the two little files and submit them.
p4 integrate bigFile.cs smallFile1.cs
p4 integrate bigFile.cs smallFile2.cs
p4 submit
You now have two extra files in your project directory, but they're doing no harm. Now check out smallFile1.cs and smallFile2.cs, and your project file(s). Add references to the smaller files, remove the reference to the big, edit the small files accordingly, etc. Finally, mark bigFile.cs for delete and submit your changes.
You have now split your big file into two smaller files and the smaller files' history will show you their big file origins.
You can use the integrate command.
When you've made changes to a file
that need to be propagated to another
file, start the process with p4
integrate.
The simplist form of the command would be
p4 integrate fromFile toFile
I would therefore perform the following tasks:
run p4 integrate with toFile being the new file and fromFile being the large, original file
p4 submit
p4 edit both fromFile and toFile to be the smaller versions of the original.
p4 submit
With this method, your file history information is kept in tact for all future revisions of the files.
This actually can be done with a single checkin. The steps are as follows:
integrate from the source file to both destination files as both raven and Scott Saad suggest
before submitting the new files, do a p4 edit on both files
make changes
p4 submit
The complete file history shows up in the revision graph and time-lapse views. The only disadvantage that I can see to skipping the intermediate submit is that the action type changes from 'integrate' to 'add'. Because of that, other people might not realize there is more to the file history.
I think I slightly prefer the two-checkin process.
How can I instruct Perforce to merge changes into an existing, open, and modified file in the workspace when unshelving a file shelved in the depot? The only options that Perforce appears to offer the user is to overwrite or revert the existing file in the workspace, but this does not allow, for example, to unshelve and integrate changes to the same file from multiple change lists. Is there a way around this limitation?
What I typically do is right-click on the shelved file and select "Diff Against Workspace File". When you open up the Diff tool, you can select a button in the toolbar to "Edit file in right pane". This essentially starts a two-way merge. With each difference you can select the changes you want from the shelved file (differences are selected from the workspace file by default).
However, it would be nice if Perforce added a type of merge feature to do this more automatically.
Edit to add:
Perforce now has a built-in capability to merge files when unshelving. If the user unshelves a file that is also checked out, and "Revert checked out files before unshelving" is unchecked, Perforce will mark that file for resolve. I looked through the release notes and was not able to find in which version this capability was added, but based on this link (see near bottom of p4 unshelve description), it was added no later than 2012.1.
Edited again to add:
That feature was added in release 2011.1 of the server. Here's the release note:
#299614 (Bug #38221, #39099) **
Unshelving a file opened for edit over a file already opened
for edit in the workspace is now allowed. A resolve record is
created when unshelving, and the user must then run 'p4 resolve'
to resolve the workspace files with the shelved files.
If you checkout your file, and then try to submit it, it will give you the option of getting the latest revision without replacing your copy. Then it will subsequently will give you the ability to run a merge tool, where you must resolve any conflicts before submitting.
Quite often when I'm working in a branch in Perforce, I realise I need a file I didn't branch when I initially branched.
So, I add the file to my client, run p4 integrate -b branchname, then p4 submit.
Thing that bugs me is that I then need to go through the list of files for submit, and remove all entries that are open for edit.
I can't see any option in p4 help submit, but it seems like this might be a reasonably common use case.
First do
p4 submit
Assuming your p4 editor is vi,
type this command in command mode
g/#.*edit\|#.*add\|#.*delete/d
You can choice to submit a single file on the command-line.
p4 submit <filename>
Then it won't bug you about the other files.
If you have more than one file, then maybe you should move all of the files you are currently editing onto an numbered changelist, or branch onto a numbered changelist, which will provide the separation you want.
If you're going to do this, it's much easier to manage numbered changelists from one of the GUIs.