Недостатки использования GIT-SVN над другими клиентами SVN? - PullRequest
Новая
       3

Недостатки использования GIT-SVN над другими клиентами SVN?

4 голосов
/ 25 июля 2011

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

Но мне было интересно, есть линедостатки, которые я должен знать?

Ответы [ 4 ]

6 голосов
/ 25 июля 2011

Преимущества

Вот почему я нашел это ценным, хотя могут быть и другие причины для этого.

  • Нет необходимости в доступе к коммиту для проекта вЧтобы начать кодирование.
  • Может выполнять контроль версий на локальных машинах без доступа к коммитам или даже без подключения к Интернету.
  • Легче просматривать всю историю изменений (включая историю SVN.)
  • git-svn rebase в тысячу раз лучше, чем встроенные в SVN инструменты разрешения конфликтов.
  • Вы по-прежнему получаете ограниченную выгоду от улучшенной механики ветвления в Git.

Недостаток

Главный серьезный недостаток: не выполняйте никаких операций merge, иначе SVN будет волноваться при попытке выполнить коммит.Кроме того, поскольку вы используете rebase для синхронизации с репозиторием SVN, а так как pull из репозитория, который был перебазирован, приведет к выходу Git из себя, гораздо труднее поддерживать клоны основного репозитория Git (выможет потребоваться их удаление и повторное клонирование после каждой перезагрузки.)

2 голосов
/ 25 июля 2011

Я согласен с MatrixFrog, что скорость - это проблема. Это особенно верно, когда вы клонируете проект в первый раз, но не только тогда.

Другая проблема, с которой я столкнулся, заключается в том, что в самом git-svn практически отсутствует поддержка svn: externals И лучшее решение, которое я смог найти не всегда работает так, как должно.

2 голосов
/ 25 июля 2011

Главный недостаток, который я могу вспомнить, заключается в том, что первоначальный клон может быть очень медленным, поскольку вы клонируете всю историю проекта. Конечно, это верно и для чистого git, но если вы клонируете с чистого git-сервера, он предназначен для этого. Репозитория svn нет, поэтому git-svn должен получать историю по одной ревизии за раз. Одно из решений (помимо простого запуска операции клонирования в одночасье) - сделать « неглубокий клон », хотя тогда у вас, очевидно, не будет всей истории, поэтому вы должны использовать svn log для поиска очень старые ревизии.

0 голосов
/ 27 июля 2011

Еще пару мыслей, о которых я подумал:

  • При перемещении / переименовании файла git не хранит метаданные с надписью «этот файл был переименован», он просто выясняет это, замечаячто старый файл и новый файл очень похожи.SVN ожидает от вас переименования от до SVN, чтобы он мог записывать некоторые метаданные.Git не будет этого делать, поэтому в вашем репозитории SVN не будет всей истории, которую он должен иметь.
  • При слиянии (или, скорее, при выборе вишни из-за того, что сказал Макс), svn:mergeinfoсвойства не будут установлены.На самом деле, я думаю, почти все, что использует свойства SVN, вы не можете сделать, хотя git-svn.

В целом, это все же намного приятнее, чем использование стандартного клиента SVN, ИМХО, но есть некоторые определенные недостатки.

...