SVN

Оно.

Зачем для одного действия делать разные команды? Это касается и скачивания (fetch/pull) и отката изменений (checkout/reset).

Только Bazaar, только хардкор!

>revert делается checkout'ом

Это у вас в ваших меркуриалах/свнах чекаут делается ревертом :)

>Кстати, я пока не понял чем отличается git fetch от git pull

git pull = git fetch && git merge

>Зачем для одного действия делать разные команды?

Действий два. Два действия, две команды.

Нет, checkout (обновление исходников) у нас делается update'ом, а revert (откат изменений) revert'ом. При этом для отката изменений одного файла используется revert и для отката всех изменений как ни странно тоже используется revert.

Действие одно «откат изменений». Это всё равно что в *nix chmod одного файла делать chmod'ом, а chmod директории делать не chmod'ом, а каким-нибудь change-mode-for-directory.

> SVN устаревшее говно, Git распиаренное говно, Mercurial нераспиаренное говно. Рулит только ClearCase.

Починил.

>Действие одно «откат изменений»

git reset - да, git checkout чаще используется для прыганья по бранчам или состояниям дерева на конкретный коммит.

> Рулит только ClearCase.

Рабы ынтерпрайза ITT.

Зато в CC дисциплина строже

Зато в CC дисциплина строже

дисциплина - она в голове, ёп

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

Кстати в git'е еще нет коротких числовых ревизий, поэтому навигация по дереву затруднена.

> > Рулит только ClearCase.

Рабы ынтерпрайза ITT.

Я давно с ней не работаю. Сейчас P4 & Git.

Насколько я понимаю, ты у нас фанат Hg? Расскажешь, как у неё обстоят дела c ACL?

> Насколько я понимаю, ты у нас фанат Hg?

Можно сказать и так.

Расскажешь, как у неё обстоят дела c ACL?

Смотря для чего они тебе нужны.

> которая для этого не предназначена это кроме как 3.14здец не назовешь.

Это напоминает стенания ярых императивщиков о ФП: «=» обозначает связывание, а не привычное присваивание. А в некоторых ФП вообще переменных нет, а массивы не имееют ничего общего с прывычными массивами в Си. Не иначе, как ArcTan[1]*4-здец.

Для указанной задачи лучше подходит Mercurial. SVN хорош, когда нужно выстраивать чёткую вертикаль власти и жёсткую централизацию. А когда один разработчик и нужно код туда-сюда таскать, то лучше Mercurial.

Можно git, но mercurial намного проще. И на python, что гарантирует его лёгкую запускаемость везде, где можно.

> Смотря для чего они тебе нужны.

Контроль за разными частями исходников платформы для разграничения доступа. Вариант по репозиторию на компонент не подходит.

Расскажешь, как у неё обстоят дела c ACL?

1 access 1 repo :)

Вариант по репозиторию на компонент не подходит.

почему?

> Контроль за разными частями исходников платформы для разграничения доступа.

Это не ответ. Нужно ли тебе ограничение на чтение (т.е. кто-то не должен видеть ынтерпрайз-секреты)?

Я вкурсе про этот подход. Он кривой и неюзабельный. Куда проще, к примеру, скрыть исходники, но оставить собранную библиотеку + хэдеры доступными кастомерам.

> Нужно ли тебе ограничение на чтение

Обязательно.

Он кривой и неюзабельный.

так в чём его кривость-то, в непривычности персонально для Вас?

Куда проще, к примеру, скрыть исходники, но оставить собранную библиотеку + хэдеры доступными кастомерам.

кто мешает так сделать?

Отстутствие вменяемого ACL. Посмотри, ради интереса, на ClearCase, и расскажи, как всё можно сделать на Hg. А потом продолжай троллить.

> Отстутствие вменяемого ACL. Посмотри, ради интереса, на ClearCase, и расскажи, как всё можно сделать на Hg. А потом продолжай троллить.

Зачем? Так можно про любое написать.

«Отсутствие возможности поменять автомат. Посмотри, ради интереса, на Urban Terror, и расскажи, как всё можно сделать на ClearCase. А потом продолжай умничать».

Первичны задачи, а не возможности. Если приложение решает задачи, значит оно хорошее. А если в приложении есть возможности, которые не вписываются в задачу, и их используют не для того, что они помогают решать задачу, а для того, что они есть, то это называется «играться с программой» а не «пользоваться программой».

Свои задачи hg решает очень хорошо. И прост, как три копейки.

>> Нужно ли тебе ограничение на чтение

бязательно.

Такого нет ни в Mercurial, ни в других известных мне DVCS. Впрочем, судя по опыту перехода OpenSolaris на Mercurial, это не особо серьезное ограничение.

жёсткую централизацию

Это всегда тормоз в девелопменте. Для того чтобы svn работал нужна (более-менее) быстрая связь и нужен сервер. А если у тебя комманда разбросана по миру то рано или поздно проблемы настанут.

Пока самый большое «преимущество» svn которое мне назвали было то что «он не хранит историю на клиентах, это более секурно в случае когда проект упрут» :)

Тут другой случай. В ФП «=» делает именно то что оно означает и ничего больше. Один функционал сконцентрирован в одной сущности и при этом эта сущность выполняет только этот один функционал.

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

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

Почему это не было? Был и есть. лежит в .git/ SVN тоже вытягивает файл, и что?

стоп. Что делает чекаут? Вытягивает директорию с нуля в новую пустую директорию. Отлично. Где ваш юникс вей? почему одна команда еще и откатывает файл до последней ревизии в системе контроля версий?

стоп. Что делает чекаут? Вытягивает директорию с нуля в новую пустую директорию.

checkout вытягивает последнюю версию файла/файлов/каталога/каталогов. Все. Это одно действие - зачем две команды??

Отстутствие вменяемого ACL. Посмотри, ради интереса, на ClearCase, и расскажи, как всё можно сделать на Hg.

я Вам показал решение, оно как минимум сравнимое по мощности, что Вам ещё непонятно?

//да, я тоже в своё время как только слез с svn удивлялся - как так

А потом продолжай троллить.

ну-ну, аргументы кончаются?

Т.е. git pull это git fetch + git merge

Не обязательно. После git fetch ты можешь сделать git rebase, а можешь git merge, можешь с fast-forward-ом, можешь без. Можешь сделать октопус merge, или merge со сквашем...

В этом фишка гита - он low level и developer oriend. А меркуриал - это гит для домохозяеек. Разница между гитом и меркуриалом - это как между линуксом и виндой.

Добавлю и я свои 5 копеек в холивар: гит сложнее, гит мощнее, в гит гораздо сложнее погрузится, поэтому изучение гита - хорошая инвестиция. Хочешь быстрый результат за дешево - юзай меркуриал.

> Разница между гитом и меркуриалом - это как между линуксом и виндой.

Разница между гит и меркуриал - это разница между старым Солярисом и современным Линуксом (и если ты не работал в Solaris 2.5 без всяких GNU-добавлений, ты не знаешь, почему Unix проиграл венде).

гит сложнее, гит мощнее, в гит гораздо сложнее погрузится, поэтому изучение гита - хорошая инвестиция.

Ага. Научиться плавать со связанными ногами - тоже хорошая инвестиция %)

Ага. Научиться плавать со связанными ногами - тоже хорошая инвестиция %)

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

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

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

А у какой профессии долг «окунаться во всю кухню системы контроля версий»?

если что-то там хоть как-то комитить по бранчам - то мерк.

Бгг. Это предложение как нельзя лучше описывает 90% гитоюзеров. Они дальше commit и push не продвинулись.

описывает 90% гитоюзеров. Они дальше commit и push не продвинулись.

Ну 90% процентов любого общества, сам знаешь :)))

А у какой профессии долг «окунаться во всю кухню системы контроля версий»?

Релиз-менеджер например.

хорошая инвестиция

не дай бог работать там где git используется. Keep it simple. Может усложнением git решаются задачи которые имеют другие решения?

А если у тебя комманда разбросана по миру то рано или поздно проблемы настанут.

какие, мм?

> я Вам показал решение, оно как минимум сравнимое по мощности, что Вам ещё непонятно?

сравнимое по мощности

Рассмешил. Ты ещё расскажи про атомарность коммитов в кучу репозиториев, клоун.

> Такого нет ни в Mercurial, ни в других известных мне DVCS.

Согласен, это всё потому, что такие понятие и применение ACL противоречит идеям DVCS.

Впрочем, судя по опыту перехода OpenSolaris на Mercurial, это не особо серьезное ограничение.

Для открытых проектов - да.

> Тут другой случай. В ФП «=» делает именно то что оно означает и ничего больше.

Я почему этот пример привёл — обозначение одно, а семантика разная в ФП и в императивных ЯП. Ничего, никто не ворчит.

Рассмешил. Ты ещё расскажи про атомарность коммитов в кучу репозиториев, клоун.

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

>> Такого нет ни в Mercurial, ни в других известных мне DVCS.

Согласен, это всё потому, что такие понятие и применение ACL противоречит идеям DVCS.

Что не мешает применять DVCS в закрытых коммерческих проектах: TeamWare, BitKeeper, да те же Mercurial и Git. В общем, проблема надумана - если часть репозитория закрыта от чтения, то без нее можно обойтись по определению, а такую часть можно вынести в отдельный репозиторий.

Впрочем, судя по опыту перехода OpenSolaris на Mercurial, это не особо серьезное ограничение.

Для открытых проектов - да.

Насколько я помню, в ON были закрытые компоненты, даже после открытия кода. Так вот, эти закрытые компоненты жили в репозитории (или нескольких), доступ к которым был только у Sun. И жалоб по этому поводу я не припомню.

какие

см. выше в том посте. Впрочем, кто о dvcs только по рассказам из интернета знает тот не поймёт :)

не дай бог работать там где git используется. Keep it simple.

Та самая simple может быть как локальной, так и глобальной. Выбор чего-то максимально простого и понятного может оказаться лишь локальными минимумом функции :) Я люблю простоту стратегическую, а не сиюминутную. Но в неумелых руках локальный максимум с надеждой на глобальный минимум сложности может так и остаться максимумом :) Так что, как в анекдоте: «нехрен выеживаться, коль летать не умеешь»

Насчет работать «там где гит». Работаю как раз в таком месте. Перед переходом с svn на dcvs был нехилый такой срач git vs mercurial. Поднимать месячную переписку нескольких десятков людей не охота, но в итоге выбрали git. В итоге все довольно быстро привыкли и всех устраивает.

И вообще гит или мерк - каждому свое, главное на bazaar не нарваться )))