Что такое объяснение того, как работает Акурев?
Я понимаю git, Subversion, CVS и множество других систем контроля версий.
Я начал использовать Accurev, и это меня смущает.
Я считаю, что мне нужно сформировать мысленную модель, которая связывает ее с другими СКМ. Идеально по отношению к мерзавцу, потому что я понимаю, мерзавец лучший.
Я бы объяснил git как "ориентированный граф коммитов, где коммит - это diff, родительский (или родительский) хеш и сам хеш". Вы можете легко перейти оттуда к объяснению таких понятий, как rebase и что такое слияния на самом деле, ускоренная перемотка вперед против фактических слияний и так далее. Мне было легко обучить новых пользователей сложным концепциям git примерно за 15-20 минут.
Я бы очень хотел понять Аккурева на этом уровне. Так...
Какая абстракция из того, как работает Акчурев, позволяет объяснить, как он себя ведет?
Вот несколько примеров вопросов, на которые я хотел бы, чтобы ответила моя ментальная модель:
- Что происходит, когда я "сохраняю" некоторые файлы, а затем "продвигаю" их?
- Что делать, если я не продвигаю те же файлы, которые я только что сохранил?
- Почему история иногда неправильно приписывается, когда происходят неконфликтные (или пересекающиеся) обновления? Это, в частности, напоминает режим сбоя Subversion, который, исходя из основных объяснений, которые я слышал, я не думаю, что должен существовать с Accurev.
- Почему различия почти никогда не содержат то, что я ожидаю от них? Я полагаю, что то, что происходит, - это то, что diff против base показывает мне diff против текущего (движущегося) родительского потока, но я действительно хочу только видеть изменения, которые я сделал с момента последнего обновления.
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 - Продвижение
SVN Checkout - Якорь (Привязка к чему-либо делает WIP - Работа в процессе)
SVN Обновление - Обновление
Accurev Workspaces
Я еще не упомянул рабочие места. Рабочая область представляет код на вашем жестком диске. Рабочая область похожа на поток в том, что она может иметь историю, и она может отслеживать сделанные вами изменения. (Это то, что делает Keep - он хранит снимок файлов, которые вы указали во время этой операции Keep, в истории вашего рабочего пространства. Вы можете в любой момент вернуться к этим снимкам файлов. В результате, рабочее пространство также можно просмотреть как ваше собственный личный поток, который представляет собой запись изменений, внесенных в код.)
Потоки - это абстрактные понятия, которые представляют изменения редакции, и историю того, что произошло. Потоки и рабочие пространства наследуют код от своих родительских потоков. Однако, в отличие от потоков, рабочие пространства не могут иметь дочерние потоки или дочерние рабочие пространства. Рабочие места похожи на листья на дереве; потоки похожи на ветви.
- Что происходит, когда я "сохраняю" некоторые файлы, а затем "продвигаю" их?
Вы продвигаетесь в поток. Вы держите на рабочем месте. Продвигаемые изменения видны всем, кто видит поток. Сохраненные изменения видны только вам, владельцу рабочей области.
Сохраненные файлы будут иметь снимки в вашем рабочем пространстве (на случай, если вы когда-нибудь захотите вернуться к ним). У продвигаемых файлов будут снимки (так сказать) в потоке, в который вы их продвигали. Большая разница в том, что продвигаемые изменения будут распространяться на любые потоки или рабочие пространства, которые наследуют этот поток.
- Что делать, если я не продвигаю те же файлы, которые я только что сохранил?
Тогда они будут только в вашем рабочем пространстве. Кроме того, я полагаю, что когда вы делаете продвижение, Accurev в первую очередь хранит данные (поэтому у вас есть запись об изменении файла как в вашей рабочей области, так и в потоке, в который вы продвигаете).
- Почему история иногда неправильно приписывается, когда происходят неконфликтные (или пересекающиеся) обновления? Это, в частности, напоминает режим сбоя Subversion, который, исходя из основных объяснений, которые я слышал, я не думаю, что должен существовать с Accurev.
Можете привести пример? Мое понимание версий файлов в Accurev немного размыто. Я полагаю, что атрибут версии будет назначен рабочей областью или потоком, из которого было продвинуто самое последнее изменение (не сохранено). Возможно, существуют некоторые отношения наследования потоков, которые приводят к тому, что файл имеет атрибуты, которые кажутся неправильными, пока вы не отследите его.
- Почему различия почти никогда не содержат то, что я ожидаю от них? Я полагаю, что то, что происходит, - это то, что diff против base показывает мне diff против текущего (движущегося) родительского потока, но я действительно хочу только видеть изменения, которые я сделал с момента последнего обновления.
Затем сделайте разногласия против "Поддержки", а не против "Основы".
Простая конфигурация, которая работает для меня: я всегда создаю свой личный, приватный поток из какого-то общественного потока разработки. Затем, когда я делаю изменения, которые я хочу зарегистрировать (или иметь возможность вернуться), я продвигаюсь в свой поток. Я продолжаю работать в своем рабочем пространстве, и если я хочу сравнить свое рабочее пространство с тем, что я делал ранее или с тем, что происходит над мной (изменения, сделанные другими людьми), я делаю сравнение с Backed.
Извините, это так долго. Надеюсь, это поможет...
Поскольку еще несколько человек попытались ответить на ваш прямой вопрос - поскольку ответ Дейва был самым кратким и точным, я попробую ответить на ваши вопросы:
Что происходит, когда я "сохраняю" некоторые файлы, а затем "продвигаю" их?
Хранение файла создаст новую версию этого файла, все еще закрытую для вашего рабочего пространства. Отлично подходит для автономного кодирования, создания точек отвлечения, просто для частного развития. Вы можете в любой момент в будущем вернуться к любой предыдущей сохраненной версии файла, либо от себя, либо от любого другого участника. Если вам удобна текущая версия (которую вы скомпилировали, собрали, протестировали и т. Д.), Вы можете повысить ее в своем родительском потоке, таким образом предоставляя другим доступ к вашей версии, не рискуя нарушить то, что вы можете сделать, когда делаете коммит. во время регистрации.
Что делать, если я не продвигаю те же файлы, которые я только что сохранил?
Опять же, полная автономия рабочего пространства. Вы можете работать с 100 файлами одновременно, если вы являетесь разработчиком, который может отслеживать, что вы делаете. Вы можете продвигать ни одного, все, один, некоторые - на самом деле не имеет значения - и вы можете сделать это в своем графике.
Почему история иногда неправильно приписывается, когда происходят неконфликтные (или пересекающиеся) обновления? Это, в частности, напоминает режим сбоя Subversion, который, исходя из основных объяснений, которые я слышал, я не думаю, что должен существовать с Accurev.
Не уверен, что я точно знаю, что вы имеете в виду здесь. Когда вы запускаете обновление в рабочей области AccuRev, оно никогда не перезапишет вашу незавершенную работу. Если вы работаете с элементами, которые в противном случае были бы унаследованы, то есть содержимое вашей родительской иерархии изменилось, они будут перечислены как (перекрывающиеся) в вашей рабочей области. Опять же, вы можете выбрать, когда выполнять слияние, и при этом обновлять другие изменения, указанные выше, и даже продолжать работать с конфликтующим файлом. Слияние происходит в рабочей области, а не во время Promote, что дает вам возможность еще раз скомпилировать, собрать, протестировать результат до его доставки в другое место.
Почему различия почти никогда не содержат то, что я ожидаю от них? Я полагаю, что то, что происходит, - это то, что diff против base показывает мне diff против текущего (движущегося) родительского потока, но я действительно хочу только видеть изменения, которые я сделал с момента последнего обновления.
Разница с базой покажет вам, как версия в вашем рабочем пространстве сравнивается с версией, которую вы в последний раз унаследовали от обновления или создания рабочего пространства. Diff против Backed покажет вам, как ваша версия сравнивается с текущей версией в родительском потоке. Поэтому, если кто-то внес изменения в этот файл, пока вы еще не создали свой файл, Diff против основы будет сравниваться только с оригиналом, а функция Diff против резервной копии сравнивается с новым содержимым в родительском файле. Кстати, в представлении "История" -> "Просмотр версий" вы можете сравнивать любые две версии файла друг с другом.
Надеемся, что это дает немного перспективы по вашим конкретным вопросам.
Я бы объяснил git как "ориентированный граф коммитов, где коммит - это diff, родительский (или родительский) хеш и сам хеш".
Git-репозиторий - это FWIW, лес деревьев истории, из которых листьями коммитов являются (коммит метаданные плюс) деревья каталогов и файлов. Нет различий, не в Git, по крайней мере, когда дело доходит до концепции. Если подсистема хранения данных выполняет делтификацию, это уже другая история.
Что касается AccuRev, я смотрел их 2-минутное вводное видео (ссылка предназначена для справки, а не для рекламы), и оно выглядит в значительной степени как ваше среднее дерево истории SCM (ветви). Предметы со значком водяных волн - это головки веток, а желтая папка - рабочая копия. Когда докладчик перемещает рабочие копии, он, кажется, делает перебазирование всех рабочих копий своего подчиненного (зло, просто подумайте о конфликтах слияния!). Значок с тремя зелеными точками (список проблем) будет списком коммитов, который будет выделен при копировании.
В одном предложении: ничего, что вы не знаете уже по опыту cvs/svn/git - двигайтесь дальше, я бы сказал.
Accurev является производным от ClearCase и принимает после потоков ClearCase UCM.
(Модель Accurev имеет некоторые сходства с UCM и хорошо принята бывшими пользователями ClearCase)
Поток - это конфигурация, то есть список меток (для компонентов, доступных только для чтения) или файлов (для записываемых компонентов), с которыми вам нужно работать (компилировать, и / или тестировать, и / или отлаживать,...).
Именно поэтому Accurev представлен как потоковая архитектура для SCM.
If имеет один частный поток на разработчика (поток рабочей области), из которого вы можете перейти к более распространенным потокам. Каждая акция обновляет конфигурацию (которая опять-таки является просто списком того, что вам нужно для работы) родительского потока.
Я дам вам техническое (не бизнес) одно предложение, основанное на стиле вашего Q:
AccuRev использует объектно-ориентированный подход к моделированию конфигураций программного обеспечения. Это так просто и круто! Особенно, если вы моделируете рабочий процесс или, что еще лучше, настраиваете непрерывную доставку (другая тема). Но я видел, что так много людей отвергают этот мощный подход к технологиям и модели данных, потому что они не могут выходить за рамки традиционных "ветвей" ala cvs, svn, p4, cc, до бесконечности. Лучшей аналогией будет сравнение серии потоков AccuRev с правилами в спецификации конфигурации в clearcase... (примечание: это просто аналогия), но гораздо более мощный, поскольку потоки - это объекты первого класса, которые поддерживают основанную на времени конфигурацию и историю.
Хитрость в понимании AccuRev заключается в том, что хотя любой данный "поток" представляет полную конфигурацию (т.е. вы можете проверить ее), фактическое содержимое этого потока определяется динамически путем агрегирования любых локальных изменений файла / каталога, любых изменений из родитель, вверх по дереву до самого верха, где собраны остальные файлы. Таким образом, всякий раз, когда вы видите "дерево" потоков, они НЕ являются ветвями... это скорее серия конфигураций, основанных на наследовании, где верхний поток подобен "суперклассу", а все [великие] дочерние элементы - [под] подклассы. Новые изменения файлов / каталогов продвигаются вверх по дереву по мере развития, интеграции, контроля качества и т. Д.
HTH _ Дейв