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

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

[Daniele Segato]

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

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

[Eric Wong]

Daniele Segato <daniele.bilug@gmail.com> wrote:
> 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.

> 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

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

[Daniele Segato]

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.

>> 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

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

[Eric Wong]

Daniele Segato <daniele.bilug@gmail.com> wrote:
> 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

> 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.

> 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.

> >> 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.

> (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