Работа с папками в RCS

Question

Я следую учебному пособию http://www.burlingtontelecom.net/~ashawley/rcs/tutorial.html о том, как работать с файлами с помощью RCS. Это работает хорошо, но только с одним файлом. способ создать файл RCS с каталогами, а?

У меня есть папка проекта с именем myproject , и в этом каталоге у меня есть все мои файлы для этого проекта. Я хочу создать систему контроля версий для папки myproject и всех ее файлов, которые находятся внутри.

Answer 1

Как говорится в комментарии Уильяма, RCS работает только с отдельными файлами.(Это также, кажется, не особенно подходит для многопользовательских вещей.)

Конечно, ничто не мешает вам поместить каждый (исходный) файл в каталог под контролем RCS;на самом деле это именно то, что делает CVS (хотя в последних версиях он обрабатывает сами данные RCS, а не вызывает RCS, чтобы делать это так, как раньше).К сожалению, это довольно сильно фрагментирует историю изменений;фиксация, затрагивающая много файлов, заканчивается как отдельные коммиты для каждого файла, которые, как оказалось, имеют одно и то же сообщение о фиксации (и метку времени?), и в целом каждый файл будет иметь свою ревизию в том, что пользователь может воспринимать как«та же» ревизия.(Это делает теги весьма существенными.) CVS также имеет проблемы с атомарностью коммитов: вы можете в конечном итоге получить коммит A и запутать коммит B, так что в файле foo коммит A предшествует коммиту B, но в файле bar commit B предшествует commit A!

SVN (Subversion) - это попытка исправить некоторые проблемы в CVS, хотя она также приносит некоторые новые ограничения и сохраняет многие из существующих;вероятно, разумнее (как предполагает Уильям) просто использовать распределенную систему контроля версий (DVCS) для своих многофайловых проектов.Есть много вариантов:

• Darcs использует уникальную модель на основе патчей: репозиторий обрабатывается как последовательность патчей, которые можно применять к пустому дереву для построениятекущая редакция;патчи часто можно переупорядочить, «коммутируя» пары патчей, и патчи для сборки вишен из других репозиториев довольно просты.Недостатком является то, что история изменений немного менее ясна, чем в большинстве DVCS.См. http://wiki.darcs.net/Using/Model, http://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory.
• DVCS, основанные на направленном ациклическом графе (DAG), моделируют репозиторий как направленный ациклический граф ревизий, где каждая ревизия может иметь одного родителя, двух родителей или, возможно,Больше.С каждой ревизией связано состояние дерева файлов;иногда переименования также отслеживаются как-то.
  • Git , как уже упоминалось.Имеет очень простую модель, но очень сложный интерфейс: есть много команд, некоторые из которых на самом деле не предназначены для использования людьми (вероятно, из-за того, что многие его части были прототипированы в сценарии оболочки), поэтому это может быть сложночтобы найти те, которые вы хотите.Кроме того, его модель может быть немного слишком простой: он вообще не отслеживает переименования.
  • Bazaar (он же bzr) имеет более сложную модель, включая поддержку переименования файлов / каталогов.Трудно сказать, насколько все сложнее, потому что любая существующая документация не так доступна, как у Git.Тем не менее, он имеет более простой пользовательский интерфейс, и есть ряд полезных плагинов, включая плагин SVN, способствующий распределенной разработке: фиксация из ветви обратно в SVN не должна мешать действительности веток других вашихветви, и метаданные bzr передаются обратно в SVN.Может сделать вещи намного менее болезненными, если вы хотите начать взламывать проект на основе SVN без коммитного доступа, но надеетесь, что ваши изменения будут зафиксированы в конце концов.Bazaar - мой любимый DVCS на основе DAG.
  • Mercurial (он же hg), похоже, довольно похож на Bazaar, хотя я думаю, что он отслеживает переименования только для отдельных файлов, а не для каталогов.Он также поддерживает плагины, хотя его плагин SVN не так хорош, как Bazaar: он не поддерживает коммиты без потерь, поэтому неразумно переходить из веток других людей.У меня нет большого опыта с этим, поэтому я не могу оценить его всесторонне.

Answer 2

TL: DR - посмотрите на DCVS для альтернативы RCS.Он использует CVS, который использует RCS, но он более модульный для работы в распределенном хранилище, а также с иерархией каталогов.

---

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

Мой менеджер не избавится от этой идеи использовать RCS какнаш контроль версий.Но что касается спецификаций, он хочет, чтобы разработчики могли создавать и редактировать свои собственные репозитории на локализованном сервере в нашей компании.С этим связаны две проблемы:

1. RCS не создает и не хранит никакого «хранилища».Это программное обеспечение, которое отслеживает изменения файлов на основе файлов.Это означает, что «хранилище» - это не что иное, как другой каталог с зарегистрированными файлами RCS.Это, по меньшей мере, подпункт для групповых проектов.

2. В крупном проекте с несколькими каталогами и десятками отдельных рабочих файлов, даже с перспективой создания топовогокаталог уровня RCS с символической ссылкой в ​​рабочих каталогах вызывает сложности, такие как соглашения об именах, а также забывает, какой файл пришел из какого нижнего уровня / рабочего каталога.

С чемВ сообщении SamB даже CVS дает дополнительные проблемы с RCS, которые мы теперь должны учитывать, но дает нам небольшую возможность для некоторой дополнительной иерархии.Но он забыл одно предложение: DCVS .

Это не более чем расширение CVS, CVSup, и:

содержит функции для распространения репозиториев CVS с локальнымилинии разработки и автоматически обрабатывает синхронизацию распределенных репозиториев в фоновом режиме.

Answer 3

Как уже упоминалось в комментариях, если вы начинаете с контроля версий, вам будет рекомендовано выбрать более новую систему, чем RCS (git, mercurial, ископаемое, subversion, ...).Тем не менее, RCS по-прежнему отлично работает для одного разработчика, работающего в основном на одной машине - я все еще использую его для своего собственного кода, потому что я еще не совсем понял, как получить (20+ лет) истории, которую я хочу git так, как я хочу.

В любом случае, чтобы использовать RCS, убедитесь, что у вас есть подкаталог RCS в каждом каталоге, где у вас есть рабочий исходный код под управлением RCS.Файлы RCS будут автоматически помещены в подкаталог и извлечены автоматически.Если ваша версия make еще не знает о RCS, вы можете обучить ее так, чтобы она была - или получить версию make, которая это делает (например, GNU Make).