How do I view a particular file from a particular commit/version?
I have seen the solution where you view the file in (any) History, right-click it and select Log Selected and then choose Open Selected Version. However, this only works when I can find the file in History, which means I need to find a commit/version where the file was updated. I don't have this info.
I have also seen solutions where I can checkout the old version. However, I'd like to avoid this. I have current files open in editors and want to keep them there, unchanged. Generally, I find that checking stuff out and creating new branches sometimes creates annoying head/branch/whatever errors that I'd just as well avoid just to view a single old file.
I used to use TortoiseHG where I could right-click any version, choose to view the files in that version, get a window showing all files, and then open any file from there as a temp file.
Related
Is there a way, with TortoiseCVS, to see what has changed in the repository since the last CVS update?
I am used to Eclipse's synchronize function. But now I want to view differences in a directory that isn't an eclipse project.
I could check out the project somewhere else and use any diff tool. But that's ugly.
The command line version of cvs provides the '-n' option for this purpose. From the cvs manual:
Do not change any files. Attempt to execute the `cvs_command', but only to issue reports; do not remove, update, or merge any existing
files, or create any new files.
Note that CVS will not necessarily produce exactly the same output as without `-n'. In some cases the output will be the same, but in
other cases CVS will skip some of the processing that would have been
required to produce the exact same output.
The option is also available in Tortoise: Choose "CVS Update Special" from the context menu. In the dialog check the box "Simulate Update" (it's on a separate tab in newer version of Tortoise).
However, I find the feature to be of limited usefulness, due to it's cryptic output and low level of integration (e.g. it's not possible to click on a file and actually view the diff's).
Is it possible in EGit to see the simple history of a file?
Team > Show in history shows all commits to all files. Not useful.
I am looking for the history of a file. There is a button in the History view that says Show changes to selected resource but no way to select a resource.
There also does not appear to be any way to compare with a specific version unless that version has a tag.
The pieces seem to be there, but are they put together properly?
(No complex branching or other cleverness. I normally use the command line for this type of work but should not have to.)
You can open a file (or select it from project explorer) and do:
Right Click -> Team -> Show in history. This will open the following view:
The filter circled in red is: "Show all changes of selected resource and its children" which basically will filter only the commits that relate in any way to the resource you've selected (you can chose the different filters to get a better understanding of how they differ from each other).
The problem was that the Team > Show in History needs to be run from the Project Explorer window. When I first found those scoping buttons I right clicked on the class file's edit window and did the Team > Show in History there. That appears to be broken and only shows all changes.
(Thank you for your replies. Knowing that it could be done and by those scope buttons let me look further. I rarely use the Project Explorer, preferring to just type the class/file name into the Navigate dialog.)
Some other answers suggest clicking on Team > Show in History. This menu item does not show up. Instead, Team > Show Local History shows up.
I have Git Staging tab open all the time. I saved a small change to the file I wanted to see the history of. This caused the file to show up in the Unstaged Changes in Git Staging. I then right-clicked on the file, clicked on Show In and then History. This showed me the history of the file according to Git.
I frequently have to diff two trees of source files, one coming from svn (in which you can only check out the whole tree) and the other my eclipse workspace.
99% of the time I only want to see diffs in files that are in both compare trees. The svn side has thousands of files my workspace does not, and I don't need to see them.
Is there a way to get the compare utility to only show files that exist on both sides, and skip the ones it would put the little minus icon on?
One option would be to carefully select only the files and folders you want included in the comparison, then right-click and choose Team > Synchronize with Repository.
That will open the Synchronize perspective and show a Inbound/Outbound view of changes. From there you can "pin" the synchronization and later come back to it and re-sync to see updated results.
You can read some more about the Synchronize view at http://www.eclipse.org/subversive/documentation/teamSupport/workspace_synch.php
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
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.