Hi,
I'm currently playing around with Subversion 1.5 RC10 and have converted
the repository to the 1.5 format. This means that currently access via
http does not work which is no really a huge loss because it's not the
fastest way either. I've no disk space for the old repository so it's
gone. Guido, if you want access to this repository just send me your
public key.
Ian Clatworthy from the Bazaar team asked me to provide fast-svn-export
style dumps and he mentioned that they have relevance for git as well so
it might be worthwhile to start with them. I hope I'll get to create
them next week.
Heiner
Jan Holesovsky wrote:
Hi Guido,
On Thursday 12 June 2008 00:46, Guido Ostkamp wrote:
What concerns me a bit is the size of the repository - without actual
trying, I have no idea how efficient git-svn will be on the full OOo
import.
Correct. We have to try that. Do you have an already converted local OOo
SVN repo on your Git-box where this could be done?
No, unfortunately not yet.
If not, and you have access to an SVN repo elsewhere (e.g. on Heiner's
servers) can you arrange a mirror of this (maybe SVK could be used for
this?) so that later git tests can be run locally on your Git-box?
Let me talk to our admins, how to get the box behind the company firewall etc.
- might take a bit of time. If you can, please continue with the test
locally - please, have a look at
http://wiki.services.openoffice.org/wiki/SCM_Migration, according to the
page, it should be enough to send Heiner your public key to be able to get a
mirror of the SVN tree.
Yes, this is a bit tricky, but I believe solvable ;-) In combination
with 'svn lock', the 'pre-receive' and 'update' hooks would fail in case
there are changes in the SVN CWS branch that are not yet merged in the
git branch. You are right that this would be quite a limitation if the
changes from SVN would not be mirrored too often; OTOH thanks to the OOo
development cycle where just the release engineers can commit to trunk
and others manage just the CWSes (branches), this would not be that much
a problem for the CWSes created and managed exclusively in the git tree.
Even if this would work, you will run into trouble with duplicated
changesets. Remember, you push to Git first. Even if some mechanism
automatically moves this into SVN as well, you still will have independent
changesets in Git, and when running the next 'git-svn fetch' it will
import the SVN changes again. But that have already been applied because
Git changesets for this already exist. This will not work.
Oh - I did not mean to setup this on top of git-svn, but rather a custom
solution. The duplicate changes should not be a problem either, it is solved
at least for the git -> cvs -> git roundtrip (see
http://issaris.blogspot.com/2005/11/cvs-to-git-and-back.html), so I believe
it should not be a problem for SVN either.
Anyway - at some stage I'll try to come up with a proof-of-concept; either
I'll see it is really a bad idea, or we'll have something to build upon ;-)
Regards,
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jens-Heiner Rechtien
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
