Редактирование на месте, контроль версий - каково ваше решение?

Question

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

Каков ваш подход к управлению файлами, которые в идеале не должны перемещаться / редактироваться и тестироваться на месте?

Чтобы быть более точным:Я бы хотел иметь эквивалент

• наличие защищенного от записи file.txt
• команда типа "co -l file.txt" (RCS), чтобы сделать ее доступной для редактирования
• возможность отредактировать его на месте и немедленно протестировать
• команда типа "ci -u file.txt" (RCS), чтобы записать изменение, добавить комментарий и снова сделать его доступным только для чтения
• другие пользователи также должны иметь возможность делать это в том же месте
• но информация о версии должна храниться в безопасном месте (предположительно, у представителя svn), на другом сервере

Answer 1

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

• Использование моментальных снимков для отката целых репозиториев, независимо от того, какого типа.Например, если я полностью испорчу дерево git, я могу использовать cp -dpfR ./@123456789 ./ , который заменяет мой рабочий репозиторий файлами точно такими, какими они были в эпоху 123456789.
• Использование управления версиями / snapshots в качестве собственного неизменяемого VCS, идеально подходящего для /etc и других вещей.Поскольку файлы в прошлом не могут быть удалены или изменены, каждый моментальный снимок представляет собой неизменяемую ревизию отдельного файла или всего дерева во времени.

Обычно я использую Git или Mercurial вместо Subversion, потому что предпочитаю распределенный VCS, но сейчас я настаиваю на том, чтобы хранить свои репозитории в FS с управлением версиями локально.

Я полагаю, что для пользователей Windows существуют некоторые переносимые реализации того же самого, полностью выполненные на python ...но на самом деле не уверен.

Answer 2

Как было сказано ранее, вы пытаетесь использовать SVN для чего-то, что должно использовать DVCS, например git или Mercurial.

У каждого может быть свой собственный репозиторий, а затем синхронизировать его с центральным репозиторием mais (например, SVN repo).

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

Единственное, чего я не понял, так это зачем вам нужны замки.Файл не обязательно должен быть доступен только для чтения.Вероятно, вы так думаете из-за того, как SVN выполняет слияния (вам почти всегда приходится делать это вручную).Git действительно творит чудеса [1], и большинство слияний происходит без вмешательства человека.

[1] Ладно, это не волшебство.В то время как SVN заботится о файлах, Git заботится о фрагментах кода.Таким образом, он может объединить файл, измененный дважды одновременно, до тех пор, пока вы не измените точно такой же фрагмент кода.

Answer 3

Современные распределенные системы контроля версий, такие как Git, Mercurial или Bazaar, являются лучшим инструментом в подобной ситуации.Не из-за распределенного аспекта (который здесь явно не имеет решающего значения), а потому, что создать репозиторий на месте чрезвычайно легко.

В Mercurial вам просто нужно сделать:

cd ~/directory
hg init

С Git это аналогично:

cd ~/directory
git init
git add .

Каждая рабочая копия представляет собой полноценный репозиторий, и вы можете отправить ее на удаленный сервер в качестве резервной копии, если хотите.Более того, все данные репозитория хранятся в одном скрытом каталоге, так что вы избегаете проблемы с множеством .svn каталоги повсюду.

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

Answer 4

Вы должны понимать, что репозитории SVN бесплатны.Вы можете создать столько, сколько захотите.

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

Также не представляется разумным иметь рабочую копию репозитория везде, где есть файлы для размещения управление SVN

Я не уверен, что вы на самом деле пытаетесь сделать, но у меня сложилось впечатление, что вы используете SVN особым образом.