I'm using MS Team Foundation Server 2012 with a server workspace, and the local files are on a Linux server (accessed via Samba). Accessing TFS from Visual Studio 2017.
When I check in foo.txt, TFS successfully sets foo.txt to read only as expected (r-xr--r--). But TFS does NOT set the permissions for the directory in which foo.txt is stored. Thus although I can't modify foo.txt, I still have write permissions to the directory it's in, so I can delete foo.txt or rename it or over-write it.
Is there a way I can tell TFS to manage the permissions of the directory a file is stored in (in addition to the file itself)? So that I would NOT be able to delete/rename/overwrite a file (outside of Visual Studio) without first checking it out of TFS? I'd be happy if when I checked out a file, the directory it is stored in became writeable(u+w), and when all files in the directory are checked in, the directory becomes readonly again (ugo-w).
As a side note I thought this might be a complexity of my having the files stored on a Linux box. But I tried it with a local file stored on my Win 7 PC, and got the same result. TFS will set the read-only file attribute. But even with read-only attribute set, I can still delete / overwrite / rename a file. I suppose because I'm an administrator of my PC (the security tab of the file properties shows I have full control).
So I think it's a generic TFS question. Since TFS uses the read-only attribute to prevent files from being modified outside of TFS without being checked out, is there a good way for TFS to prevent them from being deleted / overwritten / renamed outside of TFS?
Without that, I think I'm at risk of my local files accidentally becoming out of synch with the repository, and that doesn't seem like a good thing.
Just as you said local workspace is more appropriate for your situation.
And this is also available with TFS 2012.
A local workspace caches the unmodified version of each of your files to enable you to edit, compare, and do other things without being connected to the server. Just like work offline. Besides when you add or delete files outside of Visual Studio, the program automatically detects these changes.
Even though you have permission of the directory in which foo.txt is stored, such as delete foo.txt, you still can't be able to check in TFS source contol without sufficient permissions. And if you accidentally delete the file, also easy to restore locally, just get your files again.
Moreover, if you are an administrator, you can specify which type of workspace Visual Studio creates for your team members by default: Local or Server.
Take a look this excellent blog: Server workspaces vs. local workspaces which helps you clearly understand differences between the two.
Related
I have an issue with the TFS cache folder.
I have configured TFS to save cached data in a dedicated hard drive (F:\TFSCache) and I see this in the TFS Admin Console.
If I open the F:\ drive, I can see the cached data under the "proxy" folder.
All seems to work fine, but I noticed that my C:\ drive space is still used by TFS to save cached data under "C:\Program Files\Microsoft Team Foundation Server 12.0\Application Tier\Web Services_tfs_data\1e68059b-3328-4ab3-af6e-3a068be57a6d\Proxy"
If I compare the two folders in the two drive, they have almost same folders and all these folders have the "date modified" attribute updated with the latest date and time.
Why?
I want that TFS uses only the F:\ drive as specified in the console.
Thanks in advance.
First make sure you have followed To specify a different cache root folder
The last step is Delete the old cache root folder. Otherwise, TFS will still write cache to the old folder. After deletion, TFS will uses only the F:\TFSCache as specified in the console.
Moreover, please also pay attention to the
Security Note:
The cache folder stores sensitive information that is not encrypted.
Therefore, you should make sure that only the service account of the
application tier (TFSService) has Modify permissions to this
folder.
I have fixed the problem updating TFS to the latest build (TFS 2015 Update 4).
I have a file that is currently:
Present in the TFS 2013 repository;
Included in the Visual Studio 2013 project;
And as such it's obviously also present on disk;
Previously, with Mercurial, I could just:
hg forget to remove it from version control;
add that file to my ignore pattern;
And all would be well. People that do a fresh/clean clone will see that file as "missing", which was exactly the point: everyone had (needed, even) his own local version of that file.
How do I emulate this with TFS? That is, how can I make sure:
The file is not present anymore in TFS 2013 repository;
The file is still included in the Visual Studio 2013 project;
The file might be present on disk if the user had created one;
Can I accomplish this with Visual Studio 2013? Do I need to dive into the command line?
If that file is already added to TFS Version Control, you need to run tf destroy command to delete it permanently from TFS server.
And, you need to create one .tfignore file to exclude one specific file during checking in. See: https://msdn.microsoft.com/en-us/library/ms245454.aspx#tfignore
and http://blog.appliedis.com/2014/11/06/excluding-files-from-team-foundation-version-control-using-tfignore-files/
In the end what I did was this:
Copy-paste "backup" of the file;
Delete the file from the solution explorer;
Put the "backup" back in the original file's location;
Edit the csproj (e.g. in Notepad) and revert the change done by TFS during step 2;
Check in these changes;
Warning: this does remove the file for others that currently have it. The file will show as "missing" for them after getting the latest updates from TFS. They will need to manually restore the file at that location (e.g. from an old version, or freshly created).
I don't think this is the proper way to do this, probably #Vickey's answer (i.e. use TFS command line and ignore files properly) is the correct way to do it. I just haven't gotten around to trying it yet. But this answer does work.
I deleted a local copy of a TFS source-code branch (actually I renamed the branch and had to delete the old-named version), but Source Control Explorer window in Visual Studio says I still have the latest version so whenever I double-click a file, I get an error that the file doesn't exist.
Is TFS supposed to notice when I delete a local working copy i.e. this is a glitch?
How can I address it? Get the latest version and then delete it?
Is TFS supposed to notice when I delete a local working copy...?
No. TFS TFVC expects that it controls your working directories, at least with a Server Workspace. When you start doing things without telling it, then it has no idea.
If you want to remove files from your local drive, do a get of changeset 0 on that path (where the files won't be) and/or delete your working folder mapping or delete the TFS workspace.
Why does it work this way? Performance. If you have 10+ GB of sources, you can't afford to have your version control system scanning your filesystem to try to figure out what you've done. That's why TFVC Server Workspaces work this way.
Change your workspace to a Local Workspace if you have only a small bit of source code and you want to scan the filesystem for changes. Or switch to Git in TFS if you want a complete distributed experience.
I am working with a project (shared by a small team via SourceSafe source control) with four .config files in it:
App.config is the configuration file that is eventually used when the program is executed.
The other three files are essentially templates that I can quickly copy & paste into App.config.
App.Integration.config and App.Release.config are valid for all team members. For instance, it refers to integration or production database servers on the network.
App.Debug.config is a template with settings that are valid only for my machine, e.g. because it refers to my local copy of a development database.
Background: Why am I managing multiple configuration files manually? ASP.NET web projects automatically support multiple configuration files, but other project types don't. I also know that this could be automated by adding a custom MSBuild task to the project file; however, this might break or confuse later build steps, such as ClickOnce deployment.
Obviously, I do not want to check in "my" local version of App.Debug.config into SourceSafe, which is why I told Source Safe to ignore that file. For the same reason, I have SourceSafe ignore App.config, because that file is often going to be edited, e.g. when switching from the local configuration file to the integration environment's version. If everyone checked in their versions of these files, they would be seen by all other developers.
However, if I understand correctly, this leads to SourceSafe no longer keeping a copy of these files at all, so if someone checks out a fresh copy of the project, these two files will be missing.
Is there a way to have an "initial" copy of e.g. App.config in my SourceSafe repository, but at the same time prevent Visual Studio from checking out the file when it is locally edited by a developer?
Background: Why am I using SourceSafe at all? It's not my decision, and I can do nothing about it in the short term.
You can use the pin feature to keep a copy but not allow checkout.
In solution explorer, locate your file (e.g. App.config), right click on it to call menu "Show History...", select a version of your file and then click button "Pin".
I use VS 2005 and VSS 2005. Every time I close VS I get error: ss.ini not found. But except this VSS works fine, no problems when I open VS and do check in and check out. ss.ini is present and VSS repository specified as network path. I just worry that I can have problems later.
Ss.ini keeps track of your preferences, project locations, dialog settings, and such. The ss.ini needs to be in the user's folder for the data base. In my case, it is C:\DEV_\VSS\SourceSafe\users\amissico\ss.ini.
If the file exists, check permissions of folder and file. If the file doesn't exist, check permissions of folder.
Copy paste SS.ini file from user folder from another user folder into user folder with whom you are getting an issue like :
Source: Project\users\ajit\SS.ini
Destination: Project\users\Sujit\SS.ini
VSS provides Deploy command which allows you publish files to your web server. You can check the following link for more info:
http://msdn.microsoft.com/en-us/library/bb509340(v=vs.80).aspx