I changed several files in my project and I haven't checked those files in and I want to get the last version of the project from TFS. Right now all the local files have been changed (that broke the project) and I want get the code from the last check-in/changeset and basically void the current changes (that are not checked in). I changed like 10 files and lot of code. Is there a way to get the project into a different folder and run it? I still need the current changes because I was fixing the code.
How about backup your current changes first, retrieve the last changeset and move it to your desired folder, and then you can restore your backup in your working folder and continue working on it.
Related
I am working on a project and need to see where I have made changes to a file-- these should be marked in blue but for some reason the changes only appear for some of the files, even though all are added. According to the documentation:
"When you add a new file or delete an unused file, you must commit
both the file and the Xcode project file (called project.pbxproj)
together for your project to remain in a consistent state."
But it is not clear to me where this file lives or how to include it in the commit.
The usual fixes (restart Xcode, restart computer...) have not helped and I have had to resort to the very messy procedure of using Time Machine to revert to a previous state.
I have a project under source control using TFS and Azure DevOps.
It all works normally except for one thing: When I check in a file, I get this error message:
TF10122: The path '$/KnowledgeBuilder/V2/$tf/1/1f8c47a1-8066-42d7-b56c-c9960b0ee7ea.gz' contains a '$' at the beginning of a path component. Remove the '$' and try again.
The check-in does in fact succeed, but I get three of the above error messages each time. I can simply ignore this, but it is starting to get annoying.
It appears the folder in question is a TFS created and controlled folder. I tried deleting the folder, but that remove the Project from Source Control, so I restored them.
Is there a way to resolve this?
This occurs in VS22 on a Blazor Server Project. I have tried opening the Project in VS19, making a change, and then checking it in, and it works fine. So, it must be something specific to VS22.
Someone, sometime, at some point, added that $tf folder to version control. It should not be there, ever, under any circumstances -- that's the folder that TFVC uses to track local workspaces. That's why removing it messes up your workspace.
Make sure any pending changes are committed or shelved first.
Remove that folder from source control. Make sure the change is checked in. You might need to use a server workspace to do this so that the $tf folder isn't relevant.
Use tf get to force a re-sync of your local workspace. tf get /all /overwrite should do the trick. If it doesn't, then just delete and recreate the workspace.
Add $tf to your .tfignore file (although if memory serves, that shouldn't be strictly necessary -- I haven't worked with TFVC in a few years)
Another user on a different machine checked out files and was working on them until her computer crashed, keeping those files checked out. Is there a way to check in that work?
Some files in one repo she's made some changes to since her computer was reimaged. She was able to save them, but I am not sure if they will be permanently changed. If the old files are checked in, will it affect the changes that she's made in the past couple days? Is there a way to accept the most current changes?
I've used the workspace sidekick from Attrice, but not sure if that is on the right path.
Files that are checked out should be viewed as a reservation. If the files exist in the form that can be checked in either:
Recreate the working folder and recreate the workspace and copy the files to the correct subfolders and check in
preferred approach cancel the check-in, create a new workspace, get latest and merge the copies of the files into the new workspace and check-in.
the undo from the other workspace can be accomplished with the following tf command.
tf undo /workspace:OtherUserWorkspace;OtherUser $/Project/ItemName.cs /s:http://yourtfsserver:8080
We use VisualStudio with SVN and VisualSVN.
I restructured the solution by moving (cut and paste/drag and drop) and renaming a lot of files.
Never heard a complaint from VisualSVN, now it is time to commit it refuses to do so:
Commit failed (details follow):
Error: Cannot commit 'C:\Sources\xxx' 'xx\Model\Model.cs' because it was moved to
'xxx\NewModel.cs' which is not part of the commit; both sides of the move must be committed together
That is correct neither file exists any longer at the given positions, and frankly I don't care.
I need SVN to store the solution as it is now. It is OK that I will not be able to trace change history for moved and/or copied files.
Is there a way to force the commit?
It seems that you get the error because you commit only the part of the move action. Moves in Subversion consist of svn copy (to the new item location) followed by svn delete (of the original item), so both sides of the move must be committed in one revision together.
I suggest following these steps:
Visual Studio | VisualSVN | Commit....
Make sure that both sides of the move you've performed are listed in "Changes made" list view and try to commit. Do you still get the same error?
If the first step fails, go to Visual Studio | VisualSVN | Windows | Pending Changes. Right-click the root node of your solution / working copy and choose Commit.... Still getting the error?
Go to Visual Studio | VisualSVN | Set Working Copy Root... and make sure that the working copy root points to the root of your solution's WC. Attempt to commit after this step.
I ran into this exact problem over the past week while refactoring some code and renaming numerous files. I was able to correct the problem as follows:
I committed my project folders one at a time (at the folder level) to isolate the problem. In my case, all but two folders committed without errors.
In the problematic folders, I committed the files individually. I now had a green dot next to every file, but the two folders were still yellow.
I tried to commit the folder again. It gave me the same error, but now it just showed the files it was having an issue with in the dialog box.
The files that were giving me a problem were files that had been deleted and not on my drive. I right clicked on each file and reverted it. This put the file back on my drive, even though it wasn't part of my project in VS.
Lastly, I added the file back to the project in VS and then immediately deleted it and committed the project. Everything appears to be fixed now.
TL;DR -- If SVN thinks a file is part of your project, but the file is missing from you HDD, it will give you this error. Simply revert the file to get it back on your drive. To clean it up, add the file back into your project and then delete it within VS to get everything in sync.
Please click refresh button first, after refresh in commit package Visual Studio will be included delete and rename rules, needed for SVN
I pressed Alt-E which I mistakenly thought was Merge Changes In Merge Tool, however, that was actually Keep Local Version. Is there a way to go back? Is there a way to find out what was merged, as in what file? Ugh! :(
I have completely stopped working in case I erase something of importance.
I'm using MSVS 2013 Professional.
Here's another possible approach.
If you know what version of the code you started with before you started making your current batch of changes, you can grab a copy of your local workspace files. Then Undo all your Pending Changes. Then delete all the files in your local workspace (in Windows explorer). Then do a Get Specific Version to get back the old version of the files from where you started, then copy-paste in your updated files from your backup copy. Then do a Get Latest. This should retrigger the Merge process.
I don't know a great answer to this problem, but I do know one thing you can do (I hope you don't have a massive amount of pending changes, or this will get tedious).
The problem is that TFS thinks you have now merged the server changes (other devs changes) into your workspace, even though you told it to basically toss them. If you try to check-in now it will blow away other developers changes in TFS.
What you can do is go through each file in your pending changes window, and do a Compare With Latest Version. This will show you the differences between your local file, and the file in TFS. You will notice two types of differences:
the changes you made which you can just skip past.
Changes that other devs made and are on the server, these differences will show up as though you have deleted/undone that code locally
For the changes that other devs made, you will have to manually reapply them in your local workspace before you check-in.