Несколько репозиториев в одном каталоге (одного уровня) - возможно ли это?

Question

Моя изначальная проблема в том, что у меня есть каталог, в котором я пишу различные скрипты Каждый из них не зависит от других и обычно состоит из одного файла. Я хочу применить к ним некоторые версии, но у меня есть следующие проблемы / требования:

1. Я не хочу, чтобы должен был хранить каждый маленький скрипт в отдельном каталоге !
2. Я не хочу хранить их все в одном хранилище OTOH, поскольку они совершенно не связаны, и:
   • некоторые из них могут позже вырасти до большего количества файлов (и тогда им понадобится отдельный каталог),
   • Иногда мне хочется скопировать один из них на другой компьютер (и я хочу клонировать весь репозиторий).
3. I хочу воспользоваться (распределенными) механизмами контроля версий - как минимум:
   • «бесконечное» количество ревизий,
   • возможность клонировать репозитории на разных компьютерах,
   • возможность делать "атомарные" многофайловые коммиты.

Возможно ли это?
Я бы предпочел сделать это в некоторых распространенных VCS (решение с использованием Mercurial было бы предпочтительнее, но я не исправлен).

РЕДАКТИРОВАТЬ: решение должно быть бесплатным (по крайней мере, "как в пиве") и кроссплатформенным (по крайней мере, Win32 и Linux).

Связано, но не помогло:

• "two-git-repositories-in-one-directory" - не нашел это полезным: принятый ответ для меня выглядит как пункт 2. (выше); текущий ответ "Голосование сообщества" звучит как 1.
• «Контроль версий отдельных файлов с использованием Subversion» - также слишком много 2. или 1.

Answer 1

Эти требования кажутся мне довольно «особыми», так что вот решение наравне с ними ^^

Вы можете использовать два совершенно разных VCS в одном каталоге. Даже два «экземпляра» SVN могут работать: SVN хранит свои метаданные в каталоге с именем .SVN и имеет (по историческим причинам, касающимся ASP) возможность использовать _SVN. Список в каталоге должен выглядеть следующим образом

.SVN    // Metadata for rep1
_SVN    // Metadata for rep2
script1 // in rep1
script2 // in rep2
...

Конечно, вам нужно будет скрывать или игнорировать сторонние скрипты или папки из каждого VCS ...

Добавлено: Это учитывает только два сценария в одной папке и требует одну дополнительную VCS на сценарий сверх этого, поэтому, если вы даже рассмотрите этот маршрут и вам нужно больше репозиториев, переименуйте каждый Metadir и используйте сценарий для переименования его обратно перед обновлением:

MOVE .SVN-script1 .SVN
svn update
MOVE .SVN .SVN-script1

Answer 2

Вы можете создать несколько скрытых каталогов репозитория и символическую ссылку .hg на ту, какую хотите активировать.Поэтому, если у вас есть два репозитория, создайте для них каталоги:

.hg_production
.hg_staging

Затем, чтобы активировать любой из них, просто выполните:

ln -sf .hg_production .hg

Вы можете легко создать команду bash, чтобы сделать это.Таким образом, вместо этого вы можете написать что-то вроде activate-repo production, которое будет запускать ln -sf .hg_production .hg.

Примечание: Mac, похоже, не поддерживает ln -sf, поэтому вместо этого вам нужно будет сделать:

rm .hg; ln -s .hg_production .hg

Answer 3

Еще одно предложение для моего собственного рассмотрения - Статья «Использование преобразования для разложения вашего репозитория» на hgtip.com .Он не работает как «автономное» решение, но может быть полезным как дополнение к идее «mv .hgN .hg / MOVE .SVN-script1 .SVN».

Answer 4

Почему бы вам просто не создать отдельную ветку (в смысле git) для каждого (группы) сценариев?

Вы можете разрабатывать их по своему усмотрению. Переключение на ветку покажет вам только скрипты из этой ветки. Это что-то вроде каталогов, но управляется системой контроля версий. Если позже вы захотите вставить ветку в другой репозиторий, вы можете сделать это, и если вы хотите объединить два скрипта в один проект, вы можете сделать это также. Копирование их на другой компьютер может быть проблемой, но вы можете клонировать интересующую вас ветку, и она должна работать для вас.

Answer 5

Как насчет компромисса между 1 и 2? Вместо папки + репо для каждого сценария, можете ли вы объединить их в слабо связанные группы, такие как «база данных», «резервная копия» и т. Д., А затем создать одну папку + репо для каждой группы? Затем, если вы клонируете репозиторий на другом компьютере, вы загружаете только меньшее количество несвязанных файлов. (Является ли пропускная способность / дисковое пространство действительно проблемой?) Для меня это звучит намного проще, чем все другие предложения.

(Технически этот подход соответствует вашим требованиям, поскольку (1) каждый сценарий не находится в своем собственном каталоге, (2) не все сценарии находятся в одном и том же хранилище, и (3) вы можете легко сделать это с любой популярной DVCS. : D)

Answer 6

ОБНОВЛЕНИЕ (2016): Видимо, парень по имени Cosmin Apreutesei создал инструмент с именем multigit , который, кажется, реализует то, что я хотелв этом вопросе!Если вы когда-нибудь прочитали это, спасибо большое Cosmin! Я начал использовать ваш инструмент в этом году и нашел его потрясающий .

---

IЯ начинаю думать о каком-то наложении на Mercurial / git / ..., которое сохранит пару «отключенных» мета-каталогов репозитория, скажем:

.hg1/
.hg2/
.hg3/

и т. д., и затем наhg commit FILENAME найдет конкретный .hgN, который связан с FILENAME, и затем временно:

mv .hgN .hg
hg commit FILENAME
mv .hg .hgN

Главный недостаток состоит в том, что мне потребуется некоторое время на написание инструмента.Или кто-нибудь знает какой-нибудь готовый как этот?Если вы это сделаете, пожалуйста, напишите как полнофункциональный ответ (не комментарий), я более чем готов принять его.

Answer 7

Я могу думать только об этих двух легких системах управления версиями:

1) Использование Dropbox с обновлением Pack-Rat для сохранения полной истории версий для каждого файла, автоматически сохраняемого в резервной копии и с возможностью совместного использования несколькими пользователями Dropbox: https://www.dropbox.com/help/113

Если у вас есть несколько компьютеров, управляемых одним и тем же пользователем (вами), синхронизация будет автоматической. Кроме того, если машины находятся в одной локальной сети, Dropbox достаточно умен, чтобы синхронизировать файлы по локальной сети, поэтому большие файлы не должны беспокоить.

2) Использование текстового редактора с поддержкой версий для Mac OS X Lion . Я ожидаю, что TextMate, Coda и другие популярные редакторы кода Mac будут обновлены для поддержки этой функции, когда выйдет Lion.