Какое расположение по умолчанию для проектов в Visual Studio? - PullRequest
0 голосов
/ 24 мая 2009

В течение многих лет я колебался между тем, чтобы мои папки проектов / исходных файлов находились в каталоге, удаленном на один уровень от корня (например, D: \ Projects), и держал их в расположении по умолчанию для Visual Studio.

Раньше я отказывался хранить что-либо в различных папках «Мои документы», установленных в Win 95, Win 98 и XP. Наконец, я перешел на хранение их в папке «Документы», так как Vista сократила путь, и мне надоело менять каталоги по умолчанию для моих инструментов разработки. Однако теперь я снова склоняюсь к созданию папки без прав доступа, поскольку настраиваю новую машину.

Я устала от длинных путей, по которым нужно переходить, когда вещи хранятся в папках документов. Кроме того, я не делаю резервную копию исходного кода и файлов базы данных, как я делаю с другими моими документами, так как я использую VCS для исходного кода. Однако кажется, что вы всегда боретесь за поддержание «нестандартного» исходного местоположения, так как каждый инструмент разработки обычно хочет хранить вещи в подпапке документов.

Я хотел бы услышать мнения других по этому вопросу.

Ответы [ 9 ]

2 голосов
/ 24 мая 2009

Я предпочел местоположение в другом разделе. Поскольку в проектах много и много мелких файлов, и если вы используете SVN или другую систему контроля версий, эти файлы имеют очень высокую степень фрагментации и замедляют работу системы, если они хранятся в разделе ОС.

2 голосов
/ 24 мая 2009

Я думаю, это зависит от вашего использования ... Я предпочитаю, чтобы мои проекты разработки располагались на отдельном диске / разделе, поэтому обычно используется следующее соглашение D:\projects\{company-name}\({client-name}|internal)\{project-name} Когда имя клиента вступает в игру, когда работа одной компанией, но другой. Я держу свои проекты под D:\projects\personal\... Это позволяет улучшить структуру.

Что касается стратегий резервного копирования, imho - это то, для чего нужен контроль версий. Я предпочитаю Subversion, и у меня есть стратегия резервного копирования для сервера SVN. Хотя я не очень заботился о ankh 1.x, версия 2.x вместе с TortoiseSVN работали для меня довольно хорошо. На практике я часто проверяю и пытаюсь проверять код только в работоспособном состоянии (хотя новые функции / код могут не работать).

2 голосов
/ 24 мая 2009

В явном нарушении прошлого Unix я использую c: \ dev (для разработки) или любой другой диск, который использую для разработки. Примечание. Рекомендуется НЕ использовать системный раздел для разработки, так как разработка программного обеспечения действительно фрагментирует диск.

У меня никогда не было причин использовать другой каталог - за исключением некоторых проектов, где «стандарты компании» заставляли всех иметь каталог разработки в корне диска C :. (на самом деле! У них были жестко запрограммированные пути к c: \ what)

Во время разработки я иногда проверяю несколько версий исходного кода для разных директорий - хотя бы для того, чтобы выяснить, что версия, введенная в систему управления версиями, действительно проверяет каждый файл. (Иногда я добавляю файл в каталог разработки, но не забудьте проверить его.)

Так что я думаю, что это не имеет значения, где находится ваш каталог разработки, если путь для вас типизируемый (я предпочитаю короткие пути) и не содержит пробелов по обычным причинам в Windows (если вы хотите сделать некоторые сценарии).

1 голос
/ 24 мая 2009

Я не пробовал сам, но, думаю, вы можете поместить свои проекты в Мои документы и использовать символическую ссылку на каталог в корневой папке. Делая это, вы можете получить доступ к своим файлам в обоих направлениях и решить такие проблемы, как смена каталога для инструментов. Информация о символических ссылках в Vista

Если вы единственный, кто использует ваш компьютер, я действительно не понимаю, почему вы должны поместить свой код в каталог профиля, в любом случае резервное копирование должно выполняться с использованием системы контроля версий.

0 голосов
/ 31 июля 2009

лучше оставить ваш проект в другом разделе, чем в окне, и я думаю, что и я d: \ projects \ "некоторая группировка проекта имеет свой собственный выбор" \ projectname

например. d: \ проекты \ UNIversty \ прием d: \ Проекты \ universry \ экспертиза d: \ проекты \ планировщиков \ IPP

0 голосов
/ 24 мая 2009

Только один вопрос, вы в первую очередь разрабатываете настольные приложения или веб-приложения?

Если вы постоянно пишете веб-приложения, вот что мне подходит:

  1. Создать папку: c: \ dev или c: \ sites (не усложняйте ее)
  2. Зарегистрировать папку как виртуальный каталог в IIS
  3. Создайте отдельную папку для каждого из ваших проектов и создайте веб-приложение в IIS для каждого из них

Одним из преимуществ этой настройки может быть то, что вам легче перемещаться по сайту в браузере, т. Е. Меньше набирать текст, легче запоминать, стандартизировать все остальные ваши приложения.

мои 2цента.

0 голосов
/ 24 мая 2009

Для личных проектов я просто помещаю их на рабочий стол (хотя я перемещаю рабочий стол в D: \ Desktop). Они архивируются в мои документы, когда они становятся неактивными.

Для работы у меня есть все проекты в папке C: \ Sourcecode внутри выделенной виртуальной машины разработки.

0 голосов
/ 24 мая 2009

Я использую SUBST (запуск при запуске), чтобы сопоставить какую-то случайную папку с жестким диском. Тогда я могу положить свои вещи куда угодно и переместить их, и все же я всегда могу сослаться на это по Y: или Q: или как угодно.

Это один из тех дополнительных уровней косвенности, которые, как говорят, решают каждую проблему.

0 голосов
/ 24 мая 2009

Я храню «активные» проекты на дополнительном диске, один уровень от корня. Гораздо проще быстро добраться до этой папки (даже если на VS2008 теперь есть эта замечательная «Открыть папку в проводнике Windows»). Это также удобно для резервного копирования, форматирования / переустановки и т. Д. «Менее активные» проекты хранятся на NAS для быстрого ознакомления. Все они также хранятся на удаленном резервном сервере SVN. (Я бы также рекомендовал не использовать # в папке для веб-приложения, поскольку это (иногда) создает странные ошибки с веб-сервера разработки)

...