Отказ от ответственности: я лучше всего понимаю систему управления версиями 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