git/mercurial, набор проектов

[t.t]

Возник вопрос возможности работы с одним подкаталогом из репозитория как с отдельныи репозиторием. Интересно узнать, как с этим в git. Потому как в mercurial есть subrepo, но, насколько я понял из документации, пока у него есть недоработки, которые, конечно, будут исправляться, но вот вопрос когда.

[/dev/random]

Что именно требуется? Описание задачи не совсем понятно.

[sash-kan]

t.t
скорее всего, ты имеешь в виду то, что называется submodule.

p.s. что-то заржавела у меня эта тема за отсутствием времени на разборки с mercurial-ом.

[t.t]

Возник вопрос возможности работы с одним подкаталогом из репозитория как с отдельныи репозиторием. Интересно узнать, как с этим в git. Потому как в mercurial есть subrepo, но, насколько я понял из документации, пока у него есть недоработки, которые, конечно, будут исправляться, но вот вопрос когда.

Совсем забыл (наверное потому, что раньше не было нужно): есть ведь forest. Собственно, на его функционале идея subrepo и основана.

[t.t]

Что именно требуется? Описание задачи не совсем понятно.

Есть проект, состоящий из множества отдельных приложений. Хочется хранить всё в одном репозитории, но при этом иметь возможность с каждым приложением работать отдельно, как с самостоятельным репозиторием.

[t.t]

t.t
скорее всего, ты имеешь в виду то, что называется submodule.

Почитал немного про него. Похоже.

[sash-kan]

Хочется хранить всё в одном репозитории, но при этом иметь возможность с каждым приложением работать отдельно, как с самостоятельным репозиторием.

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

p.s. может быть, имеет смысл отрезать твой вопрос от этой эпичной темы?

[t.t]

p.s. может быть, имеет смысл отрезать твой вопрос от этой эпичной темы?

Раз обсуждение пошло в таком ключе, то имеет.

[t.t]

Хочется хранить всё в одном репозитории, но при этом иметь возможность с каждым приложением работать отдельно, как с самостоятельным репозиторием.

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

Тут есть два "но". По структуре развития проекта добавлять новые репозитории имеют право все разработчики, т.е. недостаточно начинить makefile уже существующими пунктами, нужна какая-то автоматизация. Понимаю, что решаемо, но всё же дополнительная сложность. И второе: часть разработчиков работают вне офиса, т.е. доступ получают по внешнему ip; все остальные -- по локалке. Ещё одна дополнительная сложность.

[sash-kan]

нужна какая-то автоматизация

дело техники. пример:
мои репозитории лежат у меня на сервере в ~/var/gits :
$ ls ~/var/gits
project1.git
project2.git
доступ к нему у меня по ssh.
там, где мне надо работать, можно сделать такой примерно файлик:

Shell

$ cat GNUmakefile %.git: -[ ! -e $(patsubst %.git,%,$@) ] && git clone ssh://server/~/var/gits/$@

чтобы склонировать project1:
$ make project1.git
будет сделан клон в каталог ./project1
это так можно получать клоны для новых, ещё пока не «прописанных» в мэйкфайл репозиториев.
а прописывать можно как-нибудь так (полный вариант файла):

Shell

$ cat GNUmakefile projects=project1 project2 gits=$(patsubst %,%.git,$(projects)) projects: $(gits) %.git: -[ ! -e $(patsubst %.git,%,$@) ] && git clone ssh://server/~/var/gits/$@

$ make projects
и вуаля.

p.s. ну а сам это мэйкфайл можно включить в некий мета-проект. и развёртывание репозиториев будет выглядеть примерно так:

Shell

$ cd <куда надо> $ git clone <путь к этому мета-проекту> . $ make projects

p.p.s. мэйкфайл, конечно, кривоват. но я пока не make-гуру.

И второе: часть разработчиков работают вне офиса, т.е. доступ получают по внешнему ip; все остальные -- по локалке. Ещё одна дополнительная сложность.

не вижу, в чём тут хоть какая-то сложность.

[t.t]

И второе: часть разработчиков работают вне офиса, т.е. доступ получают по внешнему ip; все остальные -- по локалке. Ещё одна дополнительная сложность.

не вижу, в чём тут хоть какая-то сложность.

Тут уже сложность не технического, а организационного характера. Пока склоняюсь к мысли, что проще всего будет использовать forest.

[kamre]

Хочется хранить всё в одном репозитории, но при этом иметь возможность с каждым приложением работать отдельно, как с самостоятельным репозиторием.

я тоже когда-то озадачивался такой «хотелкой».
по здравом размышлении пришёл к выводу, что ну его в баню.
и лучше реализовать что-то вроде проекта-«пускалки».

А как при этом разруливается состояние проекта? Оно состоит из состояний всех подпроектов, т.е. где-то должен храниться snapshot с ревизиями всех подпроектов.

При переключении проекта на другую ревизию каждый подпроект должен переключаться на соответствующую ему ревизию. Как это делается?

[t.t]

Хочется хранить всё в одном репозитории, но при этом иметь возможность с каждым приложением работать отдельно, как с самостоятельным репозиторием.

я тоже когда-то озадачивался такой «хотелкой».
по здравом размышлении пришёл к выводу, что ну его в баню.
и лучше реализовать что-то вроде проекта-«пускалки».

А как при этом разруливается состояние проекта? Оно состоит из состояний всех подпроектов, т.е. где-то должен храниться snapshot с ревизиями всех подпроектов.

При переключении проекта на другую ревизию каждый подпроект должен переключаться на соответствующую ему ревизию. Как это делается?

А зачем общее состояние проекта и общие ревизии? Я для того и думаю разнести все программы по отдельным "репам", чтобы в этом всём каши не было. Иначе мне смысл самого разделения хранилищ не очень понятен.

[kamre]

А зачем общее состояние проекта и общие ревизии?

Выделяем библиотеки в подпроекты. Тогда основной проект должен знать с какими ревизиями библиотек сейчас согласован его код.
Получается примерно так:

Код: Выделить всё

project/
       .hg/
       src/
       libA/
          .hg/
          src/
       libB/
          .hg/
          src/

Я для того и думаю разнести все программы по отдельным "репам", чтобы в этом всём каши не было. Иначе мне смысл самого разделения хранилищ не очень понятен.

А какой смысл общего репозитория, если программы независимы?

[t.t]

Нет, они не независимы, из них всех одна прошивка собирается; в частности, библиотеки общие там тоже есть. Я сразу не совсем правильно понял, о чём речь. А так да, ещё один аргумент в пользу forest.

[sash-kan]

А как при этом разруливается состояние проекта?

чтобы связать состояния подпроектов — используйте submodules в git-е или forest (рекомендуемый t.t) в mercurial.
то, что описано мной как «пускалка» — это работа с несвязанными (по крайней мере не жёстко связанными) между собой проектами. мне как раз такое и было нужно.