I have a project stored in TFS Source Control (2008) that is being worked on by 2 developers. All 3 versions (Developer1, Developer2 and Server) are up to date with each other. However, both Developers report that some files in Solution Explorer say 'Checked out by someone else or in another place' - but the same files viewed in Source Control Explorer say they are available. It seems as though the workspaces have gotten confused but the actual files are 'good'.
Can anyone help?
I've had these lists get out of sync before. What was required was a "Force Get Latest" to refresh the statuses. To do that, you select "Get a specific version", and then select "Latest" and "Get file even if they already exist locally" (or some option like that). This will force the files to refresh, even if they're already up to date, and should also correct their status.
You would think VS/TFS would be smart enough to reconcile this on their own, but sometimes they just don't, for whatever reason.
If I check out the file and then do a "Undo pending changes" it goes back to normal. I think it's this bug, and it doesn't seem to be fixed in any patches or a future version yet.
http://social.msdn.microsoft.com/Forums/en-SG/tfsversioncontrol/thread/2a1c6a8c-0a2b-460c-9335-e31598f1107b
Go to File->Source Control->Workspaces in Visual Studio. Make sure that the devs you have only have 1 workspace. It's likely that someone has created multiple workspaces on his machine and have files checked out there.
TFS maps workspaces to locations on the machine they are created on so if someone pulled down code to multiple places and edited it, you can have one person with code checked out in multiple places.
Also, this link shows you how to see all the files checked out for a particular person.
But I also agree with Preet. It's perfectly OK to have the file checked out by more than one person in TFS. That's one of the minor improvements over SourceSafe.
Do you have SP1 installed? This fixed it for our team. If not, check if any of your devs have separate workspaces and may have checked out files to it
We had this problem when we upgraded from TFS 2005 to TFS 2008. There were problems with the upgrade that forced us to create a new virtual machine and restore/upgrade the 2005 database. We were under workgroup authentication and re-created local user accounts but since they all had new SIDs they were considered different accounts in some respects. All of the original users' workspaces hung around.
Take a look at the commandline tf and tfpt tools for manipulating workspaces, see if you have something orphaned. Attrice Team Foundation Sidekicks has a nice GUI workspaces manager too.
A bigger question. Why do you care if someone else has a file checked out? TFS supports multiple parallel checkouts on files. If you want exclusive control then use a lock.
Sorry to be clearer - I often find that the state in Solution explorer is not worth looking at. If I need a file I check it out. If someone's locked it then I have get told by TFS at that time, otherwise I just work with the file.
Related
We have multiple developers on our team. This works for everyone except one developer, but we cannot seem to find the reason it does not work for this individual. We all have VS premium+, TFS 2012 power tools installed.
We have a branch. We get latest version from branch. Go to windows explorer and delete all files in folder "sdk" (there exist no subdirectories in sdk/). Then we copy into it a bunch of files. (This effectively leaves some files as new files, updated files, identical files or removed files when compared with what was deleted.)
When we go to pending changes, these changes show up under "Excluded Changes - Add(s) 51, Deletes(3)".
Except for one developer. His system does not recognize these changes. What might cause this to not work for him?
If it helps troubleshoot, he is also the only developer that if he were to delete these files via power tools delete option in windows explorer, his .dll files get locked. This does not happen for anyone else either.
This is what we've checked so far:
EDIT: Solution Found - Thank you all for the responses! It was indeed the local vs server workspace option. Setting his workspace to local solved these and a few other issue he was apparently having.
Make sure that the developer is using a "Local Workspace" as opposed to the "Server Workspace".
This is a concept which was introduced in TFS 2012 which helps developers to work offline as opposed to server workspace in earlier versions which did not allow that. TFS 2012 changes up the workspace options. Server workspaces are still available, and work exactly has they have in previous versions. However, TFS 2012 now contains a new type of workspace, called a Local workspace. Again, this is an oversimplification, but in a Local workspace, all the files are read/write, not read-only. The meta-data about the files is stored in a hidden folder in the root of the workspace, which allows edits, renames and deletes to be done locally without any communication to the server.
This improves the offline story with TFS significantly, as you no longer encounter issues with editing read-only files. It also makes it easier to work with other tools (such as Notepad) to edit code files. Making a change to a code file using Notepad will still mark that file as edited, which will be picked up by TFS the next time you connect.
LINK
This only ever happens when a user tampers with a local view of source control (be it a local workspace, or not). If all you ever did was get latest from TFS this would never occur, instead, the local view of what is in TFS would always be properly managed.
Also sounds like a bad merge, e.g. getting latest (where the files no longer exist) then copying in old content (introducing untracked files.) One thing you might try doing to correct the issue is doing a forced fetch from TFS after deleting the local workspace contents BEFORE attempting a merge. This will ensure that the local workspace is up to date an accurate with what the TFS server believes is truth, if it still occurs after merging in content then the problem is almost certainly within the merge process the user is going through (i.e. PEBKAC, or a knowledge gap about what they are doing.)
If you unshelve old content (pre-deletion) into the local workspace (where the deletions have already been performed, according to the SCC, and thus locally because of a sync/get-latest) then the unshelved files will effectively become untracked and it's up to the user to clean up the mess. This is identical to a user having copied loose files into their workspace that TFS never had any knowledge of. TFS isn't going to prune untracked files for you, I believe some other source control tools might do this as a configurable default, TFS does not.
That this is only happening to one developer in the team suggests that the other developers, one at a time, should sit with this developer and drive using "their process" to see if it still occurs for them. More often than not this comes down to a bad process a user has adopted, and putting a different person in the chair can help highlight why it has been occurring and help end it. A disciplined build/source manager and/or developer should not experience this problem.
Very interested in knowing what the problem turns out to be.
If one chooses to "prevent other users from checking out and checking in" from Team Foundation Server:
Can anyone reach the code?
Is there any way to work from another user's computer?
How about shelving?
I would interpret that sort of lock as meaning that someone is going to do something so destructive that it is in your interests to not have an edited copy when that happens. If you think it is a mistake, talk to the person who locked the file.
An option, if you really want to do this, is to remove the readonly attribute on the file yourself (in Windows Explorer or through a shell) and edit the file. That is a good way to cause yourself trouble, though, if the file is going to be changed substantially by the person that locked it. Also, you will need to later mark it as checked out in TFS to actually check it in.
I do not think you will be able to shelve the file (unless you follow the option below) since you will not be able to check it out for edit.
One last option is that you could branch the file, work on the branch, and then merge it back in later. Once again, though, that may be difficult if the edits by the person locking the file are going to be extensive.
I'm not sure I understood all of your questions, but I'll give it a chance:
If by reach you mean, get latest version and read, yes they could. But they wouldn't be able to change the code while it's locked unless they circumvent Visual Studio and change the read-only attribute of the with the command-prompt, Windows Explorer etc.
Visual Studio and TFS 2010 introduces the concept of permissions on workspaces. A workspace now can be private (the old behavior), public limited or public. Using a public workspace, on could edit the files in the workspace of another person. See tf workspace /permission for more information.
You can shelve anything that is in your workspace regardless of locks on anybody's workspaces.
Here is a link to the permission values for TFS
http://msdn.microsoft.com/en-us/library/ms252587.aspx
This should answer your questions
We've only recently begun using TFS (2008) with Visual Studio (2008). A couple of developers discovered the "Get everything when a solution or project is opened" option in VS and decided it was a good idea--and it would seem to be.
However, we've been getting some curious results when opening some solutions. The solutions in question contain several projects of mixed types--mostly class libraries and web apps. The curious part is the list of files in the "Get" dialog box that comes up.
Here's what I've found out so far about the files in the list:
The list is incomplete; not every controlled file in the solution is listed.
The version in the workspace matches the version in source control.
They are not missing from the workspace.
There are files from each of the projects in the solution; though, not every file in each project is included.
The list of files is the same for three seperate developers on three seperate machines.
Running a tf get from a command line does not yeild the same results.
Any insight into this would be greatly appreciated. As I mentioned, this option seems like a good idea, but we're a bit hesitant to rely on it when the results are unexpected.
Thanks.
I know that any files that are not in any project will not be pulled down by TFS when you go to get a latest at the solution level. My guess is that is part of your mixed/unexpected results.
I personally do not have that option checked. I always pull everything down from source control first thing. Whenever I check in source code, I also pull down everything again, compile it and run it first. That way I do not introduce any issues into TFS.
I would make sure that everyone on your development team is using the same general settings for TFS source control. I always have it prompt for check out (saving/editing) and get latest version of item on check out.
Have you applied the latest SP for TFS 2008 (SP1 last I remember). And SP1 on each developer's machine as well?
I'm using VisualSVN with my Visual Studio 2008 and I have to run some sort of commit monitor in the tray area to see if the local copy of project is out of date.
I have two problems with that:
I hate to have it in two places, I want to see that as an icon in my VS,
The commit monitor software keeps an eye on several projects, when I work on project 1 (which VS knows about), I'm not interested in other projects.
I couldn't find any addons for Visual Studio to do that and was wondering if anyone knows about anything good.
Generally, you have 2 options (besides running commitmonitor as you already do):
run update before you start to change something
ignore it all and merge with any updates when you want to commit.
SVN's really designed around the 'wait until you're ready and merge it all together' model, as there's no guarantee that even if you update your working copy immediately before starting to modify it, someone won't commit changes before you've had a chance to commit. So, let the system do the work for you.
The ultimate alternative if you are worried about conflicts is to use the svn:needs-lock property which means you will have to get a lock on any file you modify before modifying it, and you won't be able to get a lock on a file someone else is modifying.
You might like to ask the VisualSVN people if they'd add an option to check the repository when a project is loaded by VS (or run AnkhSVN and implement this feature yourself).
Work has started in AnkhSVN in this direction, we started to implement the 'Synchronize View' that's also used in Eclipse/Subclipse. The things still missing are: Scheduled checking of the repository, and maybe a notification inside VS to tell you that something has changed.
Right now you can manually refresh this view to see local and remote changes (and merges which can be potential conflicts). Patches are welcome to extend this feature :-)
I'm assuming VisualSVN is your "server" (even if running on the same machine).
AnkhSVN is a good Visual Studio Integrated SVN Client.
I just wonder what the best approach is to have multiple users work on a Project in Visual Studio 2005 Professional.
We got a Solution with multiple Class Libraries, but when everyone opens the solution, we keep getting the "X was modified, Reload/Discard?" prompt all the time. Just opening one project is an obvious alternative, but I find it harder to use as you can't just see some of the other classes in other projects that way.
Are there any Guidelines for Team Development with VS2005 Pro?
Edit: Thanks. The current environment is a bit limited in the sense there is only 1 PC with RDP Connection, but that will change in the future. Marking the first answer as Accepted, but they are all good :)
What you need is source control.
You should definitely not open the same files over the network on multiple machines. For one thing, Visual Studio has safeguards in place to prevent you from modifying certain files during a build, but it has none of that that will prevent others from modifying the same files over the network.
By setting up source control, each developer will have a separate copy of the files locally on his or her developer machine, and periodically communicate with the source control system to check in/commit changes. After that, other developers can ask for the latest updates when they're ready to retrieve them.
Use source control to keep a central repository of all your code. Then each user checks out their own copy of the source code and works locally. Then submits only the code that changed.
https://en.wikipedia.org/wiki/Version_control
A number of people have recommended using source control and I totally agree. However you also need do the following.
Exclude your personal options files from the repository (eg your .suo files)
Exclude your App.config files from the repository. - Not entirely but you need to have a Template.App.config. You commit that instead, and only copy your App.config into the Template.App.config when you make structural changes. That was each user has their own individual config for testing.
There are probably some other files worth excluding (obj directories and so forth) but thats all I can think of right now.
Peter
This might sound snide, but if you're opening up the solution from a shared location then you're doing something wrong. If that's the case then you should start using source control (something like Subversion) and have everyone check out a copy of the project to work on.
However if you're already using source control, then it might be a symptom of having the wrong things checked in. I find that you only need the sln, and the vcproj under source control.
Otherwise I don't know...
You should definitely, definitely be working with source control!
This will help stop the collisions that are occurring. Also, if you are making changes to the shared projects this often that it is a problem, then also ensure that all code is tested before getting checked in (otherwise they may bust someone else's build), but make sure they check in often (or time gained from not dealing with prompts will be lost in merging conflicts) :)