Компания WANdisco, оплачивающая работу нескольких разработчиков Subversion и выпускающая на базе данной централизованной системы контроля версий несколько коммерческих продуктов, объявила (http://www.wandisco.com/php/pr.php?rss=0&prdate=2010-12-20) о решении реализовать собственными силами пожелания, наиболее часто высказываемые пользователями Subversion, такие как функций по быстрому слиянию и созданию веток.
Результат работы планируется интегрировать в основную ветку исходных текстов Subversion и довести их до готовности до выхода релиза Subversion 1.7, который намечен на 2011 год. Работа будет проведена (http://blogs.wandisco.com/2010/12/20/shaking-up-subversion-b.../) в тесном сотрудничестве с независимым сообществом разработчиков проекта Subversion, от которого будет зависеть конечное решение о включении созданных в WANdisco улучшений.
Некоторые из улучшений (http://www.wandisco.com/svndisco), которые намере...URL: http://www.wandisco.com/php/pr.php?rss=0&prdate=2010-12-20
Новость: http://www.opennet.me/opennews/art.shtml?num=29107
Что только люди не придумают чтобы не пользоваться GIT
что только не придумают любители молока, чтобы не пить кока-колу
>Что только люди не придумают чтобы не пользоваться GITПользовались, спасибо. На редкость неудобная фигня.
> Пользовались, спасибо. На редкость неудобная фигня.Это субъективное мнение. По мне так svn пора закопать и никогда больше не выкапывать.
Т.е. ваше мнение объективное, а у остальных субъективное? У Subversion есть своя ниша с которой его вряд ли выковырять распределенным системам.
>У Subversion есть своя ниша с которой его вряд ли выковырять распределенным системам.Потому что в этой нише он весьма удобен. Он создан для вполне определенной модели разработки. Для других моделей он в принципе не подходит (ни для кого не секрет, да?). Большинство распределенных систем, конечно, могут (кто больше, кто меньше) поддерживать аналогичную модель, но они РЕАЛЬНО сложней для неподготовленного (и не желающего становиться таковым!) пользователя, а таких пользователей весьма немало!
Основной плюс svn, это то, что он вытесняет cvs! Работать с svn после cvs - это просто праздник (вроде и аналогично все, но как-то стройнее и лучше вся система получается). Собственно, какой смысл сравнивать SVN и разные DVCS, если они принципиально разные и предназначены для разного?
Даже сравнивать основные DVCS между собой не имеет большого смысла (для задач общего назначения, как минимум), поскольку, в настоящее время, все заканчивается аргументами типа "нравится/не нравится", которые базируются на мнениях типа "2 года назад пробовал - не порадовало". Все что есть в одной уже давно есть в других, как минимум в виде плагинов или даже как штатные функции начиная с версии N. Например, даже bazaar, на сегодняшний день, умеет НЕ создавать отдельные директории для веток несмотря на основную свою парадигму (почему-то это до сих пор ставят ему как основной недостаток), да и git уже худо-бедно справляется с кириллицей и перемещениями файлов и папок (что непременно ставят в укор ему). Список можно продолжать очень долго...
> Основной плюс svn, это то, что он вытесняет cvs!Пробовал как пользователь использовать SVN для синхронизации исходников FreeBSD. Не понравилось то, что на диске каталог /usr/src занимал почти в три раза больше места, чем чистовой каталог, синхронизированный CVS. В чём преимущества SVN перед CVS для себя так и не уяснил.
А что скажет по этому поводу Калтенбруннер^Wрядовой разработчик FreeBSD? Сдается мне, что после парочки-тройки чекаутов/мержев/масштабных коммитов из CVS и SVN для себя он сделает далеко идущие выводы.
Где-то видел, ребята писали что наложили свой софт на порты FreeBSD. Но с SVN у них это не получалось, пришлось именно Subversion курить для этих целей. У них получился репозитарий портов в котором и порты FreeBSD и ихние порты. Они обновляют порты их репозитария FreeBSD и при этом там остаются ихние порты. Что-то в этом духе. Надо поискать, перечитать.
http://code.google.com/p/bsd-sharp/downloads/list
Там несколько методов заливки, но для портов используется portsnap
У CVS же не атомарные коммиты. Оборвалась связь во время коммита - получишь половину закомичено, половина - нет.
svn revert и svn diff не обращаются к серверу, в .svn лежат исходные файлы, поэтому и размер минимум в 2 раза больше.
> Это субъективное мнение.Недостатки git вполне объективны.
а ну ка. особенно в сравнении с svn.
>а ну ка. особенно в сравнении с svn.Нет докачки, неудобные номера ревизий, необходимость выкачивать всё дерево со всей историей, отсутствие официальной поддержки венды. Ещё?
*Нет докачки
Зачем? Или вы по gprs работаете?
*неудобные номера ревизий
Создание тегов никто не отменял.
*необходимость выкачивать всё дерево со всей историей
Это связано с тем, что это DVCS. К тому же это очень удобно, например можно сделать git blame:)
*отсутствие официальной поддержки венды
Под виндой работает.У git есть большой недостаток - он сложнее, чем svn, кривая обучения у git слишком крутая.
>У git есть большой недостаток - он сложнее, чем svn, кривая обучения у git слишком крутая.именно поэтому mercurial. те же яйца, только проще и адекватнее
> *неудобные номера ревизий
> Создание тегов никто не отменял.Для каждого комита делать тег? Вы в своём уме?
>Зачем? Или вы по gprs работаете?256-и мегабитный анлим. qt обновить невозможно, если недельку не делать git pull.
>Создание тегов никто не отменял.Для каждого коммита?
>Это связано с тем, что это DVCS. К тому же это очень удобно, например можно сделать git blame:)Ну понятно, кактус он такой вкусный.
>Под виндой работает.Ссылочку, пожалуйста.
>У git есть большой недостаток - он сложнее, чем svn, кривая обучения у git слишком крутая.На да, git для гениев с 16 мегабитным анлимом. Я знаю.
> 256-и мегабитный анлим. qt обновить невозможно, если недельку не делать git pull.вы его по http чтоли делаете? откройте для себя уже более другие протоколы.
> Для каждого коммита?
а что, каждый коммит кому то нужен кроме разработчика?
>Ну понятно, кактус он такой вкусный.
ну да, вы ж пользуетесь svn
>> 256-и мегабитный анлим. qt обновить невозможно, если недельку не делать git pull.
>вы его по http чтоли делаете? откройте для себя уже более другие протоколы.А что, для git:// уже написан мануал по прикручиванию всевозможных auth? На оффсайте? Ссылку же, срочно! Желательно не Basic, а, как минимум Digest-MD5, или подобное. А если http не годно, зачем прямо в дистрибе идет враппер для всяких апачей? "Мы умеем 100500 разных штук, но ни одну не умеем хорошо"? И да, даже по DAV оно получилось отвратным г-ном, но об этом я писал ниже - EGit не умеет ничего.
Какое отношение имеют твои комплексы к git? Мы уже поняли, что ты ретроград.
Человеческий мануал вместо "RTFSC" - уже ретроградство? Вы там со своим житом совсем уже с дуба рухнули?
git:// используется для анонимного доступа. Для "обновить qt" - в самый раз. Для auth есть git+ssh - всё есть и работает быстро. Если не хотите просаживаться на шифрование - выберите для ssh соответствующий легкий алгоритм шифрования (blowfish-cbc, например)
>вы его по http чтоли делаете? откройте для себя уже более другие протоколы.А что, другие протоколы добавляют в git поддержку докачки?
>а что, каждый коммит кому то нужен кроме разработчика?А что, разработчик должен обладать 16-и мегабитным без вариантов? А так я и тарбол по ftp скачаю. Нафиг мне гит?
>ну да, вы ж пользуетесь svnДа, после гита это просто сказка.
куча .svn директорий во всевозможных папках - да, это мечта >_<
видимо ты не умеешь его готовить.
Во-первых, можно не брать все дерево, а только нужную ветку, во-вторых, глубину историю тоже можно указать, в-третьих он уже давненько официально поддерживает винду.
> видимо ты не умеешь его готовить.
> Во-первых, можно не брать все дерево, а только нужную ветку, во-вторых, глубину
> историю тоже можно указать, в-третьих он уже давненько официально поддерживает винду.Я работаю по gprs, когда сделают докачку?
В распределенных системах контроля версий репозиторий хранится локально, поэтому инет нужен очень редко (только для скачивания и отправки новых changeset'ов, при этом коммитов можно сделать хоть сколько - для этого инет не нужен). Если вам кому-то нужно (не в центральный репозиторий) отпавить свои изменения, и при этом у вас плохая связь, то вы можете это сделать хоть по фтп, хоть через емайл, предварительно сформировав bundle с изменениями.
> В распределенных системах контроля версий репозиторий хранится локально, поэтому инет нужен очень редко (только для скачивания и отправки новых changeset'ов, при этом коммитов можно сделать хоть сколько - для этого инет не нужен).А как же распределённость? Вдруг там api поменяли, а я так и буду работать с устаревшим кодом?
>> Это субъективное мнение.
> Недостатки git вполне объективны.На git (такжк как и на svn) системы контроля версий не заканчиваются. Не подошел, по каким-то причинам, git, всегда можно попробовать что-то еще. Уж чего чего, а разных VCS в мире достаточно.
> На git (такжк как и на svn) системы контроля версий не заканчиваются.
> Не подошел, по каким-то причинам, git, всегда можно попробовать что-то еще.
> Уж чего чего, а разных VCS в мире достаточно.git не панацея. Если не нужна распределённость, то получается пшик на уровне cvs, если не хуже.
Да ладно сказки-то рассказывать. У нас git и так тоже используют -- средства для того самого быстрого мержа _несравнимы_ с cvs-ными. И при этом локально ветки разводить не в пример удобнее.SVN со своим подходом хорош в локалке индусских кодеров, где можно хоть голосом синхронизироваться -- кто что коммитит. Ну или с IRC в паре, и то уже больно начинает быть. Да, он подходит для workflow, когда "а больше ничего и не требуется" -- беда в том, когда workflow уже не масштабируется, а его всё пытаются растягивать (вместе с инструментом).
Да, git сложней и менее вылизан в плане въезда (и особенно переезда головой с CVS). Но это более осмысленное вложение времени для программиста (для кодера, пожалуй, нет): для локальной работы осваивается за четверть часа, а с распределённой довольно важно заметить git-remote(1) и не страдать ручными fetch'ами в локальные бранчи.
В любом случае хорошо, что инструментарий для централизованного воркфорва тоже пилят :)
git не поддерживает:1) svn cp: сохранение истории при разделении файлов: был file.c, стало one.c и two.c — для одного из новых файлов история правок будет идти лишь с момента разделения file.c на два файла.
2) svn import: git не позволяет импортировать кусок чужого проекта, не объявленный модулем, а svn — позволяет.
3) в git нет прозрачной нумерации коммитов; что полезно для очень крупных проектов, раздражает на небольших.
> git не поддерживает:
> 1) svn cp: сохранение истории при разделении файловgoogle://git+copy+history =>
http://markpasc.livejournal.com/186489.html?thread=556153#t5...> 2) svn import: git не позволяет импортировать кусок чужого проекта, не объявленный
> модулем, а svn — позволяет.Хм, а зачем? (и ещё: git умеет обрабатывать ситуацию, когда один из подкаталогов сам является git repo -- возможно, это бы выручило)
> 3) в git нет прозрачной нумерации коммитов; что полезно для очень крупных
> проектов, раздражает на небольших.Какая может быть честная нумерация при распределёнке -- сколько ни думал, так и не придумал. И заодно -- как с "прозрачной нумерацией", прибитой гвоздями, сделать что-нить вроде git rebase -i (ОСТОРОЖНО, оно острое!).
Тогда можно порекомендовать Mercurial. Он как git, только удобный (утрируя).
> Тогда можно порекомендовать Mercurial. Он как git, только удобный (утрируя).Звучит как начало холивара :)
git (на некоторых задачах, пока еще) быстрей, а bazaar (пока еще) удобней. Зачем mercurial?
> git (на некоторых задачах, пока еще) быстрейМне просто интересно, что это за задачи такие?
bazaar вообще не рассматривается по причине маргинальности, а git до yблюдочности усложнён, а базовых вещей не умеет. Где push в не-bare репозиторий? Где git cp? И так далее. Лучше hg еще ничего не придумали.
> а базовых вещей не умеет. Где push в не-bare репозиторий? ГдеКак Вы будете конфликты решать при push в рабочий каталог? По сети удалённо консоль Вам показывать? :)
> git cp?
git работает с diff'ами, а не с файлами. У этой модели есть как минусы, так и плюсы. Для меня - плюсов больше, cp не нужен.
Ок, готовый и полностью рабочий плагин для эклипса. Есть? По секрету: EGit - кривое поделие умеющее аж 2 фичи: показывать себя в списке плагинов, удалять себя из списка плагинов. Остальное у него не получается совсем.
Рабораю с ним больше года. В самом начале били каике-то чудеса, но очень давно всё в порядке. Так что реплика как раз из серии "видел пару лет назад - не порадовало". А вот поломанные рабочие копии при использовании Subversive видел не раз.
Видел как раз около месяца назад. Оно не пригодно к использованию при http-доступе. Так что твоя реплика из серии "мне не нужно => никому не нужно".
> Видел как раз около месяца назад. Оно не пригодно к использованию при
> http-доступе.(сочувственно) Что, заставляют? HTTP для git -- плохой транспорт, родной git или git+ssh работают куда веселей. Хотя раз реализовано -- то, конечно, стоило бы для обиженных доступом поддержать.
Ну так пусть Лунис Торвальц и напишет в главном man: this project is a compilation of the worst ideas in DVCS market. Those of them that were good are enforced to be bad by our design.
> Ну так пусть Лунис Торвальц и напишет в главном man:Давайте договоримся: я его об этом попрошу, когда удостоверюсь в Вашей личности и наличии в Вашем резюме фразы: "я неблагодарное лодырище, не только не осилил git, а полез плеваться на гораздо более компетентных в теме людей и вразумляться не собираюсь".
Критиковать -- можно и нужно, да только вот с головой, а не языком ляпать.
PS: хотя понятно, дальше egit Вам не дано и никакого конструктива Вы не ищете. Удачи.
А что, заставлять программеров пользоваться консолькой при каждом коммите/синхронизации/etc уже верх конструктива? Или есть всё же нормальные плагины к эклипсу? Если да, почему не гуглятся?
А впрочем, какая разница, что для гита (консольного) является плохим транспортом, когда на уровне гуя его никто не поддерживает толком:
http://code.google.com/p/egit/issues/detail?id=57И да: git+ssh требует наличия системного логина (как минимум pam должен знать о таком) для входа, что как ты понимаешь достойно места в списке киллер-фич жыта.
> Как Вы будете конфликты решать при push в рабочий каталог? По сети удалённо консоль Вам показывать? :)При push не возникает конфликтов, потому что рабочий каталог и репозиторий - разные вещи. У упоротых авторов гит видимо на всё своё мнение.
> git работает с diff'ами, а не с файлами. У этой модели есть как минусы, так и плюсы. Для меня - плюсов больше, cp не нужен.
Ну понятное дело, раз нету, значит не нужен.
>> Как Вы будете конфликты решать при push в рабочий каталог?
>> По сети удалённо консоль Вам показывать? :)
> При push не возникает конфликтов, потому что рабочий каталог и репозиторий -
> разные вещи.Вот только состояние верхушки той ветки репо (.git/), куда пушили, и чекаутнутой копии -- разъедется. Что делать предлагаете?
> У упоротых авторов гит видимо на всё своё мнение.
По-моему, Вы просто пытаетесь ставить на место тех, чьи задачи и близко решать не возьмётесь. Там выше про кодеров ещё писал.
Если не слабо -- вперёд, обрисуйте разумный алгоритм обработки non-bare repo push.
> Если не слабо -- вперёд, обрисуйте разумный алгоритм обработки non-bare repo push.Алгоритм абсолютно такой же как при наличии отдельного bare репозитория, только без него. Это же и идиоту очевидно, только у любителей git видимо совсем чуждая нормальному человеку логика.
>> Если не слабо -- вперёд, обрисуйте разумный алгоритм обработки non-bare repo push.
> Алгоритм абсолютно такой же как при наличии отдельного bare репозитория,
> только без него. Это же и идиоту очевидноЯсно, слабо. _Это_ действительно очевидно.
PS: какой-такой "отдельный bare repo", задумайтесь хоть... и откуда "такой же", когда вместо одной сущности вдруг появляется две, причём речь именно о поддержании их взаимной синхронизации при совершении push.
Ты как всегда в своем троллеламерском стиле.при нормальном дизайне VCS working copy не прибит гвоздями к репозиторию, т.е. схема которую предлагают адепты недоразвитого git'а (push 1>bare, pull bare>2, rebase@2) работает без необходимости сторонних репозиториев (push 1>2, rebase@2). Элементарно, казалось бы. Но нет, мы пойдем другим путём.
> Ты как всегда в своем троллеламерском стиле.С зеркалом закончите разговаривать, сообщите. :)
> при нормальном дизайне VCS working copy не прибит гвоздями к репозиторию,
Озвучьте критерии "нормального дизайна VCS", пожалуйста. Можно с примерами.
> т.е. схема которую предлагают адепты недоразвитого git'а (push 1>bare, pull bare>2,
> rebase@2) работает без необходимости сторонних репозиториев (push 1>2, rebase@2).*sigh*
"1" и "2" -- это репозитории (так понимаю) или ветки? Если первое, то какая проблема с fetch 2<1 или push в не-чекаутный бранч, если всё равно затем rebase?
Пока похоже, что у Вас проблемы с pull vs push, а не чем-либо ещё. И если так, то неудивительно.
PS: судя по слогу и уровню аргументации, это опять подросток из оракла.
>bazaar вообще не рассматривается по причине маргинальностиА вот это по-настоящему серьезный, сугубо технический и объективный аргумент! Надо бы этот параметр обязательно включать во все бенчмарки любых систем!
> А вот это по-настоящему серьезный, сугубо технический и объективный аргумент!Вообще-то это нормальный аргумент. Причём объединяет в себе как причины, так и следствия убогости базара. Был бы хорошей VCS - был бы распространён чуть шире чем нигде это следствие. А причина - зачем ставить левоту когда везде есть и уже используются git/hg?
Как минимум там адекватная система команд. Не сношающая мозг после перехода с CVS/SVN
Революционных изменений нет -- и это плохо.
Революционных изменений нет -- и это хорошо.Просто мелкие улучшения. А вот вкусные вещи (Shelve/Checkpoint, Repository-dictated Configuration) отложены до 1.8.
Да уж.. Адекватный merge - такая мелочь..
Эти ребятки даже опускались до тупого пиара в тематических конференциях -- пример: http://groups.google.com/group/git-users/browse_thread/threa...Так что закапывайте их вместе с Subversion.
хорошо что в Git/Mercurial/Bazaar -- есть слои совместимости с SVN ......ато ведь SVN-программисты будут до скончания века говорить что "svn самая удобная штука на свете, и альтернатив её нет"
бороться бесполезно :-)
>...ато ведь XXX-программисты будут до скончания века говорить что "xxx самая удобная штука на свете, и альтернатив её нет"вместо XXX подставляйте что угодно, хоть git, хоть mercurial, хоть bazaar...
доказательство см. выше - каждый хоть раз в жизни сделавший git pull считает прямо-таки своим долгом обгадить svn. При этом не задумываясь, что у vcs и dvcs достаточно разные задачи и масштабы, чтобы их объективно сравнивать.
не было еще птички, которая вылетела из гнезда не обгадив его.
> При этом не задумываясь, что у vcs и dvcs достаточно разные задачи и масштабы, чтобы их объективно сравнивать.просто долго было писать фразу "для целей -- совместной разработки программы" ..
думал что если уж написанно слово "программист" то и так ясно что реч идёт об программистской деятельности :-)
Вот сначала бы сделали, а потом бы хвастались!
> Вот сначала бы сделали, а потом бы хвастались!Вообще-то, это нормальная практика анонсировать то, что хочешь сделать. Чтобы потом толпы хомячков не слали разработчикам лучи добра и счастья.
Комменты доставляют. Сначала использовал svn, долго ненавидел git. Теперь же не понимаю, как можно использовать что-то ещё кроме git. И вот надо же, если бы я увидел это год назад, подумал что и правду git не стоит потраченных усилий. Как хорошо что год назад вас не было, дорогие анонимусы.
пользовался и svn, и git годами. второй годится разве что для kernel.org-подобных проектов, где все данные проходят через одного человека-тирана (он как раз и выполняет те функции централизации в DVCS, которые в централизованных VCS являются частью дизайна). для прозрачной слаженной командной работы svn подходит лучше
> пользовался и svn, и git годами. второй годится разве что для kernel.org-подобных
> проектов, где все данные проходят через одного человека-тирана (он как раз
> и выполняет те функции централизации в DVCS, которые в централизованных VCS
> являются частью дизайна). для прозрачной слаженной командной работы svn подходит лучшеНе так давно на глаза попадался более внятный разбор применимости -- с Вашим согласиться не могу, а там всё было толково разобрано. Вчера сходу не нашёл опять.
IMHO svn лучше подходит для слаженного кодирования разве что. И притом _требует_ слаженности, планирования и возможности оперативного взаимодействия при внесении изменений. Для кого-то такая внешняя дисциплина (как и питоний синтаксически значимый whitespace) -- нужна. А для кого-то это неразумная и контрпродуктивная помеха, потому что человек опытней тех, на кого ориентировано такое менторство инструмента.
Собсно не надо выдавать достоинства и недостатки _workflow_ за таковые _инструмента_.
я не кодер... просто занимаюсь поддержкой(в плане сборки тестовых пакетов для Linux-base)... и могу сказать что Git менее удобен чем SVN..
даже в плане таких простых операций, как удаленный запрос номера ревизии и скачивание конкретно заданной ревизии(не говоря уж о том что в Git и понятия такого внятного нет, какой-то паранойдальный хеш)
> я не кодер... просто занимаюсь поддержкойНу так и не судите инструмент _разработчика_. :) Я и пакеты собираю из гита, чем по большей части _уже_ доволен.
> даже в плане таких простых операций, как удаленный запрос номера ревизии
Поясните, какой ожидается результат запроса -- может, что соображу.
> и скачивание конкретно заданной ревизии
Если нужен снапшот -- обычно у проектов есть gitweb, а он даёт взять тарбол, соответствующий коммиту. (и историю там же может быть удобней глянуть краем глаза)
>(не говоря уж о том что в Git и понятия такого внятного нет,
>какой-то паранойдальный хеш)Ещё раз: он не "параноидальный", а отражает тот факт, что диффы и история изменений -- вещи необязательно связанные намертво.
Например, есть у меня foo.c и bar.h; правлю foo.c и делаю один коммит; правлю их оба (foo.c в другом месте, т.е. правки не пересекаются) и делаю второй коммит.
Внимание, вопрос: зачем какие-то искусственные ревизии, если может быть лучше (например, из соображений читабельности) перед публикацией эти коммиты поменять местами? Изменения те же, результат -- тот же, а вот порядок изменился. (пресловутый git rebase --interactive и такое позволяет делать)
Вообще рекомендую почитать при удобном случае вот эту статью: http://tomayko.com/writings/the-thing-about-git -- там разбирается как раз то, что git не вколачивает свой единственный правильный workflow в глотку пользователя ("и только мне попробуй шелохнуться!"), а предоставляет возможность наработать свой, удобный человеку.
Да, это сложнее, как и любое творчество сложнее хождения строем. И времени больше надо. Но это не недостаток инструмента -- а либо про него Вам наврали, что "простой" (он не простой), либо есть желание уж лучше ходить строем (что дело личное).
> ...а либо про него Вам наврали, что "простой" (он не простой), либо ..."простой для изучения" и "простой для использования" -- это немного разные понятия
инструмент зачастую бывает простой для использования -- но СЛОЖНЫЙ для изучения!!
----------
..наглядный пример: КАРАНДАШ!
карандошом легко писать слова (но это когда вы уже _научились_ правильно пользоваться карандошом)..
....но вспомните -- сколько требуется времени и усилий человеку чтобы овладеть навыком использования карандаша (для написания слов)!!! :-)
времени явно больше чем время что требуется на изучение Git :-) :-)
----------
и вот когда вы спрашиваете кого-то "<такой-то> инструмент -- он простой?" что вы ожидаете услышать? ответ на тему того что инстурмент простой для обучения? или что инструмент просто для повседневной работы?
>> ...а либо про него Вам наврали, что "простой" (он не простой), либо ...
> "простой для изучения" и "простой для использования" -- это немного разные понятияРазумеется. Я считаю, что git достаточно сложен в изучении и бывает сложен в применении, но результат того _для меня_ стоит. Но не для ламера, надо быть хотя бы честным чайником.
> и вот когда вы спрашиваете кого-то "<такой-то> инструмент -- он простой?"
Предпочитаю не задавать неоднозначных вопросов, чтоб не огорчаться ответами невпопад. :) Вы прекрасно озвучили проблему с наивным стилем вопрошания.
На дворе уже 2020, а svn всё ещё жив и процветает.