Pull to refresh

GIT, HG и прочие DVCS vs VSS, SVN и прочих SVCS: в первых деревья ортогональны, во вторых — смешаны!

Version control systems *
imageКажись, я просёк то, что нигде никто явно не пытается писать — а мне без этого как-то непонятно было. У меня довольно большой опыт работы в VSS и некий опыт присматривания к SVN. А сейчас вот и к GIT-ам всяким присматриваюсь.

На страничке mercurial.selenic.com/wiki/UnderstandingMercurial в конце сказано, что если вы думаете держать в одном репозитории HG несколько родственных проектов, как привыкли в системах типа SVN, то лучше одумайтесь, ибо HG на это не рассчитан. Похоже это потому, что он всегда работает со всей рабочей папкой в целом.

Это хороший пример следствия из того, о чём я хочу сказать: у этих новомодных распределённых систем понятие дерево каталогов и файлов в рабочей папке ортогонально дереву её версий. Это есть второе (после наличия локального репозитория) ключевое отличие этих систем от предыдущих.

В SVN и VSS — различные версии одной и той же рабочей папки предлагалось оформлять соседними папками в других папках репозитория, и соответственно дерево папок репозитория содержало не одну рабочую папку, а целый их набор, лежащих в различных подпапках в отдельно специально сфабрикованной корневой папки репозитория и ряда её служебных подпапок типа branch и trunk. Это приводило систему к необходимости давать пользователю возможность работать то с одной отдельной подпапкой репозитория, то с другой, и копировать одну в другую с сохранением истории, сливать соседние папки одну с другой, и т.п. И, в следствие такого умения, эти системы давали возможность в других подпапках того же репозитория хранить версии рабочих папок других, родственных, проектов. И соответственно, права на разные папки разным людям давать разные. Кому одни вовсе не видеть, кому другие не редактировать.

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

В норме, увидеть на диске одновременно две версии папки из одного такого репозитория — можно только если рабочую папку в состоянии одной версии куда-нибудь скопировать, и потом переключить рабочую папку на отображение другой версии (= забрать в неё из локального репозитория другую версию). Хотя, это больше касается git — потому что в hg, судя и по комментам, и по rg03.wordpress.com/2009/04/07/mercurial-vs-git — для работы с временной веткой зачастую целиком(?) клонируют репозитарий, и именно в соседнюю папку. Ибо репозитарий — он сам себе рабочая папка. Этакая «рабочая папка на стероидах». (Интересно, как на перемещение рабочих папок с библиотеками реагируют среды разработки, настроенные искать исходники библиотек по конкретным путям основной рабочей папки? Или на unix way таких не бывает?)

И права доступа — лишь на репозиторий в целом, средствами файловой системы, либо ручками писать процедурные хаки, которые будут отвергать часть присылаемых из другого репозитория правок, не устраивающих хозяина этого репозитория. Сейчас вот думают как бы наверстать — HG делает subrepos, например…
Tags:
Hubs:
Total votes 11: ↑2 and ↓9 -7
Views 3.2K
Comments 23
Comments Comments 23

Posts