VCS и один разработчик "команда"

Question

Я один разработчик, работающий над проектом для моей компании. Я использую Subversion и Trac (для отслеживания ошибок и связи с типами управления). У меня есть промежуточный сервер и рабочий сервер. Сегодня я проверил некоторый код и обнаружил, что мой репозиторий svn (v1.4) на базе FSFS непоправимо поврежден. Хотя это довольно обидно, это дало мне возможность переместить мою систему VCS / staging в более современный дистрибутив (в настоящее время на 2-летней системе). (Что касается репозитория, у меня есть не поврежденная текущая версия кода, поэтому, хотя я теряю всю историю и комментарии разработки, я не теряю никакого кода. Вот так.)

В настоящее время я разрабатываю на Ubuntu и производственные прогоны RHEL5-64. Мое оборудование останется прежним, 32-битная одноядерная система x86.

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

В настоящее время я думаю о создании следующего:

1. Рабочий стол Ubuntu 8.10 (а затем добавление apache2 и другие пакеты ... в прошлый раз я пытался добавить графический интерфейс серверная редакция я только о выдернул мои волосы)
2. SVN (потому что я знаком с этим и Git, кажется, немного излишне для одного человека команда)
3. Trac (потому что я знаком с этим и он работает с SVN).

Я хотел бы получить несколько предложений и мыслей относительно моей "новой" системы vcs. Есть ли причина, по которой я должен перейти на Git? Есть ли что-то «лучшее», чем Trac?

Answer 1

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

Answer 2

SVN (потому что я знаком с ним, а Git кажется немного излишним для команды из одного человека)

git довольно легкий и простой в использовании. Синтаксис немного отличается от Subversion, но это все. Я бы не сказал, что это излишне. В этом нет ничего более сложного в использовании, чем Subversion.

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

Answer 3

Вторая рекомендация для Redmine . Хотя я в основном пользователь Mercurial, git также поддерживается (как и Darcs, svn и cvs). Одна из приятных особенностей распределенных систем контроля версий заключается в том, что вы в основном получаете резервные копии бесплатно (вы знаете, что вы должны были делать резервные копии своего старого репозитория SVN, верно?) ...

Answer 4

Git - прекрасная система контроля версий, особенно если вы довольны командной строкой. SVN, очевидно, старая добрая рабочая лошадка, и теперь она намного лучше с поддержкой 1,5 слияния.

Trac - это хорошо, но когда мы посмотрели на него, он был ограничен отдельными проектами и не очень хорош в отделе поддержки контроля версий.

Сейчас мы используем redmine, что позволяет использовать несколько проектов и позволяет использовать разные виды контроля версий для каждого проекта, включая git.

О да, и мы используем Хадсон для строительства :)

Answer 5

Мы используем svn / trac / ubuntu здесь.

Чтобы уменьшить влияние коррупции, я бы предложил вам внедрить автоматизированное задание (cron?) Для горячего копирования репозиториев svn и trac один раз в день и отправлять их за пределы (rsync) для резервного копирования. Мы используем NAS здесь, но что-то вроде S3 или Dreamhost тоже хорошо работает.

Таким образом, вы потеряете один день работы, если что-то пойдет не так.

Копия SVN:

svnadmin hotcopy $REPOSITORY $DESTINATION

trac hotcopy:

trac-admin $REPOSITORY hotcopy $DESTINATION

Answer 6

Я собираюсь сделать шаг назад и принять более широкий обзор. Если вы знакомы с SVN и Trac и знакомы с ними, и они выполнили работу за вас (на секунду проигнорируйте проблему коррупции), я бы поставил под сомнение необходимость переезда. Это контроль исходного кода и отслеживание ошибок, и в целом, пока они работают на вашу команду, я не вижу, чтобы тратить кучу усилий на управление своей средой, установку и оценку новых инструментов и т. Д.

Моя рекомендация в 10000 футов - использовать эту возможность, чтобы полностью рассмотреть аутсорсинг этой функции. Есть хосты (отказ от ответственности: моя компания одна), которые будут размещать ваши Subversion, Git, Trac, Lighthouse и т. Д. Для вас бесплатно / по низкой цене. Затем, когда что-то пойдет не так с дисковым массивом, FSFS или чем-то еще, кто-то, кто тратит 100% своего времени на беспокойство об этом, может справиться с этим, вероятно, даже если вы даже не осознаёте проблему. Если политика вашей компании позволяет вам использовать хост для этой функции, вы можете сэкономить выходные дни, выходные в будущем (для следующей катастрофы) и бесчисленные доллары вашего продуктивного времени.

Answer 7

Perforce - бесплатное пиво для двух пользователей и имеет хорошую репутацию .