Работа с ветками SVN

[imbeat]

спасибо! подчерпнул для себя новое!

[RVK]

Пожалуйста)))

[evilbloodydemon]

ветки в svn довольно унылы, потому что по сути являются просто каталогами по соседству. merge tracking в svn 1.5 кое-как исправляет ситуацию, но все равно с mercurial (могу говорить только за него, git не пробовал) не сравнить.

[RVK]

Но таки свои функции они выполняют. Кстати то что ветка является просто директорией это не недостаток а фишка SVN

[aberezh]

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

[RVK]

Быстро привыкаешь и потом проблем не вызывает.

[aberezh]

Да понятно, всё равно осадок-то остаётся. Извечный спор "humane vs minimalism interfaces"

[kai]

А почему-бы не отмечать в логах? Что бы не запоминать. Потом svn-log… и траляля

[xflower]

Перед занесением в лог надо ещё разрулить конфликты (которых в большом проекте может быть на пару дней), посидеть в интернете, выпить кофе, поддержать пользователей, проинтервьюировать очередного кандидата — тут, глядишь, и заново merge делать пора.

[RVK]

Похоже статья не прочитана. В ней об этом есть

[Paul]

В 1.5 уже не приходится.

[brook]

Я всегда в тексте комита пишу номер ревизии, весьма информативно и удобно.

[RVK]

И это верно

[Vomitus]

А какой в этом глубокий смысл? Везде, где встречается такая сущность, как конкретная ревизия, мы можем лицезреть ее номер. Или я не прав?

[brook]

До 1.5 нет точно, в логох у вас будет просто диф файлов, обычный апдейт, команда svn merge никак не залогирует номер ревизии.

[brook]

Каждый раз в каждом топике про SVN найдётся какой нить умник и скажет что SVN дерьмо, а GIT это супер пупер. Вас что заставляют читать эти топики и писать унылые коменты?

[maxcom]

я был бы рад если бы мне расказали о git в тот момент когда внедрялся svn

[evilbloodydemon]

ну как бы эта ситуация должна наводить на размышления тогда.

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

п.с. а mergeinfo в file properties — это просто прелесть какое элегантное решение.

[brook]

Отнюдь, вы думаете если каждый человек будет так просто отписывать разные мелкие коменты из трёх строк желающих прибавиться? Сомневаюсь, надо доносить своё мнение более аргументированно.

[virusman]

В Mercurial одного не хватает — хорошего GUI под Windows. Имхо, популярность SVN связана не в последнюю очередь именно с TortoiseSVN.
TortoiseHg пока, увы, весьма неудобен и неповоротлив.

[evilbloodydemon]

ну не TortoiseHg единым… хотя и он, версии 0.5, очень даже ничего. меркуриал удобно использовать и из комстроки. hg commit, hg status, hg add и т.д. — not a rocket science, как говорится. также меркуриал отлично поддерживается в NetBeans, и неплохо — в KomodoIDE.

[virusman]

TortoiseHg показывает полный diff в логе, а если коммит очень большой — он практически подвисает… По удобству не сравнить с TortoiseMerge и TortoiseBlame (хотя ничто не мешает использовать их — может быть, это сделают в дальнейшем). Похоже, одной из проблем стало отсутствие C-библиотеки для работы с Mercurial.
Ну да, из комстроки можно, но привыкнув к TortoiseSVN, visual diff и прочим удобствам, переходить на командную строку не очень хочется.

[xflower]

Начиная с SVN 1.5 версии появились разнообразные приятности.
Мне кажется, рассказ о ветках в SVN'е неполон без их упоминания и описания.

[RVK]

Я как то привык работать по старинке. Но это повод для знающих написать новую статью ;)

[aberezh]

О, так вот же оно!

[xflower]

Так эта… того… так весь хабр можно одной ссылкой выразить. Хочется ж простого щастья — чтобы кто-нибудь прочитал, понял и разжевал.

[aberezh]

Не, это я не в том смысле, что «юзай гугл уже», а я тоже не знал :)

[djsv]

Только что этим занимался )

[fobos]

Хорошая статейка. Талмут по ссылке обязательно читну.
В букмарки!

[RVK]

Пишу по версии 1.5 статейку.

[Sapercheg]

Спасибо! Почитал и понял что правильно сижу на SourceSafe :-)

[RVK]

О боже…

[Sapercheg]

Зависть — плохое чувство.

[RVK]

Дело в том что я пользовался этой штукой года 4 назад. Геморой в памяти остался до сих пор. Как таковую командную разработку с этой системой вести нереально. Принцип общего владения кодом соблюдать невозможно. Но я не исключаю что за 4 года что-то сильно поменялось, так что если хотите доказать приемущества — ждем статью.

[Sapercheg]

Вы не пользуетесь Visual Studio?

SourceSafe это практически единственное чем пользуются в большинстве своём все разработчики со времён ещё VS 6.0

[RVK]

я не пользуюсь VS хотя бы по причине того что в качестве OS и дома и на работе у меня Linux

Но даже когда пользовался VSS писал я на Delphi

[Sapercheg]

Ну тогда понятно. А мы с VS с 2000-го года и никаких неудобств при использовании SourceSafe не замечал, наоборот — уже в 2000м году мне в нём было удобно и понятно, всё интегрировано в среду разработки.

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

[RVK]

Может наоборот от тех кто пробовал? ;)
Дело то в том что у двух систем разная философия, и главное отличие в том что в VSS необходимо блокировать файлы над которыми ты сейчас работаешь. Это означает что никто другой их править не сможет. Это порождает множетсво неудобст, начиная от невозможности делать одну и ту-же задачу в команде, и заканчивая неудобствами связанными с необходимостью переговоров при внесении изменений в файл который держит другой человек. Он должен понять что ты собрался сделать, отпустить файл, подождать пока ты внесешь изменинея и отпустишь файл в свою очередь, потом опять залочить.
В SVN же ничего блокировать не надо, и можно не заботиться об этом. Каждый может менять любые файлы которые заблагорассудится. При этом это безопасно.

[akzhan]

Не обязательно блокировать эксклюзивно, Всегда в настройках репозитория VSS можно указать опцию allow multiple checkouts.

Вообще, VStudio + VSourceSafe — это очень удобно в работе.

Но сам VSourceSafe плох только тем, что у него маолвато возможностей и иногда репозиторий разваливается.

SVN гораздо в этом плане надёжнее и приятнее, и к енму тоже можно докупить VS SCC-плагин для интеграции с VS.

[Paul]

Я пользуюсь Visual Studio уже 7 лет. VSS трогал последний раз к своему превеликому счастью 4 года назад. До сих пор содрогаюсь впоминая это поделие.

[Sapercheg]

А как вы работаетет то я тогда не понял? Через проводник — бегаете по каталогам, Commit Update жмёте?

Для нас это неприемлимо — у нас 3000 файлов в проекте

[RVK]

Удивительно, да, но с учетом того что я работаю в idea, в котором есть замечательный плагин для работы с svn, GUI и все дела, пользуюсь я исключительно командной строкой. Скажете я извращенец, но я так привык. А файлов в проекте не многим меньше.
Притом что в случае с SVN количество файлов вообще неважно. Это в VSS надо бегать по каталогам и файлы лочить/разлочивать по одному. В SVN очень редко необходимо комитить 1 файл. Обычно ниже корня спускаться не приходится.

Так что в случае если у вас в проекте 3000 файлов, вам тем более пора отказаться от VSS.

[RVK]

И стоит обратить наверное внимание на этот коммент)))
habrahabr.ru/blogs/development_tools/45203/#comment_1143897

P.S. Эх, вдруг удастся спасти заблудшую душу)))

[Sapercheg]

Не удастся, у нас это корпоративный стандарт. :-)

А почтовый клиент у нас MS Outlook :-) И там всё-всё-всё, от контактов до календаря и планировщика заданий.

[RVK]

Зря расcказал… теперь в кошмарах сниться будет…
Компания не МВ случайно?

[Sapercheg]

Нет :-) Обычный такой разработчик небольшой российской ERP системы с двумя десятками программистов.

[RVK]

Вот вот. Там я тоже ERP разрабатывал)))

[Paul]

Не всё ли равно, сколько файлов в проекте? Commit, Update, Check for modifications делаются для корневого каталога и всё.

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

[almazik]

VisualSVN — плагин к Visual Studio, полностью интегрирует TortoiseSVN в оболочку Visual Studio. Но при этом есть возможность выполнять все действия и из проводника/командной строки.

А о слабости SourceSafe как системы управления версиями говорит хотя бы отсутствие транзакционного коммита.

[Sapercheg]

Да.

[razetdinov]

Если вы переодически мёржитесь с транка, то для реинтеграции ветки в транк нельзя копировать изменения в своей ветке, т. к. они включают в себя мёржи с транка. Вместо этого нужно наложить на транк разницу между транком и веткой, как советуют в документации.

[SkyEagle]

Мир не стоит на месте, развивайтесь, попробуйте Git.

[Iskin]

А зачем ещё писать о SVN O_o :D

[RVK]

Было бы неплохо если бы каждый кто тут продвигает свою систему расказал бы о ней. А так, языком трепать конечно легко. Докажите статьей чем ваша система лучше SVN. Между прочим очень хотел бы послушать про VSS. Юзал её 4 года назад, после неё SVN это сказка. Но вдруг за это время многое изменилось. Хотя у VSS совсем другая концепция изначально худшая и устаревшая. Но вдруг…

[RVK]

сори этот ответ нетуда)))

[evilkost]

Чем запоминать ревизии, или смотреть по логам, имхо гораздо проще делать 2 копии:
svn cp trunk branch--base
svn cp branch--base branch
svn co branch
работаем в бранче

легко посмотреть внесенные самим изминения
svn diff branch{--base,}

если сливаться с транком:
svn co trunk trunk--to--merge
svn merge branch{--base,} trunk--to--merge // лучше посмотреть насколько удачно слилось
svn ci

если хотим изминения из транка, то создадим еще пару бранчей и перенесем изминения из текущего
svn cp trunk branch2--base
svn cp branch2--base branch2
svn co branch2
svn merge branch{--base,} branch2
работаем дальше в branch2

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

[RVK]

ужас… не проще ли просто один коммент в логе?

[evilkost]

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

[RVK]

Было бы неплохо если бы каждый кто тут продвигает свою систему расказал бы о ней. А так, языком трепать конечно легко. Докажите статьей чем ваша система лучше SVN. Между прочим очень хотел бы послушать про VSS. Юзал её 4 года назад, после неё SVN это сказка. Но вдруг за это время многое изменилось. Хотя у VSS совсем другая концепция изначально худшая и устаревшая. Но вдруг…

[razetdinov]

Сначала исправьте логическую ошибку, о которой я писал выше, дабы не вводить читателей в заблуждение.

[RVK]

Ага, ошибся)))

[xeningem]

Вчера попытался «смержить» в ветку изменения из основного дерева, не получилось — выдал ошибку «Malformed URL for repository». Всё проклял. Решил, что руки растут не из того места.
Суббота началась с чтения SVN Book (http://svnbook.red-bean.com/nightly/ru/svn.branchmerge.whatis.html), благо русская версия там есть (не то, чтобы я английский не знал, но решил, что что-то не понимаю).
Спустя пару часов понял, что ещё вчера верно уловил суть. Задумался о версии Tortoise SVN (у меня она 1.5.0), обновил до 1.5.5 — всё заработало. :)

[RVK]

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

[virusman]

А как понять, работает ли merge tracking или нет? TortoiseSVN по-прежнему не показывает слияние веток на графике…

[RVK]

Как это сделать с помощью TortoiseSVN не знаю, не пользуюсь им года два. Из командной строки проверить можно просто выполнив svn merge svn://rvk1.firstvds.ru/trunk --dry-run и посмотреть какие ревизии svn будет копировать

А проще всего узнать версию сервера, например у админа ;) Если 1.5.х то поддерживает

[Jaggy]

Для интеграции со студией можно попробовать вот это ankhsvn.open.collab.net/, чтобы все работало нормально на машине должен стоять TortoiseSVN. Сервер под винды visualsvn.com/. У меня это нормально работает вместе.

[akzhan]

сервер — обычный SVN.

Клиентская часть:
www.pushok.com/soft_svn.php

[RVK]

Как обещал написал продолжение
habrahabr.ru/blogs/development_tools/45222/