VCS и единая команда разработчиков

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

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

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

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

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

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


git development-environment version-control svn bug-tracking
person salt.racer    schedule 18.02.2009    source источник

Ответы (7)


arrow_upward
1
arrow_downward

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

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

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

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

person Jim T    schedule 18.02.2009

arrow_upward
4
arrow_downward

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

person SingleNegationElimination    schedule 18.02.2009

arrow_upward
2
arrow_downward

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

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

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

person Himadri Choudhury    schedule 18.02.2009

arrow_upward
1
arrow_downward

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

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

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

Горячая копия SVN:

svnadmin hotcopy $REPOSITORY $DESTINATION

trac hotcopy:

trac-admin $REPOSITORY hotcopy $DESTINATION
person BenB    schedule 18.02.2009

arrow_upward
1
arrow_downward

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

person Keltia    schedule 18.02.2009
comment
Да, я знал лучше. :( Redmine выглядит неплохо. А учитывая, что я разрабатываю приложение Rails ... мне это тоже нравится. - person salt.racer; 18.02.2009

arrow_upward
0
arrow_downward

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

person ChrisW    schedule 18.02.2009

arrow_upward
0
arrow_downward

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

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

person runako    schedule 18.02.2009
comment
К сожалению, мое программное обеспечение разработано под NDA с ​​другой третьей стороной. Мой работодатель не поддерживает аутсорсинг службы хостинга кода (хотя я бы с удовольствием). - person salt.racer; 18.02.2009