You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by florent andré <fl...@4sengines.com> on 2011/07/26 13:51:00 UTC
OOO340 to svn
Hi there,
I actually run a script [1] on my local laptop and online svn serveur
that import the OOO340 hg to an svn trunk folder.
For now, it's work pretty well - get all history from OO340 - with good
commit log e.g. :
-------
Added:
ooo/trunk/trunk/xmloff/source/text/XMLTextColumnsContext.cxx
Modified:
ooo/trunk/trunk/xmloff/source/text/XMLTextPropertySetContext.cxx
ooo/trunk/trunk/xmloff/source/text/makefile.mk
Log:
changeset: 41:196d10f76091
user: mib
date: Thu Sep 21 09:48:30 2000 +0000
text column import
--------
But, as it simulate all svn commit, it's a little bit long...
Actually on 45/276930 revision.
If the process goes well to the end, what could be the next step ?
Restart this script on the apache svn or extract some kind of svn dump
from my svn-serveur and import it ?
++
Re: OOO340 to svn
Posted by florent andré <fl...@4sengines.com>.
Recap so far :
https://cwiki.apache.org/confluence/display/OOOUSERS/svn+import+experience
Try write details as much for reproducibility.
On 07/27/2011 10:14 PM, Rob Weir wrote:
> Can we review what has been attempted and what has failed? I want to
> make sure we understand the dead-ends, so we don't retrace them.
>
> 1) Have we tried posting to the Apache subversion user list? Perhaps
> someone there has an idea or tool that we have not thought of? Or
> maybe this would be an interesting problem that they might be willing
> to help with?
I don't. Do a fast search on markmail, but don't see nothing relevant.
I will not have time to manage this.
>
> 2) I assume someone has tried the Hg "convert" extensions, e.g., hg
> convert --dest-type svn hgreponame svnreponame . If so, what didn't
> work right?
Yep. see recap.
>
> 3) Tailor? http://progetti.arstecnica.it/tailor Probably not very
> fast, but looks very flexible.
look a little bit, found this [1] for starting point, use bazar as a
pivot from hg to svn.
No find information about perf.
I will not have time to fire this now.
[1]
http://wargle.blogspot.com/2006/12/using-tailor-to-move-from-hg-to-svn.html
Re: OOO340 to svn
Posted by Rob Weir <ap...@robweir.com>.
On Wed, Jul 27, 2011 at 9:23 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> TBD = To Be Determined/Defined
>
> There was extensive discussion with Greg Stein and Marcus (and others) in previous weeks on this list. Greg's last post was July 9, as previously noted. There has been further work/discussion by Mathias Bauer, Michael Stahl, Marcus Lange, Eike Rathke, and others.
>
> It seems to have become unclear exactly where we are heading.
>
> Where are we heading?
>
August is almost here. I'm heading for vacation. I suspect many
project members are already there ;-)
Lake Winnipesaukee and Weir's Beach (of course) for me.
> - Dennis
>
> -----Original Message-----
> From: florent andré [mailto:florent.andre-dev@4sengines.com]
> Sent: Wednesday, July 27, 2011 15:42
> To: ooo-dev@incubator.apache.org
> Subject: Re: OOO340 to svn
>
> ..
>>
>> ergh
>>
>> Have you guys not been following what Greg Stein and co have been doing in svn
>> and on this list with regards to a conversion tool?
>
> May I really miss something, but what's on single-hg is a hg
> concatenation tool.
>
> This file have this in notice :
> "See <TBD> for converting the resulting repository to Subversion,"
>
> I admit to not see what TDB stand for...
>
> ++
>
>
> [1]
> http://svn.apache.org/viewvc/incubator/ooo/trunk/tools/dev/single-hg.sh?revision=1144587&view=markup
>
>
Re: OOO340 to svn
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/28/2011 06:41 AM, schrieb Greg Stein:
> On Wed, Jul 27, 2011 at 21:23, Dennis E. Hamilton
> <de...@acm.org> wrote:
> 2) move all the Hg repositories over to apache-extras.org. That
> supports Hg and it supports "any OSI license". We can indefinitely
> retain history there without it being "part of" our ASF project.
+1
apache-extras seems to be our straw. ;-)
> While it means that we won't have history in svn, it does mean that
> we'll have full history available to us. And in its natural Hg state.
OK, if this is our way (and AFAIU the only that is possible from point
of view of technical, time and effort) to keep all SVN history data then
we should go this.
Marcus
Re: OOO340 to svn
Posted by Herbert Duerr <hd...@alice.de>.
> 1) import just the OOO340 tip into svn
> 2) move all the Hg repositories over to apache-extras.org. That
> supports Hg and it supports "any OSI license". We can indefinitely
> retain history there without it being "part of" our ASF project.
To get things going fast this might be the best way.
But shouldn't the Oracle-license headers be replaced by ASL2 license
headers first before the tip is committed into the ASF-projects svn?
The original OOo project went through three revision control systems
(CVS -> SVN -> HG) and during each transition valuable information was
lost. So it may be a good idea to preserve not only the HG-history, but
also the older CVS and SVN histories.
Herbert
Re: OOO340 to svn
Posted by Dave Fisher <da...@comcast.net>.
On Jul 27, 2011, at 9:41 PM, Greg Stein wrote:
> On Wed, Jul 27, 2011 at 21:23, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> TBD = To Be Determined/Defined
>>
>> There was extensive discussion with Greg Stein and Marcus (and others) in previous weeks on this list. Greg's last post was July 9, as previously noted. There has been further work/discussion by Mathias Bauer, Michael Stahl, Marcus Lange, Eike Rathke, and others.
>
> Yup. Sorry about being away. The Apache Subversion project created its
> 1.7.x stabilization branch for our upcoming 1.7 release. This has been
> two years in the making, so it has been a Big Deal. I haven't had the
> time to properly dedicate here.
Sounds exciting. "svn patch" is part of of subversion 1.7, correct? When will svn.apache.org be 1.7?
Carl Marcum and I are working on svn instructions for the project and if 1.7 is happening very soon, I think it would be great if we could include svn 1.7 type instructions.
>
> I've read some of the threads, and will need to cut this short (at
> OSCON right now). In short, I saw a concern about how to handle the
> two-parent merges. That was also becoming a concern of mine, but
> hadn't quite reached the "geez. I dunno" stage.
>
> With these various conversion issues, I might be coming around to just
> saying "not really possible with the current set of tools today". I'll
> talk to a friend of mine to see if they have something that can help
> (his company does a lot of version control work, and they may have
> ideas/tooling).
>
> In the meantime, and I can dig in more this weekend once I get home,
> I'll suggest one possible road for us:
>
> 1) import just the OOO340 tip into svn
+1
> 2) move all the Hg repositories over to apache-extras.org. That
> supports Hg and it supports "any OSI license". We can indefinitely
> retain history there without it being "part of" our ASF project.
+1 - a great idea.
>
> While it means that we won't have history in svn, it does mean that
> we'll have full history available to us. And in its natural Hg state.
>
> ... more later, but I just wanted to get that thought out there.
Regards,
Dave
>
> Thanks,
> -g
Re: OOO340 to svn
Posted by Eike Rathke <oo...@erack.de>.
Hi Stephan,
On Wednesday, 2011-08-03 10:22:08 +0200, Stephan Bergmann wrote:
> On Aug 3, 2011, at 12:28 AM, Eike Rathke wrote:
> > The problem with binfilter is that it depends on modules not in
> > binfilter, changing them incompatibly may entail changes necessary to
> > binfilter, those changes should be in one changeset, which I think is
> > not possible when not in trunk, insights anyone?
>
> With svn, there would be no problem having a single changeset span
> multiple directories like trunk and some other directory.
Ah, ok, my living with SVN was long ago ;-) and we never used such
a structure. Then separating binfilter is of course desirable.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: OOO340 to svn - directory setup
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On Wed, Aug 3, 2011 at 8:45 AM, IngridvdM <In...@gmx-topmail.de> wrote:
> Am 03.08.2011 08:12, schrieb Jürgen Schmidt:
>
>> On Wed, Aug 3, 2011 at 12:28 AM, Eike Rathke<oo...@erack.de> wrote:
>>
>> Hi IngridvdM,
>>>
>>> On Tuesday, 2011-08-02 20:17:52 +0200, IngridvdM wrote:
>>>
>>> The Hg archive should simply replicate the current structure at OOo,
>>>>> also for ease of adding in pending CWSs as branches, so a separate l10n
>>>>> repository.
>>>>>
>>>>> Another good argument to separate l10n from trunk was given in an
>>>> earlier thread: This way it is easier for developers to get only
>>>> what they will need usually and spare the extra time and space.
>>>>
>>>> I think this is a good argument and I wonder whether we shouldn't be
>>>> prepared to identify more such stuff - for example the binfilter.
>>>>
>>>
>>> The problem with binfilter is that it depends on modules not in
>>> binfilter, changing them incompatibly may entail changes necessary to
>>> binfilter, those changes should be in one changeset, which I think is
>>> not possible when not in trunk, insights anyone?
>>>
>>>
>>> well binfilter is maybe not the best example because in the long term we
>> should think about the elimination of binfilter completely. Announcing the
>> end of life of these filters, then allow the import only for some time and
>> the next step is to drop it ...
>>
>> Ok agreed, binfilter is not the best example.
> But what about the general idea to have a second directory where we can
> place all the stuff that is not needed to build the main office (so not
> needed in the usual day to day work of a code developer), but anyhow belongs
> to the product and to each codeline/release.
> Maybe templates or some extensions could qualify for this stuff. Maybe we
> have nothing right now but my point is, if we identify such things later I
> do not want to clutter the directory structure with more and more
> directories next to trunk.
>
> I think even that it would be more natural to have those main office
> components and the extras components both within trunk. That should also
> ease the creation of release branches.
> So another suggestion for the directory setup:
>
> ooo/trunk/main
> with all the other main office modules
> ooo/trunk/main/sw (writer)
> ooo/trunk/main/sc (calc)
> ooo/trunk/main/sd (draw)
> ooo/trunk/main/chart2 (chart)
> ...
> ooo/trunk/extras
> with l10n and maybe more stuff later
> ooo/trunk/extras/l10n
>
> ooo/tags/...
> ooo/branches/...
> this could look like this for example
> ooo/branches/R3_4/main
> ooo/branches/R3_4/extras
> ooo/branches/R3_4_1/main
> ooo/branches/R3_4_1/extras
>
> ooo/site/...
>
i would definitely support such a structure but on the other side the
question is if it would be enough to trigger optional parts with appropriate
configure switches, e.g. mysql-connector-enabled. Extensions are somewhat
special because they can be provided as standalone extension packages or
they can be bundled. And therefor both directory structures can make sense.
But for the i18n stuff i would definitely separate it as you propose because
we have the main language English in the main repository. And of course as
you already mentioned we can identify useful parts that should belong to the
extra repo later.
Juergen
>
> Kind regards,
> Ingrid
>
> Juergen
>>
>>
>>
>> Eike
>>>
>>> --
>>> PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
>>> Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
>>>
>>>
>>
>
Re: OOO340 to svn - directory setup
Posted by Ingrid von der Mehden <In...@gmx-topmail.de>.
Am 03.08.2011 21:23, schrieb Mathias Bauer:
> On 03.08.2011 10:38, IngridvdM wrote:
>
>> Am 03.08.2011 10:24, schrieb Stephan Bergmann:
>>> On Aug 3, 2011, at 8:45 AM, IngridvdM wrote:
>>>> Ok agreed, binfilter is not the best example.
>>>> But what about the general idea to have a second directory where we can place all the stuff that is not needed to build the main office (so not needed in the usual day to day work of a code developer), but anyhow belongs to the product and to each codeline/release.
>>>> Maybe templates or some extensions could qualify for this stuff. Maybe we have nothing right now but my point is, if we identify such things later I do not want to clutter the directory structure with more and more directories next to trunk.
>>>
>>> Remember, with svn the complete directory structure can always be changed. So I see no need to come up with a perfect solution up front.
>>>
>> It is not only svn to think about. When it comes to building and
>> packaging and creation of release branches there is easily a lot of
>> scripting involved. Those things are often not so nice to change
>> afterwards. So may we can think a day or two about a good directory
>> structure before. ;-)
>
> As Stephan wrote, the structure can be changed easily afterwards.
> Building and packaging should follow dependencies (after all that was
> the idea of our new build environment) and so the directory structure is
> of second order importance.
>
> Besides that I agree that moving parts that are already known to be no
> part of the regular OOo installation set into separate top level
> directories makes sense. We just shouldn't dive too deep into that now.
>
Agreed and it wasn't my point to dive deep into which single parts
should be moved around. My point was only to prepare that we can move
parts with less hassle later. I just want to prepare the target
directory for such moves. Nothing more, nothing less. It is really a
quite simple and quick question that could be solved right now.
What directory setup do you prefer and why:
1)
ooo/trunk/main/sw
ooo/trunk/extras/l10n
or 2)
ooo/trunk/sw
ooo/l10n
I would prefer 1) because it accumulates all that belongs to the trunk
code line in the trunk directory, while still allowing to easily check
out only one directory for the typical day to day code development.
Collecting more and more directories outside trunk that logically would
belong to trunk, will complicate the creation of release branches
unnecessarily. In addition something that is not logically is a problem
in itself, because it confuses people.
Kind regards,
Ingrid
> Regards,
> Mathias
>
Re: OOO340 to svn - directory setup
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
Hi;
--- On Wed, 8/3/11, Mathias Bauer wrote:
...
>
> As Stephan wrote, the structure can be changed easily
> afterwards.
> Building and packaging should follow dependencies (after
> all that was the idea of our new build environment) and
> so the directory structure is of second order importance.
>
> Besides that I agree that moving parts that are already
> known to be no part of the regular OOo installation set
> into separate top level directories makes sense. We just
> shouldn't dive too deep into that now.
>
I agree.
Moving around the directory structure would break bugzilla
patches and make it difficult to merge some branches. We
should really wait a bit and let the dust settle first.
cheers,
Pedro.
Re: OOO340 to svn - directory setup
Posted by Mathias Bauer <Ma...@gmx.net>.
On 03.08.2011 10:38, IngridvdM wrote:
> Am 03.08.2011 10:24, schrieb Stephan Bergmann:
>> On Aug 3, 2011, at 8:45 AM, IngridvdM wrote:
>>> Ok agreed, binfilter is not the best example.
>>> But what about the general idea to have a second directory where we can place all the stuff that is not needed to build the main office (so not needed in the usual day to day work of a code developer), but anyhow belongs to the product and to each codeline/release.
>>> Maybe templates or some extensions could qualify for this stuff. Maybe we have nothing right now but my point is, if we identify such things later I do not want to clutter the directory structure with more and more directories next to trunk.
>>
>> Remember, with svn the complete directory structure can always be changed. So I see no need to come up with a perfect solution up front.
>>
> It is not only svn to think about. When it comes to building and
> packaging and creation of release branches there is easily a lot of
> scripting involved. Those things are often not so nice to change
> afterwards. So may we can think a day or two about a good directory
> structure before. ;-)
As Stephan wrote, the structure can be changed easily afterwards.
Building and packaging should follow dependencies (after all that was
the idea of our new build environment) and so the directory structure is
of second order importance.
Besides that I agree that moving parts that are already known to be no
part of the regular OOo installation set into separate top level
directories makes sense. We just shouldn't dive too deep into that now.
Regards,
Mathias
Re: OOO340 to svn - directory setup
Posted by IngridvdM <In...@gmx-topmail.de>.
Am 03.08.2011 10:24, schrieb Stephan Bergmann:
> On Aug 3, 2011, at 8:45 AM, IngridvdM wrote:
>> Ok agreed, binfilter is not the best example.
>> But what about the general idea to have a second directory where we can place all the stuff that is not needed to build the main office (so not needed in the usual day to day work of a code developer), but anyhow belongs to the product and to each codeline/release.
>> Maybe templates or some extensions could qualify for this stuff. Maybe we have nothing right now but my point is, if we identify such things later I do not want to clutter the directory structure with more and more directories next to trunk.
>
> Remember, with svn the complete directory structure can always be changed. So I see no need to come up with a perfect solution up front.
>
It is not only svn to think about. When it comes to building and
packaging and creation of release branches there is easily a lot of
scripting involved. Those things are often not so nice to change
afterwards. So may we can think a day or two about a good directory
structure before. ;-)
Kind regards,
Ingrid
> -Stephan
Re: OOO340 to svn - directory setup
Posted by Stephan Bergmann <st...@googlemail.com>.
On Aug 3, 2011, at 8:45 AM, IngridvdM wrote:
> Ok agreed, binfilter is not the best example.
> But what about the general idea to have a second directory where we can place all the stuff that is not needed to build the main office (so not needed in the usual day to day work of a code developer), but anyhow belongs to the product and to each codeline/release.
> Maybe templates or some extensions could qualify for this stuff. Maybe we have nothing right now but my point is, if we identify such things later I do not want to clutter the directory structure with more and more directories next to trunk.
Remember, with svn the complete directory structure can always be changed. So I see no need to come up with a perfect solution up front.
-Stephan
Re: OOO340 to svn - directory setup
Posted by IngridvdM <In...@gmx-topmail.de>.
Am 03.08.2011 08:12, schrieb Jürgen Schmidt:
> On Wed, Aug 3, 2011 at 12:28 AM, Eike Rathke<oo...@erack.de> wrote:
>
>> Hi IngridvdM,
>>
>> On Tuesday, 2011-08-02 20:17:52 +0200, IngridvdM wrote:
>>
>>>> The Hg archive should simply replicate the current structure at OOo,
>>>> also for ease of adding in pending CWSs as branches, so a separate l10n
>>>> repository.
>>>>
>>> Another good argument to separate l10n from trunk was given in an
>>> earlier thread: This way it is easier for developers to get only
>>> what they will need usually and spare the extra time and space.
>>>
>>> I think this is a good argument and I wonder whether we shouldn't be
>>> prepared to identify more such stuff - for example the binfilter.
>>
>> The problem with binfilter is that it depends on modules not in
>> binfilter, changing them incompatibly may entail changes necessary to
>> binfilter, those changes should be in one changeset, which I think is
>> not possible when not in trunk, insights anyone?
>>
>>
> well binfilter is maybe not the best example because in the long term we
> should think about the elimination of binfilter completely. Announcing the
> end of life of these filters, then allow the import only for some time and
> the next step is to drop it ...
>
Ok agreed, binfilter is not the best example.
But what about the general idea to have a second directory where we can
place all the stuff that is not needed to build the main office (so not
needed in the usual day to day work of a code developer), but anyhow
belongs to the product and to each codeline/release.
Maybe templates or some extensions could qualify for this stuff. Maybe
we have nothing right now but my point is, if we identify such things
later I do not want to clutter the directory structure with more and
more directories next to trunk.
I think even that it would be more natural to have those main office
components and the extras components both within trunk. That should also
ease the creation of release branches.
So another suggestion for the directory setup:
ooo/trunk/main
with all the other main office modules
ooo/trunk/main/sw (writer)
ooo/trunk/main/sc (calc)
ooo/trunk/main/sd (draw)
ooo/trunk/main/chart2 (chart)
...
ooo/trunk/extras
with l10n and maybe more stuff later
ooo/trunk/extras/l10n
ooo/tags/...
ooo/branches/...
this could look like this for example
ooo/branches/R3_4/main
ooo/branches/R3_4/extras
ooo/branches/R3_4_1/main
ooo/branches/R3_4_1/extras
ooo/site/...
Kind regards,
Ingrid
> Juergen
>
>
>
>> Eike
>>
>> --
>> PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
>> Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
>>
>
Re: OOO340 to svn
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On Wed, Aug 3, 2011 at 12:28 AM, Eike Rathke <oo...@erack.de> wrote:
> Hi IngridvdM,
>
> On Tuesday, 2011-08-02 20:17:52 +0200, IngridvdM wrote:
>
> > >The Hg archive should simply replicate the current structure at OOo,
> > >also for ease of adding in pending CWSs as branches, so a separate l10n
> > >repository.
> > >
> > Another good argument to separate l10n from trunk was given in an
> > earlier thread: This way it is easier for developers to get only
> > what they will need usually and spare the extra time and space.
> >
> > I think this is a good argument and I wonder whether we shouldn't be
> > prepared to identify more such stuff - for example the binfilter.
>
> The problem with binfilter is that it depends on modules not in
> binfilter, changing them incompatibly may entail changes necessary to
> binfilter, those changes should be in one changeset, which I think is
> not possible when not in trunk, insights anyone?
>
>
well binfilter is maybe not the best example because in the long term we
should think about the elimination of binfilter completely. Announcing the
end of life of these filters, then allow the import only for some time and
the next step is to drop it ...
Juergen
> Eike
>
> --
> PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
> Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
>
Re: OOO340 to svn
Posted by Stephan Bergmann <st...@googlemail.com>.
On Aug 3, 2011, at 12:28 AM, Eike Rathke wrote:
> The problem with binfilter is that it depends on modules not in
> binfilter, changing them incompatibly may entail changes necessary to
> binfilter, those changes should be in one changeset, which I think is
> not possible when not in trunk, insights anyone?
With svn, there would be no problem having a single changeset span multiple directories like trunk and some other directory.
-Stephan
Re: OOO340 to svn
Posted by Eike Rathke <oo...@erack.de>.
Hi IngridvdM,
On Tuesday, 2011-08-02 20:17:52 +0200, IngridvdM wrote:
> >The Hg archive should simply replicate the current structure at OOo,
> >also for ease of adding in pending CWSs as branches, so a separate l10n
> >repository.
> >
> Another good argument to separate l10n from trunk was given in an
> earlier thread: This way it is easier for developers to get only
> what they will need usually and spare the extra time and space.
>
> I think this is a good argument and I wonder whether we shouldn't be
> prepared to identify more such stuff - for example the binfilter.
The problem with binfilter is that it depends on modules not in
binfilter, changing them incompatibly may entail changes necessary to
binfilter, those changes should be in one changeset, which I think is
not possible when not in trunk, insights anyone?
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: OOO340 to svn
Posted by IngridvdM <In...@gmx-topmail.de>.
Am 01.08.2011 23:31, schrieb Eike Rathke:
>
> The Hg archive should simply replicate the current structure at OOo,
> also for ease of adding in pending CWSs as branches, so a separate l10n
> repository.
>
Another good argument to separate l10n from trunk was given in an
earlier thread: This way it is easier for developers to get only what
they will need usually and spare the extra time and space.
I think this is a good argument and I wonder whether we shouldn't be
prepared to identify more such stuff - for example the binfilter.
So what I would like to consider is whether we should go with a
structure like:
ooo/trunk/...
ooo/extras/l10n/...
(ooo/extras/binfilter/... as possibility to add later)
instead of:
ooo/trunk/...
ooo/l10n/...
The name extras is of course open to discuss also.
Opinions?
Ingrid
> For SVN I think l10n as sibling to trunk would be best.
>
> Eike
>
Re: OOO340 to svn
Posted by Eike Rathke <oo...@erack.de>.
Hi Rob,
On Monday, 2011-08-01 16:33:59 -0400, Rob Weir wrote:
> So where are we with this? The last I heard, the proposal was to
> store an archival version of the Hg repositories at apache-extras [1]
> and then to check the tip into SVN.
Yes, AFAIR there was no objection.
> I suppose one remaining thing to close on would be the repository
> structure. Do we want to merge the translation and the code
> repositories into one? Keep them as separate paths in the same
> repository? Or have them in separate repositories? This is an issue
> for both the tip checkin into SVN as well as the Hg archive.
The Hg archive should simply replicate the current structure at OOo,
also for ease of adding in pending CWSs as branches, so a separate l10n
repository.
For SVN I think l10n as sibling to trunk would be best.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: OOO340 to svn
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/01/2011 10:33 PM, schrieb Rob Weir:
> So where are we with this? The last I heard, the proposal was to
> store an archival version of the Hg repositories at apache-extras [1]
> and then to check the tip into SVN.
>
> Were there any objections to this approach? Yes, I know it is not
AFAIK no.
> ideal. But ideal doesn't seem to be working very well right now ;-)
The ideal way would be to migrate stuff from HG to SVN. But I think
anybody has understood in the meantime that this would result in data
loss (history).
> I suppose one remaining thing to close on would be the repository
> structure. Do we want to merge the translation and the code
> repositories into one? Keep them as separate paths in the same
> repository? Or have them in separate repositories? This is an issue
> for both the tip checkin into SVN as well as the Hg archive.
At Oracle we have separated the L10N stuff from the normal code to
simplify things. We should continue this, so everybody can build the
office like he/she wants without to be forced to integrate all
languages. Mostly en-US is the most preferred one.
As Apache has only one repository for everything there is no question to
split into separate ones. But we should store the L10N code in separate
pathes.
In apache-extras we should do an 1:1 transfer, so 1 repo for the code
and 1 for L10N.
My 2 ct.
Marcus
> On Fri, Jul 29, 2011 at 12:11 PM, Malte Timmermann
> <ma...@gmx.com> wrote:
>>
>>
>> On 28.07.2011 12:37, Eike Rathke wrote:
>>>
>>> Hi Greg,
>>>
>>> On Thursday, 2011-07-28 00:41:40 -0400, Greg Stein wrote:
>>>
>>>> 1) import just the OOO340 tip into svn
>>>> 2) move all the Hg repositories over to apache-extras.org. That
>>>> supports Hg and it supports "any OSI license". We can indefinitely
>>>> retain history there without it being "part of" our ASF project.
>>>
>>> +1
>>
>> Yes - sounds good! :)
>>
>> Malte.
Re: OOO340 to svn
Posted by Rob Weir <ap...@robweir.com>.
So where are we with this? The last I heard, the proposal was to
store an archival version of the Hg repositories at apache-extras [1]
and then to check the tip into SVN.
Were there any objections to this approach? Yes, I know it is not
ideal. But ideal doesn't seem to be working very well right now ;-)
I suppose one remaining thing to close on would be the repository
structure. Do we want to merge the translation and the code
repositories into one? Keep them as separate paths in the same
repository? Or have them in separate repositories? This is an issue
for both the tip checkin into SVN as well as the Hg archive.
-Rob
[1] http://code.google.com/a/apache-extras.org/p/ooo/
On Fri, Jul 29, 2011 at 12:11 PM, Malte Timmermann
<ma...@gmx.com> wrote:
>
>
> On 28.07.2011 12:37, Eike Rathke wrote:
>>
>> Hi Greg,
>>
>> On Thursday, 2011-07-28 00:41:40 -0400, Greg Stein wrote:
>>
>>> 1) import just the OOO340 tip into svn
>>> 2) move all the Hg repositories over to apache-extras.org. That
>>> supports Hg and it supports "any OSI license". We can indefinitely
>>> retain history there without it being "part of" our ASF project.
>>
>> +1
>
> Yes - sounds good! :)
>
> Malte.
>
Re: OOO340 to svn
Posted by Malte Timmermann <ma...@gmx.com>.
On 28.07.2011 12:37, Eike Rathke wrote:
> Hi Greg,
>
> On Thursday, 2011-07-28 00:41:40 -0400, Greg Stein wrote:
>
>> 1) import just the OOO340 tip into svn
>> 2) move all the Hg repositories over to apache-extras.org. That
>> supports Hg and it supports "any OSI license". We can indefinitely
>> retain history there without it being "part of" our ASF project.
>
> +1
Yes - sounds good! :)
Malte.
FW: OOO340 to svn
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Ahem.
-----Original Message-----
From: Greg Stein [mailto:gstein@gmail.com]
Sent: Thursday, July 28, 2011 04:56
To: ooo-dev@incubator.apache.org
Subject: Re: OOO340 to svn
[ ... ]
I have created "ooo" on apache-extras, but would like to give a full 72 hour
discussion to see what support looks like. This does mean that we will only
have "tip" in svn. That needs some thought and acceptance before we do that.
Cheers,
-g
Re: OOO340 to svn
Posted by Greg Stein <gs...@gmail.com>.
On Jul 28, 2011 3:38 AM, "Eike Rathke" <oo...@erack.de> wrote:
>
> Hi Greg,
>
> On Thursday, 2011-07-28 00:41:40 -0400, Greg Stein wrote:
>
> > 1) import just the OOO340 tip into svn
> > 2) move all the Hg repositories over to apache-extras.org. That
> > supports Hg and it supports "any OSI license". We can indefinitely
> > retain history there without it being "part of" our ASF project.
>
> +1
>
> This should be a fast going approach and is congruent with the opinion
> voiced by others in the thread of
>
> Message-ID: <j0...@dough.gmane.org>
>
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201107.mbox/%3Cj04sqo$mj0$1@dough.gmane.org%3E
>
> where Michael Stahl proposed #3 to commit OOO340 tip. If it's possible
> to copy the hg repos to apache-extras.org I think there's all the
> project needs.
Right. I saw where consensus was heading on those threads, and my own
education on how Hg works and the available tooling. It would be awesome to
get the history converted, but realistically...
Sigh.
>
> Actually I don't get why we still waste time discussing this, it seems
> to have turned out that retaining full history in hg->svn is not
> possible without manual intervention and lot of work, so use the next
> feasible solution.
We talk about it because we are optimistic, and we are hopeful.
I have created "ooo" on apache-extras, but would like to give a full 72 hour
discussion to see what support looks like. This does mean that we will only
have "tip" in svn. That needs some thought and acceptance before we do that.
Cheers,
-g
Re: OOO340 to svn
Posted by Eike Rathke <oo...@erack.de>.
Hi Greg,
On Thursday, 2011-07-28 00:41:40 -0400, Greg Stein wrote:
> 1) import just the OOO340 tip into svn
> 2) move all the Hg repositories over to apache-extras.org. That
> supports Hg and it supports "any OSI license". We can indefinitely
> retain history there without it being "part of" our ASF project.
+1
This should be a fast going approach and is congruent with the opinion
voiced by others in the thread of
Message-ID: <j0...@dough.gmane.org>
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201107.mbox/%3Cj04sqo$mj0$1@dough.gmane.org%3E
where Michael Stahl proposed #3 to commit OOO340 tip. If it's possible
to copy the hg repos to apache-extras.org I think there's all the
project needs.
Actually I don't get why we still waste time discussing this, it seems
to have turned out that retaining full history in hg->svn is not
possible without manual intervention and lot of work, so use the next
feasible solution.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: OOO340 to svn
Posted by Rob Weir <ap...@robweir.com>.
On Thu, Jul 28, 2011 at 3:01 PM, florent andré
<fl...@4sengines.com> wrote:
>
>
> On 07/28/2011 08:50 PM, Jens-Heiner Rechtien wrote:
>>
>> On 07/28/2011 08:37 PM, florent andré wrote:
>>>
>>>
>>> On 07/28/2011 08:00 PM, Rob Weir wrote:
>>>>
>>>> On Thu, Jul 28, 2011 at 12:41 AM, Greg Stein<gs...@gmail.com> wrote:
>>>>>
>>>>> On Wed, Jul 27, 2011 at 21:23, Dennis E. Hamilton
>>>>> <de...@acm.org> wrote:
>>>
>>> ...
>>>>
>>>> It says we have a "storage quota" of 4096 MB. I'm uncertain whether
>>>> that is for releases, or includes repository storage as well.
>>>
>>> Ha... full hg import is 70+ Gb [1].
>>>
>>> [1]
>>>
>>> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201107.mbox/%3CCABD8fLWAn1afWKDmdD46G302XJhZRjdeao+-OeY4Mca5gEpNNg@mail.gmail.com%3E
>>>
>>>
>>>
>>
>> I think we have already established that a proper hg repository
>> including all active CWSs is around 3 GB if done in a proper way. And
>> it's read-only so it would fit neatly into the storage quota. Converting
>> the repository into git is fine with me, but the last time I tried the
>> conversion it resulted in a larger repository than the Mercurial one
>> which is a bit surprising. Probably an artifact of the conversion tool.
>
> Yes, sure, nearly the double :
> $ du -h git_repos --summarize
> 6.6G git_repos
> $ du -h OOO340_local --summarize
> 3.5G OOO340_local
>
> If any one have an idea of the cause... could be interesting for general
> culture.
>
> By the way how do you get a 3Gb with all (active) cws when OOO340 already
> size 3,5 ?
That's what Greg reported for his single-hg.sh script. That cloned
OOO340 and then pull'ed down each of the CWS's. More info here:
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201107.mbox/%3CCABD8fLWAn1afWKDmdD46G302XJhZRjdeao+-OeY4Mca5gEpNNg@mail.gmail.com%3E
-Rob
>
> ++
>
>
>
>>
>> Heiner
>>
>
Re: OOO340 to svn
Posted by florent andré <fl...@4sengines.com>.
On 07/28/2011 08:50 PM, Jens-Heiner Rechtien wrote:
> On 07/28/2011 08:37 PM, florent andré wrote:
>>
>>
>> On 07/28/2011 08:00 PM, Rob Weir wrote:
>>> On Thu, Jul 28, 2011 at 12:41 AM, Greg Stein<gs...@gmail.com> wrote:
>>>> On Wed, Jul 27, 2011 at 21:23, Dennis E. Hamilton
>>>> <de...@acm.org> wrote:
>> ...
>>>
>>> It says we have a "storage quota" of 4096 MB. I'm uncertain whether
>>> that is for releases, or includes repository storage as well.
>>
>> Ha... full hg import is 70+ Gb [1].
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201107.mbox/%3CCABD8fLWAn1afWKDmdD46G302XJhZRjdeao+-OeY4Mca5gEpNNg@mail.gmail.com%3E
>>
>>
>>
>
> I think we have already established that a proper hg repository
> including all active CWSs is around 3 GB if done in a proper way. And
> it's read-only so it would fit neatly into the storage quota. Converting
> the repository into git is fine with me, but the last time I tried the
> conversion it resulted in a larger repository than the Mercurial one
> which is a bit surprising. Probably an artifact of the conversion tool.
Yes, sure, nearly the double :
$ du -h git_repos --summarize
6.6G git_repos
$ du -h OOO340_local --summarize
3.5G OOO340_local
If any one have an idea of the cause... could be interesting for
general culture.
By the way how do you get a 3Gb with all (active) cws when OOO340
already size 3,5 ?
++
>
> Heiner
>
Re: OOO340 to svn
Posted by Jens-Heiner Rechtien <jh...@web.de>.
On 07/28/2011 08:37 PM, florent andré wrote:
>
>
> On 07/28/2011 08:00 PM, Rob Weir wrote:
>> On Thu, Jul 28, 2011 at 12:41 AM, Greg Stein<gs...@gmail.com> wrote:
>>> On Wed, Jul 27, 2011 at 21:23, Dennis E. Hamilton
>>> <de...@acm.org> wrote:
> ...
>>
>> It says we have a "storage quota" of 4096 MB. I'm uncertain whether
>> that is for releases, or includes repository storage as well.
>
> Ha... full hg import is 70+ Gb [1].
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201107.mbox/%3CCABD8fLWAn1afWKDmdD46G302XJhZRjdeao+-OeY4Mca5gEpNNg@mail.gmail.com%3E
>
>
I think we have already established that a proper hg repository
including all active CWSs is around 3 GB if done in a proper way. And
it's read-only so it would fit neatly into the storage quota. Converting
the repository into git is fine with me, but the last time I tried the
conversion it resulted in a larger repository than the Mercurial one
which is a bit surprising. Probably an artifact of the conversion tool.
Heiner
--
Jens-Heiner Rechtien
Re: OOO340 to svn
Posted by florent andré <fl...@4sengines.com>.
On 07/28/2011 08:00 PM, Rob Weir wrote:
> On Thu, Jul 28, 2011 at 12:41 AM, Greg Stein<gs...@gmail.com> wrote:
>> On Wed, Jul 27, 2011 at 21:23, Dennis E. Hamilton
>> <de...@acm.org> wrote:
...
>
> It says we have a "storage quota" of 4096 MB. I'm uncertain whether
> that is for releases, or includes repository storage as well.
Ha... full hg import is 70+ Gb [1].
[1]
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201107.mbox/%3CCABD8fLWAn1afWKDmdD46G302XJhZRjdeao+-OeY4Mca5gEpNNg@mail.gmail.com%3E
Re: OOO340 to svn
Posted by Rob Weir <ap...@robweir.com>.
On Thu, Jul 28, 2011 at 12:41 AM, Greg Stein <gs...@gmail.com> wrote:
> On Wed, Jul 27, 2011 at 21:23, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> TBD = To Be Determined/Defined
>>
>> There was extensive discussion with Greg Stein and Marcus (and others) in previous weeks on this list. Greg's last post was July 9, as previously noted. There has been further work/discussion by Mathias Bauer, Michael Stahl, Marcus Lange, Eike Rathke, and others.
>
> Yup. Sorry about being away. The Apache Subversion project created its
> 1.7.x stabilization branch for our upcoming 1.7 release. This has been
> two years in the making, so it has been a Big Deal. I haven't had the
> time to properly dedicate here.
>
> I've read some of the threads, and will need to cut this short (at
> OSCON right now). In short, I saw a concern about how to handle the
> two-parent merges. That was also becoming a concern of mine, but
> hadn't quite reached the "geez. I dunno" stage.
>
> With these various conversion issues, I might be coming around to just
> saying "not really possible with the current set of tools today". I'll
> talk to a friend of mine to see if they have something that can help
> (his company does a lot of version control work, and they may have
> ideas/tooling).
>
> In the meantime, and I can dig in more this weekend once I get home,
> I'll suggest one possible road for us:
>
> 1) import just the OOO340 tip into svn
> 2) move all the Hg repositories over to apache-extras.org. That
> supports Hg and it supports "any OSI license". We can indefinitely
> retain history there without it being "part of" our ASF project.
>
> While it means that we won't have history in svn, it does mean that
> we'll have full history available to us. And in its natural Hg state.
>
> ... more later, but I just wanted to get that thought out there.
>
Very interesting. I had seen apache-extras.org mentioned before but
didn't notice that it supported Hg.
I've gone ahead and created a project there called "Hamburger", an
homage to the residents of Hamburg, the city where OpenOffice
originated.
http://code.google.com/a/apache-extras.org/p/hamburger/
It says we have a "storage quota" of 4096 MB. I'm uncertain whether
that is for releases, or includes repository storage as well.
Whoever needs commit rights, please send me your email, especially any
one that you already use for Google Code. Send off list if preferred.
Thanks!
> Thanks,
> -g
>
Re: OOO340 to svn
Posted by Carl Marcum <cm...@apache.org>.
On 07/28/2011 12:41 AM, Greg Stein wrote:
<snip>
> In the meantime, and I can dig in more this weekend once I get home,
> I'll suggest one possible road for us:
>
> 1) import just the OOO340 tip into svn
> 2) move all the Hg repositories over to apache-extras.org. That
> supports Hg and it supports "any OSI license". We can indefinitely
> retain history there without it being "part of" our ASF project.
>
> While it means that we won't have history in svn, it does mean that
> we'll have full history available to us. And in its natural Hg state.
>
> ... more later, but I just wanted to get that thought out there.
>
> Thanks,
> -g
>
+1 - Great Idea. This seems like the best path forward.
Thanks,
Carl
Re: OOO340 to svn
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Jul 27, 2011 at 21:23, Dennis E. Hamilton
<de...@acm.org> wrote:
> TBD = To Be Determined/Defined
>
> There was extensive discussion with Greg Stein and Marcus (and others) in previous weeks on this list. Greg's last post was July 9, as previously noted. There has been further work/discussion by Mathias Bauer, Michael Stahl, Marcus Lange, Eike Rathke, and others.
Yup. Sorry about being away. The Apache Subversion project created its
1.7.x stabilization branch for our upcoming 1.7 release. This has been
two years in the making, so it has been a Big Deal. I haven't had the
time to properly dedicate here.
I've read some of the threads, and will need to cut this short (at
OSCON right now). In short, I saw a concern about how to handle the
two-parent merges. That was also becoming a concern of mine, but
hadn't quite reached the "geez. I dunno" stage.
With these various conversion issues, I might be coming around to just
saying "not really possible with the current set of tools today". I'll
talk to a friend of mine to see if they have something that can help
(his company does a lot of version control work, and they may have
ideas/tooling).
In the meantime, and I can dig in more this weekend once I get home,
I'll suggest one possible road for us:
1) import just the OOO340 tip into svn
2) move all the Hg repositories over to apache-extras.org. That
supports Hg and it supports "any OSI license". We can indefinitely
retain history there without it being "part of" our ASF project.
While it means that we won't have history in svn, it does mean that
we'll have full history available to us. And in its natural Hg state.
... more later, but I just wanted to get that thought out there.
Thanks,
-g
RE: OOO340 to svn
Posted by "Dennis E. Hamilton" <de...@acm.org>.
TBD = To Be Determined/Defined
There was extensive discussion with Greg Stein and Marcus (and others) in previous weeks on this list. Greg's last post was July 9, as previously noted. There has been further work/discussion by Mathias Bauer, Michael Stahl, Marcus Lange, Eike Rathke, and others.
It seems to have become unclear exactly where we are heading.
Where are we heading?
- Dennis
-----Original Message-----
From: florent andré [mailto:florent.andre-dev@4sengines.com]
Sent: Wednesday, July 27, 2011 15:42
To: ooo-dev@incubator.apache.org
Subject: Re: OOO340 to svn
..
>
> ergh
>
> Have you guys not been following what Greg Stein and co have been doing in svn
> and on this list with regards to a conversion tool?
May I really miss something, but what's on single-hg is a hg
concatenation tool.
This file have this in notice :
"See <TBD> for converting the resulting repository to Subversion,"
I admit to not see what TDB stand for...
++
[1]
http://svn.apache.org/viewvc/incubator/ooo/trunk/tools/dev/single-hg.sh?revision=1144587&view=markup
Re: OOO340 to svn
Posted by florent andré <fl...@4sengines.com>.
..
>
> ergh
>
> Have you guys not been following what Greg Stein and co have been doing in svn
> and on this list with regards to a conversion tool?
May I really miss something, but what's on single-hg is a hg
concatenation tool.
This file have this in notice :
"See <TBD> for converting the resulting repository to Subversion,"
I admit to not see what TDB stand for...
++
[1]
http://svn.apache.org/viewvc/incubator/ooo/trunk/tools/dev/single-hg.sh?revision=1144587&view=markup
Re: OOO340 to svn
Posted by Rob Weir <ap...@robweir.com>.
On Wed, Jul 27, 2011 at 5:41 PM, Gavin McDonald <ga...@16degrees.com.au> wrote:
>
>
>> -----Original Message-----
>> From: Rob Weir [mailto:apache@robweir.com]
>> Sent: Thursday, 28 July 2011 6:14 AM
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: OOO340 to svn
>>
>> Can we review what has been attempted and what has failed? I want to
>> make sure we understand the dead-ends, so we don't retrace them.
>>
>> 1) Have we tried posting to the Apache subversion user list? Perhaps
>> someone there has an idea or tool that we have not thought of? Or maybe
>> this would be an interesting problem that they might be willing to help with?
>
> You have svn devs right here on this list, use them.
>
>>
>> 2) I assume someone has tried the Hg "convert" extensions, e.g., hg convert
>> --dest-type svn hgreponame svnreponame . If so, what didn't work right?
>
> there is branch and history issues with this.
>>
>> 3) Tailor? http://progetti.arstecnica.it/tailor Probably not very
>> fast, but looks very flexible.
>
> ergh
>
> Have you guys not been following what Greg Stein and co have been doing in svn
> and on this list with regards to a conversion tool?
>
> Greg for those that don’t know is an svn dev and you'll find no-one better here to
> lead the effort on getting this import done. I would concentrate your efforts there.
>
The latest I've seen on Greg's efforts was from July 9th:
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201107.mbox/%3CCABD8fLWAn1afWKDmdD46G302XJhZRjdeao+-OeY4Mca5gEpNNg@mail.gmail.com%3E
It looks like a great start, but still a sizable list of remaining
tasks. He asked for help, but I didn't see anyone take him up on that
in the past three weeks. it is worth renewing that call, in case
anyone missed it. But I'm not sure if we have others on the list with
sufficient SVN hacking skills.
Although I'd love a comprehensive solution, of the kind Greg has
outlined, I also am willing to consider the possibility that "good
enough" works as well. And if we don't see additional progress on the
migrating the CWS's to branches, then a trunk-only migration would be
the obvious Plan B.
> Gav..
>
> http://svn.apache.org/viewvc/incubator/ooo/trunk/tools/dev/
>
> http://mail-archives.apache.org/mod_mbox/incubator-ooo-commits/201107.mbox/%3c20110709033659.B586323888CF@eris.apache.org%3e
>
>
>
>
RE: OOO340 to svn
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Rob Weir [mailto:apache@robweir.com]
> Sent: Thursday, 28 July 2011 6:14 AM
> To: ooo-dev@incubator.apache.org
> Subject: Re: OOO340 to svn
>
> Can we review what has been attempted and what has failed? I want to
> make sure we understand the dead-ends, so we don't retrace them.
>
> 1) Have we tried posting to the Apache subversion user list? Perhaps
> someone there has an idea or tool that we have not thought of? Or maybe
> this would be an interesting problem that they might be willing to help with?
You have svn devs right here on this list, use them.
>
> 2) I assume someone has tried the Hg "convert" extensions, e.g., hg convert
> --dest-type svn hgreponame svnreponame . If so, what didn't work right?
there is branch and history issues with this.
>
> 3) Tailor? http://progetti.arstecnica.it/tailor Probably not very
> fast, but looks very flexible.
ergh
Have you guys not been following what Greg Stein and co have been doing in svn
and on this list with regards to a conversion tool?
Greg for those that don’t know is an svn dev and you'll find no-one better here to
lead the effort on getting this import done. I would concentrate your efforts there.
Gav..
http://svn.apache.org/viewvc/incubator/ooo/trunk/tools/dev/
http://mail-archives.apache.org/mod_mbox/incubator-ooo-commits/201107.mbox/%3c20110709033659.B586323888CF@eris.apache.org%3e
Re: OOO340 to svn
Posted by Rob Weir <ap...@robweir.com>.
Can we review what has been attempted and what has failed? I want to
make sure we understand the dead-ends, so we don't retrace them.
1) Have we tried posting to the Apache subversion user list? Perhaps
someone there has an idea or tool that we have not thought of? Or
maybe this would be an interesting problem that they might be willing
to help with?
2) I assume someone has tried the Hg "convert" extensions, e.g., hg
convert --dest-type svn hgreponame svnreponame . If so, what didn't
work right?
3) Tailor? http://progetti.arstecnica.it/tailor Probably not very
fast, but looks very flexible.
Re: OOO340 to svn
Posted by florent andré <fl...@4sengines.com>.
Comments inside
On 07/26/2011 05:44 PM, Pedro F. Giffuni wrote:
>
>
> --- On Tue, 7/26/11, Christian Lohmaier<cl...@openoffice.org> wrote:
>
>>
>> Well, do some over-the-thumb-maths please and see that this
>> approach is doomed. 260000 linear revisions (the "easy part"),
>> and you can do 500 in two hours.
>> You need around 1040 hours, or more than 40 days to do the
>> conversion this way.
No ! really ? Thanks to over-the-thumb-maths, my insane brain now have a
better evaluation of result/time ratio...
>>
>
> This is certainly a problem :(. Perhaps it will be faster if
> done in the same LAN of the physical repository?
For testing, I set up a machine with svn serveur and the script (so no
lan delay).
In fact the processing time was almost the same, the costly part of the
script seems to be the empty folder remove...
>
> Is the converter that comes with Hg, worse?
Don't work for me. Try with mercurial 1.9 version, but fall down with a
strange python error.
>
>
>> And that is only the time until you very likely hit the
>> point where
>> the conversion will bail out "sorry, can not deal with
>> merges". This
>> is insane...
>>
>
> It doesn't seem like it will bail out but the script does have
> some documented issues:
>
> * no handling of branches
> * all commits come from the user running the script
yes true, but the name of the original commiter is in the commit's
comments, and that's the better things we can have, because not all the
original commiters have an Apache's svn account, and even if it's the
case it will really complicated any script.
++
> * move operations probably won't appear in the history as such
>
> Nevertheless thanks to Florent for trying and reporting.
>
> cheers,
>
> Pedro.
Re: OOO340 to svn
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
--- On Tue, 7/26/11, Christian Lohmaier <cl...@openoffice.org> wrote:
>
> Well, do some over-the-thumb-maths please and see that this
> approach is doomed. 260000 linear revisions (the "easy part"),
> and you can do 500 in two hours.
> You need around 1040 hours, or more than 40 days to do the
> conversion this way.
>
This is certainly a problem :(. Perhaps it will be faster if
done in the same LAN of the physical repository?
Is the converter that comes with Hg, worse?
> And that is only the time until you very likely hit the
> point where
> the conversion will bail out "sorry, can not deal with
> merges". This
> is insane...
>
It doesn't seem like it will bail out but the script does have
some documented issues:
* no handling of branches
* all commits come from the user running the script
* move operations probably won't appear in the history as such
Nevertheless thanks to Florent for trying and reporting.
cheers,
Pedro.
Re: OOO340 to svn
Posted by Christian Lohmaier <cl...@openoffice.org>.
On Tue, Jul 26, 2011 at 4:17 PM, florent andré
<fl...@4sengines.com> wrote:
>
>
> On 07/26/2011 03:53 PM, Michael Stahl wrote:
>>
>> On 26.07.2011 13:51, florent andré wrote:
>
> ...
>>>
>>> But, as it simulate all svn commit, it's a little bit long...
>>> Actually on 45/276930 revision.
>>
>> well, the first 263206 revisions are the easy ones, because they're
>> linear :)
>
> ha ! So looking forward to the 263207 revision ! :)
>
> But have to be patient... now = 467/276930 !
Well, do some over-the-thumb-maths please and see that this approach is doomed.
260000 linear revisions (the "easy part"), and you can do 500 in two hours.
You need around 1040 hours, or more than 40 days to do the conversion this way.
And that is only the time until you very likely hit the point where
the conversion will bail out "sorry, can not deal with merges". This
is insane...
ciao
Christian
RE: OOO340 to svn
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: florent andré [mailto:florent.andre-dev@4sengines.com]
> Sent: Wednesday, 27 July 2011 12:18 AM
> To: ooo-dev@incubator.apache.org
> Subject: Re: OOO340 to svn
>
>
>
> On 07/26/2011 03:53 PM, Michael Stahl wrote:
> > On 26.07.2011 13:51, florent andré wrote:
> ...
<snip>
> >> If the process goes well to the end, what could be the next step ?
> >> Restart this script on the apache svn or extract some kind of svn dump
> >> from my svn-serveur and import it ?
> >
> > presumably it ought to be possible and easiest to import an SVN dump,
> > but i'm no SVN expert...
>
> I think so.
> May ask procedure to infra if import goes well.
Yes, infra will require an svn dump.
That provided dump (in someones home dir on people.a.o is easiest) will then
be imported into a test instance here where it can be reviewed and approved
before
then being imported into the live instance.
HTH
Gav...
>
> ++
>
> >
> > regards,
> > michael
> >
Re: OOO340 to svn
Posted by florent andré <fl...@4sengines.com>.
On 07/26/2011 03:53 PM, Michael Stahl wrote:
> On 26.07.2011 13:51, florent andré wrote:
...
>>
>> But, as it simulate all svn commit, it's a little bit long...
>> Actually on 45/276930 revision.
>
> well, the first 263206 revisions are the easy ones, because they're
> linear :)
ha ! So looking forward to the 263207 revision ! :)
But have to be patient... now = 467/276930 !
>
> btw, what script are you using?
This one :
http://qa-ex-consultant.blogspot.com/2009/10/converting-mercurial-repo-to-subversion.html
that work (for now) not like the mercurial export plugin that says
managing hg to svn export...
>
> what will it do with merge revisions?
hummmm, I don't know ! :)
I will give you access to my svn privately for now - I don't want to
stress too much my kind prepubescent server - if you want to check some
specific commits.
>
>> If the process goes well to the end, what could be the next step ?
>> Restart this script on the apache svn or extract some kind of svn dump
>> from my svn-serveur and import it ?
>
> presumably it ought to be possible and easiest to import an SVN dump,
> but i'm no SVN expert...
I think so.
May ask procedure to infra if import goes well.
++
>
> regards,
> michael
>
Re: OOO340 to svn
Posted by florent andré <fl...@4sengines.com>.
About hg --> git then git --> svn
== hg --> git ==
Finish !
It take approx 40h to complete (someone to math over-the-thumb ? :))
Result it that it's "seems" to import merge... I have not time for more
investigation, I copy/paste bellow outputs that give me this feeling [1].
diff -r between hg and git is really clean :
Only in git_repos/: .git
Only in OOO340_local/: .hg
Only in OOO340_local/: .hgtags
== git --> svn ==
I actually do the rebase (seems to take time), this is the penultimate
before real svn import...
I will be out of this machine tomorrow for 5 days... hope I can fire the
last command before going.
== get git repos ==
I currently upload the git repos to people.apache.org if you want to
play with.
== [1] ==
=== After ht to git command ===
Exporting tag [DEV300_m106] at [hg r276728] [git :276729]
Exporting tag [OOO340_m0] at [hg r276743] [git :276744]
Issued 277030 commands
git-fast-import statistics:
---------------------------------------------------------------------
Alloc'd objects: 2235000
Total objects: 2233937 ( 8097599 duplicates )
blobs : 549813 ( 7325130 duplicates 472589 deltas)
trees : 1407193 ( 772469 duplicates 1192144 deltas)
commits: 276931 ( 0 duplicates 0 deltas)
tags : 0 ( 0 duplicates 0 deltas)
Total branches: 100 ( 1 loads )
marks: 1048576 ( 276931 unique )
atoms: 56682
Memory total: 115159 KiB
pools: 10394 KiB
objects: 104765 KiB
---------------------------------------------------------------------
pack_report: getpagesize() = 4096
pack_report: core.packedGitWindowSize = 1073741824
pack_report: core.packedGitLimit = 8589934592
pack_report: pack_used_ctr = 20176769
pack_report: pack_mmap_calls = 702302
pack_report: pack_open_windows = 4 / 9
pack_report: pack_mapped = 3397905146 / 8589934592
---------------------------------------------------------------------
=== Git log ===
commit c1a19b7f2fbd65d7c8b8a4cb32bdf1c3b418f92c
Author: Martin Hollmichel <mh...@openoffice.org>
Date: Mon May 9 14:07:54 2011 +0200
corrected merge of gridfixes cws integration
commit 032eda538088ed2009223a8063e2c143636b6dd0
Author: Martin Hollmichel <mh...@openoffice.org>
Date: Fri May 6 08:13:12 2011 +0200
OOO340_m1
commit 9479cbfd2fc76106b1beb5e9ede70300241d23bc
Merge: 450b957 4e28838
Author: Kurt Zenker <kz...@openoffice.org>
Date: Thu Apr 14 15:47:03 2011 +0200
CWS-TOOLING: integrate CWS obic007_OOO340
commit 450b9579887579f2498d24aeff1274678ca2051e
Merge: 1b8c3ce 7b335b1
Author: Kurt Zenker <kz...@openoffice.org>
Date: Thu Apr 14 15:29:52 2011 +0200
CWS-TOOLING: integrate CWS fs34b_OOO340
commit 1b8c3ce1fcbd5d4d62ebfd28d1942d6b68e0d83e
Merge: aed026c 0461b2b
Author: Kurt Zenker <kz...@openoffice.org>
Date: Thu Apr 14 13:14:35 2011 +0200
CWS-TOOLING: integrate CWS l10ndev300m106_OOO340
== git fetch origin ==
From /home/florent/dev/dev-apache/OoO/import/git_repos
* [new branch] master -> origin/master
From /home/florent/dev/dev-apache/OoO/import/git_repos
* [new tag] DEV300_last_svn_milestone -> DEV300_last_svn_milestone
* [new tag] DEV300_m100 -> DEV300_m100
* [new tag] DEV300_m101 -> DEV300_m101
* [new tag] DEV300_m102 -> DEV300_m102
* [new tag] DEV300_m103 -> DEV300_m103
* [new tag] DEV300_m104 -> DEV300_m104
* [new tag] DEV300_m105 -> DEV300_m105
* [new tag] DEV300_m106 -> DEV300_m106
* [new tag] DEV300_m31 -> DEV300_m31
* [new tag] DEV300_m32 -> DEV300_m32
* [new tag] DEV300_m33 -> DEV300_m33
* [new tag] DEV300_m34 -> DEV300_m34
* [new tag] DEV300_m35 -> DEV300_m35
* [new tag] DEV300_m36 -> DEV300_m36
* [new tag] DEV300_m37 -> DEV300_m37
* [new tag] DEV300_m38 -> DEV300_m38
* [new tag] DEV300_m39 -> DEV300_m39
* [new tag] DEV300_m40 -> DEV300_m40
* [new tag] DEV300_m41 -> DEV300_m41
* [new tag] DEV300_m42 -> DEV300_m42
* [new tag] DEV300_m43 -> DEV300_m43
* [new tag] DEV300_m44 -> DEV300_m44
* [new tag] DEV300_m45 -> DEV300_m45
* [new tag] DEV300_m46 -> DEV300_m46
* [new tag] DEV300_m47 -> DEV300_m47
* [new tag] DEV300_m48 -> DEV300_m48
...
* [new tag] OOO330_m13 -> OOO330_m13
* [new tag] OOO330_m14 -> OOO330_m14
* [new tag] OOO330_m15 -> OOO330_m15
* [new tag] OOO330_m16 -> OOO330_m16
* [new tag] OOO330_m17 -> OOO330_m17
* [new tag] OOO330_m18 -> OOO330_m18
* [new tag] OOO330_m19 -> OOO330_m19
* [new tag] OOO330_m2 -> OOO330_m2
* [new tag] OOO330_m20 -> OOO330_m20
* [new tag] OOO330_m3 -> OOO330_m3
* [new tag] OOO330_m4 -> OOO330_m4
* [new tag] OOO330_m5 -> OOO330_m5
* [new tag] OOO330_m6 -> OOO330_m6
* [new tag] OOO330_m7 -> OOO330_m7
* [new tag] OOO330_m8 -> OOO330_m8
* [new tag] OOO330_m9 -> OOO330_m9
* [new tag] OOO340_m0 -> OOO340_m0
On 07/27/2011 06:07 PM, florent andré wrote:
> I manage(d) another try :
>
> hg --> git
>
> This is currently in process. After 20h a little bit more than 180000
> rev are exported to git.
> Will wait some hours more to see what append, but so far so good.
>
> git --> svn
>
> This is the second step of my idea, in order to see if it's more faster
> with this conversion.
> But have to wait the hg --> git finishing.
>
> hg --> svn
>
> Do another try with only the 30 last revisions with the same script
> (start revision configurable)
>
> This work pretty well (just a little special case with man@work.gif file).
> And
> $ diff -r svn-repos/ hg-repos/ > diff-result
> $ cat diff-result | grep -v ".svn"
>
> relevant results only show 2 empty folders in svn repos that are not
> still present in hg one :
> offapi/drafts/
> smoketestoo_native/com/
>
> =========
>
> So, without a really good surprise from the git --> svn conversion, it's
> clearly appear that it will not be manageable to import all history in
> svn [1].
>
> So 2 options :
>
> 1) Import all the code without history. Have to check history into hg or
> git (have to wait if conversion goes well to the end)
>
> 2) Define a "good" starting revision, were good means :
> * enough history in svn for pretty well being
> * time reasonable computation (over-the-thumb-maths says [ :) ]
> approximately 250 commits/hour)
>
>
> What do you think ?
> ++
>
>
> [1] at least with my material, may a really BIG machine can lower time,
> but I doubt it will achieve it in reasonable time.
>
>
> On 07/26/2011 03:53 PM, Michael Stahl wrote:
>> On 26.07.2011 13:51, florent andré wrote:
>>> Hi there,
>>>
>>> I actually run a script [1] on my local laptop and online svn serveur
>>> that import the OOO340 hg to an svn trunk folder.
>>>
>>> For now, it's work pretty well - get all history from OO340 - with good
>>> commit log e.g. :
>>> -------
>>> Added:
>>> ooo/trunk/trunk/xmloff/source/text/XMLTextColumnsContext.cxx
>>> Modified:
>>> ooo/trunk/trunk/xmloff/source/text/XMLTextPropertySetContext.cxx
>>> ooo/trunk/trunk/xmloff/source/text/makefile.mk
>>> Log:
>>> changeset: 41:196d10f76091
>>> user: mib
>>> date: Thu Sep 21 09:48:30 2000 +0000
>>> text column import
>>> --------
>>>
>>> But, as it simulate all svn commit, it's a little bit long...
>>> Actually on 45/276930 revision.
>>
>> well, the first 263206 revisions are the easy ones, because they're
>> linear :)
>>
>> btw, what script are you using?
>>
>> what will it do with merge revisions?
>>
>>> If the process goes well to the end, what could be the next step ?
>>> Restart this script on the apache svn or extract some kind of svn dump
>>> from my svn-serveur and import it ?
>>
>> presumably it ought to be possible and easiest to import an SVN dump,
>> but i'm no SVN expert...
>>
>> regards,
>> michael
>>
Re: OOO340 to svn
Posted by florent andré <fl...@4sengines.com>.
I manage(d) another try :
hg --> git
This is currently in process. After 20h a little bit more than 180000
rev are exported to git.
Will wait some hours more to see what append, but so far so good.
git --> svn
This is the second step of my idea, in order to see if it's more faster
with this conversion.
But have to wait the hg --> git finishing.
hg --> svn
Do another try with only the 30 last revisions with the same script
(start revision configurable)
This work pretty well (just a little special case with man@work.gif file).
And
$ diff -r svn-repos/ hg-repos/ > diff-result
$ cat diff-result | grep -v ".svn"
relevant results only show 2 empty folders in svn repos that are not
still present in hg one :
offapi/drafts/
smoketestoo_native/com/
=========
So, without a really good surprise from the git --> svn conversion, it's
clearly appear that it will not be manageable to import all history in
svn [1].
So 2 options :
1) Import all the code without history. Have to check history into hg or
git (have to wait if conversion goes well to the end)
2) Define a "good" starting revision, were good means :
* enough history in svn for pretty well being
* time reasonable computation (over-the-thumb-maths says [ :) ]
approximately 250 commits/hour)
What do you think ?
++
[1] at least with my material, may a really BIG machine can lower time,
but I doubt it will achieve it in reasonable time.
On 07/26/2011 03:53 PM, Michael Stahl wrote:
> On 26.07.2011 13:51, florent andré wrote:
>> Hi there,
>>
>> I actually run a script [1] on my local laptop and online svn serveur
>> that import the OOO340 hg to an svn trunk folder.
>>
>> For now, it's work pretty well - get all history from OO340 - with good
>> commit log e.g. :
>> -------
>> Added:
>> ooo/trunk/trunk/xmloff/source/text/XMLTextColumnsContext.cxx
>> Modified:
>> ooo/trunk/trunk/xmloff/source/text/XMLTextPropertySetContext.cxx
>> ooo/trunk/trunk/xmloff/source/text/makefile.mk
>> Log:
>> changeset: 41:196d10f76091
>> user: mib
>> date: Thu Sep 21 09:48:30 2000 +0000
>> text column import
>> --------
>>
>> But, as it simulate all svn commit, it's a little bit long...
>> Actually on 45/276930 revision.
>
> well, the first 263206 revisions are the easy ones, because they're
> linear :)
>
> btw, what script are you using?
>
> what will it do with merge revisions?
>
>> If the process goes well to the end, what could be the next step ?
>> Restart this script on the apache svn or extract some kind of svn dump
>> from my svn-serveur and import it ?
>
> presumably it ought to be possible and easiest to import an SVN dump,
> but i'm no SVN expert...
>
> regards,
> michael
>
Re: OOO340 to svn
Posted by Michael Stahl <ms...@openoffice.org>.
On 26.07.2011 13:51, florent andré wrote:
> Hi there,
>
> I actually run a script [1] on my local laptop and online svn serveur
> that import the OOO340 hg to an svn trunk folder.
>
> For now, it's work pretty well - get all history from OO340 - with good
> commit log e.g. :
> -------
> Added:
> ooo/trunk/trunk/xmloff/source/text/XMLTextColumnsContext.cxx
> Modified:
> ooo/trunk/trunk/xmloff/source/text/XMLTextPropertySetContext.cxx
> ooo/trunk/trunk/xmloff/source/text/makefile.mk
> Log:
> changeset: 41:196d10f76091
> user: mib
> date: Thu Sep 21 09:48:30 2000 +0000
> text column import
> --------
>
> But, as it simulate all svn commit, it's a little bit long...
> Actually on 45/276930 revision.
well, the first 263206 revisions are the easy ones, because they're
linear :)
btw, what script are you using?
what will it do with merge revisions?
> If the process goes well to the end, what could be the next step ?
> Restart this script on the apache svn or extract some kind of svn dump
> from my svn-serveur and import it ?
presumably it ought to be possible and easiest to import an SVN dump,
but i'm no SVN expert...
regards,
michael