От ClearCase до Mercurial, а теперь и до Subversion.Я должен беспокоиться?

Question

Когда я начал свою текущую работу, я провел год в аду ClearCase.Зимой все было как Мордор, только без смеха.Тогда мы начали использовать Mercurial.Примерно через полтора дня облака ушли, засияло солнце, начали петь птицы - или это были ангелы?Я спросил, был ли это рай, и Кевин Костнер сказал: «Нет, это Айова Mercurial».

Теперь я переезжаю в компанию, которая использует Subversion.Должен ли я бояться?Я слышал хорошие вещи о Subversion, что он лучше, чем Vault (который я ненавидел) и намного лучше, чем ClearCase.Я читал многие обсуждения здесь, посвященные SO, но я продолжаю возвращаться к неявному заявлению Джоэла Спольски, что, если я использую Subversion , у меня будет повреждение мозга .Я подготовлен к небольшому повреждению головного мозга, но есть ли у кого-нибудь совет, как минимизировать шок и потерю серого вещества?

Answer 1

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

ты будешь в порядке на SVN. Вы будете скучать по hg, но сможете выполнить свою работу с минимальными усилиями. Если нет - вините парней, управляющих шоу, а не инструмент.

Некоторые администраторы svn используют ловушку для предотвращения коммитов от клиентов, которые не поддерживают свойство svn: mergeinfo, в этих реализациях коннекторы git и hg не будут работать. Не то, чтобы mergeinfo была настолько полезной ... она совершенно бесполезна, если вы не можете рассчитывать на ее присутствие.

Answer 2

Движение назад приведет к тому, что Subversion покажется несколько примитивным, но, как правило, он прост в использовании и надежен, если не так функционален. Я думаю, что самая большая разница между переходом с современной DVCS, такой как Mercurial на Subversion («CVS сделано« правильно »»), заключается в том, что Subversion использует файловую систему в качестве аналогии для всего:

• В Subversion вы «разветвляетесь», буквально копируя все файлы из вашего «транкового» каталога в новый каталог в «ветках».
• Аналогично, чтобы «пометить» ревизию, вы буквально копируете все файлы из «ствола» в каталог «теги».

Эти операции не являются на самом деле тегами или ветвями, но каталоги "тегов" и "ветвей" названы так по соглашению.

Вы также должны быть более осторожны, потому что фиксация любых изменений подтолкнет его к главному репо, чтобы все могли его увидеть. Случайный коммит может сломать «хобот» для всех, что приведет к несчастным ситуациям.

Кроме того, будьте готовы к медленным операциям, когда вам нужно делать все по сети.

Answer 3

Попробуйте hgsubversion в качестве клиента, который, по крайней мере, позволит вам делать свои собственные экспериментальные ветки, локальные коммиты, полки и пару других приятных функций Hg.

Иногда у меня возникали трудности с импортом больших репозиториев, однако в этом случае я переключаюсь на hgsvn и использую «hg-importsvn --local-only» в рабочей копии Subversion. Требуется клиент SVN. Я рекомендую Slik SVN .

Оба инструмента позволяют вам вернуться к репозиторию svn, но они различаются по тому, как они работают.

Должен признать, я чаще использую hgsvn, хотя мне больше нравится концепция hgsubversion. Процесс импорта еще недостаточно надежен.

Answer 4

После многих лет работы с Subversion, а теперь и с Mercurial основным отличием для меня является ветвление. Я бы не хотел возвращаться в Subversion, я бы скучал по нему.

Но в конце концов вы можете использовать Mercurial на своем локальном диске (даже в каталоге, который является извлечением из хранилища Subversion), возможно, в ближайшем будущем вы сможете убедить нужного человека, и тогда солнце снова засияет ...

Answer 5

Существует разногласие между миром распределенного контроля версий (DSVC) (git / mercurial / et al) и CSVC (централизованным ...) относительно того, что лучше.

Некоторым нравитсяDSVC-метод часто регистрируется локально, но только когда-либо помещает «работающий» код в центральный / главный репозиторий.

Некоторые, такие как метод CSVC всех коммитов, сразу видны всем, но код в центральном репозиторииможет не всегда работать.

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

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

Answer 6

Есть разъем svn-hg.

Я использую Clearcase в моей нынешней компании и храню свои мелкие коммиты в репозитории hg.