We're using TFS and we're having problems when we switch branches, it's throwing up problems with the TFS bindings every single time.
We still have
.vspcc files
.vsscc files
which is I'm guessing where it stores the bindings, does anyone have any advice on how to easily switch between branches in TFS without pain?
These files are used to store files that are excluded from source control - and yes, they are themselves under source control. I've never had to worry about these before, so I don't think that's where the problem is.
Bindings are normally stored in your actual proj and sln files.
If you have problems with binding, you actually have some problem with your workspace. Either make a new workspace in a new local folder, and get everything from the server there from scratch (i.e. setting up the workspace mapping through visual studio, opening your solution via the source explorer etc. Don't use any clever tricks here - otherwise strange things happen), or try going to File -> Source Control -> Change Source Control, unbinding all projects and rebinding them. VS will blindly write the binding info anew into your project and sln files if you do this.
Especially make sure that all server paths you're checking out can be mapped to a local path.
Switching between branches is just done by opening the appropriate solution file from the appropriate folder/branch. It's not normal that this gives you problems, obviously.
Related
we have a project in which there are a number of launch/debug options referenced in the top-level Visual Studio Code's .vscode/launch.json file.
The issue is that this file needs to be edited for custom local debug options so it constantly triggers Git issues when doing a pull (stash etc) and at worst, sometimes gets committed with changes people needed locally. Yes, I know that's what PRs are for but somehow they keep sneaking in...
Unfortunately there are plenty of entries in the launch.json that need to be shared between devs so ignoring it is not an option.
Ideally I'd like to keep launch.json clean and have it reference another file that devs can tinker with and keep that one out of source.
Is there a way to do this or maybe have an approach that amounts to the same thing?
thanks
with the extension Command Variable you can use the command extension.commandvariable.file.content to read parts of a file and use it in your launch config. You can place the file in your .vscode directory and place that file also in your .gitignore.
The file can be a Key-Value text file or a JSON file.
In eclipse, you can right click in a file and then select Team / Show local history. This shows your local saves and is pretty useful.
Now, I made some changes to a file. I am 100% certain I made them. But they have disappeared. Overwritten by someone else I guess. But when I check my local history I can't see my file changes.
My question is:
Does Eclipse always update the local file history for every save? How reliable is it?
Note: I appreciate people are thinking how can someone else overwrite your files. I am working in a force.com project. When you make changes to a file they are push to a central server. There is source control per se. It is like everyone working with a shared folder.
It depends. Each Eclipse plugin dealing with workspace artifacts can optionally set a flag for local history in its API calls to the workspace resource management when deleting or changing files. If the flag is set, changed files surely get copied into local history. But every plugin can set this flag different.
So even if you might have an editor plugin which always uses local history when saving the edited file, another plugin might delete/modify the file without using local history and therefore interfere.
Summary: Local history is not a reliable way to go back to previously saved versions of a file.
If anyone else runs into this issue, check to make sure you didn't accidentally edit a file in a build or target directory. For instance if you are working on a jsp page and make edits, swear you changed it but they are no longer there in the editor or the local history when you open the file, check to make sure you weren't editing the built version by accident.
This sometimes happens if you are quick to use ctrl-shift-R shortcut to open resources. To avoid this, you can set your build or target folder to derived by right clicking on the folder and checking the derived checkbox. This will prevent the resource from showing in the Open Resource view which could save you headaches later.
To get the code back, I opened the target version and used undo to get to the edited version.
So I decided to add my referenced 3rd party dlls to source control in a separate folder called lib and then reference them from said directory.
This works just fine, but when I want to update the files, TFS seems completely oblivious to the fact that the files have actually changed. Even if I copy over the old files, there seems to be no way of checking in the newer ones. If I choose the Check-in pending changes from the source control explorer, I get an info box saying there are no changes. But if I run a compare to a single DLL between latest and workspace versions, TFS does tell me the files are indeed different.
So is the only solution to delete the files from source control and then re-add them back as the newer versions, or could I just somehow update them?
Team Foundation Server (through 2010, and with 2012's "Server Workspaces") use a "Checkout/Edit/Checkin" model for version control that differs from many other types of version control systems (eg, "Edit/Merge/Commit" systems).
In order to update your binaries, you need to explicitly check them out and update the contents. You can then check them in. This type of system is tuned for dealing with large repositories and large files like binaries since it need not scan your disk to determine whether files have changed or not.
If you prefer to work with an Edit/Merge/Commit type system, which will scan your disk looking for changes and you need not explicitly check files out, this is available in TFS 2012 (as "Local Workspaces").
Have you tried to check out for edit the file before replacing it? It works here...
Is it common for a developer to keep their NAnt global configuration file (NAnt.exe.config) in version control?
And should or shouldn't the the rest of the files in the NAnt installation be added to the ignore file of the version control system?
One use of version control is as a backup. If the only copy of NAnt.exe.config is on a hard disk that dies, it will take some effort to reconstruct it (along with everything else that disappeared and wasn't backed up).
From the corporate perspective, having all of the work in progress backed up is a method for preserving assets. The corporate owner of the source code asset is assured that the asset will not be destroyed.
When there is another backup strategy, then sometimes the rule of thumb is not to put anything into version control that should not be shared with other developers. Such as customized data relevant only to one user and/or machine, or confidential information.
I keep a copy of the NAnt code for the version I'm using. This includes the .config file. This is so my build system is safe from "it disappeared from the internet" events (unlikely, but still).
Beyond that I see no reason to keep it around on your code repository, unless for some reason you've modified it somehow. Most everything in NAnt can be overridden in build files, like the target framework and so on.
My team is taking over a project from a previous team. We use a different TFS server than the original team, and we are also not interested in keeping the history of the project because we are accepting the latest version of the code as the beginning of our history with the project. Branching is not an option since we want to start our history from the current version of the code. We just want a fresh project with the existing code.
I have not been able to create the new project from the old code successfully. I keep getting an error: "Source control cannot add the solution: Solution would span multiple workspaces"
My process for attempting the new project creation:
Create a workspace for the previous team's version of the code.
Get latest version of that code into local mapped workspace directory
Open the solution.
Unbind all projects and solution.
Close solution.
Create a workspace for the new version of the code on our TFS server.
Copy the unbound code on my local box to the new local workspace mapped folder.
Open the solution from the new directory.
"Add to source control" from the new solution.
Then I get the error. I have tried removing the TFS security files out of the code directories in the unbound version and tried changing source control instead of adding to source control (but it just binds back to the original instead of letting me bind to the new).
Is there any other way to do this besides recreating the solution/projects and adding back all the files and references? It doesn't seem like it should be this difficult...
Any advice much appreciated!
Your way should work...there's probably some minor discrepancy in your steps or your initial state that I'm misinterpreting. Rather than debug to death, let's abandon what you've got so far and do this instead:
Fetch the previous team's code onto your machine somehow. Preferably just a straight robocopy from a colleague or the old build server; no TFS connections. If you do have any workspaces associated with the old TFS, delete them now.
Unplug from the network, or otherwise ensure the old TFS is not reachable.
Open the solution.
You'll be prompted: "work offline" or "permanently remove bindings"? Choose the latter.
File -> Save All.
Reconnect to the network.
Create a workspace that maps a superset of the code dirs to some path on the new TFS.
Solution Explorer -> rightclick root node -> "Add to source control."
Per the rules I describe on my blog, step 8 should succeed w/o user intervention (no "browse for folder" dialog, no error popups).
Note: steps 2-4 assume you have VS 2008. If you have 2005 you'll have to manually poke around in the Bind dialog.