TFS 2008, remove file from source control but leave it in the project?

By adding a new file to solution explorer, you will get the little plus sign indicating it is due to be added to source control. Then, right-click and choose "undo pending changes". This will cancel the add but leave the file in your project.

By adding a new file to solution explorer, you will get the little plus sign indicating it is due to be added to source control. Then, right-click and choose "undo pending changes". This will cancel the add but leave the file in your project.

If that doesn't work I suggest one of the following methods: Use the Attrib task from the MSBuild Community Tasks project to remove the read only flag. Use the Exec task in MSBuild to invoke tf. Exe and checkout the file.

So, I need to delete the file, check it in, add a new web. Config, and then undo? – Josh Sep 4 '09 at 14:56 Yeah, I would suggest deleting the file from source control first.

– apathetic Sep 4 '09 at 14:59 Don't do this. It defeats the whole point. – Richard Berg Sep 4 '09 at 20:05 1 Actually, it's irrelevant whether the file is in source control because a script is being run to create the file.

The files that are being put in place by the script will still be fully versioned. – apathetic Sep 4 '09 at 13:43.

You should leave the file in source control. Otherwise you'll run into several issues: changes won't be versioned. 'nuf said.It can't be branched or merged, even though web.

Config is one of the files that's most likely to vary between parallel dev/test/production environments changes you make locally won't propagate to coworkers without manual workarounds developers setting up an environment for the first time won't get the file at all Team Builds won't contain the file, so neither will your deployments. (surely you're not deploying directly from the desktop?! ) Note that the state of individual files is stored entirely on the TFS server.

('tf properties' dumps this metadata if you're curious) Only projects & solutions have bindings actually written into the file. And even those are dummy entries that tell VS "don't worry about me, just ask TFSProvider, it'll know who I am and where I'm supposed to be. " While there are many other quirks in the VS project system that give me endless headaches, in this case it's your friend.

Don't circumvent it. Best options: Edit your build script to toggle the read-only attribute before/after modification. If you're using the "copyifnewer.

Bat" script from the linked blog post, it should literally be one extra line. Even if you want to keep things entirely declarative within the MSBuild makefile, it's barely any work with the help of 3rd party tasks. Use the File -> Source Control -> Exclude feature.

After applying this setting, the file remains under source control, but will no longer be subject to automatic checkouts/checkins by the active solution.In other words, you can edit the file locally to your heart's content without affecting anyone else, but if you want to commit (or shelve) your changes you'll need to do it from Source Control Explorer or the command line. Option #1 has the advantage of being a very quick fix for your existing setup. The downside comes from maintaining several copies of web.config.

* Same reason why copy/pasting code is bad: if you change one, you have to go change all the others -- or worse, forget and let them drift out of sync until strange bugs force you to revisit the issue. This could be improved by changing the process so that there's only 1 "master" web. Config and the additional copies only contain differences (via a textual diff engine, XSLT transforms, programmatic manipulation in Powershell, etc).

Of course, that's more work. Option #2 avoids #1's problems with very little overhead. (the engineering process itself is unchanged; only difference is how the Visual Studio UI behaves) This advantage is critical if you make changes to web.

Config at all frequently. Downside is that there is no built-in way to track variations on the "master" file. If the only diffs are dirt simple, eg a connection string or two, you may find it easiest to stick with just one "master" and let people make ad hoc changes on their dev machines.

There are even tools to do this for you, such as Web Deployment Projects (easy) and the IIS Deployment Tool (complex). In any case your actual deployment should be automated and source-controlled, of course! If heavier customizations are required than these tools are capable of, then you'll probably want the hybrid master + transform approach described earlier.

1 I understand your point, Richard, but the web. Config is merely a copy of 1 of 4 other files in the project, which are already under source control. The file is simply swapped out per environment depending on the build configuration.

Having it in TFS is unnecessary because it's just a copy of what is already protected with version control, and a headache. Thanks for your input though! – Josh Sep 14 '09 at 20:59 No prob.

I'd check out option #2 anyway -- it's one of those little known VS features that once you know it, you'll find invaluable -- even if not for web. Config specifically. – Richard Berg Sep 16 '09 at 1:54 Exclude doesn't work, because when I publish, the web.

Config isn't pushed. It has to be part of the project, but not in source control so I can overwrite it. – Josh Nov 10 '09 at 16:53 He's excluding it from source control, not from the project.

File -> Source Control -> Exclude. This will then put a Minus symbol next to the file, stating that it is no longer under source control, but it's still apart of the project. I have a bunch of JS files that I compress to a -min file in the project, and this is the only way to get it to work without checking out the min files all the time.

And since the build scripts and primary files are in source, anyone should be able to build. And get the min files. – Mike Nov 8 '10 at 15:41 Oh and if you didn't have them checked out prior to excluding, then you'll need to uncheck readonly on the files themselves.

– Mike Nov 8 '10 at 15:42.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.