Вроде, NFK* не приведут национальные символы, к латинице. Т.е. NFKD для русского «ё» = русское «е» + комбинирующий ":", а не латинское «e». Да и для того, что бы канонически разложить Ж, скажем, на >I< надо свою либу писать…
Вообще-то, прямо зависимые. Одно дело рассматривать сферические мерджи в вакууме (что SVN, что git с такими _не_ справляются — то контекста им не хватает, то ещё чего), другое — реальные ситуации правки исходников и бинарников конкретного проекта.
Пример с драйверами в Linux показательный, т.к. драйвера, поддерживающие модульное исполнение, как правило, — независимое от основного ядра ПО, размещённое в отдельном каталоге. В svn для их форка достаточно просто сделать svn copy, а в git для этого придётся переписывать историю коммитов, с выкидыванием из changeset`ов не относящихся к данному драйверу файлов. При этом история изменений в случае SVN сохранится в виде «бесплатного» приложения к копированию, а в случае git придётся следить за копированиями, склейками и переименованиями файлов вручную (можно скрипт написать, но пока общеупотребимого нет). Поэтому, несмотря на централизованность, SVN, я считаю, остаётся более динамичным в плане разработки, естественно, в случае, когда распределённости не требуется впрямую (<20 разработчиков из одной конторы над одним [под]проектом). Но вот дикая сложность мерджей угнетает, особенно, когда апстрим работает под версией <1.5.
Опять же, описанные ситуации довольно редкие и относятся больше к скриптовым, а не транслируемым в машинный код проектами. Так что, опять же специфика предмета проекта влияет на выбор «правильной» VCS/SCM.
Кстати, вроде бы в Mercurial с расширением forest, указанная проблема решается.
1) и реально выкидываются (случаи, когда подпроект существует уже несколько месяцев не в счёт), или это вы предположили из общих соображений?
про теги имелось в виду — то, что при любой переписи истории, криптографические теги будут испорчены, поскольку они созданы для другого коммита/дерева.
2) получается, не всё, что может SVN. Он хорош именно проработанностью в смысле use cases (с учётом, что когда SVN проектировался, мерджи и DVCS-фичи редко какие проекты использовали). То, что исполнителю можно дать определённый небольшой участочек работы — это очень удобно.
Понятно, что с этими ограничениями борются планированием структуры проекта, но SVN удобен тем, что можно именно разрабатывать активно (впрочем, в других аспектах git рулит в этом отношении ещё больше).
Накладных расходов «веток на каждый чих» в SVN нет (они сами хвалятся в документации своим O(1) ). Если не нравится засорение пространства имён, то просто удаляйте такие ветки после чихов.
Ну и стиль использования «стабильный trunk» можно реализовать и в svn.
В ближайшее время svk в текущем виде устареет из-за отсутствия поддержки merginfo апстрима. :( А Foror`у, действительно, надо было просто создать личную ветку, а утром её закончить, реинтегрировать и удалить (если она ему глаза замозолила).
Да? Предложите тогда решение для следующих use case:
1) Файл/каталог B _внутри_ репозитория создан с помощью чего-то вроде svn copy на основе, соответственно, файла/каталога A. Есть ли способ из такого подпроекта B черрипикнуть изменения в подпроект A с помощью git? Как в таком случае (раздвоения части проекта на несколько) поступают git`овцы? Неужели сразу, как только забрезжит такая возможность, выкидывают кусок изменений в субмодули (та ещё нетривиальная задача, поскольку, как минимум, все теги в субмодуле исчезнут/станут кривыми)?
/* По мне, так неподдерживание git`ом равноправных вложенных деревьев — самый большой его недостаток. С другой, стороны, понятно, для чего так сделано: ясность и производительность. */
2) Как с помощью git работать над драйвером linux из дистрибутива ядра так, что бы не тащить к себе в раздел всё дерево исходников linux в качестве working copy?
Кстати, было бы хорошо, если бы вы написали, как работается с git-svn. Насколько удобно «интегратору» сидеть на git «сбоку» от основного SVN (поддерживающего или нет merge tracking)?
А то я тут поработал с svk (работая с //local через рабочие копии svn клиента) и merge tracking — настолько всё было тяжело из-за того, что история мерджей в разных форматах и из-за того, что svk необратимо склеивает несколько разноплановых коммитов в один мердж-коммит. :(
А вот используя только git (есть опыт) всё так удобно и логично. Главное всегда помнить философию git — манипулирование не срезами деревьев в разные моменты (хотя эта фича тоже основная в git), а манипулирование патчами в контексте предыдущей истории проекта.
Просто раздражают эти издевательства над power-пользователями. Ну, запрятали бы рута куда-нибудь внутрь с нетривиальным включением… Так нет, надо наворотить что-то своё.
Кстати, эта статья не говорит ничего про поддержку радио (WiFi/Bluetooth/GPS/GSM) из линуксовского юзерспейса. Как там с ними?.. Там ведь блобы или как? И можно ли целиком прошивку (внутреннюю флешку) пересобрать?
Главное не ставить обработку юникода в библиотеки (кроме application-specific модулей).
Различия непринципиальны, если помнить всегда, что на выходе любых методов получается всегда такой же объект. А вот в случае операторов (во всяком случае, в перле), это не так. В перле обычно, в результате оператора, с одной из сторон которого стоит символьные строки, получаются символьные строки с неявным преобразованием байтовых в символьные.
$ uname -a
Linux WL700gE 2.4.20 #44 Sat Jan 26 20:07:26 EST 2008 mips unknown
Плюс в стандартной прошивке: uClibc, busybox. Плюс optware-порты под эту платформу. В общем, кривизна на кривизне, если говорить про архитектуру — содержимое / менять очень геморройно.
Верно. Я в связи с этим избегаю вообще использовать понятия строк таких-то, строк сяких-то. Есть два типа объекта: вектор/массив байтов и вектор символов (собственно, строка). Они просто имеют похожий интерфейс.
Кстати, проблем не так много, если рассматривать данные сущности, как полиморфные классы с похожим интерфейсом.
Идеалогия git подразумевает, что хранить что-то в каталоге твоего модуля, кроме твоего модуля — не стоит. Вместо этого лучше сделать рядом чекауты всех необходимых модулей, и работать с ними независимо. Тем более, что в случае --bare репозиториев (в которые могут коммиттить-пушить соразработчики) красивость межрепозитарных зависимостей теряется.
Если svn:externals, в основном, используются для удобства: «можно работать с библиотекой в этом подкаталоге», то git-submodules — для указания: «ребята, данный git-репозиторий работал с указанным коммитом из того репозитория, можете вытянуть себе».
Т.е. это похоже на svn:externals, но не то. Более аналогичным был бы подход nested trees, когда всё, необходимое для работы было бы сосредоточено в одном репозитории, с выбором нужного подрепозитория по путям (как в svn). Так вроде, собираются поступить в bazaar.
Через потоки POSIX передаются не только текстовые, но и бинарные данные. Так что я согласен с доводом максимальной стандартности, но при этом надо чётко отрецензировать большое количество библиотек, многие из которых, особенно на win32 уже не поддерживаются и даже не имеют исходников. Это — малореально…
Ибо тогда, к примеру, возникает вопрос: а что делать по умолчанию с потоками, где встречаются utf-суррогаты и отсутствующие символы (например, дуализм unicode 0x0 и java 0x0). Это нетривиально, поэтому в Перле в конце концов (5.8.x) остановились на варианте максимальной совместимости со старым кодом (не придумывать ничего за программиста). Вставить же в начале программы прагмы (слои) потоков (PerlIO layers) — способен программист любого уровня (но с этим постоянные проблемы, т.к. люди просто не понимают разницу между семантикой данных и сериализацией этих данных).
P.S. Прежде чем делать стандартизованный ввод/вывод, надо хотя бы от последнего американского программиста добиться замены char * на unsigned char*, а ещё лучше — на безопасные unicode-контейнеры.
P.P.S. проверил на Asus wl700ge (optware) — там raw_input вообще не запрашивает ввод. ;-) А вы говорите, админа… Понятно, что в linux, freebsd (и macosx) всё нормально с локалями, но этими системами хосты не ограничиваются. Поэтому о стандартизации ввода/вывода можно будет говорить не ранее, как отрапортуют об успешном решении «проблемы 2038K» :)
А если на системе кривая локаль, а приложение должно работать?.. Я, если честно, вышеприведённый мной пример сначала попробовал на cygwin — там ничего не заработало, т.к. там криво реализованы POSIX-локали. В Перле автоматический ввод/вывод в юникоде реализуется с помощью переменной окружения PERL_UNICODE, но это тоже не универсально, т.к. там много пограничных случаев. В частности, только автор может решить в какой кодировке ему работать с нестандартными потоками ввода/вывода (они ведь могут вообще быть бинарными).
Собственно, я и сообщал автору исходника, что комп не знает, что в raw_input вводится юникод. Пример, как надо работать с вводом (хотя там сложнее немного):
x@y:~$ echo $LANG
ru_RU.UTF-8
x@y:~$ python
Python 2.5.2 (r252:60911, May 7 2008, 15:19:09)
>>> print raw_input( 'превед ' ).upper()
превед медвед
медвед
# ^-- python не телепат
>>> import locale
>>> print raw_input( 'превед ' ).decode(locale.getdefaultlocale()[1]).upper()
превед медвед
МЕДВЕД
# ^-- как надо было
Кроме этого, есть ещё такая фишка, как драйвера. Не знаю как для дискретных видеокарт, а для моей NV 8600 GT производитель в вистовские драйвера включил неотключаемый турбокэш на 700 Мб, в результате при 2 гигах ОЗУ игрушка, под которую я покупал ноутбук, оставалось меньше 700 Мб основной памяти. И что бы отключить эту фичу можно было поступить двумя способами: искать нужную версию драйверов, где присутствовала возможность изменения размера турбокэша, потом копаться в реестре и хачить видеопрошивку, либо просто поставить XP.
Не трудно догадаться, что в такой сделает пользователь, которому нужно «по простому». Тоже самое сделал и я.
Это показывает, что вопрос производительности — это не только железо и криворукость писателей DirectX, но и странные организационно-архитектурные решения.
Потому что git submodule, увы, не аналог svn:externals (если не учитывать редкие случаи использования, случайно совпадающие). Спорят пока о реализации, т.к. там слишком много edge cases, учитывая распределённую натуру git.
А откуда python узнает, что в переменной a — юникод строка? Или, может, в культуре запускающего программу нет понятия букв в верхнем регистре — он использует только нижний регистр, или, наоборот только ВЕРХНИЙ? разве в питоне нет возможности обрабатывать вводимые строки в соответствии с явно прописанной локалью пользователя или программиста (что-то типа setlocale)?
К примеру, несмотря на юникод, в какой-то из культур (то ли шведской, то ли норвежской) принятый порядок лексикографического сравнения латинских букв с диакритическими знаками отличается от общепринятого в остальных странах Европы и попытка лексикографической сортировки «по умолчанию» у таких пользователей пройдёт не так, как они хотят.
Интернационализация — слишком сложная вещь, что бы её можно было решить заменой литералов вида u'юникод' на 'юникод'…
apt-get — всего лишь транспортный агент со связкой с dpkg для регистрации пакетов в системе (в случае debian-based дистрибутивов). dselect+apt и aptitude — фронтенды к apt, соответственно, у них своё понятие о наборе выделенных к установке пакетов.
Пример с драйверами в Linux показательный, т.к. драйвера, поддерживающие модульное исполнение, как правило, — независимое от основного ядра ПО, размещённое в отдельном каталоге. В svn для их форка достаточно просто сделать svn copy, а в git для этого придётся переписывать историю коммитов, с выкидыванием из changeset`ов не относящихся к данному драйверу файлов. При этом история изменений в случае SVN сохранится в виде «бесплатного» приложения к копированию, а в случае git придётся следить за копированиями, склейками и переименованиями файлов вручную (можно скрипт написать, но пока общеупотребимого нет). Поэтому, несмотря на централизованность, SVN, я считаю, остаётся более динамичным в плане разработки, естественно, в случае, когда распределённости не требуется впрямую (<20 разработчиков из одной конторы над одним [под]проектом). Но вот дикая сложность мерджей угнетает, особенно, когда апстрим работает под версией <1.5.
Опять же, описанные ситуации довольно редкие и относятся больше к скриптовым, а не транслируемым в машинный код проектами. Так что, опять же специфика предмета проекта влияет на выбор «правильной» VCS/SCM.
Кстати, вроде бы в Mercurial с расширением forest, указанная проблема решается.
про теги имелось в виду — то, что при любой переписи истории, криптографические теги будут испорчены, поскольку они созданы для другого коммита/дерева.
2) получается, не всё, что может SVN. Он хорош именно проработанностью в смысле use cases (с учётом, что когда SVN проектировался, мерджи и DVCS-фичи редко какие проекты использовали). То, что исполнителю можно дать определённый небольшой участочек работы — это очень удобно.
Понятно, что с этими ограничениями борются планированием структуры проекта, но SVN удобен тем, что можно именно разрабатывать активно (впрочем, в других аспектах git рулит в этом отношении ещё больше).
А куда зеркалятся svn-ветки с апстрима?
И есть ли какая-то автоматизация коммита в svn (я правильно понял, что вы просто через отдельную WC коммиттите?)?
Ну и стиль использования «стабильный trunk» можно реализовать и в svn.
1) Файл/каталог B _внутри_ репозитория создан с помощью чего-то вроде svn copy на основе, соответственно, файла/каталога A. Есть ли способ из такого подпроекта B черрипикнуть изменения в подпроект A с помощью git? Как в таком случае (раздвоения части проекта на несколько) поступают git`овцы? Неужели сразу, как только забрезжит такая возможность, выкидывают кусок изменений в субмодули (та ещё нетривиальная задача, поскольку, как минимум, все теги в субмодуле исчезнут/станут кривыми)?
/* По мне, так неподдерживание git`ом равноправных вложенных деревьев — самый большой его недостаток. С другой, стороны, понятно, для чего так сделано: ясность и производительность. */
2) Как с помощью git работать над драйвером linux из дистрибутива ядра так, что бы не тащить к себе в раздел всё дерево исходников linux в качестве working copy?
А то я тут поработал с svk (работая с //local через рабочие копии svn клиента) и merge tracking — настолько всё было тяжело из-за того, что история мерджей в разных форматах и из-за того, что svk необратимо склеивает несколько разноплановых коммитов в один мердж-коммит. :(
А вот используя только git (есть опыт) всё так удобно и логично. Главное всегда помнить философию git — манипулирование не срезами деревьев в разные моменты (хотя эта фича тоже основная в git), а манипулирование патчами в контексте предыдущей истории проекта.
Кстати, эта статья не говорит ничего про поддержку радио (WiFi/Bluetooth/GPS/GSM) из линуксовского юзерспейса. Как там с ними?.. Там ведь блобы или как? И можно ли целиком прошивку (внутреннюю флешку) пересобрать?
Различия непринципиальны, если помнить всегда, что на выходе любых методов получается всегда такой же объект. А вот в случае операторов (во всяком случае, в перле), это не так. В перле обычно, в результате оператора, с одной из сторон которого стоит символьные строки, получаются символьные строки с неявным преобразованием байтовых в символьные.
$ uname -a
Linux WL700gE 2.4.20 #44 Sat Jan 26 20:07:26 EST 2008 mips unknown
Плюс в стандартной прошивке: uClibc, busybox. Плюс optware-порты под эту платформу. В общем, кривизна на кривизне, если говорить про архитектуру — содержимое / менять очень геморройно.
Кстати, проблем не так много, если рассматривать данные сущности, как полиморфные классы с похожим интерфейсом.
Asus — Asus 1.0.7.8-kc + optware oleg/cross
Если svn:externals, в основном, используются для удобства: «можно работать с библиотекой в этом подкаталоге», то git-submodules — для указания: «ребята, данный git-репозиторий работал с указанным коммитом из того репозитория, можете вытянуть себе».
Т.е. это похоже на svn:externals, но не то. Более аналогичным был бы подход nested trees, когда всё, необходимое для работы было бы сосредоточено в одном репозитории, с выбором нужного подрепозитория по путям (как в svn). Так вроде, собираются поступить в bazaar.
Ибо тогда, к примеру, возникает вопрос: а что делать по умолчанию с потоками, где встречаются utf-суррогаты и отсутствующие символы (например, дуализм unicode 0x0 и java 0x0). Это нетривиально, поэтому в Перле в конце концов (5.8.x) остановились на варианте максимальной совместимости со старым кодом (не придумывать ничего за программиста). Вставить же в начале программы прагмы (слои) потоков (PerlIO layers) — способен программист любого уровня (но с этим постоянные проблемы, т.к. люди просто не понимают разницу между семантикой данных и сериализацией этих данных).
P.S. Прежде чем делать стандартизованный ввод/вывод, надо хотя бы от последнего американского программиста добиться замены char * на unsigned char*, а ещё лучше — на безопасные unicode-контейнеры.
P.P.S. проверил на Asus wl700ge (optware) — там raw_input вообще не запрашивает ввод. ;-) А вы говорите, админа… Понятно, что в linux, freebsd (и macosx) всё нормально с локалями, но этими системами хосты не ограничиваются. Поэтому о стандартизации ввода/вывода можно будет говорить не ранее, как отрапортуют об успешном решении «проблемы 2038K» :)
x@y:~$ echo $LANG
ru_RU.UTF-8
x@y:~$ python
Python 2.5.2 (r252:60911, May 7 2008, 15:19:09)
>>> print raw_input( 'превед ' ).upper()
превед медвед
медвед
# ^-- python не телепат
>>> import locale
>>> print raw_input( 'превед ' ).decode(locale.getdefaultlocale()[1]).upper()
превед медвед
МЕДВЕД
# ^-- как надо было
Не трудно догадаться, что в такой сделает пользователь, которому нужно «по простому». Тоже самое сделал и я.
Это показывает, что вопрос производительности — это не только железо и криворукость писателей DirectX, но и странные организационно-архитектурные решения.
К примеру, несмотря на юникод, в какой-то из культур (то ли шведской, то ли норвежской) принятый порядок лексикографического сравнения латинских букв с диакритическими знаками отличается от общепринятого в остальных странах Европы и попытка лексикографической сортировки «по умолчанию» у таких пользователей пройдёт не так, как они хотят.
Интернационализация — слишком сложная вещь, что бы её можно было решить заменой литералов вида u'юникод' на 'юникод'…