Ici Moi ([info]allter) wrote,
@ 2009-04-01 19:18:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
ещё линуксовое...
... также я сдуру поставил Ubuntu Intrepid с апдейтами. Как и следовало ожидать, дистрибутив продолжил ломательские традиции 2008 года: нет выбора не только между версиями firefox, но и kde. Естественно, ни о каких apache и mod_perl 1.x и говорить не приходится. Я даже не говорю об ужасающей локализации. Только бы эти 4е кеды при загрузке не расфигачили мои профайлы. :(((

Вопрос: кто где берёт в виде deb пакетов Firefox 2 и KDE 3.5? Естественно, что бы с устанавливаемыми из убунтовских/дебиановских sources не конфликтовали? Может есть где-то заветные урлы, на которых энтузиастами поддерживаются одлскульные пакеты?

(19 comments) - (Post a new comment)


[info]tiger1981
2009-04-03 05:26 am UTC (link)
У тебя в постах половина слов непонятные :D

(Reply to this) (Thread)

[info]allter
2009-04-03 08:27 am UTC (link)
Были бы тривиальные, вряд ли бы написал. :))) А так я их хоть сам не забуду. ;-)

(Reply to this) (Parent)

[info]neithere
2009-04-03 05:42 pm UTC (link)
о_О

почему Intrepid, ежели вот-вот выпустят Jaunty? у меня alpha5 с обновлениями, всё славно... и еще -- зачем FF2? )

кстати, в зюсе при установленных третьих кедах четвертые конфятся в ~/.kde4, а в убунте как?

(Reply to this) (Thread)

[info]allter
2009-04-03 08:01 pm UTC (link)
Почему FF2? Мне нужно, что бы у меня в истории запросов в выпадающем списке были адреса а не title-ы.

(Reply to this) (Parent)(Thread)

[info]neithere
2009-04-03 08:39 pm UTC (link)
мм.. и оно не настраивается через about:config? скверно, если так.
а Konqueror или Arora не нравятся?

(Reply to this) (Parent)

[info]allter
2009-04-03 08:02 pm UTC (link)
Дык я как раз и решил устроить себе более лёгкий апгрейд, чем 8.4 => 9.4. "Устроил".

Где профайл пока не смотрел - некогда было. :(

(Reply to this) (Parent)(Thread)

[info]neithere
2009-04-03 08:50 pm UTC (link)
йихь. кстати, нервно хихикаю, наблюдая в себе всё возрастающее желание сделать "cd /etc; hg init; hg add; hg ci -m'added files'" =)

часть системных конфигов уже действительно держу в репозитории (напр. xorg.conf, с которым недавно возился и отчаянно ломал в тч Шибко Умными Утилитами; без журнала и диффов было бы сложнее добиться результата).

а еще хочется несложным образом делать снапшоты системы вообще, как какой-нить мерсской венды в virtualbox'е... ибо хоть на ежедневно обновляемом транке живи, хоть апгрейдься раз в год -- всё время что-то ломается =(

(Reply to this) (Parent)(Thread)

[info]allter
2009-04-12 09:29 am UTC (link)
Кстати, в hg разные уровни иерархии независимы от репозитория, или там как в git: один репозиторий - один коммит на всё дерево?

(Reply to this) (Parent)(Thread)

[info]neithere
2009-04-12 10:05 am UTC (link)
.hg в корне лежит, ага.
но можно делать forest (вложенные репозитории) и с ними работать как раздельно, так и вместе.

(Reply to this) (Parent)(Thread)

[info]allter
2009-04-12 03:50 pm UTC (link)
Но для того, что бы разбить репозиторий по директориям, надо переписать всю историю изменений, да?

(Reply to this) (Parent)(Thread)

[info]neithere
2009-04-12 11:07 pm UTC (link)
http://stackoverflow.com/questions/257767/can-i-split-a-mercurial-repository

сам не пробовал, хотя, чую, придется :)

(Reply to this) (Parent)(Thread)

[info]allter
2009-04-13 10:33 am UTC (link)
А вот интересно, неужели никто не делал по технологии git/bzr/hg такую систему управления версиями, в которой каждый файл имеет независимую историю изменений - этакую смесь svn и git/bzr/hg? Понятно, что количество коммит-объектов умножится на количество файлов и каталогов, но зато можно будет сравнивать деревья (и находить историю) по "внешним" коммит-объектам...

Понятно, что сложнее будет указывать версию (в svn этому помогает глобальная нумерация версий). Но можно обойти с помощью синтаксиса URL наподобие:

xyz://hostname/path/to/repo?ver=abcdef/sub/directory/file?ver=012345

(Reply to this) (Parent)(Thread)

[info]neithere
2009-04-13 01:23 pm UTC (link)
мм.. наверно, все же накладные расходы слишком велики.. да и как хранить историю версий -- с каждым файлом таскать? тогда получается, что надо ее содержать непосредственно в файле, или каждый файл -- этакий сам себе репозиторий, который при редактировании предоставляет рабочую копию, распаковывая ее куда-нить в /tmp...
(а кстати, это не столько бред, сколько заманчиво!)

(Reply to this) (Parent)(Thread)

[info]allter
2009-04-13 01:33 pm UTC (link)
Нет, также как в DVCS: хранить в tree объектах ссылки не на blob объекты, а на commit объекты.

Версионированную инфу можно хранить в .directorиях, на Mac OS X и на NTFS можно в ресурс-форках (только тогда совсем всё будет сложно с кроссплатформенностью).

(Reply to this) (Parent)(Thread)

[info]neithere
2009-04-13 02:01 pm UTC (link)
если метаданные файла отрываются от самого файла, какой смысл отдирать файл от хранилища?
потом, вот коммит... он ведь может охватывать неск-ко файлов в разных каталогах и не иметь смысла для каждого файла по отдельности; как можно взять да отрезать ветку, при этом сохраняя коммиты? нарушается же целостность семантическая. не?

тем не менее, юзкейсы:

1. я сделал глупость в свое время -- завел большой репозиторий под джанго-приложения свои; затем его кромсал нещадно, а скоро вообще разделю на десяток реп. бывает, что приложение пишу под конкретный сайт (т.е. отдельный репозиторий со всеми настройками и дизайном), а затем выделяю в отдельное хранилище и выкладываю куда-нить на битбакет. каждый раз приходится грепать по логам и сохранять старые коммиты в ченджлог, представляющий сугубо историческую ценность (ессно, только даты и сообщения). это печально. но случай не такой уж частый и решается, видимо, вышеуказанным образом, так что необходимости в принципиально новой системе нет.

2. типичнейшая история: у меня куча текстовых документов, которые я могу переименовывать, перекладывать в другие каталоги, пересылать по мылу, расшаривать, перекидывать на флэшку, бэкапить, редактировать на разных компах и т.д. -- как мне в них разобраться? необходим контроль версий без привязки к дереву каталогов. просто вот этот файл и всё. и сравнить с другим, но не просто дифф, а именно историю. было бы чудесно сделать какой-то формат-контейнер для этого...

(кстати, что-то интересное было на эту(?) тему в OLPC-софте -- некий "дневник" и отказ от концепции файлов(!?). может, и бред... во всяком случае, логотип "один компьютер --> смерть" с подписью "children" -- точно блестящая идея.)

(Reply to this) (Parent)(Thread)

[info]allter
2009-04-14 11:28 am UTC (link)
Да, логотип OLPC - это что-то. x_x Как и символ "Rubout`а" в адресной строке в кедах. Видимо, у них андреевский крест не имеет такой чёткой связи...

Реализация - такая же как у современного поколения DVCS:

именованная ссылка:
ссылка на коммит:

коммит:
ссылка на предыдущий:
ссылка на объект (дерево или файл):

дерево:
ссылка на коммит1:
...
ссылка на коммитN:

Т.е. имеем в начале каталог D1 с элементами a == "a1-текст", b = "b1-текст" и подкаталогом d с элементами e == "e1-текст" и f = "f1-текст". В базе следующие объекты:

HEAD1(commit) = [ link: "d1", type: "tree", descr: "Начальный коммит" ]
d1(tree) = [ "a: "A1", b: "B1", d: "C2" ]
A1(commit) = [ link: "a1", type: "blob", descr: "Начальный коммит" ]
B1(commit) = [ link: "b1", type: "blob", descr: "Начальный коммит" ]
a1(blob) = "a1-текст"
b1(blob) = "b1-текст"
C2(commit) = [ link: "d2", type: "tree", descr: "Начальный коммит" ]
d2(tree) = [ "e: "E1", f: "F1" ]
E1(commit) = [ link: "e1", type: "blob", descr: "Начальный коммит" ]
F1(commit) = [ link: "f1", type: "blob", descr: "Начальный коммит" ]
e1(blob) = "e1-текст"
f1(blob) = "f1-текст"

Многовато, конечно. 50% - объекты - коммиты.
Если мы меняем /b на "b2-текст" и /d/f на "f2-текст", то в базу пишутся следующие объекты:

HEAD2(commit) = [ link: "d3", type: "tree", descr: "Многоуровневый коммит" ]
d3(tree) = [ "a: "A1", b: "B2", d: "C3" ]
B2(commit) = [ link: "b2", type: "blob", descr: "Многоуровневый коммит" ]
b2(blob) = "b2-текст"
C3(commit) = [ link: "d3", type: "tree", descr: "Многоуровневый коммит" ]
d3(tree) = [ "e: "E1", f: "F2" ]
F2(commit) = [ link: "f2", type: "blob", descr: "Многоуровневый коммит" ]
f2(blob) = "f2-текст"

При этом:
> xyz-log /?ver=HEAD2
@HEAD2: "Многоуровневый коммит"
/b
/d/f
@HEAD1: "Начальный коммит"
/a
/b
/d/e
/d/f

т.е. ченджсеты сохраняются.

(Reply to this) (Parent)(Thread)

[info]allter
2009-04-14 11:42 am UTC (link)
errata: Забыл ссылки на предыдущие в объектах-коммитах.
HEAD1(commit) = [ prev: 0, link: "d1", type: "tree", descr: "Начальный коммит" ]
A1(commit) = [ prev: 0, link: "a1", type: "blob", descr: "Начальный коммит" ]
B1(commit) = [ prev: 0, link: "b1", type: "blob", descr: "Начальный коммит" ]
C2(commit) = [ prev: 0, link: "d2", type: "tree", descr: "Начальный коммит" ]
E1(commit) = [ prev: 0, link: "e1", type: "blob", descr: "Начальный коммит" ]
F1(commit) = [ prev: 0, link: "f1", type: "blob", descr: "Начальный коммит" ]

HEAD2(commit) = [ prev: "HEAD1", link: "d3", type: "tree", descr: "Многоуровневый коммит" ]
B2(commit) = [ prev: "B1", link: "b2", type: "blob", descr: "Многоуровневый коммит" ]
C3(commit) = [ prev: "C2", link: "d3", type: "tree", descr: "Многоуровневый коммит" ]
F2(commit) = [ prev: "F1", link: "f2", type: "blob", descr: "Многоуровневый коммит" ]

(Reply to this) (Parent)

[info]nahaa
2009-05-01 03:03 pm UTC (link)
с днем рождения Вас, наш далекий под-московский товарищ! :)
многообразных радостей и благ

(Reply to this) (Thread)

[info]allter
2009-05-01 03:37 pm UTC (link)
Спасибо, Надежда! :)

(Reply to this) (Parent)

(19 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…