Есть большой проект под системой контроля версий Mercurial. В нем есть некоторая часть (папка), с которой в некоторых случаях целесообразно работать отдельно, без других папок проекта.
Сделать Clone через TortoiseHg с источником (Source) в виде этой папки — не получилось.
В svn можно было запросто извлечь любую подпапку и работать с ней полноценно как с отдельной единицей. Неужели в Mercurial нет ничего подобного?

Здравствуйте, x-code, Вы писали:

XC>Есть большой проект под системой контроля версий Mercurial. В нем есть некоторая часть (папка), с которой в некоторых случаях целесообразно работать отдельно, без других папок проекта.
XC>Сделать Clone через TortoiseHg с источником (Source) в виде этой папки — не получилось.
XC>В svn можно было запросто извлечь любую подпапку и работать с ней полноценно как с отдельной единицей. Неужели в Mercurial нет ничего подобного?

если ты не замечал, данные репозитория находятся в одном каталоге (.hg) -- mercurial не засирает рабочую копию своими служебными каталогами как это делает svn/cvs -- отсюда и такое вот ограничение...

Здравствуйте, zaufi, Вы писали:

Z>если ты не замечал, данные репозитория находятся в одном каталоге (.hg) -- mercurial не засирает рабочую копию своими служебными каталогами как это делает svn/cvs -- отсюда и такое вот ограничение...

Если я знаю полный путь к моей папке, знаю полный путь к .hg, знаю что папка точно находится под контролем версий, то почему нет? Ну и TortoiseHg вполне мог бы просканировать каждую папку пути на предмет наличия там .hg.

Здравствуйте, x-code, Вы писали:

XC>Здравствуйте, zaufi, Вы писали:

Z>>если ты не замечал, данные репозитория находятся в одном каталоге (.hg) -- mercurial не засирает рабочую копию своими служебными каталогами как это делает svn/cvs -- отсюда и такое вот ограничение...

XC>Если я знаю полный путь к моей папке, знаю полный путь к .hg, знаю что папка точно находится под контролем версий, то почему нет? Ну и TortoiseHg вполне мог бы просканировать каждую папку пути на предмет наличия там .hg.

каталог .hg один! и находится в корне репы... во всех других каталогах mercurial ничего не раскладывает...

если погуглить чучуть то оч быстро выяснится что это архитектурная "проблема" и на данный момент она не решена (есть только пожелания как ее можно былобы решить... но "обсуждения" идут уже несколько лет)

в качестве workaround'a кое-кто предлагает пользоваться расширением Forest... ничего не могу сказать о юзабилити -- сам, понятное дело, не пользовал.

Здравствуйте, zaufi, Вы писали:

Z>каталог .hg один! и находится в корне репы... во всех других каталогах mercurial ничего не раскладывает...
Z>>>если ты не замечал, данные репозитория находятся в одном каталоге (.hg) -- mercurial не засирает рабочую копию своими служебными каталогами как это делает svn/cvs -- отсюда и такое вот ограничение...

Я знаю что один, но в упор не вижу проблемы.
Для клонирования все вообще просто.
Допустим, запустили мы некую hg-команду, или вызвали контекстное меню TortoiseHg на папке X по полному пути c:/dir1/dir2/dir3/X
В ЧЕМ проблема просмотреть все папки в цикле
c:/dir1/dir2/dir3/X
c:/dir1/dir2/dir3
c:/dir1/dir2
c:/dir1
на предмет наличия там папочки .hg ?
Редко когда бывает вложенность больше 10, а как правило (если не размещать проекты во всяких идиотских Documents and settings) и того меньше, так что на производительности это вообще никак не скажется.

Для работы с частями репозитория вне большой репы — ну почему-бы не создать собственную папочку .hg в моей отдельной папке, а в служебной информации, которая в ней все равно хранится, не указать все, что необходимо для корректной синхронизации?

Поставить сторонние плагины можно, но непонятно как это будет работать к примеру с гуглокодом.

Здравствуйте, x-code, Вы писали:

XC>Есть большой проект под системой контроля версий Mercurial. В нем есть некоторая часть (папка), с которой в некоторых случаях целесообразно работать отдельно, без других папок проекта.
XC>Сделать Clone через TortoiseHg с источником (Source) в виде этой папки — не получилось.
XC>В svn можно было запросто извлечь любую подпапку и работать с ней полноценно как с отдельной единицей. Неужели в Mercurial нет ничего подобного?

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

Если с частью проекта целесообразно работать отдельно, её целесообразно выделить в отдельный проект в отдельном репозитории, а в общий проект включать соответствующими средствами — svn externals, git submodules, hg subrepositories.

Здравствуйте, x-code, Вы писали:

XC>Для работы с частями репозитория вне большой репы — ну почему-бы не создать собственную папочку .hg в моей отдельной папке, а в служебной информации, которая в ней все равно хранится, не указать все, что необходимо для корректной синхронизации?

и какойже будет default path у этого подкатлога? в оригинальной репе ведь в этом подкаталоге не было ни какого .hg ...
но это не самая большая проблема... если я правильно понял просмотрем кучу трепа "по диагонале" основные пролемы начинаются когда тебе (и еще 10 парням) захочетсяя пушнуть свои изменения обратно...

XC>Поставить сторонние плагины можно, но непонятно как это будет работать к примеру с гуглокодом.
ну, как я уже говорил, такое мне не было нужно ни разу... чтобы узнать что будет видимо нужно попробовать -- возможно на какомнь тестовом проекте

Здравствуйте, Centaur, Вы писали:

> hg subrepositories.

А как с subrepos делать:

1. hg status рекурсивно по всему дереву репозиториев?

2. hg diff по всему дереву репов, чтобы получить один готовый patch?

3. external diff через графические тулзы по всему дереву репов?

4. bundle всего дерева репов в один файл?

Здравствуйте, Аноним, Вы писали:

А>А как с subrepos делать:
А>1. hg status рекурсивно по всему дереву репозиториев?
А>2. hg diff по всему дереву репов, чтобы получить один готовый patch?
А>3. external diff через графические тулзы по всему дереву репов?
А>4. bundle всего дерева репов в один файл?

Это всё не нужно и вредно. Отдельный проект — это отдельный проект. Все изменения в нём должны быть ограничены им одним и не выходить за его пределы.

Здравствуйте, Centaur, Вы писали:

C>Это всё не нужно и вредно. Отдельный проект — это отдельный проект. Все изменения в нём должны быть ограничены им одним и не выходить за его пределы.

Есть несолько проектов и зависимости между ними. Проекты лежат каждый в своем репозитории. Но есть и parent проекты, которые связывают основной проект и его зависимости.

Как тогда удобно работать с этим parent проектом (репозиторием)? Изменения часто делаются в нескольких проектах (subrepos) сразу, т.к. есть зависимости между ними.

C>Если с частью проекта целесообразно работать отдельно, её целесообразно выделить в отдельный проект в отдельном репозитории, а в общий проект включать соответствующими средствами — svn externals, git submodules, hg subrepositories.

У нас в проекте лежат сорцы проекта и папка, в которой команда тестирования хранит сценарии автоматического интеграционного тестирования. Им для работы со сценариями (создание/обновление) не нужны сорцы проекта, поэтому они просто берут эту папку и работают с ней.

Ваша уверенность, что если что-то Вам не нужно, то это не нужно никому просто поражает.

Здравствуйте, avpavlov, Вы писали:
A>Ваша уверенность, что если что-то Вам не нужно, то это не нужно никому просто поражает.
Вот потому и не стоит увлекаться этими dvcs, что им все "вредно" да "не нужно".

Здравствуйте, Mr.Cat, Вы писали:

MC>Вот потому и не стоит увлекаться этими dvcs, что им все "вредно" да "не нужно".

Просто признать, что hg subrepos пока неюзабельны фанаты признать не могут похоже )