I'm working in Visual Studios 2010 and Ankhsvn.
I need to exclude a few of my files from being Committed (which I did through ignore-on-commit in the Change log.)
How do I exclude the files from being changed when I update?
I've tried adding the svn:ignore property, but I keep getting errors thrown. Maybe I'm using it wrong... It shouldn't be this hard to completely exclude files.
svn:ignore is a property on a directory that you set to specify that the given resources shouldn't be in version control - which doesn't sound like what you want. If the file is already under version control, SVN will always try to process it. The effect you're after (restricting svn operations to a given subset of files) can be achieved using the --changelist option. You can use svn changelist to create lists of files, then suboptions to add and remove files from that list, then you can pass that changelist to svn up to limit which files get processed.
I could use some advice.
I'm in the process of adopting subversion, and I'm trying to put some existing Visual Studio 2010 projects into a repository. I have the current version of AhnkSvn.
The projects I have are organised as;
VS2010_projects\Project_A
VS2010_projects\Project_B
VS2010_projects\Project_C
VS2010_projects\Common_code
Where Project_A, Project_B and Project_C may all refer to one or more files in "Common_Code"
In visual studio, these files will have been added using "add as link".
There is no actual project in "Common_code" just a collection of useful code files, which we're likely to re-use in different projects.
(If we have a module or class which is re-used in various projects, then we often keep a single master copy in 'common-code', and link to it.)
Visual Studio has no problem with this.
When I add any of the actual projects to subversion, all of their own files are added just fine, but the linked files are ignored.
(And as a consequence, if I then get a working copy of those files, then it's just the project files which get handled, I won't get a copy of the linked files.)
If I right click on any of the linked files, I the only subversion options I get are to refresh their status or to select the working folder.
I was wondering what the correct way to handle this situation was ?
Any advice would be much appreciated
Thanks !
Robert
if I understand your question correctly then I think SVN is acting in the desired way. A linked file is merely a reference to another file. That reference exists only in the .csproj file which is checked in. It would not make sense to have two copies of the same file in source control, and it could lead to versioning issues. The first time you checkout your repository doing a build on your projects should copy the files from Common_code to the places that they're linked.
As an aside we've had alot of random issues with .csproj linked files and SVN, and so try to avoid linked files where possible. A better way to re-use files across projects is obviously just to embed them in a library and then reference that library. This should work fine with the exception of certain files like Javascript/CSS.
Also you may want to check out SVN externals, a workmate mentioned this can be used to share common libraries between multiple projects, although as a disclaimer I haven't tried this myself and can't comment on the merits or drawbacks of the approach.
Thanks for the advice, I actually did something similar to your suggestion.
I didn't want to make a full blown library, but I did make up a dummy project, and put my shared files into that.
Then I added the dummy project to the repository.
AhnkSvn now seems to be satisfied that the linked files are under subversion control, and seems to handle them just fine.
(I haven't added any reference to the dummy project to my existing projects - they just use the linked files as before - but now AhnkSvn shows me their status, and allows me to get the latest version, and commit changes.)
I can see the case for having a proper library - but that would have meant modifying a large body of existing projects. This approach lets me get up and running with Subversion without requiring those changes first.
If I add a new file to a project under TFS source control, it will check out the project file and the corresponding .vspscc file for that project file.
The project file itself changes (to include the new file), but the .vspscc file doesn't change at all. Why bother checking it out? Is there a way to disable it from being checked out and if there is, should I?
It gets checked out because under certain conditions it will be modified..and thus they checked it out as a matter of default. I wouldn't worry about it..it's not hurting anything, and if you disable it, it might bite you badly in the future in a bizarre way.
According to this post of Ben Ryan:
Team Foundation uses these to store lists of files that have been excluded from source control. We leveraged some of the existing SCC integration layer in Visual Studio to integrate Team Foundation, and these files were one of the carryovers. I'll have to check into what the logic was in breaking out these SCC settings into separate files as opposed to putting them in the solution and project files' SCC sections.
This file is a holdover from past VSS/TFS implementations, like Paulo Santos posted.
On the solution level, I have found no functional use for these files. In 10 years of using TFS, I have never seen that file altered. You can delete these .VSSCC files, as I commonly do for my closed source solutions.
But if you delete the solution-level .vsscc file, you will get a non-destructive error message on the first time open of the solution file...only after a new branch is created. All subsequent solution opening will not show the error message again.
My TFS setup standards have the solution file alone in the root folder, all projects are under sub-folders. Since those .vsscc files double the number of files in my root, I always delete them.
On a project level, I leave those files, as my team never opens project files directly, only solution .SLN files.
For my team, I prefer programmer ease of opening solutions over that one-time error message.
I use subversion with TortoiseSVN on projects at work and my personal ones.
I was wondering what is considered best practice in terms of being able to setup your repo so that doing a SVN Checkout and VisualSVN for Visual Studio will get you all that you need to compile
...
but I want to be able to mark certain files so that they will not be recommended for any SVN Commits. Ideally the file would no longer even be marked as changed (I'm anal like that).
The classic example of this would be an app.config that will have different connect strings for each developer machines.
Seth
The usual approach is to create a template file and commit that, then add the configuration file to svn:ignore. You could even go a step further and add a pre-compile step in Visual Studio that checks for the configuration file and, if not present, creates it from the template. Depending on the values to be set in the configuration this might or might not be a good idea.
I usually commit a web.config.template and let the other developers copy this to web.config and do any changes they want. They can then select both their web.config and the web.config.template file and, using Tortoise (or any other similar functionality) show differences between the two files. This would show their local changes, and also any changes done to the template.
Use a local svn:ignore
http://sdesmedt.wordpress.com/2006/12/10/how-to-make-subversion-ignore-files-and-folders/
What about having a app.config.example shared in the repository and svn:ignore the files you want to keep for yourself ?
If you're using Visual Studio, most (but not all) project systems support the "Exclude From Source Control" action. You won't find it on the context menu unfortunately. Have to select the file(s) in Solution Explorer, then File -> Source Control -> Exclude. From then on, the project/solution will not make any requests to the active source control provider upon editing/saving/etc (depending on your Tools -> Options -> SCC -> Environment settings).
Naturally this won't work if you leave VS and accidentally checkout/checkin the excluded file from Tortoise.
Visual Studio solutions contain two types of hidden user files. One is the solution .suo file which is a binary file. The other is the project .user file which is a text file. Exactly what data do these files contain?
I've also been wondering whether I should add these files to source control (Subversion in my case). If I don't add these files and another developer checks out the solution, will Visual Studio automatically create new user files?
These files contain user preference configurations that are in general specific to your machine, so it's better not to put it in SCM. Also, VS will change it almost every time you execute it, so it will always be marked by the SCM as 'changed'.
I don't include either, I'm in a project using VS for 2 years and had no problems doing that. The only minor annoyance is that the debug parameters (execution path, deployment target, etc.) are stored in one of those files (don't know which), so if you have a standard for them you won't be able to 'publish' it via SCM for other developers to have the entire development environment 'ready to use'.
You don't need to add these -- they contain per-user settings, and other developers won't want your copy.
Others have explained why having the *.suo and *.user files under source control is not a good idea.
I'd like to suggest that you add these patterns to the svn:ignore property for 2 reasons:
So other developers won't wind up
with one developer's settings.
So when you view status, or commit
files, those files won't clutter the code base and obscure new files you need to add.
We don't commit the binary file (*.suo), but we commit the .user file. The .user file contains for example the start options for debugging the project. You can find the start options in the properties of the project in the tab "Debug". We used NUnit in some projects and configured the nunit-gui.exe as the start option for the project. Without the .user file, each team member would have to configure it separately.
Hope this helps.
Since I found this question/answer through Google in 2011, I thought I'd take a second and add the link for the *.SDF files created by Visual Studio 2010 to the list of files that probably should not be added to version control (the IDE will re-create them). Since I wasn't sure that a *.sdf file may have a legitimate use elsewhere, I only ignored the specific [projectname].sdf file from SVN.
Why does the Visual Studio conversion wizard 2010 create a massive SDF database file?
No, you should not add them to source control since - as you said - they're user specific.
SUO (Solution User Options): Records
all of the options that you might
associate with your solution so that
each time you open it, it includes
customizations that you
have made.
The .user file contains the user options for the project (while SUO is for the solution) and extends the project file name (e.g. anything.csproj.user contains user settings for the anything.csproj project).
This appears to be Microsoft's opinion on the matter:
Adding (and editing) .suo files to source control
I don't know why your project stores the DebuggingWorkingDirectory in
the suo file. If that is a user specific setting you should consider
storing that in the *.proj.user filename. If that setting is shareable
between all users working on the project you should consider storing
it in the project file itself.
Don't even think of adding the suo file to source control! The SUO
(soluton user options) file is meant to contain user-specific
settings, and should not be shared amongst users working on the same
solution. If you'd be adding the suo file in the scc database I don't
know what other things in the IDE you'd break, but from source control
point of view you will break web projects scc integration, the Lan vs
Internet plugin used by different users for VSS access, and you could
even cause the scc to break completely (VSS database path stored in
suo file that may be valid for you may not be valid for another user).
Alin Constantin (MSFT)
By default Microsoft's Visual SourceSafe does not include these files in the source control because they are user-specific settings files. I would follow that model if you're using SVN as source control.
Visual Studio will automatically create them. I don't recommend putting them in source control. There have been numerous times where a local developer's SOU file was causing VS to behave erratically on that developers box. Deleting the file and then letting VS recreate it always fixed the issues.
No.
I just wanted a real short answer, and there wasn't any.
On the MSDN website, it clearly states that
The solution user options (.suo) file contains per-user solution
options. This file should not be checked in to source code control.
So I'd say it is pretty safe to ignore these files while checking in stuff to your source control.
I wouldn't. Anything that could change per "user" is usually not good in source control. .suo, .user, obj/bin directories
These files are user-specific options, which should be independent of the solution itself. Visual Studio will create new ones as necessary, so they do not need to be checked in to source control. Indeed, it would probably be better not to as this allows individual developers to customize their environment as they see fit.
You cannot source-control the .user files, because that's user specific. It contains the name of remote machine and other user-dependent things. It's a vcproj related file.
The .suo file is a sln related file and it contains the "solution user options" (startup project(s), windows position (what's docked and where, what's floating), etc.)
It's a binary file, and I don't know if it contains something "user related".
In our company we do not take those files under source control.
They contain the specific settings about the project that are typically assigned to a single developer (like, for example, the starting project and starting page to start when you debug your application).
So it's better not adding them to version control, leaving VS recreate them so that each developer can have the specific settings they want.
.user is the user settings, and I think .suo is the solution user options. You don't want these files under source control; they will be re-created for each user.
Others have explained that no, you don't want this in version control. You should configure your version control system to ignore the file (e.g. via a .gitignore file).
To really understand why, it helps to see what's actually in this file. I wrote a command line tool that lets you see the .suo file's contents.
Install it on your machine via:
dotnet tool install -g suo
It has two sub-commands, keys and view.
suo keys <path-to-suo-file>
This will dump out the key for each value in the file. For example (abridged):
nuget
ProjInfoEx
BookmarkState
DebuggerWatches
HiddenSlnFolders
ObjMgrContentsV8
UnloadedProjects
ClassViewContents
OutliningStateDir
ProjExplorerState
TaskListShortcuts
XmlPackageOptions
BackgroundLoadData
DebuggerExceptions
DebuggerFindSource
DebuggerFindSymbol
ILSpy-234190A6EE66
MRU Solution Files
UnloadedProjectsEx
ApplicationInsights
DebuggerBreakpoints
OutliningStateV1674
...
As you can see, lots of IDE features use this file to store their state.
Use the view command to see a given key's value. For example:
$ suo view nuget --format=utf8 .suo
nuget
?{"WindowSettings":{"project:MyProject":{"SourceRepository":"nuget.org","ShowPreviewWindow":false,"ShowDeprecatedFrameworkWindow":true,"RemoveDependencies":false,"ForceRemove":false,"IncludePrerelease":false,"SelectedFilter":"UpdatesAvailable","DependencyBehavior":"Lowest","FileConflictAction":"PromptUser","OptionsExpanded":false,"SortPropertyName":"ProjectName","SortDirection":"Ascending"}}}
More information on the tool here: https://github.com/drewnoakes/suo
Using Rational ClearCase the answer is no. Only the .sln & .*proj should be registered in source code control.
I can't answer for other vendors. If I recall correctly, these files are "user" specific options, your environment.
Don't add any of those files into version control. These files are auto generated with work station specific information, if checked-in to version control that will cause trouble in other work stations.
No, they shouldn't be committed to source control as they are developer/machine-specific local settings.
GitHub maintain a list of suggested file types for Visual Studio users to ignore at https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
For svn, I have the following global-ignore property set:
*.DotSettings.User
*.onetoc2
*.suo .vs PrecompiledWeb thumbs.db obj bin debug
*.user *.vshost.*
*.tss
*.dbml.layout
As explained in other answers, both .suo and .user shouldn't be added to source control, since they are user/machine-specific (BTW .suo for newest versions of VS was moved into dedicated temporary directory .vs, which should be kept out of source control completely).
However if your application requires some setup of environment for debugging in VS (such settings are usually kept in .user file), it may be handy to prepare a sample file (naming it like .user.SAMPLE) and add it to source control for references.
Instead of hard-coded absolute path in such file, it makes sense to use relative ones or rely on environment variables, so the sample may be generic enough to be easily re-usable by others.
If you set your executable dir dependencies in ProjectProperties>Debugging>Environment, the paths are stored in '.user' files.
Suppose I set this string in above-mentioned field: "PATH=C:\xyz\bin"
This is how it will get stored in '.user' file:
<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>
This helped us a lot while working in OpenCV. We could use different versions of OpenCV for different projects. Another advantage is, it was very easy to set up our projects on a new machine. We just had to copy corresponding dependency dirs. So for some projects, I prefer to add the '.user' to source control.
Even though, it is entirely dependent on projects. You can take a call based on your needs.