Опыт локального контроля версий рабочей копии SVN?

Question

На моем рабочем месте мы используем SVN и TortoiseSVN (Windows XP) в качестве клиента. Во время этого у меня долгая поездка и работа в автономном режиме.
Теперь я хотел бы иметь какую-то "расширенную отмену" локально; то есть я хотел бы иметь локальный контроль версий моей рабочей копии SVN, чтобы решиться, например, на рефакторинг.
Переключение в целом, например, Git, Mercurial и т. д. не вариант, так как компания использует SVN.

Что я хотел бы знать, есть ли у кого-то опыт создания версий рабочей копии SVN, возможно, при запуске локального git или чего-то подобного? Есть ли потенциальные недостатки? (возможно возиться с папками .svn или аналогичными)

Answer 1

Я использую Git в качестве локального клиента Subversion для работы, и он прекрасно работает. Когда вы делаете git svn clone хранилища Subversion, получаемый вами извлечение не имеет скрытых каталогов .svn, но вместо этого представляет собой полный Git-репозиторий. Возможность использовать локальные, легкие ветки для организации собственной разработки является для меня убийственной особенностью.

Другие функции, которые я использую постоянно: git stash, поэтапные коммиты и git add -p.

Answer 2

Вы можете попробовать SVK , который децентрализован VCS на основе Subversion. Его можно использовать для зеркалирования официального репозитория на вашем ноутбуке и синхронизации ваших коммитов с официальным транком.

Answer 3

Я обычно так делаю:

1. Получить репозиторий SVN в качестве рабочей копии.
2. Инициализировать Git-репозиторий в этой рабочей копии.
3. Взломать взломать взломать;
4. Передайте мое Git-репо.
5. Обновление от компании SVN.
6. Разрешение конфликтов.
7. Предоставьте компании SVN репо полную функцию.

Answer 4

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

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

Это немного грубо, но это единственный способ управлять этим типом рабочего процесса.

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

Answer 5

Git будет хорошим решением (потому что вы можете создавать и объединять множество веток очень легко), но:

• при повторном импорте вашей модификации в svn, вы должны сначала очистить многие промежуточные ветви, которые вы создали в git;
• git-svn не работает с дистрибутивом Windows Git, поэтому вы можете использовать виртуальный образ Linux, если вы работаете в Windows
• Если вы можете запустить git-svn, используйте сценарии git2svn et svn2git ruby, как описано в этот вопрос

Answer 6

Ничто не мешает запускать локальный сервер SVN. Я использую это таким образом.

Answer 7

В прошлый раз, когда я проверял статус SVN, локальная поддержка регистрации все еще была долгосрочным планом обслуживания. Git, с другой стороны, это определенно вариант с git-svn. То есть, если ваша архитектура Unix, AFAIK, git-svn еще не поддерживается на платформе Windows.