Лучший способ организовать репозиторий подверсии многих маленьких проектов

Три точки

  1. $ myarray содержит ссылку на массив, а не на массив.
  2. $ mayarray и @myarray - разные переменные
  3. Perl на самом деле не делает многомерных массивов

Все ссылки хранятся в скалярах, поэтому все ссылки хранятся в переменные, которые начинаются с $.

[ ... ] создает анонимную ссылку на массив, поэтому [ [1, 2, 3], [4, 5, 6], [7, 8, 9]] создает анонимную ссылку на массив, содержащую 3 анонимные ссылки на массив, каждая из которых содержит 3 скаляра.

Это означает, что присвоение $ myarray присваивает ему ссылку на внешний анонимный массив.

Чтобы получить доступ к тому, на что указывает ссылка два, нужно разыменовать его. Вы можете сделать это, поместив символ для типа того, на что указывает ссылка, перед ссылкой, например @$myarray. Таким образом, $myarray[0] является первым элементом анонимного массива, содержащегося в ссылке $myarray, или вы можете использовать косвенный синтаксис $myarray->[0].

В вашем примере $myarray->[0] содержит ссылку на массив [1,2,3]. Таким образом, на эту ссылку можно ссылаться таким же образом, давая $myarray->[0]->[0] Это говорит о разыменовании $myarray и дает мне первый элемент, который является ссылкой на массив, затем разыщите это и дайте мне первый элемент этого.

Это дает вам второй пример.

Perl позволяет вам опустить -> между ] и [, а также } и { для анонимных хэшей, как синтаксический сахар. Это дает $myarray->[0][0], который является вашим первым примером.

Ваш третий пример ищет первый элемент из @myarray, который отличается от переменной $myarray. если бы вы поместили use strict в начало вашего скрипта, Perl поймал бы эту ошибку за вас.

Хорошей идеей будет поместить

use strict;
use warnings;

в качестве первых двух строк любого скрипта или модуля Perl, поскольку они будут отлавливать множество плохих и потенциально фатальных ошибок в вашей Программе. Если вы отлаживаете программу, то добавление use diagnostics в use strict дает больше подробных сообщений.

5
задан Community 23 May 2017 в 11:48
поделиться

4 ответа

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

Ваш svn repo был бы похож (Ваша первая опция.)

/svnrepo/project1/trunk
/svnrepo/project1/trunk/htdocs
/svnrepo/project1/trunk/css
...
/svnrepo/project1/branches/branch1
/svnrepo/project1/tags/blah
/svnrepo/project2/trunk
/svnrepo/project3/trunk

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

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

править: случайно сохраненные и дополнительные каталоги добавляются для ясности

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

Так как Вы еще не посвящаете себя Подверсии, рассматриваете использование Базара. Это особенно хорошо подходит для управления версиями многих маленьких проектов, так как это имеет очень мало установки наверху.

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

Я думаю, что Ваш лучший выбор является второй опцией: наличие всего кода под единственным repo с htdocs и cgi-каталогами-bin. Это правда то, что необходимо будет проверить весь код, но Вы делаете это однажды, и остальная часть изменений будет намного меньше. Если бы это - рабочий сервер, очевидно, необходимо было бы проверить, что весь код готов к производству: сохраните соединительную линию зеленой, так сказать.

В будущем это могло бы также помочь с устранением дублирующейся функциональности.

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

Во-первых, используйте единый репозиторий. Для примера того, как хорошо единый репозиторий может масштабироваться, посмотрите на репозиторий SVN Apache. Все - один репозиторий.

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

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

/svnrepo/trunk/project1/...
/svnrepo/trunk/project2/...
/svnrepo/deploy/htdocs
/svnrepo/deploy/cgi-bin

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

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

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