LINUX.ORG.RU

Распределенная система управления версиями Git. Часть 1: Введение

 


0

0

Цель этой серии статей – познакомить читателя с принципами работы СУВ и подробно рассмотреть одну из них, а именно Git. В последнее время эта система набирает популярность, и ее важность для свободного ПО сложно переоценить.

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

Данная статья предполагает, что читатель знаком с Unix-подобными операционными системами (ОС), а также имеет базовые знания в области алгоритмики и информатики в целом.

В следующих материалах мы углубимся в структуру и философию Git, специфику этой системы и тонкости практической работы с ней. Завершит цикл статья о взаимодействии Git с другими СУВ (такими как Subversion, CVS, Mercurial и др.).

>>> Подробности

★★★

Проверено: maxcom ()

Ответ на: комментарий от ArsenShnurkov

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

azure ★★
()
Ответ на: комментарий от ArsenShnurkov

>Есть разница между
Есть только разница между человеком почитавшим документацию и не почитавшим.

anotheranonymous
()
Ответ на: комментарий от Gukl

быстрее и наглядней можно найти момент, начиная с которого были внесены изменения, которые вызывают проблемы

azure ★★
()

На редкость мутная статья. Я с git'ом не работал раньше, думал, хоть разберусь интереса для. Прочитав статью ничего не понял. Чем оно лучше того же SVN? Для несчастных с инетом по мопеду что ли?

anonymous
()
Ответ на: комментарий от anonymous

> Чем оно лучше того же SVN?
SVN это VCS, а git - DVCS.

Можно спокойно кодить и делать коммиты не подключаясь к интернетам (в дороге например), можно одной командой клонировать любой публичный проект и делать свой форк.
А потом можно сделать push если апстрим даст пермишены.
Можно начать вести свой проект локально, не ставя никаких серверов. А потом очень просто склонировать свой реп на один из публичных серверов предоставляющих хостинг гит репов.
Можно достаточно просто построить произвольную иерархию репозиториев, где не все коммитят в центральный реп, а в какие-то промежуточные, оттуда уже выше и т.д. (с ядром так примерно и сделано).
Это что касается различий VCS и DVCS навскидку. git vs hg vs bzr vs <another DVCS> это уже отдельный срач.

Nao ★★★★★
()
Ответ на: комментарий от ArsenShnurkov

>В генте для этого есть виртуальные пакеты (чтобы ставили вместе несколько других пакетов с нужными флагами), но к сожалению для git нормально пока не сделали (то, что есть, меня не устраивает.

Вы наверное путаете с мета-пакетами. Они есть практически в любом нормальном дистре.

но к сожалению для git нормально пока не сделали

а что нужно то? какие пакеты и юз флаги вы хотите?

Nao ★★★★★
()
Ответ на: комментарий от Nao

а что нужно то?


Замена SVN, чтобы с него можно было перейти

Идеальный вариант:
- настраиваю use-флаги (чтобы выбрать фичи)
- мержу 2 пакета (сервер и клиент) и получаю готовое решение со следующими фичами:

Обратите внимание - два пакета.
Например:
gitclient
gitserver
Не четыре, не восемь.
Или один общий пакет, если для установки на одной машине.
Например:
git

Сервер:
1) создан дефалтовый репозиторий (если не был установлен USE=«minimal»)
2) установлена графическая утилита миграции со всех других систем
3) установлена графическая утилита администрирования и бекапа (если установлен USE=«gnome»)
4) сервер должен быть доступен через HTTPS (если USE=«openssl»)
5) должны быть флаги для интеграции с основными web-серверами (apache, nginx)
6) сервер должен быть доступен через WebDAV для amaya и подобных приложений (если USE=«webdav»)
7) утилита администрирования должна давать возможность назначать права на элементы с точностью до папок и файла (а не только целиком на проект)
8) Дополнительные скрипты (например для синхронизации, для выкладки на web, для подсчета статистики (если USE=«extras»)

Клиент:
0) Присутствует отдельный консольный клиент (USE=«console»)
1) Присутствует отдельный графический клиент (USE=«GNOME»)
2) Присутствует интеграция в Nautilus (если USE=«nautilus»)
3) Присутствует интергация в соответствующие IDE (если USE=«eclipse», «monodevelop»)
и т.д.

ArsenShnurkov
()
Ответ на: комментарий от ArsenShnurkov

>gitclient

gitserver

Это одно и то же.

создан дефалтовый репозиторий (если не был установлен USE=«minimal»)

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

4) 5) 6)

Что-то очень много вам должны, не кажется? И какое отношение гит имеет к апачу, вебдаву и прочему?
В общем, требования предъявляются к тому, о чём вы не имеете понятия. Это не СВН.

Laz ★★★★★
()
Ответ на: комментарий от ArsenShnurkov

>2) установлена графическая утилита миграции со всех других систем
А такая утилита существует?

3) установлена графическая утилита администрирования и бекапа (если установлен USE=«gnome»)

Утилиты администрирования поставляются вместе с гитом, не знаю о чём вы конкретно. А зачем для бекапа какая-то отдельная утилита? можно же просто сделать git push на удалённый (бекап-сервер) реп. Или использовать внешние утилиты (что уже никак не входит в обязанности гита)

7) утилита администрирования должна давать возможность назначать права на элементы с точностью до папок и файла (а не только целиком на проект)

Кстати сам бы хотел узнать можно ли это сделать. И можно ли в git вообще.

Nao ★★★★★
()
Ответ на: комментарий от Laz

Обычно у разработчки несколько штук,

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


Вот он не обломается выставить флаг minimal

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

Баз данных обычно тоже много, а у mysql все равно есть опция создать примеры БД

ArsenShnurkov
()
Ответ на: комментарий от Nao

А такая утилита существует?


Если ее не существует - это недоработка разработчиков git

Утилиты администрирования поставляются вместе с гитом


Для гнома?

А зачем для бекапа какая-то отдельная утилита


Утилита одна. Для администрирования (раздачи прав) и бекапа (это такая функция этой утилиты).

можно же просто сделать git push на удалённый (бекап-сервер) реп.


Можно все самостоятельно на ассемблере закодировать.

что уже никак не входит в обязанности гита


Интеграция с другими приложениями входит в обязанности разработчиков. Потому что кроме них некому.

ArsenShnurkov
()
Ответ на: комментарий от Laz

Что-то очень много вам должны, не кажется?


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

И какое отношение гит имеет к апачу, вебдаву и прочему?


Я использую SVN в такой связке и хочу заменить на git

В общем, требования предъявляются к тому,

о чём вы не имеете понятия.


Не перестать ли Вам говорить за других - о чем какие понятия они имеют?

ArsenShnurkov
()

СТАТЬЯ ОТВРАТИТЕЛЬНАЯ.
<p>
Во-первых, она произносит кучу каких-то «умных» слов, но абсолютно НИЧЕГО НЕ ОБЪЯСНЯЕТ. Она не дает структуры, ни идеологии, как устроен Git, ни первого примера, после которого читателю можно объяснить большее.
<p>
Статья как дребезжание полуобразованца.
<p>
Лучше бы этот «свободный журналист» и «студент» перевел 1:1 одну из основных, лучших объяснилок с английского.
Он же либо сдирал с какой-то из худших объяснилок, либо пыжился сам, сделав мозаику как в новостях когда надо чтобы у зрителя не осталось целостного впечатления
<p>
Отвратительная работа, которая выделяется даже среди вполне бесполезных статей печатающихся под эгидой IBM на русском

anonymous
()
Ответ на: комментарий от ArsenShnurkov

>Вот он не обломается выставить флаг minimal

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

Баз данных обычно тоже много, а у mysql все равно есть опция создать примеры БД


Желающий освоить гит полезет читать туториал, где первая же команда - git init. Дальше идёт работа с этим репозиторием - редактирование, коммиты, клонирования итд. В любом случае нужно будет выполнять эти команды. И какой толк от автоматически создаваемого репозитория? И что в нём будет? Ничего?
Кстати, пример репозитория, который вы хотите создать, будет один на всех? Я имею ввиду, общесистемный? А что делать, если один пользователь «освоил» его (о том, как быть с правами на него, спрашивать не буду), а второй только собирается? Зайдёт, значит, в пример репозитория, а там уже «освоено». Удалять всё?

Laz ★★★★★
()
Ответ на: комментарий от ArsenShnurkov

>Мне не кажется, я рассказываю, что бы я хотел,
Замечательно. Осталось воплотить эти желания в жизнь - $EDITOR git.ebuild и вперёд.

Я использую SVN в такой связке и хочу заменить на git

В составе гита есть всё необходимое для публикации его в вебе, используя webdav или cgi. Документация по настройке тоже есть. Но какой репозиторий публиковать? Особенно когда у каждого пользователя их несколько. Тот самый, который создаётся в качестве примера? Отличная идея.

Не перестать ли Вам говорить за других - о чем какие понятия они имеют?

Я говорю не за других, а о других. Не нравится моё мнение - опровергните.

Laz ★★★★★
()
Ответ на: комментарий от Laz

В любом случае нужно будет выполнять эти команды.


Вообще говоря с другими системами можно работать через графический интерфейс без команд.
Поэтому не в любом случае, а только при работе с ленивыми и самовлюбленными девелоперами из линукса.
Если девелоперы в Linux - идиоты, то да, другим пользователям больше ничего не останется (только голосовать ногами, что мы и видим, т.к. линукс занимает 1% рынка десктопов).
И пока девелоперов как следует не обосрешь, они свою точку зрения хрен поменяют. Поэтому у них нет и доли рынка и денег, только в качестве подачек от добрых людей в корпорациях.

Желающий освоить гит полезет читать туториал


Потом еще пять туториалов на соседние пакеты, и потом будет писать в форум «уже два дня копаюсь» (см. выше по треду). В то время как другой пользователь возьмет другую систему и быстро начнет с ней работать.

какой толк от автоматически создаваемого репозитория?


Возможность начать работать с клиентом не настраивая серверную часть.

И что в нём будет? Ничего?


И это правильно. VSS тоже пустым создается.

репозиторий, будет один на всех?


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

второй только собирается


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

Осталось воплотить эти желания в жизнь

- $EDITOR git.ebuild и вперёд.


Вот если Вам нужна какая либо услуга - например машину напрокат взять, вы руду сами идете добывать, и сами потом плавите, потом штампуете, собираете и обкатываете?
Про разделение труда слышали?

В составе гита есть всё необходимое для публикации его в вебе, используя webdav или cgi.


А HTTPS? А как он будет работать на одном порту с моим апачем - прийдется таки изучать документацию?

Документация по настройке тоже есть.


Я не говорю что документации нет, только она разрозненная и фрагментарная, как статья топикстартера

Тот самый, который создаётся в качестве примера? Отличная идея.


Да, в других продуктах так делают.

Не перестать ли Вам говорить за других - о чем какие понятия они имеют?

Я говорю не за других, а о других.

Ты говоришь о том,
какие именно я (а не другие) не должен предьявлять требования.
Так вот мне виднее, какие у меня требования.

Не нравится моё мнение - опровергните.


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

ArsenShnurkov
()
Ответ на: комментарий от anonymous

>Что-то IBM Developers Works сдавать начал. Почему они пропустили в >публикацию такой детский сад?Что-то IBM Developers Works сдавать >начал. Почему они пропустили в публикацию такой детский сад?

Присоединяюсь. IBM DW пора серьёзно задуматься над качеством статей. Последние просто смешны.

anonymous
()
Ответ на: комментарий от ArsenShnurkov

>> А такая утилита существует?

Если ее не существует - это недоработка разработчиков git

Для кучи действий в линуксе нет аналога/обёртки в GUI виде. Всё это недоработки? Я понимаю обычный юзер, а вот разработчику (на линуксе) не уметь работать в CLI это стыдно.

Для гнома?

Для гита. Если есть желание интегрировать с гномом то флаг вам в руки. Видимо это не очень востребовано среди разработчиков.

А зачем для бекапа какая-то отдельная утилита

Утилита одна. Для администрирования (раздачи прав) и бекапа (это такая функция этой утилиты).

Не надо мыслить так, как будто git должна выполнять абсолютно все функции svn один-в-один. Я знаю, вы подумали о svnadmin?
Про бекап это намёк на svnadmin hotcopy или svnadmin dump? ну в случае с гит просто сделайте копию репы через cp -r, или через git clone, всё.

можно же просто сделать git push на удалённый (бекап-сервер) реп.

Можно все самостоятельно на ассемблере закодировать.

Под каждую архитектуру и процессор?)
Не пойму в чём у вас возникла сложность при бекапе на удалённый сервер?

что уже никак не входит в обязанности гита

Интеграция с другими приложениями входит в обязанности разработчиков. Потому что кроме них некому.

Интеграция с чем? с tar? c rsync? с rdiff-backup? они прекрасно будут работать без всяких интеграций.

Мне не кажется, я рассказываю, что бы я хотел,

причем рассказываю не Вам и не по Вашему запросу.



Наверное по моему.
То что вы описали выходит далеко за рамки мета-пакета.

Если вам хочется чтобы все эти идеи воплотились в жизнь у вас есть три способа:
1)Написать самому
2)Заинтересовать сообщество
3)Заплатить деньги за реализацию
Причём способы можно сочетать.

Я использую SVN в такой связке и хочу заменить на git

Можно спросить - для чего?

Nao ★★★★★
()
Ответ на: комментарий от Nao

Я понимаю обычный юзер


Я обычный юзер. Мне в систему контроля версий текстовые документы из офиса складывать надо.

в чём у вас возникла сложность при бекапе на удалённый сервер?


В необходимости чтения документации.
При использовании Visual Source Safe Administration такой необходимости не возникает (там команда в менюшке и затем понятные подсказки)

Интеграция с чем?

Писал выше - http://www.linux.org.ru/jump-message.jsp?msgid=4483586&cid=4486222

То что вы описали выходит далеко за рамки мета-пакета.

Это почему? Не дистрибутив же из-за этого лепить?

у вас есть три способа


За два года мне это сказали более 50 раз. Чтобы заинтересовать сообщество мне минимум надо опубликовать мое предложение.

Можно спросить - для чего?


Была опубликована статья, решил оценить, что мне даст переход на новую «более правильную» систему.

ArsenShnurkov
()
Ответ на: комментарий от ArsenShnurkov

Я уже начал серьёзно отвечать на ваши посты, но этот пост показал вас во всей красе.

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

Если девелоперы в Linux - идиоты,


Зачем же использовать эту систему раз её разрабатывают одни самовлюблённые идиоты? Заставляют?

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

Вы считаете что вбросом говна вы что-то измените? Наивный вы человек.

Так вот мне виднее, какие у меня требования.

Вы думаете ваши требования здесь кого-то интересуют? Да и кому вы требования предъявляете-то? Разработчикам гита? Думаю тут мало таких. Идите и требуйте в мейл-листе гитовском то что вы хотите, они ваша целевая аудитория в данном случае.

Nao ★★★★★
()
Ответ на: комментарий от Nao

Я уже начал серьёзно отвечать на ваши посты,


Разным пользователям я отвечаю в разном стиле. Лично Вам - серьезно.

ArsenShnurkov
()
Ответ на: комментарий от ArsenShnurkov

>Я обычный юзер. Мне в систему контроля версий текстовые документы из офиса складывать надо.

Угу, и генту компилять на OpenMoko :) Взялись за серьёзные инструменты - извольте читать документацию.

При использовании Visual Source Safe Administration такой необходимости не возникает (там команда в менюшке и затем понятные подсказки)


Почему бы не использовать её если она вам нравится?

Это почему? Не дистрибутив же из-за этого лепить?

не дистрибутив, а новое ПО, допиливание старого и только в конце - создание такого метапакета.

За два года мне это сказали более 50 раз. Чтобы заинтересовать сообщество мне минимум надо опубликовать мое предложение.

Тут немного не та аудитория, уже писал выше.

что мне даст переход на новую «более правильную» систему.

Нет никаких «более правильных систем». У каждой софтины есть свои плюсы/минусы/особенности. Если для вас представляет сложность настроить всё это, то очевидно вам эта SCM не подходит.

Nao ★★★★★
()
Ответ на: комментарий от Nao

Если девелоперы в Linux - идиоты,

Зачем же использовать эту систему раз её разрабатывают

одни самовлюблённые идиоты? Заставляют?


Затем, что я надеюсь, что кроме них еще есть нормальные разумные люди. На лоре пока видел доих - KRoN73 и Silvy

ArsenShnurkov
()
Ответ на: комментарий от ArsenShnurkov

>Затем, что я надеюсь, что кроме них еще есть нормальные разумные люди. На лоре пока видел доих - KRoN73 и Silvy

А остальные самовлюблённые идиоты? :)
Вы действительно считаете что после таких постов люди захотят вам отвечать по теме?

Nao ★★★★★
()
Ответ на: комментарий от Nao

А остальные самовлюблённые идиоты? :)


Нет, это значит, что остальных я еще пристально не рассмотрел :)

ArsenShnurkov
()
Ответ на: комментарий от ArsenShnurkov

Спасибо за ссылку. Тот тред окончательно убедил меня в вашей неадекватности. Давно не юзал игнор, похоже придётся.

Nao ★★★★★
()
Ответ на: комментарий от ArsenShnurkov

Желающий освоить гит полезет читать туториал

Потом еще пять туториалов на соседние пакеты, и потом будет писать в форум «уже два дня копаюсь» (см. выше по треду). В то время как другой пользователь возьмет другую систему и быстро начнет с ней работать.

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

azure ★★
()
Ответ на: комментарий от ArsenShnurkov

>Вообще говоря с другими системами можно работать через графический интерфейс без команд.
Замечательно. Значит нужно будет нажимать на кнопку создания или клонирования репозитория. Это что-то меняет?

(Что-то про девелоперов-идиотов)

Этот абзац не понял, видимо что-то личное.

линукс занимает 1% рынка десктопов

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

Потом еще пять туториалов на соседние пакеты, и потом будет писать в форум «уже два дня копаюсь» (см. выше по треду). В то время как другой пользователь возьмет другую систему и быстро начнет с ней работать.

Если пользователю проще взять другую систему и начать с ней работать - пусть так и сделает. То, что пользователь дебил - это не проблема гита.

Возможность начать работать с клиентом не настраивая серверную часть.

Сколько можно повторять? В гите нет сервера.

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

То есть вы предлагаете, чтобы пользователи одновременно вносили свои изменения в одни и те же файлы в этом репозитории? И какой тогда смысл вообще использовать scm?

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

Из ебилдов? Ни разу не пробовал. Научите?

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

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

А HTTPS? А как он будет работать на одном порту с моим апачем - прийдется таки изучать документацию?

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

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

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

Я не говорю что документации нет, только она разрозненная и фрагментарная, как статья топикстартера

man git и /usr/doc/git . Чего-то не хватает?

Laz ★★★★★
()
Ответ на: комментарий от Laz

Вообще говоря с другими системами можно работать

через графический интерфейс без команд.


Замечательно. Значит нужно будет нажимать на кнопку создания или

клонирования репозитория. Это что-то меняет?


Да! Конечно меняет! Оно отображает наиболее нужные кнопки на наиболее нужном месте, эти кнопки видны сразу, они светятся и по ним есть подсказка на mousehover (локализованная). Это гораздо проще психологически, чем google + unknown keywords + 2 days of english text reading.

То, что пользователь дебил - это не проблема гита.

Ага, а то что Linux нужен только 1% - это не проблема линукса.

Сколько можно повторять? В гите нет сервера.

Модель OSI берем. Если что-то передается, значит есть два endpoint-а.
Если есть два, то они могут быть равноправными, а могут не быть равноправными. Меня интересует второй вариант. В моем случае центральный репозиторий я называю сервером. И мне удобнее думать так, даже если его можно использовать как клиента, я его поставлю на выделенную машину. И в нем больше объектов, т.к. не всем пользователям нужны все документы.

чтобы пользователи одновременно вносили свои изменения в одни и те же файлы в этом репозитории?


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

какой тогда смысл вообще использовать scm?


Чтобы вносили по очереди, а не одновременно и чтобы не портили то, на что нет прав.

Научите?


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

Два пользователя на одной машине работают.


В этом случае либо первый второго научит и будут пользоваться одной базой, либо соберут с флагом minimal и создадут две базы.

если, конечно, у вас нет волшебного гуя для апача,

который сам всё сделает


Хочу хотя бы ebuild

А вы, когда вам нужна какая-то услуга, например, машина напрокат,

вы ноете о том, как вам нужна машина,

да не любая, а чтоб с шахматами и гейшами?


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

man git и /usr/doc/git . Чего-то не хватает?


Да, у меня много пожеланий, что должно было бы быть в документации линукса и как она должна работать, но я пока не выписывал это в виде связного текста после обсуждения темы «итоги года 2009».

ArsenShnurkov
()
Ответ на: комментарий от azure

то становится понятным, что вы просто консерватор.


Это не так. Я не заявляю, что git хуже стратегически, я заявляю, что лично мне на текущий момент не хватает юзабилити.

ArsenShnurkov
()
Ответ на: комментарий от yoghurt

> Ну и чем оно лучше Mercurial?

Тем что нет несовместимостей в функциональностях, вынесенных в Mercurial в расширения.

anonymous
()
Ответ на: комментарий от anonymous

>> Ну и чем оно лучше Mercurial?

Тем что нет несовместимостей в функциональностях, вынесенных в Mercurial в расширения.

Например?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>>> Ну и чем оно лучше Mercurial?

Тем что нет несовместимостей в функциональностях, вынесенных в Mercurial в расширения.

Например?

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

В гите никакой откат репозитарий не ломает.

anonymous
()
Ответ на: комментарий от anonymous

>> нет несовместимостей в функциональностях, вынесенных в Mercurial в расширения.

Например?

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

В гите никакой откат репозитарий не ломает.

Про именованные ветки ХЗ, не пользуюсь (хотя жалоб в списках рассылки не припомню), а «откат» - это «hg rollback»? Тоже ни у самого не ломалось, ни в списках не жаловались. Если «откат» - это «hg strip», то да, бывало, но это был просто баг.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>>> нет несовместимостей в функциональностях, вынесенных в Mercurial в расширения.

Например?

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

В гите никакой откат репозитарий не ломает.

Про именованные ветки ХЗ, не пользуюсь (хотя жалоб в списках рассылки не припомню), а «откат» - это «hg rollback»? Тоже ни у самого не ломалось, ни в списках не жаловались. Если «откат» - это «hg strip», то да, бывало, но это был просто баг.

Это не был. Это есть. В сочетании hg strip и именованных веток легко получается не просто креш, а еще и убитый репозитарий.

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

anonymous
()
Ответ на: комментарий от anonymous

> В сочетании hg strip и именованных веток

Ты используешь голый hg strip? Не в виде mq, а вручную? O_O

Кстати, какой аналог hg strip в git?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

И таки да. Там были еще проблемы. Но без крешей репозитария, поэтому деталей уже не помню.

anonymous
()
Ответ на: комментарий от tailgunner

>> В сочетании hg strip и именованных веток

Ты используешь голый hg strip? Не в виде mq, а вручную? O_O

Кстати, какой аналог hg strip в git?

откат - хороший способ привести в порядок ветку. Не всегда решение о том что ветка в порядке и реальность совпадают. Поэтому mq вещь полезная но не покрывающая всей необходимой функциональности.

anonymous
()
Ответ на: комментарий от anonymous

> откат - хороший способ привести в порядок ветку.

Ты первый человек, который называет strip «откатом» :)

Поэтому mq вещь полезная но не покрывающая всей необходимой функциональности.

Если ветка изначально велась в mq, то там есть вся необходимая функциональность. Если ветка не веласть в mq, проблема решается hg qimport -r N :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> откат - хороший способ привести в порядок ветку.

Ты первый человек, который называет strip «откатом» :)

Так проще :)

Поэтому mq вещь полезная но не покрывающая всей необходимой функциональности.

Если ветка изначально велась в mq, то там есть вся необходимая функциональность. Если ветка не веласть в mq, проблема решается hg qimport -r N :)

По завершении все равно лучше обычную ветку продолжить. Выполнение этого решения и необходимость снова что-то поправить предполагает необходимость отката.

Вообщем и так все понятно. Можно сказать что это не нужно. Сказать можно, но это совсем не значит что не нужно. Вон при нормальной реализации веток в git'е долгое время думали нужен ли аналог. И так все номрально работало. Потом все же решили, что текоторые варинаты использования становятся существенно более логичными. Так же и с откатом.

anonymous
()
Ответ на: комментарий от anonymous

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

Таки hg qimport -r. А hg strip всегда была низкоуровневой командой класса «I know what I'm doing».

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

Таки hg qimport -r. А hg strip всегда была низкоуровневой командой класса «I know what I'm doing».

Долго и муторно, если надо опечатку поправить. Но не в этом суть.

Да hg strip - низкоуровневая. git reset - то же. hg strip - глючит с именоваными ветками так что базу ломает. git reset - вообще не глючит. Без hg strip и именованных веток функциональность становится меньше чем у git. Так что git фичастнее. Глюки говорят о качестве, так что git качественне. Выбор очевиден.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.