threads / discuss / 24072

Question about tracking multiple Subversion repository from the same git repository with git-svn

Subject: Question about tracking multiple Subversion repository from the same git repository with git-svn

## tl;dr

4 messages between Jun 10, 2010 and Jun 11, 2010.

replies: 3people: 2as markdown or json

Daniele Segato· Jun 10, 2010, 14:29 UTC · lore
Hi all,
Say that I have 3 subversion repository

svn: an online repo which I only have read-only rights. abc, xyz: two project in two private repo where I have write rights.

[svn-remote "svn"]
	url = http://svn.online-repo.com/repos/public
	fetch = path/to/trunk:refs/remotes/svn/trunk
	branches = path/to/branches/*:refs/remotes/svn/*
	tags = path/to/tags/*:refs/remotes/svn/tags/*
[svn-remote "abc"]
	url = https://svn.local-repo/repos/public
	fetch = path/to/trunk:refs/remotes/abc/trunk
	branches = path/to/branches/*:refs/remotes/abc/*
	tags = path/to/tags/*:refs/remotes/abc/tags/*
[svn-remote "xyz"]
	url = https://svn.local-repo/repos/public
	fetch = path/to/trunk:refs/remotes/xyz/trunk
	branches = path/to/branches/*:refs/remotes/xyz/*
	tags = path/to/tags/*:refs/remotes/xyz/tags/*

Reading the man page of git-svn it seems this is possible and specifically supported.

But I have some doubt.

Suppose I've already created the project "abc" starting with trunk copied from a specific commit (tag) of the "svn" project.

1. Is there a way to tell git that abc/trunk is a branch of svn/tags/1.2.3 ?
2. can I rename svn-remote "svn" to something like "main" without side effect?
3. after 2) can I also rename all the names of the remote branches to
main/* instead of svn/* ?
4. if project xyz is no more of interest to me can I "discard" it and
remove the remote branches I don't need anymore?
5. when I'll decide to upgrade project abc to main version 2.0.0 I'll do:
git merge --squash main/tags/2.0.0
is this the best way?
6. after point 5) when I'll further upgrade the project abc to main
version 2.1.0 can I still do:
git merge --squash main/tags/2.1.0
or this will cause me problem? (the rerere option is set to true, so
conflicts already solved shouldn't be asked twice).
7. if the merge --squash cause a lot of conflicts is there a way to
split the conflict resolution across different persons?
Thanks for any help you'll give me.

Regards, Daniele Segato

Eric Wong· Jun 10, 2010, 19:04 UTC · re: Daniele Segato · lore

Re: Question about tracking multiple Subversion repository from the same git repository with git-svn

Daniele Segato <daniele.bilug@gmail.com> wrote:
Show 35 quoted lines
> Hi all,
> 
> Say that I have 3 subversion repository
> 
> svn: an online repo which I only have read-only rights.
> abc, xyz: two project in two private repo where I have write rights.
> 
> [svn-remote "svn"]
> 	url = http://svn.online-repo.com/repos/public
> 	fetch = path/to/trunk:refs/remotes/svn/trunk
> 	branches = path/to/branches/*:refs/remotes/svn/*
> 	tags = path/to/tags/*:refs/remotes/svn/tags/*
> 
> [svn-remote "abc"]
> 	url = https://svn.local-repo/repos/public
> 	fetch = path/to/trunk:refs/remotes/abc/trunk
> 	branches = path/to/branches/*:refs/remotes/abc/*
> 	tags = path/to/tags/*:refs/remotes/abc/tags/*
> 
> [svn-remote "xyz"]
> 	url = https://svn.local-repo/repos/public
> 	fetch = path/to/trunk:refs/remotes/xyz/trunk
> 	branches = path/to/branches/*:refs/remotes/xyz/*
> 	tags = path/to/tags/*:refs/remotes/xyz/tags/*
> 
> Reading the man page of git-svn it seems this is possible and
> specifically supported.
> 
> 
> But I have some doubt.
> 
> Suppose I've already created the project "abc" starting with trunk
> copied from a specific commit (tag) of the "svn" project.
> 
> 1. Is there a way to tell git that abc/trunk is a branch of svn/tags/1.2.3 ?
You need to use grafts.
> 2. can I rename svn-remote "svn" to something like "main" without side effect?

You should be able to (and use GIT_SVN_ID=main in the env), though I haven't used these features in a while.

> 3. after 2) can I also rename all the names of the remote branches to
> main/* instead of svn/* ?
It should be possible...  you need to edit $GIT_DIR/svn/.metadata, too.
> 4. if project xyz is no more of interest to me can I "discard" it and
> remove the remote branches I don't need anymore?
Yes.
> 5. when I'll decide to upgrade project abc to main version 2.0.0 I'll do:
> git merge --squash main/tags/2.0.0
> is this the best way?
Probably, yes.
Show 5 quoted lines
> 6. after point 5) when I'll further upgrade the project abc to main
> version 2.1.0 can I still do:
> git merge --squash main/tags/2.1.0
> or this will cause me problem? (the rerere option is set to true, so
> conflicts already solved shouldn't be asked twice).
merge --squash should always be safe when dealing with SVN repos.
> 7. if the merge --squash cause a lot of conflicts is there a way to
> split the conflict resolution across different persons?

I'm not sure what you mean... multiple people working on the same working tree? On a shared screen session? I don't see why not.

-- 
Eric Wong
Daniele Segato· Jun 11, 2010, 07:18 UTC · re: Eric Wong · lore

Re: Question about tracking multiple Subversion repository from the same git repository with git-svn

On Thu, Jun 10, 2010 at 9:04 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> 1. Is there a way to tell git that abc/trunk is a branch of svn/tags/1.2.3 ?
>
> You need to use grafts.

this one? https://git.wiki.kernel.org/index.php/GraftPoint

seems what I need..
in this case, I had a question:

since if I use this feature my commit will have different SHA-1. I used to write the commit SHA-1 in some of the svn tags. If I do this they will no longer be valid. I think with git SVN the "best" way to identify a commit is using the "Tree" object SHA-1, it should be the same for every revision that contains the same content... so.. 1b. Can I extract the tree sha-1 from a commit? 1c. Is there a way to get every commit pointing to to a tree?

Ideally I would do something like

git contain-tree <sha-1-of-the-tree> [list of commit's here]

does this make any sense to you?
>> 2. can I rename svn-remote "svn" to something like "main" without side effect?
>
> You should be able to (and use GIT_SVN_ID=main in the env),
> though I haven't used these features in a while.

Renamed, thanks. do you know if I can set a GIT_SVN_ID (default) per-repository instead of using the environment variable? (since I use git-new-workdir it would be best if I can use a default per workdir)

>> 3. after 2) can I also rename all the names of the remote branches to
>> main/* instead of svn/* ?
>
> It should be possible...  you need to edit $GIT_DIR/svn/.metadata, too.
thanks, did it.
Show 5 quoted lines
>> 7. if the merge --squash cause a lot of conflicts is there a way to
>> split the conflict resolution across different persons?
>
> I'm not sure what you mean... multiple people working on the same
> working tree?  On a shared screen session?  I don't see why not.

no, what I had in mind was a "migration team" to work on the migration of the customization to a product to the new version of the main product.

What I have in mind here is some kind of "selective merge". For example...

I merge a group of commits, someone else, on another computer with git-svn or subversion merge another part and so on..

like...

git merge --squash -- path/to/something or something like

git merge --squash --interactive
this could give you a way to choose different paths you want to "merge".

I know this is not very like a merge but I hope I gave you the idea of what I meant.

Regards, Daniele Segato

Eric Wong· Jun 11, 2010, 21:28 UTC · re: Daniele Segato · lore

Re: Question about tracking multiple Subversion repository from the same git repository with git-svn

Daniele Segato <daniele.bilug@gmail.com> wrote:
Show 9 quoted lines
> On Thu, Jun 10, 2010 at 9:04 PM, Eric Wong <normalperson@yhbt.net> wrote:
> >> 1. Is there a way to tell git that abc/trunk is a branch of svn/tags/1.2.3 ?
> >
> > You need to use grafts.
> 
> this one?
> https://git.wiki.kernel.org/index.php/GraftPoint
> 
> seems what I need..
Yes
Show 10 quoted lines
> in this case, I had a question:
> 
> since if I use this feature my commit will have different SHA-1. I
> used to write the commit SHA-1 in some of the svn tags. If I do this
> they will no longer be valid.
> I think with git SVN the "best" way to identify a commit is using the
> "Tree" object SHA-1, it should be the same for every revision that
> contains the same content...
> so..
> 1b. Can I extract the tree sha-1 from a commit?
Yes, "git cat-file commit $commit" will show you the tree.
Show 8 quoted lines
> 1c. Is there a way to get every commit pointing to to a tree?
> 
> Ideally I would do something like
> 
> git contain-tree <sha-1-of-the-tree>
> [list of commit's here]
> 
> does this make any sense to you?
Sort of, yes...

Back in ancient times, there used to be a "git svn graft-branches" command which could automate what you're doing. It was removed in commit d05d72e07e49869fe988d4d99e6ac60711570db5 because it was largely unused.

Perhaps you can resurrect it as a standalone command. I imagine it could be used for other import utilities, too.

Show 9 quoted lines
> >> 2. can I rename svn-remote "svn" to something like "main" without side effect?
> >
> > You should be able to (and use GIT_SVN_ID=main in the env),
> > though I haven't used these features in a while.
> 
> Renamed, thanks.
> do you know if I can set a GIT_SVN_ID (default) per-repository instead
> of using the environment
> variable?

Err, actually, --svn-remote=main is probably preferred, these days. GIT_SVN_ID is --id=foo. Sorry for the confusion.

Show 39 quoted lines
> (since I use git-new-workdir it would be best if I can use a default
> per workdir)
> 
> >> 3. after 2) can I also rename all the names of the remote branches to
> >> main/* instead of svn/* ?
> >
> > It should be possible...  you need to edit $GIT_DIR/svn/.metadata, too.
> 
> thanks, did it.
> 
> >> 7. if the merge --squash cause a lot of conflicts is there a way to
> >> split the conflict resolution across different persons?
> >
> > I'm not sure what you mean... multiple people working on the same
> > working tree?  On a shared screen session?  I don't see why not.
> 
> 
> no,
> what I had in mind was a "migration team" to work on the migration of
> the customization
> to a product to the new version of the main product.
> 
> What I have in mind here is some kind of "selective merge".
> For example...
> 
> I merge a group of commits, someone else, on another computer with
> git-svn or subversion merge another part and so on..
> 
> like...
> 
> git merge --squash -- path/to/something
> or something like
> 
> git merge --squash --interactive
> 
> this could give you a way to choose different paths you want to "merge".
> 
> I know this is not very like a merge but I hope I gave you the idea of
> what I meant.

I'll wait for others to answer that. I rarely encounter conflict-heavy merges, partly because my workflows are setup to avoid them.

-- 
Eric Wong

← back to recent threads