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]

Reply via email to