Borland Starteam: How to re -check-in a file from a frozen labeled configuration to current configuration with history?
You should be able to go to that frozen labeled configuration (View->Select Configuration->Labeled Configuration) and pick that label. Then what you are seeing should be files as of that label. You could then checkout the file you wanted from that label.
Then go back to the current configuration (View->Select Configuration->Current Configuration) and check-in your file (you will have to do a Forced Check-In since it will show as Out of Date status). In the check-in comments you may want to mention that you pulled that file forwards from that label.
You will not lose any of the history between the label and your check-in.
If the file does not exist in the current configuration, you can share the file from the labeled config to current - just have the view open in two separate windows. This will retain all of the version history.
There is a hiccup in that it will not allow you to share the file into the same folder as it originally existed (as of 2008R2). Just share the file into a different folder then move it.
All history is retained. Note that the new instance is a share, so you may want to check the reference tab before branching to make sure it will do what you expect.
Based on GanYo's comment to the question -
The problem is not the fact that the file is sitting in a frozen label -
the real problem is that the file was deleted.
You cannot "bring back to life" a file that was deleted,
but you can "go back in time" to see it's history (as mentioned by Dougman).
The only solution supported by Borland is this:
Set-Configuration to a time (or label) just before the file was deleted
(this should allow you access to the latest version of the file with all its history).
Check-out all the different revisions of the file, one-by-one, keeping them in unique names
until you have the complete list of revisions.
(best is to append the revision-number to the name of each revision to the file being saved locally)
Set-Configuration back to 'Current'.
Check-in the complete history of the file, starting with the oldest version of the file,
and going forward, until you have imported all the file-revisions in the correct sequence.
(you have to rename each revision of the file to its original name before you check it in, of course)
Having said that, you really need to think if this is worth it, because:
This "restore" process does not bring back:
the comments of each revision
the CR-links that were attached to each revision
the Lables that were attached to each revision
The file's history was there all along, and is available via 'Set Configuration' - why duplicate it?
Bottom line:
It is probably best just to restore the latest version of the file,
mentioning in the comment that it was deleted accidentally and that its history can be reviewed
by doing 'Set Configuration' to ...
Related
In TortoiseGit commit dialog (before making a commit), I selected a particular file and right click -> Revert
I have changed my mind and would like to "unrevert" this file.
I can't find anything that achieves this. There is no record in the log of this specific file revert and of course because I hadn't committed those changes there is no point to roll back to. Is this possible?
The file should be put into the Windows recycle bin before the changes were undone.
There is no other failsafe active, as the changes were not version controlled (committed).
Also see https://tortoisegit.org/docs/tortoisegit/tgit-dug-revert.html
I've deleted a file by accident. Then I created another file with the same name. When I tried to check in the change, it didn't work out and got an error. I undid the changes then deleted the file, there's no more error when I try to check in.
I'd like now to get the latest version of the file before I deleted it.
Thanks for helping.
In TFS, a deletion only takes effect when you check in the said deletion change, and thankfully, this operation is reversible.
Here are the most common recovery scenarios, assuming that the file already had revisions stored in TFS before the accidental deletion:
If the file is still visible in the Source Control Explorer and is marked for deletion (under the Pending Change column):
Then it means that you've deleted the file from your solution (and file system), but that you didn't checked in the changes yet.
Use the "Undo" command of its contextual menu to restore the file in your workspace to its latest version before deletion.
From there, you'll be able to add the restored file to your solution.
If the file is still visible in the Source Control Explorer and is not marked for deletion:
Then it means that you've deleted the file from your file system.
Use the "Get Specific Version" command of the file's contextual menu to restore it in your workspace. In the "Get" window, select "Latest Version" and enable both options.
From there, you'll be able to add the restored file to your solution.
If the file is not visible in the Source Control Explorer:
Then it means that you've checked in the deletion change.
Turn on the "View deleted files" option of the Source Control Explorer (usually the 2nd button of its toolbar) to see your deleted file.
Use the "Undelete" command of the file's contextual menu to restore it in your workspace.
From there, you'll be able to add the restored file to your solution and you'll eventually have to check in the undeleted file to make it available to others, since this file only exists in your workspace.
Context
I am using VS 2015 and TFS as my version control. I do know how to get a history for a particular source file, and also know how to see in editor the picked version of that file.
Question
In the current version of a particular file I read a comment say
// This is a comment
I would like to find in which commit was that line committed. The obviuos solution is opening history, then the different versions of that file starting from initial commit, and searching for the text in the editor window until a looked text is found.
Is there any convenient solution for that?
Right-click inside the open file in Visual Studio, on the interesting line, and choose Source Control (bottommost menu) and then Annotate.
You'll see the file with changeset information along the left edge.
Note that this will only easily give you access to how the current file came to be, if you wish to dig through annotated historical versions it becomes a bit more cumbersome.
Today I accidentally deleted label in perforce. Is there any way to get this label back? Note that I don't want to replace file with revision that was labelled. I just want a label back so that in future somebody can get the files contained within it. I use Perforce Visual Client (Windows) and not command line.
Was it a static label or an automatic label?
If it was an automatic label, you can probably recover it from your spec depot (assuming you had a spec depot).
Whether it was a static label or an automatic label, you can probably recover it from your journal, or from your most recent checkpoint, if the checkpoint was taken after you made the label.
Either way, you'll need a bit of help from Perforce Technical Support, so you should contact them.
I have some project saved in starteam. As there are a lot of obsolete files I can't check in or check out all project, only changed files. Now I copy project from one computer to another for other developer. I expect starteam treats copied project as new item for check in and check out, but it don't.
Forexample:
I modified file on first computer.
I update list of files on second computer and see this file in "check in" list, as I modified it on second computer.
It is incorrect.
I think there is some configuration file or something like, that saves computer (or user) settings. So when project is copied, settings is copied too.
Do anybody know how to change this configuration to set copied project as new instance of starteam???
You should be able to Right-Click on either the file or a close group of files (such as the Modified group) on the file tab within a project and choose the Update Status option. This will cause StarTeam to analyze the file to try to determine if they truly are the same as what is in source control. Then you can refresh the list and it should change most of your files to current.
There is also a configuration setting under Tools->Personal Options->File tab that is "Use file checksums (MD5) to calculate status". This may be useful to you as a different way to have StarTeam determine if the file on your local disk is the same as what is in source control.
It sounds like you are using a custom filter/query for your check-in list. The status for the files that are copied/moved would be "unknown" and they can still be checked-in by checking the "force check-in" checkbox in the check-in dialog. Just verify that the local version is correct by using compare contents before committing it.
You can try switching from a central file status repository to a "per folder" repository. This will create .sbas folders wherever you check-out files and should maintain status for local files when their containing folder is copied or moved. Look under Tools, Personal Options on the File tab under Repository.