The repository folder I have been working in changed over night. Files that were in the folder are no longer in it, both in svn and the source folder. The attached pictures show what has changed between the days. The small folder 'kettle' is all that is left from the large one (what it use to look like). It looks like this in windows explorer as well. Also, since I had local changes I had no put to version control yet, I do not want to just re-checkout and lose my changes. Any insight to a solution to getting the original state of my folder would be greatly appreciated.
The current state of the folder:
What the folder looked like yesterday:
Looks to me like someone renamed the project folder in the repository. You will need to
back up your changes (project folder into a zip for example) and try to sort out things manually.
Another solution could be creating your own branch that just mirrors the current state of your workspace. But merging the changes back to trunk might be problematic here, too.
Related
At my workplace, I have managed to install and use locally Tortoise svn, to easier trak the implementation of the tools. For the new projects, it's easy because I start from scratch with the version control.
Now, for the past projects, I have copied the entire folder to keep a versioning.
It looks like this:
TempProject 20.07.2017
TempProject 21.07.2017
TempProject 22.07.2017
....
Is there a possibility to integrate all this changes with Tortoise?
Meaning , I want to have a base, than commits, for each version
Thank you...
I have managed to solve it.
I copied, one by one, the content from each folder (TempProject 22.07.2017 etc.) into my working copy folder, then I opened the project and committed the changes.
Maybe it's not the most efficient method, but at least it wasn't very complicated
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.
I have a project on codeplex and I'm trying to reorganise the tree structure so it makes a bit more sense and is easier to work with.
This is my current layout:
TopLevel
|-->src
|--->ProjectA //This is where all the files are held
|-->Core //plus three more folders
|-->MyProject.Core
|--->trunk
|-->src // I want to move all the folders and files in ProjectA into here
So I want to move all folders and files under ProjectA to ProjectA.Core/Trunk/src.
I checkout the whole source tree and right-clicked dragged the folders under ProjectA folder and selected "move versioned files here" into the src folder, that marked the folders in Project for deletion but the new files in src still had the green tick next to them and not the blue plus button.
After I commited the changes I had a look in the repo browser and saw that the folders hadn't been moved and were still in the ProjectA folder.
How can I move folders and the files in those folders to a different folder in subversion? Without loosing version history.
I'm using TortoiseSVN.
EDIT: Turns out it must have been codeplex, I moved my project to google code and everything works fine.
This type of reorganisation is easy to do with the Subversion command line client, which might be a viable option for you. Here's the commands that would do it (from the TopLevel directory):
svn mv src/ProjectA MyProject.Core/trunk/src/
svn ci -m "relocate ProjectA"
You can also combine both commands into one by using URLs as the source and destination, see the svn mv documentation for details.
I haven't found an easy way to do this sort of thing with TortoiseSVN, so when I need to I just use the command line client to do it.
I don't know what I was thinking when I suggested to export and import the files. I think I've been away from TortoiseSVN too long. I recall that tortoise svn actually has a really easy method of moving whole directories. It's not just obvious... but it's not clear why you can't get the result committed correctly to the repository. Presumably you did commit on the parent of all these folders.
Here's the summary:
You must select the folder and files you wish to move, and after doing so right click on the selection and drag it with the right button to the new location. You will get a context menu asking if you wish to relocate the files in the repository. This retains the history. Now your old files are marked for deletion and your new files should be marked as added. (I've found the status icons to be... not always representative of the true status). Commit this as one commit. I like to be picky and use check for modifications on the root of the checked out files, and then select exactly which changes I want to commit before doing so.
In the case of just moving one folder like this, open a window that is a parent to this folder, and another window that will be the new parent of this folder. Right click and drag all in one motion. I can't believe it takes this much text to describe a simple mouse action.
The standard strategy for dealing with nasty moves is, in the worst case, create all the new directories, move only the files from the old directories to the new directories, and then remove all of the old directories. This should get around almost any problem you encounter, and you can take shortcuts (moving entire directories and or trees) where that does work.
This will preserve history on all files. It will not preserve history on directory creations, but usually this is something you can live with, since you do have history for all of the file moves, which include the old and new directory names.
As of late, my team and I have been hard at work turning our inherited source code into something we can live with. Part of this process is to make the source control image look a little more like what most people might expect to find when browsing a repository.
The original structure contains a branch called "Branches", the contents of which are what one would find in a "Tags" folder in systems like Subversion. Since "Branches" is a bit too non-specific for my tastes, I wanted to change it to "Tags" -- but it would seem that I cannot do that unless I create a workspace mapped to the root of the repository and then create a working copy from it. On this project that is a huge file transfer (lots of old tags).
Please tell me that I have just overlooked the obvious and should really spend more time reading the instructions. Is there no simple way to do this without pulling everything to the client first? I really enjoy most aspects of TFS, but this is something that would have taken 15 seconds or less in Subversion -- so I hope I'm just missing something.
Thanks in advance to any responders.
You don't need to get the whole folder but you need to get the folder itself. You can't do this from within the IDE but you can from the command-line:
tf get c:\dev\
Because we haven't specified the /recursive option it will only get the immediate children of c:\dev\, which would be folders such as trunk and branches.
For there you can rename the folder:
tf rename c:\dev\branches c:\dev\tags
And then check-in the rename.
Regards,
William D. Bartholomew (Team System MVP)
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.