Hi, We have started using git and git-svn. I was thrilled to see that two people cloning using "git svn clone" from the same repository got the same sha1 IDs for the commits which meant that each of us could sync with svn independently while still being able to share code among ourselves. But my excitement was shortlived as the sha1 IDs were different if we refer to the svn server using an alias. For example, using http://mysvnserver.mydomain.com/repos/myproject/trunk gave different sha1 IDs from using http://mysvnserver/repos/myproject/trunk even though both refer to the same repository. This also disallowed using mirrors of the repository for cloning. Apparently the sha1 ID is generated from the full path of the URL. Instead of this, could git-svn init be made to accept an optional "prefix" argument as well which is filtered out of the URL before building the sha1 ID. This will allow easy support for the oft requested support for "svn switch --relocate". How much of an effort is this? I don't know perl or git internals well enough for me to take a stab at it but I am willing to learn if someone can give me some pointers. Krishnan
Mathias LafeldtRe: svn repository URL and git
H Krishnan wrote:
Show 21 quoted lines
> Hi, > We have started using git and git-svn. > I was thrilled to see that two people cloning using "git svn clone" > from the same repository got the same sha1 IDs for the commits which > meant that each of us could sync with svn independently while still > being able to share code among ourselves. > But my excitement was shortlived as the sha1 IDs were different if we > refer to the svn server using an alias. For example, using > http://mysvnserver.mydomain.com/repos/myproject/trunk gave different > sha1 IDs from using http://mysvnserver/repos/myproject/trunk even > though both refer to the same repository. This also disallowed using > mirrors of the repository for cloning. > Apparently the sha1 ID is generated from the full path of the URL. > Instead of this, could git-svn init be made to accept an optional > "prefix" argument as well which is filtered out of the URL before > building the sha1 ID. This will allow easy support for the oft > requested support for "svn switch --relocate". How much of an effort > is this? I don't know perl or git internals well enough for me to take > a stab at it but I am willing to learn if someone can give me some > pointers. > Krishnan
The problem is the "git-svn-id" which is automatically appended to each commit done with git-svn. This ID consists of the URL and the UUID of the corresponding SVN repository. A different git-svn-id value results in a different commit SHA1 (i.e. a different commit to git).
I guess git-svn's --rewrite-root option might help here. Also, you have to make sure that your SVN repos have the same UUID (with svnadmin setuuid), of course.
-Mathias
Re: svn repository URL and git
Show 35 quoted lines
> > H Krishnan wrote: > > Hi, > > We have started using git and git-svn. > > I was thrilled to see that two people cloning using "git svn clone" > > from the same repository got the same sha1 IDs for the commits which > > meant that each of us could sync with svn independently while still > > being able to share code among ourselves. > > But my excitement was shortlived as the sha1 IDs were different if we > > refer to the svn server using an alias. For example, using > > http://mysvnserver.mydomain.com/repos/myproject/trunk gave different > > sha1 IDs from using http://mysvnserver/repos/myproject/trunk even > > though both refer to the same repository. This also disallowed using > > mirrors of the repository for cloning. > > Apparently the sha1 ID is generated from the full path of the URL. > > Instead of this, could git-svn init be made to accept an optional > > "prefix" argument as well which is filtered out of the URL before > > building the sha1 ID. This will allow easy support for the oft > > requested support for "svn switch --relocate". How much of an effort > > is this? I don't know perl or git internals well enough for me to take > > a stab at it but I am willing to learn if someone can give me some > > pointers. > > Krishnan > > The problem is the "git-svn-id" which is automatically appended to each > commit done with git-svn. This ID consists of the URL and the UUID of > the corresponding SVN repository. A different git-svn-id value results > in a different commit SHA1 (i.e. a different commit to git). > > I guess git-svn's --rewrite-root option might help here. Also, you have > to make sure that your SVN repos have the same UUID (with svnadmin > setuuid), of course. > > -Mathias >
Thanks for your quick reply.
Could the git-svn-id also be based on only the suffix part of the URL? The prefix needs to be used only when connecting to the svn server and not otherwise. By default, the prefix is empty thereby getting back the current behavior.
I did try --rewrite-root but from what I understood of it, git-svn rebase will happen with the root I supply here and not from the local mirrors. We would like something like the following:
users in place A <--git-svn--> SVN mirror in place A
^ ^
| |
git fetch/merge some sort of rsync
| |
v v
users in place B <--git-svn--> SVN mirror in place BOur corporate setup will not easily move to git but some sub-teams would like to use it for their work.
Regards, Krishnan
Re: svn repository URL and git
Hi, I think I resolved this problem by using --rewrite-root as suggested. I used a dummy root during the git-svn clone:
git-svn clone --rewrite-root http://git.is.great <myrepo>
All my commit messages now have http://git.is.great but I am able to change the repository URL and continue.
Could this approach be used as an insurance against svn url changes? When initializing the repository, we could use --rewrite-root. Subsequently, if the svn repository relocates, we need to edit only .git/config.
Thanks for your help.
Krishnan
Re: svn repository URL and git
On Thu, 28.10.2010 at 16:58:28 +0000, H Krishnan wrote:
Show 13 quoted lines
> > Hi, > I think I resolved this problem by using --rewrite-root as suggested. I used a > dummy root during the git-svn clone: > > git-svn clone --rewrite-root http://git.is.great <myrepo> > > All my commit messages now have http://git.is.great but I am able to change the > repository URL and continue. > > Could this approach be used as an insurance against svn url changes? When > initializing the repository, we could use --rewrite-root. Subsequently, if the > svn repository relocates, we need to edit only .git/config.
Yes, that's exactly what the rewrite-url was introduced for, you can even clone from a local svnsync mirror (iff the UUID matches, you have to setup the mirror in a special way ...).
So, every developer must use:
$ git svn clone --rewrite-root CANONICAL-URL-NEVER-TO-CHANGE <whatever-url-is-convenient>
Oh, and all devs must use the same authormap (or no authormap at all).
hth, Uli
Mathias LafeldtRe: svn repository URL and git
On 10/28/2010 09:02 PM, Ulrich Spörlein wrote:
Show 27 quoted lines
> On Thu, 28.10.2010 at 16:58:28 +0000, H Krishnan wrote: >> >> Hi, >> I think I resolved this problem by using --rewrite-root as suggested. I used a >> dummy root during the git-svn clone: >> >> git-svn clone --rewrite-root http://git.is.great <myrepo> >> >> All my commit messages now have http://git.is.great but I am able to change the >> repository URL and continue. >> >> Could this approach be used as an insurance against svn url changes? When >> initializing the repository, we could use --rewrite-root. Subsequently, if the >> svn repository relocates, we need to edit only .git/config. > > Yes, that's exactly what the rewrite-url was introduced for, you can > even clone from a local svnsync mirror (iff the UUID matches, you have > to setup the mirror in a special way ...). > > So, every developer must use: > > $ git svn clone --rewrite-root CANONICAL-URL-NEVER-TO-CHANGE <whatever-url-is-convenient> > > Oh, and all devs must use the same authormap (or no authormap at all). > > hth, > Uli
FYI, I just learned [1] that git-svn even has a --rewrite-uuid option.
[1] http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
-Mathias
Re: svn repository URL and git
On Thu, 28.10.2010 at 21:31:18 +0200, Mathias Lafeldt wrote:
Show 32 quoted lines
> On 10/28/2010 09:02 PM, Ulrich Spörlein wrote: > > On Thu, 28.10.2010 at 16:58:28 +0000, H Krishnan wrote: > >> > >> Hi, > >> I think I resolved this problem by using --rewrite-root as suggested. I used a > >> dummy root during the git-svn clone: > >> > >> git-svn clone --rewrite-root http://git.is.great <myrepo> > >> > >> All my commit messages now have http://git.is.great but I am able to change the > >> repository URL and continue. > >> > >> Could this approach be used as an insurance against svn url changes? When > >> initializing the repository, we could use --rewrite-root. Subsequently, if the > >> svn repository relocates, we need to edit only .git/config. > > > > Yes, that's exactly what the rewrite-url was introduced for, you can > > even clone from a local svnsync mirror (iff the UUID matches, you have > > to setup the mirror in a special way ...). > > > > So, every developer must use: > > > > $ git svn clone --rewrite-root CANONICAL-URL-NEVER-TO-CHANGE <whatever-url-is-convenient> > > > > Oh, and all devs must use the same authormap (or no authormap at all). > > > > hth, > > Uli > > FYI, I just learned [1] that git-svn even has a --rewrite-uuid option. > > [1] http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
Try using them both at the same time! :]
(No, I have no idea, why that is not supported ... OTOH having the same UUID on the mirror is a kinda no-brainer)
Uli
Re: svn repository URL and git
Hi, Would the following approach for svn switch --relocate (even for current git clones):
1)If svn-remote.svn.rewriteRoot does not exist in config file:
git config svn-remote.svn.rewriteRoot <currentRepository>2)If svn-remote.svn.rewriteUUID does not exist in config file:
git config svn-remote.svn.rewriteUUID <currentRepositoryUUID>
currentRepositoryUUID can be obtained from .git/svn/metadata3) git config svn-remote.svn.url <newRepository>
If the above works, it would be much simpler than other solutions that have been proposed for svn repo relocations.
Krishnan