I have a project stored in visualstudio.com. However when I have a file checked out, my colleagues can do the same. How can I disable that feature? I went to TEAM -> Team Project Settings -> Source Control in VS 2012 and disabled "Enable multiple check-out". However nothing seems to have changed. Do I need to do something else with that? Secondly, I read this but when I right click a file and chose "Check-out for edit", it only has "Unchanged" and "CheckIn" lock types but no "Check-out" which, as I understand, is the thing I need to chose. So, is there a way to make sure only one person can edit a file at one time?
What kind of workspace are you using? Make sure you're using a server workspace. If you're using a local workspace which is the default when you create a new workspace in VS 2012/TFS 2012, checkout locks are disabled. For more info on local and server workspaces:
Decide Between Using a Local or a Server Workspace.
Related
Just learning about workspaces in TFS/Visual Studio 2012. I am testing using a Dev Branch and a Release Branch. I have setup workspaces that map to each of these branches from the server to the local folders.
Now I was assuming, and maybe incorrectly, that when I changed the current WorkSpace via Source Control Explorer, that since the workspace knows the mappings, it would then switch my Solution Explorer to show the local folder files associated with that workspace. This is not the case. Again, I was thinking it would act like FileZilla when you choose a site bookmark, that it then knows to connect to the server side code and then the corresponding local code....
So how do you actually access the local code in the Dev branch and then switch to the Release branch local code? Do you just have to close the Dev solution, then open the Release solution?
I see that this works, but it is confusing to know which version you are working with as the solution name will be the same when it is displayed in the Solution Explorer. You have to maybe r-click and view the properties of the file paths to see which actual version (Dev or Release) that you have opened. Same issue when opening VS and it lists the same solution name under the Recent section...you have to hover over it to see which version you want to open...all in all, it just seems like there is a decent chance that you could confuse the 2 and start coding in Release when you mean to code in Dev... I know you have to be careful, but this definitely doesn't help.
It would be nice, and maybe I missing this, if from when you first open VS that it would give you the option to open a WORKSPACE instead of a solution/project. At least that way, you can name your workspaces to be meaningfully different.
Unless you have rely big code bases I usually have a single workplace for all of my dev work. That way I just open any solution that I want.
I use workspaces for other tasks, like admin or merging... Or bug fixing on specific versions.
I'm fairly new to TFS, coming from a a CVS and Subversion background, with some Git and Mercurial influences. I find that I am often fighting with it because it doesn't compare the state of your working copy on the file-system with that in version control. Instead, it shows you what it thinks is the file system state, based on what you've done in Solution Explorer and Visual Studio.
For example, if you delete a file in Solution Explorer and, later, replace the file in some other tool (usually Windows Explorer) TFS will insist that the file is deleted. Further more, it will 'detect' the replacement and suggest it as an 'Add' but it won't let you promote that because the 'Add' conflicts with the 'delete'. There is no easy way to resolve this because you can't undo the 'delete' either - you can't undo a 'delete' if the file is physically still present on the file system!
This, in my opinion, is a disaster. Why can't it just forget what you have previously done in Solution Explorer and show you the current state: i.e. the file has merely changed (or remains unchanged.)
Similarly, if you edit a file in Visual Studio and subsequently edit it to undo those changes, TFS insists that the file has been modified, sometimes, even if there are no effective changes - the committed revision is identical to the new one after your changes.
Is there any way to break this link and disable tracking of you actions inside Visual Studio - i.e., when you refresh 'Pending Changes', it looks at the current state of your working copy on the File System and diffs THAT with the head revision?
If you're using TFS 2012, you could use a local workspace: this uses the local file system in a way more analogous to SVN, although it may not match it in every way..
Note that if you have more than 50,000 items in your workspace, this is not advisable due to performance considerations.
This doesn't have anything to do with Solution Explorer, per se. Team Foundation Server, when it operates in "Server Workspace" mode is a checkout/edit/checkin type of source control system. This means that you must explicitly inform the version control system that you are making changes. This allows it to scale to very large repositories, since it does not have to scan the filesystem, like an edit/merge/commit (like TFS "Local Workspaces" or Subversion) would, or like a distributed version control system (like Git) would.
Visual Studio or Eclipse will interact with the source control system, so that when you start editing (or delete, etc) a file then it will inform TFS of your changes so you do not need to make these changes manually. If you interact with your working copy from another program (Windows Explorer, Notepad, etc) then you will need to manually pend those changes with the tf command-line client or with Source Control Explorer.
If you find this frustrating and do not require the scaling abilities of TFS Server Workspaces, then you can use a TFS Local Workspace, which will scan the filesystem and notice any changes you make outside of your IDE. Or, of course, you can use the Git support built in to Visual Studio and TFS 2013.
I have a solution with two projects. I just marked the solution and checked it in and now all files have that little image of blue padlock on the left side which obviously means that they are marked as read only.
I've been working only with Tortoise SVN till now and this is my very first check in to TFS, so why does this happen, or if it is too complicated for an answer here, at least how can I return the state of my files (the entire solution maybe) to normal.
Also I've been struggling to find a good reading/tutorial on how to use/execute the basic tasks for TFS from Visual Studio 2012 so if someone can share a good source of information about the topic it would be much appreciated.
This is, in fact, normal. You are using a "server workspace", or connecting to a TFS server from before TFS 2012. Team Foundation Server has multiple modes of working:
A Checkout/Edit/Checkin system (via "server workspaces") means that you will need to explicitly check a file out to begin editing it. Files are kept read-only in order to indicate to you quickly what files are checked out and which files need to be checked out. If you simply start typing in an IDE or editor that understands TFS version control (Visual Studio, Eclipse) then the IDE will check the file out for you. Otherwise, you will need to check the file out manually (by selecting "Check Out for Edit" in Source Control Explorer or by running tf checkout <filename>.)
This type of system is very useful with teams that have very large repositories or very large files in those repositories; by explicitly instructing the source control system that you are editing a file, you avoid the need to scan the filesystem.
An Edit/Merge/Commit system (via "local workspaces") means that you do not need to take any explicit action to check a file out, when you query your pending changes, the disk will be scanned to determine what changes you have made. Local workspaces are the default in TFS 2012, though you or your administrator may change this default.
This is similar to the way Subversion operates and is generally suitable for most repositories, however if you use keep large binaries in your tree, it is probably not a good option.
A Distributed Version Control system (via git) means that you have a complete clone of the repository locally and allows you to work completely independently while offline and share your changes or receive other peoples changes as you see fit. Git is new in TFS 2013 and Visual Studio 2013.
This type of system is very useful for highly distributed teams and teams that want to take advantage of novel branching strategies but may not be appropriate for teams who have very complex requirements around fine-grained permissions.
If your server is TFS 2012 or better and you want to convert your existing server workspace to a local workspace, you can open the "Edit Workspace" dialog and in the advanced settings, change the type of your workspace. This will make all your files writable and you will continue working in a Subversion-like mode.
this is quite normal, having locks to the files.
However, you can set the level of source control of different check in / check out strategies.
link: http://msdn.microsoft.com/en-us/library/ms181237(v=vs.90).aspx
For the global documentation :
Source control : http://msdn.microsoft.com/en-us/library/vstudio/ms181368.aspx
Tfs global : http://msdn.microsoft.com/en-us/library/vstudio/hh529827(v=vs.110).aspx
I am trying to use TFS storing non-VisualStudio source code. Working with Visual Studio 2012 and Microsoft's online Team Foundation Service.
I've setup a TeamProject and mapped its root to a local folder. All it contains at the moment is a BuildProcessTemplates folder in it. (which was created as part of the TeamProject)
I copied my source code externally (using windows explorer) into the TeamProject root folder on my hard drive and since my TFS workspace is NOT a server workspace but rather a local workspace, I was expecting VS to detect the folders/files and show them in Pending Changes window .... yet it doesn't.
Interestingly, new files in the root folder are detected as "Excluded Changes" but new folders are not detected.
What am I missing?
First make sure the newly added folders contains files.
Are there any Detected changes shown in the Excluded Changes section?
Pending Changes > Detected changes link > The Promote Candidate Changes dialog box appears > check the files you want and click Promote.
I can't say I have ever noticed nor expected TFS to automatically pick up files or folders added to a mapped directory as pending changes.
I always just add them manually using the 'Add existing items' option from the source control view.
It may actually do (or at least be meant to do) the auto-detection, but I can't say I've ever relied on it. I don't think it's something to fret too much about - adding them manually is easy enough, and the 'Add existing items' option is usually smart enough to show you which files are not already under source control, so even if you need to add even more files later, it shouldn't be too much extra effort.
My home Perforce server died. I set up a new one.
The project I set it up to support died in the planning phase. The contents of the depot at that point were some prototype code and we never got to setting up a disaster recovery plan.
The dev machines still have the existing code on them. As much as possible, I'd like the change of servers to be transparent to the developers--use the same depositories and the same directories, just change the name of the server to connect to and get back to work.
What do I need to do in order to make this happen?
I assume you don't have access to the perforce depot files from your dead server? I assume you know that you will lose all your history.
If that's the case all you need to do is setup the new server, create a user / client with the same root clientspec path as your original clientspec was using on your dev machine and checkin all the files into perforce. Pretty simple really...
You may need to rebind is SCM binding that you may have in tools like Visual Studio but that's about it.
What Shane suggested will populate the depot with one person's version of the files. But if you have another user who also has a copy then you'll need a couple of extra steps.
Firstly, just set one machine up as suggested by Shane.
You now need to get the second user set up. If you are confident that the version of the code user 2 has exactly matches what you put in the new server, then just create a client spec (probably same name as used before), and then sync using the "Force" flag. This will overwrite all the files on user 2's machine, and - more importantly - ensure Perforce knows which versions you really have.
However, if you are in any doubt as to any differences in code, then do not do the initial sync from the second user's machine. Instead, set up the client spec, then use the "Reconcile offline work" option - from P4V select the workspace, then it's a right click option. Then just walk through the subsequent dialog to sort out what you need.
Finally, if you want a very quick & dirty backup system for your server, I've posted some notes on my blog here - should take you just a couple of minutes to set up.