Немного о системах хранения исходников
- modified:
- reading: 5 minutes
У меня уже достаточно давно стоит дома репозиторий для хранения исходного кода и документов. Поставил я его, наверное, еще года 4 назад, как начал работать удаленно дома. Он использовался сначала для проектов, над которыми работал (удаленного репозитория в тот момент в той конторе не было – странно, но не было), затем начал хранить свои мелкие проекты, наработки, потом подумал о том, что и диплом, который я писал в то время в LaTeX, тоже очень хорошо хранить в репозитории. Потом и OneNote, презентации, документы и т.д. Самое удивительное, что за эти 4 года репозиторий у меня вырос всего на 200 мегабайт. Использовал я тогда обычный SVN. Поставил TortoiseSVN, сделал репозиторий в папке и начал использовать. Со временем появилась необходимость расшаривать этот репозиторий между несколькими компьютерами, тогда я познакомился с Visual SVN Server, который так удачно оказался бесплатным.
Дальше получил другую работу, и там тоже оказался SVN, потом сменил работу, и тут меня настигло ужасная практика разработки с использованием системы очень похожей на Visual SourceSafe (а именно Dynamsoft). Привыкал я долго, нужно было блокировать файлы на сервере, потом можно работать с ними. Как доработали - нужно разблокировать, чтобы другие разработчики так же имели доступ на изменение и т.д. Понятное дело, что с такой системой нужно делать как можно чаще комиты, чтобы не лочить работу своим коллегам. Представляете у нас даже у каждого свой sln (файл solution для Visual Studio) файл был, это в то время когда проект разрастался, чтобы не лочить подолгу сам sln, когда добавляли проекты, особого смысла в этом конечно не было, но иногда спасало. Правда, в этом случае нужно было не забывать всем говорить о добавлении нового проекта. Благо уже месяца 3, наверное, как перешли на TFS. В принципе ура, победа, теперь все построено на merge, на слиянии файлов, и даже, вроде, работа очень становится похожа на то, как работаешь с SVN, но есть мелкие проблемы. Вроде, храним какие-нибудь шаблоны писем, смысла помещать в solution нет, потому просто болтаются в папках, так добавишь туда файл, нужно еще ручками сделать добавление, а вот SVN сам бы подхватил. Другая неприятная мелочь, что AutoMerge обязательно нужно делать ручками (нажать кнопку), сам он автоматически не хочет. А самая неприятная деталь – это то, что при изменении файла он все равно его пометит на сервере, потому при любом изменении нужно быть приконекченным к интернету (у нас распределенная команда, поэтому для нас важен интернет). А так как интернет у нас очень стабильный, то бывает, что не заметишь, как какой-нибудь файл он не пометил, и ты уже работаешь в офлайн режиме, а потом мучайся и сравнивай какие файлы ты менял, а какие нет. Еще мелких проблем с ним куча, в целом не вижу преимущества перед SVN. Во-первых, и сервер надо будет разворачиваться с БД, ресурсы будет кушать нехило, а во-вторых, и в SVN нет ничего такого, что бы заставляло переходить на TFS.
Сейчас очень модными становятся распределенные системы хранения исходного кода (они не новые, они существуют очень давно, просто только недавно как-то про них больше говорить стали). Что ж, решил и я посмотреть на это чудо и вникнуть в то, а нужно ли мне это. Надо же быть в модном и современном течении, и более того может Git или Mercurial могут предоставить мне больше, чем дает мне SVN. Замечу, правда, что с SVN у меня и так не было никаких проблем дома. Недавно на хабре была хорошая статья Почему Git, в ней очень подробно описаны преимущества этой системы перед другими. Считайте, что Mercurial очень похож по идеологии. Что будет заметно перед тем как перейти с SVN: немного сложная работа с бранчами, то есть не та, которую рекомендуют в SVN, TFS. Там настоящие бранчи, можно сказать так: там не линейно друг за другом идут ревизии как в SVN, а они могут ветвиться, причем ветки можно объединять. Еще момент – у каждого локально находится свой полный репозиторий, который опять можно предоставить для других как серверный. Делать commit вы будете туда, а когда захотите уже будете делать push в основной. В общем, это реальная настоящая классная система хранения исходников. Только представить какие тут возможности. Берешь ноутбук и в офлайн режиме спокойно работаешь с репозиторием, ветвишь проект, делаешь commit’ы, а потом как будет доступ сделаешь push. Еще интересный вариант – одна из команд начинает работать с экспериментальным бранчем и чтобы не сорить: делаем именно для них отдельный репозиторий, который берет начало от основного, команда делает push’и туда, а уже потом, если все будет хорошо с этим бранчем, то и сделаем push в основной. Есть мелкие проблемы, вроде нет возможности залочить файл, а иногда это бывает нужно. Для каждого проекта нужно бы заводить отдельный репозиторий. Локально у тебя в рабочей копии будет полный набор, начиная с root папки, хранящейся в репозитории, то есть нельзя себе загрузить отдельную подпапку репозитория в рабочую копию. Вот это был один из существенных минусов, почему для дома использовать эту могучую вещь неудобно.
Я храню в репозитории всяческие тестовые проекты, проекты для блога, презентации выступлений, заготовки лекций, а так же диплом, кандидатскую, статьи. Понятное дело, что мне хочется иметь один репозиторий, я бы не хотел на каждую курсовую или статью заводить отдельный. Бранчи мне не так важны для домашних нужд. Бывает, конечно, случается. Я как-то сделал бранч для своей курсовой, правда, не помню зачем. Что-то, что попадает в хранилище, бывает мне уже и не нужно, просто хорошо, что оно где, то есть: не хочется, чтобы винтчестер забивался, и хотелось бы чтобы это хранилось только в репозитории и не мозолило глаза. Очевидно, что мне для дома более чем подходит SVN, притом еще подсказали про такой замечательный ресурс как assembla.com, где я смог завести свой private репозиторий для домашних нужд. Иногда делаю бекап на всякий случай.
В общем, я вот про что. Да Mercurial и Git сейчас очень модные штуки, но я даже не особо вижу смысла устанавливать его в компаниях, где пишется enterprise софт, бранчи у которых очень редки. По мне так, они полезны тогда, когда вы пишите один очень здоровый большой продукт, у которого много компонент, который часто ветвится, что сегодня вы выпустили версию 5.0, хотя уже месяц как разрабатывается версия 5.5, а особо умные уже давно все переписывают и делают версию 6.0. Все верно на #ADD2010 объяснил Стас Фомин, ставите SVN, а гики без проблем, если им так нравится, будут использовать Mercurial/Git. Все-таки для простых смертных Mercurial/Git оказываются сложнее, чем SVN. Хотя бы потому, что нормальных GUI для них нет, проще действительно запомнить в консоли все команды, чем разобраться в тех интерфейсах что предлагаются.