Какая система контроля версий может управлять всеми аспектами? [закрыто]

17

Несколько месяцев назад я копался в Subversion и GIT и был разочарован. Они прекрасно справляются с SOURCE CODE, но не с другими аспектами. Например, веб-сайт под управлением версиями должен управлять владельцем файла / каталога, доступом к файлу / каталогу для чтения и записи, списками контроля доступа, временными метками, содержимым базы данных. и внешние ссылки. Существует ли система контроля версий, которая может выполнить возврат так же хорошо, как перезагрузка из резервной копии, созданной за месяц?

Энди Кэнфилд
источник
12
Выглядит так, как будто вы хотите создать резервную систему?
Мак
2
Рассматривали ли вы запуск вашего веб-сайта под OS X на Mac? Time Machine - это, пожалуй, самое простое решение для резервного копирования, доступное в настоящее время, которое позволяет легко выполнить откат при необходимости.
1
Если вы серьезно интересуетесь этой темой, вам следует взглянуть на исследования в области управления версиями файловых систем и баз данных управления версиями, которые выходят за рамки систем контроля версий для исходного кода.
Якоб
что плохого в написании небольшого количества сценариев для обработки таких вещей, которые scm не обрабатывает? таким образом вы получаете то, что хотите, и получаете контроль над источниками.
ньютопия

Ответы:

44

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

Система контроля версий сможет рассказать вам, как вы узнали, как сайт выглядел в прошлом месяце, и как он выглядит сегодня (по крайней мере, для тех компонентов, которые находятся под контролем исходного кода). Он должен включать в себя все необходимое для перестройки сайта (кроме динамического контента). Как уже отмечалось, любые изменения в разрешениях и владельцах должны быть записаны в сценарии, и этот сценарий включен в систему контроля версий.

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

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

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

РЕДАКТИРОВАТЬ:

Исправление, которое я использую: (а) совсем нет контроля версий, (б) рабочий сайт является главным сайтом, (в) архивировать каждый раз, когда что-либо меняется, (г) сценарий архивирования удаляет ненужные файлы, такие как ACL, и (д) Сценарий установки исправляет другие нежелательные файлы, такие как права доступа

Эти проблемы могут быть решены путем импорта сайта в систему контроля версий и изменения вашего процесса, чтобы главный сайт обновлялся через эту систему. (a), (b) и (c) обрабатываются непосредственно системой контроля версий. Вы можете пометить релизы, чтобы заставить (с) работать лучше. (d) обычно это не проблема, если система развертывания изменяет только ваш сайт. Я никогда не нуждался в ACL на контенте сайта.

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

Но почему никто не создал общую систему для этого?

Потому что это не нужно, если вы используете систему контроля версий.

Система контроля версий МОЖЕТ отслеживать все эти вещи, но никто не делает.

И CVS, и Subversion отслеживают, что вам нужно отслеживать, если вы их используете. Они не будут отслеживать то, что вам нужно отслеживать, потому что вы не используете систему контроля версий, и при этом они не должны. Они отслеживают то, что вам нужно отслеживать, когда вы используете систему контроля версий.

Я работал с несколькими сайтами, которые управляли своим контентом с помощью контроля версий. У всех были разные требования к промежуточным сайтам, частоте развертывания и полноте обновлений. Как только сайты были в управлении версиями, они соответствовали остальным требованиям. Документация для CVS и Subversion содержит предложения о возможных методах обновления.

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

BillThor
источник
+1 за уточнение причин, почему вопрос не верен с самого начала.
Мак
2
+1 Тем не менее, хорошо, что вопрос был задан, чтобы другие могли получить пользу от вашего ответа.
Оливер-Клэр
Система контроля версий должна дать мне возможность сказать: «Хорошо, на этом другом компьютере, создайте мне сайт с 28 июля». Контроль версий более эффективен, чем резервные копии, потому что он отслеживает изменения. В противном случае, да, ежедневное резервное копирование сделало бы работу хорошо.
Энди Кэнфилд
Да, исправление, которое я использую, это: (а) совсем нет управления версиями, (б) рабочий сайт является главным сайтом, (в) архивировать каждый раз, когда что-либо меняется, (г) сценарий архивирования удаляет ненужные файлы, такие как ACL, и ( e) скрипт установки исправляет другие нежелательные, такие как права доступа к файлам. Но почему никто не создал общую систему для этого? Система контроля версий МОЖЕТ отслеживать все эти вещи, но никто не делает.
Энди Кэнфилд
+1: отличный ответ. Однако я хотел бы добавить, что ни одна система контроля версий не отслеживает эти вещи, потому что они НЕ МОГУТ. Разрешения и имена пользователей зависят от хоста, а их формат зависит от системы; инструмент не может автоматически перенести их на другой хост, особенно если это другая операционная система.
Ян Худек
10

Все из них и ни один из них.

Это плохая идея, чтобы получить контроль над источниками, чтобы управлять этими деталями напрямую, в соответствии с вашим вопросом.

Однако вы можете написать сценарий bash (* nix) или сценарий powershell (Windows), который достигает любой или всех этих целей. Этот скрипт может быть сохранен в системе контроля версий.

Затем вы можете сделать этот сценарий одним из артефактов сборки и запустить его как часть развертывания.

прецизионный самописец
источник
Эта. Идея иметь источники вообще состоит в том, что вы можете извлечь их из вашей VCS и использовать их для создания готового продукта.
Blrfl
2

ИМХО, система контроля версий сама по себе не предназначена для такого использования.

Но я стараюсь убедиться, что вы можете получить версию из системы контроля версий, вам нужно всего лишь запустить один файл сборки / файл powershell, и все снова работает.

Для этого вам необходимо:

  • все библиотеки, которые вы используете, зависят от контроля версий
  • файл сборки, который устанавливает вашу среду
  • инструкция о требованиях вашей среды (вы не хотите помещать SQL-сервер в ваш исходный код)
KeesDijk
источник
1

Я считаю, что вам нужно в вашем случае инструмент управления конфигурацией . Тот, который я использовал, это марионетка .

Цитирую вас:

управлять владением файлом / каталогом, доступом к файлу / каталогу для чтения и записи,

Я сделал это одной строкой (убедитесь, что пользователь существует, убедитесь, что каталог существует и т. Д.) ...

Списки контроля доступа,

Если это Windows ACL, то есть специальные инструменты CM для Windows ...

метки времени,

снова команда touch unix в одной строке скриптового сценария может сделать это за вас.

содержимое базы данных.

Это сборка во многих фреймворках, работа cron, которая гарантирует, что все будет иначе?

и внешние ссылки.

Ничего не знаю об этом.

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

Димитриос Мистриотис
источник
Я не понимаю, что вы подразумеваете под «временными метками - опять же одна команда unix в одной строке в скриптовом сценарии могла бы сделать это». На моем сайте, чтобы получить версию сайта, она сканирует все сайт и возвращает дату и время самого нового файла. Я хочу, чтобы контроль версий "Checkout" давал файлам ту же временную метку, что и при регистрации, а не "сейчас". Как вы делаете это в одной команде Unix?
Энди Кэнфилд
конечно, вы ищете "touch", проверьте это: en.wikipedia.org/wiki/Touch_(Unix) . Обычно при проверке применяется текущее время, но если по какой-то причине вам нужна другая временная метка, это как это сделать.
Димитриос Мистриотис
Мне действительно понравилось обоснование вашего вопроса: вы хотите как можно больше автоматизировать, что является «правильным путем», вам нужны некоторые ноу-хау о том, как это сделать, что идет в VControl, а что нет. Я хотел бы, чтобы больше людей в
нашей
0

Существует совершенная система контроля версий, которая управляет всеми аспектами всех цифровых документов. Он называется Xanadu и был создан Теодором Холмом Нельсоном в 1960 году, еще до того, как такие вещи, как файловые системы, стали обычным явлением. Так что в теории все отлично решено. На практике Xanadu никогда не был реализован так, как предполагал Нельсон, но он вдохновил многие более специализированные системы, включая веб-системы и системы контроля версий. Работы Нельсона все еще заслуживают нового прочтения - и они могут ответить на вопрос, почему не существует общего VCS, который управляет всеми аспектами.

Jakob
источник