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

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

1 голос
/ 02 января 2009

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

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

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

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

Ответы [ 4 ]

3 голосов
/ 03 января 2009

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

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

Это фактически то, что я использую в своих собственных проектах.

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

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

3 голосов
/ 02 января 2009

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

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

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

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

2 голосов
/ 03 января 2009

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

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

cd ~/directory
hg init

С Git похож: 

cd ~/directory
git init
git add .

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

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

0 голосов
/ 02 января 2009

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

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

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

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

...