Раз уж пошла такая пьянка (штампы — отстой!) в описании отстоев (кстати, вахтерши в подъезде — отстой!), то нельзя не сказать о bzr.

Bazaar — это такая распределенная система контроля версий, по-отстойному названная, видимо, в честь отстойной книжки The Cathedral and the Bazaar, которую написал красавец Eric S. Raymond, который лучше бы писал fetchmail, а не книжки, которые я не читал и не буду. На базаре делают убунту. Bzr отличается от других тем, что документацию для него пишут живые люди, а не хрустальные черепа из "Индианы Джонса".

Так вот, это отстойная система по одной причине:

added "Mémoires.xcodeproj"

bzr: ERROR: exceptions.KeyError: u'Me\u0301moires.xcodeproj'

Traceback (most recent call last):

File "/Library/Python/2.5/site-packages/bzrlib/commands.py", line 846, in run_bzr_catch_errors

return run_bzr(argv)

File "/Library/Python/2.5/site-packages/bzrlib/commands.py", line 797, in run_bzr

ret = run(*run_argv)

File "/Library/Python/2.5/site-packages/bzrlib/commands.py", line 499, in run_argv_aliases

return self.run(**all_cmd_args)

File "/Library/Python/2.5/site-packages/bzrlib/builtins.py", line 373, in run

no_recurse, action=action, save=not dry_run)

File "/Library/Python/2.5/site-packages/bzrlib/mutabletree.py", line 52, in tree_write_locked

return unbound(self, *args, **kwargs)

File "/Library/Python/2.5/site-packages/bzrlib/mutabletree.py", line 412, in smart_add

this_ie = parent_ie.children[directory.base_path]

KeyError: u'Me\u0301moires.xcodeproj'

bzr 1.5 on python 2.5.1 (darwin)

arguments: ['/usr/local/bin/bzr', 'add']

encoding: 'UTF-8', fsenc: 'utf-8', lang: 'ru_RU.UTF-8'

plugins:

bzrtools /Library/Python/2.5/site-packages/bzrlib/plugins/bzrtools [1.5.0]

fastimport /Users/dmitry/.bazaar/plugins/fastimport [unknown]

launchpad /Library/Python/2.5/site-packages/bzrlib/plugins/launchpad [unknown]

qbzr /Library/Python/2.5/site-packages/bzrlib/plugins/qbzr [0.9.0]

rebase /Library/Python/2.5/site-packages/bzrlib/plugins/rebase [0.3.0dev0]

*** Bazaar has encountered an internal error.

Please report a bug at https://bugs.launchpad.net/bzr/+filebug

including this traceback, and a description of what you

were doing when the error occurred.

В общем, файл с é в нее не добавляется. На маке. Вот объяснение:

Thanks for the bug report. This is sort of a "known bug" with Mac's

filesystem. In that the rest of the world considers ü to be a single

character: u'\xfc' (LATIN SMALL LETTER U WITH DIAERESIS),

Mac re-normalizes it to 2 u'u\u0308' ('u' and '\u0308' COMBINING DIAERESIS).

Now, Unicode specifies that those are both valid ways of representing

the concept of ü.

However, it means that if you create u'\xfc' on Linux, and commit. And

then checkout on Mac, all of the sudden your existing file is marked as

missing, and the new file is marked as unknown.

In bzr 0.14 and earlier we tried to account for this fact. So when files

were added, on non-Mac we would check that they were properly

normalized, and on Mac we would re-normalize (to account for Mac's choice).

However this causes some other problems, because other platforms don't

always normalize (Win32 seems to create wide character japanese

parenthesis).

All other systems that I tested just ignore this (and live with the fact

that a versioned file now has changed name on Mac, and thus forces all

other platforms to use a different name).

So we decided to stop fighting as hard for what we considered

"correctness" in 0.15. But obviously some of the old code remains.

If you just want your import to succeed, you can:

1) Use WorkingTree3 (bzr init --knit) which is the format for 0.14

and earlier.

2) Take out all calls to 'osutils.normalized_filename()'.

The internals will then treat paths by whatever they exist on disk, and

it is up to the user to deal with the fact that Mac OS X is breaking

their filenames. (which is what svn, cvs, git, darcs, and hg do).

I'm sorry this is causing a problem for you. We were trying to be nicer,

but it seems to be causing more problems than it helped.

Что в дословном переводе значит:

В Линуксе буковка ü — это буковка LATIN SMALL LETTER U WITH DIAERESIS, на Маке — 'u' and '\u0308' COMBINING DIAERESIS. Раньше мы делали так, чтобы это значило одно и тоже, но так как мы тормоза и не можем писать нормальный код, это ломало еще какую-то фигню в Винде, поэтому мы просто забили на это и предлагаем мак-юзерам следующее решение:

— использовать старый дебильный формат репозитория;

— пройтись по миллиону файлов кода bzr и закомментить osutils.normalized_filename();

— идти в жопу.

Поэтому я перешел обратно на git, хоть в нем ID коммитов и выглядят как ДНК обезьяны: 0cc2815f7c736e44961d0e67a07fde80ba0737ab ("Скажите, какая версия Mémoires у вас?" — "Версия 1.1 (оу-си-си-ту-эйт-уан-файв-эф-севен-си-севен-фри-сикс-и-фор-фор-найн-сикс-уан-ди-оу-и-сикс-севен-эй-оу-севен-эф-ди-и-эйт-оу-би-эй-оу-севен-фри-севен-эй-би)!").

Oleg Andreev 2008-05-25 21:08

Ты же знаешь, что в гите принято сокращать номера коммитов там, где это некритично. В случае номера билда можно сокращать до первых 4-6 символов. И будет ДНК не обезьяны, а всего лишь амебы.

Ага, но фигово, что они не инкрементные.

dimas 2008-05-26 01:08

А не проще пропатчить эту самую normalized_filename, хотя бы заменив на пустышку? И править мало, и проблема будет решена.

dimas: я к такому решению и пришел, но мне не захотелось с этим возиться — раз сами разработчики игнорируют юзеров, то ну их нафик.

and 2008-05-26 11:08

А не пробовали ещё Mercurial? Если да, то что в нём не понравилось?

Виталий 2008-05-26 12:08

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

Виталий, ха-ха, неандертальцы что ли? Еще про CVS скажите.

Виталий 2008-05-26 14:08

нет, про CVS я ничего не скажу.

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

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

а ты вот мечешься ;)

Смысл вот тут — https://sellme.biz/2007/12/11/linus-torvalds-on-git (фиг с Линусом, там мои комменты).

Насчет разума —

git init

git add *

Все.

git commit -a

git push

Что тут сложного? Как раз для одного разработчика ничего лучше git (или любой другой подобной системы [кроме bzr]) не найти.

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

Стоит сказать, что svn постепенно движется в сторону распределенных систем и к версии так 3 будет, наверное, юзабельным.

Виталий 2008-05-26 14:08

у тебя по ссылке два аргумента:

1. долго ждать коннекта к базе

2. засоряет папки

второй отметаем как ерундовый (на этапе сборки продукта это некритично, в инсталлятор идет ровно то, что надо)

первый решается локальной базой (ну, в смысле базой в локальной сети).

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

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

смысла в распределенных системах нету. для одиночек - нету. для компаний - точно нету. линусу это было надо в силу специфики техпроцесса.

Виталий: пунк 2 критичен, причем очень, для разработки под Mac OS X, где есть бандлы — папки, ведущие себя как файлы.

Локальная база — отстой, репозиторий надо хранить удаленно. Причем в нескольких местах :)

Все плохое решается параметром --force :)

Смысл есть и для первых, и для других. Как я уже говорил, и svn туда придет.

Виталий 2008-05-26 14:08

ну есть, и чего? ты юзеру один фиг dmg будешь делать. будешь? будешь. положи туда все, кроме .svn, и будь счастлив.

что касается локальной базы, то хранится она на сервере, бекапится периодически и раскидывается "по нескольим местам". хранить саму базу в инете я смысла не вижу. а вот бекапы заливать на какой-нибудь специальный сервер - это да.

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

Кроме юзеров есть еще переводчики, которые переводят .nib. Мне нужно их трекать.

Как раз для этого и нужна распределенная система — чтобы не бекапить, а распределять :)

and 2008-05-26 18:08

Похоже Mercurial(hg) здесь табу.

hg не пробовал.

Расскажите, кстати, чем он (hg) выгодно отличается от git.

KBA-KBA 2008-07-28 19:08