a rasskazhi poka, chto govorili _af_ i Jura?

(Reply to this) (Thread)

Не, не хочу. Потом. Хочу послушать других сначала, если вдруг кто что скажет :)

(Reply to this) (Parent) (Thread)

Ну вот, в следующем посте и рассказала. Только насоветовали больше про перенос, чем про локальное хранение.

(Reply to this) (Parent)

У меня кошмарный бардак с файлами, хотя у меня меньше "точек". Два компьютера дома и один на работе. Плюс еще дискетки, на которых я все это ношу. Самую новую версию приходится искать путем долгих мыслительных усилий и сличения даты и содержания. Это ужасно. Недавно меня попросили переслать кому-то дисер. Он у меня в четырех файлах и у каждого три-четыре-пять версий. Чуть с ума не сошла. Я думала это исключительно следствие моей безолаберности. А расскажи чего люди советуют?

(Reply to this) (Thread)

Расскажу-расскажу. Пока скажи, действие происходит в виндах?

(Reply to this) (Parent) (Thread)

Да, в них родных.

(Reply to this) (Parent)

Я всегда перед началом добавления текста в файл присваиваю ему следующий номар при сохранении того же имени (otchet_modality07, otcht_modality08), а когда работа закончена присваиваю ему же какое-нибудь финальное название (otchet_modality_all, otchet_modality_final) и т.п. таким образом, когда у меня встречаются версии одного файла я всегда знаю с какой я работала последний раз. Если какая-то часть файла, вдруг поселилась в отдельном файле, я называю ее с сохранением начала файла, а дальше идет подхахактеризация (otchet_modality_literature, syntax_problem_set_ex7) и т.п. В результате сразу видно, кусочек чего это, и в какое место его вставлять.

(Reply to this) (Thread)

В системах вроде RSX и VMS версия являлась частью имени файла и увеличивалась автоматически. Правда, работало это только внутри одного компьютера -- сети тогда еще не так были распространены.

(Reply to this) (Parent) (Thread)

Предпочитаю самостоятельно. Надежнее.

(Reply to this) (Parent)

То-то же, что это только локально.

(Reply to this) (Parent)

И я так и не поняла, почему от этого потом отказались.

(Reply to this) (Parent) (Thread)

Не столько отказались, сколько не взяли в свою систему. RSX -- это семидесятые годы; UNIX тогда уже был. Введение такой штуки в UNIX создает некоторые сложности.
Ну, а ДОС с потомками -- это, скорее, производные CP/M. Там, насколько я помню, этого тоже не было.
(Вот ядро NT имеет какое-то отношение к VMS, у них был общий главный архитектор. Но к тому времени уже все привыкли, что имя -- это имя и версии не содержит.)

(Reply to this) (Parent)

Ага. А исходные файлы, otchet_modalityXX, удаляешь или оставляешь на всякий случай?

(Reply to this) (Parent) (Thread)

Стираю где-то через полгода при общей чистке

(Reply to this) (Parent)

1. CVS (иногда не хватает организованности -- завести в CVS/svn модуль, да делать commit вовремя...)
2. visual diff (недавно вот нашёл meld)
3. для нескольких наборов файлов, например, запусков программы -- поддиректории с именами вроде 040922/{1-comment1,2-comment2}
4. для версий одного файла -- имена вроде prefixes-2004-04-33.tex

И большое спагетти из всех четырёх методов понемногу :)

Вот сейчас сюда придёт Беркгаут, и тотчас всё объяснит.

(Reply to this) (Thread)

CVS на одну персону мне почему-то напоминает онанизм. (Да, я совершенно асексуальна и радости от онанизма не получаю!)
Нумерация версий, как у тебя и Мура_вья, хороша для организации пространства, но, мне кажется, забивает место и рябит в глазах. Оно конечно, диски у нас ныне просторные...
А как это -- Visual diff? Я знаю обычный дифф и diff3.

(Reply to this) (Parent) (Thread)

Да хоть монархизм! (Интересно, многопользовательский unix на одну персону тебе что-нибудь напоминает?)

CVS хорош и тем, что версии сохраняет -- не только удобным merge.

Место CVS тоже занимает, хотя меньше, чем нумерация версий.

visual diff -- это когда тебе цветами раскрашивают и линии рисуют, откуда какая строчка есть пошла. Как и всякий diff, плохо работает на jpg-файлах, не говоря уж о ворде. :)

Мечта, на самом деле -- persistent filesystem, которая хранит все версии прозрачно...

(Reply to this) (Parent) (Thread)

Многопользовательский Юникс на одну персону мне ничего не напоминает, потому что я такого не видела пока в лицо -- на всех знакомых машинах хоть два человечка были, а все ж мультиюзерность :)
CVS занимает не столько место, сколько твое время. Вопрос, стОит ли последующая неразбериха этого потраченного времени, -- кстати, не совсем уж бессмысленный.
Visual diff: то-то же! А авторы лингв. задач шлют задачи только в вордовых форматах, кстати. Да и работы с jpgами после появления цифрового фотоаппарата у меня прибавилось :)

(Reply to this) (Parent)

Мечта, на самом деле -- persistent filesystem, которая хранит все версии прозрачно...
Насколько я понимаю, ты имеешь в виду то, что есть в Plan9.
Там можно обратиться к файлу <не помню префикс>/<дата>/<имя файла>.
Жалко, на самом деле, что Plan 9 по другим причинам не поставишь в качестве основной системы.

(Reply to this) (Parent) (Thread)

Вот-вот! Именно plan9 и не хватает :)
Интересно, plan 9 filesystem for linux -- может быть?

(Reply to this) (Parent) (Thread)

О! А все красивое -- от Гнома!

(Reply to this) (Parent) (Thread)

А гном красив? :)
Может, тогда от Mac OS X? :)

(Reply to this) (Parent)

1. Тут существенна не сама файловая система (как способ раскидывания байтов по диску), а 9p, как протокол общения с этой системой. Кажется, кто-то типа Ron Minnich что-то пытался делать на тему драйвера 9p для Linux, но далеко не продвинулся.
2. Эта самая система в Plan 9 состоит из программы, которая раз в сутки делает инкрементальный бэкап, и файл-сервера, который по этому самому 9p составляет из бэкапов взгляд на файловую систему. В принципе, никто не мешает написать нечто подобное и под Linux (либо в виде драйвера fs, либо раздавать по какому-нибудь протоколу). Но пока что никто не написал.

(Reply to this) (Parent) (Thread)

Ну да, я не говорил о раскидывании байтов -- кстати, тут ведь проблем с раскидыванием нет, потому что ничего не удаляется :) -- а иметь именно нативно подключённую систему, которая сохраняет версии (а уж как при необходимости эти версии из неё добывать, не так важно...) Чтобы не делать commit руками каждый раз :)

А правильно я понимаю, что раз backup раз в сутки, то и версии сохраняются только те, что были в полночь?

(Reply to this) (Parent) (Thread)

Правильно.

(Reply to this) (Parent)

А просто делать backup раз в сутки -- это вообще доблесть небольшая. Запустить tar с нужными ключами через cron -- и все. (Ну, еще потребуется несколько строчек шелла, чтобы отмечать удаленные файлы.)
Тут прелесть как раз в основном в легкости доступа.

(Reply to this) (Parent) (Thread)

Доблесть небольшая, это верно...
Да, в общем, доступ лёгкий получить не проблема. Либо программу написать, либо в midnight встроиться.

Мне-то хочется, чтобы автоматически все версии сохранялись (ну как если бы после каждого закрытия файла, открытого на запись, делался cvs commit).

(Reply to this) (Parent)

http://sourceforge.net/projects/v9fs/
надо бы глянуть...

(Reply to this) (Parent) (Thread)

Это именно тот проект, о котором я говорил. Последний релиз -- декабрь 2002 года. И, как я, пять же, писал, тут мало 9p (и он даже не очень существен), а нужен определенного вида сервер поверх.

(Reply to this) (Parent)

О, какая прекрасная и полезная поднята тема!

(Reply to this) (Thread)

Мы еще и не то могем :)

(Reply to this) (Parent)

gogabr@lj плохого не посоветует. Я думаю, version control в любом виде, особенно для текстовых файлов и особенно если есть паралельная работа в нескольких направлениях. Не нравится CVS, попробуй чего другое. Обычный rcs вполне хорош; если пользуешь emacs, то он с ним интегрирован. На работе у нас perforce - он хорош тем что у него plug-inы ко всему на свете (но в основном не для линукса). По моим наблюдениям, люди быстро зацепляются на version control, если он интегрирован с их программами. Но вообще-то, меня всегда поражает сколько упорства и времени люди тратят чтобы не пользоваться version controlом.

(Reply to this) (Thread)

Ото-то ж! ежли интегрирован! а емакс я в последнее время не. (Интересно, кстати, почему, раньше я с ним ладила.) Я vi в основном пользуюсь. И pico.

(Reply to this) (Parent)

На работе у нас perforce - он хорош тем что у него plug-inы ко всему на свете (но в основном не для линукса).

а для чего?

(Reply to this) (Parent) (Thread)

Emacs, VisualStudio, CodeWarrior, Eclipse, Windows Explorer.

(Reply to this) (Parent)

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

Задачу переноса данных на машину только с неработающим дисководом я не рассматриваю - решение там очевидно, но неинтересно... Переписать на бумажку, если кто не понял... А задачу бардака я решаю просто - если компьютеров в проекте более одного, CVS обязателен (исключение - если компьютеров два и один из них - пальм, тогда как бы репозиторием является десктоп, а все прочее - точно так же). Затем - я помню, где у меня текущая рабочая версия текущей задачи (ну, двух-трех, если я за день успел заняться двумя-тремя), и я не переключаюсь с одной задачи на другую, не закоммитившись. Если для коммита приходится что-то носить на внешнем носителе - я помню, что вот эту штуку надо первым делом с этого носителя взять и закоммитить. Поскольку таких штук больше 3 одновременно в норме не бывает (а если бывает, то в том же пальме есть todo list), то тут бардака не происходит.

Что до ворда - с ним ровно одна проблема. diff не посмотришь. Для смотрения диффа рекомендуется патентованный метод - перед каждым коммитом catdoc его (в крайнем случае save as text), и полученный текст закоммитить рядом. Там не будет отражена правка в оформлении, но ее дифф обычно смотреть и не нужно - если она важна, про это было записано в commit log.

Со жпегами, с одной стороны, хуже, а с другой - от них в норме требуется хранить только исходник и последнюю обработанную версию.

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

И сразу: для межкомпьютерной синхронизации используется rsync. Поверх ssh или флоппинета.

(Reply to this) (Thread)

Для начала заметим, что для использования CVS достаточным поводом будет, чтобы в проекте хотя бы чего-то было более одного - файлов, разработчиков или компьютеров.
Дак если много только файлов, то каждый можно держать под RCS, а она (он?) менее громоздкий, чем CVS. А почему у Вас это вызывает протест?
Задачу переноса данных на машину только с неработающим дисководом я не рассматриваю - решение там очевидно, но неинтересно... Переписать на бумажку, если кто не понял...
Зато компьютеров без дисковода щас все больше появляется. Правда, в них есть юсб-дырья, а то и СиДи-писалки.

А так -- получается, что в голове много всего надо держать. У меня лично памяти не хватает :( Тут, понимаете, взаимосвязь разрухи на диске и разрухи в головах: я все думаю, как бы программными средствами разгрести последнюю. Не уверена, впрочем, на 100%, что это можно.

(Reply to this) (Parent) (Thread)

> Дак если много только файлов, то каждый можно держать под RCS

Если они между собой должны быть как-то синхронизированы - нет. Он срезов не дает. Он работает с каждым файлом независимо.

> а она (он?) менее громоздкий, чем CVS

И сильно? Если речь вообще идет о том, что на данном компьютере можно работать с вордовыми файлами?

$ ls -l /c/bin/cvs.exe 
-rwxr-xr-x    1 ran      Админист   561152 Feb 18  2004 /c/bin/cvs.exe

> Зато компьютеров без дисковода щас все больше появляется. Правда, в них есть юсб-дырья, а то и СиДи-писалки.

Именно. Между "только с неработающим дисководом" и "с отсутствующим дисководом, но массой других вариантов для обмена с внешним миром" есть некоторая разница...

> как бы программными средствами разгрести последнюю.

Я сразу понял задачу. Потому, собственно, к указанию двух программных средств добавил описание алгоритма его использования. Для головы.

(Reply to this) (Parent)