Hi,

I would like to convert a subversion repository to Git. The subversion

repository used to track development of several projects (only slightly

related), and I would like to divide the repository into several smaller

git repositories.
For example, I want to convert one subversion repository which contains

the folders:

trunk/projectA

trunk/projectB
into two git repositories:

projectA.git

projectB.git
As far as I have understood, the way to do this is to

1) Convert the entire subversion repository to git with git-svn.

2) Make two copies of the whole new git-repository (projectA.git and

projectB.git).

3) Use git-rm to remove projectB from projectA.git, and projectA from

projectB.git.
This works fine, but both git-repositories now carries the history for

both projects. If possible, I would like to "clean" the history in the

repositories, so that I don't see history information for projectA when I

am browsing logs in projectB.git. Has anyone been in the same situation?

Do you have suggestions on how it can be solved?
Any help will be greatly appreciated.
Thanks,

Eivind

-

I have a slightly different layout to you -
projectA/trunk

projectA/branches

projectA/tags

projectB/trunk

projectB/branches

projectB/tags

etc
- but I've been creating separate git repos from that with (for

example) :
git-svn init -t tags -b branches -T trunk http://svn.host.com/projectA

git-svn fetch
Or will git-svn not work with your sort of layout?
-

It does work.  Use:
git-svn init -t projectA/tags -b projectA/branches \

   -T trunk/projectA http://svn.host.com/

git fetch
Also you can expect the import results of each branch to be the same

regardless of whether you import all at once using a command like the

above, or import a single path without passing -t / -b / -T to git svn init.
If you have a lot of projects to mine from a single repository, use

svnsync or SVN::Mirror/svk and then import from the local repository

with --use-svm-props.
Sam.

-

With my paths this translates into
   $ git-svn init -b eivindlm/branches \

                  -t eivindlm/tags \

                  -T eivindlm/trunk/src/probesimulator \

                  file:///svn-repo/

, which prints the happy message:

   Initialized empty Git repository in .git/
The next command is unfortunately not as happy:

   $ git fetch

   fatal: 'origin': unable to chdir or not a git archive

   fatal: The remote end hung up unexpectedly

   Cannot get the repository state from origin
I suppose this is due to my silly svn-repo layout... However, after some

trial and error it seems like the following command gives me what I want

(I don't need tags or other branches than main):
   $ git-svn clone file:///svn-repo/ --follow-parent \

                   -T eivindlm/trunk/src/probesimulator
It seems to realize that the probesimulator directory has moved around in

my tree, and gives me history for files that belongs in this directory

only (and not history for other directories). So the problem appears to be

solved for my part, unless you see a reason for why I should not do it in  
Thanks a lot for the help to everyone who replied!
Eivind

-

Whoops, my mistake.  That should have been "git svn fetch".
Sam.

-

I believe you actually wanted "git-svn fetch" here
-

On Fri, 12 Oct 2007 16:23:44 +0200, Jonathan del Strother

<maillist@steelskies.com> wrote:
You are right, that solved the problem :)
So both methods work now, apparently giving the same result. Is there a

difference between the fetch- versus the clone-approach? I am doing this

as a once-and-for-all import, and would like to forget everything about

the subversion repository afterwards.
Thanks,

Eivind

-

Just be aware that, if you follow this approach, the commit logs

created by git-svn will be rewritten (relative to the original SVN

logs) with the SVN repository revision and ID information.  I believe

you can disable this behavior by passing the --no-metadata option to

"git-svn init", but I haven't tried this yet.
I also believe that this approach will leave your git repository in

such as state as to recognize that there is a remote repository from

which this repository was fetched.  I have no idea what implications

and long term repercussions (if any) this has.  It just dawned on me

as I was rereading the git-svn man page to look for the --no-metdata

option and read that it will "Set the noMetadata option in the

[svn-remote] config".  Most of that is still Greek to me.
--wpd

-

Just to clarify: this is true for all git-svn use, and has nothing to
Apart from the metadata appended to the commit messages (which you can

turn off with --no-metadata), all the extra data saved by git-svn is

purely local. Meaning that you can always get rid of it by cloning the

repository, if you can't think of a cleverer way to do it.
--

Karl Hasselström, kha@treskal.com

      www.treskal.com/kalle

-

If you look through the Subversion FAQ or the book (I forget where

I've seen it -- but I know I've seen it), you can export/filter out a

tree from a subversion repository and load it into a new repository.

Then you can import from that new repository.
This presumes you have direct access to the subversion repository and

can run commands like svnadmin --dump.
--wpd
-

Thanks,

I found svndumpfilter in the svn book, and gave it a try. Unfortunately it

seems to be confused about files that have moved around in the repository,

I was at least not able to make it dump the entire history for a directory

that over time has changed name, and that contains files that have moved

in from other directories.
Eivind
On Thu, 11 Oct 2007 15:24:59 +0200, Patrick Doyle <wpdster@gmail.com>  
-