Инструмент для управления репозиториями локального развития

Я веб-разработчик, и я работаю с различными языками и проектами (кто нет?). Я клонировал многие из этих проектов / репозиториев локально в разные каталоги.

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

Короче говоря, мне нужна система для управления репозиториями локального развития. Цель:

  • лучшей личной организации и
  • более быстрая конфигурация в случае, если я куплю новую машину

Хранилища в основном git , но есть svn и даже cvs repos.

Есть ли инструмент, который может помочь мне в этом? Мне бы очень хотелось написать собственное решение (скрипты), чтобы обнаружить, что я изобретаю колесо.

Являются ли инструменты управления конфигурацией (шеф-повар, марионетка, правдивый) хорошо подходят для этой проблемы?

2 Solutions collect form web for “Инструмент для управления репозиториями локального развития”

myrepos может быть уместным здесь; он позволяет управлять несколькими репозиториями исходного кода разных типов. Вы можете описать все свои репозитории в одном файле конфигурации и управлять ими одновременно или по отдельности.

Я не думаю, что централизованный инструмент управления конфигурацией, такой как шеф-повар или Ansible, будет здесь хорошо подходит …

Я сохраняю все сторонние источники в /usr/local/src , независимо от того, происходят они из tarball или стороннего SCM-узла.

(Почему? Потому что префикс установки по умолчанию – /usr/local для большинства пакетов, так почему бы не сохранить источники вместе с двоичными файлами?)

Таким образом, чтобы установить эту новую машину разработки, я просто говорю

 $ cd /usr/local/src $ sudo chown $USER . $ scp -r oldbox:/usr/local/src/* . 

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

Иногда у меня есть несколько версий данного пакета, например, источники, распакованные из последнего стабильного релиза tarball, а также текущая проверка «голова» SCM. В этом случае дерево выглядит

  $ cd /usr/local/src $ mkdir somepkg $ cd somepkg $ tar xvf ~/Downloads/somepkg-*tar* $ mv somepkg-1.2.3 1.2.3 $ git pull http://someserver.example.com/somepkg.git $ mv somepkg head 

То есть, у меня есть параллельные somepkg/1.2.3 и somepkg/head , поэтому я могу переключаться между ними по мере необходимости. Иногда я получаю несколько «стабильных» версий бок о бок, когда по какой-то причине мне нужно использовать несколько стабильных версий.

Вы могли бы подумать, что было бы хорошо хранить все на локальном файловом сервере, но это не работает на нескольких уровнях:

  1. В настоящее время большинство файловых серверов управляют SMB; вы не всегда можете получить тот, который хотите, с помощью NFS или другой сетевой файловой системы, совместимой с POSIX. Это означает, что разрешения накручиваются, некоторые законные имена файлов POSIX запрещены, нечувствительность к регистру может укусить вас и т. Д.

  2. Если вы обычно встраиваете дерево в дерево (например, ./configure && make ), вы autom4te.cache и двоичные выходы, поэтому при каждом изменении полей вам нужно будет make clean && ./configure .

    Вы можете исправить это, всегда создавая не-дерево, но не все пакеты знают, как построить себя таким образом.

  3. Компиляция программного обеспечения на NAS происходит медленно.

Сохранение отдельных копий на каждой машине разработки позволяет избежать этих проблем. Вы все еще должны сказать, что make clean ; ./configure make clean ; ./configure после того, как scp -дерево проверки перейдет в новый ящик, но, выполнив это один раз, вы теперь просто git pull или svn up чтобы вытащить последние изменения с хоста SCM, чтобы получать обновления, а не многократно scp новые деревья к новым коробкам.

Существует несколько попыток создания менеджеров пакетов для Интернета, чтобы лучше решить эту проблему: Bower , Jam , npm , NuGet и т. Д. Проблема заключается в том, что вы, вероятно, не найдете все пакеты, которые хотите использовать в любом одном из них. Вам предстоит управлять источниками, вытащенными из сторонних SCM для обозримого будущего.

  • Скрипт с несколькими арифметическими условиями не работает
  • сценарий оболочки, чтобы присоединиться к 2 файлам на основе 2 столбцов, и если совпадение найдено, напишите несколько полей
  • Какова цель запуска сценария?
  • Определить набор значений для переменной в сценарии оболочки
  • Как распечатать последнее слово, которое содержит разделитель поля
  • sed, как заменить, когда в строке есть «http: //»?
  • Как собрать имя файлов в каждом подкаталоге в текстовый файл в этом подкаталоге?
  • Убедитесь, что $ REPLY находится в диапазоне номеров
  • Как обеспечить, чтобы эхо в файл было очищено?
  • Копирование файла на несколько других файлов с разными именами
  • Передача кликов по ссылкам в rxvt скрипту
  • переименуйте пакет файлов после чтения из исходного файла
  • Linux и Unix - лучшая ОС в мире.