19 июля 2008 в 20:18

Совместная разработка с помощью Subversion перевод

Управлять наёмными рабочими и распределенными проектами — это просто и весело. Стоп, что за чушь? На помощь приходит хороший контроль версий — именно то, что вам нужно, чтобы правильно вести ваши проекты.

Далее — перевод статьи Collaborate and Connect with Subversion. Это мой первый перевод, поэтому был бы очень рад вашим замечаниям.



Представьте, что у вас своя веб-студия. Быть может, это лишь вы и еще пара людей. Из-за столь небольшого состава вы часто прибегаете к помощи наёмных рабочих (субподрядчиков). Благодаря этому, вы можете браться за большее количество проектов, зарабатывать больше денег и аккуратно масштабировать свой бизнес. Однако управление даже небольшим количеством наёмных рабочих требует большого напряжения и сил. На определенном этапе вы столкнетесь с тем, что субподрядчик не выполняет свои обязанности в срок, не соблюдает ваши стандарты качества, или, что еще хуже, исчезает, так и не завершив работу. Вам могут помочь тщательные проверки данных, твердые соглашения и активный менеджмент. А технологии, в свою очередь, могут улучшить совместную деятельность для того, чтобы ваши проекты всегда были под контролем. Встречайте — Subversion.

Subversion создает благоприятные условия для совместной работы



Subversion (SVN) — это система контроля версий, которая позволяет хранить и следить за изменениями вашего кода, совместно использовать файлы проекта и предоставлять к ним доступ. Это очень просто. Вы пишете код и отправляете (commit) его в ваш SVN-репозиторий (место, в котором хранятся файлы проекта). Участники вашей команды могут скачать эти файлы, посмотреть, что вы сделали, внести свои изменения и затем, снова отправить эти изменения SVN-репозиторию. Каждый такой «commit» считается ревизией. SVN отслеживает эти ревизии и присваивает им номера, так что вы всегда можете «откатиться» к предыдущей версии вашего кода.

Видимость — это хорошо



Благодаря Subversion, все участники вовлечены в проект: как только кто-то вносит изменения, остальные сразу могут их увидеть (см. ниже Необходимые инструменты). Если у вас надежные субподрядчики, вы не будете лишний раз волноваться. Однако, при работе с непроверенными людьми, такая видимость позволяет избежать всех разногласий, проблем в проекте и ошибок в коде до того, как настанет время принимать работу.

Пусть SVN будет обязательным



Если субподрядчики действительно хотят сотрудничать с вашей студией, заставьте их следовать вашему рабочему процессу и использовать те же средства. Различия могут серьезно затруднять деятельность небольших компаний, особенно компаний по работе с клиентами.

Некоторые наёмные рабочие, быть может, захотят отправить вам результаты работы. zip-файлом по почте или выложить их на удаленном сервере, чтобы вы скачали и посмотрели. Это, конечно, хороший способ, но так принадлежащий вам код находится за пределами вашей организации. Фактически, вы теряете контроль над проектом. Каково же решение? Сделайте SVN частью вашего рабочего процесса. Помимо обычных преимуществ, вроде версионности и одновременной работы множества людей над проектом, SVN заставляет ваших субподрядчиков быть более ответственными, а также позволяет держать код и файлы для ваших клиентов под контролем и в вашей собственности.

Поскольку вы — наниматель, вы имеете полное право оговорить правила сдачи, используемые средства, а также когда и как работа должна быть сделана. Ваши субподрядчики оценят серьезный рабочий процесс и будут более ясно осознавать, что действуют вместе с вами.

Есть ли исключения из этого правила?



Процесс не должен быть применен только потому, что это процесс. В зависимости от уровня ответственности наёмного рабочего, вы можете решить не включать его в ваш SVN. А когда это сделать — вы увидите сами.

Установите ожидания



Каждый использует Subversion по-разному. Кто-то любит отправлять изменения проекта по несколько раз за день. Другие же предпочитают работать над проектами и отправлять изменения в конце рабочего дня. Многое зависит от типа проекта, над которым вы работаете, а также от количества людей, работающих над одним и тем же кодом. Я обнаружил, что чем ближе завершение проекта, тем больше изменений, происходящих в течение короткого периода времени. На этом этапе я отправляю изменения в SVN чаще.

Установите, насколько часто вы ожидаете обновлений от ваших наёмных работников. Я рекомендую не менее одного раза в день, пока они работают над проектом.

Плюсы и минусы



Мы ведь не просто получаем больше управления в свои руки? Конечно. Теперь вы можете оценивать качество и количество выполняемой субподрядчиками работы за определенное время. Вы способны быстро оценивать продуктивность ваших наёмных рабочих, и им это тоже полезно — вам не нужно приставать к ним с просьбами закончить работу, пока вы работаете вместе.

Субподрядчики могут беспокоиться, что при таком порядке им не заплатят за работу. Ведь, действительно, если у вас последняя версия их исходных кодов, что мешает вам присвоить себе работу, не заплатив при этом. Subversion, сама по себе, не разрешает данную ситуацию, хотя мошенничество может иметь место при любой другой организации рабочего процесса. Убедитесь, что в вашем контракте четко описаны правила сдачи и порядок оплаты работы. В интернете полно ресурсов, где вы можете узнать, как правильно составлять контракт, чтобы полностью защитить себя. Если вы все еще работаете с субподрядчиками без контракта, вам впору задуматься о том, все ли правильно вы делаете.

Необходимые инструменты



Чтобы начать пользоваться SVN и понять её основы, прочтите статью «I Wonder What This Button Does» автора Mike West. Ещё один хороший и бесплатный ресурс — O’Reilly «Version Control with Subversion». Не забудьте прочитать хороший обзор по работе с SVN в главе Фундаментальные понятия.

SVN, сама по себе, может быть сложной при попытках управлять пользователями с различными правами доступа. К примеру, вы наверняка захотите, чтобы ваш субподрядчик имел доступ только к тому проекту, над которым он работает, а не ко всему репозиторию. Для упрощения работы с репозиторием и управлением пользователями я рекомендую Warehouse, веб-интерфейс к Subversion от Active Reload. Warehouse позволяет вам легко управлять репозиторием, следить за изменениями, и, самое важное, добавлять пользователей и устанавливать им права доступа. Управление пользователями в SVN может быть довольно утомительным, но, благодаря данному интерфейсу, вы можете легко добавлять и удалять их. Он также предоставляет RSS-ленту с изменениями репозитория, которая позволит вам и вашей команде отслеживать файлы, над которыми ведется работа в данный момент, а также все изменения, происходящие в системе. Существуют также решения, использующие свой хостинг, например, Beanstalk. Они будут располагать у себя ваш SVN-репозиторий и предоставлять пользовательский интерфейс к нему.

Хотя я настоятельно призываю людей сначала научиться пользоваться SVN из командной строки, вы также можете попробовать новое приложение под Mac OS X — Versions (в настоящее время в бета-версии). Оно предоставляет графический интерфейс к большинству команд SVN.

Встраивание в текущую работу



Добавление Subversion в ваш текущий рабочий процесс не должно происходить со скрежетом. При наличии определенных навыков, можно соединить SVN с вашими инструментами управления проектами. Существуют так называемые «события репозитория», при возникновении которых, SVN позволяет запускать любые ваши скрипты. Например, скрипт, который будет писать новое сообщение в приложение-чат Campfire от 37Signals каждый раз, когда вы отправляете изменения в SVN-репозиторий. Таким образом, вы оповещаете ваших сотрудников о сделанных вами изменениях. С помощью Google, вы найдете множество других скриптов, написанных под различные инструменты, включая интеграцию средства управления проектами Basecamp с SVN.

Существует несколько различных типов встраивания SVN, но, всё же, наиболее распространен тот, что запускает скрипт после успешной отправки изменений репозиторию. Благодаря таким скриптам, возможности по совместному использованию SVN и ваших привычных рабочих средств практически неограниченны.

Хватит читать, пора действовать



Subversion — это не только отличное средство для версионности и контроля кода ваших проектов, оно также позволяет контролировать и улучшать взаимодействие между вами, вашими сотрудниками и наёмными рабочими. Пора немного улучшить жизнь себе, своей компании и своим субподрядчикам — начните применять SVN в своей работе уже сейчас.

Оригинал статьи — Collaborate and Connect with Subversion.
Translated with the permission of A List Apart Magazine and the author[s].
Перевод: Ryan Irelan
Золотов Никита @nik
карма
13,1
рейтинг 0,0
Похожие публикации
Самое читаемое Управление

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

  • +8
    хорошая статья, особенно для новичков в сабвёржне
  • 0
    Наверное правильнее было бы разместить эту статью в блоге "Разработка".
    • 0
      Все-таки статья больше посвящена организации процесса, чем самому процессу.
      • 0
        Процесс - это положения: какую систему контроля версий использовать в проекте, порядок получения прав к VCS, порядок бренчевания и мерджинга.

        Ответ на вопрос, что позволяет делать тот или иной инструмент, к процессу отношения не имеет.
        • 0
          Все таки останусь при своём мнении насчет расположения топика, да и на ALA он имеет теги Business, Project Management and Workflow.
          • +2
            Проблема в том, что Subversion вообще не нужен руководителям проектов, не связанных с разработкой кода (дизайн, строительство, маркетинг). Он нужен разработчикам, и лишь иногда некоторым менеджерам.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Да, и помоему в документации на русском даже о возвышенном написано больше и ярче :) Да простит меня переводчик...
      • +2
        Прощаю :)
  • 0
    Versions, конечно, зачетная штука. Еше и с репозиторием
  • +4
    ИМХО - ни о чём....
    почему-то западные "специалисты" любят разводить такой трёп.
    Перевод хороший, но лучше заниматься переводом мануалов чем такой ерунды.
    • +2
      Полностью с вами согласен, в последнее время хорошие статьи отыскать становится все труднее. Текст выбрал практически наобум, для пробы в переводе. Но надеюсь, кому-то может быть полезен.
    • 0
      Пожалуй, соглашусь. Очень много воды и очень мало по существу. Текст вправе претендовать на вступление к статье, но на саму статью, при всем уважении к автору и переводчику, ну никак не тянет.
  • +2
    Интересная тема. Как раз сейчас разбираюсь с этим делом.
    Хотелось бы более подробного описания использования инструментов для решения задач.

    И по самой статье насчет ожиданий:
    Я считаю, что коммиты должны быть не "каждый час" или "после каждых 100 строк код", а логически целостными: то есть решил какую-то задачу (пусть даже исправил важную ошибку всего в одной строке) — закоммить и прокомментрируй что сделал. В этом случае процесс разработки будет представлять собой последовательность целостных шагов. В последствии может оказаться так, что какие-то шаги были ошибочными, их можно будет откатить. А если коммит делался абы когда зато по графику, чтобы показать активную работу, то шаги и откаты будут бредовые.
    Ну и считается полезным коммитить к конце рабочего дня. Из тех же соображений, что элементарная задача не должна занимать больше 8 часов.
    • 0
      В конце рабочего дня коммитить надо, потому что кто-то может раньше прийти на работу завтра, в выходной выйти поработать из дома или клиент захочет последние изменения посмотреть или еще что-то. Вряд ли тут зависит от времени выполнения задачи.
      • 0
        Угу. Просто хочется, чтобы коммит в первую очередь был осмысленным. Т.к. наврядли половинчатые изменения кому-нибудь помогут. Скорее еще больше запутают.
      • +4
        пришел кто-то завтра пораньше на работу - а код не компилится, потому что задачу я не доделал, зато все коммитнул.
    • +2
      Правильно говорите. Коммит всегда должен закрывать какой-то таск. Т.е. лучше когда в репозитории рабочая версия, которая по крайне мере компилируется. Чтобы в любой момент, любой участник проекта, мог получить и собрать версию. Также есть такое понятие, как continues builds, т.е. билд сервер проверяет check-in'ы и строит очередную версию. Далее на эту версию запускаются юнит тесты. Мы правда работаем под MS Team System, но суть не меняется.
      • 0
        У нас примерно так же сделано. У каждого своя рабочая версия, после решения очередно задачи коммит на сервер. В итоге trunk хоть как-то, но работоспособен. Снижается риск, что у других разработчиков после апдейта все поломается.
    • 0
      если пользоватся Гитом а не Сабвершином - то проблема слишком длинных таском решается отдельным бранчем, в который делаются коммиты, и который впоследствии сливается с основным репозиторием.
      • 0
        Вообще-то эта проблема точно так же решается даже если пользоваться сабвершеном.
        • 0
          по сути да... в жизни же я редко видел когда бы люди делали бранчи в сабвершине - разве что для очень длительных сторонних разработок... в гите же все для этого предназначено
          • 0
            У меня сложилось впечатление, что люди боятся делать бранчи потому, что думают, что это долго/накладно.
            • 0
              так все и есть, зато в гите - все заточено под бранчи да слияния - там сама система настаивает на них, и словно направляет разработчиков на правильный путь )
          • 0
            Вы удивитесь...
            Когда мне потребовалось внести большие изменения в проект (в котором я единственный разработчик) я сделал отдельную ветку, все сделал, протестил и потом слил с основной.
            Вопрос: нафига такие мучения?
            Во-первых, это оказалось совсем несложно - merge и все ок.
            Во-вторых, изменения заняли порядком времени, параллельно в основной ветке я решал основные рабочие задачи (которые нужно было сделать к определенному сроку). Если бы я делал все одновременно, то получил бы жуткую кашу в проекте и проблемы с работоспособностью в переходный период.
            • 0
              вы круты. а мне вот в свн как-то в лом бранчить од.. как вспомню все что этому сопутствует... ну не предназначен свн для быстрых и удобных бранчей и слияний
              • 0
                STALKER разрабатывали как раз с использованием SVN. Жаль они не могут высказать свое мнение по этому поводу основанное на практике
              • 0
                Честно говоря, я это тоже 1 раз использовал, когда был риск поломать проект.
                Но все же мне не показалось это настолько сложным: вначале copy, а потом merge. Или у вас возникали конфликты при слиянии веток? В этом плане у меня ситуация проще.
                • 0
                  когда над кодом работает команда, то конфликты всегда возникают...
                  • 0
                    А когда команда пользуется Git'ом, конфликты что-ли не возникают?
              • +1
                А я вот не понимаю, хоть убей, что там может быть "в лом". Сделать бранч - одна(!) команда. Слить - тоже одна команда. А вот если накосячить в единственной разрабатываемой ветке - вот это да, это будет геморрой конкретный.
                • 0
                  влом сливать в финале и резловить все конфликты, да еще и постоянно апдейтить содержимое моего бранча к основному коду.

                  я умом вроде понимаю что ничего тут страшного нет, и что это хорошо и правильно. Наверное просто был отрицательный опыт который не хочется повторять.
                  • 0
                    влом сливать в финале и резловить все конфликты, да еще и постоянно апдейтить содержимое моего бранча к основному коду.
                    Если вы будете постоянно мержить транк в свой бранч, то конфликтов при мерже бранча назад в транк у вас быть не должно.
                    • 0
                      Это не всегда возможно. Например, при рефакторинге,
                      когда меняются интерфейсы\слои.
                • +2
                  вы несколько упрощаете. Сделать бранч действительно одна команда, а вот мерджить до версии 1.5 было не настолько просто, особенно если ветка развивается в паралель тому, на что вы мерджите и вы делаете эти слияния постоянно. Да и в 1.5 до того как мердж завершен, надо немало работы контрольной проделать. Обычно делается dry-run, потом смотрится собственно diff, делается собственно слияние, резолвятся конфликты (если возникли) а уж потом все это дело коммитится. И как я вижу наблюдая окружающих меня программеров, многим все это кажется слишком хлопотно, хотя я сам приверженец всей этой магии :)
    • 0
      Раз уж вы интересуетесь как раз сейчас, может быть вам поможет статья со сравнением существующих систем контроля версий
      http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
  • 0
    SVN надо пользоваться в команде, без него никак, поэтому если решились взяться за него, то все здесь:
    http://www.collab.net/downloads/subversi… - сервер и консольный клиент
    http://tortoisesvn.tigris.org/ - визуальный клиент под винду
    А также многие IDE поддерживают работу с сервером.
    • +1
      VCS стОит пользоваться, даже если вы — маньяк-одиночка.
  • 0
    А можно в двух словах, что дает Warehouse ?
    Я как раз подбираю средство для удобного просмотра репозитария и упрвления багами. Пока хочу попробовать Trac.

    По описанию очень похожий инструмент. В чем его преимущество?
    • 0
      Советую посмотреть на redmine (redmine.org) - отличная интеграция с Subversion. В нём намного проще управлять пользователями.
      • 0
        Спасибо. Симпатичная вещь и вроде как лучше русифицирован.
        Понравилось наличие календаря и встроенного Ганта, только последний показался крайне сложным в поддержании адекватной структуры задач.
        А какие еще аналоги знаете, чтобы можно было сравнить и подобрать для себя оптимум?
        • 0
          А что собственно вам надо - просмотр репозитария или управление багами ? ;)

          Мы используем в качестве багтрекера Atlassian JIRA. Очень, очень навороченный продукт
          (легко настраиваемый впрочем).
          Есть интеграция с SVN - можно в коммитах забивать номера карточек
          и собственно в карточках просматривать чего там девелоперы накоммитили.
          Посмотрите, триал-версия полностью функциональна и разворачивается на раз.
  • +1
    А мне казалось, что каждый хабрачеловек уже знает, что такое сабвершан и использует ее. Наверное нет особого смысла давать здесь такие общие описания столь известных и популярных систем.
    • 0
      Я только год работаю в этой сфере (программирование)и, к сожаленью, еще не использовал( Сейчас уже примерно месяц думаю начать, но не знаю с чего. Я был бы очень рад, если бы кто-нибудь написал статью о начале работы с SVN (что установить, как использовать). Если кому-нибудь не сложно - напишите.
      • 0
        Об этом уже давно написано. Почитайте svnbook, она даже на русский переведена (правда для версии 1.4, но в вашем случае это не так уж важно).
        • 0
          Спасибо)
      • 0
        • 0
          Спасибо большое.
  • 0
    Предложил бы еще один полезный инструмент — скрипт post-commit, рассылающий уведомления по всем задействованным в проекте с подробной информацией кто, зачем внес изменения + diff. Таким образом все в курсе последних изменений в проекте, ну и менеджер видит как продвигается работа :)
  • +1
    расскажи, как убедить разработчиков писать развернутые комментарии к чекинам :)
    • 0
      Попросите их рассказать новому разработчику про коммиты :)
      На самом деле написать подробный комментарий требует на 1 минуту больше, а вспомнить через полгода зачем ты это сделал - минут 15 :)
    • +2
      Поставьте pre-commit hook, который проверяет длину комментария :) Ну или просто бейте по рукам тех, кто ленится писать подробно.
      • 0
        Отличная идея, спасибо.
    • 0
      Развернутый комментарий не обязателен, часто достаточно привязки к логу задачи в таск-трекере (если компания больше 10 человек, таск-трекер должен быть).
      Т.е. не требовать развернутого комментария в момент коммита, пусть пишет «Task 1235» (а это проверяется регэкспом хук-скрипта на pre-commit), а суть изменений фиксирует в логе задачи. Тогда становится легко по каждой задаче вытащить список ревизий и даже патч.
  • 0
    а мне при слове "распределенной" сразу же мерещится Git
    • 0
      А как насчет Bazaar? :)
      • 0
        А как насчет Mercurial? :)
        • 0
          Дык не используем... пока SVN хвататет.
          Но надо понять в чем его кардинальные преимущества лично для нас.
          • 0
            Значит, работает — не трогай =)
  • –1
    К сожалению до сих пор очень мало IDE под Windows поддерживают SVN(а то и CVS даже нет). Приходится работать через программы типа tortoisesvn. А это иногда не удобно.

    Эх.. ещё бы сделали что-нибудь подобное для БД....
    • 0
      Работайте с SVN через командную строку. Там графика ни к чему совершенно.
      • 0
        Вся суть в удобстве
        • 0
          Можете привести пример?
          • 0
            Eclipse SDK. Очень удобно работает с SVN
          • 0
            Для VisualStudio есть SVNклиент.
          • 0
            Могу. Ihmo diff-ать удобнее НЕ из командной строки ;)
            Мержить в ручном режиме тоже.
          • 0
            В Eclipse например очень удобно смотреть диффы, ну и видно сразу в дереве, какой файл в каком состоянии.
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Наверное, если ваша IDE все еще не научилась SVN, ее надо сменить на что-то современное. Практически все современные IDE могут работать с SVN как минимум после установки плагина.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Как запущен svnserve? standalone или через inetd? не пытается ли svnserve резольвить IP-адреса клиентов? У вас настроена локальная DNS-зона?
      • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Спасибо за статью! Очень полезный инструмент в хозяйстве.
  • 0
    Кстати, сомневающимся очень рекомендую попробовать http://www.assembla.com. Там в свободное пользование можно получить готовый к работе SVN репозиторий + Track + вики + систему нотификаций — готовая площадка для ведения проекта небольшого-среднего размера.
    • 0
      Еще есть довольно симпатичный Acunote с весьма либеральными ценами.
  • 0
    А чё так отстаём. Почему об устаревшей SVN, а не о распределённых системах контроля версий (Git, Mercurial, Bazaar)?
    • 0
      распределённые системы - это тоже не панацея, мало того использование таких систем контроля версий, к примеру, усложняет возможность continuous integration
    • 0
      Ну кому-то интересует, почему SVN уже никогда не устареет, и чем она будет лучше любой распределенной системы контроля версий, то см. серию статей (переводов) на эту тему.
  • +1
    SVN интересная вещ для начинающих разработчиков и просто программистов. У Вас есть обзор инструментов для простого поднятия сервера под CentOS или Win?
  • 0
    SVN это вещь дико необходимоя, уже не представляю разрабодку без нее...
    Единственное что не удаеться решить с ее помощью - это синхронизацыю бд между разработчиками. Писать в комментариях при коммитах sql-запросы всеже не очень удобно.
    Может есть у кого опыт решения подобной проблеммы?
    • +1
      Можно модель базы хранить в репозитории и при коммитах указывать ревижн модели базы, который необходимо применить на данный ревижн.

      Можно вести историю изменений базы в SQL-скриптах и в коммитах кода давать номера ревижнов, которые надо применить.
      Это скорее не технологическая а административная проблема :)
    • 0
      Ruby On Rails, например, решают эту проблему с помощью Migrations. Но почему-то эта практика не получила распространения в других фреймворках :)

      Как вариант: складываем скриптики для изменения базы в отдельную папку. Каждое изменение — в свой скрипт под номером.
    • 0
      Для PostgreSQL есть отличная тулза - apgdiff.
      Умеет сравнивать структуры двух баз по дампам и выдавать «патч» — sql-скрипт, применив который, вы приведете базу к нужной структуре.

      Если бы еще прикрутить ее ввиду плагина к SVN, чтобы можно было получать такие патчики.
      • 0
        Опыт использования подобных инструментов для Oracle - весьма отрицательный
        для баз со сложной структурой (~1000 таблиц,~500 вьюх и огромное количество API-шных пакетов).

        Причём, зачастую приходится отслеживать не только структуры - но и сами данные
        (метаинфа, классификаторы и справочники).
        В таких случаях спасает только внесение изменений базы в отдельную ветку репозитория(SQL-скрипты с изменениями относительно пустой модели данных или же дампы)
    • +1
      Есть замечательная программа EMS Database Comparer http://www.sqlmanager.net/en/products
      В наличии версии для MySQL, SQL Server, PostgreSQL, InterBase/Firebird, Oracle и DB2
      Выводит все различия между базами и сразу предлагает изменения в виде sql-запросов.
      • 0
        Все, советующие всякого рода дбкомпареры - ответьте пожалуйста на один простой вопрос:
        Как вы предлагаете использовать эти утилиты в случае если база-источник изменений в одном городе
        а базы-потребители - в других? ;)
        • 0
          Расположение баз не имеет значения. Программа может подключаться удаленно по SSH.
          • 0
            ммм.
            Imho какой то сомнительный способ синхронизации баз для использования
            в качестве решения.
            Как разовый вариант - не спорю, полезная фича.

            И, сия тулза сравнивает структуры или может и данные сравнивать?
            • 0
              Только структуру.
              Как вариант, я думаю, можно настроить репликацию.
              • 0
                Не вариант вообще.
                Слишком много телодвижений и, как следствие,
                бардак. Проще всё же не "тулзы" использовать
                а написать регламент по порядку внесения изменений
                в БД и следовать ему,
                выкладывая изменяющей стороной дампы И/ИЛИ SQL-скрипты,
                актуализующие состояние БД.
  • 0
    уже давно практикуем trac+subversion, даже менеджеры могут узнать о текущих планах :)
  • 0
    Разве слово control, в данном случае, не уместнее переводить как "управление"?
    Система управления версиями. При чём тут "контроль"?
    • 0
      Вообще, принципиальной разницы нет, хотя в википедии используется именно «управление». Но и «контроль» тоже часто употребляется.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.