Как в одном предложении объяснить, как работает Accurev?

Я понимаю git, Subversion, CVS и множество других систем контроля версий.

Я начал использовать Accurev, и это меня смущает.

Я считаю, что мне нужно сформировать ментальную модель, которая связывает его с другими SCM. В идеале относительно git, потому что я понимаю git лучше всего.

Я бы объяснил git как «ориентированный граф коммитов, где коммит представляет собой diff, родительский (или родительский) хэш и хеш самого себя». Отсюда вы можете легко перейти к объяснению таких понятий, как перебазирование и то, что на самом деле представляют собой слияния, ускоренная перемотка вперед по сравнению с фактическими слияниями и так далее. Мне было легко обучить новых пользователей сложным концепциям git примерно за 15-20 минут.

Я бы очень хотел понять Accurev на этом уровне. Так...

Что такое абстракция одного предложения о том, как работает Accurev, которая позволяет объяснить, как он ведет себя?

Вот несколько примеров вопросов, на которые я хотел бы, чтобы моя ментальная модель ответила:

  • Что происходит, когда я «сохраняю» некоторые файлы, а затем «продвигаю» их?
  • Что, если я не буду продвигать те же файлы, которые я только что сохранил?
  • Почему история иногда неправильно атрибутируется, когда происходят неконфликтующие (также известные как перекрывающиеся) обновления? Это, в частности, напоминает режим отказа Subversion, который, судя по основным объяснениям, которые я слышал, не должен существовать в Accurev.
  • Почему различия почти никогда не содержат того, что я от них ожидаю? Я считаю, что происходит то, что сравнение с базой показывает мне различие с текущим (движущимся) родительским потоком, но я действительно хочу видеть только изменения, которые я сделал с момента последнего обновления.

person Otto    schedule 06.01.2011    source источник
comment
Представьте ситуацию, когда у вас есть команда разработчиков, работающих над проектом. У вас есть другие команды, работающие над проектами, которые используют ваш проект в своей работе. У вашей компании есть продукт (или веб-сайт), основанный на сочетании всех ваших проектов. Accurev позволяет легко управлять потоком изменений в этой сложной рабочей среде, не заставляя команды выпускать код всегда синхронно друг с другом.   -  person Michael Shaw    schedule 24.03.2015
comment
У меня есть объяснение из одного слова: плохо.   -  person nonsensickle    schedule 26.06.2015
comment
Если вам надоел Accurev и вы хотите выйти, загляните на github.com/orao/ac2git. чтобы преобразовать вашу историю в git.   -  person parsley72    schedule 17.03.2016
comment
ac2git перемещен. Обновленная ссылка: github.com/NavicoOS/ac2git.   -  person nonsensickle    schedule 02.11.2016


Ответы (5)


Отказ от ответственности: я лучше всего понимаю систему управления версиями SVN. Так что это окрашивает мое использование таких терминов, как репо, проверка и т. д. Кроме того, я использую Accurev ежедневно, но я не склонен отходить далеко от основных концепций, которые, как мне кажется, я хорошо понимаю.

Одно предложение (со звездочкой): Accurev — это упорядоченный по времени репозиторий, который хранит историю версий файлов, измененных для каждого потока/рабочей области, и позволяет разрабатывать разные версии кода (в потоках). в то время как каждый поток прозрачно обновляется основным кодом из родительского и дочернего* потоков.

(*) Поток обновляется дочерним потоком только после того, как дочерний поток продвигает изменения в родительский поток.

Основным преимуществом Accurev является возможность легко поддерживать разные версии кода. Если вы хотите понять это, я бы не стал искать быстрые абстракции или термины, переопределенные на языке, с которым вы знакомы. Я бы искал примеры и мягкое объяснение терминов по мере их возникновения. К сожалению, я знаю только то, что мне нужно знать, но я попробую...

(Я вернусь к рабочим областям позже. Пока не беспокойтесь о них.)

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

Допустим, вы начинаете с потока CompanyStream. Ваша кодовая база управляется этим потоком, и у него есть история изменений, которые вы внесли в файлы. Затем вы решаете создать два дочерних потока ниже этого, ChildStream1, ChildStream2. Любые изменения, внесенные в файлы в CompanyStream, будут распространяться на оба дочерних потока, поэтому они всегда будут иметь самый последний код, унаследованный от CompanyStream. (Наследование изменений ревизии является основной концепцией Accurev.) Между тем, вы выполняете разработку для одного поставщика в ChildStream1, а изменения для другого поставщика — в ChildStream2. Вы можете выборочно решить, какой код из ChildStream1 и 2 будет переведен в CompanyStream, но любые изменения, сделанные в CompanyStream, должны быть теми, которые вы хотите отобразить в обоих дочерних потоках. Если вы продвигаете код из ChildStream1 в CompanyStream, эти изменения появятся в ChildStream2 после того, как он выполнит обновление (поскольку он снова наследует CompanyStream).

Визуализация потока будет выглядеть так:

CompanyStream --
|-- ChildStream1
|-- ChildStream2

Accurev Overlap = Файл в родительском потоке был изменен с тех пор, как вы обновили свой поток. Визуализируйте родительский поток над вами (именно так он будет отображаться в клиенте), и этот поток продвигается горизонтально, так что он перекрывает момент времени, в котором вы находитесь.

Быстрое сопоставление SVN с концептами Accurev:
SVN Checkin - Promotion
SVN Checkout - Anchor (привязка чего-то делает его WIP - Work In Progress)
SVN Update - Update

Рабочие пространства Accurev

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

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

  • Что происходит, когда я «сохраняю» некоторые файлы, а затем «продвигаю» их?

Вы рекламируетесь в потоке. Вы остаетесь на рабочем месте. Рекламируемые изменения видны всем, кто может видеть трансляцию. Сохраненные изменения видны только вам, владельцу рабочей области.

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

  • Что, если я не буду продвигать те же файлы, которые я только что сохранил?

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

  • Почему история иногда неправильно атрибутируется, когда происходят неконфликтующие (также известные как перекрывающиеся) обновления? Это, в частности, напоминает режим отказа Subversion, который, судя по основным объяснениям, которые я слышал, не должен существовать в Accurev.

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

  • Почему различия почти никогда не содержат того, что я от них ожидаю? Я считаю, что происходит то, что сравнение с базой показывает мне различие с текущим (движущимся) родительским потоком, но я действительно хочу видеть только изменения, которые я сделал с момента последнего обновления.

Затем сделайте diff против «Backed», а не против Basis.

Простая конфигурация, которая мне подходит: я всегда создаю свой личный, частный поток из какого-то общедоступного потока разработки. Затем, когда я вношу изменения, которые хочу зафиксировать (или иметь возможность вернуться), я продвигаюсь в свой собственный поток. Я продолжаю работать в своем рабочем пространстве, и если я хочу сравнить свое рабочее пространство с тем, что я делал ранее или с тем, что происходит надо мной (изменения, которые внесли другие люди), я делаю сравнение с Backed.

Извините, что так долго. Надеюсь, это поможет...

person compilererror    schedule 18.01.2011
comment
Я не уверен, что diff против backed делает то, что я ожидаю, но я создам другой вопрос для странностей diff. А пока лучший ответ. Принятый! - person Otto; 20.01.2011
comment
Кажется, я понимаю, как сформулировать вопрос. Я не верю, что могу отличаться от исторической поддержки. Я могу сравнить резервную копию для моего потока рабочей области, но поскольку дерево наследования является изменчивым, у меня нет контекста, чтобы узнать, какая поддержка была, когда кто-то другой внес изменения, поэтому я больше не могу это сравнивать. Напишите это в отдельном вопросе сейчас. - person Otto; 20.01.2011
comment
Сохраненные изменения видны только вам, владельцу рабочей области. Это не совсем так. Accurev позволяет пользователям видеть рабочие области других пользователей. Это просто не очень заметная особенность; Вы должны пойти искать его. - person Stephen; 23.08.2013

Поскольку несколько других пытались ответить на ваш прямой вопрос, причем ответ Дейва был самым кратким и точным, я нанесу удар по вашим пулям:

  • #P2#
    #P3#
  • #P4#
    #P5#
  • #P6#
    #P7#
  • #P8#
    #P9#

Надеюсь, это дает некоторое представление о ваших конкретных вопросах.

person jtalbott    schedule 07.01.2011
comment
Вы приближаетесь к тому, чтобы заставить меня понять, но сейчас я вижу кое-что, что заставляет меня думать, что есть еще одна часть. Например, если я добавлю несколько файлов, а затем продвину те же самые файлы, я получу две транзакции. Обе транзакции # одинаковы для всех файлов. Транзакция продвижения отображается как транзакция псевдонима. Это означает, что есть какой-то специальный механизм, который срабатывает, если это один и тот же набор файлов. Если бы этого не было, то я бы всегда продвигал файлы, которых не хотел, если бы мне довелось сохранить их в то же время. - person Otto; 08.01.2011
comment
Я думаю, что мне действительно может понадобиться просмотр транзакций, потому что я постоянно сталкиваюсь с проблемами, когда хочу увидеть внесенные изменения. Например, обзоры кода, я хочу видеть изменения, которые вы сделали в своем рабочем пространстве, а не текущие отличия от движущегося резервного или базового потока. Меня могут волновать эти различия, но не тогда, когда я пытаюсь выяснить, правильны ли ваши конкретные изменения кода и соответствуют ли они вашей ошибке или чему-то еще. - person Otto; 08.01.2011
comment
Re: пуля 3, я думаю, вы пропустили, что я говорю, что это не перекрывающееся (что, как я понимаю, означает конфликтующее) изменение. Не должно быть никаких слияний, если наши изменения не перекрываются. Но по какой-то причине мы всегда находим неправильно атрибутированный код. Я бы понял, если бы это было разрешение конфликта. - person Otto; 08.01.2011

Я бы объяснил git как «ориентированный граф коммитов, где коммит представляет собой diff, родительский (или родительский) хэш и хеш самого себя».

Репозиторий git — это, FWIW, лес деревьев истории, листьями которого являются (коммитные метаданные плюс) деревья каталогов и файлов. Никаких различий, не в Git, по крайней мере, когда дело доходит до концепции. Если механизм хранения выполняет дельтификацию, это уже другая история.

Что касается AccuRev, я посмотрел их двухминутное вступительное видео ( ссылка предназначена для справки, а не для рекламы), и она очень похожа на обычное упорядоченное по времени дерево истории SCM (ветви). Элементы со значком водянистой волны — это головки ветвей, а желтая папка — рабочая копия. Когда ведущий перемещает рабочие копии, он как бы делает ребаз всех рабочих копий своего подчиненного (черт возьми! Только подумайте о конфликтах слияния!). Значок с тремя зелеными точками (список проблем) будет списком коммитов, который будет выбран при копировании.

Одним предложением: ничего, чего бы вы не знали из предыдущего опыта работы с cvs/svn/git — я бы сказал, двигайтесь вперед.

person user562374    schedule 07.01.2011
comment
Мне не нужно думать о конфликтах слияния, я вижу их каждый день. Хотел бы я двигаться вперед... историческое технологическое решение, принятое до меня, и теперь мы здесь. :) - person Otto; 07.01.2011
comment
Хотя я не чувствую, что этот ответ приводит меня к тому, чего я хочу достичь в понимании Accurev, я считаю, что он суммирует мое текущее понимание Accurev. Добавьте к этому мое растущее мнение, что никто не понимает Accurev достаточно хорошо, чтобы разумно ответить на мои вопросы, это принятый ответ, пока не появится что-то лучшее. - person Otto; 12.01.2011

Accurev является производным от ClearCase и следует за Потоки ClearCase UCM.
(The Accurev модель имеет некоторое сходство с UCM и хорошо полученные бывшими пользователями ClearCase)

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

Вот почему Accurev представлен как потоковая архитектура для SCM< /сильный>.

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

person VonC    schedule 07.01.2011
comment
Я почти принял этот ответ. Возможно, у меня недостаточно ментальной модели Accurev, чтобы полностью понять этот ответ. - person Otto; 12.01.2011

Я дам вам техническое (не связанное с бизнесом) одно предложение, основанное на стиле вашего вопроса:

AccuRev использует объектно-ориентированный подход к моделированию программных конфигураций. Это так просто и это здорово! Особенно, если вы моделируете рабочий процесс или, что еще лучше, настраиваете непрерывную доставку (другая тема). Но я видел так, что многие люди отвергают эту мощную технологию и подход к модели данных, потому что они не могут выйти за рамки традиционных «ветвей» аля cvs, svn, p4, cc, до бесконечности. Лучшей аналогией было бы сравнение серии потоков AccuRev с правилами в спецификации конфигурации в чистом регистре... (примечание: это просто аналогия), но гораздо более мощной, поскольку потоки являются объектами первого класса, которые поддерживают конфигурацию и историю на основе времени.

Хитрость в понимании AccuRev заключается в том, что хотя любой заданный «поток» представляет собой полную конфигурацию (т. е. вы можете проверить ее), фактическое содержимое этого потока определяется динамически путем агрегирования любых локальных изменений файла/каталога, любых изменений из parent, вверх по дереву до самого верха, где собраны остальные файлы. Таким образом, всякий раз, когда вы видите «дерево» потоков, они НЕ являются ветвями... скорее это серия конфигураций, основанных на наследовании, где верхний поток подобен «суперклассу», а все [великие] дети являются [под]подклассами. Новые изменения файлов/каталогов продвигаются вверх по дереву по мере их перехода от разработки, интеграции, контроля качества и т. д.

HTH _ Дэйв

person user129236    schedule 07.01.2011
comment
Более одного предложения и (не?), к счастью, у меня нет контекста ClearCase. - person Otto; 07.01.2011
comment
AccuRev использует объектно-ориентированный подход к моделированию программных конфигураций. :) - person user129236; 08.01.2011
comment
Объектно-ориентированный подход может моделировать что угодно и не имеет смысла без информации о том, как ведет себя модель. Хотя вы предоставили часть этой информации, она по-прежнему не отвечает на мой вопрос, поскольку требует базового понимания ClearCase, которого у меня нет. - person Otto; 11.01.2011
comment
Точно так же я ищу информацию более низкого уровня, чем объектно-ориентированная. Например, вы можете описать C++ как объектно-ориентированный, но после компиляции он ничем не отличается от кода C. Я ищу эквивалентную информацию о том, как собираются двоичные файлы C++. Например, C++ объединяет имя класса и имя метода, чтобы создать метод в конечном бинарном объекте. - person Otto; 11.01.2011