Daniele Segato <daniele.bilug@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html