Apache Subversion (известна също като „SVN“) е безплатна, централизирана система за контрол на версиите, официално пусната през 2004 г. от компанията CollabNet.
Предназначена е да замени разпространената по това време система CVS ( Concurrent Versions System ), която вече се счита за остаряла. Apache Subversion реализира всички основни функции на CVS и е освободена от някои от недостатъците на последната.
Apache Subversion се използва от много общности с отворен код (включително общности, които преди това са използвали CVS ). Сред тях са такива известни проекти като Apache OpenOffice, GCC, Free Pascal, Python, Ruby, FreeBSD, AROS, Blender, Boost, Tor Vidalia Bundle, OGRE. Apache Subversion се използва широко и в затворени проекти и корпоративната сфера. Хостингът на Subversion, включително за проекти с отворен код, се предоставя и от популярни хостинг проекти SourceForge.net, Tigris.org, Google Code и BountySource.
През 2007 г. аналитичната компания Forrester, която сравнява предимствата и недостатъците на различните системи, оценява Apache Subversion като „едноличен лидер в категорията Standalone Software Configuration Management (SCM) и силен участник в категорията Software Configuration and Change Management (SCCM)“.
Според статистическите данни за използването на пакетите Linux-от дистрибуциите Debian и Ubuntu броят на активните потребители на Apache Subversion е приблизително същият като този на Git и надхвърля този на CVS, Mercurial и Bazaar (към юни 2011 г.).
Като официална документация се позиционира книгата на издателството O’Reilly Media, която е свободно достъпна и се актуализира от авторите при излизането на нови версии на SVN.. Съществуват и преводи на книгата на редица езици, включително и на руски, но докато в английските версии на книгата вече са описани версиите 1.6 и 1.5, на руски език са достъпни само книгите, описващи версиите до 1.4 включително.
Характеристики на Apache Subversion
създаване на клонове (чрез копиране на директории) и работа с тях; сливане на клонове (чрез прехвърляне на промени).
директен достъп до локалната файлова система; чрез собствен мрежов протокол; чрез уеб сървър чрез WebDAV/DeltaV.
база данни или набор от общи файлове.
Недостатъци на Apache Subversion
Apache Subversion не винаги може да се справи правилно с операциите по преименуване на файлове, ако съдържанието на файла се променя едновременно с преименуването. Проблеми могат да възникнат и ако файл, преименуван в локалното копие, е променен от някой друг в хранилището. Някои от тези проблеми са отстранени във версия 1.5, но това решение все още не е завършено.
Също така за слабо място на Apache Subversion се смятат операциите за сливане на клонове. Преди 1.5 всички такива операции трябваше да се проследяват ръчно от потребителите с помощта на подробни записи в дневника на промените. От 1.5 нататък има основна поддръжка за автоматично проследяване на сливанията, която разработчиците планират да подобрят в бъдещите издания. Понастоящем Apache Subversion поддържа сравнително добре типични сценарии за сливане; при по-сложни случаи може да възникнат проблеми. Препоръчително е да организирате работния си процес, за да избегнете проблемните сценарии. Не се поддържа сливане на преименувани файлове и директории.
Информацията, веднъж поставена в хранилището Apache Subversion, остава там завинаги: даден файл може да бъде изтрит в текущата редакция, но винаги е възможно да се възстанови от хранилището една от предишните редакции, в които е съществувал файлът. Въпреки че запазването на предишни ревизииединственият начин да направите това е да създадете дамп на хранилището, да го обработите със стандартната помощна програма и след това да възстановите хранилището от дамп-а. В Apache Subversion няма стандартен начин да се направи това; единствената възможност е да се създаде дамп на хранилището, да се обработи със стандартната програма svndumpfilter и след това да се възстанови хранилището от дамп-а. Съществуват и програми на трети страни за автоматизиране на този процес, но при всички случаи тази операция изисква временно спиране на достъпа до хранилището и намесата на администратор с достатъчно високи права, за да изтрие напълно старото хранилище и да го замени с ново.
запушва файловата структура на проекта. Започвайки с 1.7, в корена на работното копие на проекта се създава една директория.svn, метаданните в която се записват с помощта на SQLite.
