Работа с папками в RCS
Я следил за учебником http://www.burlingtontelecom.net/~ashawley/rcs/tutorial.html о том, как работать с файлами с помощью RCS. Это хорошо работает, но только с одним файлом. Есть ли способ создать файл RCS с каталогами, а?
У меня есть папка проекта myproject, и в этом каталоге у меня есть все мои файлы для этого проекта. Я хочу создать систему контроля версий для папки myproject и всех ее файлов, которые находятся внутри.
3 ответа
Как говорится в комментарии Уильяма, RCS работает только с отдельными файлами. (Это также, кажется, не особенно подходит для многопользовательских вещей.)
Конечно, ничто не мешает вам поместить каждый (исходный) файл в каталог под управлением RCS; на самом деле это именно то, что делает CVS (хотя в последних версиях он обрабатывает сами данные RCS, а не вызывает RCS, чтобы делать это так, как раньше). К сожалению, это довольно сильно фрагментирует историю изменений; фиксация, затрагивающая много файлов, заканчивается как отдельные коммиты для каждого файла, которые, как оказалось, имеют одно и то же сообщение о фиксации (и метку времени?), и в целом каждый файл будет иметь свою ревизию в том, что пользователь может воспринимать как "та же" ревизия. (Это делает теги весьма существенными.) CVS также имеет проблемы с атомарностью коммитов: вы можете получить коммит А и запутать коммит Б, например, в файле. foo коммит А предшествует коммиту В, но в файле bar коммит B предшествует коммиту A!
SVN (Subversion) - это попытка исправить некоторые проблемы в CVS, хотя она также приносит некоторые новые ограничения и сохраняет многие из существующих; Вероятно, разумнее (как предполагает Уильям) просто использовать распределенную систему контроля версий (DVCS) для ваших многофайловых проектов. Есть много вариантов:
- Darcs использует уникальную модель на основе исправлений: хранилище обрабатывается как последовательность исправлений, которую можно применить к пустому дереву для построения текущей ревизии; патчи часто можно переупорядочить, "коммутируя" пары патчей, и патчи для сборки вишен из других репозиториев довольно просты. Недостатком является то, что история изменений немного менее ясна, чем в большинстве DVCS. См. http://wiki.darcs.net/Using/Model, http://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory.
- DVCSs на основе ориентированного ациклического графа (DAG) моделируют репозиторий как ориентированный ациклический граф ревизий, где каждая ревизия может иметь одного родителя, двух родителей или, возможно, больше. С каждой ревизией связано состояние дерева файлов; иногда переименования также отслеживаются как-то.
- Git, как уже упоминалось. Имеет очень простую модель, но очень сложный интерфейс: есть много команд, некоторые из которых на самом деле не предназначены для использования людьми (вероятно, из-за того, что многие его части были прототипированы в сценарии оболочки), поэтому это может быть сложно чтобы найти те, которые вы хотите. Кроме того, его модель может быть слишком простой: он вообще не отслеживает переименования.
- Базар
bzr) имеет более сложную модель, включая поддержку переименований файлов / каталогов. Трудно сказать, насколько все сложнее, потому что любая существующая документация не так доступна, как в Git. Тем не менее, он имеет более простой пользовательский интерфейс, и есть ряд полезных плагинов, включая плагин SVN, способствующий распределенной разработке: фиксация из ветви обратно в SVN не должна мешать действительности других веток вашего ветви, и метаданные bzr даже передаются обратно в SVN. Может сделать вещи гораздо менее болезненными, если вы хотите начать взламывать проект на основе SVN без фиксации доступа, но надеетесь, что ваши изменения будут зафиксированы в конце концов. Bazaar - мой любимый DVCS на основе DAG. - Mercurial (иначе
hg) выглядит довольно похоже на Bazaar, хотя я думаю, что он отслеживает переименования только для отдельных файлов, а не для каталогов. Он также поддерживает плагины, хотя его плагин SVN не так хорош, как плагин Bazaar: он не поддерживает коммиты без потерь, поэтому неразумно переходить из веток других людей. У меня нет большого опыта с этим, поэтому я не могу оценить его всесторонне.
TL:DR - Посмотрите на DCVS для альтернативы RCS. Он использует CVS, который использует RCS, но он более модульный для работы в распределенном репозитории, а также с иерархией каталогов.
В настоящее время я сталкиваюсь с подобной проблемой и, возможно, нашел что-то достойное внимания, особенно для людей, которые вынуждены использовать легкие системы контроля версий на основе командной строки с несколькими членами команды.
Мой менеджер не избавится от этой идеи использования RCS в качестве контроля версий. Но что касается спецификаций, он хочет, чтобы разработчики могли создавать и редактировать свои собственные репозитории на локализованном сервере в нашей компании. Две проблемы с этим:
RCS не создает и не хранит какие-либо "хранилища". Это программное обеспечение, которое отслеживает изменения файлов на основе файлов. Это означает, что "хранилище" - это не что иное, как другой каталог с зарегистрированными файлами RCS. Это, по меньшей мере, подпроект для командных проектов.
В большом проекте с несколькими каталогами и десятками отдельных рабочих файлов даже перспектива создания каталога RCS верхнего уровня с символической ссылкой в рабочих каталогах приводит к сложностям, таким как соглашения об именах, а также забывание того, из какого файла получен файл. какой нижний уровень / рабочий каталог.
С тем, что написал SamB, даже CVS создает дополнительные проблемы с RCS, которые мы теперь должны учитывать, но дает нам небольшую возможность для некоторой дополнительной иерархии. Но одно предложение, которое он забыл, было DCVS.
Это не что иное, как расширение CVS, CVSup и:
содержит функциональные возможности для распространения хранилищ CVS с локальными линиями разработки и автоматически обрабатывает синхронизацию распределенных хранилищ в фоновом режиме.
Как уже упоминалось в комментариях, если вы начинаете с контроля версий, вам будет рекомендовано выбрать более новую систему, чем RCS (git, mercurial, fossil, subversion, ...). Тем не менее, RCS по-прежнему работает отлично для одного разработчика, работающего в основном на одной машине - я все еще использую его для своего собственного кода, потому что я еще не в порядке, как получить (20+ лет) истории, которую я хочу в git так, как я хочу.
В любом случае, чтобы использовать RCS, убедитесь, что у вас есть подкаталог RCS в каждом каталоге, где у вас есть рабочий исходный код под управлением RCS. Файлы RCS будут автоматически помещены в подкаталог и извлечены автоматически. Если ваша версия make он еще не знает о RCS, поэтому вы можете обучить его такому - или получить версию make, которая это делает (например, GNU Make).