Subversion



Введение


Subversion (сокращенно SVN) — система управления версиями (Version Control System, VCS). Обычно тулзы этого рода считаются теми, кто с ними не знаком, чем-то нужным только большим командам программистов. Но на самом деле, они крайне полезны даже одиночке, и даже не программисту — всем, кому приходится редактировать какие-либо файлы. Так, я встречал весьма восторженное описание системы CVS (идейный предшественник SVN и первая свободная VCS — благодаря чему она до сих пор достаточно распространена) от какого-то то ли журналиста, то ли писателя, ее использовавшего.

Итак, зачем же оно одиночке?
  • VCS хранит всю историю изменений файлов, за которыми следит — всегда можно просмотреть историю файла, различия между двумя его версиями или откатиться после неудачных изменений.
  • VCS хранит файлы эффективно — хранятся только изменения файлов, благодаря чему репозиторий с сотней версий некоторого проекта может весить меньше, чем сам проект.
  • VCS облегчает создание резервных копий. Репозиторий легко сбэкапить, не заботясь о том, а не затрется ли какая-нибудь старая версия, которая в будущем может пригодиться — он всегда хранит всю историю. Кроме того, репозиторий — сам по себе бэкап, если он хранится отдельно от рабочей копии проекта.
  • Онлайн-репозиторий облегчает публикацию исходных кодов (и не только их), кроме того, всегда можно скачать из него самую свежую версию, либо любую из предшествующих. К тому же, при обновлении уже скачанной копии по сети передаются только изменения, резко сокращая расход трафика (и времени на передачу данных).
  • Онлайн-репозиторий — удобное средство синхронизации нескольких рабочих копий. Можно, например, подредактировать что-то на работе, зафиксировать изменения и придя домой — синхронизироваться с репозиторием и продолжить работу. VCS гарантирует, что ни одно изменение при переносе не будет забыто, а если обновляемый файл содержит какие-то незафиксированные изменения — предупредит об этом, предотвратив их потерю.

Именно последний пункт делает VCS столь ценным средством для команд, делая невозможной ситуацию «твою мать, какая сволочь затерла всю мою вчерашнюю работу своей правкой?!». Кроме того, всегда можно выяснить «кто эту херню глючную понаписал?!» или «а что мы такого наменяли под новый год, что все сломалось?».

Почему SVN?

Систем управления версиями — достаточно много, и, в принципе, многие в чем-то лучше. Но
  • SVN прост. Минимальный мануал, который я писал, занимал менее странички текста, и его хватало для вкуривания в SVN в условиях командной работы.
  • SVN — свободное ПО. Хотя нынче этим свойством из заслуживающего внимания не обладает разве что P4 и VSS.
  • SVN широко распространен.
  • SVN лишен большинства недостатков CVS.
Недостатки также имеются, о них с радостью поведают сайты, посвященные другим системам — P4 и Git, например :) Git, кстати, весьма интересная система и во многом он лучше. Но у него есть фатальный недостаток — я его не знаю)

Что такое SVN?

Subversion — централизованная система управления версиями — то есть, она хранит файлы и их историю в центральном хранилище, называемом репозиторий. Subversion ориентирована на работу с файлами — она следит за изменениями файлов, отданных под ее контроль, и сохраняет их. Также, в отличие от CVS, SVN следит и за папками. Подробней об отличиях (и вообще о системе) можно почитать тут, раздел «Subversion и CVS».

Основные понятия

Основными понятиями SVN являются репозиторий и рабочая копия.
  • Репозиторий (Repository) — центральный архив, хранящий файлы и их историю.
  • Рабочая копия (Working Copy, WC, РК) — копия содержимого репозитория определенной версии, с которой и производится работа. Это обычная папка (не считая скрытого каталога .svn, содержащего необходимую для работы системы информацию — его трогать не следует), с которой можно работать как с обычной папкой. Но — SVN следит за изменениями файлов в ней и всегда можно посмотреть сделанные изменения, откатить их или зафиксировать в репозитории, а также обновить до любой версии, содержащейся в репозитории.
  • Извлечение (Checkout) — процедура извлечения из хранилища файлов указанной версии и создания рабочей копии из них.
  • Фиксация (Commit) — процедура сохранения в репозитории очередной версии файлов. SVN не хранит все изменения подконтрольных ей файлов — это не нужно, да и накладно. Она хранит только те версии, которые были зафиксированы.
  • Обновление (Update) — процедура синхронизации рабочей копии с репозиторием — получение из него всех обновлений файлов с момента предыдущего обновления. Также, возможно обновление до указанной версии (в том числе и более старой) — в этом случае рабочая копия будет приведена в соответствие с содержимым репозитория указанной версии.
  • Ревизия (Revision) — версия файлов. Каждая фиксация создает новую ревизию. Ревизия идентифицируется числом — ее порядковым номером. Самая свежая ревизия называется HEAD.
  • Базовая версия — версия файла, полученная из репозитория при последнем извлечении или обновлении, либо успешно отправленная туда при фиксации. Именно относительно нее пользователем и делаются изменения.
  • Конфликт (Conflict) — то, из-за чего все и затевалось. Ситуация, когда один и тот же файл изменили два человека и теперь, прежде чем его сохранить в репозитории, необходимо объединить внесенные ими изменения. Стоит отметить, конфликты часто игнорируются даже, казалось бы, вполне серьезными пользователями, а зря. Бездумное разрешение конфликта — отличный способ грохнуть работу другого.

И как с этим работать?

Итак, предположим, что репозиторий уже существует и в нем содержится какая-то версия проекта. Тогда типичный процесс работы выглядит так:
  1. Прежде всего, следует извлечь рабочую копию — иначе с чем же работать? Репозиторий в лучшем случае содержит непонятно что, а то и вовсе где-то там. На гуглекоде например. Делается это командой checkout, которая требует указания URL репозитория и опционально — ревизии. По умолчанию вытягивает самую свежую версию. Кроме того, можно вытянуть не весь репозиторий, а только какую-либо папку в нем.
  2. Теперь можно работать с ней как с обычной папкой с файлами. Единственное исключение — удаление, копирование и переименование (оно же перемещение) следует делать средствами SVN (команды delete, copy, move) — иначе она проигнорирует эти изменения и откатит их при первом же обновлении. Также, SVN не будет следить за новым файлами, пока они не будут явно добавлены под ее контроль командой add.
  3. (Опционально) Обновить копию, чтобы получить обновления из репозитория и проверить наличие конфликтов. Можно делать в любой момент по необходимости, для одиночки это вообще нужно только когда надо синхронизировать несколько рабочих копий. Если возникли конфликты — их необходимо разрешить.
  4. Сделанные изменения (доведенные до некоторой логической точки) следует зафиксировать в репозитории. В случае неразрешенных конфликтов — SVN фиксировать откажется. Если конфликт обнаружится в процессе фиксации — вся фиксация отменяется, в этом случае нужно обновить копию и разрешить конфликты. Фиксация атомарна, она или применяется вся, или не применяется вообще. Также она не влияет на параллельно идущие процессы обновления — выполняющие их пользователи получат ту версию, которую начали получать.
  5. Вернуться к пункту 2. Либо, если работа с проектом завершена — удалить РК как обычную папку.

Также, в любой момент работы можно:
  • Посмотреть текущие изменения по сравнению с базовой версией — status, diff.
  • Сравнить две ревизии файла — diff.
  • Откатить изменения в любом из файлов — revert.
  • Посмотреть историю ревизий файла или проекта — log.

Иногда, при сорвавшемся обновлении, рабочая копия оказывается в заблокированном состоянии. Тогда нужно выполнить команду cleanup и обновиться еще раз.

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

Разрешение конфликтов

Если над проектом работает более одного человека — будут неизбежно возникать конфликты. Допустим, есть два пользователя — Гарри и Салли (да, я сперва заглянул в SVN Book, но картинки оттуда тянуть лень). Они работают с одним и тем же файлом А.

  1. Гарри и Салли получают копию файла А из репозитория (в процессе извлечения или обновления).
  2. Гарри вносит правки в свою копию, получая файл А' и фиксирует из в репозитории — теперь там хранится файл А'.
  3. Салли также вносит свои правки в свою копию, получая файл А" и пытается зафиксировать их. В случае обычного файлохранилища файл А" перезаписал бы файл А', попутно угробив все внесенные Гарри правки. Но в случае SVN возникает конфликт — в результате Салли объединяет правки из файлов А' и А" и фиксирует файл А*, содержащий все внесенные в него правки.

Для разрешения конфликта есть несколько путей.
  • Можно попросить SVN разрешить конфликт автоматически командой resolve. Она попытается слить изменения в текстовых файлах примерно по тому же принципу, по которому работают 3-way Diff/Merge утилиты. Если правки производились в разных строках (например, Гарри изменил начало файла, а Салли — конец) — SVN автоматом внесет обе правки. Если оба пользователя поменяли одну и ту же строку — выберет вариант, указанный параметром команды (также можно вместо слияния указать SVN взять одну из версий файла полностью, проигнорировав изменения другой версии). С бинарными файлами не работает — можно только указать, какую из версий считать правильной — свою, чужую или базовую.
  • Можно отредактировать конфликт вручную. В текстовые файлы в места конфликтов SVN вносит маркеры конфликта, для бинарных — сохраняет все три версии (базовая, своя и чужая) в рабочей копии. Нужно ручками выправить все конфликты, разобраться с бинарными файлами и финальную версию пометить как решенную — командой resolved.
  • Можно скормить файлы во внешнюю утилиту слияния — например, KDiff3. Правда, не уверен, доступна ли такая функция в самом SVN — я пользуюсь GUI-клиентом TortoiseSVN.
  • Можно забить на конфликт и сразу пометить файл как resolved. Правда, он окажется засран маркерами конфликта вместе с заключенными между ними обеими версиями… Плохой метод.

Экспорт

Часто бывает нужно получить чистую копию проекта — без папок .svn, например, для публикации архива исходников. Можно скопировать рабочую копию и удалить папки .svn… Правда, они есть и во всех вложенных папках тоже… Когда-то я даже написал утилитку для рекурсивного удаления папки .svn. Но лучше использовать команду export. Она позволяет экспортировать чистую копию как из рабочей, так и непосредственно из репозитория.

Ветви

SVN поддерживает идеологию ветвей — когда независимо от основной линии развития проекта разрабатываются побочные, при этом изменения могут копироваться между ветвями. Правда, поклонники Git утверждают, что поддержка ветвей в SVN говно и недостойна таковой называться. Возможно и правы, Git и правда выглядит очень любопытно и обеспечивает контроль над туевой хучей ветвей ядра Linux (для которого и был создан Торвальдсом).
С ветвями я не работал, поэтому рекомендую почитать на эту тему SVN Book.

Создание репозитория

Чтобы работать с репозиторием, нужен, как ни странно, сам репозиторий. Хорошо, когда подключаешься к существующему проекту — он уже есть. А если проект начинаешь сам? Тогда его необходимо создать. И тут есть два варианта — локальный и удаленный репозитории.

Создание локального репозитория
Прежде всего — надо создать папку под репозиторий. Затем — создать в ней репозиторий командой create (точнее, в случае официального клиента — svnsdmin create). При этом нужно выбрать тип репозиторий — FSFS или BDB. Не буду вдаваться в подробности, но лучше создать FSFS (а свежие версии так и делают по дефолту). Кроме того, BDB репозиторий нельзя создавать на нелокальной файловой системе (например, на подмонтированном сетевом ресурсе) — через некоторое время он просто сломается.
URL для созданного локально репозитория — file:///path/to/repository, например, если репозиторий в папке C:\MyRepository, то его URL — file:///C:/MyRepository.
С локальным репозиторием клиент SVN работает непосредственно — сервер не требуется. Для обслуживания репозитория (как локального, так и выведенного в сеть сервером) предназначена утилита svnadmin.

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

Немного о содержимом этой папки. Вообще, хранить файлы в репозитории можно как угодно, но есть рекомендованный стандарт. Согласно ему в репозитории при импорте создаются пустые папки trunk, branches и tags. Если планируется хранить в репозитории несколько проектов — то для каждого создается папка, а уже в этих папках — папки trunk, branches и tags.

Назначение этих папок:
  • trunk — ствол, здесь собственно и хранятся файлы проекта, с которыми ведется работа.
  • branches — ветви, сюда (в свою подпапку для каждой ветви) делаются копии ствола (или других ветвей), с которыми потом можно работать независимо от ствола, а по окончании работы — слить со стволом. В SVN копирование очень дешевая операция — по сути просто запись «сюда сделана копия таких-то файлов такой-то ревизии» в репозитории, поэтому и ветки, и метки на ней сделаны.
  • tags — метки, копии ревизий, соответствующих релизам проекта. В отличие от других VCS, в SVN метки можно модифицировать далее, как обычные ветви. Обычно это считается недостатком, но в принципе, может использоваться для поддержки старых версий проекта (например, текущая версия — 3.1, но некоторые клиенты не хотят переходить на нее с 2.3 и требуют багфиксов к ней — эта работа может производиться в метке /tags/2.3, не затрагивая текущую версию).

Удаленный репозиторий
Удаленный репозиторий может быть в локальной сети и в интернете.
В первом случае (а также во втором, когда репозиторий на своем хостинге) на хосте репозитория следует поднять и настроить SVN сервер — родной svnserve (говорят, крайне дыряв) или на основе apache+webdav или иной SVN-плагин. Но это тема не этой статьи, да и не знаком я с ней.
Но есть еще один вариант — это SVN-хостинги. Их немало, как платных, так и бесплатных. Они предоставляют уже готовый репозиторий, а если и нет — то сами расскажут, как его создать. Лично я пользуюсь хостингом от гугла. Остальных — доставит он же :)
Репозиторий в интернете позволяет синхронизировать свои рабочие копии на разных компах, а также работать над проектом вместе с другими людьми, возможно на другом конце мира. А также, при желании — предоставлять всем желающим доступ (на чтение) к самой свежей версии исходников.

Круто. А где взять?

На официальном сайте, теперь под крылышком у Apache. Однако, официальный клиент — это кроссплатформенная консольная программа. Не всем они нравятся, хотя свои плюсы у них есть. Поэтому существуют альтернативные клиенты и оболочки на официальный консольный клиент.



Лично мне нравится TortoiseSVN — это GUI-клиент (т.е. в отличие от оболочки он выполняет действия сам, а не передает их консольной программе svn), выполненный как расширение Проводника Windows. Вся работа с ним производится через контекстное меню Проводника. Также совместимо с Total Commander и ему подобными файл-менеджерами (теми, которые запрашивают иконки файлов у винды и умеют показывать контекстное меню Проводника). Поклонникам FAR'а и других операционок могу порекомендовать только гугл. Также TortoiseSVN показывает состояние файлов, накладывая оверлеи на их иконки. Благодаря этому с первого взгляда видно состояние рабочей копии — модифицированные файлы, конфликты и так далее.
Стоит также обратить внимание на то, что TortoiseSVN добавляет свои пункты в контекстное меню, показываемое при перетаскивании файлов/папок правой кнопкой мыши. Там такие полезные команды, как Export, Copy, Move.
Алсо, в разделе языковых пакетов к TortoiseSVN имеется годный мануал в PDF, на русском. Рекомендую почитать, это своеобразный аналог SVN Book для TortoiseSVN.

Настройки TortoiseSVN

Настройки вызываются через контекстное меню проводника, вызванное на любом объекте, пункт TortoiseSVN->Settings. Их там довольно много, опишу основные.



Здесь следует настроить Global ignore pattern — список масок файлов, которые SVN будет игнорировать — т.е. не предлагать их добавить, зафиксировать и т.д. Сюда следует внести различные временные файлы — на скриншоте, например, внесены файлы, создаваемые Delphi версий по 7-ю. Здесь же можно поменять язык, русский поддерживается — но не гарантирую совпадение терминологии, т.к. пользуюсь английской версией.



Здесь внимания заслуживает Status cache. Выбранный вариант обеспечивает рекурсивную проверку статуса — папка будет помечена как модифицированная даже если модифицированный файл в одной из ее подпапок.
При снятой галочке «Show overlays and context menu only in explorer» можно использовать TSVN из менеджеров вроде Total Commander.
Галочки Show overlay for позволяют отключить назойливые метки на файлах, не находящихся под присмотром SVN.
Галочки в поле Drive Types позволяют отвадить SVN от проверки на модификации медленные носители и флешки (последнее — чтобы оно не мешало их извлекать), а также от заданных дисков.

На вкладке Network можно настроить доступ к сети и выбрать клиент для SSH, но у меня там значения по умолчанию (разве что, ЕМНИП, я вручную указал использовать прилагающийся к TortoiseSVN TortoisePLink.exe как клиент SSH).

На вкладке Saved data можно почистить истории и сохраненные данные аутентификации.

На вкладке Hook scripts можно добавить программы, срабатывающие при определенных событиях. У меня там, например, внесен скрипт, срабатывающий после обновления одной из РК.

На остальных вкладках (кроме рассмотренных далее) преимущественно настройки вида и поведения. Можно настроить их на свой вкус или удовлетвориться дефолтными.

Свистелки и перделки

На TortoiseSVN можно навешать некоторое количество дополнений, расширяющих возможности. Итак, по порядку.

Внешние Diff/Merge
Хотя к TortoiseSVN прилагается родная программа TortoiseMerge, мне больше нравятся WinMerge для сравнения файлов (он подсвечивает изменения внутри строк, позволяет редактировать файл прямо в нем и умеет подсвечивать синтаксис для многих языков, но не умеет сравнивать три файла) и KDiff3 (удобная программа для сравнения и слияния трех файлов, изначально созданная под KDE). Кроме них интерес могут представлять Beyond Compare, Structured Difference Viewer, утилиты Diff/Merge из состава Perforce и Borland StarTeam (или как его там, не помню уже) — но из них бесплатны только две последние.

Настраиваются эти утилиты в разделе External Programs, в прилагаемом хелпе есть командные строки для многих распространенных программ. В моем случае это
"C:\Program Files\WinMerge\WinMerge.exe" -e -ub -dl %bname -dr %yname %base %mine
для обоих вариантов на вкладке Diff и
"C:\Program Files\KDiff3\kdiff3.exe" %base %mine %theirs -o %merged --L1 Base --L2 Mine --L3 Theirs
для вкладки Merge.

Интеграция с багтрекерами
Осуществляется плагинами, список их можно найти на сайте TortoiseSVN. После установки плагина его можно подключить к соответствующей РК на вкладке Hook Scripts->Issue Tracker Integration.

CommitMonitor
Пара глазок, которые сидят в трее и периодически проверяют указанные репозитории на наличие обновлений. Иногда полезно. Обитает вместе с другими полезняшками в разделе Other Tools сайта TortoiseSVN.

Ссылки
Официальный сайт у Apache.
Старый официальный сайт.
TortoiseSVN.
Полезняшки для TortoiseSVN.
WinMerge.
KDiff3.
Википедия о SVN.
SVN Book — книга-руководство по Subversion.

  • +6
  • 29 мая 2011, 06:48
  • Vga

Комментарии (27)

RSS свернуть / развернуть
Для git так же есть гуи tortoisegit, самое главное из-за чего я перешёл на него: децентрализованная работа, т.е. не нужно иметь постоянную связь с «центральным» сервером. Репка создается локально в папке с проектом, особенно удобно когда работаешь с мобильным диском, или например взять проект проект домой поработать, тупо скопировал папку с проектом на флешку принес домой и все у тебя с собой (когда дома сети не было, это был идеальный вариант).
0
  • avatar
  • ZiB
  • 29 мая 2011, 07:12
Да, я знаю. Тортила есть и для CVS, и для Mercurial. Но статья-то не о Git :)
Ну а сетевая активность SVN меня не напрягает. Дома я работаю в основном с своими локальными репозиториями, а обновить репоз на гуглкоде или работать над командным проектом без инета все равно не получится.
К тому же, отдельный репоз на другом диске — это чуть надежнее с точки зрения сохранности сорцов) Если не весь репоз, то хотя бы HEAD уцелеет при аварии диска. Хотя с распределенной системой это тоже можно сделать.
0
а в чем проблема, так же заливай периодически на внешний сервак и все у тебя уцелеет :)
0
Ну я же сказал — можно и так. На whygitisbetterthanx.com наглядно показано, что с ним можно реализовать такой же workflow, как с svn, а обратное неверно. Но так уж сложилось, что я освоил svn и осваивать git в объемах больших, чем нужно для выуживания репозиториев VoGeeky причин пока нет. А писать статью про систему, где я знаю полторы команды… :) Но ее можешь написать ты!
0
Но стоит отметить, что даже там git выигрывает по Easy to Learn только у перфорса :)
0
за чем описывать то, что уже и так описано не однократно, доки море…
ОК, я понял тебя :)
0
Ну, например, чтобы разьяснить, почему заинтересовавшемуся VCS электронщику стоит хранить свои схемы и трассировки в Git, а не SVN :)
0
Вы молодец, что подняли тему VCS, но SVN ИМХО не лучшая система из них. Как программист, работающий за деньги много лет ;), я видел и работал с CVS, SVN, Darcs, git, mercurial и для себя сделал вывод, что лучше mercurial не встречал ничего.
Во-первых, можно использовать без всякого сервера персонально.
Во-вторых, очень легко переходить с SVN и иже с ними.
В-третьих, все служебные файлы лежать в top-dir в одной папке, если надо сформировать архив сырцов не приходится рыскать по проекту и убирать .svn папки из каждой директории.
В-четвертых, есть бесплатный сервер репозиториев Битбакет, с которым можно синхронизировать для бэкапа свои локальные репо.
В-пятых, только DVCS позволяют работать полноценно без сети, а при появлении ее записать на сервер не последнее состояние репо, а историю всех изменений. В шестых, в mercurial ОЧЕНЬ удобно проводить мердж, редко приходится корректировать результат руками, тогда как в SVN это приходится делать сплошь и рядом.
Вот как-то так.
+1
Хе-хе, а вот и сторонник меркуриала) Мое общение с ним ограничилось командой hg clone. Кстати, именно за это люблю консольные VCS-ки — можно инстальнуть такую VCS для стягивания пары репозиториев не сильно засирая систему. Максимум — PATH подправит и пару иконок создаст.
1. Ну это и к SVN относится.
3. У гита так же, а у SVN есть специальная команда для чистой копии. В случае с TSVN она выполняется одним взмахом мыши.
4. Это у всех так. Тот же гуглокод предоставляет репозитории и для гита с меркуриалом. Опять же всякие там gitorious и github.
5. Это да. Хотя одиночке это малоактуально, а в команде обычно VCS приходится не выбирать, а принимать :)
6. Гитовцы говорят, что у них еще лучше поддержка веток. Но я с ветками не работал, так что не знаю.
— Короче, тему я поднял, а за свои любимые системы сами агитируйте :3
0
А черт, оно превратило HR-ку из трех дефисов в тире. Хочу редактирование комментариев в течение пяти минут после публикации — косяки править)
+2
Да, я сторонник — буквально проповедник ;). «Здравствуйте, вы пользуетесь mercurial»? ;)
4. Я пользовался всеми перечисленными репо, больше всего понравился bitbucket, гугл-код на втором почетном месте. Свои персональные репо я держу на битбакете и на домашнем NAS (если кому интересно: Netgear Stora — линукс с RAID1 на борту, mercurial практически настраивать не пришлось :))
5. Одиночке малоактуально, но согласитесь, приятно. По правде говоря, это одно из самых приятных для меня свойств всех DVCS :).
6. Нагло врут ;). Ветки хороши в любой DVCS. Обычно они являются просто тэгами (а не копиями репо, как в SVN), поэтому слияние веток проходит гораздо проще.
Да, еще 7. DVCS хранит не файлы, а историю изменений файлов, поэтому так просто проходят слияния и такой маленький размер служебных файлов. Вот я мигрировал в одном из больших проектов (около 500Мб исходных текстов и файлов данных) — SVN метаданные занимают около 1Гб, mercurial — чуть меньше 200Мб (причем история изменений импортирована из SVN).
0
5. Ну, никто же не мешает держать репо локально, ежли не в команде. Забавно кстати, что в последнем командном проекте, где я участвовал, без сети работать было невозможно даже не из-за SVN, а из-за того, что без соединения с сервером программа умела только ругаться :)
6. whygitisbetterthanx.com/#cheap-local-branching — хз-хз)
7. SVN хранит так же. РК имеют столь страшный вес потому, что там в .svn сныкана полная копия базовой версии, для быстрого отката и сравнения. DVCS-кам она не нужна, у них там весь репозиторий припасен. А вот репоз SVN'овский тоже вполне скромен размером.
0
5. Локально нужно хранить, но главное не забывать про бэкап :). А так повесил хук на коммит и рраз — все коммиты автоматом пушатся на удаленный сервер.
6. В меркуриале точно так же :).
0
5. Чтож, определенные плюсы в этом есть. Но с SVN слезать все равно пока лень.
0
Гитхаб за непубличные репозитории вроде просит денежку. На битбакете можно заводить неограниченное число публичных репозиториев бесплатно. Единственное ограничение — доступ к бесплатному непубличному репозиторию могут иметь только пять юзеров.
0
Я тоже с полгода назад перешел на меркуриал. Очень меня он радует, все просто и удобно. Особенно порадовал Bitbucket, на котором можно хостить бесплатно и закрытые проекты.
До этого для личных целей использовал Plastic SCM, он хотя и проприетарный, но с некоторых пор бесплатный для небольших команд (до 15 человек). Штука тоже очень удобная, вот только хостингов с ним я не встречал. Поэтому для меня меркуриал оказался удобней.
0
оо хорошая вещь при разработке промышленного или любого другого крупного объекта.
Плюс 5 Студии в том что там система контроля версий встроена.
0
Мм, какой именно студии? AVR? Не знаю уж что там встроено, но родная для M$ Visual SourceSafe, AFAIK, теплых слов удостоена только на microsoft.com.
А так с VCS интегрируются uVision (правда, для SVN придется самому пункты меню прописывать, или искать готовый — там в основном всякие коммерческие вроде P4, VSS, Rational), MPLAB (эта из коробки умеет SVN и CVS, а вот DVCS идут лесом), скорее всего дружат и эклипсовые. Впрочем, меня больше устраивает интеграция тортилы с проводником.
0
5 студия подхватывает все плагины VisualStudio (категорически рекомендую VisualAssist), так что для интеграции SVN можно поставить AnkhSVN.
0
VAX в поставке. Хотя отдельно стоит тоже.
Ну, то, что туда можно интегрировать другие VCS — хорошо. Хотя по дефолту там только VSS (и то возможно только потому, что у меня стоят 6, 8 и 9 студии).
Но я интеграцию даже в Delphi не использую.
0
ну просто хотя бы что-то. По функциональности не скажу — не юзал, тоже пока использую черепашку. Ибо проекты разрабатываю в 1 лицо.
0
Нет, в 2010-й студии, на которой основана AVR Studio 5, по дефолту есть поддержка TFS, который очень сильно превосходит VSS. Хотя, ИМХО, что git, что mercurial все равно приятнее.
0
А у меня оно тока VSS провайдер видит. причем как бы не от MSVS 6. Да и фиг с ним, мне хватает интеграции с файл-менеджером.
0
В полной VS2010 точно есть, а вот про AVR Studio с уверенностью не скажу. А так да, мне тоже вполне хватает интеграции с проводником и Total Commander. :)
0
У меня стоят полные 2005 и 2008. причем вторая вроде Team-чтототам.
0
Там фишка в том, что он ставится вместе только с 2010-й. Для 2005-й и 2008-й нужно было отдельно ставить клиент. Причем все эти клиенты еще не вполне совместимы. Просто начиная с 2010-й студии мелкософт окончательно забил на убогий VSS и предлагает TFS как альтернативу. TFS 2010 уже даже ставится на обычный комп и не требует серверную винду и участие в домене. Хотя он все равно создает впечатления чего-то очень тяжелого и неповоротливого. SVN для меня, по крайней мере, гораздо удобнее.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.