Comments 72
спасибо! подчерпнул для себя новое!
ветки в svn довольно унылы, потому что по сути являются просто каталогами по соседству. merge tracking в svn 1.5 кое-как исправляет ситуацию, но все равно с mercurial (могу говорить только за него, git не пробовал) не сравнить.
Но таки свои функции они выполняют. Кстати то что ветка является просто директорией это не недостаток а фишка SVN
Есть неприятный эффект, что приходится как-то искуственно запоминать, с какой ревизии в прошлый раз смерджились.
Быстро привыкаешь и потом проблем не вызывает.
Да понятно, всё равно осадок-то остаётся. Извечный спор "humane vs minimalism interfaces"
А почему-бы не отмечать в логах? Что бы не запоминать. Потом svn-log… и траляля
В 1.5 уже не приходится.
Я всегда в тексте комита пишу номер ревизии, весьма информативно и удобно.
UFO just landed and posted this here
Каждый раз в каждом топике про SVN найдётся какой нить умник и скажет что SVN дерьмо, а GIT это супер пупер. Вас что заставляют читать эти топики и писать унылые коменты?
я был бы рад если бы мне расказали о git в тот момент когда внедрялся svn
ну как бы эта ситуация должна наводить на размышления тогда.
svn довольно мила, но чтобы бранчить в ней и при этом иметь гораздо более удобную альтернативу, нужно иметь определенный склад характера.
п.с. а mergeinfo в file properties — это просто прелесть какое элегантное решение.
svn довольно мила, но чтобы бранчить в ней и при этом иметь гораздо более удобную альтернативу, нужно иметь определенный склад характера.
п.с. а mergeinfo в file properties — это просто прелесть какое элегантное решение.
В Mercurial одного не хватает — хорошего GUI под Windows. Имхо, популярность SVN связана не в последнюю очередь именно с TortoiseSVN.
TortoiseHg пока, увы, весьма неудобен и неповоротлив.
TortoiseHg пока, увы, весьма неудобен и неповоротлив.
ну не TortoiseHg единым… хотя и он, версии 0.5, очень даже ничего. меркуриал удобно использовать и из комстроки. hg commit, hg status, hg add и т.д. — not a rocket science, как говорится. также меркуриал отлично поддерживается в NetBeans, и неплохо — в KomodoIDE.
TortoiseHg показывает полный diff в логе, а если коммит очень большой — он практически подвисает… По удобству не сравнить с TortoiseMerge и TortoiseBlame (хотя ничто не мешает использовать их — может быть, это сделают в дальнейшем). Похоже, одной из проблем стало отсутствие C-библиотеки для работы с Mercurial.
Ну да, из комстроки можно, но привыкнув к TortoiseSVN, visual diff и прочим удобствам, переходить на командную строку не очень хочется.
Ну да, из комстроки можно, но привыкнув к TortoiseSVN, visual diff и прочим удобствам, переходить на командную строку не очень хочется.
Начиная с SVN 1.5 версии появились разнообразные приятности.
Мне кажется, рассказ о ветках в SVN'е неполон без их упоминания и описания.
Мне кажется, рассказ о ветках в SVN'е неполон без их упоминания и описания.
Я как то привык работать по старинке. Но это повод для знающих написать новую статью ;)
О, так вот же оно!
Так эта… того… так весь хабр можно одной ссылкой выразить. Хочется ж простого щастья — чтобы кто-нибудь прочитал, понял и разжевал.
Только что этим занимался )
Хорошая статейка. Талмут по ссылке обязательно читну.
В букмарки!
В букмарки!
Пишу по версии 1.5 статейку.
Спасибо! Почитал и понял что правильно сижу на SourceSafe :-)
О боже…
Зависть — плохое чувство.
Дело в том что я пользовался этой штукой года 4 назад. Геморой в памяти остался до сих пор. Как таковую командную разработку с этой системой вести нереально. Принцип общего владения кодом соблюдать невозможно. Но я не исключаю что за 4 года что-то сильно поменялось, так что если хотите доказать приемущества — ждем статью.
Вы не пользуетесь Visual Studio?
SourceSafe это практически единственное чем пользуются в большинстве своём все разработчики со времён ещё VS 6.0
SourceSafe это практически единственное чем пользуются в большинстве своём все разработчики со времён ещё VS 6.0
я не пользуюсь VS хотя бы по причине того что в качестве OS и дома и на работе у меня Linux
Но даже когда пользовался VSS писал я на Delphi
Но даже когда пользовался VSS писал я на Delphi
Ну тогда понятно. А мы с VS с 2000-го года и никаких неудобств при использовании SourceSafe не замечал, наоборот — уже в 2000м году мне в нём было удобно и понятно, всё интегрировано в среду разработки.
Не знаю за что я схлопотал минусов, видимо тоже от линуксоидов которые не пробовали.
Не знаю за что я схлопотал минусов, видимо тоже от линуксоидов которые не пробовали.
Может наоборот от тех кто пробовал? ;)
Дело то в том что у двух систем разная философия, и главное отличие в том что в VSS необходимо блокировать файлы над которыми ты сейчас работаешь. Это означает что никто другой их править не сможет. Это порождает множетсво неудобст, начиная от невозможности делать одну и ту-же задачу в команде, и заканчивая неудобствами связанными с необходимостью переговоров при внесении изменений в файл который держит другой человек. Он должен понять что ты собрался сделать, отпустить файл, подождать пока ты внесешь изменинея и отпустишь файл в свою очередь, потом опять залочить.
В SVN же ничего блокировать не надо, и можно не заботиться об этом. Каждый может менять любые файлы которые заблагорассудится. При этом это безопасно.
Дело то в том что у двух систем разная философия, и главное отличие в том что в VSS необходимо блокировать файлы над которыми ты сейчас работаешь. Это означает что никто другой их править не сможет. Это порождает множетсво неудобст, начиная от невозможности делать одну и ту-же задачу в команде, и заканчивая неудобствами связанными с необходимостью переговоров при внесении изменений в файл который держит другой человек. Он должен понять что ты собрался сделать, отпустить файл, подождать пока ты внесешь изменинея и отпустишь файл в свою очередь, потом опять залочить.
В SVN же ничего блокировать не надо, и можно не заботиться об этом. Каждый может менять любые файлы которые заблагорассудится. При этом это безопасно.
Не обязательно блокировать эксклюзивно, Всегда в настройках репозитория VSS можно указать опцию allow multiple checkouts.
Вообще, VStudio + VSourceSafe — это очень удобно в работе.
Но сам VSourceSafe плох только тем, что у него маолвато возможностей и иногда репозиторий разваливается.
SVN гораздо в этом плане надёжнее и приятнее, и к енму тоже можно докупить VS SCC-плагин для интеграции с VS.
Вообще, VStudio + VSourceSafe — это очень удобно в работе.
Но сам VSourceSafe плох только тем, что у него маолвато возможностей и иногда репозиторий разваливается.
SVN гораздо в этом плане надёжнее и приятнее, и к енму тоже можно докупить VS SCC-плагин для интеграции с VS.
Я пользуюсь Visual Studio уже 7 лет. VSS трогал последний раз к своему превеликому счастью 4 года назад. До сих пор содрогаюсь впоминая это поделие.
А как вы работаетет то я тогда не понял? Через проводник — бегаете по каталогам, Commit Update жмёте?
Для нас это неприемлимо — у нас 3000 файлов в проекте
Для нас это неприемлимо — у нас 3000 файлов в проекте
Удивительно, да, но с учетом того что я работаю в idea, в котором есть замечательный плагин для работы с svn, GUI и все дела, пользуюсь я исключительно командной строкой. Скажете я извращенец, но я так привык. А файлов в проекте не многим меньше.
Притом что в случае с SVN количество файлов вообще неважно. Это в VSS надо бегать по каталогам и файлы лочить/разлочивать по одному. В SVN очень редко необходимо комитить 1 файл. Обычно ниже корня спускаться не приходится.
Так что в случае если у вас в проекте 3000 файлов, вам тем более пора отказаться от VSS.
Притом что в случае с SVN количество файлов вообще неважно. Это в VSS надо бегать по каталогам и файлы лочить/разлочивать по одному. В SVN очень редко необходимо комитить 1 файл. Обычно ниже корня спускаться не приходится.
Так что в случае если у вас в проекте 3000 файлов, вам тем более пора отказаться от VSS.
И стоит обратить наверное внимание на этот коммент)))
habrahabr.ru/blogs/development_tools/45203/#comment_1143897
P.S. Эх, вдруг удастся спасти заблудшую душу)))
habrahabr.ru/blogs/development_tools/45203/#comment_1143897
P.S. Эх, вдруг удастся спасти заблудшую душу)))
Не всё ли равно, сколько файлов в проекте? Commit, Update, Check for modifications делаются для корневого каталога и всё.
Да, поддержка SCM на уровне студии приятная штука конечно, но практика показывает, что это не более, чем приятная штука, и не может быть решающим критерием при выборе системы.
Да, поддержка SCM на уровне студии приятная штука конечно, но практика показывает, что это не более, чем приятная штука, и не может быть решающим критерием при выборе системы.
VisualSVN — плагин к Visual Studio, полностью интегрирует TortoiseSVN в оболочку Visual Studio. Но при этом есть возможность выполнять все действия и из проводника/командной строки.
А о слабости SourceSafe как системы управления версиями говорит хотя бы отсутствие транзакционного коммита.
А о слабости SourceSafe как системы управления версиями говорит хотя бы отсутствие транзакционного коммита.
Если вы переодически мёржитесь с транка, то для реинтеграции ветки в транк нельзя копировать изменения в своей ветке, т. к. они включают в себя мёржи с транка. Вместо этого нужно наложить на транк разницу между транком и веткой, как советуют в документации.
Мир не стоит на месте, развивайтесь, попробуйте Git.
А зачем ещё писать о SVN O_o :D
Было бы неплохо если бы каждый кто тут продвигает свою систему расказал бы о ней. А так, языком трепать конечно легко. Докажите статьей чем ваша система лучше SVN. Между прочим очень хотел бы послушать про VSS. Юзал её 4 года назад, после неё SVN это сказка. Но вдруг за это время многое изменилось. Хотя у VSS совсем другая концепция изначально худшая и устаревшая. Но вдруг…
Чем запоминать ревизии, или смотреть по логам, имхо гораздо проще делать 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
ненужные бранчи предпочитаю сносить в архив, но можно и удалять
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
ненужные бранчи предпочитаю сносить в архив, но можно и удалять
Было бы неплохо если бы каждый кто тут продвигает свою систему расказал бы о ней. А так, языком трепать конечно легко. Докажите статьей чем ваша система лучше SVN. Между прочим очень хотел бы послушать про VSS. Юзал её 4 года назад, после неё SVN это сказка. Но вдруг за это время многое изменилось. Хотя у VSS совсем другая концепция изначально худшая и устаревшая. Но вдруг…
Вчера попытался «смержить» в ветку изменения из основного дерева, не получилось — выдал ошибку «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 — всё заработало. :)
Суббота началась с чтения SVN Book (http://svnbook.red-bean.com/nightly/ru/svn.branchmerge.whatis.html), благо русская версия там есть (не то, чтобы я английский не знал, но решил, что что-то не понимаю).
Спустя пару часов понял, что ещё вчера верно уловил суть. Задумался о версии Tortoise SVN (у меня она 1.5.0), обновил до 1.5.5 — всё заработало. :)
UFO just landed and posted this here
Самое интересное что у меня на работе, клиент (обычный из командной строки, так привык) 1.5.1 но сервер версии 1.4 и они прекрасно работают вместе, только новые фичи не поддерживаются.
А как понять, работает ли merge tracking или нет? TortoiseSVN по-прежнему не показывает слияние веток на графике…
Как это сделать с помощью TortoiseSVN не знаю, не пользуюсь им года два. Из командной строки проверить можно просто выполнив svn merge svn://rvk1.firstvds.ru/trunk --dry-run и посмотреть какие ревизии svn будет копировать
А проще всего узнать версию сервера, например у админа ;) Если 1.5.х то поддерживает
А проще всего узнать версию сервера, например у админа ;) Если 1.5.х то поддерживает
Для интеграции со студией можно попробовать вот это ankhsvn.open.collab.net/, чтобы все работало нормально на машине должен стоять TortoiseSVN. Сервер под винды visualsvn.com/. У меня это нормально работает вместе.
Как обещал написал продолжение
habrahabr.ru/blogs/development_tools/45222/
habrahabr.ru/blogs/development_tools/45222/
UFO just landed and posted this here
Sign up to leave a comment.
Работа с ветками SVN