From: H Krishnan <hidden> Date: 2016-06-15 22:49:55
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
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
From: H Krishnan <hidden> Date: 2016-06-15 22:49:55
H Krishnan wrote:
quoted
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 B
Our corporate setup will not easily move to git but some sub-teams would like to
use it for their work.
Regards,
Krishnan
From: H Krishnan <hidden> Date: 2016-06-15 22:49:55
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
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
On Thu, 28.10.2010 at 16:58:28 +0000, H Krishnan wrote:
quoted
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
On Thu, 28.10.2010 at 21:31:18 +0200, Mathias Lafeldt wrote:
On 10/28/2010 09:02 PM, Ulrich Spörlein wrote:
quoted
On Thu, 28.10.2010 at 16:58:28 +0000, H Krishnan wrote:
quoted
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
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
From: H Krishnan <hidden> Date: 2016-06-15 22:49:56
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/metadata
3) 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