A while ago, I moved a large number of files into an new project to better organize my program. Now I have discovered that all history have disappeared since TFS (of course) solve it by removing the files from the old location and create new files in the new location.
My question is whether it is at all possible to restore the history for the files?
This can only be accomplished by using a migration tool like OpsHub or the TFS Migration Tools.
You will have to destroy the files in their current location, do the migration and then re-do the changes made since the migration. There is no way to check in the history "behind" already checked in files.
How badly do you need the history? And Could you live with the history being in the old project?
Related
I'm in a lot of trouble.
During a composer update, somehow, the git process crashes and I have lost all my edits since last commit. It looks like there was an hard reset of my repository.
In eclipse I can find all the history files but I have to iterate on every file to check if it was changed and get the last version.
Unfortunately the massive "restore from local history" on the project doesn't work for edited file but only for deleted.
Is there any way to browse eclipse history and get all the last versions?
I know there are inside .metadata.plugins\org.eclipse.core.resources.history but they are hashed and probably I have many version of the same file.
I have an application that is developed without any version control system so far, and I want to use TFS version control from now.
I have different copies (snapshots) of projects files stored at different times of project development and I want to store them in TFS repository too.
Can I use single workspace and copy each version to that workspace
and check in? Does the changes to all files captured automatically this way?
Where can I submit time and version history for each stored version?
So, you have the project in its current state and versions of it from previous dates?
From my experience, it's best to check-in the current version in Tfs as you would do for a new project. This becomes your working copy and all future changes are checked-in/checked-out and tracked in history.
For the pervious version, create an Archive folder in TFS with sub-folders for each date when you kept a copy of the project. Check in all files of that version into the appropriate folder. This can be used for reference.
Is there a way to tell TFS that one or more files has been moved/renamed by another application (in our case, WebMethods 9) running in Eclipse? We have to move/rename the files using WebMethods and not TFS, because WebMethods does a whole lot of automatic reference updating. However, we haven't found a way to tell TFS "hey, trust me - I moved/renamed/deleted it outside of TFS". Instead, it refuses to commit any changes back to the repository until the old file reappears.
We're working around this at the moment by creating dummy files with the old name and then deleting them again via TFS, but you have to agree that kinda sucks. I'd be happy to treat a move/rename as a deletion of the old filename and creation of the new filename; I just don't want to have to fight TFS over it.
Eclipse: 3.6.1.M20100909-0800
TFS plugin: 11.0.0.201306181529
It depends on whether you use server workspaces or local workspaces.
In a server workspace, TFS requires that you inform the server for every change - to check out a file, rename, delete, etc. This allows TFS to avoid scanning your disk for changes, which is beneficial for large repositories. If you want to force a disk scan with Team Explorer Everywhere, because you may have made some changes outside of Eclipse, you can go to the Actions menu and select Detect Local Changes.
In a local workspace, TFS will examine your disk for changes every time you look at the pending change status. So all you have to do is run tf status or click refresh in the Pending Changes View to see changes made to files outside of Eclipse.
If your workflow involves files changed outside your IDE frequently, I would strongly recommend using local workspaces, however this requires TEE 11.0 and TFS 2012 or better.
My work uses Visual SourceSafe for versioning. When I worked on my local, I add or remove code as I make changes to the file. I want to keep a local repository for my files, In-case If I accidentally checkout from SourceSafe, or If my computer shut down for some reason, so I don't loose my changes. Sometime I modify a function, but I need to see what I did few days ago. I only checked in to SourceSafe the code that is bug free or final version. Can I use svn on my local on same folder that is used by SourceSafe? Any other process/suggestions. Thanks in Advance
If you don't want to check in every modification to your source control tool, the Shelve/Unshelve feature may fulfill your requirements. After you make the modification, you can shelve the files. This way, you don't need to check in the unfinished version, and on the other hand don't need to worry about losing the modifications.
I'm not sure whether SVN can do this. But you can try SourceAnywhere Standalone or TFS. Both of the tools support the shelve feature and provide easy ways to do the database migration from VSS.
We have a new ASP.NET project on VS 2008 environment, and a new TFS server was setup for it, but originally the bin folder of the project also got checked-in.
The team has about 10 active developers at a time and it a big issue now as some of the common libraries remains checked-out by someone or other.
As per the best practice, I now wish to fix this issue and remove the bin folder out of the version control AND I need to ensure that from now on, when a developer checks-in his project, the bin folder again does not gets checked-in. How do I ensure the both things with the correct approach? It would be great if I can do something as an TFS Admin so that from the next day all developers automatically get some settings pulled into their boxes so that they stop checking-in the bin folder once I have removed it from TFS control.
I am a beginner in TFS, as earlier I used SVN primarily, so please point me to the proper steps, documentation. Thanks!
Delete the bin folder in solution explorer, this will add a delete to the pending checkins.
A build should re-create the bin folder, but not add the folder to the project (and thus there'll be no prompting for it to be added to version control).
This won't prevent someone adding it (or anything it contains) back into version control outside of VS (eg. from the command line, or adding the bin folder back into a project). I don't think there is anything you can do to stop arbitrary files being added except training (if your developers cannot handle this, how do they handle all the other "don't do that"s associated with development?)
Updated, since this was written TFS (including VSTS and Visual Studio1) allow files and folders to be ignored via a .tfignore file.
1 Often Visual Studio does not pick up changes to the .tfignore file, needing a restart.