Здравствуйте, dr.Chaos, Вы писали:

DC>Насколько я понял, он значительно лучше работает с бранчами в силу своей идеологии, меркуриал же с бранчами работает более.
DC>не смотря на его гиковость.

т.е. поработав с ним я смогу понять выделенную фразу?.

Здравствуйте, neFormal, Вы писали:

C>>3) Более удобная работа с ветками.
F>а можно более развёрнутый ответ?. в чём выражается большее удобство?.

Здесь инересное сравнение mercurial и git. При этом как раз обуждается разница в структуре репозитория и в работе с ветками.

Моё IMHO, что работать с ветками проще начать в mercurial, но после того как освоишься, с git как-то поудобней.

Поковырялся я тут весьма плотно на прошлой неделе с сабжем (линуксоидам: под вин7, используя tortoisegit, так что не обольщайтесь). На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss). Я ошибаюсь?

Здравствуйте, kochetkov.vladimir, Вы писали:

k> Поковырялся я тут весьма плотно на прошлой неделе с сабжем (линуксоидам: под вин7, используя tortoisegit, так что не обольщайтесь). На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss). Я ошибаюсь?

Дык, эта, "отчет о приключениях" в студию!

Здравствуйте, Sinix, Вы писали:

S>возможностей чего угодно с блокировкой и атомарными коммитами хватит за глаза. SVN, повторюсь, был выбран по одной причине — мне удалось под него собрать устраивающее нас окружение.

Если хватит — о чём речь? Но, если ты здесь спрашиваешь, то, наверное, сомневаешься?

L>>С Git можно работать как с svn. Точно так же с окошком коммита, только пользы от него тогда будет как от svn.
L>>Повторю свой тезис — в svn этого не делают, потому что делать сложно, а не потому что бесполезно.
S>Повторюсь. Git вполне кошерная штука. Но до тех пор пока она будет работать как вешь в себе — толку от неё никакого.

Само собой, инструмент должен приносить пользу, а не быть фетишем. Но вот что интересно, когда я смотрю, как люди используют Х, я невольно думаю — "делать им нечего, нашли игрушку". Чтобы понять, почему люди используют инструмент, надо попробовать им попользоваться. Выяснятся некоторые тонкости (например, Git сложен в обучении, но очень прост в использовании — там просто нет ничего невозможного).

Нужно ли тебе это? Не знаю. Вот история. То ли в первых Дельфи, то ли ещё где, я уже не вспомню, был примитивный автокомплит, ужасно тормозной. Он был такой медленный, так замораживал разработку, что его приходилось отключать. Иногда время компиляции очень сильно влияет на наше желание не запускать тесты. Замедленная работа с ветками в svn вовсе не поощряет их использовать. Из-за того, что историей управлять трудно, ей никто и не управляет.

Но сейчас мы пользуемся автокомплитом, быстренько проверяем наши идеи в REPL, и пользуемся Git

S>Если не согласны — приведите плиз фичи, что перевешивают сырые ui-тулзы, лёгкие грабли с развёртыванием, отсутствие интеграции со студией и большей частью баг-трекеров. С учётом нужд мелких проектов (см выше).

Насчёт сырых UI тулзов. У меня вот в Эклипсе есть плагин Git, вроде работает он нормально и ничем не отличается от схожего плагина SVN. Есть gitk/giggle для просмотра истории (второй посимпатичнее). Правда, я пользуюсь командной строкой, но я и при работе с svn ей пользовался — быстрее получается. Что вообще имеется в виду под сырыми тулзами? Какие функции они должны выполнять?

С развёртыванием — какие грабли? Тем более для мелких проектов. Зашёл в папку проекта, git init и всё — репозиторий готов. Что необходимо сделать при развёртывании?

Со студией не знаю — я вообще не работаю ни со студией, ни вообще в Windows. Говорят, для Windows и для быстрого обучения неплох mercurial, сам не пробовал, только читал. А может быть у нас подход к разработке такой разный, что Git действительно не подойдёт? У меня Git — один из многих инструментов, а ты ищешь плагин к Студии. Я могу только рассказать о своём опыте, посмотри, подходит ли он тебе.

Баг-трекеры — я работаю с trac, redmine. Там всё в порядке. Какой используется у вас?

Мелкие проекты. Что может быть меньше индивидуальных проектов? Там у меня тоже Git.

Список фич. Из-за того, что реп — локальный, мы получаем лёгкие бранчи, поощряются частые коммиты. Реально частые — написал функцию — закоммитил. При использовании с SVN тоже стараешься так писать, но он к этому совсем не располагает. Список фич вряд ли поможет делу, лучше попробовать разные воркфлоу. Например, мёрж в Git — штатное дело, делается он легко и непринуждённо. В большинстве случаев Git сам разруливает конфликты.

Самое главное, это то, что себя не нужно ограничивать. Сколь мелким не был бы проект, часто (всегда!) возникает задача/проблема/идея, которая является прерыванием текущей работы. Как поступают в этом случае при работе с svn? В Git это вообще не проблема. На каждый чих там создаётся бранч. Коммиты летают по дереву истории как угодно, ветки перестраиваются как угодно. У тебя возникла какая то идея — ты создаёшь бранч, проверяешь там идею. У тебя возникала нужда в этом бранче использовать что-то из экспериментальной ветки — ты далешь черрипикинг или ребейз. Закончил проверку идеи/реализацию фичи/фикс бага — слил ветку, удалил её, чтобы не мусорила историю.

Я не могу привести список фич, они ничего не скажут о том, в чём именно они помогают. Вот для сравнения — почему ты используешь багтрекер, а не используешь простой туду лист? Примерно поэтому я использую Git вместо SVN.

Здравствуйте, Sinix, Вы писали:

S>Если не согласны — приведите плиз фичи, что перевешивают сырые ui-тулзы, лёгкие грабли с развёртыванием, отсутствие интеграции со студией и большей частью баг-трекеров. С учётом нужд мелких проектов (см выше).

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

Множество приёмов описано в Git Community Book.
Приятно описаны команды Git в Git for the Lazy. Читается легко и непринуждённо.
Если нужен более основательный подход, загляни сюда — в Git Magic.

Здравствуйте, neFormal, Вы писали:

F>>>давно хочется узнать, а никто не говорит..
C>>1) Он быстрый.
F>на каком объеме исходников это становится заметно?.
Десятки мегабайт.

C>>2) Есть удобнейший rebase.
F>мм.. это смена адреса репозитория?.
Нет, это редактирование истории.

C>>3) Более удобная работа с ветками.
F>а можно более развёрнутый ответ?. в чём выражается большее удобство?.
В Mercurial'е используется append-only формат, так что операции типа "удалить ветку" делаются сложно.

Здравствуйте, neFormal, Вы писали:

C>>>>2) Есть удобнейший rebase.
F>>>мм.. это смена адреса репозитория?.
C>>Нет, это редактирование истории.
F>эм.. это всмысле откаты или что?. я не понял..
Именно _редактирование_. Можно разбивать/сливать коммиты, перемешивать их местами, удалять, редактировать их.

Т.е. делаю я какую-то фичу, и коммичу изменения каждые 5 минут. С description'ами типа "change" или "bugfix".

И чтоб потом такое г. не пихать в основнойрепозиторий — делаю "git rebase -i" и сливаю все эти мусорные коммиты в один коммит с нормальным описанием.

k> Поковырялся я тут весьма плотно на прошлой неделе с сабжем (линуксоидам: под вин7, используя tortoisegit, так что не обольщайтесь). На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss). Я ошибаюсь?

В чем-то я согласен с этим товарищем (1, 2, 3 и главное).

git меня привлекает скоростью, с которой он все выполняет. но при этом любой шаг в сторону от цепочки git commit, git push, git pull для меня выглядит каким-то страшным шаманством. Я до сих пор не знаю, как приавильно откатывать последние изменения в git обычно все скатывается к танцам с бубном и git reset --hard и прочим непонятным действиям

но он, сволочь, скоростной, и github рулит

Здравствуйте, dr.Chaos, Вы писали:

DC>Может кто-то имеет опыт работы с git-ом и bazzar-ом. И мог бы всё таки пояснить кто же всё таки sucks.

С базаром не работал. Для гита есть gerrit (example 1, example 2), но это human gatekeeper, не знаю как там с автоматизацией.
А вот с виндой все плохо В принципе есть поддержка в Eclipse, платный SmartGit (no release yet) и развивающийся TortoiseGIT. Пожалуй, на этом все Я как-то привык работать под юниксом и писать в (g)vim.

Здравствуйте, neFormal, Вы писали:

C>1) Он быстрый.
F>на каком объеме исходников это становится заметно?.

Исходники 175Mb, 24 тысячи файлов, .git — 88Mb. Здесь хорошо заметно преимущество git в скорости.
Исходники 650Mb, 16 тысяч редко изменяемых файлов, .git — 150Mb. git тянет нормально. Мercurial не пробовал.
Исходники 11.5Gb, 6 тысяч файлов, .git — 7.7Gb (в основном редко изменяемые бинарные файлы). git чуть тормозит, но работать можно. Mercurial использовать не рискну

Здравствуйте, neFormal, Вы писали:

C>>Т.е. делаю я какую-то фичу, и коммичу изменения каждые 5 минут. С description'ами типа "change" или "bugfix".
C>>И чтоб потом такое г. не пихать в основнойрепозиторий — делаю "git rebase -i" и сливаю все эти мусорные коммиты в один коммит с нормальным описанием.
F>вот, добрался до mercurial-а, посмотрел как там это делается..
F>т.к. ядро довольно маленькое, то эта фича реализована расширением mq.. включаются они, правда, руками в файле hgrc..
F>само расширение предоставляет возможность "рулить" патчами: сливать, менять содержимое, менять комменты и прочее..
Немного другое. В git'е rebase мощнее, чем в hg.

Аналог MqExtension в git'е — это http://procode.org/stgit/

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss). Я ошибаюсь?

Вполне возможно, внутре оно прекрасно, но как быть с окружением?

Сам свн своими нюансами более чем задолбал. Но! Для него есть бесплатный VisualSVN Server, а в нём — визуальная консоль администрирования (примитив, но хоть что-то), есть анк, который с парой макросов может изображать из себя серьёзную среду (интеграция с багтрекером (пока полузаброшено за малым числом людей на проекте), FxCop+StyleCop перед коммитом etc).

В результате контроль версий у нас just works, без камланий на мануал и (главное) без обучения чему-либо для пользующихся. Разумеется, не без граблей — то ли VisualSVN, то ли анк дважды убивали репозитарий. Сценарий — переименование файла, его правка, затем — перемещение + что-то ещё. За редкостью бага ловить лень.

Для git — ?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Поковырялся я тут весьма плотно на прошлой неделе с сабжем (линуксоидам: под вин7, используя tortoisegit, так что не обольщайтесь). На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss).

чем он лучше mercurial-а ?.
давно хочется узнать, а никто не говорит..

KV>Я ошибаюсь?

ответа на этот вопрос имхо почти никто не знает..

Здравствуйте, andrey.desman, Вы писали:

AD>Мне действительно непонятно, что за файл такой, что его нельзя смержить?
1) [Автогенерируемые средой] Ресурсы (.rc, .h). Не то чтобы смержить было нельзя, но зачем нужен гемморой на ровном месте ?
2) [Автогенерируемые средой] Настройки проекта (.vcproj). Переколбашиваются капитально, зачастую проще заново внести изменения чем мержить. Благо изменение настроек явление редкое.
3) Объемный XML. Не знаю почему, но у диффа из SVN частенько отрывает башню, и он мержит без конфликтов, но результат — полная ерунда.
4) [В порядке гипотезы] Бинарные файлы. Например документация (.doc, .xls, .ppt, etc.). Не мержатся в принципе. Для таких проще административно заставить делать lock перед изменениями, чем разгребать результаты. Да, чур всякие SharePoint-ы и InfoPath-и не предлагать. И смену формата тоже не предлагать.

AD>Ну, например, если два человека одновременно делают в одном файле что-то такое, что git не в состоянии разрулить, то, боюсь, что-то у вас не так.
Варианты ?

Здравствуйте, Ytz, Вы писали:

C>>Именно _редактирование_. Можно разбивать/сливать коммиты, перемешивать их местами, удалять, редактировать их.
Ytz>Это что-бы вредители могли историю грохнуть?
Естественно, для разделяемого репозитория это запрещается (ставится флаг "fast-forward-only").

C>>Т.е. делаю я какую-то фичу, и коммичу изменения каждые 5 минут. С description'ами типа "change" или "bugfix".
C>>И чтоб потом такое г. не пихать в основнойрепозиторий — делаю "git rebase -i" и сливаю все эти мусорные коммиты в один коммит с нормальным описанием.
Ytz>Я в SVN для таких целей делаю branch, творю там что хочу, а потом сливаю с основной веткой. Не вариант?
Нет, так как мусорные коммиты всё равно окажутся в истории на центральном сервере.

Здравствуйте, lomeo, Вы писали:
MC>>Ну это смотря с чем интергация. У mercurial, например, есть плагин для VS, есть shell extension, есть поддержка в средствах CI (в TeamCity, например).
L>Сначала надо узнать, какая именно интеграция требуется. Я пока не понял.
Думаю, Sinix имеет в виду интеграцию с типичным окружением .net-разработчика. Поэтому стараюсь актуальные для него примеры приводить.

L>На рсдн интеграция == интеграция со студией?
В КСВ и не такое бывает В доказательство...
L>Я вот использую xmonad + rxvt + zsh + vim как инструменты разработки. Git туда отлично интегрируется
... сейчас возьму вот и спрошу, а ты историю коммитов через conky на рабочий стол выводишь?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Поковырялся я тут весьма плотно на прошлой неделе с сабжем (линуксоидам: под вин7, используя tortoisegit, так что не обольщайтесь). На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss). Я ошибаюсь?

Да нет, вроде SVN меня не впечатлил, а вот ClearCase и git вполне.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Поковырялся я тут весьма плотно на прошлой неделе с сабжем (линуксоидам: под вин7, используя tortoisegit, так что не обольщайтесь). На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss). Я ошибаюсь?

На мой взгляд тоже (работал с svn, vss, mercurial, StarTeam). Использую больше полугода msysgit. До этого эволюция шла в следующем направлении: svn => mercurial => git.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Поковырялся я тут весьма плотно на прошлой неделе с сабжем (линуксоидам: под вин7, используя tortoisegit, так что не обольщайтесь). На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss). Я ошибаюсь?

Не подскажите, как в DVCS происходит глобальная блокировка файла (монопольное владение), аналогичное команде lock в SVN.
Или какими средствами можно добиться аналогичного поведения.
Просто всегда в проекте есть 1-2 файла которые невозможно (очень сложно) смержить.

Здравствуйте, andrey.desman, Вы писали:

AD>Да нет, вроде SVN меня не впечатлил, а вот ClearCase и git вполне.

SVN не видел, VSS, imho,— детский сад, ClearCase, опять же imho, могуч, но капризен.

Здравствуйте, neFormal, Вы писали:

KV>>Поковырялся я тут весьма плотно на прошлой неделе с сабжем (линуксоидам: под вин7, используя tortoisegit, так что не обольщайтесь). На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss).
F>чем он лучше mercurial-а ?.
F>давно хочется узнать, а никто не говорит..
1) Он быстрый.
2) Есть удобнейший rebase.
3) Более удобная работа с ветками.
4) Он быстрый.

Здравствуйте, Lexxpin, Вы писали:

KV>>Поковырялся я тут весьма плотно на прошлой неделе с сабжем (линуксоидам: под вин7, используя tortoisegit, так что не обольщайтесь). На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss). Я ошибаюсь?
L>Не подскажите, как в DVCS происходит глобальная блокировка файла (монопольное владение), аналогичное команде lock в SVN.
Никак.

L>Или какими средствами можно добиться аналогичного поведения.
L>Просто всегда в проекте есть 1-2 файла которые невозможно (очень сложно) смержить.
Знакомые используют вот это: http://github.com/dustin/elock

Здравствуйте, neFormal, Вы писали:

F>чем он лучше mercurial-а ?.
F>давно хочется узнать, а никто не говорит..

Насколько я понял, он значительно лучше работает с бранчами в силу своей идеологии, меркуриал же с бранчами работает более. Да и основная идеология такая: нужен бранч — делай ещё один репозиторий. Т.е. различия в идеологии и, как следствие, в средствах решения проблем. Мне пока более симпатичен git, не смотря на его гиковость.

Здравствуйте, Cyberax, Вы писали:

F>>чем он лучше mercurial-а ?.
F>>давно хочется узнать, а никто не говорит..
C>1) Он быстрый.

на каком объеме исходников это становится заметно?.

C>2) Есть удобнейший rebase.

мм.. это смена адреса репозитория?.

C>3) Более удобная работа с ветками.

а можно более развёрнутый ответ?. в чём выражается большее удобство?.

Здравствуйте, Cyberax, Вы писали:

L>>Не подскажите, как в DVCS происходит глобальная блокировка файла (монопольное владение), аналогичное команде lock в SVN.
C>Никак.
C>Знакомые используют вот это: http://github.com/dustin/elock

ФФФФУУУУУ!!11
ещё и с костылями..

Здравствуйте, neFormal, Вы писали:

L>>>Не подскажите, как в DVCS происходит глобальная блокировка файла (монопольное владение), аналогичное команде lock в SVN.
C>>Никак.
C>>Знакомые используют вот это: http://github.com/dustin/elock
F>ФФФФУУУУУ!!11
F>ещё и с костылями..
Ну а что ты хочешь?

Здравствуйте, neFormal, Вы писали:

F>т.е. поработав с ним я смогу понять выделенную фразу?.

Ну если ты не используешь ветки, то преимуществ его тебе не понять .

Как по мне ветвление это более удобно чем постоянное клонирование репозитория. Мержится с основной веткой значительно проще за счёт git-rebase. Просто у меня и сейчас такой стиль работы правда он поддерживается с помощью скриптов поверх MKS-а.

Да и move у Меркуриала вроде не ахти реализован.

Здравствуйте, Cyberax, Вы писали:

C>>>2) Есть удобнейший rebase.
F>>мм.. это смена адреса репозитория?.
C>Нет, это редактирование истории.

эм.. это всмысле откаты или что?. я не понял..

Здравствуйте, Lexxpin, Вы писали:

L>Не подскажите, как в DVCS происходит глобальная блокировка файла (монопольное владение), аналогичное команде lock в SVN.
L>Или какими средствами можно добиться аналогичного поведения.
L>Просто всегда в проекте есть 1-2 файла которые невозможно (очень сложно) смержить.

Он потому и называется distributed, что действительно distributed.
Во-первых, у каждого своя копия репозитория, потому и запретить что-то ты не сможешь.
Во-вторых, непонятно, в чем собственно проблема, ибо по идеологии git нужды в такой блокировке просто нет.

Мне действительно непонятно, что за файл такой, что его нельзя смержить?
Ну, например, если два человека одновременно делают в одном файле что-то такое, что git не в состоянии разрулить, то, боюсь, что-то у вас не так. Ну то есть, ваши изменения по сути офигенно несовместимы между собой, и налицо самый натуральный бардак, который SVN решает самым топорным способом, запретив одному из вас что-то делать вообще.
Если подходить к git с точки зрения процесса SVN, то тут все действительно печально.
Если же придерживаться того способа, для которого git собственно и был создан, то проблем не будет.

Примерно так делаю я:

Клонировать репозиторий
1) git clone git://repoaddr
Создать локальный бранч
2) git checkout -b branch_name
Синхронизация сорцами с коллегой (совместная работа над несколькими общими файлами):
3) git pull ssh://colleagueaddr commit_id
Апмерж на новую метку
4) git remote update
git rebase master_branch
Слить все коммиты в один (ставим squash, где надо).
5) git rebase -i
Залить на один из основных серваков
6) git push git://repoaddr branch_name
7) Отправить запрос на интеграцию, пусть мержат в основную ветку

Здравствуйте, Cyberax, Вы писали:

F>>эм.. это всмысле откаты или что?. я не понял..
C>Именно _редактирование_. Можно разбивать/сливать коммиты, перемешивать их местами, удалять, редактировать их.
C>Т.е. делаю я какую-то фичу, и коммичу изменения каждые 5 минут. С description'ами типа "change" или "bugfix".
C>И чтоб потом такое г. не пихать в основнойрепозиторий — делаю "git rebase -i" и сливаю все эти мусорные коммиты в один коммит с нормальным описанием.

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

Здравствуйте, Константин, Вы писали:

C>>>3) Более удобная работа с ветками.
F>>а можно более развёрнутый ответ?. в чём выражается большее удобство?.
К>Здесь инересное сравнение mercurial и git. При этом как раз обуждается разница в структуре репозитория и в работе с ветками.

прекрасная ссылка, спасибо..

Здравствуйте, IID, Вы писали:

AD>>Мне действительно непонятно, что за файл такой, что его нельзя смержить?
IID>1) [Автогенерируемые средой] Ресурсы (.rc, .h). Не то чтобы смержить было нельзя, но зачем нужен гемморой на ровном месте ?
Не коммить автогенерируемый файлы.

IID>2) [Автогенерируемые средой] Настройки проекта (.vcproj). Переколбашиваются капитально, зачастую проще заново внести изменения чем мержить. Благо изменение настроек явление редкое.
Используй cmake

IID>3) Объемный XML. Не знаю почему, но у диффа из SVN частенько отрывает башню, и он мержит без конфликтов, но результат — полная ерунда.
Никаких проблем с 30Мб XML'ем не было (REnouveau Dump'ы, если интересно).

IID>4) [В порядке гипотезы] Бинарные файлы. Например документация (.doc, .xls, .ppt, etc.). Не мержатся в принципе. Для таких проще административно заставить делать lock перед изменениями, чем разгребать результаты. Да, чур всякие SharePoint-ы и InfoPath-и не предлагать. И смену формата тоже не предлагать.
Ну .doc ещё мерджится, .xls тоже. С остальными никак

AD>>Ну, например, если два человека одновременно делают в одном файле что-то такое, что git не в состоянии разрулить, то, боюсь, что-то у вас не так.
IID>Варианты ?
Сделать отдельный lock-сервер.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, IID, Вы писали:

AD>>>Мне действительно непонятно, что за файл такой, что его нельзя смержить?
IID>>1) [Автогенерируемые средой] Ресурсы (.rc, .h). Не то чтобы смержить было нельзя, но зачем нужен гемморой на ровном месте ?
C>Не коммить автогенерируемый файлы.
Здрасьте, приехали. Ресурсы не коммитить

IID>>2) [Автогенерируемые средой] Настройки проекта (.vcproj). Переколбашиваются капитально, зачастую проще заново внести изменения чем мержить. Благо изменение настроек явление редкое.
C>Используй cmake
Мне из студии как-то удобнее Да и настройки проекта пережить как раз проще всего. В предельном случаем можно, кстати, тупо поставить R/O доступ на эти файлы всем, кроме ответственного за эти настройки. Он же пусть и файлы в проект добавляет.

IID>>3) Объемный XML. Не знаю почему, но у диффа из SVN частенько отрывает башню, и он мержит без конфликтов, но результат — полная ерунда.
C>Никаких проблем с 30Мб XML'ем не было (REnouveau Dump'ы, если интересно).
Возможно зависит от структуры документа. В моём случае имелось много (несколько мегабайт. Не 30, но всё равно дофига) почти одинаковых по содержимому блоков, состоящих из примерно 10-уровневой вложенности тегов. Когда блоки "опускались" вниз по файлу в силу изменений, мерж начинал рассовывать "серединки" блоков последующих изменений не на причитающееся им место, а в соседей. Видимо соседи выглядели для него слишком похожими Он их начинал воспринимать тоже как изменения.

IID>>4) [В порядке гипотезы] Бинарные файлы. Например документация (.doc, .xls, .ppt, etc.). Не мержатся в принципе. Для таких проще административно заставить делать lock перед изменениями, чем разгребать результаты. Да, чур всякие SharePoint-ы и InfoPath-и не предлагать. И смену формата тоже не предлагать.
C>Ну .doc ещё мерджится, .xls тоже. С остальными никак
Во-во.

AD>>>Ну, например, если два человека одновременно делают в одном файле что-то такое, что git не в состоянии разрулить, то, боюсь, что-то у вас не так.
IID>>Варианты ?
C>Сделать отдельный lock-сервер.
С другой VCS, ага

Здравствуйте, IID, Вы писали:

IID>>>1) [Автогенерируемые средой] Ресурсы (.rc, .h). Не то чтобы смержить было нельзя, но зачем нужен гемморой на ровном месте ?
C>>Не коммить автогенерируемый файлы.
IID>Здрасьте, приехали. Ресурсы не коммитить
Хм.

C>>Используй cmake
IID>Мне из студии как-то удобнее Да и настройки проекта пережить как раз проще всего. В предельном случаем можно, кстати, тупо поставить R/O доступ на эти файлы всем, кроме ответственного за эти настройки. Он же пусть и файлы в проект добавляет.
Cmake генерирует файлы проектов для Студии, так что можно прекрасно в Студии работать продолжать. Зато намного приятнее вести конфигурацию становится.

C>>Никаких проблем с 30Мб XML'ем не было (REnouveau Dump'ы, если интересно).
IID>Возможно зависит от структуры документа. В моём случае имелось много (несколько мегабайт. Не 30, но всё равно дофига) почти одинаковых по содержимому блоков, состоящих из примерно 10-уровневой вложенности тегов. Когда блоки "опускались" вниз по файлу в силу изменений, мерж начинал рассовывать "серединки" блоков последующих изменений не на причитающееся им место, а в соседей. Видимо соседи выглядели для него слишком похожими Он их начинал воспринимать тоже как изменения.
Надо подкрутить настройки эвристик, наверное. Кстати, ещё есть mergexml — он под него специально заточен.

IID>>>Варианты ?
C>>Сделать отдельный lock-сервер.
IID>С другой VCS, ага
Нет, можно просто отдельный сервер блокировок. Распределённых

Здравствуйте, andrey.desman, Вы писали:

Лично у меня проблема с файлами edmx (Entity Framework).
Проблема в основном в том, что все хранится в одном файле и основные конфликты
вносит дизайнер. Пока отделить описание модели и дизайнерской инфы нет.
Смержить такое почти не реально, файл меняется редко, так что заблокировать его
на время можно.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Поковырялся я тут весьма плотно на прошлой неделе с сабжем (линуксоидам: под вин7, используя tortoisegit, так что не обольщайтесь). На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss). Я ошибаюсь?

Я работал с перфорсом, и он мне понравился (в отличие от глюкодрома ClearCase).
Из бесплатных, svn вне конкуренции. С git я тоже мучался. Даже освоил хождение по стандартному пути.
Но ужасы с попыткой отойти чуть вправо-влево не помещаются в моё сознание.
Преимущества в распределённости репозитория я просто не заметил. Только при необходимости вносить свои изменения в код из чужих репозиториев, чтоб не ждать, когда они поправят засабмиченные баги. Это чуть удобнее, чем в svn-е руками делать merge. Всё.
Зато вправо-влево в svn-е делается легко и понятно. Без бубнов. Описано в доке. В 90% уже умеется в виде нажатия кнопки в TortoiseSVN и т.п.

Здравствуйте, Cyberax, Вы писали:

C>Именно _редактирование_. Можно разбивать/сливать коммиты, перемешивать их местами, удалять, редактировать их.

Это что-бы вредители могли историю грохнуть?

C>Т.е. делаю я какую-то фичу, и коммичу изменения каждые 5 минут. С description'ами типа "change" или "bugfix".

C>И чтоб потом такое г. не пихать в основнойрепозиторий — делаю "git rebase -i" и сливаю все эти мусорные коммиты в один коммит с нормальным описанием.

Я в SVN для таких целей делаю branch, творю там что хочу, а потом сливаю с основной веткой. Не вариант?

Здравствуйте, andrey.desman, Вы писали:

AD>Во-первых, у каждого своя копия репозитория, потому и запретить что-то ты не сможешь.
AD>Во-вторых, непонятно, в чем собственно проблема, ибо по идеологии git нужды в такой блокировке просто нет.
...
AD>Если же придерживаться того способа, для которого git собственно и был создан, то проблем не будет.
...
AD>7) Отправить запрос на интеграцию, пусть мержат в основную ветку

То есть не решаем проблему разрешения конфликтов, а просто переносим проблему на другой уровень Кстати Линус в своем интервью сказал что-то вроде: "Какая же это проблема? Я знаю, что большинство комитеров идиоты и просто их комиты не буду смотреть"

Здравствуйте, Mamut, Вы писали:
M>но он, сволочь, скоростной, и github рулит
А чем он, собственно, рулит? Типичный бесплатный кодхостинг. Багтрекер добавили только недавно, вики с идиотской разметкой (textile, емнип) и без истории, часто лежит (ну я по крайней мере его часто в таком состоянии нахожу), нельзя пушить по хттп.

MC> M>но он, сволочь, скоростной, и github рулит

MC> А чем он, собственно, рулит? Типичный бесплатный кодхостинг. Багтрекер добавили только недавно, вики с идиотской разметкой (textile, емнип) и без истории, часто лежит (ну я по крайней мере его часто в таком состоянии нахожу), нельзя пушить по хттп.

Ну, они недавно апгрейднули сервера, так что он сейчас, вроде, редко лежит без движения.

А так — хз Но мне он нравится

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Поковырялся я тут весьма плотно на прошлой неделе с сабжем (линуксоидам: под вин7, используя tortoisegit, так что не обольщайтесь). На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss). Я ошибаюсь?

Раз пошла такая пьянка: у меня сейчас появилась возможность перевести один из проектов на новую СКВ, а потом уже по результатам такого перевода, возможно, будут серьёзные подвижки в сторону использования СКВ. Рассматривались только распределённые СКВ, т.к. офисов много причём многие в разных странах. Пока я успел более менее подробно рассмотреть git и mercurial на очереди bazaar и darcs( но его разворачивание на AIX-е задача довольно не простая, т.е. он должен обладать серьёзными преимуществами).

Что важно:
1. Поддержка нескольких веток продукта, причём ветки желательно уметь замораживать (делать Read-Only). Поскольку у разных веток много общего кода, то предпочтительней чтоб была общая история.
2. Нужен такой вот вид workflow Decentralized with automatic gatekeeper, ну или что-то на него похожее. Насколько я понял Mercurial позволяет такое делать только через ж... создание дополнительных репозиториев и перекидывание измений туда-обратно(может и не так смотрел).
3. Скорость работы.
4. Простота использования девелоперами из под винды (имеются ввиду основные use cases).

Mercurial мне не показался подходящим для нашего процесса и сейчас я пытаюсь сравнивать bazaar и git. Как я понял из беглого сравнения bazaar более тормозной и менее фичастый, но зато у него есть куча готовых решений которые вроде как нам подходят, т.е. git более гибкий и мощный, но всё же конструктор.

Может кто-то имеет опыт работы с git-ом и bazzar-ом. И мог бы всё таки пояснить кто же всё таки sucks.

Здравствуйте, andrey.desman, Вы писали:

AD>С базаром не работал.

Да я смотрю что с ним вообще мало кто работал , но многие заявляют что смотреть не на что.

AD>Для гита есть gerrit (example 1, example 2), но это human gatekeeper, не знаю как там с автоматизацией.
AD>А вот с виндой все плохо В принципе есть поддержка в Eclipse, платный SmartGit (no release yet) и развивающийся TortoiseGIT. Пожалуй, на этом все Я как-то привык работать под юниксом и писать в (g)vim.

Да я то и сейчас с MKS-ом из vim-а и консоли работаю, вопрос в том, что абсолютное большинство людей в нашей конторе работают под виндой.

Здравствуйте, Ytz, Вы писали:

AD>>7) Отправить запрос на интеграцию, пусть мержат в основную ветку
Ytz>То есть не решаем проблему разрешения конфликтов, а просто переносим проблему на другой уровень Кстати Линус в своем интервью сказал что-то вроде: "Какая же это проблема? Я знаю, что большинство комитеров идиоты и просто их комиты не буду смотреть"

Нет, не так. Проблема разрешения конфликтов разрешается еще до СКВ (не путать со свободно конвертируемой валютой ). Я опишу тот процесс, который у нас был на ClearCase. В ClearCase, в отличие от того же SVN, история не линейна. У каждого элемента (файла/директории) своё дерево веток и версий, при чем основной меткой может служить любая ветка и их может быть несколько. Собственно, для ClearCase все ветки равнозначны. И совсем нет коммитов. Определенный срез файлов (view) задается набором правил(configuration specification), где просто перечисляются файлы, их ветки и версии на этих ветках:

# My dev branches/rules
element /project_path/...        /main/product_XXX/my_branch/LATEST

# Release rules
element /project_path/Makefile   /main/product_XXX/14
element /project_path/src        /main/product_XXX/10
element /project_path/src/file.c /main/product_XXX/7
element /project_path/src/...    /main/product_XXX/LATEST

Так же любой срез можно пометить меткой для упрощения config-spec:

# My dev branches/rules
element /project_path/...        /main/product_XXX/my_branch/LATEST

# Release rules
element * PRODUCT_XXX.V1.02.BUILD_2321

Все, что выше, я написал, чтобы было понятно, что такое метка в моем случае.

Есть продукт, он очень большой и девелопится множеством команд на множестве сайтов по всему миру. Отдельные команды отвечают за один или несколько компонент.
С точки зрения configuration management есть:
1) Продуктовая метка.
2) Компонентная метка для каждого отдельного компонента.

Метки выпускаются, ну допустим, раз в неделю. Компоненты собирают все изменения от девелоперов, объединяют это в релиз компонента (метку) и фигачат этот релиз в продуктовую метку.
Продуктовая метка подсасывает в себя все последние компонентные метки и также выпускает новый продуктовый релиз (метку).
Так и живем изо дня в день

Никто, кроме нашей команды, вносить изменения в наш компонент не может. Но желающие без проблем могут присылать нам свои фиксы, какие-либо запросы на изменения, запросы на новый API и т.д., которые мы уже сами вносим.
Соотвественно компонент сам по себе тоже немаленький и за каждую подсистему отвечает один человек (pilot) с несколькими помощниками (co-pilot). Здесь проще. Любой член нашей команды в принципе может менять любые исходники по необходимости. Но на code review обязательно должен присутствовать pilot той подсистемы, куда были внесены изменения.

Итак сам процесс выглядит примерно так:
1) На меня назначают issue в багтрекере.
2) Я беру нашу последнюю метку, отращиваю свою метку и делаю багофикс.
2.1) В то же самое время мой помощник делает другой багофикс в этой же подсистеме.
2.2) В это же время другой pilot ваяет новую фичу и затрагивает часть файлов из моей подсистемы.
2.3) На всем этом промежутке мы трое постоянно общаемся и я знаю, что и как собираются делать двое моих коллег. Собственно конфликты разруливаются уже здесь.
3) Я закончил свой багофикс и приглашаю нескольких человек принять участие в code-review. Одновременно, я участвую как reviewer в инспекциях кода двух моих коллег и я знаю, что никаких аццких глобальных изменений они не делали. Если вдруг сделали, то изменения я просто не одобрю, либо мы все трое синхронизируемся как следует.
4) Инспекции закрываются, замечания (если есть таковые) исправляются.
5) Мы трое подаем запросы на интеграцию.
6) Наш CM-инженер собирает в кучу наши изменения. Если здесь возникают какие-то конфликты, то они тривиальны и CM-инженер сам их разруливает. CM-инженер так же отклоняет любые изменения, которые не были одобрены пилотом соответствующего компонента.
7) CM-инженер строит код со всеми изменениями. Все проблемы с падающими билдами решаются тут же со всеми участниками.
8) Отстроенный продукт отдается на тестирование. Если что-то поломалось, то ищется злосчастный запрос, который и выкусывается, тогда итерация повторяется.
9) Релиз оттестирован. CM-инженер завершает мерж в ветку продукта, помечает срез меткой и пуляет нашу метку в продуктовую метку.

Здравствуйте, andrey.desman, Вы писали:

AD>Итак сам процесс выглядит примерно так:
[skip]

Примеро аналогичный процесс действует в других проектах с git'ом — там за merge изменений в центральные ветки отвечает их maintainer. Другое дело, что это может создать bottleneck'и на нём.

Здравствуйте, Cyberax, Вы писали:

C>Примеро аналогичный процесс действует в других проектах с git'ом — там за merge изменений в центральные ветки отвечает их maintainer. Другое дело, что это может создать bottleneck'и на нём.
Хм. Возможно. Но я с этим не сталкивался. Вообще, maintainer проверяет и сливает изменения быстрее, чем девелоперы могут писать код, если конечно их не тысячи на одного. Если проект большой, то соответственно и людей с правом голоса/мержа должно быть больше, т.е. надо делать разбивку на подсистемы. Если бы на android был всего один maintainer, то это было бы печально

Здравствуйте, Sinix, Вы писали:

S>Вполне возможно, внутре оно прекрасно, но как быть с окружением?

Центральный реп на gitosys. Интеграция с багтрекером/нотификаторы по мылу/jabber через хуки. Всякие проверки перед коммитом (стиль, связь с issue, да хоть чтоб пробелов лишних не было) — тоже через хуки. Локально или на сервере.

S>В результате контроль версий у нас just works, без камланий на мануал и (главное) без обучения чему-либо для пользующихся.

Обучение Git-у сравнимо с обучением svn-у. IMHO.

S>Для git — ?

На работе пользуюсь git-svn, соответственно локальные правки делаю в локальных ветках, затем мёржу в мастер и лью. Если при мёрже конфликт (кто-то уже залил что посвежее) — очень просто сделать rebase. В svn этой проблемы нет только потому, что там нет и огромного преимущества — локальных веток. Что-то сделал в соседней ветке — очень лёгкий cherry-pick и изменения в другой ветке. Не нравится история — rebase и получаешь то, что надо. Интерактивный rebase для простых случаев (слить коммиты, поменять коммит, удалить коммит) — рулит. Всё, что я хочу проверить/сделать — проверяет/делает Git хуками.

Здравствуйте, mkizub, Вы писали:

M>Я работал с перфорсом, и он мне понравился (в отличие от глюкодрома ClearCase).
M>Из бесплатных, svn вне конкуренции. С git я тоже мучался. Даже освоил хождение по стандартному пути.
M>Но ужасы с попыткой отойти чуть вправо-влево не помещаются в моё сознание.

Развернёшь?

M>Преимущества в распределённости репозитория я просто не заметил.

Грубо говоря, из-за того, что реп находится локально и работа с ветками очень лёгкая — ты можешь менять историю как тебе вздумается. Из-за этого работа ведётся на совершенно ином уровне нежели в svn. Т.е. если ты с Git работал как с svn, то преимуществ не заметишь, да.

Здравствуйте, mkizub, Вы писали:

M>Преимущества в распределённости репозитория я просто не заметил. Только при необходимости вносить свои изменения в код из чужих репозиториев, чтоб не ждать, когда они поправят засабмиченные баги. Это чуть удобнее, чем в svn-е руками делать merge. Всё.
M>Зато вправо-влево в svn-е делается легко и понятно. Без бубнов. Описано в доке. В 90% уже умеется в виде нажатия кнопки в TortoiseSVN и т.п.

Попробуй Mercurial — там распределенность, но зато прекрасная документация, описывающая что когда зачем и почему, плюс названия команд аналогичны svn-овским (там, где это возможно), что облегчает использование.

DC>Да я то и сейчас с MKS-ом из vim-а и консоли работаю, вопрос в том, что абсолютное большинство людей в нашей конторе работают под виндой.

В любом случае нужно же будет реплицировать исходники в MKS(привет из Днепра )?
Как собираетесь это делать?

Здравствуйте, Константин, Вы писали:

К>Исходники 11.5Gb, 6 тысяч файлов, .git — 7.7Gb (в основном редко изменяемые бинарные файлы). git чуть тормозит, но работать можно. Mercurial использовать не рискну
Если не секрет, что это за проект такой, что в одном репозитарии 11.5Gb исходников?

Здравствуйте, Константин, Вы писали:

C>>1) Он быстрый.
F>>на каком объеме исходников это становится заметно?.

К>Исходники 175Mb, 24 тысячи файлов, .git — 88Mb. Здесь хорошо заметно преимущество git в скорости.
К>Исходники 650Mb, 16 тысяч редко изменяемых файлов, .git — 150Mb. git тянет нормально. Мercurial не пробовал.
К>Исходники 11.5Gb, 6 тысяч файлов, .git — 7.7Gb (в основном редко изменяемые бинарные файлы). git чуть тормозит, но работать можно. Mercurial использовать не рискну

Что-то не вставляет меня такое сравнение. Не очень понятен первый пункт — там все же запускался Mercurial? И насколько "хорошо заметно" превосходство git?
Пункт 2 и 3 — это это просто вырезать и повесить на рамочку как пример идеального сравнения — "Система А работает, Систему Б я даже не пробовал запускать, значит А — лучше, лучше, лучшееееее!!!!"


Как-то скорость Mercurial тоже в обзорах никогда не ругают. Структура репозитория у него тоже оптимизирована на быстрое извлечение любой ревизии файла — в общем случае чуть медленее, чем git из-за поддержки хранения разниц, но за счет постоянного присутствия "мастер-кадров" время построения нужной версии близко к постоянному, в отличии от SVN, где файлы с длинной историей могут строиться очень долго.
Зато получается, что объем репозитория у mercurial должен быть меньше, причем безо всяких шаманств с репаком.

DC>Да я то и сейчас с MKS-ом из vim-а и консоли работаю, вопрос в том, что абсолютное большинство людей в нашей конторе работают под виндой.

У нас в конторе, кроме MKS-а, несколько команд используют еще и SVN.
Как минимум одна из команд использует один репозиторий на 2 украинских офиса и на Польшу.
Так что по поводу SVN-а есть у кого консультироваться.
Но если выберете mercurial или git, то будет интересно узнать про процесс перехода и его результаты.

Здравствуйте, andrey.desman, Вы писали:

...
AD>Есть продукт, он очень большой и девелопится множеством команд на множестве сайтов по всему миру. Отдельные команды отвечают за один или несколько компонент.
AD>С точки зрения configuration management есть:
AD>1) Продуктовая метка.
AD>2) Компонентная метка для каждого отдельного компонента.
...
AD>5) Мы трое подаем запросы на интеграцию.
AD>6) Наш CM-инженер собирает в кучу наши изменения. Если здесь возникают какие-то конфликты, то они тривиальны и CM-инженер сам их разруливает. CM-инженер так же отклоняет любые изменения, которые не были одобрены пилотом соответствующего компонента.
AD>7) CM-инженер строит код со всеми изменениями. Все проблемы с падающими билдами решаются тут же со всеми участниками.
...
AD>8) Отстроенный продукт отдается на тестирование. Если что-то поломалось, то ищется злосчастный запрос, который и выкусывается, тогда итерация повторяется.
AD>9) Релиз оттестирован. CM-инженер завершает мерж в ветку продукта, помечает срез меткой и пуляет нашу метку в продуктовую метку.
Моторола, SEI-CMMI5
Это все прекрасно работает, когда есть монстроузный проект (начинка телефона) и в нем надо делать какие-то косметические изменения. Да еще нужно содержать целую ораву сертифицированных админов чтобы обслуживать VOB-ы.

Здравствуйте, vladimird, Вы писали:

V>В любом случае нужно же будет реплицировать исходники в MKS(привет из Днепра )?
V>Как собираетесь это делать?

Примерно так же как и кусишники. Мы сейчас пока в процессе выбора СКВ.

Здравствуйте, Vladimir Bezugliy, Вы писали:

VB>У нас в конторе, кроме MKS-а, несколько команд используют еще и SVN.
VB>Как минимум одна из команд использует один репозиторий на 2 украинских офиса и на Польшу.
VB>Так что по поводу SVN-а есть у кого консультироваться.

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

VB>Но если выберете mercurial или git, то будет интересно узнать про процесс перехода и его результаты.

Ну mercurial мне пока меньше всего понравился, bazaar интересен набором готовых рецептов и официальной платной поддержкой (но что-то после 2х годичного использования продуктов Canonical есть ощущение, что не смотря на всю "гламурность" придётся работать напильником и паяльником). Пока у меня в фаворитах git за счёт совей скорости и кастомизируемости, но время покажет что у нас получится.

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

В чем сложность?
В поддержке кучи веток?

Здравствуйте, alsemm, Вы писали:

A>Здравствуйте, Константин, Вы писали:

К>>Исходники 11.5Gb, 6 тысяч файлов, .git — 7.7Gb (в основном редко изменяемые бинарные файлы). git чуть тормозит, но работать можно. Mercurial использовать не рискну
A>Если не секрет, что это за проект такой, что в одном репозитарии 11.5Gb исходников?

Это не исходники в смысле исходного кода. Скорее это наборы тестовых данных, которые крайне редко, но всё-таки меняются.

Здравствуйте, vladimird, Вы писали:

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

V>В чем сложность?
V>В поддержке кучи веток?

Куча веток это одна из проблем. Вообще в идеале, хочется создать удачный прецедент и набор готовых решений для перехода других юнитов. Т.е. хочется и конвертер истории и интеграцию с существующей MKS инфраструктурой.

DC>Куча веток это одна из проблем. Вообще в идеале, хочется создать удачный прецедент и набор готовых решений для перехода других юнитов. Т.е. хочется и конвертер истории и интеграцию с существующей MKS инфраструктурой.

У нас каждая команда сама по себе создает такие прецеденты и пишет велосипеды
Мы сейчас тоже что-то подобное собираемся делать(вернее переделать имеющееся) для конвертации SVN -> MKS.
Основная переделка — поддержка бранчей/вариантов.
Правда у нас команда нераспределенная. Все сидим в одном офисе. Пока

Но пока не будет команды сверху, то все велосипеды так и останутся велосипедами

Здравствуйте, lomeo, Вы писали:

L>Обучение Git-у сравнимо с обучением svn-у. IMHO.
Повторю: без обучения чему-либо для пользующихся. Просто стандартное окно Pending changes в студии. Для нетривиальных случаев — контекстные меню (основная грабля с анком и была в раскидывании пунктов таким образом чтобы спрятать опасные фичи поглубже и сделать нужное легконаходимым).

L>На работе пользуюсь git-svn, соответственно локальные правки делаю в локальных ветках, затем мёржу в мастер и лью. Если при мёрже конфликт (кто-то уже залил что посвежее) — очень просто сделать rebase. В svn этой проблемы нет только потому, что там нет и огромного преимущества — локальных веток. Что-то сделал в соседней ветке — очень лёгкий cherry-pick и изменения в другой ветке. Не нравится история — rebase и получаешь то, что надо. Интерактивный rebase для простых случаев (слить коммиты, поменять коммит, удалить коммит) — рулит. Всё, что я хочу проверить/сделать — проверяет/делает Git хуками.

Отдельные слова понятны (поскольку дежурный по глюкам окружения). Сосед сделал круглые глаза и поинтересовался почему низзя просто работать и "сохранять в репозиторий по кнопке".
Прелесть именно в том что люди тратят время на полезные вещи а не на повышение ЧСВ.

Здравствуйте, vladimird, Вы писали:

V>У нас каждая команда сама по себе создает такие прецеденты и пишет велосипеды
Да, насколько я понял, BU у нас много, а вот SVN используют только новые, которые с самого начала на нём процесс построили.

V>Мы сейчас тоже что-то подобное собираемся делать(вернее переделать имеющееся) для конвертации SVN -> MKS.
V>Основная переделка — поддержка бранчей/вариантов.

Бранчи то будут, сливать эти бранчи и перекидывать между ними коммиты в SVN-е довольно геморно, в смысле руками делать надо будет.
А с DCVS можно настроить более гибко:
1. Сделать набор скриптов чтоб девелопер мог использовать DCVS как локальный репозиторий, а MKS — используется для взаимодействия с другими.
2. Поменять эти скрипты так, чтоб этот репозиторий мог использоваться всей командой, а MKS — только для взаимодействия с другими коммандами.
3. MKS зеркало только для отчётности.

Хотя SVN, в принципе, может стать ступенькой, т.к. git/mercurial/bazaar поддерживают вытягивание истории из SVN-а.

V>Правда у нас команда нераспределенная. Все сидим в одном офисе. Пока

V>Но пока не будет команды сверху, то все велосипеды так и останутся велосипедами

Надо показать им преимущества. Мне, например, чтоб залиться на Днепропетровский сервак (10-20 файлов) надо не менее 1,5 часов потратить на просмотр окошек и статус баров MKS-а. Сам понимаешь это очень много, да и Днепропетровске тоже времени не мало уходило, т.к. нельзя одной командой просмотреть объем изменений, дифы и залить. Прыганье по папкам тоже занимает время.

В крайнем случае мы просто облегчим жизнь себе .

Здравствуйте, alsemm, Вы писали:

A>Моторола, SEI-CMMI5
Она самая

A>Это все прекрасно работает, когда есть монстроузный проект (начинка телефона) и в нем надо делать какие-то косметические изменения.
Что касается косметических изменений, то все совсем наоборот. Слишком много геммороя на ровном месте из-за нескольких строк. А вот для более существенных изменений этот процесс работает как надо. Просто моторка, как и почти всякая крупная компания, не обладает достаточной степенью мобильности и гибкости.
В принципе, примерно так же оно работает и в linux kernel (читаем про лейтенантов тут).
Ну а вариаций вообще дофига.

A>Да еще нужно содержать целую ораву сертифицированных админов чтобы обслуживать VOB-ы.
А то! Именно поэтому git рулит Сам себе админ.

Здравствуйте, IID, Вы писали:

IID>1) [Автогенерируемые средой] Ресурсы (.rc, .h). Не то чтобы смержить было нельзя, но зачем нужен гемморой на ровном месте ?
IID>2) [Автогенерируемые средой] Настройки проекта (.vcproj). Переколбашиваются капитально, зачастую проще заново внести изменения чем мержить. Благо изменение настроек явление редкое.

Любая VCS, которая умеет мержить (т.е. оперирует дельтами), заточена под хранение текстовых данных, изменения в которые вносятся стабильно (стабильность — примерно как стабильность в stable sort). Иначе сносит крышу у любой из них.
Весь автогенерируемый хлам по-хорошему должен генерироваться из источника в процессе билда. С файлами студии глюк заключается в том, что источником нагенеренного барахла являются галки, комбобоксы и прочий UI. В то же время, местом хранения этих галок является сам автогенерируемый файл. Т.е. источником для автогенерации является сам автогенерируемый файл, при том что стабильность при его перегенерации студия не обеспечивает (ну конечно, нах оно надо? ).
В общем, кривые подходы требуют кривых решений. Причем глобальная блокировка — это не менее кривое решение, которое, ну да, имеет свои преимущества и недостатки, и в отдельных случаях конечно будет предпочтительней. Но конечно, it depends. Если бы настройки проекта менялись часто, то от блокировки вы бы взвыли. А если изменения можно вносить только атомарно в несколько файлов сразу, то тут и дэд-локи не заставят себя ждать.
Еще одним решением может служить хук при коммите, который будет брать дельту, парсить ее и делать stable apply на базовую версию.
Еще одно решение ты уже озвучил — назначение владельца, который по скриншотам будет расставлять галки (т.е. мержить из источника) Логически правильный, но геморройный.
Еще одно решение — редактирование файлов вручную. Тоже логически верный... и геморный.
Еще одно решение — использование альтернативных средств — (n|c)make. Убиваем автогенерацию, проблемы нет. Но появляется необходимость править настройки в текстовом виде. Мне, например, поправить make-файл не составит труда, но не всем такое придется по нраву, это да.

IID>3) Объемный XML. Не знаю почему, но у диффа из SVN частенько отрывает башню, и он мержит без конфликтов, но результат — полная ерунда.
Про SVN не знаю, возможно он просто слишком умный и добрый. У меня ClearCase по каждому чиху открывал графический мерж.

IID>4) [В порядке гипотезы] Бинарные файлы. Например документация (.doc, .xls, .ppt, etc.). Не мержатся в принципе. Для таких проще административно заставить делать lock перед изменениями, чем разгребать результаты. Да, чур всякие SharePoint-ы и InfoPath-и не предлагать. И смену формата тоже не предлагать.

У всяких библиотек как правило есть ответственный. Смысл их хранения в VCS — для удобства, но сам по себе version control не имеет смысла. Ок, проехали.
Документация. Документацию по коду лучше хранить в самом коде (doxygen javadoc, etc.), иначе она быстро устаревает. Дизайны и прочие high-level документы как правило имеют своего владельца, который вносит изменения единолично, или они вносятся с его позволения.
Документы, которые относительно часто меняются всеми (статусы, требования на оперделенном этапе, etc.), лучше хранить в вики-подобном движке. Хочется мучиться/блочиться с doc-ами — пожалуйста
Word/Excel документы, к которым нужен общий доступ с блокировкой, у нас лежат на веб-серваке. Там тоже некоторое подобие VCS, только без мержей и дельт — самый простой вариант (большего и не надо). Такие документы в основном нужны, чтобы собрать инфу с нескольких человек, а редактирование заключается в заполнении пары строк в табличке.

AD>>Ну, например, если два человека одновременно делают в одном файле что-то такое, что git не в состоянии разрулить, то, боюсь, что-то у вас не так.
IID>Варианты ?
Масса

Здравствуйте, andrey.desman, Вы писали:

AD>Здравствуйте, alsemm, Вы писали:

A>>Моторола, SEI-CMMI5
AD>Она самая

A>>Это все прекрасно работает, когда есть монстроузный проект (начинка телефона) и в нем надо делать какие-то косметические изменения.
AD>Что касается косметических изменений, то все совсем наоборот. Слишком много геммороя на ровном месте из-за нескольких строк.
Я не совсем корретко выразился. Вся эта бюрократия, ClearCase, выделенный человек который занимается только мержем и т.п. — атрибуты процесса разработки ПО, при котором большинство программистов легко заменяемы. Собственно SEI-CMMI5 — это оно и есть. С такой организацией производства наиболее комфортно можно заниматься багфиксом. Ну а багфикс — это пара строк и есть. Под это дело лет пять назад и "программистов" стали пачками набирать (в java отдел, по крайней мере) соответствующих. Каждый день новое лицо, блин

Здравствуйте, Константин, Вы писали:

К>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Поковырялся я тут весьма плотно на прошлой неделе с сабжем (линуксоидам: под вин7, используя tortoisegit, так что не обольщайтесь). На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss). Я ошибаюсь?

К>На мой взгляд тоже (работал с svn, vss, mercurial, StarTeam). Использую больше полугода msysgit. До этого эволюция шла в следующем направлении: svn => mercurial => git.
А вы не могли бы поподробне рассказать про mercurial => git часть эволюции? Что вы нашли в git, чего нет в mercurial. В данный момент в компании имеют место муки выбора системы контроля версий для нового проекта, интересен ваш опыт.

_jw> А вы не могли бы поподробне рассказать про mercurial => git часть эволюции? Что вы нашли в git, чего нет в mercurial. В данный момент в компании имеют место муки выбора системы контроля версий для нового проекта, интересен ваш опыт.

Можно почитать, почему Gogle Code испольщует меркуриал, а не гит: http://code.google.com/p/support/wiki/DVCSAnalysis

Здравствуйте, Sinix, Вы писали:

L>>Обучение Git-у сравнимо с обучением svn-у. IMHO.
S>Повторю: без обучения чему-либо для пользующихся. Просто стандартное окно Pending changes в студии. Для нетривиальных случаев — контекстные меню (основная грабля с анком и была в раскидывании пунктов таким образом чтобы спрятать опасные фичи поглубже и сделать нужное легконаходимым).

С Git можно работать как с svn. Точно так же с окошком коммита, только пользы от него тогда будет как от svn.

L>>На работе пользуюсь git-svn, соответственно локальные правки делаю в локальных ветках, затем мёржу в мастер и лью. Если при мёрже конфликт (кто-то уже залил что посвежее) — очень просто сделать rebase. В svn этой проблемы нет только потому, что там нет и огромного преимущества — локальных веток. Что-то сделал в соседней ветке — очень лёгкий cherry-pick и изменения в другой ветке. Не нравится история — rebase и получаешь то, что надо. Интерактивный rebase для простых случаев (слить коммиты, поменять коммит, удалить коммит) — рулит. Всё, что я хочу проверить/сделать — проверяет/делает Git хуками.

S>Отдельные слова понятны (поскольку дежурный по глюкам окружения). Сосед сделал круглые глаза и поинтересовался почему низзя просто работать и "сохранять в репозиторий по кнопке".

Можно. Я могу привести ещё кучу полезных инструментов, без которых обходятся люди. Что из этого следует?

Повторю свой тезис — в svn этого не делают, потому что делать сложно, а не потому что бесполезно. Как только что-то можно сделать проще — можно перейти на качественно другой уровень. Возьми REPL, вот для Java он тоже есть, но им никто не пользуется. Из-за его неудобства я даже названия его не помню — java shell, кажется.

S>Прелесть именно в том что люди тратят время на полезные вещи а не на повышение ЧСВ.

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

Здравствуйте, Mamut, Вы писали:
M>Можно почитать, почему Gogle Code испольщует меркуриал, а не гит: http://code.google.com/p/support/wiki/DVCSAnalysis
А ответа-то там и нет (комменты не читал). Просто говорится, что гит лучше работает с ветками и у него в целом побольше фич. А mercurial попроще и лучше работает по http.

Здравствуйте, Sinix, Вы писали:
S>Сосед сделал круглые глаза и поинтересовался почему низзя просто работать и "сохранять в репозиторий по кнопке".
Просто он еще не знает всех возможностей современных систем контроля версий. Можно, конечно, утверждать, что людям свойственно маяться любой херней, лишь бы не работать, однако я склонен считать, что затраты на изучение и использование систем контроля версий со временем окупаются.

MC> M>Можно почитать, почему Gogle Code испольщует меркуриал, а не гит: http://code.google.com/p/support/wiki/DVCSAnalysis

MC> А ответа-то там и нет (комменты не читал). Просто говорится, что гит лучше работает с ветками и у него в целом побольше фич. А mercurial попроще и лучше работает по http.

Ну, для многих и это может быть решающим

Здравствуйте, Mamut, Вы писали:
M>Ну, для многих и это может быть решающим
А, все, перечитал и понял. Для гугла, похоже, была решающей работа по http.

Здравствуйте, lomeo, Вы писали:

S>>Прелесть именно в том что люди тратят время на полезные вещи а не на повышение ЧСВ.
L>Ты уже и меня посчитал?
L>Я Git-ом пользуюсь, чтобы потом как-нибудь перед тобой попонтоваться?
Уппс... что-то холивар не в ту сторону пошёл из-за вышесказанного. Ни разу не ставил цель обстебать — написал именно то что думал. Если восприняли как личный наезд — прошу прощения.

Учитывая что:
-команда небольшая.
-используются мелкие итерации.
-над конкретным куском кода _одновременно_ работают не больше двух человек (да ещё и за одним компом — чтобы время на беготню не тратить).
-часть файлов в проекте редактировать совместно не выйдет — тот же код от дизайнера

возможностей чего угодно с блокировкой и атомарными коммитами хватит за глаза. SVN, повторюсь, был выбран по одной причине — мне удалось под него собрать устраивающее нас окружение.

L>С Git можно работать как с svn. Точно так же с окошком коммита, только пользы от него тогда будет как от svn.
L>Повторю свой тезис — в svn этого не делают, потому что делать сложно, а не потому что бесполезно.
Повторюсь. Git вполне кошерная штука. Но до тех пор пока она будет работать как вешь в себе — толку от неё никакого.

Если не согласны — приведите плиз фичи, что перевешивают сырые ui-тулзы, лёгкие грабли с развёртыванием, отсутствие интеграции со студией и большей частью баг-трекеров. С учётом нужд мелких проектов (см выше).

Здравствуйте, Mr.Cat, Вы писали:

MC>Просто он еще не знает всех возможностей современных систем контроля версий.
Э-мм? Дифф/blame/history/lock/... — прямо в меню у Pending changes. И используются как нечто очевидное. Чего нехватает для работы помимо веток?

С ветками — да, вопрос крайне больной из-за ньюансов svn. После двукратного обрушения репозитария мерж упрятан куда подальше. Кто виноват (из софта) — не разбирались.

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

Ну да. Другое дело что изучение не должно превращаться в поголовное чтение мануалов и обсасывание фич системы. Оно должно просто работать — ибо не основной инструмент.
Собсно исходный посыл был — "оно сырое в плане интеграции". Почему со мной спорят по иным поводам — это не ко мне

Здравствуйте, Sinix, Вы писали:
S>Сосед сделал круглые глаза и поинтересовался почему низзя просто работать и "сохранять в репозиторий по кнопке".
MC>>Просто он еще не знает всех возможностей современных систем контроля версий.
S>Э-мм? Дифф/blame/history/lock/... — прямо в меню у Pending changes. И используются как нечто очевидное. Чего нехватает для работы помимо веток?
Вот видишь — человек пользуется всеми кнопками, какие нашел, а ты "сохранять в репозиторий по кнопке". Впрочем, ветки — это самое интересное. Несмотря на некоторую их неполноценность в svn.

S>С ветками — да, вопрос крайне больной из-за ньюансов svn. После двукратного обрушения репозитария мерж упрятан куда подальше. Кто виноват (из софта) — не разбирались.
Есть проблема в была тулзе — то скорее всего виноват ankh. Я им опасаюсь пользоваться кроме как для того, чтобы правильно работало перемещение файлов в солюшене.

S>Собсно исходный посыл был — "оно сырое в плане интеграции". Почему со мной спорят по иным поводам — это не ко мне
Ну это смотря с чем интергация. У mercurial, например, есть плагин для VS, есть shell extension, есть поддержка в средствах CI (в TeamCity, например).

Здравствуйте, Mr.Cat, Вы писали:

MC>Ну это смотря с чем интергация. У mercurial, например, есть плагин для VS, есть shell extension, есть поддержка в средствах CI (в TeamCity, например).

На рсдн интеграция == интеграция со студией?

Я вот использую xmonad + rxvt + zsh + vim как инструменты разработки. Git туда отлично интегрируется

Сначала надо узнать, какая именно интеграция требуется. Я пока не понял.

Здравствуйте, Cyberax, Вы писали:

C>>>Никаких проблем с 30Мб XML'ем не было (REnouveau Dump'ы, если интересно).
IID>>Возможно зависит от структуры документа. В моём случае имелось много (несколько мегабайт. Не 30, но всё равно дофига) почти одинаковых по содержимому блоков, состоящих из примерно 10-уровневой вложенности тегов. Когда блоки "опускались" вниз по файлу в силу изменений, мерж начинал рассовывать "серединки" блоков последующих изменений не на причитающееся им место, а в соседей. Видимо соседи выглядели для него слишком похожими Он их начинал воспринимать тоже как изменения.
C>Надо подкрутить настройки эвристик, наверное. Кстати, ещё есть mergexml — он под него специально заточен.

Вот, сейчас опять всплыла проблема кривого диффа XML штатными черепашьими средствами. Не подскажешь точную ссылку ? По киворду "mergexml" находится дофига чего, в т.ч. платные решения от Altova.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Поковырялся я тут весьма плотно на прошлой неделе с сабжем (линуксоидам: под вин7, используя tortoisegit, так что не обольщайтесь). На мой скромный взгляд — это лучшая система контроля версий из всех, что я видел (а видел и щупал я svn, mercurial и vss). Я ошибаюсь?

К большим бинарникам в репозитории git относится сильно хуже чем subversion.

Здравствуйте, Cyberax, Вы писали:

C>Именно _редактирование_. Можно разбивать/сливать коммиты, перемешивать их местами, удалять, редактировать их.
C>Т.е. делаю я какую-то фичу, и коммичу изменения каждые 5 минут. С description'ами типа "change" или "bugfix".
C>И чтоб потом такое г. не пихать в основнойрепозиторий — делаю "git rebase -i" и сливаю все эти мусорные коммиты в один коммит с нормальным описанием.

вот, добрался до mercurial-а, посмотрел как там это делается..
т.к. ядро довольно маленькое, то эта фича реализована расширением mq.. включаются они, правда, руками в файле hgrc..
само расширение предоставляет возможность "рулить" патчами: сливать, менять содержимое, менять комменты и прочее..
выглядит это так:

# включаем расширение
$ hg qinit
# импортим в патчи коммиты с 1 до tip
$ hg qimport -r 1:tip
# удаляем их всех из истории (остаётся нулевой)
$ hg qpop -a
# запихиваем первый патч в историю
$ hg qpush 1.diff
# и в него фолдятся все остальные
$ hg qfold 2.diff
...
$ hg qfold 8.diff
# вот здесь они все собрались в один патчик и теперь можно изменить мусорные комменты..
# запихиваем все патчи обратно в историю
$ hg qpush -a
$ hg qfinish -a

правда, последней команды в моей старой версии не оказалось..
http://mercurial.selenic.com/wiki/MqExtension

Здравствуйте, neFormal, Вы писали:

F>выглядит это так:
F>

F># включаем расширение
F>$ hg qinit
F># импортим в патчи коммиты с 1 до tip
F>$ hg qimport -r 1:tip
F># удаляем их всех из истории (остаётся нулевой)
F>$ hg qpop -a
F># запихиваем первый патч в историю
F>$ hg qpush 1.diff
F># и в него фолдятся все остальные
F>$ hg qfold 2.diff
F>...
F>$ hg qfold 8.diff
F># вот здесь они все собрались в один патчик и теперь можно изменить мусорные комменты..
F># запихиваем все патчи обратно в историю
F>$ hg qpush -a
F>$ hg qfinish -a
F>

F>правда, последней команды в моей старой версии не оказалось..
F>http://mercurial.selenic.com/wiki/MqExtension

И эти люди говорят что git сложный . В меркуриале мне не понравилось что для бранчевания используется 4 способа: клонирование, анонимные бранчи, именованные бранчи и букмарки(они уже переносятся между серверами?). Причём именованные бранчи имеют одну потрясающую особенность: когда делаешь пуш по умолчанию заливает во все бранчи, не это правится в конфиге, но ... Кстати, как там с контролем доступа? Для git-а я могу настроить авторизацию через ssh или webdav, которая будет использовать kerberos и ldap, причём в первом случае(ssh) мне доступно выполнять любые проверки(хуками) централизованно. А меркуриал подобное умеет?

Здравствуйте, dr.Chaos, Вы писали:

F>>выглядит это так:
F>>

F>>$ hg qinit
F>>$ hg qimport -r 1:tip
F>>$ hg qpop -a
F>>$ hg qpush 1.diff
F>>$ hg qfold 2.diff
F>>...
F>>$ hg qfold 8.diff
F>>$ hg qpush -a
F>>$ hg qfinish -a
F>>

F>>http://mercurial.selenic.com/wiki/MqExtension
DC>И эти люди говорят что git сложный .

а тут ничего сложного нет.. вытащили всё в виде патчей (кстати, можно использовать git-style патчи) и соединили между собой, потом запихнули обратно.. да и это только один плуг к hg.. можно сделать другой, который сделает те же команды, но незаметно для юзера..
EXPANSIBILITY! EXPANSIBILITY! EXPANSIBILITY!

DC>В меркуриале мне не понравилось что для бранчевания используется 4 способа: клонирование, анонимные бранчи, именованные бранчи и букмарки(они уже переносятся между серверами?). Причём именованные бранчи имеют одну потрясающую особенность: когда делаешь пуш по умолчанию заливает во все бранчи, не это правится в конфиге, но ...

клонирование — это не бранч..
за букмарки не знаю, а с просто бранчами не заметил, чтобы оно заливалось во все ветки..

DC>Кстати, как там с контролем доступа? Для git-а я могу настроить авторизацию через ssh или webdav, которая будет использовать kerberos и ldap, причём в первом случае(ssh) мне доступно выполнять любые проверки(хуками) централизованно. А меркуриал подобное умеет?

можно.. я сделать "центральный" репозиторий на соседней железке и по ssh заливаю туда изменения.. авторизация осуществляется средствами системы..
но там можно запустить hg-сервер, который будет предоставлять доступ по своему протоколу.. пока это не трогал, т.к. не надо..
а ещё можно сделать веб-доступ к просмотру репозитория.. так-то.. :-P

Здравствуйте, neFormal, Вы писали:

F>а тут ничего сложного нет.. вытащили всё в виде патчей (кстати, можно использовать git-style патчи) и соединили между собой, потом запихнули обратно.. да и это только один плуг к hg.. можно сделать другой, который сделает те же команды, но незаметно для юзера..
F>EXPANSIBILITY! EXPANSIBILITY! EXPANSIBILITY!

Это всё последствия формата хранения, в итоге всё ручками надо. Это на самом деле несколько уменьшает количество людей использующих это.

DC>>В меркуриале мне не понравилось что для бранчевания используется 4 способа: клонирование, анонимные бранчи, именованные бранчи и букмарки(они уже переносятся между серверами?). Причём именованные бранчи имеют одну потрясающую особенность: когда делаешь пуш по умолчанию заливает во все бранчи, не это правится в конфиге, но ...

F>клонирование — это не бранч..

Бранч в стиле svn-а, git-такое тоже умеет но там это обычно называют форк . Причём этот вид бранча наиболее часто используем ибо один из самых безопасных и простых.

F>за букмарки не знаю, а с просто бранчами не заметил, чтобы оно заливалось во все ветки..
Ну здесь пишут что таки льёт.

DC>>Кстати, как там с контролем доступа? Для git-а я могу настроить авторизацию через ssh или webdav, которая будет использовать kerberos и ldap, причём в первом случае(ssh) мне доступно выполнять любые проверки(хуками) централизованно. А меркуриал подобное умеет?

F>можно.. я сделать "центральный" репозиторий на соседней железке и по ssh заливаю туда изменения.. авторизация осуществляется средствами системы..
F>но там можно запустить hg-сервер, который будет предоставлять доступ по своему протоколу.. пока это не трогал, т.к. не надо..
F>а ещё можно сделать веб-доступ к просмотру репозитория.. так-то.. :-P
Ну насколько я понимаю у git-а тоже самое, только не понятно почему меркуриал более http-friendly. Хуки у меркуриала есть?

Здравствуйте, Cyberax, Вы писали:

F>>само расширение предоставляет возможность "рулить" патчами: сливать, менять содержимое, менять комменты и прочее..
C>Немного другое. В git'е rebase мощнее, чем в hg.

это не rebase.. rebase реализован отдельным плугом, но его я ещё не смотрел, т.к. в моей древней версии его нет..

C>Аналог MqExtension в git'е — это http://procode.org/stgit/

ага.. действительно..

Здравствуйте, dr.Chaos, Вы писали:

F>>а тут ничего сложного нет.. вытащили всё в виде патчей (кстати, можно использовать git-style патчи) и соединили между собой, потом запихнули обратно.. да и это только один плуг к hg.. можно сделать другой, который сделает те же команды, но незаметно для юзера..
DC>Это всё последствия формата хранения, в итоге всё ручками надо. Это на самом деле несколько уменьшает количество людей использующих это.

какие такие последствия?. и что там "такого" в формате?.

F>>клонирование — это не бранч..
DC>Бранч в стиле svn-а, git-такое тоже умеет но там это обычно называют форк .

git clone — это тоже бранч?. ~_^

F>>за букмарки не знаю, а с просто бранчами не заметил, чтобы оно заливалось во все ветки..
DC>Ну здесь пишут что таки льёт.

ну, я сегодня заливал на отдельный репозиторий.. залил бранч — не увидел..

DC>Хуки у меркуриала есть?

есть.. http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html
ещё есть приятное расширение, которое присылает мыло, когда кто то что нибудь делает с репозиторием..

Здравствуйте, neFormal, Вы писали:

F>какие такие последствия?. и что там "такого" в формате?.

Ну хранится ведь патч, вот и чтоб менять как-то историю надо над этими патчами работать, в git-е выкидывание коммита очень простая операция. Да и хранение имени бранча в коммите весьма "интересное" решение, которое весьма затрудняет работу с ними. Т.е. эти решения влияют на частоту использования именованных бранчей, т.е. они по сути long term бранчи, не более. А вот чтоб зашарить изменения в кратковременных бранчах придётся поизвращаться.

Вот пример: у проекта есть 5 разных версий в бранчах, 3 бранча заморожены (т.е. туда изменения пойдут не сразу), мы находим баг который аффектит все версии, и получается так что править в разных местах его надо сильно по разному. В git-е это будет до 5 topic бранчей, часть из которых будет ждать разморозки своих версий. Как мне хранить эти изменения в меркуриале? Именованные бранчи плохой вариант ИМХО.

F>git clone — это тоже бранч?. ~_^

Да, только в git-е так делают редко, потому как есть более прямой и очевидный способ с именованным бранчем.