Однажды я стал свидетелем обсуждения этой темы. Коллеги обсуждали тот самый сайт и пришли к выводу, что «меняем шило на мыло».
В этом диалоге я был невольным слушателем, но что там за сайт и его аргументы меня заинтересовали. Пошел разбираться.
Начнем с первого заявления
Git repositories are significantly smaller than equivalent Subversion ones
False. A myth.
The particular delta compression algorithms used in both version control systems differ in many details, but in general Subversion and Git store data in the same way. This results in the fact that Subversion and Git repositories with equivalent data will have approximately the same size. Except for the case of storing a lot of binary files, when Subversion repositories could be significantly smaller than Git ones (because Subversion’s xdelta delta compression algorithm works both for binary and text files).
Ниже есть пример, где они сравнивают размер репозитория. Вывод – разница не существенна.
Меня смутило различное число коммитов, и фактически разные первоисточники(кто знает, как они там синхронизируют эти репозитории). Так же меня не устроил уровень детализации описания процесса получения этих чисел.
Итак, начнем свой эксперимент!
Получаем svn репозиторий
svnrdump.exe dump https://core.svn.wordpress.org/ > svndump
svnadmin create svn
svnadmin load svn < svndump У нас локальная копия всего репозитория в формате svn. Это папка размером 213 МБ, которая содержит 79758 файлов и 88 папок.
На этот момент в репозитории насчитывается 39864 коммита. Рабочая копия проекта состоит из 1701 файла и 160 папок.
Начинаем миграцию в гит
git svn clone -s --prefix "svn/" file:///%path%/svn git_from_svn Этот этап был самым длительным, затянулся более чем на сутки (примерно 32 часа). В результате имеем git репозиторий — копия оригинального svn репозитория(не совсем копия, но для нас различия не существенны).
Здесь я сделал небольшую глупость, стоило бы создавать репозиторий без рабочей копии, но еще раз ждать более суток я был не готов.
Итак, папка git_from_svn/.git: 208 МБ содержит 7841 файлов и 509 папок. На данном этапе действительно можно говорить о незначительном перевесе в пользу git, видимо как раз на этом этапе и остановились те, кто ведет сайт. Но ведь у гита есть 2 формата хранения: “loose” object и “packfile".
Посмотрим, что же мы имеем:
git count-objects -v -HРезультат:
count: 6826
size: 30.21 MiB
in-pack: 249852
packs: 25
size-pack: 145.51 MiB
prune-packable: 73
garbage: 0
size-garbage: 0 bytes
То есть у нас есть множество пакетов и 6826 (30.21 МБ) не сжатых объектов.
Оптимизируем хранение
git gc
git count-objects -v -HРезультат:
count: 0
size: 0 bytes
in-pack: 256605
packs: 1
size-pack: 104.54 MiB
prune-packable: 0
garbage: 0
size-garbage: 0 bytes
Размер самой папки ".git" получается 136 МБ(945 файлов, 255 папок). Мне кажется такое преимущество уже сложно назвать незначительным.
Еще подчистим
Но и это еще не все, если избавиться от наследия svn — пушнуть это все в bare репозиторий получаем еще интересней картинку: 106 MБ, 19 файлов, 8 папок.
Соберем все вместе
svn — 213 MБ (79 758 файлов, 88 папок)
svn(после pack) — 214 MБ (4 644 файлов, 89 папок) (дополнение после публикации)
git svn — 208 MБ (7 841 файлов, 509 папок)
git svn(pack) — 136 MБ (945 файлов, 255 папок)
git bare(pack) — 106 MБ (19 файлов, 8 папок)
Мне кажется на этом этапе развенчивание мифа можно считать развенчанным(утверждение на сайте опровергнуто).
Еще стоит упомянуть, что loose объекты у вас все же будут, предназначены они для повышения производительности работы с часто используемыми файлами. Обычно в таком формате будут храниться файлы из веток, в которых сейчас активно идет работа. Их количество можно регулировать через конфигурационные файлы.
Идем дальше
Branches are expensive in Subversion
False. A myth.
Branches in Subversion are implemented with Copy-On-Write strategy (referred to as ‘Cheap Copies’ in the svnbook). No matter how large a repository or project is, it takes a constant amount of time and space to make a branch. In fact, Subversion branches are extremely cheap beginning with version 1.0 and you can branch even for small bugfixes in a very busy and large project.
И эксперимент это «подтверждающий».
Вывод – создание бранчи происходит быстрей чем вы глазом моргнуть успеете. Мне показалось, что если вся операция занимает меньше 0,01 секунды то тут и сравнивать нечего. Но почему-то на заявление о дороговизне бранчей в svn, сайт проверил только их создание. Но есть другие операции, например клонирование( или svn checkout). В этом эксперименте все происходит локально, возможное влияние сети исключено.
Первый эксперимент – клонирование
svn checkout %local_path%/trunkTotalSeconds: 14.0737539
git clone %local_path%TotalSeconds: 21.8173709
Git проиграл. Но здесь стоит учесть, git получил всю историю, а svn — одну ревизию.
Второй эксперимент – смена бранчи
svn switch <local_path>/branches/4.7TotalSeconds: 4.3741352
git checkout -B "4.7" "origin/4.7"TotalSeconds: 1.2700857
Здесь все наоборот, при этом на одном переключении мы отыграли половину от потери при клонировании.
На этом я пожалуй закончу. Пойду обсуждать эти результаты с сотрудниками.
PS: Несмотря на то, что посыл этой заметки банален «не стоит доверять непроверенным источникам в интернете», но, оказывается, есть еще люди, не развившие достаточный уровень здорового скептицизма.
Спасибо за внимание!
Update:
В комментариях VBKesha упомянул, что не плохо бы сделать svnadmin pack.
svnadmin.exe pack svn214 MB (4,644 Files, 89 Folders)
Помогло только с количеством файлов, объем незначительн вырос.
Комментарии (242)
oYASo
28.01.2017 22:09+7Какие вообще сегодня могут быть преимущества в использовании svn по сравнению с остальными vcs? Время клонирования (при котором гит еще и выкачивает 100% репозитория, в отличии от)? Ну это смешно.
selivanov_pavel
28.01.2017 22:30+13Одну назову — возможность дать доступ только к определённым подпапкам в репозитории. Гит такого не может архитектурно — или всё, или ничего. Редкий юз-кейс, но возможный.
Второе — гит всё-таки надо осваивать. Не бог весть какая rocket science, но если системой контроля версий пользуются не айтишники и возможностей svn им хватает — зачем заставлять людей тратить время и силы на непрофильные вещи?oYASo
29.01.2017 03:10+3Одну назову — возможность дать доступ только к определённым подпапкам в репозитории. Гит такого не может архитектурно — или всё, или ничего. Редкий юз-кейс, но возможный.
subtree позволяет вытащить любую папку, из которой потом можно сделать отдельный репозиторий. Мало того, это не просто даст доступ к папке, а также можно будет получить все историю изменений в этой папке.
Второе — гит всё-таки надо осваивать. Не бог весть какая rocket science, но если системой контроля версий пользуются не айтишники и возможностей svn им хватает — зачем заставлять людей тратить время и силы на непрофильные вещи?
Ну 95% использования git — это 5 команд. На моей практике осваивали даже люди около пенсионного возраста.
Тем не менее, заставлять, наверное, смысла нет. Но вот начинать новые проекты на svn — кощунственно.
ctacka
29.01.2017 03:43subtree, как я понимаю, сначала должен вытащить весь репозиторий, и только потом вытащить из этого папку. subtree нельзя сделать без fetch.
oYASo
30.01.2017 03:28-1Человек спрашивал — как сделать доступ к отдельной папке. Вот я предложил: вытащить subtree нужную папку и сделать из нее отдельный репозиторий. Дальше уже можно дать юзеру к ней доступ, пусть пишет код.
Ваш кейс, ясное дело, не будет работать, потому что subtree split пробегается по всем коммитам и ищет такие, которые затрагивают нужную папку. Тут вопрос, зачем это вам.
areht
29.01.2017 03:43-7> Ну 95% использования git — это 5 команд.
Это миф. Если использовать только эти 5 команд — гите нет смысла.oYASo
30.01.2017 03:30Ну если вы не можете организовывать и поддерживать порядок в своем репозитории, то ясное дело.
areht
30.01.2017 03:40Я ещё и код с ошибками пишу.
Кстати, а перечислите эти 5 команд?oYASo
30.01.2017 04:20-2commit, pull, push, merge, branch
git flow можем посчитать за одну команду.
Ну ок, еще сюда можно вписать add, rebase, diff, log, хотя этого можно и не знать, используя какое-либо gui.areht
30.01.2017 04:57+2> хотя этого можно и не знать, используя какое-либо gui.
С Gui я могу и первые 5 не знать.Но надо изучать guioYASo
30.01.2017 05:51Первые 5 команд — это фундамент всего git. В конце-концов, даже при общении с коллегами приходится говорить «ты запушил изменения?», «ща сделаю коммит и...», «смерж ветки» и прочее. Можно и в gui все делать, ок, ну надо понимать, что происходит. И, как я уже говорил, с этой задачей и бабушки справляются.
areht
30.01.2017 12:05> И, как я уже говорил, с этой задачей и бабушки справляются.
Напомните, в чём именно вы хотите меня убедить? О способностях бабушки я точно не упоминал.oYASo
30.01.2017 16:53Вас — ни в чем. А если другие люди будут читать тред, то, возможно, найдут здесь какие-то ответы на вопросы.
areht
30.01.2017 17:01-1Ок. Я так и подумал, что вы предпочитаете сами с собой.
«Потому что проект может состоять из десятков и сотней модулей» тоже на мой вопрос не отвечает никак.
kk86
29.01.2017 09:06+4Про 95% — чистая правда, но не все это понимают. Недавно пересаживал одну команду с архаики SVN на Git. БОльшая часть команды осваивала постепенно с базовых 5 команд к чему-то поумнее, типа cherry-pick, rebase [-i], и так далее. Но были и люди, которые привыкли учить что-либо "наскоком и целиком", как по учебнику. Вот они страдали больше, потому что learning curve выглядел для них хуже...
aikixd
29.01.2017 13:08Берите SourceTree. Настроить репу нужно руками будет, но коммиты и ветки очень удобно делать.
DrLivesey
29.01.2017 14:54Мое мнение о SourceTree для Git здесь.
oYASo
30.01.2017 03:34Нет под никсами.
Одно время был жутко тормозной, как сейчас — хз.
Лично я юзаю консоль и SmartGit. Еще хотел поюзать gitkraken, но что-то он у меня с ходу не взлетел, а дальше я забил. Но уж много времени прошло, можно его и еще раз потыкать.
VMichael
30.01.2017 12:28Это напоминает осваивание некоей гимнастики или единоборств.
Пока не освоишь простые движения, не стоит переходить к сложным.
Такая аналогия возникает.
И это же говорить о сложности системы под названием GIT.
Освоение требует больших сил.
Оправданны ли затраты, не знаю.
Убедительного ответа не прозвучало.
Большинство ответов похоже на спор верующих, о том, чья религия лучше, без примеров.
EaE
29.01.2017 16:03+2Ну 95% использования git — это 5 команд
«Привет, добро пожаловать в команду! Мы используем git-flow, вот ссылка на <те самые 5 команд, только во flow>. Все просто, вот эта ветка — девел, вот эта — мастер, вот тебе тикет на фичу, давай запили!»
git flow feature start, денек покоммитались, git flow feature finish, все красиво как на гламурной фотке в журнале… «ого, уже готово? отлично! слушай, это короче не могет ждать до следующего релиза, секурити риски, все такое, зафигачь это хотфиксом в мастер?»
Приплыли.
P.S. разумеется это решается, о да. Но нет, это вовсе не 5 команд.
selivanov_pavel
29.01.2017 16:36+2> subtree позволяет вытащить любую папку, из которой потом можно сделать отдельный репозиторий
subtree по гибкости раздачи прав и сложности использования сильно отстаёт от нормальных прав на файловой системе: во-первых, только папки, отдельные файлы нельзя; во-вторых, если в проекте появился новый файл с ограниченным правами доступа, достаточно сделать chown/setfacl, а не заморачиваться с заведением целого нового репозитория.
> Начинать новые проекты на svn — кощунственно
Кощунственно не использовать самый подходящий для конкретной задачи инструмент. Гит безусловно хорош, я сейчас только им и пользуюсь. Но стоит понимать, что в некоторых юз-кейсах он проигрывает svn. Кстати, посмотрел на упомянутый в статье svnvsgit.com и нашёл ещё один: работа с файлами по модели " Lock-Modify-Unlock".oYASo
30.01.2017 03:48subtree по гибкости раздачи прав и сложности использования сильно отстаёт от нормальных прав на файловой системе: во-первых, только папки, отдельные файлы нельзя; во-вторых, если в проекте появился новый файл с ограниченным правами доступа, достаточно сделать chown/setfacl, а не заморачиваться с заведением целого нового репозитория.
Наверное, есть где-то этот мир с единорогами, вечной радугой и гибкой раздачей прав на отдельные файлы в репозитории, но я его никак принять и представить не могу. Что будет делать пользователь с правами на три сорца, раскиданного по всему проект, для меня загадка. Как он будет что-то проверять, тестировать, кто потому это будет вливать и нести ответственность — для меня еще большая загадка.
о стоит понимать, что в некоторых юз-кейсах он проигрывает svn.
Этот тред начался с того, что я спросил, цитирую: «Какие вообще сегодня могут быть преимущества в использовании svn по сравнению с остальными vcs?». А вы мне говорите — в некоторых юз-кейсах git проигрывает svn. Я снова возвращаю к своему вопросу — в каких? :)
работа с файлами по модели " Lock-Modify-Unlock"
Вы серьезно что ли или троллите? Если серьезно, то у меня грустные новости — вы вообще не понимаете, как работает git. Тогда я не удивлен вопросам с непониманием перехода с svn на git.
entomolog
30.01.2017 08:30+2А чем вас потребность в " Lock-Modify-Unlock" так удивляет? Очень часто в репозитории приходится хранить не только текстовые файлы. Вот вам реальный пример из жизни: исходники флэша (.fla), текстуры (psd, tga), файлы 3ds max'а и еще куча всего остального. Поставил лок на файл, и спокойно его редактируешь и не волнуешься, что придется делать заново потому что кто-то успел закоммитить раньше.
DrLivesey
30.01.2017 10:49-2Если одну и ту же текстуру или модель редактируют 2 и более человека одновременно, то это неправильная организация рабочего процесса или неправильное разделение на файлы.
vintage
30.01.2017 14:04Так расскажите же как правильно.
DrLivesey
30.01.2017 15:111. Действительно ли нужно, чтобы несколько человек редактировали одну текстуру или модель одновременно? Чем это обусловлено?
2. Можно ли разбить текстуру или модель на логические куски и в случае модели иметь один файл, который бы через ссылки собирал все воедино?vintage
30.01.2017 21:53+2- Нужно-то как раз, чтобы несколько человек не редактировали одну текстуру одновременно, для чего и используются блокировки.
- В идеальном-то мире всегда можно, а в реальном как-то не всегда получается.
DrLivesey
30.01.2017 23:22-4Ставлю минус в комментарий за первый пункт.
Такие вопросы должны решаться тем, кто распределяет задачи по конкретным исполнителям а не системой контроля версий.
Чем должен заниматься человек, если он получил (или дошел) до задачи, требующей редактирования какой-нибудь конкретной модели, а файл залочен?
Второй пункт всегда в силе ибо время, деньги first to market.vintage
31.01.2017 06:33+4И почему вы считаете, что человек с этой задачей справится лучше программы?
Если файл заблокирован, то человек может либо заняться другой задачей, не требующей доступа к этому файлу, либо пойти к тому, кто его заблокировал и обговорить какие изменение тот вносит, когда закончит и не может ли он сразу же внести и необходимые первому изменения.
DrLivesey
31.01.2017 11:40-4И почему вы считаете, что человек с этой задачей справится лучше программы?
Если мы говорим о распределении задач, то для этого и существуют менеджеры разных звеньев со своей областью ответственности. Когда программы будут заниматься менеджментом лучше людей профессия исчезнет сама собой.
Мне кажется, что менеджмент ресурсов и задач — не та задача, которая решается системой контроля версий по определению. Поэтому вменять гиту, что в нем нету локов на файлы потому что менеджер не проследил за ситуацией или менеджера нет вообще — несколько странно.vintage
31.01.2017 23:35+1Вы когда-нибудь слышали про скрам, канбан и прочий аджайл, где менеджеры если и нужны, то только "на подхвате"?
VolCh
01.02.2017 10:51+2В скраме ещё хуже с этим. Там команда самоорганизованная, что означает что в одновременном редактировании одного бинарного файла без локов виноват минимум один из редактирующих, а то и все и тимлид в придачу — не сумели самоорганизоваться.
DrLivesey
01.02.2017 12:27Про аджайл я слышал, но не работал по нему, однако если мне не изменяет память, то есть ежедневные митинги, на которых каждый рассказывает, чем занимается сегодня.
Если все друг друга слушают, то выявить конфликт задач не составляет труда и поговорить до того как лок файла понадобится как инструмент разруливания конфликта.VolCh
01.02.2017 13:15Если все друг друга слушают
Я же говорю, если конфликт произошёл, то все виноваты, а не один менеджер :)
А если серьёзно, то не всегда при составлении планов ты точно знаешь какой-файл будешь трогать в ходе запланированных задач, а бывают задачи и незапланированные.
selivanov_pavel
30.01.2017 12:25+4> Что будет делать пользователь с правами на три сорца, раскиданного по всему проект, для меня загадка
Легко: репозиторий — какой-нибудь ansible или puppet. Файлики ssl_prod.pem и db_crypt_data_prod.key должны читать только админы, а ssl_dev.pem и db_crypt_data_dev.key — также программисты и тестировщики, чтобы наливать девелопмент и тестовые среды. А если роли шарятся между проектами, то db_crypt_data_prod.key должны читать только админы соответствующего проекта.
> А вы мне говорите — в некоторых юз-кейсах git проигрывает svn. Я снова возвращаю к своему вопросу — в каких? :)
Думайте шире. VCS применяются не только для разработки ПО с помощью редактирования кучи тесктовых файлов. Дизайнеры с *.psd, разные конструкторы/инженеры со своими специфичными CAD-ами, любые другие люди, чьи результаты труда храняться в бинарном виде.
> Вы серьезно что ли или троллите? Если серьезно, то у меня грустные новости — вы вообще не понимаете, как работает git
Я как раз понимаю как работает git, и понимаю, что «Lock-Modify-Unlock» он не может в принципе. Это не лучший воркфлоу для разработки ПО, но для специфичных юз-кейсов или для других задач(см. выше) он может очень даже подходить. Ну вот например не позволяет какой-нибудь схемотехнический CAD мёржить файлы описания плат, а одной платой два человека одновременно не занимаются, так у них построен рабочий процесс. Они сидят в SVN-е, лочат файлики и счастливы.
grossws
30.01.2017 16:42Легко: репозиторий — какой-нибудь ansible или puppet. Файлики ssl_prod.pem и db_crypt_data_prod.key должны читать только админы, а ssl_dev.pem и db_crypt_data_dev.key — также программисты и тестировщики, чтобы наливать девелопмент и тестовые среды. А если роли шарятся между проектами, то db_crypt_data_prod.key должны читать только админы соответствующего проекта.
Вариант "не хранить ключи и пароли в репозитории" не рассматривается?
В остальном (use case "svn как версионное хранилище артифактов") согласен.
selivanov_pavel
30.01.2017 16:48> Вариант «не хранить ключи и пароли в репозитории» не рассматривается?
А почему бы и нет, если с безопасностью репозитория всё не хуже, чем на продакшн-серверах? А скорее лучше, потому что доступен только из корпоративной сети и VPN. Ну то есть всё равно конечно дополнительная поверхность атаки, но если админы/безопасники считают это приемлимым, то почему бы и нет.grossws
30.01.2017 16:54Мне сходу видятся следующие проблемы:
- сложность отзыва доступа (например, увольнение сотрудника: невозможно обеспечить недоступность закрытого ключа, т. к. он лежит в локально копии репозитория у этого сотрудника);
- отсутствие аудита доступа к ключевой информации (невозможно отследить как и куда копировался ключевой материал).
Но в некоторых пределах, конечно, рабочая схема, спорить не буду.
Alexeyslav
30.01.2017 12:33Речь, как я понял, идёт о главном репозитории в отдельные части которых изменения могут делать только определённые люди. Причем у себя на локальном репозитории можешь менять любые файлы, а вот закоммитить изменения в чужих файлах нельзя. Разделение зон ответственности и всё такое. в GIT-е такое настроить сложно, если вообще возможно — у него же все репозитории равноправны и нет какого-то главного, а стало быть они все должны обладать одинаковыми свойствами.
grossws
30.01.2017 16:50GIT-е такое настроить сложно, если вообще возможно — у него же все репозитории равноправны и нет какого-то главного, а стало быть они все должны обладать одинаковыми свойствами.
Это не так. И исходно было не так для того же linux'а. Существование blessed репозиториев вполне себе объективная реальность.
Вообще авторизация при работе с git'овыми репозиториями штука внешняя по отношению к git'у. Тот же gitolite (а ранее gitosis) позволяют относительно гибко работать с правами: защитить отдельные ветки/теги (начиная от push, заканчивая force push/create/delete операциями) в разрезе по пользователям/группам. Тот же gerrit (который уже управление code review) ещё более гибок и тяжел для нормального пользователя. Как промежуточный вариант — github/gitlab, которые позволяют управлять мержем pull request'ов по выбору владельца репозитория (или лиц к нему приравненных в рамках этих операций).
ctacka
30.01.2017 23:45+2Ну вот юзкесы — хранение бинарных файлов. Например, мы храним картинки. Или тестовые данные. Тут сразу несколько недостатков git:
- нельзя залочить файл (а бинарники смерджить нельзя)
Два дизайнера пошли поменять одну картинку, и теперь работа одного из них пропадет. - необходимо вытягивать весь репозиторий, даже если нужно поменять один файл
Например, для смоук-тестов мы хотим брать только 5% тестовых данных. Или заранее подобранные для нужных тестов, тесты храним по папкам с id теста. Или дизайнеру надо поменять только иконочки, но ему придется вытянуть и фотографии. - невозможность просто раздачи прав на папка
— В разных папках разные виды картинок. Там, где 18+, доступ только для женатых.
— Там, где в тестовых файлах есть персональные данные — доступ только для подписавших бумажку.
- нельзя залочить файл (а бинарники смерджить нельзя)
shoorick
29.01.2017 17:01+1Когда начало нового проекта сводится к созданию на рабочем сервере коммита с папками projectname/{brancher,tags,trunk}, добавлению проекта в редмайн и копированию настроек хранилища из соседнего проекта — почему бы нет? Работает же.
Опять же, монотонно возрастающие целые номера коммитов в SVN как-то приятнее выглядят, чем гитовские хэш-суммы.oYASo
30.01.2017 03:53Честно говоря, я по первому абзацу мысль не уловил. Если я правильно понял, то гитом еще проще: git init и вперед, репа готова.
Ну про возрастающие коммиты — это, конечно, аргумент :)
areht
29.01.2017 03:33+2Почему вы думаете, что иметь один репозиторий, давая доступ к его части лучше, чем иметь 2 репозитория?
ctacka
29.01.2017 03:51+1В некоторых случаях это лучше. Активно работать одновременно с двумя репозиториями в одном проекте в git-е не очень-то удобно, если честно.
areht
29.01.2017 04:25-1Одном проекте? А почему вы хотите кому-то показать только часть проекта?
ctacka
29.01.2017 04:43+3Ну могут быть причины.
Например, у меня может быть часть проекта на аутсорсе (UI например), а IP в остальной части проекта. И я не хочу, чтобы вьетнамский фронтендер-фрилансер имел доступ к коду, реализующему мое конкурентное преимущество.
Или я хочу дать дизайнерам возможность force push-ить их кратинки, но чтобы они случайно не убили важный код.
Неужели вы думаете, что таких причин быть не может?areht
29.01.2017 05:24> Неужели вы думаете, что таких причин быть не может?
Что вы, я уверен, что у людей есть причины на любые глупости.
Но недостатком Гита будет не тогда, когда «а вы на шкаф залезьте», а когда идеология(и, в меньшей степени, реализация) не позволят решить бизнес-задачу.
Мне, например, кажется логичным или использовать репозиторий фрилансера как Submodules, или переносить в проект работу фронтэндера в рамках «приёмки» своими силами. А не давать физически публичный доступ к IP — парольная защита никогда не была идеальной, тем более на неё нельзя полагаться в каком-нибудь SVN, где это далеко не core-функционал.
Jef239
29.01.2017 14:27А как вы отличаете одно от другого? :-) Submodules работает без подводных камней? Мы как-то в своей время погуглили и забоялись и использовать.
areht
29.01.2017 14:34-3Примерно так:
Если у вас проблема с правами на подпроект фрилансера, то это проблема у вас.
Если у вас проблема с Submodules, то проблема у гита
> Submodules работает без подводных камней?
Да всё в этой жизни работает не без подводных камней :(Jef239
29.01.2017 15:31Ну идеология GIT — один репозитарий — один набор прав. А это входит в противоречие не только с бизнес-логикой, но и с чисто-программистскими реалиями. Потому что на каждую библиотеку — свой набор мейтейнеров.
Да всё в этой жизни работает не без подводных камней :(
А вот это было бы интересно почитать.areht
29.01.2017 15:45+1> Потому что на каждую библиотеку — свой набор мейтейнеров.
и свой репозиторий. И Submodules.Jef239
29.01.2017 16:03Свой репозитарий — само собой. А вот сабмодули…
- я правильно понимаю, что они сидят как подкаталоги? И система сборки должна быть настроена именно на такое расположение путей?
- я правильно понимаю, что при N проектах получится N копий каждого сабмодуля на диске?
- Какие ещё есть подводные камни?
areht
29.01.2017 16:28Вряд ли я вам поведаю подробнее https://git-scm.com/book/en/v2/Git-Tools-Submodules
> при N проектах получится N копий каждого сабмодуля на диске?
Можно попробовать сделать directory junctoin, или на подмодуль, или на .git подмодуля. Но это вручнуюJef239
29.01.2017 17:25Ну вряд ли создатели git будут писать о подводных камнях. А потерпит ли subversion симлинки — это вопрос. Ведь тогда один каталог будет принадлежать сразу нескольким репозитариям.
ctacka
30.01.2017 01:49+3Ну зачем вы говорите неправду? Использовать активно разрабатывающуюся библиотеку как submodule очень неудобно. Просто катастрофически. По сути, вам надо на каждый коммит в библиотеку делать коммиты во все активные бранчи основного репозитория. Автоматизация тут слабо помогает, потому что проблема не в том, чтобы коммиты делать, а в том, что ваш код начинает ломаться постоянно. Решение, конечно, не в svn, но зачем же давать вредные советы?
areht
30.01.2017 02:13-21) Так у них и так ломается, и так ломается. Как вы то предлагаете?
2) Это из серии «назвался груздем — полезай в кузовок». Если нужна отдельная, но активно разрабатывается библиотека, — надо под это workflow подгонять, что бы не комитить каждый раз все бранчи.
nick_volynkin
30.01.2017 08:03+2Смотрите: библиотека — это зависимость. Обновление зависимости нужно поддерживать (если интерфейс поменялся) и обязательно тестировать (потому что могло поменяться что-то внутри). Поэтому очень логично, что пока вы сознательно и явным образом не перешли на новый коммит библиотеки, ничего менять не нужно.
Работал тестировщиком на проекте на C++ с кучей зависимостей в субмодулях. Всегда было так, что обновление библиотеки — это интеграция, под которую выделяется время на разработку и тестирование.
Jef239
29.01.2017 14:21Не сколько показать, сколько дать разные права доступа.
Есть N проектов на K конфигураций железа. Соответственно есть N прикладных частей, есть общая прикладная библиотека, есть K аппаратных частей и общая аппаратная библиотека. И все это имеет разные права доступа для разных программистов.
А несколько репозитариев — и впрямь морока. И более менее регулярные проблемы от того, что при рефакторинге надо обновить все затронутые им репозитарии. А если забыл git pull на одном из 10 репозитрариев сделать- «ты фигню сделал, у меня не собирается».areht
29.01.2017 14:28Я правильно понимаю, что у вас один файл в нескольких репозитариях?
Jef239
29.01.2017 14:32конечно, неправильно.
areht
29.01.2017 15:10-1То есть у вас N*K частей, к каждой (зачем-то) свои права, но вы рефакторите вы все кусочки одновременно и регулярно?
Я бы даже на SVN не стал при такой связности так с правами морочиться…Jef239
29.01.2017 15:17Ну не все… Но если библиотека меняет API, то идут синхронные изменения во всех частях, где этот API вызывался.
А частей (репозитариев) у нас примерно N+K+M, где M — число библиотек.
У каждой части — есть ответственный, он и определяет у кого какие права.
А ваше решение с правами? Разрешить всем всё?areht
29.01.2017 16:15Ну может и всем всё, или 2-3 группы (железо, прикладники). Думаете все побегут в чужие части комитить в рабочее время? Или важно, что бы программисты одной аппаратной части не подглядывали код другой?
> Но если библиотека меняет API, то идут синхронные изменения во всех частях, где этот API вызывался.
Если у вас изменения в N модулях происходят синхронно, я не уверен, что «ответственный» — ответственный. Он может наложить вето на ваши правки? Он вообще в курсе, что что-то поменялось?
Вы, перед рефакторингом, ходите и получаете права на 10 частей у каждого ответственного? И остальным, скорее всего, не надо. Остальные сделают фигню — получат то же «ты фигню сделал, у меня не собирается».
На мой взгляд, надо или ответственность вернуть ответственным (пусть сами обновляют после обновления библиотеки, асинхронно), или с правами перебор (не надо решать организационные проблемы техническими средствами)Jef239
29.01.2017 17:47Важно, чтобы у каждой части был ответственный. И он сам раздавал бы права, кого и в какие ветки он пускает. Тогда количество конфликтов (людских) минимально.
С одной стороны, 99.9% времени мы живем дружно. С другой стороны — мы живем дружно именно потому, что у каждого репозитария есть мейнтейнер, который отвечает за этот код.
Если у вас изменения в N модулях происходят синхронно, я не уверен, что «ответственный» — ответственный.
Почему? Если я отвечаю за библиотеку — я могу понять, что стоит сменить API. Сменить его, и исправить все места, где этот API вызывается. Если API новый и экспериментальный, такое бывает довольно часто.
пусть сами обновляют после обновления библиотеки, асинхронно
Гм, вы путаете обновления кода репозитария с получением последней версии репозитария.
Видимо нас спасет git submodule foreach 'git pull". Это если можно из нормальных репозитариев сделать такой супермодуль с пустым содержимым.areht
29.01.2017 18:02+1> Если API новый и экспериментальный, такое бывает довольно часто.
Если при этом проект не компилиться у ответственного — что-то тут не так. Как минимум, ограничение прав не помогло.
> Гм, вы путаете обновления кода репозитария с получением последней версии репозитария.
с чего бы?Jef239
29.01.2017 18:24У ответственного — компилится. у остальных — частая проблема с тем, что забыли обновить (git pull) все репозитарии. А с чего вы путаете — вам виднее.
Ситуация простая — я обновил свою библиотеку и сменил в ней API. Соответственно сменил в трех репозиатриях, где этот API вызывался. Запушил все в git. А коллега сделал pull лишь тем репозитариям, с которыми он постоянно работает. Но в одном из них было использовано новое API… И на такое налетаем раз в неделю…michael_vostrikov
29.01.2017 20:22+1Вроде бы можно через хуки автообновление после git pull сделать.
Jef239
30.01.2017 06:22Можно подробности?
michael_vostrikov
30.01.2017 13:30
Just add files named post-checkout and post-merge to your .git/hooks directory of the relevant repositories, and put the following into each of them:
#!/bin/sh git submodule update --init --recursive
И еще вот тут более подробно.
Сам не пробовал, но должно работать.Jef239
03.02.2017 11:59Это только для сабмодулей. А для них — проще через алиасы.
$ git config alias.spull '!'"git pull && git submodule foreach 'git pull'"
А у нас пока сабмодулей нет и встает вопрос, а не стоит ли их ввести. Проблема в том, что или делать изменении структуры десятков проектов или делать симлинки, работающие и на windows и на linux. Скорее второе.
areht
30.01.2017 00:52т.е. если API не менялся, то разработчик может и не узнать, что он на неактуальной версии?
Jef239
30.01.2017 06:21А зачем? Ну написал коллега работу с USB, пока я не решу USB задействовать — мне это не важно. Аналогично, коллеге все равно, если изменил обработку ГЛОНАСС.
В этом и кайф от деления на репозитарии.
P.S. Для испытаний, само собой, все репозитарии обновляем. Но для разработки — это просто не важно.areht
30.01.2017 08:02Если у вас не стреляет — наверное, незачем.
То есть у вас получается 2 типа релизов библиотеки(на которые стоит завязываться в submodules): изменение API и перед испытанием.
> В этом и кайф от деления на репозитарии.
Эм? Такой кейс же даже в одной ветке так работает, не? )Jef239
30.01.2017 09:00Эм? Такой кейс же даже в одной ветке так работает, не? )
Не понял, поясните чайнику.
Релизы у нас отдельно идут. То есть интеграция непрерывная, а релизы — это уже после прохождения всех испытаний. Перед релизами — некий период общей заморозки кода, когда баги правим, а фичи не вставляем…areht
30.01.2017 09:13> Ну написал коллега работу с USB, пока я не решу USB задействовать — мне это не важно. Аналогично, коллеге все равно, если изменил обработку ГЛОНАСС.
Вот это в одном репозитории в одном бранче работает.
А про релизы — это про другое, про библиотеки. С виду интеграция у вас непрерывная, по факту — как получиться (контролируется только в 2-х случаях). Вот с непрерывной интеграцией и submodules будет непросто, но вам, получается, и не надо.
vintage
30.01.2017 09:29+2В СВН используется идеология, что ветка — это директория. Эта идея подкупает своей простотой и элегантностью. Но есть один косяк — если вы будете иметь доступ лишь к поддиректории проекта, то:
- либо теряете возможность полноценно бранчеваться, так как ваш "репозиторий" находится лишь в одной конкретной ветке "всего репозитория".
- либо начинаете бранчеваться внутри бранча и получаются в результате /project/trunk/gui/branches/123-better-design/outsource/trunk/
oYASo
30.01.2017 03:59+1Потому что проект может состоять из десятков и сотней модулей, часть из которых нужно либо сохранить в коммерческой тайне, либо их пишут определенные люди, и другим там делать нечего.
Выделять 2 файла из модуля и давать кому-то на разработку, забивая на тесты и вообще целостность модуля — идиотизм высшей степени.areht
30.01.2017 05:58А как у вас собирают такой проект люди, не имеющие доступа к коммерческой тайне?
oYASo
30.01.2017 06:18Очень просто — это делает билд-сервер.
areht
30.01.2017 06:59оок, переформулирую.
А как у вас отлаживают свои правки в такой проект люди, не имеющие доступа к коммерческой тайне?oYASo
30.01.2017 21:43+1Ну нужно пояснить, что у нас происходит.
У нас большой C++, состоящий из большого количества модулей (компилируются в итоге в статические/динамические библиотеки). Ясное дело, каждый модуль мы можем выделить в отдельный репозиторий, и дать к нему полный доступ. Юзер может писать там код, добавлять тесты и т.д.
Финальный проект собирает такие модули в один проект, и компилируется в готовый продукт. Дальше уже готовый продукт тестируется на наличие разных ошибок и багов.areht
31.01.2017 07:02+1То есть работа, так или иначе, происходит на уровне модуля, он секретным бывает целиком, и права выдаются на него тоже целиком?
А «Выделять 2 файла из модуля и давать кому-то на разработку» — это к чему было?oYASo
31.01.2017 15:53Меня, честно говоря, уже начал утомлять этот тред. Я не понимаю, как ты не понимаешь!
Есть большой проект, который состоит из большого количества библиотек. Скажем, ModuleA, ModuleB, ModuleC и т.д.ModuleA, например — купленный за лям баксов проект у сторонней организации, и допиленный нами до нужного функционала. Лежит в отдельном репе. ModuleB — наша математическая модель, которую пишет всего пара человек, разбирающиеся в вопросе. Он также закрыт от большинства.
ModuleC — какой-нибудь удобный враппер над какой-нибудь библиотекой, нам все равно, кто его пишет, главное — чтобы хорошо работал.
Каждый отдельный модуль является самодостаточным. Его можно скачать, собрать, прогнать юнит-тесты и прочее.
Большой прожект состоит из этих мелких проектов, которые вливаются в него с помощью subtree. Он собирается на билд-сервере, дальше уже прогоняются юнит-тесты и прочие тесты всего проекта. Дальше q&a берут с сервера deb пакет, ставятся себе и уже тыкают в него на поиск багов, которые спрогнозировать сложно.
Данный воркфлоу вполне себе пашет уже долгое время, свои задачи он решает, все довольны.
А «Выделять 2 файла из модуля и давать кому-то на разработку» — это к чему было?
Это было к предыдущего сообщению:
Почему вы думаете, что иметь один репозиторий, давая доступ к его части лучше, чем иметь 2 репозитория?
imps
01.02.2017 14:00простой пример, поддержка версионирования двух репозиториев намного сложнее поддержки одного
saboteur_kiev
29.01.2017 04:12+1В последнее время крайне редко видел чистый гит. Обычно все пользуются им через bitbucket/gerrit и др., где права доступа настраиваются на порядок гибче.
Гит осваивать почти не нужно — разъяснить что кроме commit надо еще push, написать краткую вики и все. Просто нужно, чтобы в проекте был человек, который первые пару месяцев сможет разруливать нестандартные конфликты.
Kater-auf-Dach
29.01.2017 23:21+2Добавлю пять копеек за hg. В нем можно создавать полноценные сабрепозитории (например, в них можно перемещаться по любым веткам и даже создавать свои, но последнее не приветствуется) и давать доступ только к ним. Единственное неудобство — тем, кто имет доступ к основному репу, приходится подтягивать изменения в сабрепах и коммитить основной.
Rend
29.01.2017 03:18+3Из преимуществ вспоминаются:
1. При копировании файла сохраняется его история
2. Раздельные права доступа на отдельные каталоги
3. Externals (хотя фича крайне неоднозначная)
4. Не нужно распихивать .gitignore по пустым каталогамomickron
29.01.2017 11:07+1Кстати, об истории переименованного файла. Есть ли способ избежать утраты истории?
DrLivesey
29.01.2017 12:00+1Если я не ошибаюсь, то с версии 2.9 в гите переименование файла не теряет историю.
vintage
29.01.2017 12:46+5В гите всегда теряется история. Он пытается угадать, ища похожий файл в предыдущем коммите, но как правило часто ошибается. Для сравнения — меркуриал пытается угадать перед коммитом и если он угадал не правильно — ему можно объяснить как правильно.
DrLivesey
29.01.2017 15:29+1Не очень понятна природа этой ошибки, если файл не переписывается почти полностью.
vintage
29.01.2017 16:56+4Ну так в гите эвристика простая — если отличия превышают определённый процент строк, то файлы считаются разными. Такой вот кривой дизайн Торвальдс придумал. Починить это можно, например, добавлением мета информации где-нибудь сбоку, как к в SVN прикрутили merge tracking, но работать этот костыль будет также криво и косо. Так и живём: притворяемся, что в гите есть ветки, что легко можно восстановить историю кода, что команды логичны и удобны, что сквашивание коммитов и перебазирование нужно для "чистоты истории", а не потому, что невозможно достоверно понять какой коммит к какой ветке относился.
DrLivesey
29.01.2017 17:35-1Вопрос именно в этом проценте строк, которые поменялись. Если это 80% файла (например от старого остался только копирайт, а не поменяли уровни отступов), то уже не важно что было в прошлом — важно зачем это поменяли, что должно быть написано в самом коммите.
VolCh
29.01.2017 18:16+1А если добавили try catch на основное тело и отступ сделали, то это новый файл
DrLivesey
29.01.2017 18:26- Как костыль можно переименование и изменение разбить на 2 коммита
- Я не знаю как гит относится к отступам при перемещении файлов, но если в этом случае файл считается полностью измененным тогда это несомненный косяк
VolCh
29.01.2017 19:12+1Насколько я знаю, у самого репозитория способа хранения копирования/перемещения/переименования вообще нет, для него этого новые/удаленные файлы. А решение показывать удаление и(или) создание или переименование принимается во время показа пользователю непосредственно в клиенте и там задаются параметры типа считать ли пробелы значимыми или сколько процентов должно быть совпадения, чтоб считать одним файлом
vintage
29.01.2017 23:27- Это сломается, когда все коммиты фичеветки сольют в один коммит в мастер "для чистоты истории"..
По умолчанию, гит считает файлы разными, если различия превышают 50%.
Есть ещё кейсы, когда файл разделяется на два или сливаются в один или ещё как хитрее. У систем контроля версий с этим сейчас туго и у гита — особенно.
DrLivesey
30.01.2017 10:55+1С моей точки зрения, фичеветка должна быть влита в мастер с --no-ff — так получится, что в мастере будет один коммит приносящий фичу, а история сохранится для потомков.
oYASo
30.01.2017 04:101. Как было замечено рядом в треде, это ломается только при сильном изменении файла (что, может, и логично). Если файл просто переместился, все ок.
2. Этот тред обсуждался чуть выше — решается subtree и отдельным репозиторием.
3. Я, честно говоря, не очень в теме, что это.
4. .gitignore достаточно положить в корень репозитория.
nick_volynkin
30.01.2017 07:44+1По пустым каталогам обычно
.gitkeepраспихивают, если действительно нужно версионировать пустой каталог.VolCh
30.01.2017 15:40Обычно если нужно, чтобы при git clone он создавался.
nick_volynkin
30.01.2017 18:31+1Я это к тому, что
.gitkeep, а не.gitignore(как пишет Rend). Так-то любой файл можно, но.gitignoreслегка сбивает с толку.
rg_software
29.01.2017 06:51+2Из очевидного, большие бинарные файлы все ещё боль в git и hg тоже.
akzhan
29.01.2017 10:43+3Для этого придуман HG Largefiles extension. Идёт в комплекте поставки, надо только включить в конфиге.
Это я пишу, как Gitовод, но в компании любят Mercurial, видимо, за large files из коробки.
А Git LFS надо спецом клиенту ставить, иначе молча пропускает...
rg_software
29.01.2017 12:27+3Всё верно, но, к сожалению, это тоже палка о многих концах, с largefiles мы хлебнули массы неочевидных проблем, хотя от безысходности пользуемся.
Bonart
30.01.2017 15:41+2Возможно, не только за большие файлы.
Мерк помнит, была ли уже запушена конкретная ревизия.
Мерк при мерже сливает граф патчей, а не просто два файла.
В мерке не бывает отсоединенных коммитов.
Для меня гит на фоне мерка напоминает профессиональный инструмент. Профессиональный в том плане, что любитель в процессе эксплуатации с легкостью отрежет себе пальцы, потому что про изоляцию проводки и каком-нибудь защитном кожухе над циркулярной пилой никто не думал — профи должен соблюдат технику безопасности сам.
alexeykuzmin0
29.01.2017 19:22Я в некоторых проектах использую SVN для репозиториев Thirdparty. Нет смысла хранить локально всю историю изменений очень тяжелого редко обновляющегося репозитория.
athacker
31.01.2017 20:37-1С точки зрения хранения серверных конфигов SVN гораздо удобнее. Потому что не тянет локально на каждый сервак весь репозиторий, а позволяет системный каталог с конфигами (например, /etc или /usr/local/etc) сделать рабочей копией. Что очень удобно — поменял конфиг на серваке, дёрнул сервис, если всё заработало — сразу закоммитил прямо из /etc.
grossws
01.02.2017 03:10+1В git help clone прекрасно описаны параметры
--depthи--branch, которые позволяют вытащить определенную ветку/тэг на указанную глубину. О depth в комментариях говорилось уже не раз.
- Держать
/etcв репозитории для сохранения истории изменений в принципе можно. Ради последующего просмотра. Делать checkout крайне не рекомендуется: проблемы бывают от побитых прав на файлы (user/group/xattr/acl) до приведения системы в нерабочее состояние, но это сильно зависит от того, что живёт на сервере, может и пронести.
ZyXI
01.02.2017 05:37Права и атрибуты можно так же сохранить в VCS. Готовых систем я не видел, но технических препятствий не вижу, другое дело, насколько и как именно придётся заморочится и чем вы за это заплатите. С git’ом, кажется, будет проще, если написать скрипты?обёртку над commit/status/checkout и сохранять данные об атрибутах в отдельных файлах, mercurial вроде позволяет написать расширение, улучшающее функционал встроенных команд и позволяющее сохранять дополнительные метаданные (и ещё посылать пользователей, хотящих сделать clone без установки расширения), но это должно быть более трудоёмким. Subversion — не знаю. С сохранением метаданных у него вроде лучше чем у git, но про расширения я не слышал.
Jaromir
28.01.2017 22:40+1Git так и не научился отдавать один файл/директорию без скачивания всего репозитория со всеми изменениями? Менеджеры пакетов, постоенные на git так и качают 95 избыточных процентов в виде папки .git для каждого пакета?
lega
28.01.2017 22:52+11В git можно задать (глубину) depth, и скачать только один «срез».
Jaromir
29.01.2017 00:12Спасибо. Не знал. А что насчет скачивания отдельного файла или директории?
Self_Perfection
29.01.2017 00:22+2Да легко
git archive "$BRANCH" "$OPTIONAL_PATH" --remote="$REPO" | tar -x -C "$DESTDIR"
Но сервер может не поддерживать. С гитхаба у меня так стянуть не удаётся.Jaromir
29.01.2017 00:28Странно что гитхаб не поддерживает. По идее, позволило бы значительно снизить нагрузку на их сервера
akzhan
29.01.2017 10:49Для этого там другая фича — режим просмотра файла Raw.
Но вообще файлы без истории как-то не ок.
EaE
29.01.2017 16:10+1Но вообще файлы без истории как-то не ок.
Сейчас стильно-модно-молодежно ставиться из репа напрямую, Атом так свои плагины ставит например. То есть речь идет о файле, для которого никто никогда не посмотрит не только историю, но и сам файл.
selivanov_pavel
29.01.2017 16:39> файлы без истории как-то не ок
Например, деплой. Зачем там история? Нужен только определённый коммитakzhan
29.01.2017 19:49Понятно, что CVS могут выкатить данные без истории.
Но выкатка подразумевает другое, в зависимости от админов.
Почитайте на досуге про Capistrano (один подход) или про Opscode Chef.
P.S. у нас выкатка подразумевает Blue/Green, или хотя бы
npm run build/make build.selivanov_pavel
29.01.2017 21:42> выкатка подразумевает другое, в зависимости от админов
Понятно, что там ещё всякие проверки, миграции и прочее, но код-то из репозитория всё равно скачать надо, если язык не компилируемый
> Capistrano (один подход) или про Opscode Chef
Я люблю няшненький питончег, поэтому Ansible :)
webasyster
29.01.2017 13:46Не сказал бы, так как проще выкачивать http/s, чем держать процессы архивации, которые жрут по 50-100% CPU.
Jaromir
29.01.2017 16:07tar не архив. Как минимум, не в современном понимании этого слова
grossws
29.01.2017 19:33tar именно архив без какой-либо компрессии. Просто благодаря всяким архиваторам типа zip/rar/arj народ привык, что архиватор не только архивирует, но ещё и жмёт.
VolCh
29.01.2017 19:35не в современном понимании этого слова
Сейчас уже называют архиваторами компрессоры с функций архивации.
ctacka
29.01.2017 03:41+1Это, насколько я понимаю, дает вам только сам голый файл. Без истории. Вы не можете вытащить один файл из git-а, поменять его и запушить. Это обусловлено архитектурой git-а.
Andy_U
29.01.2017 13:45Возьмите Git Extensions (для Windows), который умеет показать вам произвольный файл из произвольного коммита, Не думаю, что он работает с «базой данных» GIT'а не через его API.
grossws
29.01.2017 19:37С большой вероятностью он делает то же, что и
git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>..., см.git-checkout(1).
VBKesha
28.01.2017 23:29+2А еcли для svn сделать svnadmin pack и посмотреть размер?
ki0
30.01.2017 11:56Отличное замечание, но особо не влияет.
svnadmin.exe pack svn
214 MB (4,644 Files, 89 Folders)
Помогло только с количеством файлов, объем незначительн вырос.VBKesha
30.01.2017 12:03Ну как сказать у меня есть система где один раз в 6 минут идёт комит. Там объём с 20 гигов до 500 метров падал.
1vanK
29.01.2017 00:22+1Из статьи я так и не понял, почему же стоит мигрировать с уже работающего свна на гит
VolCh
29.01.2017 10:34Статья опровергает, прежде всего, аргументы тех, кто против перехода.
1vanK
29.01.2017 18:34ну опровергнутые аргументы такие себе, получается правы сослуживцы, считающие, что шило на мыло
VolCh
29.01.2017 19:16+1Как бывает:
— Давайте перейдём на гит, у него есть такие-то такие-то плюсы!
— Плюсы, конечно, хорошо, но вот есть такие минусы — и список этих мифов
— Вот на хабре опровергли эти минусы — и ссылка на это пост.
Минусы перехода опровергнуты, а плюсы — нет.
ctacka
29.01.2017 03:49+7Мифы, как мне кажется, неправильно сформулированы.
Когда говорят о том, что размер репозитория больше, говорят в основном о том, что нельзя часть репозитория вытащить. То есть если у вас 20 гигабайт репозиторий, то вам придется тащить сначала все 20 гигабайт, даже если вам нужно поменять 1 файлик на 10 байт. В SVN любая папка сама по себе практически репозиторий.
Про ветки — даже если в svn сделать ветку также легко, как и в git-e, то это не значит, что они такие же легкие. Операции с ветками, например слияние, в svn все-таки тяжелее проходят. А merge (и rebase) — это главная операция для веток все-таки.
Scf
29.01.2017 10:49+1Основные преимущества гит перед свн:
- скорость работы
- быстрые и качественные операции над ветками — merge и rebase
- образцово качественная утилита командной строки с очень богатым инструментарием
Основные преимущества свн перед гит:
- возможность заливать большие файлы без потери производительности (актуально для документации и не только в IT)
- наличие GUI для секретарш
- быстродействие не деградирует для очень больших репозиториев (монорепо или просто крупный проект)
- возможность назначать права на каталоги.
crazylh
29.01.2017 11:35+3наличие GUI для секретарш
А что для Git не существует гуев "для секретарш"? SourceTree, Tower, GitUp — это то что на вскидку вспомнилось.
DrLivesey
29.01.2017 11:59+3Довелось работать с SourceTree — в итоге использовал для запуска консоли.
Source Tree — относительно универсальная среда и поэтому не всегда пользуется терминологией гита, что при знании консольных комманд заставляет каждый раз задумываться, что происходит под капотом.
Мое личное мнение — для гита нужно использовать либо консоль, либо GUI написанный специально для него, чтобы «секретарши» говорили на одном языке с теми, кто GUI не пользуется.
Lamaster
30.01.2017 16:58Юзаю TortoiseGit, всё устраивает. Если навести на элемент GUI, то он покажет какие ключики будут использоваться. Пишет команду, которую использовал, так что можно скопировать коллеге или на будущее, отображает процесс во время работы.
dim_s
29.01.2017 13:17+2Для секретарш советую использовать расшаренный диск или FTP, или даже WebDAV. Меня всегда удивляло, что в плюсы SVN записывают аспекты, не относящиеся к разработке. SVN это инструмент для разработчика, в первую очередь.
Scf
29.01.2017 14:04Для секретарш и документооборота в целом главный плюс SVN — полная защита от повреждения информации, в том числе криптолокерами.
DrLivesey
29.01.2017 15:04+9Начет криптолокеров: в случае с Git все нужно провернуть на абсолютно всех без исключения копиях репозитория и сервере через который происходит синхронизация. Только в этом случае будет потеряно все, включая историю изменений.
В случае с SVN — чтобы убить историю достаточно просто зашифровать сервер.Scf
30.01.2017 11:34Откуда криптолокер возьмется на сервере? Кто будет синхронизировать гигабайты или даже десятки гигабайт данных на каждую машину?
sabio
30.01.2017 01:23+4образцово качественная утилита командной строки
Да уж, "качественная".
Это не одна утилита, а несколько разрозненных команд.
В каждой свой подход к заданию параметров:
Вывести список веток:git branch -a
Вывести список тэгов:git tag
Вывести список стэшей:git stash list
Вывести список remote:git remote -v
Одна и та же команда может выполнять совершенно не связанные вещи:
Переключиться на другую ветку:git checkout
Создать ветку (и переключиться на неё):git checkout -b
Обновить содержимое файла:git checkout
В отличие от принятого в *nix подхода, длинные и короткие опции не эквивалентны:
git branch --helpвыдаст полную информацию о команде, аgit branch -h— только краткую справку
Вот и появляются всякие Gitless да "Human Git Aliases".
nick_volynkin
30.01.2017 07:51Скажите, а откуда в документации берутся большие файлы? Это видеоинструкции или PDF-ки?
Scf
30.01.2017 11:36как правило, word, powerpoint, картинки. Одна инструкция пользователя чего стоит. Формы и образцы, если приложение относится к документообороту. Всякие-разные регулирующие документы по предметной области.
VMichael
29.01.2017 23:20+1На последней работе пользовались древним CVS, с графическим интерфейсом, с таким: http://cvsgui.sourceforge.net/shots.html
Очень удобно просматривать историю, очень удобно сравнивать различные версии, просто выбирая на дереве мышью, все очень наглядно.
Проекты учитывались в самописной системе учета. Номер проекта присваивался ветке.
На коммит ставился тег номера обновления (проекты разворачивались с помощью обновления).
При развертывании обновления в боевую систему, тег дополнялся.
После этой системы переход на гит это ломка, признаюсь.
Не встречал подобного, удобного GUI.
zystem
30.01.2017 01:44+5Прямо с первых строк статьи начинается подтасовка фактов. Надеятся что на хабре читатели не знают английский по меньшей мере странно.
Except for the case of storing a lot of binary files, when Subversion repositories could be significantly smaller than Git ones (because Subversion’s xdelta delta compression algorithm works both for binary and text files)
После чего автор берет свн репозитарий исходных кодов без бинарей (фактов о наличии в нем бинарей в статье не приведено, да и количество файлов при размере 213 МБ намекает) и радостно рапортует, что текст git хранит лучше.
Пусть автор попробует создать репозиторий с 100мб бинарями. И сконвертит его в гит. Убедится что гит умрет, и включит LFS. После чего с удивлением узнает, что LFS ничего ни о каких дифах не знает и тупо хранит каждую измененную версию в отдельном файле. Итого по 100 и более мб на каждую ревизию. Поэтому git безусловно крут, но вот для смешанного хранилища бинарей и исходных кодов ничего лучше svn так и не придумали (maven, artifactory… это не vcs у них своя ниша)ki0
30.01.2017 12:29+2Хочу подчеркнуть одну мелкую но важную деталь: я перепроверял результаты экспериментов, которые приводят на обсуждаемом сайте.
Они сами выбрали wordpress, я лишь повторил тот же эксперимент но на ОДНОМ источнике, и сделал несколько дополнительных шагов.
Беда проверки с бинарными фалами — все они разные!
Я могу взять ISO образ с текстовыми файлами — такой формат данных отлично сжимается и я прогнозирую победу git-а.
С другой стороны, можно взять архивы и эту будет худший случай для гита.
Насколько я знаю у гита одна проблема с большими бинарными файлами по сравнению с svn — весь репозиторий будет у каждого клиента, а если там много несжимаемых бинарей — он будет большой. Фактически будет жраться место на компах и страдать время клонирования. LFS именно эту проблему и решает.
С другой стороны я провел кучу сравнений хранения бинарных файлов в git и svn для нашего проекта. Средний проект: пара десятков мелких файлов, десяток бинарных на 1-2 МБ, 1-2 крупных бинаря на 10-50 МБ. И в результате гит на наших файлах показывает приемлемый результат: 500 коммитов на проект, репозиторий весит в 2 раза меньше чем рабочая копия. Хранить на LFS полные копии несжатых файлов мне в этом случае кажется лишним.
Из-за специфики формата не думаю, что это будет интересно широкой публике.
NLO
30.01.2017 09:40НЛО прилетело и опубликовало эту надпись здесь
grossws
30.01.2017 17:08А вы читали там ответ с 80+? В нём содержится информация о том почему эта проблема возникает и рекомендации, как её избежать. Не забудьте сказать спасибо разработчикам используемого вами софта, который любит эксклюзивно открывать файлы.
vasiliysenin
30.01.2017 15:34Лет 10 назад, использовал svn, добавил в проект файл с именем на кириллице. Он благополучно его закоммитил. А когда я пытался восстановить проект из репозитория, выдал ошибку и весь репозиторий сломался. Хорошо ещё что я регулярно делал .zip архивы.
Git хоть и не разрушает репозиторий, в аналогичной ситуации, но при выводе имён файлов выдаёт коды символов через слэш. С диффом и комментариями (в тексте программы) на русском языке та же проблема.grossws
30.01.2017 17:11+1Git хоть и не разрушает репозиторий, в аналогичной ситуации, но при выводе имён файлов выдаёт коды символов через слэш. С диффом и комментариями (в тексте программы) на русском языке та же проблема.
Если git отображает имена файлов и содержимое с символами через бэкслеш (иногда в угловых скобках), то это означает, что ваш терминал плохо работает с используемой кодировкой. С большой вероятностью, с utf8. Проверяйте настройки терминала и локали.
ctacka
30.01.2017 23:52+1Вы знаете, у меня даже emoji в описаниях коммитов нормально работают. Кажется, дело не в git-е.
lega
Сравнение не о чем. Скорость операций — это далеко не первый пункт. Это как, если бы к вам подошел отчисленный Вася и предложил сделать операцию в 3 раза быстрее и дешевле чем квалифицированный хирург.
Да он вроде тоже может, но результат будет отличаться.
Туда же и mercurial (hg), я его лет пять использовал (после svn), не хотел переходить на гит, т.к. там вроде бы все тоже самое. Пришлось перейти под «давлением общественности», и не зря, т.к. гит на прядок лучше. Теперь для меня норма — то, что не приятно было трогать в hg. Продуктивность выросла, и не важно кто там быстрее клоны делает.
sabio
Расскажите, что вам было «неприятно трогать в hg», и в чём именно «гит на порядок лучше [hg]»?
lega
Например работа с бранчами и другие мелочи. Чем мерседес лучше жигуля? Вроде у обоих есть и руль и сиденье, тут надо пробовать чтобы почувствовать.
ctacka
А можете побольше рассказать? Я 6 лет работаю с git-ом и все время комплексую, что hg наверное лучше и я что-то теряю.
DeeKey
Навскидку могу сказать про ветки в hg — commit содержит имя ветки, соответственно принадлежность commit'а к ветке однозначна. Ветка в git'е это блуждающий указатель на commit — после разветвления или мёржа о том в какой ветке были созданы «старые» commit'ы можно только догадываться. Tag'и в git'е — это только метки/указатели на дерево истории; в mercurial — установка tag'а это тоже часть истории. В целом, hg несколько более формализован а git несколько более гибок — соотвественно hg дает чуть больше шансов понять что, где и как изменялось, а git несколько меньше путается под ногами.
kk86
Спасибо за комментарий по существу вместо балабольства о жигулях vs мерседесах!
Можете привести пример того, когда важно знать, в какой ветке родился commit? С Git это и правда не определить. Так что, например, после cherry-pick так сразу и не скажешь, что откуда пришло (но мне и не приходилось задаваться вопросом).
VolCh
Во многих командах принято в git начинать сообщение коммита с метки тиккета/таска, работа по тиккету/таску обычно ведётся в одной ветке, коммитов может быть много и каждый раз писать надо или как-то автоматизировать. В mercurial достаточно указать метку в названии ветки и все коммиты в ней будут её хранить, то есть по коммиту мы сможем всегда сказать в рамках какой задачи он был сделан.
ghost404
В гите можно мерждить ветку с флагом
--no-ffи тогда в network будет видно откуда коммиты пришли.VolCh
Будет видно какие коммиты мержелись, но не какие ветки, если указателей веток ушли с этих коммитов или вообще удалены
DrLivesey
В коммите написано: Merge 'very_hot_featrue' into 'master'.
VolCh
Это по умолчанию будет, но их можно изменять.
DrLivesey
А что запрещает договориться чтобы не меняли или писали что-то отслеживаемое?
Кодинг конвенции же существуют.
VolCh
Для гит требуется больше договоренностей, чтобы отследить в рамках какой задачи был сделан тот или иной коммит. Ну и собственно отслеживание сложнее.
DrLivesey
Знаете, вы меня убедили.
В моем текущем проекте меня больше волнует есть ли конкретный коммит в мастере, или его там нет.
ghost404
на мой взгляд ничего сложного нет
https://habrahabr.ru/post/106912/
vintage
Это только в мёрж коммите. В остальных коммитах будет всякая ерунда.
ghost404
Да, конечно, но остальные коммиты будут в ветке. В network будут отдельно коммиты сделанные в мастер и отдельно коммиты сделанные в ветку + мердж коммит.
А для того что бы по номеру коммита из истории в мастере определить из какой ветки он в нее пришел достаточно посмотреть вверх по истории до ближайшего мержда. Ну и конечно ветку нужно называть по номеру тикета.
https://habrahabr.ru/post/106912/
VolCh
Не будут они в ветке, если принято удалять ветку после мержа. Или если втеки часто мержатся между собой, например в мастер ветку мержится из девелопмент ветки, куда мержится всё остальное.
ghost404
Вы что, не читали статью по ссылке?
После удаления ветки удаляется только метка ветки, а коммиты никуда не деваются. Они все еще висят в истории как отдельная ветка (если конечно ветку смерджили куда-то с флагом
--no-ff). Я даже больше скажу. Можно восстанавить ветку после удаления и начать работать с того же места на котором остановился (доводилось такое делать). И все ветки прекрасно видно в истории даже после их удаления. Сами полистайте историю.Если вам лень читать статью, то объясню все на пальцах:
Перед релизом обязательно сливаться в master.
Также полезным будет слить master в develop.
Если develop не сливать в master, то через несколько итераций расхождение веток может стать критическим (сталкивался с таким).
Создается из master и мерджится в develop.
Если ей для работы нужны другие задачи, то они мерджатся в нее.
Ни в коем случае нельзя в нее мерджить develop ибо может потребоваться выкатить эту задачу до полного релиза с мерджем develop в master, а в этот момент в develop может быть еще не доработанная или не до тестированная фича.
Создается из master и мерджится в master, develop и другие активные ветки по необходимости.
Далее выкатывается master с hotfix-ами.
Ветку develop не трогаем.
Работаю по этой схеме уже несколько лет в разных компаниях и ни каких проблем.
VolCh
Никто не говорит, что коммиты пропадают, речь о том, что пропадает информация в какой ветке был коммит сделан. В какой-то момент все имеющиеся (а есть ещё удаленные) указатели веток могут указывать на один коммит и нет никакого способа определить средствами гит в какой ветке он был сделан.
ghost404
Не сталкивался с таким и даже слабо себе это представляю.
Протестировал немного.
Да, сделать такое можно.
Получается если создать ветку Б из ветки А, то они будут эквевалентны и будет сложно понять что это ветка Б сделана из А или А из Б. То есть какая из веток является изначальной и соответственно к какой ветке относятся сделанные ранее коммиты. Но если ветки эквевалентны, то какая принципиальная разница какая из них изначально созданная?
Что вы в корзину положите одно яблоко, что одно яблоко положите в корзину, все равно в корзине будет одно яблоко.
То же самое происходит если создать ветку Б из корня ветки А и смерджить в нее ветку А, но при условии что ветка А не участвовала в других мерджах. В моем случае это ветки issue-345 и issue-456 с общими коммитоми 916908b и 4310c9e. А вот с веткой issue-3 это уже не работает так как ветки issue-1 и issue-2 уже участвовали в мерджах.
У меня нет под рукой SVN чтоб проверить, но думается мне что там будет похожая картина
ghost404
Забыл сказать. Проблемы есть только с тестированием, когда нужно отдать задачу на тестирование тестировщикам.
По правильному нужно тестировать задачу сначала отдельно (как отдельную ветку), а потом сливать в develop и тестировать еще раз на совместимость с другими задачами в develop.
У нас тестировщики были ленивые и тестировали сразу develop что изрядно усложняло разработку и ветвление в git.
rakeev
В hg есть классические тяжелые ветки и легкие скользящие указатели bookmarks. Корректнее сравнивать с git-ом именно последние.
Теги в гите могут быть аннотированными, и они таки часть истории.
leventov
Существует слово "тег". https://habrahabr.ru/post/212657/
Bonart
Немного не так.
У мерка есть аналог гитовых веток — букмарки.
У гита аналогов мерковых веток нет.
ZyXI
Насколько я вижу, архитектура mercurial позволяет запилить туда в качестве расширений git’овские ветки (закладки начинали как расширение), фазы (аналогично) и даже таких монстров как evolve — расширение, позволяющее “переписывание” истории, при этом в значительной степени сохраняя её неизменность — должно позволять делать
rebaseбезpush -f, насколько я понимаю. Вопрос: почему ничего подобного не делали в git? Не то что evolve, git’оводы на вопрос «как ко всем изменениям автоматически прикреплять номер тикета» нормально ответить не могут — архитектура не позволяет.Собственно, по моему мнению для закапывания git достаточно посмотреть на его потенциал развития — сразу после рассматривания его CLI. К сожалению, github вместе с большинством разработчиков сами знаете на чём.
Moldovich
Простите за невежество, а на чём же, собственно? С пруф-линком если возможно, пожалуйста.
semmaxim
В hg ветки — это настоящие ветки и остаются такими даже после закрытия и слияния. Это самое главное, пожалуй.
Ну и hg более «человечен» что ли. Я работал с тем и другим и в hg всё понятно интуитивно и есть прекрасный удобный клиент (TortoiseHg). В git же надо либо вникать, либо курить мануалы. И GUI хуже.
ghost404
А чем не устроил TortoiseGit? TortoiseSvn в туже степь. Можно еще gui из PhpStorm, но я лично gui не использую. Мне консоль удобнее.
rg_software
Может, сейчас что-нибудь улучшилось, но раньше это была очень тонкая надстройка над командной строкой. Например, начинаешь что-нибудь делать, а оно визуально просто висит намертво, потому что угадай, там вообще хоть что-то происходит или зависло уже. Причём шаг влево-вправо, уже расстрел, потому что сами инструменты тоже откомпилированы не совсем родным для Windows способом. Скажем, имя папки ему не нравится или имя файла. А для аутентификации мне приходилось ещё pageant осваивать — не rocket science, конечно, но с чего бы такие сложности.
develop7
https://www.quora.com/What-things-does-Mercurial-do-better-than-Git
rg_software
Не троллинга ради, я сижу на hg, и те пару раз, что пришлось иметь дело с гитом, казалось, что пересел на жигуль. Без аллегорий, расскажите подробнее о преимуществах, а то чувствую себя отщепенцем на hg, а мотивации переходить на гит нет.
Funbit
Присоединяюсь к вопросу, т.к. испытываю абсолютно такой же дискомфорт при использовании git после hg.
vintage
Особенно учитывая, что у гита бранчей фактически нет, а есть лишь "автоперемещаемые теги".
netch80
Основные и чрезвычайно ценные вкусности Git — это interactive rebase, index и stash.
Rebase позволяет формировать цепочки изменений в том виде, в котором они должны быть представлены независимо от внутренних процессов разработчика; он может коммитить каждую секунду, может для себя делать что-то в таком стиле, но на публичную фиксацию и/или командное взаимодействие подаётся уже продукт, а не сырьё. Качественного аналога в Hg нет.
Stash позволяет формировать внятную последовательность изменений в типичном (в моих краях и задачах) случае, когда, начиная какую-то мелкую правку, обнаруживаешь, что вслед требуется цеплять что-то более крупное, а там и докатываться до больших рефакторингов. Изменения, которые стронули лавину, откладываются, и так может быть несколько раз. И даже без этого, после приёма новых чужих изменений из аплинка, он помогает их аккуратно скрестить. (Аналог — говорят про queues, но это только частичная замена, и говорят, что их выпилят за концептуальную несовместимость.)
Index (с add -i, add -e) или помогает stash?у, или позволяет отправлять только часть изменений; например, в моих задачах типично, что я навешиваю в локальных функциональных и интеграционных тестах расширенную отладку, которая не должна попадать аплинку; также могут быть адаптации под локальную платформу, и т.п. (Замечу, что Tortoise клиенты дают такое для всех поддерживаемых SCM; но «из коробки» в Hg и SVN этого нет.)
Теперь про «ветки» в Hg — тут есть ряд злобных засад. В Hg понятие ветки это смешение нескольких разнородных сущностей в одну не сильно приятную (именно из-за смешения) кашу:
Основное неприятное тут то, что именно авторы Hg принципиально поддерживают этот бардак. (И я ещё не вспомнил bookmarks, которые тоже ветки, но иначе.) Прямая цитата из родной вики: «The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial.» Но в результате те, кто хвалят ветки Hg за их персистентность, имеют в виду только ветки-2 и только факт явной пометки в истории. Но на самом деле эти пометки не являются ветками — это теги ченжсетов. (А почему именно один такой тег и только branch, если механизм таких тегов в принципе существует, почему он не расширяем?)
Аналог «веток-2» (тегов коммитов) для Git делается не прямо, но через pre-commit hook можно редактировать сообщение коммита. Но если такое делают, то лучше вписывать не какой-то непонятный branch name, а ссылку на тикет, в рамках которого это делается; на моей прошлой работе такое делали — такой хук вылавливал номер тикета из имени локальной ветки (в смысле Git).
По всему описанному, для меня пробы работы под Hg закончились только возмущением «и как в этом бардаке можно что-то делать?», после продирания через грязные коммиты с посторонним мусором, зависшие головы и невозможность без дикого напряга привести всё это в порядок (в итоге я перекинул всё в Git и успокоился). Некоторые из этих возможностей Hg, однако, выглядят иногда полезно. Безымянные головы (но при условии — только в рабочей копии, и нельзя делать push, пока их больше одной, и не по умолчанию). Или автоприклеиваемые к сообщению коммита строки (лучше — набор с именами и содержимым). Но и без них отлично работается.
И ещё одно — очень часто говорят, что на Hg легче переходить после CVS и SVN, чем на Git. Мне получилось строго противоположно — после CVS Git оказался лёгким и простым, а с SVN и Hg резко не сложилось.
sabio
Спасибо за подробный ответ.
Кстати, что касается stash, в Mercurial версии 2.8 и выше поставляется ShelveExtension. Как я понимаю, это тот самый stash и есть.
Для
git add -iтоже есть аналог и без TortoiseHg. Раньше это было реализовано в RecordExtension. А сейчас уже есть "из коробки":hg commit --interactiveА про "легче переходить", скорее всего, обычно имеется в виду более согласованный синтаксис команд в Mercurial, в отличие от "полной анархии" в командах Git (см. мой комментарий ниже). Вряд ли на этапе перехода всплывают концептуальные нюансы использования веток.
netch80
Вот именно, что эти аналоги очень неполные.
> ShelveExtension
Нет аналога --keep-index. Также непонятно, относится это только к файлам, которые уже под контролем, или вообще ко всем. В Git это управляется опциями, можно stash?ем убрать вообще всё, можно только то, что в известных ему файлах.
> hg commit --interactive
В Git я могу набирать индекс по частям и постепенно, анализируя, что получилось, возвращая части и снова добавляя, сравнивая диффы между рабочей копией и индексом, и что попало в сам индекс, могу что-то подправлять прямо в самих диффах (в варианте add -e), могу сложить его в stash. (Как правило, нужно в таких диффах удалять дополнительную отладку или специфические локальные опции, но иногда бывает и то, что должно идти в следующий коммит.)
hg commit --interactiveэто набор подмножества патчей одним махом. Если они меня не устраивают в таком виде — начинается некрасивая работа по бэкапу файлов и ручной вычистке ненужного.И описанные тут «могу» и «приходится вручную» относятся к реальным и регулярным случаям.
> А про «легче переходить», скорее всего, обычно имеется в виду более согласованный синтаксис команд в Mercurial,
Аргументация сторонников Hg тут, как правило, была иной — им нравилась хотя бы частичная эмуляция стиля линейной последовательной истории, начиная с номеров коммитов для локального репо. Синтаксис команд звучал как аргумент, но не для лёгкости перехода. Я не психоаналитик, чтобы раскапывать тут реальные связи, поэтому ограничился наблюдаемым.
develop7
Не совсем понятно, чем именно вас не устраивает
hg histedit, но даже и плагин "MutableHistory" (позволяющий совместно править shared историю) вполне себе юзабелен.1) эта функциональность полностью воспроизводится средствами искаробочного плагина MQ; частичный коммит реализован искаробочным плагином
record2)hg shelve(правильно, это тоже искаропки)Голова графа ревизий репозитория. Другой вопрос, что в гите почему-то принято считать, будто головы, на которые никто не ссылается, то ли не существуют, то ли являются мусором (мнения разнятся в зависимости от man page). Mercurial же просто записывает всё за пользователем.
netch80
> Не совсем понятно, чем именно вас не устраивает hg histedit
До последних версий (3.8? я сбился с историей нумерации) он был непригоден. Сейчас надо перещупать заново.
> частичный коммит реализован искаробочным плагином record
1) deprecated 2) принципиальная разница в отсутствии явного индекса, я не могу перед коммитом посмотреть, что же получилось. (В описании вообще подтасовка — «interactively select changes to commit» не подразумевает самого коммита, но он происходит.) Да, можно потом корректировать историю, но это много лишних движений. Ещё и легко ошибиться (strip без --keep потеряет изменения).
> hg shelve (правильно, это тоже искаропки)
И снова без возможности учесть индекс. Как-то его, я смотрю, в Hg совсем не оценили, и всё сравнение в итоге утыкается в него.
> Mercurial же просто записывает всё за пользователем.
Я бы оценил эту фичу в варианте 1) автоматически не включена, 2) препятствует внешнему обмену, пока не указана конкретная голова или не осталась одна. Но в текущем варианте это источник тяжёлых диверсий.
develop7
Так а чем именно? После 3.8 его практически не правили.
Идея набирать изменения, безусловно, любопытна, однако лично я в какой-то момент обнаружил, что использую индекс где-то раз в полгода. И оба раза можно было бы обойтись interactive commit.
это если только ещё и с
--no-backupНу это, в гите наличие индекса существенно усложняет чуть менее, чем весь интерфейс. А пользы — чуть.
а оно и препятствует:
Таким образом, без дополнительных телодвижений новые головы просто-напросто не выпинываются.
netch80
> Так а чем именно? После 3.8 его практически не правили.
Я про «до».
> Ну это, в гите наличие индекса существенно усложняет чуть менее, чем весь интерфейс. А пользы — чуть.
Ну вот тут и видна фатальная разница. Для меня это не «чуть», это критично. И соответственно ценность всех остальных механизмов, если они это не поддерживают, снижается в разы.
> Таким образом, без дополнительных телодвижений новые головы просто-напросто не выпинываются.
OK, принято. Я не помню, откуда взял про передачу всех голов — скорее всего, это утверждал один из апологетов Hg, а я не проверил. Осталось не разрешать их локально по умолчанию :)
Bonart
Так они локально появляются после pull естественным образом.
Наверно, при желании можно и руками такое сотворить… но это потребует сознательных усилий и мотивации.
vintage
Это в каком виде? В виде, не соответствующем реальности? А зачем? Какой прок от недостоверной истории?
https://habrahabr.ru/post/179123/
https://habrahabr.ru/post/179673/
Оно всего-лишь создаёт скрытую локальную ветку для незаконченной работы. Это даже в SVN не сложно реализовать, не говоря уж о том, что в HG оно есть из коробки.
Чувствую у вас не редки ситуации, когда у вас на машине "всё работает", а у того, кто пульнёт ваши изменения, всё сломается, ибо вы то забыли закоммитить, то закоммитили чего лишнего.
Я так и не уловил этого тонкого различия. Почему вы противопоставляете часть (голова) целому (ветка)? Ветка метро — это всё множество последовательно соединённых станций, или только лишь конечная станция?
Ничего удивительного. Git — это этакий прокачанный CVS, который отслеживает не отдельные файлы, а группы файлов, и плевать он хотел на историю их содержимого (которое кочует между файлами).
netch80
> Это в каком виде? В виде, не соответствующем реальности? А зачем? Какой прок от недостоверной истории?
Должна ли история сохранять все опечатки и душевные метания программиста? Я лично живу в мире, где лучше, что автор выставляет некоторое «предложение», и только с момента его принятия оно становится частью истории, независимо от того, какие внутренние процессы привели к нему.
Ссылки на статьи после этого — забавны, но не имеют отношения к текущему обсуждению, и, по-моему, вообще ни о чём. Если требуется рабочее состояние после каждого коммита, то это должна обеспечить автоматизированная проверка. Например, у нас к Gerrit?у для этого был прикручен Jenkins. Если коммиты были отправлены под другую версию, и корректировка под новое API была сделана потом одним рывком, а не на каждый участвующий, то проверка не прошла, и это уже вопрос административный, допускать такое вообще или нет. Но хуже то, что с merge, которое предложено взамен, если это именно merge, то по любому получим неработающую версию после слияния, а если тут же править результат слияния, то это будет уже не честное слияние, а доработка. По-моему, тут идеального выхода нет вообще.
> Оно всего-лишь создаёт скрытую локальную ветку для незаконченной работы. Это даже в SVN не сложно реализовать,
Локальную — в SVN?
> Чувствую у вас не редки ситуации, когда у вас на машине «всё работает», а у того, кто пульнёт ваши изменения, всё сломается, ибо вы то забыли закоммитить, то закоммитили чего лишнего.
Бывают — там, где нет автоматизированной проверки коммита. (Сейчас я расслабился, потому что основную компоненту веду один. Раньше за счёт центрального Gerrit с code review такое не проходило, и приходилось заботиться сразу.) Но доля таких ситуаций всё равно в разы меньше, чем грязи в процессе, когда вначале коммитится со всеми локальными мотлохами, а потом они вычищаются (а часто даже тупо забываются, пока не всплывают на продакшене). Так что чисто статистически от этого тоже польза.
> Я так и не уловил этого тонкого различия. Почему вы противопоставляете часть (голова) целому (ветка)? Ветка метро — это всё множество последовательно соединённых станций, или только лишь конечная станция?
Потому что Hg позволяет быть нескольким безымянным головам одновременно. А это уже в случае метро не одна ветка, а несколько, вплоть до всей сети.
> Ничего удивительного. Git — это этакий прокачанный CVS, который отслеживает не отдельные файлы, а группы файлов, и плевать он хотел на историю их содержимого (которое кочует между файлами).
Я не понял логики этого замечания. CVS следил за каждым файлом отдельно, а Git, оказывается, «прокачанный CVS», но за одним файлом уже не следит.
develop7
Да и нет, см. https://www.mercurial-scm.org/doc/evolution/
вероятно, речь об угадывании rename/copy вместо записывания
netch80
> Да и нет,
Я не говорил о публично выставленной части (тут скорее надо сослаться на концепцию Phases), хотя и тут есть разные мнения — иначе бы в `git help rebase` не было секции «Recovering from upstream rebase». Но именно свою локальную работу привести в порядок, по-моему, обязательно.
> вероятно, речь об угадывании rename/copy вместо записывания
Тут я тоже удивляюсь, что мешает в Git добавить запись этих данных, если автор явно хочет. Вероятно, они не считают частный случай настолько существенным (над частичным разбросом содержимого в разные файлы), а детект по содержимому сейчас работает достаточно неплохо (и для log, и для merge).
develop7
Вообще, ЕМНИП, obsolete changesets не видны по умолчанию и, соответственно, не клонируются.
оно там только и исключительно оттого, что любой залетевший в форточку дятел может переписать любой и каждый ref в remote (если не принять к этому меры заранее).
Навскидку: сишечка и скрепы.
да не имеет значения, хорошо он работает или плохо — пока имя файла и путь несут семантическую нагрузку, их правки должны и обязаны записываться.
Scf
За git push -f любому дятлу следует отрывать клюв.
develop7
git push someremote +somebranch, но это тот же самый force pushScf
Нечаянно такое запушить не получится, так что разработка в адекватной команде не пострадает.
а если речь идет о неадекватной команде, то да, хуки или галочки в gui, смотря какой софт используется для репозитория.
develop7
а вот будь в git аналог phases, можно было бы совсем выкинуть кожаных мешков из уравнения
grossws
Одной конкретной явно указанной ветки, а не просто текущей ветки. Гораздо нагляднее и заставляет задуматься перед тем как нажать enter.
develop7
может быть и вообще всех веток, в зависимости от параметра
push.defaultBonart
Фальсификация истории системой контроля версий с внесением ошибок туда, где их не было — это "вообще ни о чем"? Ну-ну.
Это еще почему? Вы после слияния конфликты не правите, тесты не прогоняете, упавшие сразу не чините?
Полностью автоматического слияния в общем случае не бывает, ручные правки являются частью процесса.
Да, после слияния логично ожидать наличия ошибок.
Вот только если вы те же самые коммиты склеите ребейзом — вы получите целую цепочку нерабочих коммитов и заведомо неверный результат поиска места ошибки, если она всплывет не сразу.
Зато история будет красивая и линейная.
В мерке вмсето мержа можно использовать graft AKA transplant, позволяющий копировать коммиты из ветки в ветку с разрешением конфликтов по одному. Связь скопированного коммита с оригинальным сохраняется в метаданных и показывается в дереве. Даже если будет ошибка из-за смены контента — ее легко проверить и установить по оригиналу.
У гита есть аналог cherry pick но он ссылку на оригинальный коммит добавляет только опциально и только в комментарий.
Мержит мерк лучше, поскольку учитывает не только текущее состояние файлов, но и историю их изменений.
И какой смысл рассказывать про чудо-индекс, если хороший тон — это маленькие коммиты, а mq в мерке кроет индекс как бык овцу?
netch80
> Фальсификация истории системой контроля версий с внесением ошибок туда, где их не было — это «вообще ни о чем»? Ну-ну.
Да, именно. Если убрать эмоции и само слово «фальсификация», которое уже содержит в себе эмоциональную оценку, то надо начать с признания, что истории, если она не зафиксирована в некоем авторитетном хранилище, вообще нет. Даже без SCM на локальных файлах можно написать любую историю, а с distributed SCM любого вида это становится тривиально — всегда есть возможность взять другую ветку или рабочую копию и повторить начисто. Поэтому вопрос должен стоять так — чего мы хотим от истории? Видеть коммит промежуточного кривого состояния каждый раз, когда программист отшёл в туалет, или всё-таки набор логически цельных изменений? Не знаю, как у вас, а вокруг меня второе таки преобладает.
> Это еще почему? Вы после слияния конфликты не правите, тесты не прогоняете, упавшие сразу не чините?
> Полностью автоматического слияния в общем случае не бывает, ручные правки являются частью процесса.
Именно потому, что ручные правки при merge предполагают правки именно конфликта, а не произвольного места.
Если у вас в foo.h поменялось getFoo() на getFoo(FooContext*), это не повлияет на неправильное использование уже несуществующего getFoo() в bar.c.
Чаще (по тому, что я видел) делают таки правки после мержа, чтобы разделять логически разные действия в разные диффы. Но это требует возможности отменить тестирование самого merge commit.
> Вот только если вы те же самые коммиты склеите ребейзом — вы получите целую цепочку нерабочих коммитов и заведомо неверный результат поиска места ошибки, если она всплывет не сразу.
Именно поэтому я и рекомендовал при таком ребейзе надо править нерабочие коммиты, а не делать правку им вдогон.
Это не настояние на ребейзе вместо мержа или наоборот. Это именно как сделать такой ребейз беспроблемным для будущего поиска.
> У гита есть аналог cherry pick но он ссылку на оригинальный коммит добавляет только опциально и только в комментарий.
Ну я её добавляю всегда. Автоматизация показа этой связи, возможно, полезна, но пока что не сталкивался с такой необходимостью.
> И какой смысл рассказывать про чудо-индекс, если хороший тон — это маленькие коммиты, а mq в мерке кроет индекс как бык овцу?
Не кроет он никак индекс, потому что для представления патча для mq он уже должен быть чистым от прочих изменений.
ZyXI
Пока дело касается только «внутренних процессов разработчика»
rebase/histeditв Mercurial работает. Чтобы он работал после push пилят changeset evolution. Единственное но: когда я последний раз использовал histedit в mercurial, цепочка «fold fold fold» (аналог «squash squash squash») требовала вводить сообщение об изменении три раза, при этом сохранялся лишь последний. В git всё было нормально. Как сейчас — не знаю.Есть расширение
shelve(в стандартной поставке, но не включено по?умолчанию). Но для вашего use-case же используют что?то вродеhg record.Насчёт последнего: по моему мнению,
git add --interactiveнеудобен, аhg recordнеудобен вдвойне (если его за это время не допилили). Поэтому мной был запилен UI как часть дополнения Vim. Принцип работы является совместимым с любой VCS, единственное требование — возможность указать, в каких файлах изменения нужно зафиксировать (т.е. если вы найдёте VCS, принципиально фиксирующую только все изменения во всех файлах, то … это возможно и принцип будет примерно тот же, но моё расширение придётся сильно допиливать).Ответил выше. Не удивлюсь, если узнаю, что tortoise клиенты используют тот же принцип, что и я (кстати, я, кажется взял его то ли из
hg record, то ли изhg crecord: просто нужно сохранить где?то «полную» версию изменённого файла, а на её место подсунуть то, что вы хотите сохранить).Бардак есть, но у mercurial здесь преимущество: проконтролировать поведение разработчика с ветками?тёгами проще: pre-commit можно и забыть поставить на какой?то машине и вам придётся писать ещё какой?то hook на сервере, чтобы проваливался
push. Сделать так, чтобы у изменения оказалось неправильное имя ветки куда как сложнее (для всех изменений, кроме первого).И откуда взялось «непонятный branch name»? Вам запрещают писать туда номер тикета (причём именно в mercurial: «хук вылавливал номер тикета из имени локальной ветки»)? Тут только вопрос к Web?интерфейсу, будет ли он делать это ссылкой. Технически препятствий нет.
Лично мне в mercurial не хватает возможности изменения истории с помощью допиленного changeset evolution — так можно и приводить в порядок бардак, получая нормальную отображаемую историю, и при том сохранять неизменность истории. «Не хватает» в смысле «не поддерживается на bitbucket» и «официально не допилено» («the full implementation of the changeset evolution concept is still in progress»). Бардак в коммитах в mercurial действительно образуется и с ним нельзя нормально бороться после push — это основное достоинство git в моих глазах. Только с git я уже стрелял себе в ногу с помощью
push -fпослеrebase -i, тогда как с changeset evolution что?то невосстановимо удалить просто невозможно (невосстановимо без помощи администратора github либо контактов с другими разработчиками — я знаю про reflog, и я знаю, что он не поможет, если нужных изменений на моей машине никогда не было).Bonart
Честно говоря, не вижу смысла прятать "бардак", если это объективно отражает историю изменений.
Bonart
Все, кроме гитоводов, привыкли к тому, что ветка растет от ствола или ветки потолще и включает все свои коммиты.
И только в гите ветка — это именованная голова, а принадлежность коммитов определяется только по связям и работает лишь до первого мержа.
Отсоединеннный коммит — это вообще уникальная гитофича, похожая до степени смешения на багу.
Необходимость помнить, запушен ли коммит, после мерка вымораживает.
История файла, меняющаяся при одних и тех же данных при изменении настройки чувствительности поиска совпадений, доставляет отдельно.
Любовь к rebase есть любовь к фальсификации истории в угоду чисто эстетического профита от няшной линеечки коммитов.
Я в свое время компанию-работодателя агитировал на переход с CVS на распределенную систему контроля версий. Сначала хотели на гит, но посмотрев и сравив, выбрали и мерк и не пожалели ни разу.
Я имею опыт эффективной работы с обеими системами, но гит напрягает больше, перекладывая массу мелочей (которые можно контролировать автоматически) на пользователя
netch80
> Все, кроме гитоводов, привыкли к тому, что ветка растет от ствола или ветки потолще и включает все свои коммиты.
> И только в гите ветка — это именованная голова, а принадлежность коммитов определяется только по связям и работает лишь до первого мержа.
Этого я не понял, учитывая, что безымянные головы вроде есть только в Hg, а для остальных различие между этими интерпретациями несущественно.
> Отсоединеннный коммит — это вообще уникальная гитофича, похожая до степени смешения на багу.
Оно существует только при особых режимах работы. Меня вот множественные головы напрягают больше :)
> Необходимость помнить, запушен ли коммит, после мерка вымораживает.
Этого не понял совсем. Сравнение с Hg или CVS/SVN? В любой распределённой системе локальный коммит может быть не запушен.
> Любовь к rebase есть любовь к фальсификации истории в угоду чисто эстетического профита от няшной линеечки коммитов.
«Эстетический профит» превращается в реальную потребность понимать, что происходило, при разборе через 1-2-5-10 лет, когда никто не помнит подробностей происходящего. И главное не линейка, а чёткость и законченность каждого отдельного действия, а также разделение действий по характеру (как минимум, ни в коем случае не смешивать форматирование, рефакторинг и изменение функциональности). Линейчатость удобна, но не критична.
> но посмотрев и сравив, выбрали и мерк и не пожалели ни разу.
Ну так не CVS же выбрали (имел я дело с одной конторой в 2015-м, принципиально сидящей на CVS — это был ужас). Но стоит таки оценить, как это повлияло на методы работы с кодом и с задачами.
dim_s
Все таки, если у вас корпоративный медленный svn сервер, скорость работы с ним падает еще сильнее, если какая-то операция с svn делается 10-30 секунд, то за это время можно случайно на что-то отвлечься и потерять фокус над задачей и эти 10-30 секунд превращаются в 5 минут.
kk86
Привязка к корп серверу и интернету вообще большое зло. Автономность с Hg/Git/… даёт большой выйгрыш при "переключении контекста".
Xandrmoro
Что можно сделать хуже, чем в гите?
(уже ощущаю затылком коллективный пистолет)Bonart
Вы не работали с мерком.