Comments 23
UFO just landed and posted this here
UFO just landed and posted this here
1) я пытаюсь понять, как с практик svn перейти к практикам git. Пытаюсь понять, как именно нужно изменить методы, и на каком основании.
2) я не говорил, что гит плохой
2) я не говорил, что гит плохой
UFO just landed and posted this here
Ну, если команда touch создаёт файл в папке our_repo, а bzr add его добавляет в первый репозиторий, не добавляя в него папку not_a_repo — то это уже не совсем оно. Это не получится привычный мне vss-style. Это получается папка и её репозитарий, лежащие внутри рабочей папки другого репозитария, и этим другим полностью игнорируемые.
P.S.: Рассказывая, чем GIT отличается от VSS я почему-то не думал, что придётся ещё и рассказывать и о том, чем VSS отличается от GIT… ;) Но видимо придётся. Только вот с мыслями соберусь…
P.S.: Рассказывая, чем GIT отличается от VSS я почему-то не думал, что придётся ещё и рассказывать и о том, чем VSS отличается от GIT… ;) Но видимо придётся. Только вот с мыслями соберусь…
> «Одновременно на диске увидеть две версии папки из одного такого репозитория невозможно»
Ну какбе
Ну какбе
hg clone -r 1234 old_path new_path
Это у меня случаем не два репозитария окажутся?
А какая разница?
В VSS и SVN — бранчи априори лежат как соседние папки в дереве папок. Но это отчасти облегчается тем, что я вовсе не обязан работать с этим полным деревом, даже скорее наоборот — я должен работать с одной из его подпапок, а на другие у меня и прав может не быть.
Ну в hg тоже, если у вас есть два бранча, по дефолту один будет основным. Вы можете как переключиться на второй в той же папке, так и положить его в соседнюю через hg clone, как вам удобнее.
С правами да, здесь так не получится, но этот вопрос решается по-другому, на уровне репозиториев. То есть если вам нужна защищенная от врагов ветка на сервере, вы клонируете репозиторий на сервере, просите админа поставить вам специальные права на второй репозиторий, и нет проблем.
С правами да, здесь так не получится, но этот вопрос решается по-другому, на уровне репозиториев. То есть если вам нужна защищенная от врагов ветка на сервере, вы клонируете репозиторий на сервере, просите админа поставить вам специальные права на второй репозиторий, и нет проблем.
действительно — судя по rg03.wordpress.com/2009/04/07/mercurial-vs-git/, пользователи hg частенько бранчи делают путём копирования рабочей папки в соседнюю, вместе с репозиторием…
надо бы мне ещё разобраться, как они потом сливаются воедино, а в случае защищённой копии — как её вместе с остальным массивом кода в целостном виде могут разглядывать те, у кого есть право видеть и её…
надо бы мне ещё разобраться, как они потом сливаются воедино, а в случае защищённой копии — как её вместе с остальным массивом кода в целостном виде могут разглядывать те, у кого есть право видеть и её…
Копируем папку (hg clone это то же самое по сути), работаем там, потом из первой папки-репозитория втягиваем изменения из второй (hg pull), получаем обе ветки уже внутри первой папки (вторая ветка не будет видна в файловой системе), и потом сливаем их (hg merge).
А как раз со слиянием проблем-то и нету, клонированный репозиторий сливается так же легко, как и ветка в существующем.
UFO just landed and posted this here
Дочитал бы — поэксперементировал с subrepos сначала. Он вполне подходит для решения многоих задач.
Ну и Forest Extension никто не отменял.
Ну и Forest Extension никто не отменял.
разница в том, что вам больше не надо думать про бэкап на сервере для SVN
и очевидные плюсы в виде работы без инета
и очевидные плюсы в виде работы без инета
Ну в общем-то, описанное мне и не нравится именно у меркуриала.
В git легко ведутся несколько разных связанных проектов в одном репозитории.
Равно же нетрудно ведутся несколько разных связанных проектов в разных репозиториях с подключением одного в другой.
Находясь внутри какой-либо папки внутри, можно попросить дифф только файлов из этой папки, например.
В git легко ведутся несколько разных связанных проектов в одном репозитории.
Равно же нетрудно ведутся несколько разных связанных проектов в разных репозиториях с подключением одного в другой.
Находясь внутри какой-либо папки внутри, можно попросить дифф только файлов из этой папки, например.
Так же, используя gitolite легко можно так же ставить ограничения именно на отдельные папки внутри проекта.
Можно просить историю только файлов, трогающих файлы текущй папки и тд — в git это всё вполне себе естественно.
Просто тут надо ставить себе вопрос — а _надо_ ли держать несколько проектов в одном репозитории?
Это уже вопрос идеологический. В Меркуриал ответ один — не пытайтесь, огребёте.
В гит ответ другой — делайте, если это удобно. В текущем проекте у нас было сперва всё в одном репозитории, потом разделили на три — один с одной частью системы, довольно независимой, один с API этой системы (thrift модули), который через submodule включен в оба других проекта, и третий с сервисом, построенным на базе первого.
При этом, несмотря на то, что из одного репозитория было получено три репозитория, вся история сохранена по каждому проекту, и история не трогающая файлы конкретного репозитория в нём не присутствует более.
Было удобно. Стало удобнее, и более логично. Потребовало только одно — попросить всех закоммитить все свои промежуточные изменения, и потом склонировать два новых репозитория и обновить старый, после чего все продолжили свою работу.
Можно просить историю только файлов, трогающих файлы текущй папки и тд — в git это всё вполне себе естественно.
Просто тут надо ставить себе вопрос — а _надо_ ли держать несколько проектов в одном репозитории?
Это уже вопрос идеологический. В Меркуриал ответ один — не пытайтесь, огребёте.
В гит ответ другой — делайте, если это удобно. В текущем проекте у нас было сперва всё в одном репозитории, потом разделили на три — один с одной частью системы, довольно независимой, один с API этой системы (thrift модули), который через submodule включен в оба других проекта, и третий с сервисом, построенным на базе первого.
При этом, несмотря на то, что из одного репозитория было получено три репозитория, вся история сохранена по каждому проекту, и история не трогающая файлы конкретного репозитория в нём не присутствует более.
Было удобно. Стало удобнее, и более логично. Потребовало только одно — попросить всех закоммитить все свои промежуточные изменения, и потом склонировать два новых репозитория и обновить старый, после чего все продолжили свою работу.
Самый главный постулат — видеть два состояния одного рабочего проекта в разные моменты времени — мне просто непонятен. ЗАЧЕМ?!
Если нужно найти разницу между ними — git diff rev1 rev2
Если нужно проверить есть ли баг в таком-то коммите —
git stash && git checkout oldrev && make && make test && git checkout currev && git stash pop
История при копировании/перемещении? Она есть. git log --follow.
Больше что-то ничего не могу придумать.
Если нужно найти разницу между ними — git diff rev1 rev2
Если нужно проверить есть ли баг в таком-то коммите —
git stash && git checkout oldrev && make && make test && git checkout currev && git stash pop
История при копировании/перемещении? Она есть. git log --follow.
Больше что-то ничего не могу придумать.
Sign up to leave a comment.
GIT, HG и прочие DVCS vs VSS, SVN и прочих SVCS: в первых деревья ортогональны, во вторых — смешаны!