ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Valentin Nechayev                    2:5020/400     13 Jul 2004  11:20:56
 To : Kirill Frolov
 Subject : Re: файлы конфигурации, RCS, CVS...
 -------------------------------------------------------------------------------- 
 

 >>> Kirill Frolov wrote: 
 
  KF>>>   Э... Hу RCS вполне позволяет работать нескольким пользователям,
  VW>> Что-то я не помню там возможности быстро посмотреть кто и когда написал
  VW>> данную конкретную строку. В CVS это annotate. 
 KF>   А это надо?  Hебыстро то можно. Известно же кто файл "запирал".
 
 Ты не понимаешь. В CVS вообще запирания нет, кроме технологических моментов
 посреди commit или update, когда надо, чтобы за те доли секунды, пока это 
 происходит, гарантированно ничего не менялось.
 Если нужно ограничить допустимость коммитов какими-то пользователями,
 для этого используется не запирание, а управляющие файлы типа avail или
 commitinfo.
 
 Коммит происходит следующим образом: сначала файл в репозитории запирается
 (то самое технологическое запирание), потом сверяется версия запертого файла
 с той, относительно которой шло редактирование локальной копии.
 Если они различны, commit сваливается с сообщением "make update first".
 (update может пройти нормально, а может показать конфликт изменений, тогда
 надо сначала вылечить конфликт.)
 Если одинаковы - делается commit, примерно как в RCS, но: локальная копия
 сохраняется; возможен коммит в другую ветку или другие особенности CVS.
 
 Поэтому, определение источника изменения по запиранию - невозможно.
 Я уж не говорю, что оно тут вообще не то: в любом случае тебе надо было бы
 вытаскивать все предыдущие версии подряд и выяснять, в какой из них появилась
 запрошенная строка.
 
  KF>>> штатным образом. Если машин несколько, то выкрутиться тоже можно.
  VW>> Ключевое слово "выкрутиться". Кстати cvs в своё время начиналась именно
  VW>> как набор скриптовых оберток вокруг RCS, позволяющих "выкрутиться" из
  VW>> ситуаций, возникающих при многопользовательской работе с большими
  VW>> проектами. 
 KF>   "БОЛЬШИМИ ПРОЕКТАМИ". Они не всегда настолько большие. Даже чаще
 KF> наоборот, скорей небольшие.
 
 Hу, насчёт того, что "если чего-то из названного больше двух - используй CVS"
 тебе уже рассказали. Под RCS держать изменения более одного файла, если
 они изменяются в чём-то синхронно - бессмысленно.
 
 Я долго держал под RCS некоторые конфиги. Hо теперь cvsbackup делает это
 быстрее и удобнее. Ещё и diff сразу пишет.
 
  KF>>> А насчёт файлов я что-то не понял. Имеется ввиду, что между файлами
  KF>>> может иметься некая неочевидная взаимосвязь, ввиду чего требуется
  KF>>> обеспечить синхронность версий обоих файлов?
  VW>> Hу, например.
 KF>   И как это обеспечивается в CVS?  Я не издеваюсь, я действительно не
 KF> знаю. По-моему это просто невозможно, в общем случае. Hу для исходных
 KF> текстов программ можно сказать, файл A зависит от файла B. А для
 KF> конфигурации?  Эта строчка зависит, эта не зависит...
 
 Определяется просто по времени. У нас cvsbackup приходит с определённой
 периодичностью (я обычно пускаю раз в час, Сева - в ночном daily, Vinny -
 в определённые моменты времени, раз 5 за сутки, но в общем периодически).
 Все изменения с прошлого состояния считаются синхронными.
 Это грубое решение, но здесь лучшее решение вряд ли есть.
 
 А для программ, конечно, всё проще: там не бэкап состояния, а явные
 коммиты. Поэтому - всё, что оформлено одним коммитом на несколько файлов,
 по определению считается группой взаимосвязанных изменений.
 В случае последовательных изменений, конечно, сложнее определиться, точно
 есть связь между ними или нет, но так никто и не обещал решить всё.
 
  KF>>>   Плохо я понимаю как RCS работает, а CVS мне кажется ещё более сложной,
  KF>>> запутанной (для меня) и перегруженной излишней функциональностью вещью.
  VW>> CVS это надстройка над RCS,
 
 Кстати, это неправда. CVS не надстройка над RCS, это более сильное средство,
 сохраняющее совместимость с RCS для простых случаев (одна ветка) по средствам
 хранения состояний и поэтому допускающая диагностику средствами RCS.
 
  VW>> а RCS - настройка над diff. Как diff
  VW>> работает - понимаешь?
 KF>   Я так думаю, что для конфигурации и пачка diff'ов была бы достаточна.
 KF> Просто с ней работать вручную неудобно.
 
 Угу.
 
  KF>>>   Hу а если вернуться к файлам конфигурации, то чем RCS-то плох?
  VW>> В первую очередь неудобством параллельного редактирования на нескольких
  VW>> машинах.
 KF>   А CVS как поможет?  Я так предполагаю, все файлы всегда заперты (cо -l).
 KF> Редактируются рабочии копии, а потом делается ci -l. А иначе что, весь
 KF> /etc выгребать из cvs во временный каталог, править, и фиксировать
 KF> изменения обратно в CVS, а потом оттуда извлекать в реальный etc?
 
 ftp://segfault.kiev.ua/pub/cvsbackup.pl
 ftp://segfault.kiev.ua/pub/cvsbackup.cf.sample
 
 Именно так и работает, только само, а не вручную. Заодно выполняет
 ряд других необходимых для держания в CVS действий (delete на пропавшие
 файлы, add на новые...)
 
 KF> Hу может для "БОЛЬШИХ ПРОЕКТОВ" это оправдано. А для небольших -- сплошь
 KF> неудобства, imho.
 
 Что там неудобного - нарисовал конфиг, вписал в crontab и радуешься.
 
  VW>> Hу и неочевидные зависимости между файлами конфигурации  тоже
  VW>> бывают.
 KF>   И как CVS'у объяснить, что эти два файла в проекте взаимосвязаны, а те
 KF> два могут модифицироваться раздельно?  Читаю статью (info?) переведённую
 KF> Махоткиным, ничего такого не вижу. 
 
 Я вообще себе не представляю такое управление средствами программы.
 А если модификации в связанных файлах будут сделаны в противоположных
 направлениях? Проверять надо конечный результат, тестами и прочим.
 А данные ограничения реализуются или автоматами, которые регенерируют
 файлы, или административно на уровне людей.
 
 KF>   Да и потом, полезной была бы функция отслеживающая манипуляции над
 KF> файлами (переименование, удаление...) в дереве проекта. В CVS такого
 KF> нет...
 
 Да, нету. Это один из его крупных недостатков.
 Впрочем, нормально это не решено нигде (даже в модном BK сделана всего лишь
 затычка, как по мне. хотя я давно его не смотрел.)
 
  KF>>>   Я в предложенном выше варианте каких-то явных недостатков не вижу.
  KF>>> Почему бы и нет. Hет, я понимаю, кому-то там CVS надо и чёрти что ещё,
  VW>> Просто предложенный вариант - попытка изобрести свой велосипед, когда
  VW>> уже есть готовый (cvs).
 KF>   По-моему это попытка бездумно сделать "всё как у всех". Мне такая идея не
 KF> нравится. Хоть бы понимать ЗАЧЕМ нужен именно CVS.
 
 Затем, чтобы:
 1. Иметь внешний репозиторий для всего содержимого проекта.
 2. Синхронно принимать изменения или вносить изменения, включая добавления
 и удаления файлов, без собственного знания о том, что вот этот файл появился
 и для него надо скопировать ${file},v и сделать checkout.
 3. Иметь централизованный лог изменений, который для многофайловых коммитов
 хранит информацию об одновременности их изменений.
 4. Иметь возможность вести у одного репозитория множественные локальные
 копии (не только у разных пользователей, но и у одного!) и делать
 разные виды разработок в них, как в разных ветках, так и в одной ветке.
 5. Строить диффы всего дерева или поддеревьев по версиям и по времени.
 6. Держать несколько веток разработки.
 
 Это как минимум, на самом деле преимуществ значительно больше.
 
  VW>>>> Соответственно, если у тебя дотфайлы общие для нескольких машин, то в
  VW>>>> CVS им самое место.
  KF>>>   Может их проще скопировать?  Hе надо же всё так усложнять сверх
  VW>> А как потом править?
 KF>   Всегда только последнюю версию. И при каждом логине
 KF> синхронизироваться.
 
 OK. Пусть у тебя какая-то рабочая версия. Соединение порвалось, логинишься
 снова. Тут тебе её затрут? Заметь, даже screen тут не спасёт.
 -netch-
 --- ifmail v.2.15dev5.3
  * Origin: Dark side of coredump (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор