git

[sab123]

Посмотрел старое выступление Линуса про Гит:

https://www.youtube.com/watch?v=4XpnKHJAok8&index=12&list=WL

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

Вторым делом можно заметить, что у него есть и умные мысли: всегда хочется иметь местную ветку, куда хотелось бы складывать изменения каждые полчаса, даже если нет связи с главным сервером. И как раз под это git заточен, и для этого скажем svn чуть тяжеловесен. Поэтому git удобно использовать как пришлепку к старомодным системам типа Perforce или Clearcase: делаешь чек-аут из "большой" системы, создаешь новый репозиторий в git из этого состояния и делаешь промежуточные версии. А потом некоторое состояние засовывается назад в "большую" систему.

Третьим делом, он прямо там рассказывает про кривизну Гита: по его архитектуре, у _каждого_ клиента должна быть полная копия репозитория со всей историей. И поэтому он плохо живет с большими репозиториями.

Морали тут видимо две:

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

2. Система прав доступа в версионировании должна быть двухмерной: по директорию и по ветке.

Comments

[juan-gandhi.livejournal.com]

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

[sab123.livejournal.com]

Ну, вообще-то даже в перфорсе есть ветки. Только гугель их не использует.

[juan-gandhi.livejournal.com]

Ну как это. Когда оркут билдили, собирали черипики в ветку.

[sab123.livejournal.com]

Ну я и говорю, _нормально_ не использует. Черипики - вообще по своей сути редкое извращение.

[juan-gandhi.livejournal.com]

С ними особо-то не поспоришь. Им, может, Ларри сказал, что надо черипики.

[sab123.livejournal.com]

Это скорее Крэйг Силверстин или как его.

[juan-gandhi.livejournal.com]

Ну и Крейг тоже.

[dmitry-vk.livejournal.com]

Собственно, п.1 постепенно проникает в git. Например, если я правильно понимаю, то из shallow clone уже можно коммитить, пушить, пуллить и клонировать (начиная с git 1.9 --- см. https://github.com/git/git/commit/82fba2b9d39163a0c9b7a3a2f35964cbc039e1a ). Фундаментально нет необходимости хранить на клиенте всю историю, и от этого технического требования постепенно избавляются.

[sab123.livejournal.com]

Но рассказывают, что он все равно не живет на больших репозиториях.

[vit-r.livejournal.com]

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

[sab123.livejournal.com]

Не надо путать систему хранения версий с системой билда. (Хотя, конечно, у системы билда тоже есть проблема хранения версий).

[vit-r.livejournal.com]

В этом случае можно пользоваться разными версионными системами на разных уровнях.

[sleepy-drago.livejournal.com]

многое зависит от того хранятся в контроле версий большие двоичные данные.

[sab123.livejournal.com]

С одной стороны, по уму - не должны. С другой стороны - где-то их хранить надо. Когда-то уже давно в Калдере была своя система для хранения SRPMов. Они разбирались на .tgz, которые хранились просто в директориях по имени версии и на патчи вместе с управляющими файлами, которые хранились в э-э-э то ли CVS, то ли RCS.

[sleepy-drago.livejournal.com]

большие двоичные данные могут быть "исходниками" =) про продукты компиляции я не говорю.

[sab123.livejournal.com]

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