I had quite a big solution with a lot of code here. Because of some issues with TFS I wanted to create a new 'clean' repository. I removed the mapping to the old repository, and tried creating a new mapping. This resulted in an error that there already was a mapping to my solution. I went to the Source Control Explorer -> Workspaces and deleted the mapping to my solution there. After that I was able to map my new repository to my solution.
But when I checked my hard disk I almost had a heart attack: TFS deleted ALL my code files! The directories and dependencies were still there, but all my project files, my solution file and all of the code was gone!
Please StackOverflow, help me out here! This is a LOT of work that is now gone and I really desperately need it back :(
Edit: I'm currently trying to recover my files with a couple of file recovery tools (like Recuva), but none of them can find any deleted changes. But the files are really gone, Windows search doesn't find them, and they aren't hidden either. Can anyone tell me why this is? Are the files still on my SSD then?
Source control systems like TFS all work along very similar lines. They treat the server's version of the code as "the code" - it's the master copy, and is "owned" by the server. You can then get a copy of the code on your PC (by adding a workspace mapping you tell it where you want it to put this copy). You can make changes to your copy of the code, and then check them in to apply them back to the master version of the code on the server.
So if you change a workspace mapping (e.g. change the location of your copy of the code from folder A to folder B), what you are telling the source control system is "please take away the copy of the code that is in location A, and put it in B". So this is why it deleted all "your" code. It wasn't "your" code, it was a copy of the server's code - you asked it to put it somewhere else on your PC ... so it did.
However, if you had edited any of the code in your workspace, the files would have been checked out, in which case TFS would have known that you had pending changes, and it shouldn't have deleted those files - it should have reported an error as you were trying to change a workspace mapping that included pending changes.
The only way this wouldn't happen is if you manually changed the files to be writable and made changes to them outside of Visual Studio/TFS, so that TFS did not know you had made the changes. If you "secretly" changed some files, TFS may have thought they were unchanged, and therefore permanently deleted them. These files may not show up in file recovery tools because by asking TFS to relocate the workspace you got it to delete the files and then immediately re-get them (into a new folder), which will almost certainly have overwritten the data of the deleted files.
If your changes might have been checked in, then you can find them like this: go to your Team Project in the TFS Source Control view. Right click the Project and choose the "View History" option. This will list all checkins to the project in reverse historical order - if you checked in, then you should see your checkins here. (You can double click any changeset entry in the history to view the list of files that were changed, and if you right click any file you can "Compare..." to see a diff that illustrates exactly what changes were made)
If the changes are not in your checkin history, then I'm afraid you've lost them.
You've probably already learned this, but it's important to learn to use tools like source control properly - they are useful and powerful tools, but they can be dangerous if you don't understand how they work.
If you checked all in before you removed the mapping. The source is almost in the repos. But if not it is already gone sorry :(
Sorry for your loss.
TFS didn't delete anything. You simply never checked it in. If TFS had "deleted" your code, then you would be able to see your code in the history in Source Control Explorer. You would see that there was a changeset with "Delete" operations against your code.
You would then be able to roll back that changeset and get all of your code.
Related
I suddenly deleted the local repo that contains all of my code. Now all of my code is deleted. I do not know where the deleted files went or any method that can help me to restore all the code.
What I have done, is right click on the repo-name and then select delete
Don't you have any save on a back-up system? Maybe on an external drive or something like that?
Have you checked your trash bin? (If you're on Linux, check ~/.local/share/Trash/files)
Just a little advice: Configure an automatic back-up on an other drive at a fixed time (once a week). That way, even if you loose the latest modifications, you don't loose the whole code.
I have a big problem. One of my coworkers left the company yesterday and one of his projects went into my hands. We work for a company which set up a TFS for us to work together on one big project. He accessed the TFS by using his LiveID. When he left yesterday, he hasn't checked in his new/updated items and I forgot to do it today before I disconnected him and logged in with my account.
So basically I still have the updated solution on my local hard disk. But since my workspace is mapped to another folder, it actually downloaded old versions of our code files.
How can I copy the updated, not-checked-in items into my local workspace folder and check them in?
UPDATE: I have tried changing the local workspace folder by going to File --> Source Control --> Workspaces but I get another error telling me that the folder I'm trying to map (the one used by my ex-coworker) belongs to somebody else.
The easy way would be to log in as him, but a it is a Microsoft ID rather than an AD account you are kind of scuppered there. You o however have the files from disk. If you copy the files from his workspace and drop them over the top of your workspace TFS will detect the adds and edits for you. You will then have to go through and look for any deletes yourself..
a...make sure it builds, run all your unit tests, and then check in.
I have a rather large project made up of lots of...projects, each with their own Debug and Release folders along with a bunch of other files that I don't really want to commit like .rc and .user.
At the moment I right click the top folder, click commit and eclipse asks how i would like to store all these "new files" it has detected, how do i tell it I don't want to commit any of them.
So far i have read that i need a .cvsignore file but that doesn't seem to make a difference. I tried doing a "clean" of the project but there was still plenty of files i don't want.
Does anyone have any advice on how to make this at the very least less painful? I have even tried doing a search on the project for certain . files I don't want and deleting them but some of them re-create themselves....
Note: I usually just commit the files I want by selecting them individually but this time it is about 600+ files...
UPDATE
Sorry for taking so long. Thank you to everyone for their answers, they are all technically correct, none actually worked for me, but i will mark Burhan as the best answer
I have tried the cvs ignore route before and it never seemed to work, unfortunately it still didn't work for me.
The per directory approach does seem to work but its quite a painful process in this case. But khmarbaise is correct this is the documented method, and is actually correct.
The Global method Burhan mentioned seemed ideal but didn't seem to work, Perhaps i have mis-understood where CVSROOT is, i always assumed it was the "CVS" folder located in the top most directory, it includes files like "Tag", "Root" etc. is this wrong?
#thkala, the "Team->Add to .cvsignore" was always greyed out for me and therefore could not be used but again is another valid route when it does work.
However I think i have finally realized why I have so many problems with CVS and eclipse and i would like to post what finally worked for me and what may actually be the missing link for the .cvsignore route.
I always checked the project out this way: CVS Repositoris -> Right click the branch -> check out as -> check out as project in the workspace.
However the reason i was having so many problems with cvs and indexing what i should have done is:
*CVS Repositoris -> Right click the branch -> check out as -> check out as ...New Project Wizard. -> retype branch -> Makefile Project with Existing code * (as a side note does anyone know how to specify the directory for the new project?)
Anyone who didn't do this and doesn't want to re-checkout can remove the project and re-add it using "new project"
At this point "Add to CVS ignore" was no longer greyed out. So you can now use that route if you want.
At this point however i tried something else i hadnt used before Team->synchronize with repo. This Seemed to bring up only the Changes i had made and therefore did not have any of the "new files" which was all the files i didn't want to commit. I was therefore able to simply double check the folders and then do a blanket commit on all those files in the sync view. It is really important to note that I actually had some build generated .h and .c files, so if i had succeeded in ignoring certain files, i would have still checked in these unwanted files (silver lining i suppose).
Perhaps i should rephrase the question to "large commit" to be more helpful to future cvs + eclipse newbies? anyone agree?
You can add a .cvsignore file on a per-directory basis containing the files in the directory that you want cvs to ignore. Note that if you want this to persist, you will have to commit that file too. #khmarbaise pointed to some documentation that talks about what kind of thing you can put in this file.
If you want to ignore certain file types on a global basis, then you should check out the CVSROOT module and make additions to the cvsignore file in that module (note that lack of a "dot" at the start of the name). Don't forget to commit this change for it to take effect.
Both .cvsignore and cvsignore files can contain the same types of information.
You can create a file which is call cvsignore which contains certan file types. I can't remember if it's called ".cvsignore" or "cvsignore". Check the documentation.
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
Disclaimer: I'm stuck on TFS and I hate it.
My source control structure looks like this:
/dev
/releases
/branches
/experimental-upgrade
I branched from dev to experimental-upgrade and didn't touch it. I then did some more work in dev and merged to experimental-upgrade. Somehow TFS complained that I had changes in both source and target and I had to resolve them. I chose to "Copy item from source branch" for all 5 items.
I check out the experimental-upgrade to a local folder and try to open the main solution file in there. TFS prompts me:
"Projects have recently been added to this solution. Would you like to get them from source control?
If I say yes it does some stuff but ultimately comes back failing to load a handful of the projects. If I say no I get the same result.
Comparing my sln in both branches tells me that they are equal.
Can anyone let me know what I'm doing wrong? This should be a straightforward branch/merge operation...
TIA.
UPDATE:
I noticed that if I click "yes" on the above dialog, the projects are downloaded to the $/ root of source control... (i.e. out of the dev & branches folders)
If I open up the solution in the branch and remove the dead projects and try to re-add them (by right-clicking sln, add existing project, choose project located in the branch folder, it gives me the error...
Cannot load the project c:\sandbox\my_solution\proj1\proj1.csproj, the file has been removed or deleted. The project path I was trying to add is this: c:\sandbox\my_solution\branches\experimental-upgrade\proj1\proj1.csproj
What in the world is pointing these projects outside of their local root? The solution file is identical to the one in the dev branch, and those projects load just fine. I also looked at the vspscc and vssscc files but didn't find anything.
Ideas?
#Ben
You can actually do a full delete in TFS, but it is highly not recommended unless you know what you are doing. You have to do it from the command line with the command tf destroy
tf destroy [/keephistory] itemspec1 [;versionspec]
[itemspec2...itemspecN] [/stopat:versionspec] [/preview]
[/startcleanup] [/noprompt]
Versionspec:
Date/Time Dmm/dd/yyyy
or any .Net Framework-supported format
or any of the date formats of the local machine
Changeset number Cnnnnnn
Label Llabelname
Latest version T
Workspace Wworkspacename;workspaceowner
Just before you do this make sure you try it out with the /preview. Also everybody has their own methodology for branching. Mine is to branch releases, and do all development in the development or root folder. Also it sounded like branching worked fine for you, just the solution file was screwed up, which may be because of a binding issue and the vssss file.
#Nick: No changes have been made to this just yet. I may have to delete it and re-branch (however you really can't fully delete in TFS)
And I have to disagree... branching is absolutely a good practice for experimental changes. Shelving is just temporary storage that will get backed up if I don't want to check in yet. But this needs to be developed while we develop real features.
Without knowing more about your solution setup I can't be sure. But, if you have any project references that could explain it. Because you have the "experimental-upgrade" subfolder under "branches" your relative paths have changed.
This means when VS used to look for your referenced projects in ..\..\project\whatever it now has to look in ..\..\..\project\whatever. Note the extra ..\
To fix this you have to re-add your project references. I haven't found a better way. You can either remove them and re-add them, or go to the properties window and change the path to them, then reload them. Either way, you'll have to redo your references to them from any projects.
Also, check your working folders to make sure that it didn't download any of your projects into the wrong folders. This can happen sometimes...
A couple of things. Are the folder structures the same? Can you delete and readd the project references successfully?
If you create a solution and then manually add all of the projects, does that work. (That may not be feasable - we have solutions with over a hundred projects).
One other thing (and it may be silly) - after you did the branch, did you commit it? I'm wondering if you branched and didn't check it in, and then merged, and then when you tried to check-in then, TFS was mighty confused.
#Kevin:
This means when VS used to look for your referenced projects in ....\project\whatever it now has to look in ......\project\whatever. Note the extra ..\
You may be on to something here, however it doesn't explain why some projects load and others do not. I haven't found a correlation between them yet.
I think I'll try to re-add the projects and see if that works.
#Cory:
I think that's what I'm going to try... I have about 20 projects and 8 or so aren't loading. The folder structures are identical from root... ie: there aren't any references outside of DEV.