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

Я видел, что контроль версий используется для других целей, не связанных с исходным кодом, например,

1. Файлы схемы-набор файлов схемы XML, которые представляют реальную схему мира
2. Файлы содержимого-содержимое, представленное в определенном формате, это связано с конструктором в VStudio, с использованием системы управления версиями, позволяет историю, откаты все, без взаимодействия с базой данных

В обоих случаях мы замечаем, что это в основном подробные файлы, основные причины иметь эти файлы в системе управления версиями, а не" текстовые записи в базе данных", заключается в том, что

1. файлы, которые могут нуждаться в возможности сравнения версий
2. история (потому что над ними работают несколько пользователей)
3. возможность отката к более ранней версии
4. маркировка и релизы путем получения определенной метки
5. если вы используете Team Foundation (TFS), все шаблоны scrum с рабочими элементами и т. д
6. без участия базы данных, без дополнительной разработки для всего вышеперечисленного

На одной из моих ранних работ мы использовали CVS для контроля версий DNS. Это был в основном дешевый и грязный способ резервного копирования файлов зоны.

Я также слышал о людях, использующих систему управления версиями для своих домашних каталогов.

Во время моего последнего семестра в школе я взял два класса, каждый из которых имел большой, трудоемкий проект, подлежащий в конце семестра. Они оба также требовали несколько длинных статей в течение семестра. Я активно использовал SVN для обоих классов, чтобы отслеживать каждое изменение, которое я сделал в каждой статье и проекте.

Я больше похож на парня "write it all at once", когда дело доходит до написания, и, как правило, теряю ход своих мыслей, если я пытаюсь распространить процесс на несколько сеансов. Будучи в состоянии diff последние редакции моих документов сделал его гораздо легче для меня, чтобы вернуться на правильный путь.

Я редактирую много документов в LaTeX, поэтому я использую SVN для хранения файлов tex и изображений и так далее. Удобно для выполнения диффов, и, надеюсь, спасет меня, если у меня будет катастрофа.

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

У меня есть папка в пути под названием bin с полезными утилитами, такими как Sysinternals и другие. Я использую svn, чтобы держать их в актуальном состоянии на разных машинах. Кроме того, такие вещи, как скрипты powershell, файлы vimrc и т. д. отлично подходят для централизованного хранения.

Я никогда даже не думал использовать его для личных вещей, но в программных проектах я проверяю почти все, что не может быть восстановлено позже (примеры этого включают исполняемые файлы и созданные с помощью кода документы). Документация всегда проверяется. Презентации для клиентов регистрируются и помечаются вместе с базой кода, используемой для демонстрации, если была демонстрация.

Я думаю, что SVN и CVS недостаточно "friendly" для нетехнических пользователей, но теперь мне любопытно, как можно использовать контроль версий для неинженерных проектов...

Большинство документов, которые будут просмотрены более чем одной парой человеческих глаз. Это невероятно полезно, например, на этапах планирования проекта, когда аналитик обновляет документ требований, и вы хотите увидеть, что изменилось с момента его последнего просмотра. Вики тоже есть эта функция, естественно. Мы используем SharePoint для этих целей, но выбираем вашего поставщика.

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

Новый сеанс в любом из них начинается со скрипта под названием 'start', который обновляет кучу проверок, и заканчивается скриптом под названием 'stop', который фиксирует некоторые вещи в VCS или показывает мне, по крайней мере, изменения.

Я использую его для:

• мой список задач с одним файлом Getting Things Done (см. yagtd, инструмент, который я использую)
• моя база паролей (я должен был отправить это предложение в подкаст StackOverflow в ответ на вопрос Джоэла)
• все мои случайные заметки и файлы по проектам
• куча электронных таблиц (в том числе одна, которая отслеживает некоторые личные вещи изо дня в день)
• некоторые изображения (например, веб-аватары, которые я использую)

Кроме того, я написал что-то на вершине Subversion для управления файлами конфигурации для обеих систем и моих учетных записей пользователей. У меня так много учетных записей на стольких машинах,и я устал всегда переучивать, как настроить мой shell/vim/..., поэтому теперь я храню большинство этих вещей в системе управления версиями. Это включает в себя файлы сигнатур email, кучу скриптов shell в $HOME/bin, ...

Я использую контроль версий практически для всех Моих документов для любых целей.

Я использую Mercurial, поэтому настройка нового репозитория в данном каталоге - это вопрос простого "HG init", который я нашел гораздо меньше хлопот, чем настройка нового репозитория Subversion.

Я также обнаружил, что RCS отлично подходит в любой ситуации, когда вам нужно синхронизировать файлы - я использую это сейчас вместо rsync для всех моих потребностей в синхронизации. Также проще создавать резервные копии-клонирование репозитория в другой location/machine/disk означает, что я могу просто переместить изменения в это местоположение, что еще проще с помощью репозитория push по умолчанию. Если вы не изменяете в удаленном РЕПО, то вам даже не нужно слишком беспокоиться о настройке этого, кроме значения по умолчанию.

Одна из самых приятных вещей для меня-это то, что я могу синхронизировать, создавать резервные копии или что-то еще в любой системе, к которой у меня есть доступ SSH. (Ну, если бы они установили mercurial для меня в Uni, тогда я мог бы!)

В моей компании Группа разработчиков стремится использовать Subversion практически для каждого электронного документа. Это зависит от возможности "lock" файлов, которые не могут быть объединены, например Excel документов. SVN предоставляет функцию "requires-lock", а рабочий процесс get-lock, modify, commit достаточно прост.

Инженеры-программисты находятся на борту, но есть некоторое сопротивление со стороны инженеров-механиков. Например, они хотят использовать функции одновременного совместного редактирования Excel. Они не приспособлены к вам-блокировка, изменение, фиксация рабочих процессов.

TortoiseSVN позволяет вам diff Word docs, которые я нахожу чрезвычайно полезными. Он также поддерживает слияние, по-видимому, хотя я был слишком куриным, чтобы попробовать эту функцию...

Я бы хотел серьезно рассмотреть DVCS, такие как git или Mercurial. Но если он не может блокировать двоичные файлы формата файла (т. е. не может объединяться) (таким образом, становясь более похожим на централизованную модель для таких файлов) и/или объединять двоичные форматы файлов, которые мы используем, он не будет вписываться в использование моей компании.

Я просто хочу, чтобы все программные компании предоставили хорошие инструменты diff и слияния для своих проприетарных форматов doc. Это повысило бы ценность систем контроля версий для проприетарных форматов doc.

Да, у меня есть каталог doc в git. Я содержит список задач, календарь и несколько других документов.

Я использую SVN для проверки изменений в файлах конфигурации сервера Asterisk VOIP. У меня есть один репозиторий с папкой, соответствующей каждому из нескольких серверов. Эта папка содержит все содержимое /etc/asterisk.

Я использовал Subversion для всего, начиная с системы управления версиями, сред сборки, сценариев установки и всего, что хорошо для разработки. Я также создал репозиторий для нетехнических пользователей для двоичных файлов, в данном случае старых документов Excel и Word. Это сработало хорошо, учитывая, что мы потеряли функциональность слияния. Но это позволило всем нашим пользователям получить целую тонну информации, которая в основном редактировалась двумя или тремя людьми довольно легко. И с простыми инструкциями о том, как обновить, прежде чем вы сделаете какое-либо редактирование (блокировка, если это необходимо), а затем разберетесь с конфликтами (проверьте, что вы обновили, а затем удалите свою копию и выполните обновление), они смогли справиться с репозиторием довольно хорошо, хотя я не уверен, что им это когда-либо нравилось. :)