Вопросы Теги

Когда мультимодуль должен спроектировать для разделения на отдельные деревья репозитория?

Это работает для меня: 

def p = 'ps aux'.execute() | 'grep foo'.execute() | ['awk', '{ print $1 }'].execute()
p.waitFor()
println p.text

по неизвестной причине, параметры awk не могут быть отправлены только с одной строкой (я не знаю, почему! Возможно, bash цитирует что-то по-другому ). Если вы сбросите с помощью команды поток ошибок, вы увидите ошибку относительно компиляции awk-скрипта.

Изменить: Фактически,

  1. "-string-".execute() делегировать to Runtime.getRuntime().exec(-string-)
  2. Это задание bash для обработки аргументов, содержащих пробелы с «или». Runtime.exec или ОС не знают кавычки
  3. Выполнение "grep ' foo'".execute() выполняет команду grep, с ' в качестве первых параметров, а foo' - вторым: это неверно. То же самое для awk
6
задан Rich Seller 21 July 2009 в 18:47
поделиться

4 ответа

Книга Подверсии содержит два раздела по этому:

Запись в блоге на предмете: "Расположение Репозитория подверсии"

Короткий ответ, хотя: в то время как Ваш пробег будет варьироваться (каждая ситуация является отдельной), Ваш /bundle/<project>/(trunk|tags|branches) схема довольно распространена и будет, вероятно, работать хорошо на Вас.

7
ответ дан 8 December 2019 в 14:49
поделиться

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

branches
  project-name
    module1
      branch-name
    module2   
      possibly-another-branch-name
    branch-name-on-a-higher-level-including-both-modules
      module1
      module2
tags
  ... (same as branches)
trunk
  project-name
    module1
    module2

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

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

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

6
ответ дан 8 December 2019 в 14:49
поделиться

Просто мои два цента...

Я просто хочу подчеркнуть комментарий в документации SVN (уже заключенный в кавычки в другом ответе, том же потоке) http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

Выборка ссылается на следующую структуру: / соединяют / магистралью calc/календарь/, электронная таблица / … отмечает / calc/календарь / электронная таблица / … ответвления / calc/календарь / электронная таблица /

"Нет ничего особенно неправильного о таком расположении, но оно может или не может казаться как интуитивное для Ваших пользователей. Особенно в больших, многопроектных ситуациях со многими пользователями, те пользователи могут быть склонны быть знакомыми только с одним или двумя из проектов в репозитории. Но projects-as-branch-siblings имеет тенденцию преуменьшать роль индивидуальности проекта и внимания на весь набор проектов как единственный объект. Это - социальный вопрос все же. Нам нравится наше первоначально предложенное расположение по чисто практическим причинам — легче спросить о (или изменить или мигрировать в другом месте) вся история единственного проекта, когда существует путь единого репозитория, который содержит всю историю — мимо, подарок, отмеченный, и перешел — для того проекта и одного только того проекта".

Для моего собственного я склонен соглашаться вполне сильно с этим и предпочитать следующее расположение: / utils/calc/соединяют теги / магистралью / ответвления/, календарь / соединяют теги / магистралью / ответвления / … офис/, электронная таблица / соединяют теги / магистралью / ответвления /

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

Давайте использовать пример: Если проект 1 зависит от moduleA v1.1 и moduleB v2.3, я не хочу, чтобы более новый moduleA v2.x появился в тегах. На самом деле, при возвращении несколько дней/недель/месяцев спустя к этому теговому выпуску, я был бы вынужден открыть дескриптор пакета в теговой версии проекта 1 считать версию moduleA, на самом деле требуемого.

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

Это были просто мои два цента.

3
ответ дан 8 December 2019 в 14:49
поделиться

Я ответил на подобный вопрос в вопросе о Структуре Управления версиями StackOverflow. Это на самом деле соответствует еще лучше здесь, так как мы делаем тяжелую разработку OSGi и имеем много пакетов. Я должен повторить комментарии Anders Sandvig: сохраните соединительную линию/теги/ответвления на корневом уровне, так как Вы только перейдете ограниченный набор модулей. Это также не вмешивается в модули, создающие индивидуально.

Я не скопирую ответ, который я сделал, прежде, но это совершенно относится к этому вопросу.

0
ответ дан 8 December 2019 в 14:49
поделиться
Другие вопросы по тегам:

Похожие вопросы: