Подверсия - соединительная линия является действительно лучшим местом для основной разработки?
В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.
При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.
Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».
Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример:
public class Some {
private int id;
public int getId(){
return this.id;
}
public setId( int newId ) {
this.id = newId;
}
}
И в другом месте вашего кода:
Some reference = new Some(); // Point to a new object of type Some()
Some otherReference = null; // Initiallly this points to NULL
reference.setId( 1 ); // Execute setId method, now private var id is 1
System.out.println( reference.getId() ); // Prints 1 to the console
otherReference = reference // Now they both point to the only object.
reference = null; // "reference" now point to null.
// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );
// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...
Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.
10 ответов
Ваша соединительная линия должна ВСЕГДА компилировать, если необходимо внести повреждающиеся изменения, необходимо использовать ответвление и объединить изменения назад позже.
Read эта глава книги SVN: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html
Это действительно зависит от Вашей среды. В некоторых случаях повреждение соединительной линии временно не является грандиозным предприятием. Но если бы Вы работаете больше чем с 2-3 людьми, которые, вероятно, не были бы хорошей идеей.
В этом случае, я думал бы с помощью ответвлений более свободно , хорошая идея. Их достаточно легко настроить и повторно объединиться (если Вы не позволяете вещам стать слишком далекими из синхронизации).
, Конечно, если все Ваши разработчики используют то же ответвление, Вы ничего действительно не получите - у Вас просто будет своя соединительная линия названной/branch/dev, но повреждение его все еще было бы главной проблемой! Сломайте ответвления так, чтобы только несколько разработчиков работали над каждым, и необходимо быть хорошими.
Я рекомендовал бы читать этот статья о лучших практиках SCM.
Извлеченный из статьи:
Имеют магистраль. "Магистраль" или "соединительная линия", является ответвлением строки кода, которая развивается навсегда. Магистраль предоставляет окончательному месту назначения почти для всех изменений - и обслуживание фиксирует и новые возможности - и представляет основную, линейную эволюцию программного продукта. Выпустите строки кода, и строки кода разработки переходятся от магистрали, и работа, которая происходит в ответвлениях, распространена назад к магистрали.
Редактирование: Я также рекомендовал бы читать Шаблоны SCM .
Соединительная линия - то, где продолжающаяся разработка, как предполагается, происходит. У Вас действительно не должно быть проблемы со "взломанным" кодом, если все тестируют их изменения прежде, чем фиксировать их. Хорошее эмпирическое правило состоит в том, чтобы сделать обновление (получите весь последний код от repos) после кодирования изменений. Затем создайте и сделайте некоторое поблочное тестирование. Если все создает и работает, необходимо быть хорошими для регистрации его.
, Когда Вы подготовитесь к выпуску, сделайте ответвление. Тест может сделать их проверку выпуска против ответвления. Если проблемы найдены, фиксация (s) сделаны к ответвлению и соединительной линии, и новое сокращение ответвления дано тесту. Между тем разработчики деловито добавляют новые изменения в соединительной линии.
, Таким образом... проблемы, определенные тестом и блестящими решениями этих тривиальных проблем, являются текущими в обоих ответвление и соединительная линия, у тестовых людей есть стабильное сокращение для работы с, и разработка продолжила продвигаться, тест whilest проверил текущий выпуск.
Как Hanibal, всегда говорившийся относительно "A-команды", "Я люблю его, когда план объединяется".
У команд, которые используют Подверсию часто, есть патологическое отвращение к слиянию, потому что до 1,5 это был долгий сложный процесс, подверженный отказу. Если у Вас будет достаточно разработчиков так, чтобы наличие всегда рабочей соединительной линии было абсолютно необходимо, так как многие люди работают над многими различными модулями, которые сотрудничают, разветвленная разработка, конечно, поможет.
Между прочим, даже когда Вы переименовываете файл, Вам все еще разрешают отредактировать его. Я делаю это все время.
Я создал несколько сценариев оболочки для упрощения создающих недолгих ответвлений разработки:
# Create new branch and switch to it
function svn_bswitch()
{
branch=$1; shift
msg="$1"; shift
URL=$(svn info . | sed -ne 's@URL: \(.*\)@\1@p')
REPO=$(svn info . | sed -ne 's@Repository Root: \(.*\)@\1@p')
BRANCH_URL=$REPO/branch/$branch
svn copy $URL $BRANCH_URL -m "$msg"
}
# Switch to a branch or tag
function svn_switch()
{
d=$1; shift
REPO=$(svn info . | sed -ne 's@Repository Root: \(.*\)@\1@p')
URL=$REPO/$d
svn switch $URL
}
Нет соединяют магистралью, не лучшее место. В нашей организации мы всегда следуем за этим подходом: Соединительная линия содержит код выпуска, таким образом, это всегда компилирует. С новым каждый выпуск/этап мы открываем новое ответвление. Каждый раз, когда разработчик честно признается объект, он создает новое ответвление к этому ответвлению выпуска и объединяется, оно в выпуск переходит только после тестирования его. Ответвление выпуска объединяется в соединительную линию после тестирования системы.
приложенное изображение является сырым представлением. 
Другой пример того, когда старая добрая "стабильная соединительная линия, dev в ответвлении" процесс становится проблемой:
Вы разрабатываете веб-приложение, которое зависит от большого количества живых, возможно внесенных пользователями, данные. Вы можете по некоторым причинам не , просто генерируют другой экземпляр бэкенда базы данных (-s) или внешних файловых систем, от которых Вы зависите. (Например, Ваша среда могла бы испытывать недостаток в миграциях модели данных)
, Команда A разрабатывала новую возможность F в/branches/F. Команда B только что запустила другое ответвление для устранения некоторых проблем производительности, которые происходят на живом сайте в/branches/P, и первая вещь , Команда B должна сделать, осуществляют рефакторинг набор таблиц базы данных и/или как файлы размечаются во внешней файловой системе. Это заставляет Команду должной быть осуществлять рефакторинг много их нового материала, прежде чем они смогут продолжить разработку. Затем Команда C входит и делает другую вещь... И внезапно у всех есть проблема.
Затем прибывает фаза слияния - и после этого никто когда-либо want's для использования TortoiseSVN больше.
В нашей компании у нас есть ночная сборка соединительной линии. Ожидается, что все тестируют их код так, чтобы это по крайней мере скомпилировало, прежде чем они будут регистрировать его. Если ночная сборка перестала работать, незаконный код удален, пока не зафиксировано.
я думаю, что самая важная часть - чтобы все поняли роль подверсии и почему важно, чтобы они зарегистрировались только в коде, который компилирует.
Нет, ствол - не лучшее место для фиксации кода уровня разработки. В нашей среде мы рассматриваем ствол как зеркало всего, что было развернуто в производственной среде. Рабочий процесс может отличаться для веб-разработки и разработки приложений, но ствол должен содержать последние производственные изменения.
Мы работаем над ветвями разработки, то есть ветками / feature1, и создаем тег qa, копируя ветки / feature1 -> tags / feature1- qa1 и исправьте все ошибки в ветках / feature1, чтобы создать теги / feature1-qa1 и так далее. Когда все будет готово к развертыванию, все изменения, которые произошли в ветвях / feature1 с момента последнего слияния в магистраль, объединяются в магистраль перед созданием последнего тега выпуска, то есть тегов / 5.1.0.
Рабочий процесс может варьироваться в зависимости от того, как настроена ваша команда или в каком типе проекта / среды вы находитесь.