Я собираюсь сделать этот ответ в блоге, так как он немного не по теме GRIN. На http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ в главе 6 я дал некоторое объяснение SVN в затмении, но вы, вероятно, ищете что-то другое.
История, которую я сделал здесь, была о вашем комментарии
«Итак, пока я использую функции интеграции VCS в IDE (NetBeans, PHPStorm). Это часто оставляет меня в замешательстве в отношении специфики и способов правильной работы». и «Что-то, что фокусируется на концепциях и рабочих процессах, а не на вводе загадочных строк в консоли».
Я слышал, что еще чаще я хотел объяснить SVN в более широком контексте, например, описывая сначала «языки программирования», а затем объясняя PHP, вы лучше понимаете PHP, и в данном случае сначала «Управление конфигурацией», а затем решение SVN в нем.
Я просто напишу что-нибудь здесь, и если это не по теме или не нужно, я удалю это:
------------ 8 <----------------
Если вы устанавливаете Eclipse PDP, я написал это: [ http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ ]
Если вы прокрутите вниз до # 6, я кратко объясню, как установить в Eclipse подклип collabnet (в основном просто укажите на сервер, выберите все и установите)
В Eclipse с любым инструментом управления версиями команды для управления версиями всегда находятся под правой кнопкой мыши «КОМАНДА». Поскольку вы можете переключаться между проектами, у вас может быть поддержка нескольких инструментов управления версиями, и большинство команд знакомы с инструментами через графический интерфейс.
Плагины
Как вам известно: для нового проекта плагина WordPress вы получаете svn-местоположение с WordPress.org (в вашем почтовом ящике), они используют Trunk для вашего последнего кода и копируют теги для стабильных выпусков. (ОЧЕНЬ основной шаблон CM). Это то, что вы видите на первый взгляд.
Таким образом, ваш проект будет связан с TRUNK. и вы можете просто совершить это. Это место, где вы работаете (но не там, где вы выпускаете) (если вы не укажете «trunk» в файле readme.txt в качестве места для вашего окончательного кода).
Кроме того, вы можете включить WordPress / wp-include и / wp-admin в ваш проект Eclipse в виде библиотек, чтобы вы могли искать функции и видеть устаревшие функции. Они недоступны для записи и поэтому не попадают под управление версиями (!). Это со стороны клиента, поэтому не «внешние», которые на самом деле связаны в проекте управления версиями.
Как только у вас есть стабильная версия, выберите материал и щелкните правой кнопкой мыши «команда» и «создать тег / ветку», это откроет местоположение WordPress svn, и вы сможете выбрать каталог тегов и ввести новый номер, и ваша новая версия будет доступна (что может быть полезно для тех, кто читает это). Обратите внимание, что вам не следует выбирать корень вашего проекта, но все остальное, иначе он создаст этот корень также в ваших тегах / 2.3.4, а это не то, что вы хотите, чтобы все в корневом каталоге находилось в каталоге / tag.
Смотрите пост для некоторых снимков экрана.
http://wp.leau.co/files/2011/02/image_thumb17.png
Сам WordPress
Если вы являетесь участником, вы можете использовать то же, что и выше, но вы создаете «патчи» из внесенных вами изменений. «Патчи» - это концепция в мире CM, например, Subversion предоставляет это или джаз RTC. С помощью щелчка правой кнопкой мыши «Применить патч» вы можете применить патч, если у вас есть патч, который еще не был применен к стволу WordPress.
Некоторые люди также связывают себя с стволом.
Сам WordPress "Читай"
Просто создайте проект «WordPress», который содержит извлечение версии / LATEST в транке (кода subversion), снова через команду> checkout.
Лично я не делаю этого, а просто использую экспорт последнего кода (с силой), чтобы просто получить каталог с последней версией WordPress (то есть, который не подпадает под управление версиями)
В основном
Поскольку у вас есть некоторый опыт работы с VCS и вопросами по SVN: в основном, все инструменты для версий связаны с концепцией именования вещей. Или лучше сказать, имея лучшее пространство имен. Вы можете отобразить большинство команд из CVS, Git, RTC, ClearCase, SourceSafe и т. Д. В концепцию этого пространства имен. Поскольку у вас есть небольшой опыт работы с другими инструментами, немного шире:
Новые люди часто закрывают глаза на определенные команды или определенную функциональность, но ключевой задачей является предоставление наилучшего варианта размещения всех элементов, необходимых в пространстве имен.
Так как это в основном основная функциональность этих инструментов, термин «управление версиями» неверен. Это на самом деле менеджер пространства имен.
Так что если у вас есть
/ Проект A / Отдел B / Команда C / Член D / Поток E / Компонент F / Элемент G / Филиал H / Филиал I / Версия J
Вы можете создать уникальное имя для каждой «вещи». Выше приведена реализация пространства имен, которое вам необходимо для определенной цели с использованием одного из инструментов пространства имен.
Почти все концепции в этом мире могут быть сопоставлены с этим, поэтому способ, которым вы МОЖЕТЕ поддерживать свою собственную область имен / таксономию, зависит от возможностей вашего инструмента. Так что ... это действительно зависит от концепций и решений, которые сделали разработчики сотен различных инструментов.
В хорошем инструменте вы можете щелкнуть и увидеть эту полную таксономию в одном дереве или увеличить одно дерево.
Это ядро: инструмент, который может помочь вам управлять сложностью (см. Сложность в википедии: http://en.wikipedia.org/wiki/Complexity ), предоставляя вам хорошие инструменты для управления ВАШЕЙ ТАМОЖЕННОЙ таксономией. Человек, который создает таксономию и думает, как ее настроить, - менеджер по конфигурации, он пишет план, называемый планом управления конфигурацией, который сначала обдумывает это.
Просто представьте, что кто-то просит вас создать набор пользовательских таксономий в WordPress, которые представляют ВСЕ объекты в его компании, включая возможность вывести из него состояние, как оно было в любой момент. Вы можете сделать много вариантов дизайна, и каждый будет делать что-то еще на основе некоторых вариантов. Некоторые будут содержать больше функций, некоторые из них будут более простыми, а более сложные будут принимать разные решения. Это «эти инструменты». Поэтому я никогда не понимаю дискуссий на уровне инструментов об управлении версиями, потому что это совершенно странно.
В настоящее время в PHP вы можете создавать пространства имен, создавать иерархию с каталогами, применять соглашения об именах к объектам и их методам. Если вы берете один файл, который вы поместили в иерархию, сделайте еще один шаг вперед. Вы добавляете один / за ним и размещаете номер версии за ним. Этого даже недостаточно, потому что вы бы хотели, чтобы команда A работала над версией 4 файла, а команда B работала над этой версией. Таким образом, вы добавляете другой / и добавляете идентификатор ветви. Вот как вы строите пространство имен. В зависимости от инструмента вы можете сходить с ума, как вам хотелось бы.
Но это значит: если кто-то приходит к вам с вопросом «где находится документ Z», вы не можете дать ответ. Потому что в системе управления версиями «документ Z» не существует. И даже когда он говорит «дайте мне« документ Z версии 5 »», вы не можете передать его, поскольку он может означать «документ Z версии 5» ветви 1 команды или «документ Z версии 5» ветви 2 команды. Все дело в именовании. «документ Z версии 5» - это просто неправильный подход к именованию в определенном пространстве имен.
В Subversion вы можете сделать это только в ограниченном количестве, что упрощает понимание. Некоторые концепции соответствуют этому:
"версия"
Версия - это ревизия определенного элемента. Например, wp-config.php версии 5. В таком инструменте, как ClearCase, вы также можете видеть отдельные версии элементов и «фиксировать» отдельные файлы (но также делать атомарные фиксации или изменять набор или что-либо еще).
В версиях Subversion обработка более ограничена:
- набор изменений, которые вы делаете локально за один раз, вы « фиксируете », что означает, что этот полный набор «изменений» атомарно фиксируется, и вся база получает новый номер версии. Это номер версии, который вы видите на сайте подрывной деятельности WordPress.
- так что вы не можете вносить локально больше изменений в 1 файл, и все они рассматриваются как отдельные новые версии, как в clearcase. все изменения, которые вы вносите локально в этот 1 файл или любой другой файл, передаются за один раз и получают это «уникальное новое имя».
- если у вас нет доступа к репозиторию (права), вы можете внести изменения и сохранить их в «патче». Затем вы можете отправить этот патч кому-нибудь, например, менеджеру интеграции или даже менеджеру сборки, который применяет его к хранилищу. Такие инструменты, как, например, RTC, также поддерживают «патчи». Таким образом, один человек создает патч, а другой применяет патч. Вы должны учитывать это на самом деле, так как слово означает «патч», а не вариант использования кода по умолчанию при разработке кода.
- вместо / branch N / hello.doc / version 25 есть также метки, такие как / branch N / hello.doc / LATEST или / HEAD. В некоторых системах управления версиями вы можете применять сложные метки, а затем писать сценарии, работающие с этими метками.
работает над версией
В Subversion использовать по умолчанию случае является то , что вы просто загрузить все вещи на ваш жесткий диск из репозитория проверки , работы над материалом , а затем commmit , а затем сталкиваются все изменениями и другие люди сделали чего разрешать конфликты. Эти понятия вы видите в графическом интерфейсе. Если вы хотите, чтобы кто-то еще не мог отредактировать ваш файл, например, hello.doc, тогда вы ЗАБЛОКИРУЕТЕ его значение: никто другой не сможет его изменить.
Мне ДЕЙСТВИТЕЛЬНО не нравится эта идея :( IMHO, это очень плохая практика. Для сравнения и понимания: в ClearCase извлечение более или менее сопоставимо с блокировкой, а checkin - это фиксация (в subversion checkin - это псевдоним для фиксации) Это вариант использования по умолчанию в ClearCase, где он также поддерживает угоны, которые аналогичны извлечению Subversion, но затем на выбранных файлах. ИМХО, это намного чище. Более того, даже когда вы делаете извлечение в ClearCase, вы получаете 3 варианта: другое люди могут не работать над ним (например, с документами Word), другие люди могут работать над ним, если это действительно необходимо, и «каждый может работать над этим» (например, с файлами исходного кода). Итак ... это то, что означает checkout, lock and commit в СВН.
компоненты и основы
В таких инструментах, как RTC и ClearCase, вы можете сгруппировать элементы в компоненты. Мощный, поскольку эти компоненты являются частью пространства имен и получают собственные версии, основывая их. Так, например, компонент «WordPress» получает базовую версию 4.53. Эти базовые линии сами по себе являются объектами, которые могут также получать метаданные, такие как «в тесте». Однако SVN не имеет этого. Так... :
теги
В SVN (и так далее на сайте WordPress) вы видите каталоги с номерами в общем каталоге, называемом «тегами». Обходная идея. Вы просто берете определенный репозиторий и сбрасываете его (на основе файлов) в каталог tags / 3.2.4. Вот и все. Он не имеет никакого отношения к пространству имен управления версиями и т. Д. - просто к простой директории .... SIGH ..... Невозможно выполнить любое управление конфигурацией с помощью такого инструмента. Так что это не объект метаданных, в котором вы можете создавать сценарии, назначать свойства и делать самые смелые вещи, нет ... это просто каталог ............. В RTC для сравнения вы можете сделать ' снимок "определенной базовой линии, чтобы также поддержать этот вариант использования. В ClearCase UCM вы создадите новую ветку / поток с определенной базовой линией, а затем «просмотрите ее».
ветви
Насколько я знаю, это не используется в среде WordPress, но, возможно, я ошибаюсь, и есть команды, которые делают это для выпусков WordPress, чтобы поддержать изменения порта в более старых версиях. Так что я не знаю, может быть, кто-то еще знает.
Это используется для дерева пространства имен. Чтобы две команды работали над одним и тем же кодом, вы можете сказать «по-английски» \ team 1 \ hello.doc и \ team 2 \ hello.doc. Затем обе команды начинают работать, и через некоторое время у вас есть \ team 1 \ hello.doc \ версия 51 и \ team 2 \ hello.doc \ версия 23. (таким образом, команда 1 сделала 51 версию, а команда 2 сделала 23 версии). Теперь у вас есть возможность слияния из группы 1 филиала в группу 2 филиала, и вы получите слияния в команде 2, но в конце команда 2 будет иметь все изменения команды 1 (версия 24), и отдельные ветви по-прежнему показывают работу для каждого из них.
В RTC и ClearCase это не используется, а является более продвинутым объектом, называемым «потоками» (для сравнения). С низкой точки зрения вы можете рассматривать их как одно и то же, НО ....... когда вы в реальной жизни, ваши ветки будут содержать МНОГО материала. Таким образом, в реальном мире вам придется делать заметки, заметки о выпуске, документацию и т. Д. Для улучшения этого поток содержит не только «код», но и «изменения», чтобы вы знали, что RFC23 был примерно 34,32 версии. и 56, и вы можете освободить их отдельно.
ИМХО, если вы хотите все настроить правильно, вы даете КАЖДОМУ человеку один или несколько личных потоков / веток. Таким образом, они могут проверить / зафиксировать и оформить заказ оттуда, и это никому не мешает. только когда кто-то готов, они «доставляют» свои вещи, например, в групповой поток, а групповой поток - в поток интеграции и т. д. В WP, возможно, релизы являются ветвями, но для обычных людей: все они работают в одной и той же ветке. Недостаток, так как «проекты тестирования» находятся тогда в c: \ temp и не находятся под управлением версиями, и у вас не может быть группы людей, временно работающих над функцией X, которая понадобится только во время 5 выпусков.
идеальный мир и компромиссы
если у вас есть \ team1 \ hello.doc и кто-то копирует в \ team2 \ ALSO hello.doc, то это BAaaaaad. Поскольку теперь у нас есть 2 элемента с разными идентификаторами, где пользователь считает, что они одинаковы, но система воспринимает их как разные. Это называется «злые близнецы», и вы никогда не должны делать это в такой среде. Всегда слияние или база филиалов. Если вы понимаете злых близнецов, вы понимаете ветви (почему это плохо: потому что при слиянии они будут рассматриваться как 2 разных объекта, в то время как вы хотите, чтобы они рассматривались как одинаковые) (или разные типы поведения в разных системах). Если новый пользователь что-то испортил, это в основном это. 'Я просто удалил hello.doc и скопировал его обратно в' argh
ИЗМЕНЕНИЯ
SVN не предлагает поддержку для этого, НО есть инструменты, которые вы можете интегрировать с ним для поддержки какого-либо интегрированного управления изменениями / ALM. В таких инструментах, как ClearCase-UCM-вариант или RTC, вы не можете изменить 1 букву, если нет дефекта, RFC, тикета и т. Д. ... В SVN при фиксацииВы можете ввести описание для вашего атомарного коммита. Значение: вы должны попытаться внести изменения в «исправляемые» части, другими словами: сделать атомарный коммит для дефекта / изменения, чтобы в некоторой степени соответствовать такому поведению. (но, разумеется, нигде после этого все не связаны между собой в дереве имен, например в базе данных ClearCase) (так что вы можете автоматизировать заметки о выпуске или помочь бедному парню, являющемуся администратором развертывания, получать тонны новых наборов кода, изменений, выпусков и смешать это без реального инструмента, чтобы дать ему какое-либо представление о том, что это на самом деле).
Поскольку SVN не поддерживает управление изменениями, WordPress настроен на использование TRAC: http://core.trac.wordpress.org/, как вы знаете, потому что вы там живете :)
Я чувствую, что TRAC существует, потому что отсутствует реальный инструмент, такой как ClearCase или RTC, в котором изменения интегрированы в виде объектов (да, того, с которым вы программируете). Таким образом, у вас есть инструмент, в котором вы обсуждаете и отправляете набор изменений своего рода (хотя эта концепция также отсутствует). Так что это «патчи» - просто набор файлов без метаданных, которые вы ожидаете в хорошей системе (так что я сейчас в состоянии Grumpy). Номер TRAC важен, так как это общий идентификатор в дереве имен, связанный с некоторыми изменениями.
Доставка изменений
Об этом можно написать в отдельной статье в блоге. Короче говоря: в идеальном мире вы хотели бы выбрать ваши изменения, которые вы хотите «доставить» (или другую концепцию), а затем не беспокоиться о файлах, каталогах (версиях). Вы просто «поставляете RFC 3 и 5». Вот как работает ClearCase UCM или RTC. В SVN / base clearcase вы «фиксируете» кучу файлов, и мы надеемся, что вы приняли правильное решение. Это большая разница и важная. (именно поэтому SVN в основном используется вместе, например, с jira / clearquest / etc ... для достижения такого поведения). Патчинг .... не доставляет его больше из одного потока в другой как "патч".
внешность
В других инструментах это происходит иначе, в SVN это проще: если у вас есть код из части, которая не принадлежит вам, вы можете рассматривать его как управляемую внешнюю версию и ... вернуться к основной концепции: вы имеете в виду, что это часть не попадает под вашу ответственность пространства имен, так как все дело в именовании. НО, хотя он и внешний, он подпадает под вашу ответственность.
В графическом интерфейсе нет рабочего процесса в обычной «правой мыши», но это определено в структуре проекта. Так что это часть вашего определения.
Эта концепция, если она используется, определяется в CMP IEEE, как требуется для определения (см. Ниже)
Интеграция и слияния
Как сказал. Парадигма SVN состоит в том, чтобы получать вещи локально, выполнять свою работу, а затем фиксировать и затем иметь s ***. В GUI вы получаете точно такой же набор инструментов, как и большинство других. Здесь вы должны понимать трехстороннее слияние, двухстороннее слияние и разницу между конфликтами, которые могут быть автоматически разрешены, и конфликтами, которые не могут быть разрешены автоматически. Этот последний затем делится на 2 класса: те, где инструмент может предложить вам, каким будет хороший конечный результат, и те, в которых он не знает, каков будет конечный результат. Вы спрашивали о графическом интерфейсе, но в командной строке вы получаете информационные файлы о том, что вы должны исправить / объединить перед фиксацией.
Много больше для статьи в блоге. (Например, разработка с открытым исходным кодом по сравнению с разработкой предприятия и сборка менеджеров и менеджеров по интеграции, так как здесь вам действительно нужно сделать другой выбор).
Последний, но не менее важный CMP
То, что вы просите, это план управления конфигурацией для WordPress. Это документ IEEE. Значение: независимо от того, какие миллионы планов управления конфигурацией вы найдете в Google, все они действительны в соответствии с IEEE (несколько версий) CMP.
Так же, как (например, HTTP) RFC, есть IEEE CMP.
Этот план содержит определенные разделы, такие как «как обращаться с внешними» и «как выглядит пространство имен, как мы получаем элементы и как мы воспроизводим элементы», роли, обязанности и т. Д ...
Из этого CMP вы можете создавать рабочие инструкции. Любой, кто хочет знать, каковы правила, может прочитать CMP.
В контексте открытого исходного кода часто отсутствует роль «менеджер конфигурации». Таким образом, вы также пропустите план управления конфигурацией.
В отличие от общедоступного RFC (например, URI или HTTP) Вы должны заплатить за стандартный документ IEEE, но ... если вы Google, вы найдете его здесь и там.
Улица доставки
На улице доставки у вас будет команда, которая думает о новых бизнес-идеях. У вас есть отдел техобслуживания, который получает в своей системе тысячи ошибок. У вас будет несколько команд, работающих над одним и тем же кодом. и в каждом подотделе у вас будет команда требований, определяющая требования. Команда архитекторов разделена на функциональную группу и операционную группу (варианты использования переходят в функциональную группу, а не функционалы - в оперативную группу). Часто бывают разные выпуски параллельно в реальном времени в среде модульного тестирования, средах приемлемости, средах нагрузочных и стресс-тестов, средах функционального тестирования, средах предпроизводственного тестирования и производственных средах.
Во всех них есть версии, которые все связаны друг с другом.
одна версия в конкретной тестовой среде связана с набором версий, связанных с конкретным RFC, а эта - с конкретными версиями требования. Затем требование связывается с определенной версией набора тестов. ВСЕ попадают под управление версиями.
В WP с SVN / TRAC я еще не нашел базу данных требований и базу данных версий требований. (чтобы вы могли проводить анализ влияния и видеть, какой код изменяется, если вы измените 1 требование) (и что в новой версии вы можете распечатать, какие требования изменились). Я видел отдельные элементы в TRAC, где ссылки делались на другие отдельные элементы в TRAC в комментариях. Я также не видел прослеживаемости между элементами TRAC и кодом, кроме как в комментариях. Таким образом, это означает, что люди много делают в своих головах, и это очень зависит от активного сообщества или основных разработчиков, так как они имеют много в своем мозгу.
Но это идет далеко от темы ухмылки
OSLC для ALM
Еще одно замечание к этой истории: не было бы неплохо, если бы был один пакет стандартов для всех этих инструментов управления жизненным циклом приложений (ALM)? Кто-то подумал об этом, и теперь существуют стандарты, чтобы все концепции были переведены на более высокий уровень абстракции, а затем реализованы в инструментах. Google: OSLC для ALM. (чтобы все инструменты могли общаться друг с другом и для пользователя: чтобы вы понимали их все, понимая уровень абстракции).
С / УАП
Даже на шаг впереди, если у вас есть время: мир сейчас движется к C / ALM, следующему поколению продуктов, в которых процессы и инструменты являются одной интегрированной вещью, так что вам больше не придется задаваться вопросом, что это за процесс. Первый продукт этого поколения - RTC. Поэтому, если вы хорошо понимаете SVN или понимаете ClearCase или Jira, или Trac, или ANT, или Agile, или RUP, или iRUP, или любой другой процесс, управление версиями, управление изменениями, управление сборкой, вам понадобится все это для понимания RTC, потому что все это объединено с одной стороны, потому что все они связаны друг с другом, и это само по себе взаимодействует через OSLC, так что любой из этих старых инструментов может «подключиться».
Но сейчас я действительно не по теме.