Лучшие практики для проектов Подверсии и Visual Studio
Когда я решил, что должен использовать систему управления версиями кода, я навел справки о любых хороших учебных руководствах о том, как начать, но не нашел никого, который мог помочь мне.
, Таким образом, я просто установил Сервер SVN и Черепаху SVN для клиента и погрузился в углубленный и меня learn't, как использовать его по пути.
7 ответов
You can add the following files to Visual Studio source control:
- Solution files (
*.sln).- Project files, for example,
*.csproj,*.vbprojfiles.- Application configuration files, based on XML, used to control run-time behavior of a Visual Studio project.
Files that you cannot add to source control include the following:
- Solution user option files (
*.suo).- Project user option files, for example,
*.csproj.user,*.vbproj.userfiles.- Web information files, for example,
*.csproj.webinfo,*.vbproj.webinfo, that control the virtual root location of a Web project.- Build output files, for example,
*.dlland*.exefiles.
I would suggest using AnkhSVN - a Subversion source control plugin for Visual Studio 2008/2010.
You can use it to perform your initial add and commit of the solution, projects and sources to the repository and it won't add any of the build artefacts. It won't add anything that is generated by your build, only files that are referenced by your solution. If there are any other bits and pieces you need that aren't in your solution, you can add them afterwards.
Put the following files in version control:
- .dsw (VS6 workspace)
- .dsp (VS6 project)
- .sln (VS Solution)
- .*proj (VS Project files of various types)
- of course your source files and other artifacts you create
Do not put the following files into version control:
- .ncb (something to do with browsing or intellsense)
- .suo (user workspace settings like window placement, etc - I think)
- .user (user project settings like breakpoints, etc - I think)
Also, don't put in any object files, executables, auto-generated files (like headers that might be generated).
As for executables and other generated files - there might be an exception if you want to be able to archive releases. That might be a good idea, but you'll probably want to manage that a little differently and possibly in a different place than your source code. If you do this, also archive your .pdb files so you can debug the stuff later. you might want to use a Symbol Server to store you archived symbols (see Debugging Tools for Windows for the symbol server and its documentation).
Here's my list of VS-specific files that I exclude from SVN:
Ankh.Load
*.projdata
*.pdb
*.positions
*proj.user
*proj.*.user
*.ncb
*.suo
*.plg
*.opt
*.ilk
*.pch
*.idb
*.clw
*.aps
Уровень решения:
- ] добавить файл решения
.sln - игнорировать файл параметров пользователя решения
.suo
Уровень проекта:
- добавить
.csproj,.vbproj(и c ++ proj?) Файлы - игнорируют
.csproj.user,.vbproj.
I would manually include all files that I think I shouldn't version control.
My global ignore pattern is:
.dll .pdb .exe .cache .webinfo .snk bin obj debug _Resharper .user resharper
Если вы используете список игнорирования, SVN чувствителен к регистру. Поэтому не забывайте игнорировать папки bin и Bin по отдельности.
Также у меня возник вопрос ... почему для обновления значка статуса иногда требуется много времени? Иногда это очень сбивает с толку.
См. Mercurial .hgignore для проектов Visual Studio 2008 для получения списка игнорирования Mercurial. Я не знаком с синтаксисом списка игнорирования SVN, но в этом потоке есть несколько хороших списков того, что следует игнорировать в Visual Studio.