lubu-lord · 22-Ноя-08 10:36(16 лет 7 месяцев назад, ред. 04-Фев-09 14:30)
Управление версиями в Subversion Год выпуска: 2007 Автор: Бен Коллинз-Сассман, Брайан У. Фитцпатрик, К. Майкл Пилато Жанр: обучение Формат: PDF Качество: eBook (изначально компьютерное) Количество страниц: 342 Описание: Доступный в online перевод учебника по свободной системе управления версиями Subversion (SVN), собранный в формате chm.
Книга практическая и неплохая, представляет собой развитие Subversion FAQ.
"Subversion представляет собой относительно молодую систему управления версиями, призванную прийти на смену CVS. Её разработчики стремятся завоевать сердца пользователей CVS сразу с двух сторон: во-первых, Subversion создаётся как система с открытым исходным кодом, которая по своему устройству и ощущениям от работы напоминает CVS, а во-вторых, она пытается исправить наиболее очевидные недостатки CVS. И хотя то, что получается в результате, не обязательно является новым витком в развитии технологий управления версиями, Subversion на самом деле очень мощное, удобное и гибкое средство." Не откажусь от плюсика в репутацию))
Да, это было скачано раньше по этой ссылке. Но сейчас по ссылке уже обновленная версия (Для Subversion 1.4 (Соответствует редакции 3603)). Раздача устарела
"Subversion представляет собой относительно молодую систему управления версиями" На данный момет Subversion - устаревающая система. (из пяти последних проектов у меня только на одном использовалась Subversion, и на двух Mercurial)
Сейчас всё чаще используются Distributed Version Control System (DVCS), например такие как Mercurial и Git, преимущество которых в том, что можно себе локально сохранять какие то резултаты своей работы, без необходимости иметь связь с "условно-центральным сервером"
50697270"Subversion представляет собой относительно молодую систему управления версиями" На данный момет Subversion - устаревающая система. (из пяти последних проектов у меня только на одном использовалась Subversion, и на двух Mercurial)
Сейчас всё чаще используются Distributed Version Control System (DVCS), например такие как Mercurial и Git, преимущество которых в том, что можно себе локально сохранять какие то резултаты своей работы, без необходимости иметь связь с "условно-центральным сервером"
А что мешает в SVN сделать локальный репозиторий? и сохранять результаты своей работы...
Например отсутствие нормальной синхронизации между локальным и удаленным. Можно конечно нагородить кучу костылей и подпорок, но зачем когда есть git, hg, fossil. Если проводить аналогии, то вы пытаетесь владельцам современных винтовок рассказать про то, что из аркебузы тоже можно стрелять. Можно, но зачем?
nuyakeangramania
она не устаревающая, а очень хорошая и проверенная временем централизованная система. для корпоративных решений - самое оно. заказчик, который дорожит своей кодовой базой, вряд ли просто так станет предоставлять историю всех изменений посредством меркуриала или гита. в вашем распоряжении есть "svnadmin create". без проблем можно сделать чекаут репозитория, используя псевдосхему file:/// в урлах, если что, и если уж так хочется делать зеркала в стиле master/slave -- есть svnsync * клонирование в гите не всегда получается сделать при наличии плохого соединения. даже если прервать процесс клонирования вручную -- гит считает, что вообще ничего не клонировалось. оборвалась связь -- капец клонированию
* в svn проще контроллировать доступ тех или других членов к тем или иным веткам репозитория, причём далеко не только на уровне транк-тег-бренч
* ни в git, ни в hg невозможно хранить пустые директории. а это бывает очень даже кстати
* честно говоря, не нашёл пока аналога svn-свойств. файлы типа .hgignore вызывают улыбку (кстати, почему он не находится в .hg? -- то же самое касается .hgtags)
* не уверен что нет в hg/git, но в svn без проблем можно сделать чекаут части ветки с любого уровня вложенности, и по любой уровень. кстати, как там дела с svn:external?
* svn:lock есть?
* ... отсюда: http://programmers.stackexchange.com/questions/111633/what-does-svn-do-better-than-git
При желании у аркебузы тоже можно найти преимущества перед современной винтовкой. Например ее можно чинить и даже с нуля сделать при помощи молотка и такой-то матери. И патроны под нее не нужно делать, силу заряда можно варьировать для каждого выстрела, выстрелить можно хоть камнем. Ах, да, временем арекбуза тоже была проверена. Вот только почему-то аркебузами при наличии винтовок никто в здравом уме не хочет пользоваться.
Аналогично с svn и git/hg, новые проекты создаются сразу на какой-нибудь из dvcs, старые тоже потихоньку на них переезжают, кто раньше, кто позже, но движение идет в один конец, с git на svn может перейти только очень альтернативно одаренный человек. Не буду говорить за hg, но git хорош в том числе и тем, что позволяет создать любую схему работы(workflow), в том числе и аналог центрального репозитория svn, но при этом не мешает каждому разработчику делать локальные операции так, как удобно лично ему, а не следовать хотелкам боссов.
Никакого печального опыта, вполне успешно использовал svn раньше, но потом появились git и fossil и смысл использования svn пропал начисто. Речь не о том, что svn был плох для своего времени, возможно, он вообще был лучшим из открытых vcs. Вот только прогресс не стоит на месте, vcs это прошлое, dvcs рулят просто по определению.
на работе имею дело с git, для домашнего использования всё же выбрал hg. должен признать, что удобства просто море, включая простую репликацию данных (хоть это и абюз vcs). всё же, от некоторых приведённых мною выше свойств svn можно отказаться из-за удобства работы, но некоторые вещи всё же оставляют осадок. систему команд в git придумал и документацию писал сумасшедший -- без гугла и памяти по-быстрому ну просто не разобраться, и всё тут. а в hg -- нет stage index, что иногда чревато коммитами с последующими амендами; брезгует временем создания и изменения файлов + ещё пару неудобств (например, наличие encode/decode фильтров генерирует странный hg status). и да, .hgignore (про .gitignore не знаю) автоматически, по крайней мере из коробки, не понимает, когда игнорируемый материал "шастает" по рабочей копии с места на место. ну это такое, у svn дефектов вообще вагон был. так что пока вполне доволен hg
и ещё раз отпишусь спустя почти год. к превеликому сожалению, на текущем проекте снова столкнулся с Subversion. описать ощущения после двух лет работы с Mercurial/Git сложно. скажем так: в топку эсвээн
