Subversion 1.7

у hg адекватный вывод --help и сообщения об ошибках

У git - тоже.

а также по командам он совсемистим с svn/cvs/bitkeeper

В этом плане да. Тем не менее, если он будет вашей первой VCS - вам будет безразлично на это.

> То есть аргумент, что git сложный для освоении это вообще не аргумент.

Очень даже аргумент, потому что git бессмысленно сложный, и при этом есть и другие DVCS.

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

Удивили в камментах.

Как по мне, выбор svn для нового проекта - профнепригодность. Прям вопрос для собеседования на позицию тимлида - «Какие проблемы будут испытывать разработчики, используя svn вместо hg? hg вместо git?»

Правильный ответ: никаких?

git уже умеет из каропки пушить по http?

а как на счет автоматического изменения «\n» <-> «\r\n» в зависимости от рабочей ОС с поддержкой исключений для выбранных файлов?

как на счет возможности закоммитить пустой каталог без всяких там .keepme внутри?

Лично для меня под новую задачу выбор будет между svn и hg. Набор скриптов под названием git идет в биореактор.

а как на счет автоматического изменения «\n» <-> «\r\n»

Можешь сказать зачем это может быть нужно?

> > а как на счет автоматического изменения «\n» <-> «\r\n»

Можешь сказать зачем это может быть нужно?

Чтобы не бегать за каждым виндовс девелопером и не упрашивать пользоваться правильными редакторами. Всем вдруг становится неожиданно пофигу где редактировался/создавался текстовый файл. На каждой ОС он всегда выглядит нативно.

и не упрашивать пользоваться правильными редакторами.

Обычно для этого вешается хук. И никого упрашивать не надо. У всех становится единообразный '\n'.

> > и не упрашивать пользоваться правильными редакторами.

Обычно для этого вешается хук. И никого упрашивать не надо. У всех становится единообразный '\n'.

Обычно для какой RCS? В случае с svn, хуком дело не исправить, т.к. во время коммита это приведет к десинхронизации рабочей копии. На сервере будет версия с '\n', а в локальной копии '\r\n'.

Поэтому в svn это именно фича протокола. Приятная, на мой взгляд, фича.

hg вместо git?

а какие?

Ну вот на вскидку

1. Команда получит проблемы с merge. Ветвить svn будут гарантированно уметь не все. В реале получим завязку на одного конкретного парня, который это умеет.

2. Единственный центральный репозиторий. Отключили инет, органы изъяли сервер - сидим курим.
Есть задачи, где нужно иметь 0 общих репозиториев (папочка со всей историей проекта, которую можно скинуть на флэшку), есть, где нужно иметь целое дерево: репозитории отдельных команд -> ропозиторий тестирования -> продуктивный репозиторий. svn здесь ограничивает возможности.

3. Ну и самое главное - отсутствие локальных комитов.
По итогам моего слезания с svn на DCVS: размер комита в общий репозиторий остался прежним, зато появились «минорные» комиты для себя. Потери кода при откате сократились в разы.

С окончаниями согласен. Сам не от хорошей жизни установил dos2unix. Но я и не говорил, что git чем-то лучше hg.
Опишите случай, когда будет выбран svn.

На сервере будет версия с '\n', а в локальной копии '\r\n'.

Да нет же, имелось в виду давать отлуп при попытке коммита неправильно оформленного кода.

По мне hg лучше.
Единственный момент, несколько оправдывающий использования git - стоимость развертывания на редких юниксах. Хрен знает, есть ли готовый python под HP UX на итаниуме. perl и bash все-таки вероятнее.

>hg вместо git?

Если ставить вопрос так, то ответ однозначен: bazaar!

Почему о нелогичностях и неадекватных сообщениях я ничего не знаю?

Маны по любой VCS читать придется, если это первая ваша VCS.

Не сложный он, просто «не совсем такой, как остальные».

Почему о нелогичностях и неадекватных сообщениях я ничего не знаю?

Привык наверно? Например, когда не работает push из-за того, что репозитории разъехались hg предлагает сделать pull/merge, а git выдает какой-то неадекват, видя который 90% разработчиков хватаются за голову с фразой «%ля, чего случилось, куда бежать, что делать».

Ну и очередной раз напомню про невзаимнообратные команды, которые называются взаимнообратно.

О чём ты? Все редакторы (даже виндовые, а в семерке вроде даже блокнот) умеют работать и с никсовыми, и с виндовыми переносами.

git оправдывают удобство и быстрота. python, как и perl и bash, есть везде.

Базар - это ужас... Во всех смыслах этого слова...

Ты gnu tla не видел.

Привык наверно?

С первых дней использования?

Например, когда не работает push из-за того, что репозитории разъехались hg предлагает сделать pull/merge, а git выдает какой-то неадекват

Потестил:

To file:///home/roman/myprograms/git1
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'file:///home/roman/myprograms/git1'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.[/quote]
Обращаем внимание на это:

Merge the remote changes (e.g. 'git pull')

Предлагает сделать pull. ЧЯДНТ?

Ну и очередной раз напомню про невзаимнообратные команды, которые называются взаимнообратно.

Помню только два случая.

Не видел.

если бы увидел, то bzr уже не называл бы ужасом :)

>1. Команда получит проблемы с merge. Ветвить svn будут гарантированно уметь не все. В реале получим завязку на одного конкретного парня, который это умеет.
Какие такие проблемы с merge?
вы что все из сонсоли работаете?

2. Единственный центральный репозиторий. Отключили инет, органы изъяли сервер - сидим курим.

Чай не в Нигерии живём.
Кроме того кто мешает работать локально?
Или у вас работа только из тоступа к VC состоит?

3. Ну и самое главное - отсутствие локальных комитов.

Нахрен он нужен, если есть бранчи?

зато появились «минорные» комиты для себя.

Вы судя по всему бранчами не научились пользоваться. Ну, не беда. Зато в полку пользоватетелей маргинальных VCS прибавление :)

Для разработи 1-3 человеками SVN за глаза хватет. С большим, так сказать, запасом. А группы из 1-3 это всяк больше половины прооектов.

Может это и так, но мне изначально git показался удобней хоть для одного человека :) В нём всё как-то... более логично, что ли, реализовано, более понятно. Опять же ИМХО, основанное лишь на собственном опыте использования VCS.

>> 3. Ну и самое главное - отсутствие локальных комитов.

Нахрен он нужен, если есть бранчи?

Ты никогда не слышал о том, что разработка программ - итеративный процесс?

>Ты никогда не слышал о том, что разработка программ - итеративный процесс?
В чём проблема?
Персональные бранчи не позволяю комитить код когда хочется?

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

>Базар - это ужас... Во всех смыслах этого слова...
Bazaar как раз самый вмеряемый из маргинальных VC

> Персональные бранчи не позволяю комитить код когда хочется?

Я делаю десятки коммитов за рабочий день (hg qref) %) Подавляющее большинство из них нафиг не нужны никому, кроме меня. Да, если я создам себе персональный бранч в SVN, я смогу коммитить тогда, когда нужно. Но в результате история проекта станет нечитаемым мусором.

Локальность коммита означает то, что ты можешь его редактировать, удалять, объединять несколько в один. Это очень удобно. Свобода делать коммит когда угодно меняет стиль работы.

> Ветвить svn будут гарантированно уметь не все.
И этот человек работает программистом :(

>Локальность коммита означает то, что ты можешь его редактировать, удалять, объединять несколько в один. Это очень удобно.
ок
я рад что вы нашли себе VC по душе.

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

>>Локальность коммита означает то, что ты можешь его редактировать, удалять, объединять несколько в один. Это очень удобно.

ок

я рад что вы нашли себе VC по душе.

Я не «нашел VC, который мне по душе», а описал инкрементальную разработку при наличии поддерживающей ее системы.

Тем не менее когда пользователь маргинальной VCS заявляет, что он будет нанимать кого-то на работу

Это понты же.

> Какие такие проблемы с merge? вы что все из сонсоли работаете?
Ну хорошо, будем считать, что Вы победили меня и здравый смысл, если опишете следующий сценарий в svn:
1. ответвляем Б от А
2. Б уехала на 2 коммита, А уехала на 2 коммита.
3. Нужно влить часть изменений ветки Б в А, оставив жить обе (подразумевается, что делать это нужно регулярно).

Кроме того кто мешает работать локально?

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

Вы судя по всему бранчами не научились пользоваться. Ну, не беда. Зато в полку пользоватетелей маргинальных VCS прибавление :)

Это как раз Вы демоснстрируете узость кругозора, пытаясь заменить теплое мягким. Ну и ко всему прочему, у Вас комплекс связанный со словом «маргинальный».

>Нужно влить часть изменений ветки Б в А, оставив жить обе
Выбираю изменения и добавляю туда куда нужно.
В чём проблема? Это ведь элементарная операция. В первых главах описано.

Нужно только Гуёвым клиентом пользоваться и всё очень просто.
просматриваегь конфликты, выбираешь что оставить.
Занимат время, если много изменений в одних и тех-же файлах из разных бранчей.

Ну и ко всему прочему, у Вас комплекс связанный со словом «маргинальный».

Хехе.
Это точно не у вас комплекс?
Если бы вас этого комплекса не было вы бы проигнорировали это предложение. А так да.
Останентесь в моей памяти как фанат маргинальных VCS

>описал инкрементальную разработку при наличии поддерживающей ее системы.
Ок.
Остановимся на том, что я лично не сталкивался с такой проблемой часто.
Возможно просто не не привык и соответственно не считаю это киллер-фичей.

Это понты же.

Это понятно.
Сам таким изредка страдал.
Но раздражает.

> Если бы вас этого комплекса не было вы бы проигнорировали это предложение. А так да.
О нет, вот именно такому комплексу в моей коллекции места не нашлось. Обратил внимание в контексте определения соционической квадры по точке агнста: боязнь «быть шестеркой» - вторая соционическая квадра.

>боязнь «быть шестеркой» - вторая соционическая квадра.
Ну вот вы и диагноз себе поставили.
Поздравляю!
Это первый шар на пути к выздоровлению.

Какие такие проблемы с merge?

Он не работает. Сколько раз я пытался мерджиться в svn столько же раз про2.71бывал важные коммиты. В hg я просто делаю hg pull/hg merge и всё происходит само, ни разу ничего не терялось.

вы что все из сонсоли работаете?

Естественно. Нафиг мне на локалхосте держать сорцы проекта, который работает только в специально настроенном unix-окружении ?

Кроме того кто мешает работать локально?

а как экспериментировать без сохранения истории?

Нахрен он нужен, если есть бранчи?

есть, но такие,что толку от них нет

На одной из своих работ я встречал людей, которые считали маргинальными VCS все что было отлично от VSS6.0 :)

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

Нафиг мне на локалхосте держать сорцы проекта, который работает только в специально настроенном unix-окружении ?

Не только Юникс но и Виндов и макос

есть, но такие,что толку от них нет

Может вам просто доки почитать?

Больной, не отвлекайтесь. Вы уже придумали набор команд, реализующий приведенный мной сценарий. Или все это время Вы обсуждали свой любимый плагин к IDE вместо svn-а?

Не только Юникс но и Виндов и макос

Я про сорцы над которыми я работаю удаленно по ssh.

Может вам просто доки почитать?

Каждый раз перед merge читал ман и каждый раз наступал на грабли. Вывод — merge не работает, а раз так, то и смысла в ветках нет.

Ну есть svn merge в котором надо указывать в определенном порядке страшные пути и номера ревизий. Малейшая ошибка и трындец всему :)

Ну у меня тоже получалось достичь состояния «трындец». Неожиданно-так получалось :)
Благо, это все в прошлом.

>Больной, не отвлекайтесь
Вот вы уже и сам с собой разговариваете :(

>Я про сорцы над которыми я работаю удаленно по ssh.
Да. Видел я такого кадра в штатах.
Логинился на продакшн сервер и там и редактировал исходники.
Я так не могу.

Каждый раз перед merge читал ман и каждый раз наступал на грабли.

Я уж не помню когда в ман лазил. Проблем нет.

Вывод — merge не работает, а раз так, то и смысла в ветках нет.

Это как дедуля у которого не стоит всем рассказывает что смысла в сексе никакого.

Логинился на продакшн сервер и там и редактировал исходники.

Для этого есть разработческие сервера с развернутой средой. Нафиг на локалхосте поднимать древний линух с кучей специфичного мусора?

Я уж не помню когда в ман лазил. Проблем нет.

Сравни push/pull и svn merge с туевой хучей аргументов. Нет, конечно это всё можно вызубрить и страшные пути и их порядок и номера ревизий куда и зачем писать ... но я так не могу.