Accidentally changed workspace without checking updated items in - version-control

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.

Related

how to get back delete responsitory from source tree

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.

TFS deleted my files when changing the mapping

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.

SQLite database cached due to SVN

My iPhone application uses Core Data and a SQLite database; versions are being tracked using SVN. Adding data to the database is not reflected in the application. I make sure I delete the project out of the simulator and that the new database is added as a file to the project. I suspect the data is being cached in another location.
Please note, SVN shows no changes to the database, even when directly edited. Also, if I copy and paste the project to a new folder, delete the hidden svn folders, delete the build folders, edit the DB, delete the project out of the simulator, then compile and run, it works the first time. After that, the data again is cached in some unknown location.
Any ideas where this could be?
UPDATE:
The solution to this was to exit my SVN Client (Versions). I am still unsure of how this affected updates to the DB; I wouldn't think it would block or revert any changes. I am now able to edit and save changes.
Thanks everyone for the help.
Could be more than a couple of things going wrong here. If you have the SQLite DB added to your project by reference, and if you haven't made any code changes, then when you click "Build" you won't see your changed DB resource copied over. Basically, Xcode has long-standing problems sensing when (referenced) resources have changed. Doing a clean build is your nuclear option, as depending on your compilation time, it can take quite a while. A better option is just to delete the .app bundle out of the build directory. This doesn't take as long for Xcode to reconstruct, although if you have a lot of resources, it also can take a while. The best option (the one I use) is to leave a "dummy" file at the root level of the folder included by reference (let's say it's a blank text file), and when I update a resource, I will make a change to the dummy file, undo the change, and hit Save (inside Xcode). This triggers something in Xcode to recursively go through that included directory to see if anything's changed.
All that aside, if you are modifying the DB file, and SVN is telling you that you haven't made changes to it, you have some other problem going on. Simply put, are you certain that the DB file has been added and checked in already to SVN, so SVN knows about it? And are you certain you're editing the same file you're checking in SVN?
Could it be that the database is elsewhere? Have you tried opening the database manually to see if the right records are there?

What's the best way to take my TFS source controlled project on the road and then bring it back?

So my desktop is my primary workstation for VS2008 that's supported on the backend by TFS. I'm hitting the road for a week and I'd like to take a project with me. I'd like to checkout the entire project, copy it to my external HD and then work off that. I know that when I try to open it on my laptop that won't be connected to the network, I'll be asked to remove the source control bindings. So do I do that, and then when I come back to the office just copy all the files on top of my checked out version? I just don't wanna mess anything up. :)
You can take your TFS solution offline on your Desktop Machine. Then you copy the working directories onto your laptop (assuming your laptop has VS and everything else set up) it will allow you to continue working.
When you get back, you copy your Laptop solution root folder over your Desktop solution root folder, and then take the solution back online. Depending on the size of your solution, this might take some time, because it will do a file-by-file comparison to see what was changed (it will do this only against the files that you changed on the road, because your solution in an 'offline mode' will still keep track of which files were changed). Then a list will appear in your pending changes. You can check each of those (as you normally would) before checking them in.
You could use SvnBridge and get it out into a svn repository, and then do whatever you want with it because svn handles working offline really well, and then check it back in when you're done.
Since you have VS2008, this should mostly be handled for you. No need to make extraneous copies.
Here's a click-by-click walkthru of the new offline feature: http://teamfoundation.blogspot.com/2007/12/offline-and-back-again-in-vs2008.html
If you want to manually manage the offline state, Ben Ryan has several instructional posts: http://blogs.msdn.com/benryan/archive/2008/07/09/using-tfs-2008-power-tools-to-modify-server-s-offline-state.aspx
Checkout the entire project if you can.
Don't remove the source bindings
Before you check-in make a copy of your local source just to be safe.

TFS - Branching for experimental development: Solution fails to load

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.