ltwood: (Default)
На страничке http://hgbook.red-bean.com/read/how-did-we-get-here.html есть такой абзац:

Prior to version 1.5, Subversion had no useful support for merges. At the time of writing, its merge tracking capability is new, and known to be complicated and buggy.

А к этому абзацу есть вот такие вот комментарии:

Ben Collins-Sussman 2009-09-08
fuck you bastard

fulatoro 2009-09-16
FYI this is not a disinterested commenter, as a matter of fact he is one of the original developers of SVN...

helloworld 2009-10-06
It's easy to write someone else's name...

Ben Collins-Sussman 2009-12-02
Ha, love the fact that people are impersonating me now. :-)

I actually wrote the section of the svnbook which the 'complicated and buggy' link points to, and I totally agree with the phrase. I'm a dedicated mercurial user these days.


Во втором случае Ben Collins-Sussman вроде бы настоящий.
ltwood: (Default)
Внезапно обнаружил, что некто Bram Cohen [livejournal.com profile] bramcohen придумал, как вылечить основную болезнь классического алгоритма diff -- его склонность генерировать оптимальные, но загадочные diff'ы. Идея проста до гениальности -- игнорировать при сравнении строки, имеющие дубликаты в одном из сравниваемых файлов.

Авторское описание алгоритма: http://bramcohen.livejournal.com/73318.html, http://alfedenzo.livejournal.com/170301.html, http://git.661346.n2.nabble.com/Bram-Cohen-speaks-up-about-patience-diff-td2277041.html

Алгоритм называется Patience Diff и уже реализован в Bazaar и Git. Standalone реализации я не нашел. В Mercurial обсуждают включение, а в Subversion мы его наверно никогда не дождемся.
ltwood: (Default)
Недавно в реальном проекте вляпался в относительно свежий баг svn.

Формальное описание:
added subtrees with mergeinfo break reintegrate, Issue #3654,
см. http://subversion.tigris.org/issues/show_bug.cgi?id=3654
Исправлено в версии 1.6.12 (Revision 955369)
см. http://svn.apache.org/viewvc?view=revision&revision=955369

Если кто-то использует reintegrate merge, то очень рекомендую обновиться (достаточно обновить клиента).

У меня проявилось в ситуации, когда из-за старых бранчей, выполненных на поддиректории (не на корне), некая поддиректория получила свой собственный mergeinfo. Если поддиректория имеет свой mergeinfo, то она не наследует mergeinfo родителя и в нее клиент должен ручками прописывать mergeinfo из родителя, чего он не делал. В результате reintegrate на директории-родителе не работал, поскольку при мерже транка в бранч (перед reintegrate) в свойства этой поддиректории не прописывалась запись mergeinfo из trunk.
ltwood: (Default)
В очередной раз потратил кучу времени на поиски причин того, что в SVN после выполнения операции reintegrate бранча в транк требуется удалять бранч. Даже если в бранче будет продолжена работа, его придется удалить и создать заново.

Ответ содержится по ссылке [http://blogs.open.collab.net/svn/2008/07/subversion-merg.html].

Коротко:

При выполнении операции reintegrate производится сравнение бранча и транка без учета того, что они имеют общего предка. Причина состоит в том, что в бранче при его регулярной синхронизации с транком могли возникать конфликты, которые разрешались вручную. После reintegrate транк выглядит так, как будто в него за один коммит были внесены все те изменения, которые были сделаны в бранче за время его жизни. Если после этого попытаться снова синхронизировать бранч с транком, то первой же версией, которая попытается помержиться в бранч, будет как раз та версия, в которой сделаны изменения, извлеченные из бранча при выполнении reintegrate. Эти изменения фактически в бранче присутствуют (они из него и были взяты), но соответствующей записи в свойстве mergeinfo нет. В результате появятся множественные конфликты.

Непонятка:

Вроде бы для исправления ситуации достаточно пометить как игнорируемую ту версию, в которой были закоммичены в транк изменения, полученные при выполнении reintegrate. Ясно также, почему SVN сам не делает этого — по его идеологии слияние (merge) всегда производится в рабочей копии (что правильно из-за вероятности конфликтов) и коммитится независимо. При этом в момент коммита в транк SVN уже не может как бы то ни было менять бранч.
ltwood: (Default)
Искал стенограмму доклада «Linus Torvalds on git» и наткнулся на перевод «Линус Торвальдс о GIT на Google Talks» [http://lib.custis.ru/index.php/Линус_Торвальдс_о_GIT_на_Google_Talks], вполне приличный.

Одновременно нашлась неплохая подборка переводов статей об SVN — статей идеологических, а не советов по использованию [http://lib.custis.ru/index.php/Категория:Статьи_о_Subversion]. Еще интересно сообщение «Subversion, decentralized version control, and the future» [http://svn.haxx.se/dev/archive-2007-06/0780.shtml] (ссылка на него есть в одной из статей).

Оценка доклада Линуса как «dust from Linus Torvald's GIT talk» всегда казалась мне вполне-вполне адекватной (или даже слишком мягкой).

SVN

2009-02-11 16:58
ltwood: (Default)
Прочитал описание проблем, которые решает (и создает) опция --reintegrate команды merge в SVN 1.5+ (http://blogs.open.collab.net/svn/2008/07/subversion-merg.html). В целом интерес мой был во многом теоретическим, поскольку мы тут пользуемся платным SVN-сервером (2x.ru), на котором стоит версия 1.4.4. Показалось, что проблемы с Cyclic Merges в SVN немного напоминают проблемы с Attic в CVS — вряд ли они будут приемлемо решены в рамках текущей модели репозитория. Текущее решение (reintegrate), попутно приводящее к проблемам с svn move и требованию удалять branch после каждого reintegrate, кажется костылями (как и Attic в CVS).

P.S. К желающим покричать «все срочно переходите на Git!» есть маленькая просьба: не полениться прочитать описание проблемы и рассказать, как она решена в волшебном Git.

Upd: Описание опции reintegrate см. здесь: http://subversion.tigris.org/svn_1.5_releasenotes.html

Profile

ltwood: (Default)
ltwood

January 2017

S M T W T F S
1234567
891011121314
15161718192021
22232425262728
293031    

Syndicate

RSS Atom

Expand Cut Tags

No cut tags
Page generated 2017-09-25 04:34
Powered by Dreamwidth Studios