Создание перемещения к управлению исходным кодом

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

10
задан 20 December 2010 в 16:06
7 ответов

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

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

И, чтобы не обратиться к обращениям к полномочиям или чему-либо, но проверить то, что Joel Spolsky должен сказать относительно темы. (Кавычка выбора: "Подверсия = Пиявки. Подвижный и Мерзавец = Антибиотики".) Среди прочего, он делает интересное замечание, что эти новые системы используют новую умственную модель, отличающуюся от традиционного управления версиями — который является, почему вхождение в этот вид подхода с начала является победой.

10
ответ дан 2 December 2019 в 22:01

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

Насколько начальные ловушки идут, Вы должны, не придется волноваться очень; передайте все серверу и если это не корректно, можно переставить его вокруг и удалить дополнительный материал позже. Единственной вещью, которую я не фиксировал бы, являются артефакты, которые создаются из источника, т.е. файлы кода Java принадлежат управления версиями, но не скомпилированных классов или всего ISOs / DVD "созданного из источника" двоичные файлы.

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

/trunk/project/branches/project/version1/branches/project/version2/branches/project/version3

Так скажем, Вы находите ошибку в версии 2 продукта, Вы перешли к тому ответвлению, фиксируете его, и версия выпуска 2.1. Все время Вы работаете над/trunk/project папкой для новой версии 4 и Вам решать какие функции объединяются назад и вперед.

Не позволяйте SCM kool-помочь дураку пьющих Вы, существует очень мало функциональных различий между популярными системами управления версиями там, а именно, Подверсия и Мерзавец. Самая важная вещь для Вашей команды будет состоять в том, как хорошо те серверы интегрируются с Вашими существующими инструментами. Мне не нравится WYSIWYGs или но уверенный хорошо иметь затмение-php или другие IDE, которые совместимы с сервером.

3
ответ дан 2 December 2019 в 22:01

Я - разработчик и был вовлечен в работу администратором IT прежде.

Отвечать на Ваши конкретные вопросы:

1) Да, Присвойте версию всему.

2) Предположите установку фиктивного репозитория управления версиями и фиктивного проекта для людей учиться на.

3) Отметьте версии, которые введены в эксплуатацию. даже пробные версии. Затем можно всегда проверять определенную версию, которую кто-то выполняет.

Я вижу, что Вы отметили вопрос CVS.

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

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

Может также быть выгодно установить один из веб-интерфейсов в cvs или подверсию.

Причина я предлагаю подверсию по CVS, состоит в том, что, в то время как CVS очень хорош, он имеет некоторые серьезные проблемы разработки и реализации. Важные персоны для меня были: 1) Вы не можете каталоги версии 2), обработка Двоичного файла не слишком хороша как много вещей значение по умолчанию к тому, чтобы быть текстом. 3) Никакие атомарные фиксации. 4) я вспоминаю это часто портить и отъезд файлов блокировки, вокруг которых я должен был удалить вручную из хранилища кода. Была комната для повреждения в выполнении этого начиная с Вашей комнаты файлы блокировки. 5) Поддержка SSL и руководящие пользователи/пароли

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

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

Этот веб-сайт мог бы иметь некоторую выгоду (хотя я не могу ручаться за него): Установка модульного репозитория SVN для php веб-сайтов http://www.howtoforge.com/set-up-a-modular-svn-repository-for-php-websites

3
ответ дан 2 December 2019 в 22:01

С большим уважением к большой части мудрости, которая появляется выше - и это мудро - развертывание управления версиями похоже на развертывание систем контроля. Мои клиенты говорят, "что должно я контролировать", и очевидный ответ является "монитором все". Но это не желанные новости: у них есть 350 систем, каждая из которых имеет 20-30 системных переменных плюс набор определенных для использования переменных, и они могли все полезно контролироваться; но существует только один из меня, и они хотели бы видеть некоторые результаты в двух неделях.

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

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

Мало того, что это даст Вам лучший возврат для инвестиций-разового, но это дает Вам в свою очередь веские причины для расширения использования управления версиями в будущем: "Так как мы добавили управление версиями к коду приложения, незапланированные отключения электричества, которые более чем 30 минут отбросили от 11 в месяц к 2. Те два были вызваны статическими изменениями HTML, таким образом, мы предназначаем к управлению версиями их затем"..

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

Редактирование 1: если Вы решаете пойти этим путем, дешевая поскольку микросхемы поддержка должна добавить растяжку на вершине, по крайней мере, на производственном поле. Тот путь, если Вещи Повреждаются, но VCS, говорит, что это было ничто, за что он в настоящее время несет ответственность, можно быстро определить то, что изменилось, который обе скорости фиксация и предлагает следующего кандидата на управление версиями.

3
ответ дан 2 December 2019 в 22:01

Управление версиями все. Нет никакого смысла имеющего файлы HTML при управлении версиями и затем имеющий сайт, полностью завинченный из-за изменения в CSS, которым не управляют и поэтому нельзя легко инвертировать.

Ловушки: Я лично не столкнулся ни с кем во время своего по общему признанию довольно ограниченного использования управления версиями.

Развертывание: Я в настоящее время использую подверсию, размещенную на полях Windows, и на работе и дома. Windows только потому, что, именно это доступен. Иначе это, возможно, столь же легко была другая ОС. Ключ для нетехнических пользователей i, чтобы дать им простой основанный на GUI инструмент для обработки импорта, экспорта, фиксаций, diffs, и т.д. Какой инструмент использовать будет зависеть немного от ОС и используемой системы VCS.

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

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

2
ответ дан 2 December 2019 в 22:01

Присвойте версию всему.

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

Если Вы пойдете с "контролем непосредственно в сайт клиента" модель распределения, то Вы захотите быть уверенными, что Ваш сервер исключает доступ к каталогам управления версиями так, чтобы люди не могли просмотреть на http://example.com/.git/ и посмотреть в Ваши внутренности. Кроме того, у меня определенно были бы тест и производство virtualhost для каждого клиента, чтобы удостовериться, что обновление сайта не выходит из строя. Особенно при внесении пользовательских изменений в файлы отдельных клиентов затем необходимо будет обработать конфликты, прежде чем изменения пойдут живые. В этом случае Вы были бы контроль/обновление тест виртуальный хост, и когда все работает правильно, Вы скопировали бы тест виртуальный хост производства виртуальный хост.

2
ответ дан 2 December 2019 в 22:01

Все, что люди говорят о том, что присвоить версию, хорошо.

Если Вы решаете пойти с подверсией, может я рекомендовать пробовать стек Bitnami Trac; http://bitnami.org/stack/trac

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

Дайте всем Вашим разработчикам Windows TortoiseSVN. Преподавайте всем несколько svn основ командной строки.

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

0
ответ дан 2 December 2019 в 22:01

Теги

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