Is it possible to automatically synchronise settings between computers, especially LiveTemplates?
Basically, I would like that if I add a LiveTemplate on a computer, it would be automatically added to all the other development team machines. Currently, the only option I managed was to export the settings to a file (.DotSettings), and then re-import them on another machine. However, this is very tedious if you have computers.
Explicitly move all your settings to solution layer. This would create ".DotSettings" file near your "*.sln" file.
Check this ".DotSettings" file into source control.
After that, use "Save to" to save your settings changes to this layer (and select this layer in Live Templates Explorer).
Now every change to settings now automatically propagates to all of your team computers via source control. Read more about this at http://blogs.jetbrains.com/dotnet/tag/resharper-settings/
Related
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 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.
We have bought Team Viewer corporate, and need to deploy to our infrastructure, it includes Windows XP SP3, and Windows 7, our domain controller is Windows 2003 SP2, the setting of Team Viewer was exported to .reg file including the passwords and whitelists, I used the .vbs that Team Viewer provided to merge the registry values we exported earlier.
At a testing environment that matches the real environment, the deployment itself runs perfectly using GPO, but the script doesn’t run, if I tried to run the script manually by double clicking the .vbs file, I get “open file security warning” dialogue box, so I disabled it at the attachment manager by adding .vbs to the low risk list and everything worked fine, but the management refused this solution since it will endanger the network by marking all .vbs files as safe, and because it uses “user configuration” rather than using “computer configuration” at GPO, why does this matter? Because users are mobile throughout the regions where we operate, and when a user logs in using their credentials they will trigger the script and the deployment which will affect the network bandwidth.
My question, is there any way to deploy Team Viewer and merge the registry file through .vbs using “computer configuration” at active directory GPO?
Here's an interesting article that suggests using .adm files (instead of .vbs scripts) to propagate a registry change to your users, using Group Policy:
http://blogs.technet.com/b/askds/archive/2007/08/14/deploying-custom-registry-changes-through-group-policy.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.