Используете ли вы контроль версий, кроме как для исходного кода?
Я обнаружил, что SVN чрезвычайно полезен для документации, личных файлов и других видов использования, не связанных с исходным кодом. Какие еще практические применения вы нашли для систем контроля версий в целом?
14 ответов
Я видел, как управление версиями используется для других целей, не связанных с исходным кодом, например,
- Файлы схемы - набор файлов схемы XML, которые представляют реальную схему
- Файлы содержимого - содержимое, представленное в определенном формате, оно привязано к конструктору в VStudio с использованием контроля версий, разрешает историю, выполняет откат всего, без взаимодействия с базой данных
В обоих случаях мы замечаем, что это в основном подробные файлы, основные причины, по которым эти файлы находятся в системе контроля версий, а не "текстовые записи в базе данных", заключаются в том, что
- файлы, которым может потребоваться возможность сравнения версий
- история (потому что над ними работают несколько пользователей)
- возможность отката к более ранней версии
- маркировка и релизы путем получения конкретного ярлыка
- если вы используете Team Foundation (TFS), целые шаблоны Scrum с рабочими элементами и т. д.
- нет базы данных, нет дополнительной разработки для всего вышеперечисленного
В течение моего последнего семестра в школе я взял два класса, каждый из которых имел большой, трудоемкий проект, который должен был состояться в конце семестра. Им обоим также потребовалось несколько длинных работ в течение семестра. Я активно использовал SVN для обоих классов, чтобы отслеживать каждое изменение, которое я вносил в каждую статью и проект.
Я больше отношусь к типу "напиши все сразу", когда дело доходит до письма, и, как правило, теряю ход мыслей, если пытаюсь распределить процесс по нескольким сеансам. Возможность просматривать последние редакции моих работ значительно упростила мне процесс.
На одной из моих ранних работ мы использовали CVS для контроля версий DNS. В основном это был дешевый и грязный способ резервного копирования файлов зоны.
Я также слышал о людях, использующих систему контроля версий для своих домашних каталогов.
Я редактирую много документов в LaTeX, поэтому я использую SVN для хранения текстовых файлов и изображений и так далее. Удобно для выполнения Diffs и, надеюсь, спасет меня, если у меня будет катастрофа.
Обычно все, что нужно процессу сборки, я помещаю в систему контроля версий. Единственная проблема, которая возникает, - это если у вас есть ресурсы, подготовленные другими отделами, например, отделом маркетинга, которые входят в вашу установку, например.
У меня в папке есть папка bin с полезными утилитами, такими как sysinternals и другие. Я использую SVN, чтобы поддерживать их в актуальном состоянии на разных машинах. Кроме того, такие вещи, как сценарии powershell, файлы vimrc и т. Д., Отлично подходят для централизации.
Большая часть документации, которая будет просматриваться несколькими парами человеческих глаз. Это невероятно полезно, например, на этапах планирования проекта, когда аналитик обновляет документ с требованиями, и вы хотели бы увидеть, что изменилось с момента его последнего просмотра. Вики также имеют эту функциональность, естественно. Мы используем SharePoint для этих целей, но выбираем вашего поставщика.
Я часто использую контроль версий для обычных файлов, потому что у меня есть один ноутбук, настольный компьютер на работе и домашний рабочий стол, на котором я тоже много работаю (я работаю дома два дня в неделю).
Новый сеанс в любом из них начинается со сценария "start", который обновляет кучу проверок, и заканчивается сценарием "stop", который фиксирует некоторые вещи в VCS или показывает мне, по крайней мере, изменения.
Я использую это для:
- мой однозадачный список задач Getting Things Done (см. yagtd, инструмент, который я использую)
- моя база паролей (я должен был отправить это предложение на подкаст Stackru в ответ на вопрос Джоэла)
- все мои случайные заметки и файлы по проектам
- куча электронных таблиц (в том числе та, которая отслеживает некоторые личные вещи изо дня в день)
- некоторые изображения (например, веб-аватары, которые я использую)
Кроме того, я написал кое-что поверх Subversion для управления файлами конфигурации для обеих систем и моих учетных записей пользователей. У меня так много учетных записей на стольких машинах, и я устал от переучивания, как настроить свою оболочку /vim/..., поэтому теперь я храню большинство этих вещей и в управлении версиями. Это включает в себя файлы подписи электронной почты, набор сценариев оболочки в $HOME/bin, ...
Я даже не думал использовать его для личных целей, но в программных проектах я проверяю практически все, что не может быть восстановлено позднее (примеры этого включают исполняемые файлы и документы, сгенерированные кодом). Документация всегда проверяется. Презентации для клиентов проверяются и помечаются вместе с кодовой базой, используемой для демонстрации, если была демонстрация.
Я думаю, что SVN и CVS не настолько "дружелюбны" для нетехнических пользователей, но мне любопытно, что еще можно использовать для контроля версий в неинженерных проектах...
Я использую контроль версий практически для всех своих документов в любых целях.
Я использую Mercurial, поэтому настройка нового репозитория в заданном каталоге - это вопрос простого hg init, который, как мне показалось, доставляет гораздо меньше хлопот, чем настройка нового репозитория Subversion.
Я также обнаружил, что RCS хорош в любой ситуации, когда вам нужно синхронизировать файлы - я использую это сейчас вместо rsync для всех моих потребностей синхронизации. Также проще создавать резервные копии - клонирование репозитория в другое место / машину / диск означает, что я могу просто перенести изменения в это место, что еще проще с использованием стандартного push-репозитория. Если вы не вносите изменения в удаленном репо, вам даже не нужно слишком беспокоиться о настройке, отличной от настройки по умолчанию.
Одна из самых приятных вещей для меня - это то, что у меня может быть синхронизация, резервное копирование или что-то еще в любой системе, к которой у меня есть доступ по SSH. (Ну, если бы они установили Mercurial для меня в Uni, тогда я мог бы!)
В моей компании группа разработчиков стремится использовать Subversion практически для каждого электронного документа. Это зависит от возможности "заблокировать" файлы, которые невозможно объединить, например документы Excel. SVN предоставляет функцию "require-lock", а рабочий процесс get-lock, modify, commit достаточно прост.
Инженеры-программисты на борту, но есть некоторое сопротивление со стороны инженеров-механиков. Например, они хотят использовать функции совместного редактирования в Excel. Они не адаптировались к рабочему процессу get-lock, edit, commit.
TortoiseSVN позволяет вам просматривать документы Word, что я считаю чрезвычайно полезным. Это также поддерживает слияние, по-видимому, хотя я был слишком куриным, чтобы попробовать эту функцию...
Я хотел бы серьезно рассмотреть DVCS, такие как git или Mercurial. Но если он не может блокировать файлы в двоичном формате (то есть, не могут быть объединены) (таким образом, становится более похожим на централизованную модель для таких файлов) и / или объединять используемые нами двоичные форматы файлов, он не будет вписываться в использование моей компании.
Я просто хотел бы, чтобы все компании-разработчики предоставили хорошие инструменты сравнения и слияния для своих проприетарных форматов документов. Это повысило бы ценность систем контроля версий для проприетарных форматов документов.
Я использую SVN для проверки изменений в конфигурационных файлах Asterisk VOIP Server. У меня есть один репозиторий с папкой, соответствующей каждому из нескольких серверов. Эта папка содержит все содержимое /etc/asterisk.
Да, у меня есть каталог документов в git. У меня есть список задач, календарь и несколько других документов.
Я использовал Subversion для всего: от управления исходным кодом, сред сборки, сценариев установщика и всего, что было в разработке. Я также создал хранилище для не технических пользователей для двоичных файлов, в данном случае старых документов Excel и Word. Это работало хорошо, учитывая, что мы потеряли функциональность слияния. Но это позволило всем нашим пользователям получить целую тонну информации, которая в основном редактировалась двумя или тремя людьми довольно легко. И с простыми инструкциями о том, как обновлять, прежде чем выполнять какое-либо редактирование (блокировка при необходимости), а затем иметь дело с конфликтами (проверьте, что вы обновили, а затем удалите свою копию и выполнить обновление), они смогли довольно хорошо справиться с вещами хранилища, хотя я не уверен, что им когда-нибудь это нравилось.:)