I have a file I need to move that's already under perforce. Once moved it needs some editing - update the package, etc - appropriate to its new location. Should I submit the move changespec and then reopen it for edit, or can I do this in one go? If so, what is the appropriate sequence of events?
I have done this before in one go, but depending on your build process, I recommend against it. What I generally do is this:
Move the file.
If the move needs a change in order to compile, open it for edit and make those changes.
Submit the changes, telling perforce to reopen the files for editing.
Make the changes for path, etc., that don't cause compile errors but should be updated.
Submit those changes with an appropriate description.
If you want to, however, you could just do all your changes in step (2) above. Perforce might change the flag for the new file from integrate to add, but it still remembers the source path for the file.
Edit: Better method
I realized that I often use a different method, but the idea of "moving" the file distracted me. So, I would recommend these steps instead:
Integrate the file into the new path/name, leaving the previous file there. I am assuming that this won't break your build process.
Submit the new file, checking it out again for edit after submission.
Make the required changes to the new file, and to the project so that you are using the new file.
Submit the edits for the new file.
[Optional] You might need to check through branch specs to see if you need to map the old file into the new one in any branches.
Create a changelist for deleting the old file, and submit it sometime later.
This method allows the edits to be cleanly separated from the rename/move, while never leaving the project in a state that won't compile.
Also, why wait for step 6? Sometimes, especially on bigger projects, you might want to move a file that another person is editing. Perforce will helpfully tell you this. By waiting to delete the file, you allow your coworker(s) to finish the edits and submit without needing to move their work manually. After the edits are submitted, they can be integrated into the new file, and then the old one can be safely deleted.
Submit the move change and then reopen for edit (you could use the reopen option too).
This is much more readable to the user in the change history.
Also, recent versions of Perforce do perform checks for changes to files after resolution. So, there may be complaints editing files after some resolve operations have been completed.
I would say always submit first then edit. It is much cleaner and makes it more obvious whats happening in your repository. Then simply checkout the file in the new location and make whatever changes. This also makes it much more obvious that the changes were made in the new location and to all it to work after renaming.
Yes you can. Simply reopen for edit the branched file (i.e. the new one). In P4Win, there is a context menu for this ("re-open for edit").
"Safely" is probably an important point here. Once you rename or move the file it'll get a revision number of "1" which looks like a new file to your Perforce client. Of course, admins will be able to get its prior history, but if the editing/version history of the file is important to you it's a little harder to get the older revision.
Update: Thanks to Commodore Jaeger and Greg Whitfield for enlightening comments.
This wasn't easy to track down regarding what the One True Answer is, even from Perforce support, so I figured I'd update everyone on what we found:
Perforce stores all versions of every document in its database.
If it's saving your file as type <text> or <ktext> then it stores the diffs of one file version to another and not the entire file.
If you check out a file, make no changes to it, and then re-submit, it will save as a new version with 0 diffs. This is configurable and P4 can be set up to ignore changelist items without any actual diffs. You can force this behavior by selecting "Revert unchanged files..." before you submit a changelist.
Use "Rename/Move..." to move files in P4 so it can track them. Don't copy them using Windows Explorer and then re-add them in P4.
If you use the "Rename/Move..." function from the context menu, the "new" file will show a revision number of "1" as though it were a new file.
However, since P4 saves every function performed on a file, you can actually get to any previous revision (and even recover "deleted" files) with the CLI command p4 filelog -i
If you want to get to the revision history of a moved or renamed file and you're not an admin, you can right-click and select its "Revision Graph" which shows every version of a file even when moved between branches.
According to Perforce support, easier tracking of revision history through branch or folder moves is an oft-requested feature and is in their current roadmap.
Perforce's answer: At the moment, there isn't a way to move/rename/integrate files and still maintain the exact file history.
However, if you were to choose "Integrate..." by right-clicking on the folder that you want to share, the versions of the files of the newly branched folder and underlying files will start from revision #1, but the integration history between the branched folder and underlying files and the original folder and underlying files will remain through which you can trace the revision history of the files.
Related
I'm looking for a way to do version control on a set of files, but not for project history, more of an extended undo. Basically I'm looking for a very simply version control with little overhead that will watch a directory for changes then save the differences so I can go back and view any file at any save. I don't want all the features of git or another version control like it. Also I don't want to have to commit changes, changes should be save as soon as a file is modified. Any suggestions?
I'm contently running into situations I write a block of code, save the file, rewrite the block of code, save the file, then realize I need it like it was at first but can't undo in my text editor for some reason.
Dropbox has a very simple version control only for files. You can revert to any previous version and every time yo save changes and updates the file it creates a new version. You can work on Dropbox folder to do this automatically
(I work with perforce from eclipse by the perforce plugin).
After associating my workspace with a perforce depot, all the files got status "Version in workspace is not latest version" (yellow triangle)....
When a file has this status, submit is disabled for this file.
When I do "Sync with depot" on a project, all those files show the conflict icon (even when there's no conflict...).
Conflict? does it mean I need to resolve?
Here is how to do resolve:
http://www.perforce.com/perforce/doc.current/manuals/p4guide/05_resolve.html
The problem is... by "resolving" perforce overrides all the files in my workspace with the files in the depot. So every change I made to the workspace before associating it to perforce is gone.
What I actually want to achieve is the other way around: submit all the files in my workspace to the depot. i.e. override the depot.
How can I do that?
If perforce says that you cannot submit because "Version in workspace is not latest version", then this means that you have a file open for edit that was already changed and submitted by someone else, i.e. you're working on an old version of the file.
You definitely should not try to force your (old) version on top of the newer one in the depot.
You really need to resolve. Perforce will not "override" all the files your workspace and discard your changes.
For merging (resolving) you can use the eclipse built-in merge tool or the p4merge (from Perforce).
As other answers say, most of the time your best bet is to work with Perforce's workflow and check out the workspace in advance and make your changes there, rather than make changes first and create the workspace later. Sometimes, though, you really do need to break Perforce's workflow and override the changes in the depot. If you're going to do that, you need to be extra careful that you're not reverting something important. (Even on a one-person project you might have forgotten you checked something in, so look carefully at the diffs before submitting.)
The easiest thing to do is, when Perforce tells you that you have a conflict, resolve but keep your changes. In the Perforce documentation link, that's 'resolve, accept yours' rather than accepting what Perforce thinks is the sensible merge. From the command line, that's p4 resolve -ay. It's worded a little differently in the p4v GUI, and may be worded differently still in the Eclipse plugin (which I haven't actually worked with).
The other option, which you might use if you have files checked out from an earlier revision, and you want to update to the tip revision without making any changes, is to tell Perforce to update the metadata, so that it thinks you have a newer version of the file, without actually altering any of your files. From the command line, that's p4 sync -k (whatever you want to sync). This, too, can be dangerous if used inappropriately.
I don't think you can achieve what you want in Perforce. You will need to copy the files you've changed to a safe place and then resolve/revert all of the files to remove the conflict/out of date flag. Once done, copy your changes back and submit. It's a pain, but you should have connected with Perforce before making your changes.
I'm using Perforce to integrate two codelines. In the resulting changelist, there are files which are marked as opened for integration, but have not actually changed.
Should I submit these unchanged files or should I revert them?
I want to revert them because I don't want these unchanged files to pollute the changelist.
But, if I submit them, I have a feeling that Perforce might have a use of this "fact" (that the files have been integrated) for future integration.
There is no need to submit unchanged files. I can't even understand why the option exists. Perforce only needs to know about changes you make to files. The fact that you checked a file out, but did nothing to it, is irrelevant. Revert unchanged files. As you said, don't pollute the revision history.
Yes, you should submit them. This will create the integration record to record that the changes have been "integrated" (which may not mean actual changes occurred on the target).
I always reverted unchanged files in my changelists. I can't remember any wrong consequences.
(Fortunately, now we switched to git.)
Is there a simple way to convert a (large) list of p4 moves to p4 integrates? There are a lot of pending modifications to the moved files, so just reverting and instead integrating isn't an option.
Perforce won't let you just revert the deleted file (which would leave the desired integration behind).
Even if Perforce allowed it, reverting the deleted files wouldn't leave an integration behind, it would leave an add behind. A move operation consists of adding (not integrating) the file(s) to the new location and then deleting them from the old. If you think about it, integrating files to a new location and then deleting them from their original location makes no sense. The purpose of an integration is to maintain a relationship between two sets of files.
As far as I know, Perforce provides no "one click" mechanism to do what you want, but it's not too difficult:
Copy the files you've modified to a temporary directory
Revert your file moves
Integrate the files and then open them for edit in their new location
Copy the changed files from the temporary directory into the new location and submit them
I'm using Visual Source Safe at a new job and it hasn't been too bad... then I renamed a file.
I clicked through the warning prompts not really paying attention realized that by renaming the file I lost all of my history. Is this really the case? I can't believe VSS doesn't support renaming.
I refactor lots of code and not having a renaming work properly really bites.
Thanks for the answers. I guess VSS does have renaming functionality, just not in Visual Studio. What a dealbreaker though, switching apps to rename a file in source control? :/
It's possible to do this in SourceSafe, but it requires a bit of manual intervention:
First, make sure the file you want to rename is checked in.
In SourceSafe, right-click the file and select Rename from the menu (or alternatively, simply press F2), then rename the file.
This only renames the file within SourceSafe. You will have to check out the renamed file to your working folder and then delete the original file from your working copy to complete the rename.
If you view the file's history (right-click, then Show History, or altenatively, Ctrl-H), you will see that all of its history is intact. Note, however, that SourceSafe will refer to the file by its new name in all of the history entries for the file. The actual rename is tracked at the project folder level. If you view the history of the folder that contains the renamed file, you'll see a history item indicating that the file was renamed from oldname to newname.
Addendum: A note on retrieving older versions of renamed files from history
Joe White commented on this answer that SourceSafe doesn't honor the original filename when you do a Get on an older version of a renamed file. This is true, if you are getting the older version from the File History viewer.
However, if you do a Get of an older version of your code (before the rename) from the parent folder's history viewer, SourceSafe will correctly use the original filename when it puts the files in your working folder.
The reason for this behavior goes back to the fact that SourceSafe tracks renames at the parent folder level and not at the per-file level.
It doesn't matter.
Once you've seen your SourceSafe "database" corrupted through no action of your own, SS could produce daily rainbows and unicorns, but they'd eventually morph into festering sea creatures of random bytes, unrecoverable by man.
Get away from Source Safe. It was a noble effort by Microsoft to get people into the idea of source control, but I've twice (in 2 years, same data store, 3 people working against it) seen it die an unrecoverable death.
Get into svn, tfs, anything else! Tell your higher-ups that you're playing with fire every time you check in. You may be as lucky as I was on the project before the failed one, or you could just end up... relying on your backup strategy...
VSS has a rename feature which maitains history
File > Rename (I am positive that this maitains history)
but its been a long time since I've used it