Subversion e свободна софтуерна система за контрол на версиите. Проектът е разработен на база на концепцията отворен код. Системата използва централизирано хранилище за съхранените на файлови структури. Тя следи всички промени в директориите и файловете, поставени под неин контрол, като запазва всички стари копия със съответната дата и час, при постъпване на нови версии в хранилището. Това позволява на потребителя при нужда да се върне към по-стара версия на проекта или да разгледа в детайли историята на промените. Такава организация на съхранение на файловете улеснява съвместната едновременна работа на много хора над даден проект, работещи от различни места и в различни времеви зони. Тази система може да бъде използвана за всякакви колекции от файлове – от изходен код до домакински списъци за пазаруване.
Subversion е широко използвана система в общността на отворения код и се използва от редица известни проекти, включително Apache Software Foundation, KDE, Free Pascal, FreeBSD, GCC, Python, Django, Ruby, Mono, SourceForge.net, ExtJS and Tigris.org.
История на Subversion През 2000 г. новосъздадената американска компания CollabNet, Inc. започва да търси програмисти, които да напишат и развият заместител на CVS („Concurrent Versions System“ – първата система за контрол на версиите. Тя е с отворен код и поддържа мрежова връзка, което позволява на много програмисти от цял свят да работят заедно). Като първа такава система, CVS не е идеално изпипана и има много недостатъци, чието отстраняване става основна цел на програмистите. От CollabNet решават да започнат от нулата с нова система, като запазят основните идеи на CVS, но премахнат бъговете и грешките, които тя дава.
През февруари 2000 г. от CollabNet се свързват с Карл Фогел, автор на книгата Open Source Development with CVS (Coriolis, 1999) и му предлагат да се включи в работата по проекта за нова система за контрол на версиите. По стечение на обстоятелствата, точно по същото време Карл, съвместно с неговия приятел Джим Бланди, обмисля дизайн за нова такава система. През 1995 г., двамата с Джим Бланди създават фирмата Cyclic Software, която предлага договори за поддръжка на CVS. Въпреки че скоро след това я продават, те продължават да използват CVS ежедневно в работата си и така се сблъскват с недостатъците ѝ, което ги навежда на мисълта, че е необходим по-добър начин за обработка и управление на информацията за версиите. Още преди да получи поканата от CollabNet за работа по проекта, Карл Фогел вече е наясно с основния дизайн и името на новата система – Subversion. Той веднага приема поканата за работа, а неговият приятел Джим Бланди успява да придума работодателя си, Red Hat Software, да го „дари“ за неопределен период от време на CollabNet, за да може да участва и той в работата по проекта.
През май същата година започва задълбочената работа по дизайна на новата система, в която се включват и Браян Белендорф и Джейсън Робинс от CollabNet, както и Грег Щайн, който по това време е независим разработчик на програмни осигурявания. Subversion бързо привлича интереса на голяма част от активните разработчици на софтуер. Става ясно, че много хора не са били доволни от работата на CVS и приветстват идеята най-сетне тя да бъде подобрена.
Като цяло работният екип на Subversion не се опитва да намери нови концепции за методологията на системите за контрол на версиите, а да поправи неизправностите на CVS.
След 14 месеца на разработка на 31.август 2001 г., Subversion получава собствен хостинг. Това е датата, на която разработчиците на Subversion спират да използват CVS за управлението на изходния код на Subversion и започват да използват новоразработената система.
През 2009 г. CollabNet съвместно с разработчиците на Subversion успяват да интегрират проекта си във Фондация за софтуер Apache (ASF) – един от най-известните колективи за свободни проекти в света.
В началото на 2010 г. системата Subversion е напълно приета в семейството на топ-проектите на ASF, премества „уеб – присъствието“ си на www.subversion.apache.org и бива преименувана на „Apache Subversion“.
Начин на работа Това, което прави една такава система полезна и ценна за разработчиците на софтуер е това, че предоставя възможност за подробно разглеждане на направените промени, които са довели до създаването на нова версия, за сравняване на версиите една с друга и за връщане на по-стара версия като актуална.
В основата на всяка една система за контрол на версиите, както е и при Subversion, стои хранилището на информация (repository). При постъпване на нова версия на файл в хранилището, старата му версия се съхранява с дата и час или с други думи, съхраняват се всички версии на даден файл в хронологичен ред. Едно типично Subversion-хранилище съдържа файлове на повече от един проект, като всеки проект е поддиректория във файловата система на хранилището. Системата съхранява също и автора на всяка версия – по тази причина при свързване с хранилището всеки потребител се идентифицира с име и парола. Потребителите имат различни права – или да редактират файла (т.е. да запазват нови версии в хранилището) или само да четат данни. Тъй като повечето софтуерни продукти могат да работят само с по една версия на даден файл, а не с всички наведнъж, потребителят получава работно копие (working copy) на нужните му файлове, което съдържа изисканата от него версия от хранилището (в типичния случай – най-актуалната) и работи с него.
Системите за контрол на версиите могат да работят по един от следните модели – „заключи – промени – отключи“ („lock – modify – unlock“) и „копирай – промени – слей“ („copy – modify – merge“). Subversion работи по втория, но нека разгледаме и двата: Моделът „Заключи – промени – отключи“ – този модел предотвратява успешно сценарии, при които двама потребители работят едновременно върху работно копие на проекта и в крайна сметка единият публикува промените си преди другия и след публикуването и на промените на втория, тези на първия биват загубени. Въпреки това този модел не е сигурен. Той позволява само на един потребител да работи върху проекта в дадения ден и час. След получаването на работното копие, потребителят заключва файла и едва тогава има възможност да го променя. След приключване на работата с дадения файл, потребителят отключва файла и той става достъпен за обработка и от останалите. Проблемите с този модел са следните: след заключване на файл, потребителят може да забрави да го отключи и това да доведе до невъзможност за работа на другите потребители заключването може да доведе до излишна сериализация на файла – един потребител променя началото, а друг – края. Промените не се застъпват и те спокойно могат да ги правят и едновременно, след което да слеят двата проекта. Няма нужда да се правят нови версии в случая. Заключването води до фалшиво чувство за сигурност – моделът позволява на различни потребители да работят върху различни файлове едновременно, но в случай, че двата файла зависят един от друг, моделът не дава гаранция, че информацията няма да се промени фатално.
Моделът „Копирай – промени – слей“: Този модел работи по следния начин: всеки потребител се свързва с хранилището на проекта и получава свое собствено работно копие. Всеки работи самостоятелно върху копието си. Накрая отделните копия се сливат в една финална версия. Системата за контрол на версиите подпомага сливането, но при големи застъпвания в информацията е необходима и човешка намеса преди финализирането на новата версия на проекта.
При всяко обновяване на хранилището в Subversion, или всички промени биват приети, или никои от тях. В случай на приемане следва създаване на ново състояние на файловата система на хранилището, наречено „ревизия“. Всяка ревизия има уникален номер, по-голям с единица от този на предходната. При създаването на хранилището на даден проект ревизията е с номер 0 и се състои от празна директория.
Команди за работа в Subversion svn checkout – получаване на работно копие за някое от поддърветата на хранилището. Пример:
$ svn checkout http://svn.example.com/repos/nature A nature/Makefile A nature/plants.c A nature/animals.c Checked out revision 56. $ ls -A calc Makefile plants.c animals.c .svn/ $
Буквата А в началото на реда означава, че Subversion добавя определен брой елементи в работното копие. Допълнението „– .svn –„ е файл, който пази системната информация на Subversion по поддръжката на работното копие – точно време на създаването му и състоянието на последната ревизия преди създаването на работното копие. Точно този файл .svn отчита дали са направени промени в оригиналния файл. svn commit – изпращане на промените към хранилището. След тази команда, всички нови работни копия съдържат направените промени. Може да бъде добавено и съобщение за направените промени при изпращането им с текущата команда. Например: svn commit plants.c -m "Fixed names in plants.c." Ако междувременно още някой работи върху работно копие на същия файл, който първият потребител е променил, той остава с неактуално копие. За целта се използва другата команда svn update, която актуализира работното копие на втория потребител, като му добавя промените, запаметени от първия след края на работата му. Не е необходимо уточняване на това, кой точно файл трябва да бъде актуализиран. Subversion го намира сам, използвайки информацията от .svn файла. svn help <subcommand> – описва употребата на командата, написана на мястото на <subcommand>, като включва нейните синтаксис, опции и поведение. Пример: $ svn help update .
Има два начина за добавяне на нови файлове в хранилището на Subversion и това е чрез командите svn import и svn add. svn import < path/to/the/tree > – служи за добавяне в хранилището на цяло дърво от файлове, като автоматично се създават необходимия брой директории за файловете от дървото. svn add – добавя нови файлове към хранилището. svn delete – изтриване на файлове от хранилището. svn copy <file1><file2> – създава се нов файл („file2“) като дубликат на първия файл. Вторият файл се насрочва да бъде добавен към хранилището. След следващия commit историята на промените на първия файл също се добавя към копието – „file2“.
След направени промени върху работното копие, винаги е добре те да бъдат прегледани преди commit-ването им. Команди: svn status – преглед на промените. svn diff – подробно описание на промените – вникване в детайлите им.
Други команди: svn revert – връща по-стара версия на файла или директорията като текуща (актуална). svn resolve – отстраняване на конфликтите при merge-ване на файлове.
Инструменти
TortoiseSVN – свободен Уиндоус инструмент за Apache Subversion с лиценз от GNU General Public License (GPL). Управлява файлове и директории в реално време. TortoiseSVN се интегрира безпроблемно в Windows-обвивката (като например Windows Explorer). Това позволява на потребителя да продължи да работи с инструментите, с които е свикнал, без да му се налага да отваря приложението всеки път при необходимост от използване функциите за контрол на версиите, предоставени от Subversion.
Контекстното меню на TortoiseSVN е съвместимо с различни файлови мениджъри, което не задължава потребителя да използва Windows Explorer-a, може да го достъпва и чрез File/Open-диалоговия прозорец.
Състоянието на всеки файл с подверсии в себе си се индицира от малка иконка върху тази на файла. По този начин потребителят вижда в какво състояние е работното му копие.
Всички команди от Subversion са достъпни от контекстовото меню, където TortoiseSVN добавя и свое подменю.