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

Ответ 1

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

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

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

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

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

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

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

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

CompanyStream -
                            | | - ChildStream1
                            | | - ChildStream2

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

Быстрое сопоставление SVN с концепциями Accurev:
SVN Checkin - продвижение
SVN Checkout - Anchor (Закрепление чего-то делает его WIP - работа продолжается)
Обновление SVN - Обновление

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

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

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

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

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

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

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

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

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

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

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

Затем сделайте разницу против "Поддерживается", а не от "Основы".

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

Жаль, что это так долго. Надеюсь, это поможет...

Ответ 2

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

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

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

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

  Опять же, полная автономия рабочей области. Вы можете работать с 100 файлами сразу, если вы являетесь разработчиком, который может отслеживать, что вы делаете. Вы можете продвигать ни одного, все, одно, другое - на самом деле не имеет значения - и вы можете сделать это на своей временной шкале.

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

  Не уверен, что я точно знаю, что вы здесь имеете в виду. Когда вы запускаете обновление в рабочей области AccuRev, оно никогда не перезапишет вашу незавершенную работу. Если вы работаете над элементами, которые в противном случае были бы унаследованы - это означает, что контент в вашей родительской иерархии изменился - они будут отображаться как (перекрытие) в вашей рабочей области. Опять же, вы можете выбрать, когда выполнять слияние, и все еще обновлять другие изменения сверху и даже продолжать работу над конфликтующим файлом. Слияние происходит в рабочей области, а не в Promote time, давая вам возможность снова скомпилировать, построить, протестировать результат до доставки в другое место.

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

  A Diff против Basis покажет вам, как версия в вашей рабочей области сравнивается с версией, которую вы в последний раз унаследовали от обновления или создания рабочей области. Diff против Backed покажет вам, как ваша версия сравнивается с тем, что в настоящее время находится в родительском потоке. Поэтому, если кто-то продвигал изменения в этом файле, пока вы все еще работаете, Diff против Basis будет сравниваться только с вашим оригиналом, тогда как Diff против Backed сравнивается с новым контентом в родительском. Кстати, в окне History → Browse Versions вы можете различать любые две версии файла друг против друга.

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

Ответ 3

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

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

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

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

Ответ 4

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

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

Вот почему Accurev представлен как Stream-Based Architecture для SCM.

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

Ответ 5

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

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

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

HTH _ dave