Svn to git: Как бороться с нашими нестандартными, возможно, неправильно разветвленными svn - PullRequest
Новая
       1

Svn to git: Как бороться с нашими нестандартными, возможно, неправильно разветвленными svn

5 голосов
/ 02 июня 2011

Наша текущая структура SVN выглядит следующим образом: 

trunk
-- project
-- projectDao
-- projectResources
branches
-- project-1.0
-- projectDao-1.0
-- projectResources-1.0
-- project-2.0
-- projectDao-2.0
-- projectResources-2.0
tags
-- project-1.0.0
-- ...

Что еще хуже, Project-1.0 был отделен от проекта projectDao-1.0 от projectDao (каждый в отдельном коммите движения фиксирует).В идеале это было бы так.

Это журнал коммитов: 

trunk
-- project
-- projectDao
-- projectResources
branches
-- 1.0
---- project
---- projectDao
---- projectResources
-- 2.0
---- project
---- projectDao
---- projectResources
tags
--1.0.0
----project
---- ...

И это имеет смысл.И тогда мы должны были перейти от транка к 1.0 вместо двух разных коммитов.

Однако мы хотим перейти на git сейчас (навсегда), и я не знаю, как мне начать с этого.

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

* master
  remotes/project-1.0
  remotes/project-1.0@3
  remotes/project-2.0
  remotes/project-2.0@10
  remotes/projectDao-1.0
  remotes/projectDao-1.0@4
  remotes/projectDao-2.0
  remotes/projectDao-2.0@11
  remotes/projectResources-1.0
  remotes/projectResources-1.0@5
  remotes/projectResources-2.0
  remotes/projectResources-2.0@12
  remotes/tags/project-1.0.0
  remotes/tags/projectDao-1.0.0
  remotes/tags/projectResources-1.0.0
  remotes/trunk

Это то, что генерирует gitg

This is what gitg generates

Я не знаю, как я могу использовать rebase, чтобы получить это право, например: 

* master
  remotes/1.0
  remotes/2.0
  remotes/tags/1.0.0
  remotes/trunk

Ответы [ 2 ]

5 голосов
/ 02 июня 2011

Если я правильно понимаю, вы хотите изменить импортированные ветки на каталоги в ветке 1.0. Кроме того, вы не упоминаете, является ли это постоянной миграцией или проверкой git-svn, пока вы поддерживаете свой svn-репозиторий.

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

Если вы хотите преобразовать свой репозиторий, добавьте коммит во все ветви, поместив содержимое этой ветви в каталог в корне, чтобы впоследствии объединить ветви. Вы не потеряете историю SVN со старой структурой веток в своей истории GIT, но будущее будет в новом стиле.

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

0 голосов
/ 02 июня 2011

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

...