rarst
  • 0
Гуру

Есть какие-нибудь руководства по использованию WP SVN с клиентами IDE? [закрыто]

  • 0
Закрыто. Этот вопрос
не по теме. В настоящее время ответы не принимаются.

Share
  1. Это codex.wordpress.org/… та информация, которую вы ищете? Если нет, не могли бы вы объяснить больше того, что вас интересует?

    • 0
  2. Я собираюсь сделать этот ответ статьей в блоге, так как он немного не по теме GRIN. На http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ в главе 6 я дал некоторое объяснение SVN в eclipse, но вы, вероятно, ищете что-то другое.

    История, которую я сделал здесь, была о вашем комментарии

    «Поэтому на данный момент я использую функции интеграции 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, я кратко объясню, как установить subclipse collabnet в Eclipse (в основном просто укажите сервер, выберите все и установите)

    В Eclipse с любым инструментом управления версиями команды для управления версиями всегда находятся под правой кнопкой мыши «КОМАНДА». Поскольку вы можете переключаться между проектами, вы можете иметь поддержку нескольких инструментов управления версиями, и большинство команд знакомы с инструментами через графический интерфейс.

    Плагины

    Как вы знаете: для нового проекта плагина WordPress вы получаете svn-адрес с WordPress.org (в вашем почтовом ящике), они используют Trunk для вашего последнего кода и копий «тегов» для стабильных выпусков. (ОЧЕНЬ базовый шаблон CM). Это то, что вы видите на первый взгляд.

    Таким образом, ваш проект будет связан с TRUNK. и вы можете просто посвятить себя этому. Это место, где вы работаете (но не место, откуда вы освобождаетесь) (если только вы не укажете «магистраль» в файле readme.txt в качестве места для вашего окончательного кода).

    Кроме того, вы можете включить WordPress /wp-includes и /wp-admin в свой проект Eclipse в качестве библиотек, чтобы вы могли искать функции и видеть устаревшие функции. Они не доступны для записи и поэтому не подпадают под управление версиями (!). Это со стороны клиента, а не «внешних», которые фактически связаны с проектом управления версиями.

    Как только у вас будет стабильная версия, выберите материал и щелкните правой кнопкой мыши «команда» и «создать тег / ветку», это откроет местоположение svn WordPress, и вы сможете выбрать каталог тегов и ввести новый номер, и ваша новая версия будет запущена. (что может быть полезно для тех, кто читает это). Обратите внимание, что вы не должны выбирать корень вашего проекта, а все остальное, иначе он создаст этот корень также под вашими тегами/2.3.4, а это не то, что вам нужно, вы хотите, чтобы все под корнем было в вашем каталоге /tag.

    См. публикацию для некоторых снимков экрана.


    http://wp.leau.co/files/2011/02/image_thumb17.png

    Сам WordPress

    Если вы являетесь участником, вы можете использовать то же, что и выше, но вы создаете «патчи» из внесенных вами изменений. «Заплатки» — это концепция в мире CM, например, subversion обеспечивает это или джазовый RTC. Щелкнув правой кнопкой мыши «Применить патч», вы можете применить патч, если у вас есть патч, который еще не был применен к стволу WordPress.

    Некоторые люди также фиксируют прямо в багажнике.

    Сам WordPress «Читать»

    Просто создайте проект «WordPress», который содержит проверку / LATEST версии в багажнике (кода подрывной деятельности), опять же, через команду > 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 вы можете создавать пространства имен, создавать иерархию с каталогами, применять соглашения об именах к объектам и внутри них методы. Если вы возьмете один файл, который вы поместили в иерархию, сделайте еще один шаг вперед. Вы добавляете один / за ним и ставите за ним номер версии. Этого даже недостаточно, потому что вы бы хотели, чтобы команда А работала над версией 4 файла, а команда Б работала над этой версией. Таким образом, вы добавляете еще один / и добавляете идентификатор ветки. Вот как вы создаете пространство имен. В зависимости от инструмента вы можете сойти с ума, как вам хочется.

    Но это означает: если кто-то придет к вам и спросит, «где документ Z», вы не сможете дать ответ. Потому что в системе управления версиями «документа Z» не существует. И даже когда он говорит дайте мне «документ Z версии 5», вы не можете передать его, поскольку он может иметь в виду «документ Z версии 5» ветки команды 1 или «документ Z версии 5» ветки команды 2. Все дело в именовании. «документ Z версии 5» — это просто неправильный подход к именованию в определенном пространстве имен.

    В Subversion вы можете сделать это только ограниченно, так что это упрощает понимание. Некоторые концепции соответствуют этому:

    «версия»

    Версия — это ревизия определенного элемента. Так, например, wp-config.php версии 5. В таком инструменте, как ClearCase, вы также можете видеть отдельные версии элементов и «фиксировать» отдельные файлы (но также выполнять атомарные фиксации или наборы изменений или что-то еще).

    В версиях Subversion обработка более ограничена:

    • набор изменений, которые вы вносите локально за один раз, вы « фиксируете », что означает, что этот полный набор «изменений» автоматически фиксируется, и вся база получает новый номер версии. Это номер версии, который вы видите на сайте subversion WordPress.
    • поэтому вы не можете внести локально больше изменений в 1 файл и все они будут рассматриваться как отдельные новые версии, как в чистом регистре. все изменения, которые вы вносите локально в этот 1 файл или любой другой, отправляются за один раз и получают это «уникальное новое имя».
    • если у вас нет доступа к репозиторию (прав) вы можете внести набор изменений и сохранить их в «патче». Затем вы можете отправить этот патч кому-нибудь, например, менеджеру по интеграции или даже менеджеру по сборке, который применит его к репозиторию. Такие инструменты, как, например, RTC, также поддерживают «заплатки». Итак, один человек создает патч, а другой его применяет. Вы должны учитывать это на самом деле, поскольку слово означает «патч», а не вариант использования по умолчанию для разработки кода.
    • вместо /branch N/hello.doc/version 25 также есть такие метки, как /branch N/hello.doc/LATEST или /HEAD. В некоторых системах управления версиями можно применять сложные метки, а затем писать сценарии, работающие с этими метками.

    работаю над версией

    В Subversion вариант использования по умолчанию заключается в том, что вы просто загружаете все материалы на свой жесткий диск из хранилища , работаете над ними, а затем фиксируете, а затем сталкиваетесь со всеми изменениями, внесенными другими людьми, после чего вы разрешаете конфликты. Эти концепции вы видите в графическом интерфейсе. ЕСЛИ вы хотите, чтобы кто-то другой также не редактировал ваш, например, hello.doc, тогда вы БЛОКИРУЕТЕ его, что означает: никто другой не должен иметь возможность его изменить.

    Мне ОЧЕНЬ не нравится эта идея 🙁 ИМХО, это очень плохая практика. Для сравнения и понимания: в ClearCase проверка более или менее сопоставима с блокировкой, а проверка — это фиксация (в подрывной деятельности проверка — это псевдоним для фиксации). Это вариант использования по умолчанию в ClearCase, где он также поддерживает hijacks, который аналогичен проверке Subversion, но затем для выбранных файлов. ИМХО, это намного чище. Кроме того, даже когда вы выполняете проверку в ClearCase, он дает вам 3 варианта: другое люди могут не работать над ним (например, с документами Word), другие люди могут работать над ним, если это действительно необходимо, и «каждый может работать над этим» (например, с файлами исходного кода) Итак… это то, что означает проверка, блокировка и фиксация в СВН.

    компоненты и базовый уровень

    В таких инструментах, как RTC и ClearCase, вы можете группировать элементы в компоненты. Мощный, поскольку эти компоненты являются частью пространства имен и получают свои собственные версии, определяя их. Так, например, компонент «WordPress» получает базовую версию 4.53. Эти базовые показатели затем сами по себе являются объектами, которые также могут получать метаданные, такие как «в тесте». Однако у SVN нет НИКАКОГО этого. Так… :

    теги

    В SVN (и так далее на сайте WordPress) вы видите каталоги с номерами в общем каталоге, который называется «теги». Идея обходного пути. Вы просто берете определенный репозиторий и выгружаете его (на основе файлов) в каталог tags/3.2.4. Вот и все. Он не имеет отношения к пространству имен управления версиями и т. Д…. просто простой каталог…. ВЗДОХ….. ИМХО невозможно выполнять какое-либо управление конфигурацией с помощью такого инструмента. Так что это не объект метаданных, где вы можете создавать сценарии и назначать свойства и делать самые дикие вещи, нет… это просто каталог…………. В RTC для сравнения вы можете сделать ‘ моментальный снимок определенного базового уровня, чтобы также поддерживать этот вариант использования. В ClearCase UCM вы должны создать новую ветвь/поток определенного базового уровня, а затем «просмотреть его».

    ветви

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

    Это используется для дерева пространства имен. Чтобы две команды работали над одним и тем же кодом, вы можете сказать «по-английски» \team 1\hello.doc и \team 2\hello.doc. Затем обе команды начинают работать, и через некоторое время у вас есть \team 1\hello.doc\version 51 и \team 2\hello.doc\version 23. (таким образом, команда 1 сделала 51 версию, а команда 2 сделала 23 версии). Теперь у вас есть возможность выполнить слияние из команды филиала 1 в команду филиала 2, и вы получите слияния в команде 2, но в конце команда 2 будет иметь все изменения команды 1 (версия 24), а отдельные ветки по-прежнему будут показывать работу для каждой их.

    In RTC and ClearCase this is not used but a more advanced object called «streams» (for comparison). From a low perspective you can consider these the same BUT……. when you are in real life your branches will contain A LOT of stuff. So in the real world you would have to make notes, release notes, documentation etc… To enhance this a stream contains not only the «code» but also the «changes» so that you know that RFC23 was about version 34,32 and 56 and you can release them seperately.

    IMHO if you want to setup things right then you give EVERY person one or more personal streams/branches. So they can checkin/commit and checkout from there and it bothers noone. only when someone is ready they «deliver» their stuff to e.g. the team stream and the team stream delivers to the integration stream etc… In WP possibly the releases are branches but for regular persons: they all work in the same branch. A disadvantage since «testing projects» are then in c:\temp and not under version management and you can not have a group of people temporarily working on feature X that will only be needed in 5 releases time.

    the ideal world and trade-offs

    if you have \team1\hello.doc and someone copies in \team2\ ALSO hello.doc that this is BAaaaaad. Since now we have 2 elements with different ID’s where the user thinks they are the same but the system treats them as not the same. This is called ‘evil twins’ and you should never do this in such kind of environment. Always merge or base of branches. If you understand evil twins you understand branches (why this is bad: because on a merge they will be treated as 2 different entities while you want them to be treated as the same) (or different kind-of behaviour in different systems). If a new user screws anything up, this is mostly it. ‘I just deleted hello.doc and copied it back in’ argh

    CHANGES

    SVN does not offer support for this BUT there are tools you can integrate with it to support some kind of integrated change management / ALM. In tools like ClearCase- UCM variant or RTC you can not change 1 letter without there being a defect, RFC, ticket, etc… In SVN when you a commit you can type a description for your atomic commit. Meaning: you should try to have you changes in «patchable» pieces in other words: do an atomic commit per defect/change to have somewhat that behaviour. (but ofcourse it is nowhere afterwards all linked together in a naming tree such as in the ClearCase database) (so that you can automate release notes or help the poor guy being deployment manager getting tons of new sets of code, changes, releases and trying to mingle it together with no real tool to give him any insight on what it actually is).

    Since SVN does not support change management WordPress set up to use TRAC: http://core.trac.wordpress.org/ as you know because you live there 🙂

    I feel TRAC is there because a real tool like ClearCase or RTC which has changes integrated in as objects (yes the one you program against) is missing. So you have a tool where you discuss and submit a «sort of » change set to (while that concept is also missing). So these are the «patches» just a bunch of files without any of the metadata which you would expect in a good system (so I am now in Grumpy state). The number of TRAC is important since that is the overall ID in the naming tree linked to some changes.

    Delivering Changes

    This is something to write in a seperate blog article. In short: in the ideal world you would want to select your changes you want to ‘deliver’ (or another concept) and then don’t worry about files, directories (versions of). You just «deliver RFC 3 and 5». This is how ClearCase UCM or RTC works. In SVN / base clearcase you ‘commit’ a bunch of files where we hope that you made the right decision. That is a big difference and an important one. (this is why SVN is mostly used together integrated with e.g. jira / clearquest / etc… to reach this behaviour). Patching…. is not delivering it is more from 1 stream to another as a uhm ‘patch’.

    Externals

    In other tools you this differently in SVN it is more simple: if you have code from a part which is not your own then you can treat it as external version managed and… to go back to the core concept: you mean that that part does not fall under you name space responsibility since it is all about naming. BUT even though it is external it falls under your responsibility.

    In the GUI there is not workflow in the regular «right mouse» but it is defined in the project structure. So it is part of your definition.

    This concept, if used, is defined in the IEEE CMP as required to define (See under)

    Integration and Merges

    As said. The paradigma behind SVN is to get stuff locally, do your work and then commit and then have the s***. In the GUI you do get though exactly the same tooling as most others. Here you should really understand three-way merging, two-way merging and the difference between conflicts that can be automatically resolved and conflicts that can not be automatically resolved. This last one then falls in 2 classes: those where the tool can propose you what the good end result would be and those in which it does not know what the end would be. You asked about the GUI but on the command line you get information files on what you should fix/merge before committing.

    Lots more for a blog article. (e.g. Open Source Development versus Enterprise Development and build meisters and integration managers since you really have to make different choices here).

    Last but not least the CMP

    What you ask for is a Configuration Management Plan for WordPress. This is a IEEE document. Meaning: whatever of the millions of configuration management plans you find on Google they all are valid against the IEEE specified (several versions) of the CMP.

    Just like (e.g. HTTP) RFC’s there is the IEEE CMP.

    This plan contains defined sections such as «how to treat externals» and «how the namespace looks like, how we retrieve items and how we reproduce items», roles, responsibilities etc…

    From this CMP you can then create work instructions. Anyone wanting to know what the rules are can then read the CMP.

    In an open source context often the role ‘configuration manager’ is missing. So you also miss the Configuration Management Plan.

    Different from a public RFC (e.g. URI or HTTP) You have to pay for the IEEE standard document but… if you Google you will find it here and there.

    Delivery Street

    In a delivery street you would have a team thinking about new business ideas. You have a maintenance department getting a gazillion production bugs in their system. You would have multiple teams working on the same code. and in each substreet you would have a requirements team defining requirements. An architecture team split in a functional team and an operational team ( use cases go to functional team and non functionals to the operational team). You would often have different releases parallel live in a unit test environment, acceptence environments, load and stresstesting environments, functional test environments, pre production test environments and production environment(s).

    In all of them are versions that are all traced to each other.

    one version on a specific test environment is linked to a set of versions linked to a specific RFC and this one is linked to a specific versions of a requirement. The requirement is then linked to a specific version of a testset. ALL fall under version management.

    In WP with SVN/TRAC I have not found yet the requirements database and the versioning database of the requirements. (so that you can do impact analyses and see what code changes if you change 1 requirement)(and that in a new release you can print out which requirements have changed). I have seen individual items in TRAC where links are made to other individual items in TRAC in the comments. I have also not seen traceability between TRAC items and the code other than in comments. So it means people are doing a lot in their heads and it is very dependent on an active community or core developers since they have much of this in their brain.

    But this is going far off topic grin

    OSLC for ALM

    Just one more note for this story: would it not be nice if there would be one package of standards for all of these application lifecycle management tools (ALM)? Someone thought of that and there are now standards so that all concepts are put on a higher abstraction level and then implemented in the tools. Google: OSLC for ALM. (so that all tools can talk to each other and for the user: that you understand them all by understanding the abstraction layer).

    C/ALM

    Если у вас есть время, вы сделаете еще один шаг вперед: сейчас мир движется к C/ALM, продукту следующего поколения, в котором процессы и инструментарий представляют собой единое целое, так что вам больше не нужно задаваться вопросом, что это за процесс. Первым продуктом этого поколения является RTC. Итак, если вы хорошо понимаете SVN или понимаете ClearCase, Jira, Trac, ANT, Agile, RUP, iRUP или любой другой процесс, управление версиями, управление изменениями, управление сборкой, вам понадобится все это, чтобы понять RTC, потому что все это объединено. во-первых, потому что все они связаны друг с другом, и это само по себе взаимодействует через OSLC, так что любой из этих старых инструментов может «подключаться».

    Но сейчас я совсем не в теме.

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

    Своими словами:

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

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

    Почти то, что я искал, читаю сейчас.

    • 0
  4. Если вы используете Windows, вы можете попробовать TortoiseSVN (http://tortoisesvn.tigris.org/). Он не интегрируется с IDE, но интегрируется с проводником Windows, так что вы можете щелкнуть правой кнопкой мыши, а также зарегистрировать/выгрузить свой код.

    • 0
  5. Лучший графический интерфейс, который я видел, это http://blog.ftwr.co.uk/archives/2005/11/03/windows-wordpress-toolbox/.

    Здесь есть отличный визуальный учебник, основанный на mercurial http://hginit.com/

    Во многом это зависит от того, насколько хорошо ваша IDE имеет svn и git интеграцию, которая упрощает работу, например, в Eclipse есть много инструментов, но что-то вроде ultraedit (которое я использовал) имеет странный графический интерфейс и систему управления версиями.

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

    • 0

Оставить ответ

You must login to add an answer.