[Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ro...@apache.org>]

We've been discussing for two months now how to get Hg over to SVN.
There have been several suggestions for how the CWS's and complete
revision history could be migrated over, but little progress has been
made.  Either the proposals didn't work, or no volunteers stepped
forward to implement them.

The alternative proposal was to just check in the tip of the trunk,
without history, and then migrate Hg to Apache-Extras.org, where Hg is
supported.  I've made some progress on this proposal.

Here's what I did.  I'd like some review, to make sure I didn't screw
anything up. I am neither an Hg nor a SVN expert.  But I do have a big
harddrive.

I used Subversion command-line client, version
1.6.17-SlikSvn-tag-1.6.17@1130896-WIN32.

I first brought down OOo, both the trunk and the language stuff, into
separate directories:

hg clone http://hg.services.openoffice.org/OOO340
hg clone http://hg.services.openoffice.org/master_l10n/OOO340/

I then moved these into a common directory structure, as Ingrid had
earlier suggested:

ooo/trunk/core --- all the OOO340 stuff
ooo/trunk/l10n -- all the language stuff

I removed the .Hg directories before proceeding, so I had a clean local copy.

I then created a local SVN repository, enabled auto-props to get the
proper EOL treatment and imported the project:

svn import c:\merged file:///c:/svn-repo/ -m "initial import"

During local svn import I received error messages:

"svn: Inconsistent line ending style"

This typically indicated that a text file had a mix of EOL styles
(DOS/UNIX).  But I found some cases where this was not true, but where
the problem appeared to be related to an unsupported encoding.  For
example, SVN does not seem to support UTF-16 encodings.

I received this "Inconsistent line ending style" on the following files:

ooo/trunk/core/dictionaries/de_DE/README_hyph_de_DE.txt
ooo/trunk/core/dictionaries/de_CH/README_hyph_de_CH.txt
ooo/trunk/core/dictionaries/de_AT/README_hyph_de_AT.txt
ooo/trunk/core/gettext/gettext-0.18.1.1.patch
ooo/trunk/core/apache-commons/patches/codec.patch
ooo/trunk/core/libcroco/libcrco-0.6.2.patch
ooo/trunk/core/testautomation/writer/optional/input/import/mactext.txt
ooo/trunk/core/graphite/graphite-2.3.1.patch
ooo/trunk/core/hwpfilter/source/hwpeq.cpp (some weird non-ascii text
in file, should review)
ooo/trunk/core/solenv/bin/cwstouched.pl (should review)
ooo/trunk/core/readlicense_oo/html/THIRDPARTYLICENSEREAMDE.html
ooo/trunk/core/writerfilter/source/doctok/escher.html
ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML
Schemas/xsdlib.xsd (convert from UTF-16 to UTF-8)
ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/body.xsl
ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/style_mapping_css.xsl
ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/style_collector_css.xsl
ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/table/table.xsl
ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/table/table_cells.xsl
ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/table/table_columns.xsl
ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/table/table_rows.xsl

In each case, the error aborted the import which had to then be
restarted from the top.  So it was a slow process, finding all of
these problem files.  Possible solutions could include adding them as
binary (not text) files, or editing them (dos2unix, e.g.) to make
their EOL style consistent.  I did the latter.

Note:  any other approach to migrating Hg to SVN will run into the
above problem files, so I'd recommend that anyone who wants to try an
alternative migration approach start by fixing the above files.

Once the project was imported, I did an svn export to get a clean copy
of the project, and compare it to the original directory.  The file
counts matched, which is a good sign:  69202 files.

I then did an svnadmin -c dump >ooo-dump to create a dump file of this
repository.

The dump file is 1.8 GB, with an MD5 hash of:  fd611942d297128d021cd03795b54708

It compressed to a 367 MB gzip which I've put on my website here:

http://www.robweir.com/ooo-dump.gz

So unless anyone has a better idea, and more importantly, is willing
to implement a better idea, I'd like to go forward with importing this
dump file.

Let's take a few days to review the steps above, and to review the
dump file, to make sure there are not any major errors introduced.  If
someone can kick off a build with this source, it would be a great way
to confirm.

I have all of my partial steps saved, so making small tweaks to this
are relatively easy.  For example, if there are some file extensions
used by OOo that should be treated as text, but are not listed in the
standard SVN config, or in the recommended Apache project extended
list, this is a good time to get those corrected.

Regards,

-Rob

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ap...@robweir.com>]

On Mon, Aug 15, 2011 at 1:08 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> On Mon, 15 Aug 2011 12:46 -0400, "Rob Weir" <ro...@apache.org> wrote:
>> In each case, the error aborted the import which had to then be
>> restarted from the top.  So it was a slow process, finding all of
>> these problem files.  Possible solutions could include adding them as
>> binary (not text) files, or editing them (dos2unix, e.g.) to make
>> their EOL style consistent.  I did the latter.
>>
>
> Or, don't set svn:eol-style.  svn will treat a file as an opaque blob of bytes when such properties aren't set (which is the default).
>

But is there an easier way of finding out what files had inconsistent
EOL styles short of doing an import?  That was the most painful part
of the process.  In the end, these were text files, files we'll want
to be able to diff and bring down and edit with text editors in
Windows and in Linux, so it was important to get them into a
consistent style.

>> I then did an svnadmin -c dump >ooo-dump to create a dump file of this
>> repository.
>>
>
> 'svnadmin dump' doens't take '-c'.
>
> It does take --deltas, though.
>

You are correct. The -c was on the gzip, not the svadmin dump

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Daniel Shahaf <d....@daniel.shahaf.name>]

On Mon, 15 Aug 2011 12:46 -0400, "Rob Weir" <ro...@apache.org> wrote:
> In each case, the error aborted the import which had to then be
> restarted from the top.  So it was a slow process, finding all of
> these problem files.  Possible solutions could include adding them as
> binary (not text) files, or editing them (dos2unix, e.g.) to make
> their EOL style consistent.  I did the latter.
> 

Or, don't set svn:eol-style.  svn will treat a file as an opaque blob of bytes when such properties aren't set (which is the default).

> I then did an svnadmin -c dump >ooo-dump to create a dump file of this
> repository.
> 

'svnadmin dump' doens't take '-c'.

It does take --deltas, though.

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Daniel Shahaf <d....@daniel.shahaf.name>]

Rob Weir wrote on Wed, Aug 17, 2011 at 19:58:44 -0400:
> On Wed, Aug 17, 2011 at 5:15 PM, Michael Stahl <ms...@openoffice.org> wrote:
> > On 16.08.2011 20:41, Rob Weir wrote:
> >>
> >> During local svn import I received several error messages like this:
> >>
> >> "svn: Inconsistent line ending style"
> >>
> >> The following files gave this error:
> >>
> >> /ooo/trunk/core/dictionaries/de_DE/README_hyph_de_DE.txt
> >> /ooo/trunk/core/dictionaries/de_CH/README_hyph_de_CH.txt
> >> /ooo/trunk/core/dictionaries/de_AT/README_hyph_de_AT.txt
> >> /ooo/trunk/core/gettext/gettext-0.18.1.1.patch
> >> /ooo/trunk/core/apache-commons/patches/codec.patch
> >> /ooo/trunk/core/libcroco/libcroco-0.6.2.patch
> >> /ooo/trunk/core/graphite/graphite-2.3.1.patch
> >
> >> /ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/body.xsl
> >>
> >> /ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/style_mapping_css.xsl
> >> /ooo/trunk/core/solenv/bin/cwstouched.pl
> >> /ooo/trunk/core/readlicense_oo/html/THIRDPARTYLICENSEREADME.html
> >> /ooo/trunk/core/writerfilter/source/doctok/escher.html
> >
> > guess these just need proper consistent EOL.
> >
> >> /ooo/trunk/core/testautomation/writer/optional/input/import/mactext.txt
> >
> > this one is called "mactext", maybe it wants mac EOL.
> > there is a "dostext.txt" "wintext.txt" "unixtext.txt" in the same dir.
> >
> 
> Presumably we want these to be come down as-is without any EOL conversion.
> 
> The options for the svn:eol-style property are:
> 
> native -- store in normalized format, and bring down in client's native style
> 
> CRLF -- bring down always with DOS/Windows convention
> 
> LF -- bring down in Unix convention
> 
> CR -- not sure who uses that? Is that Mac?
> 
> But odd that dostext.txt and wintext.txt are different files.  Perhaps
> it is testing character set as well?  Might be safer to just treat
> these test files as binary files, e.g., set svn:mime-type to
> "application/octet-stream".

Subversion will treat the contents of files as opaque ("binary") byte
strings UNLESS svn:keywords or svn:eol-style is set.  No need for
explicit MIME type setting.

(and it might interfere with accessing those files in $BROWSER)

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ro...@robweir.com>]

On Thu, Aug 18, 2011 at 11:49 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Rob Weir wrote on Thu, Aug 18, 2011 at 11:17:45 -0400:
>> On Thu, Aug 18, 2011 at 10:22 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> > Stephan Bergmann wrote on Thu, Aug 18, 2011 at 15:46:33 +0200:
>> >> On Aug 16, 2011, at 8:41 PM, Rob Weir wrote:
>> >> > By request I've created a new SVN dump file, this time from Linux.
>> >>
>> >> I would make the commit log more detailed than just "initial import,"
>> >
>> > Then edit it post-import.
>> >
>>
>>
>> There are a few things we need to get right before import:
>>
>
> There is no turning back after the import is done.  If the dump file you
> have provided to infra is not right then POST A HOLD-ON NOTE ON JIRA.
>

Sorry if my note was confusing.  That was not what I said at all.   My
point was certain things need to be done right, and they have been
done right.

-Rob

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Daniel Shahaf <d....@daniel.shahaf.name>]

Rob Weir wrote on Thu, Aug 18, 2011 at 11:17:45 -0400:
> On Thu, Aug 18, 2011 at 10:22 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Stephan Bergmann wrote on Thu, Aug 18, 2011 at 15:46:33 +0200:
> >> On Aug 16, 2011, at 8:41 PM, Rob Weir wrote:
> >> > By request I've created a new SVN dump file, this time from Linux.
> >>
> >> I would make the commit log more detailed than just "initial import,"
> >
> > Then edit it post-import.
> >
> 
> 
> There are a few things we need to get right before import:
> 

There is no turning back after the import is done.  If the dump file you
have provided to infra is not right then POST A HOLD-ON NOTE ON JIRA.

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Eike Rathke <oo...@erack.de>]

Hi Michael,

On Wednesday, 2011-08-17 23:15:24 +0200, Michael Stahl wrote:

> - similar number of executable files
>   (why the heck are there 8425 of these???)

Just a wild guess: maybe because people added them working on a NFS
volume exported via Samba that added the executable bit.

  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: [Repo][Proposal] OOO340 SVN Dump file import

[Ingrid von der Mehden <In...@gmx-topmail.de>]

Am 19.08.2011 15:30, schrieb Mathias Bauer:
> On 19.08.2011 15:10, Ingrid von der Mehden wrote:
>
>> Directly after import is fine. There was consensus on that already. But
>> if we don't discuss the name change now, we need another couple of weeks
>> and the moment directly after import will have gone. So do you have
>> different names in mind?
>
> Nothing that sounds better. If we split up "extras" in the "main" repo,
> my main concern would be solved anyway, so I would be fine with "main"
> and "extras" in that case.
>
Ok.

>> Good question regarding 'minimal' and 'regular'. I am not totally
>> decided. Is there a way to have both? For the day to day development I
>> think an easy and fast way to build a minimal office would be the
>> greater benefit. But that demand might clash with demands from QA side ...
>
>> From the build environment POV you definitely can have both, in case we
> taught "instsetoo_native" and "postprocess" that e.g. a build without
> help content, extras etc. is valid. Not a big deal, but someone has to
> do it.
>
Cool, that is an encouraging outlook.

> Our build system concept also had a different idea for how developers
> should work with OOo: the build already should have created a runnable
> instance of OOo, no packaging required. In that case you can build
> whatever you want, with extras or without, if it runs it is usable for
> developers.
>
Sounds good :-)

>>> The new build system is capable of
>>> working with several (sub-)repositories, the old one still needs the
>>> "source_config" crutch.
>>
>> Yes, I now found for the new system there is the environment variable
>> gb_REPOS which takes the list of repos. Lets assume it contains the two
>> repos 'main' and 'extras'. What happens if the directory 'extras' is not
>> present? Does the build abort with error, or does it continue with
>> warning? Can we make it so that it does continue with a gentle note?
>
> As gbuild already has shown that it works without code changes with or
> without "l10n" repo, this is not a problem. I don't remember the
> details, but we can look that up when necessary.
>
Agreed, that is not so urgent at the moment. Thanks a lot anyhow.

Kind regards,
Ingrid

> Regards,
> Mathias
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Mathias Bauer <Ma...@gmx.net>]

On 19.08.2011 15:10, Ingrid von der Mehden wrote:

> Directly after import is fine. There was consensus on that already. But 
> if we don't discuss the name change now, we need another couple of weeks 
> and the moment directly after import will have gone. So do you have 
> different names in mind?

Nothing that sounds better. If we split up "extras" in the "main" repo,
my main concern would be solved anyway, so I would be fine with "main"
and "extras" in that case.

> Good question regarding 'minimal' and 'regular'. I am not totally 
> decided. Is there a way to have both? For the day to day development I 
> think an easy and fast way to build a minimal office would be the 
> greater benefit. But that demand might clash with demands from QA side ...

>From the build environment POV you definitely can have both, in case we
taught "instsetoo_native" and "postprocess" that e.g. a build without
help content, extras etc. is valid. Not a big deal, but someone has to
do it.

Our build system concept also had a different idea for how developers
should work with OOo: the build already should have created a runnable
instance of OOo, no packaging required. In that case you can build
whatever you want, with extras or without, if it runs it is usable for
developers.

>> The new build system is capable of
>> working with several (sub-)repositories, the old one still needs the
>> "source_config" crutch.
> 
> Yes, I now found for the new system there is the environment variable 
> gb_REPOS which takes the list of repos. Lets assume it contains the two 
> repos 'main' and 'extras'. What happens if the directory 'extras' is not 
> present? Does the build abort with error, or does it continue with 
> warning? Can we make it so that it does continue with a gentle note?

As gbuild already has shown that it works without code changes with or
without "l10n" repo, this is not a problem. I don't remember the
details, but we can look that up when necessary.

Regards,
Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Ingrid von der Mehden <In...@gmx-topmail.de>]

Am 19.08.2011 14:10, schrieb Mathias Bauer:
> On 19.08.2011 13:43, Ingrid von der Mehden wrote:
>
>> Am 18.08.2011 18:27, schrieb Mathias Bauer:
>>> On 18.08.2011 17:17, Rob Weir wrote:
>>>
>> [...]
>>
>>>> 2) Do we have the basic directory structure right? (Could fix that
>>>> later, but easier to get it right initially)
>>>
>>> The structure is fine and AFAIK reflects the consensus, just the names
>>> "main" and "extras" are debatable. We will have an "extras" module in
>>> the "main" repo, perhaps we can find a better name for that part. But
>>> that can be changed easily post import.
>>>
>>
>> If we want to change the 'outer' directory names, lets change them now.
>> It is difficult enough for people to learn all the new things and find
>> the way to the code. So let us not make it more complicated by changing
>> the main repository path more often than necessary.
>
> I doubt that changing it next week, directly after import, would confuse
> anyone. OTOH getting the first import soon and not postponing it until
> this discussion has settled is a big step forward.
>

Directly after import is fine. There was consensus on that already. But 
if we don't discuss the name change now, we need another couple of weeks 
and the moment directly after import will have gone. So do you have 
different names in mind?

>>
>> For the two 'extras' directories I would favor to move as much stuff as
>> possible from the inner 'extras' to the outer 'extras'. If that is not
>> possible lets rename the inner one. Looking at the deliver list we seem
>> to have wordbooks and fonts here. All the gallery content and the
>> templates are here also even with localization! I doubt that most of
>> this is really needed for the typical day to day coding. It's more
>> design related stuff. So moving this out of 'main' would be a benefit.
>> But that move can be done later. When we do that I would like to
>> consider moving module helpcontent2 to the outer extras directory also.
>
> Hm, what is the meaning of "main"? Is it a "minimal" repository that is
> needed for building at least the code or should it be what makes up the
> "regular" en-US build? If we agree that it's the latter, the "extras"
> module belongs into "main". Of course we can think about breaking it
> into several parts, like "templates", "gallery" etc. That would be an
> improvement not only because it avoids the name clash.
>

Yeah breaking it apart in the described way would be an improvement also.

Good question regarding 'minimal' and 'regular'. I am not totally 
decided. Is there a way to have both? For the day to day development I 
think an easy and fast way to build a minimal office would be the 
greater benefit. But that demand might clash with demands from QA side ...

>> I haven't looked so deeply into the new build system and the packaging
>> so far. Would it be possible to build a minimal office install set with
>> or without the outer 'extras' directory dependent on its existence? Or
>> is it necessary to define some environment variables?
>
> It's not a problem of the build system, the packaging is too inflexible
> ATM. But that can be tweaked also.

I hoped you would say that.

> The new build system is capable of
> working with several (sub-)repositories, the old one still needs the
> "source_config" crutch.

Yes, I now found for the new system there is the environment variable 
gb_REPOS which takes the list of repos. Lets assume it contains the two 
repos 'main' and 'extras'. What happens if the directory 'extras' is not 
present? Does the build abort with error, or does it continue with 
warning? Can we make it so that it does continue with a gentle note?

Kind regards,
Ingrid

>
> Regards,
> Mathias
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Mathias Bauer <Ma...@gmx.net>]

On 19.08.2011 13:43, Ingrid von der Mehden wrote:

> Am 18.08.2011 18:27, schrieb Mathias Bauer:
>> On 18.08.2011 17:17, Rob Weir wrote:
>>
> [...]
> 
>>> 2) Do we have the basic directory structure right? (Could fix that
>>> later, but easier to get it right initially)
>>
>> The structure is fine and AFAIK reflects the consensus, just the names
>> "main" and "extras" are debatable. We will have an "extras" module in
>> the "main" repo, perhaps we can find a better name for that part. But
>> that can be changed easily post import.
>>
> 
> If we want to change the 'outer' directory names, lets change them now. 
> It is difficult enough for people to learn all the new things and find 
> the way to the code. So let us not make it more complicated by changing 
> the main repository path more often than necessary.

I doubt that changing it next week, directly after import, would confuse
anyone. OTOH getting the first import soon and not postponing it until
this discussion has settled is a big step forward.

> 
> For the two 'extras' directories I would favor to move as much stuff as 
> possible from the inner 'extras' to the outer 'extras'. If that is not 
> possible lets rename the inner one. Looking at the deliver list we seem 
> to have wordbooks and fonts here. All the gallery content and the 
> templates are here also even with localization! I doubt that most of 
> this is really needed for the typical day to day coding. It's more 
> design related stuff. So moving this out of 'main' would be a benefit. 
> But that move can be done later. When we do that I would like to 
> consider moving module helpcontent2 to the outer extras directory also.

Hm, what is the meaning of "main"? Is it a "minimal" repository that is
needed for building at least the code or should it be what makes up the
"regular" en-US build? If we agree that it's the latter, the "extras"
module belongs into "main". Of course we can think about breaking it
into several parts, like "templates", "gallery" etc. That would be an
improvement not only because it avoids the name clash.

> I haven't looked so deeply into the new build system and the packaging 
> so far. Would it be possible to build a minimal office install set with 
> or without the outer 'extras' directory dependent on its existence? Or 
> is it necessary to define some environment variables?

It's not a problem of the build system, the packaging is too inflexible
ATM. But that can be tweaked also. The new build system is capable of
working with several (sub-)repositories, the old one still needs the
"source_config" crutch.

Regards,
Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Ingrid von der Mehden <In...@gmx-topmail.de>]

Am 18.08.2011 18:27, schrieb Mathias Bauer:
> On 18.08.2011 17:17, Rob Weir wrote:
>
[...]

>> 2) Do we have the basic directory structure right? (Could fix that
>> later, but easier to get it right initially)
>
> The structure is fine and AFAIK reflects the consensus, just the names
> "main" and "extras" are debatable. We will have an "extras" module in
> the "main" repo, perhaps we can find a better name for that part. But
> that can be changed easily post import.
>

If we want to change the 'outer' directory names, lets change them now. 
It is difficult enough for people to learn all the new things and find 
the way to the code. So let us not make it more complicated by changing 
the main repository path more often than necessary.

For the two 'extras' directories I would favor to move as much stuff as 
possible from the inner 'extras' to the outer 'extras'. If that is not 
possible lets rename the inner one. Looking at the deliver list we seem 
to have wordbooks and fonts here. All the gallery content and the 
templates are here also even with localization! I doubt that most of 
this is really needed for the typical day to day coding. It's more 
design related stuff. So moving this out of 'main' would be a benefit. 
But that move can be done later. When we do that I would like to 
consider moving module helpcontent2 to the outer extras directory also.

I haven't looked so deeply into the new build system and the packaging 
so far. Would it be possible to build a minimal office install set with 
or without the outer 'extras' directory dependent on its existence? Or 
is it necessary to define some environment variables?

Kind regards,
Ingrid

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Mathias Bauer <Ma...@gmx.net>]

On 18.08.2011 17:17, Rob Weir wrote:

> On Thu, Aug 18, 2011 at 10:22 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> Stephan Bergmann wrote on Thu, Aug 18, 2011 at 15:46:33 +0200:
>>> On Aug 16, 2011, at 8:41 PM, Rob Weir wrote:
>>> > By request I've created a new SVN dump file, this time from Linux.
>>>
>>> I would make the commit log more detailed than just "initial import,"
>>
>> Then edit it post-import.
>>
> 
> 
> There are a few things we need to get right before import:
> 
> 1) What repositories and what revisions are we importing?

I think that this is already clear: it's OOO340m1 and it was agreed that
this is the right one.

> 
> 2) Do we have the basic directory structure right? (Could fix that
> later, but easier to get it right initially)

The structure is fine and AFAIK reflects the consensus, just the names
"main" and "extras" are debatable. We will have an "extras" module in
the "main" repo, perhaps we can find a better name for that part. But
that can be changed easily post import.

> 3) Are we mangling the files when converting, e.g., eol style,
> executable bit, etc.  (We have issues with around 10 files, which I
> have excluded from this import.  We can add them post import)

The missing files indees can be added post import, and we can also deal
with the EOL changes later. IMHO.

> I think we have the basics right.  At least no one has said otherwise.
>  I have not heard any issues raised that can be easily fixed
> post-import.
> 
> We should all remember that right now, I am the only able to make
> changes to this dump file, and re-running this
> import/verify/dump/gzip/transfer process takes hours to turn around,
> since I'm running it on an old laptop.  But as soon as we get this on
> the server, any committer can make a change, and doing so will take
> them 30 seconds.
> 
> Getting this on the server will allow us to make improvements in parallel.

Indeed. Let's move forward.

Regards,
Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ro...@robweir.com>]

On Thu, Aug 18, 2011 at 10:22 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Stephan Bergmann wrote on Thu, Aug 18, 2011 at 15:46:33 +0200:
>> On Aug 16, 2011, at 8:41 PM, Rob Weir wrote:
>> > By request I've created a new SVN dump file, this time from Linux.
>>
>> I would make the commit log more detailed than just "initial import,"
>
> Then edit it post-import.
>


There are a few things we need to get right before import:

1) What repositories and what revisions are we importing?

2) Do we have the basic directory structure right? (Could fix that
later, but easier to get it right initially)

3) Are we mangling the files when converting, e.g., eol style,
executable bit, etc.  (We have issues with around 10 files, which I
have excluded from this import.  We can add them post import)

I think we have the basics right.  At least no one has said otherwise.
 I have not heard any issues raised that can be easily fixed
post-import.

We should all remember that right now, I am the only able to make
changes to this dump file, and re-running this
import/verify/dump/gzip/transfer process takes hours to turn around,
since I'm running it on an old laptop.  But as soon as we get this on
the server, any committer can make a change, and doing so will take
them 30 seconds.

Getting this on the server will allow us to make improvements in parallel.


-Rob

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Daniel Shahaf <d....@daniel.shahaf.name>]

Stephan Bergmann wrote on Thu, Aug 18, 2011 at 15:46:33 +0200:
> On Aug 16, 2011, at 8:41 PM, Rob Weir wrote:
> > By request I've created a new SVN dump file, this time from Linux.
> 
> I would make the commit log more detailed than just "initial import,"

Then edit it post-import.

FYI all, Rob has filed an INFRA JIRA for the import to be done.

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Mathias Bauer <Ma...@gmx.net>]

Hi,

I just wanted to clarify how we want to proceed with the files that have
been changed during the svn import.

Am 17.08.2011 23:15, schrieb Michael Stahl:

> On 16.08.2011 20:41, Rob Weir wrote:
>> During local svn import I received several error messages like this:
>>
>> "svn: Inconsistent line ending style"
>>
>> The following files gave this error:
>>
>> /ooo/trunk/core/dictionaries/de_DE/README_hyph_de_DE.txt
>> /ooo/trunk/core/dictionaries/de_CH/README_hyph_de_CH.txt
>> /ooo/trunk/core/dictionaries/de_AT/README_hyph_de_AT.txt
>> /ooo/trunk/core/gettext/gettext-0.18.1.1.patch
>> /ooo/trunk/core/apache-commons/patches/codec.patch
>> /ooo/trunk/core/libcroco/libcroco-0.6.2.patch
>> /ooo/trunk/core/graphite/graphite-2.3.1.patch
>> /ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/body.xsl
>> /ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/style_mapping_css.xsl
>> /ooo/trunk/core/solenv/bin/cwstouched.pl
>> /ooo/trunk/core/readlicense_oo/html/THIRDPARTYLICENSEREADME.html
>> /ooo/trunk/core/writerfilter/source/doctok/escher.html
> 
> guess these just need proper consistent EOL.

cwstouched.pl and THIRDPARTYLICENSEREADME.html are different. dos2unix
thinks they are binary files. For the time being we should add them as
they are in the Mercurial repo. As far as I can see, the former is
obsolete and the latter has to be rewritten anyway before we can release
something.

All other files indeed should be converted to Unix line ends with
dos2unix and added/committed to the svn repo.

Some of these files are "external" files from the dictionaries, and
usually we don't change these files directly. We can just add them from
the Mercurial repo as they are. As these files will be removed from the
repository soon anyway (wrong license), it doesn't make a big difference
how we treat them. We could even leave them out.

>> /ooo/trunk/core/testautomation/writer/optional/input/import/mactext.txt
> 
> this one is called "mactext", maybe it wants mac EOL.
> there is a "dostext.txt" "wintext.txt" "unixtext.txt" in the same dir.

We should take this file from the Mercurial repo and commit it to svn
without changes.

"dostext" and "wintext" have been converted to Linux line ends in the
svn repo. We should revert that.

>> /ooo/trunk/core/hwpfilter/source/hwpeq.cpp
> 
> this one has comments with Korean characters in some annoying encoding.
> perhaps we should just remove the offending comments for now.

+1

>> /ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML
>> Schemas/xsdlib.xsd
>> /ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML
>> Schemas/wordnetaux.xsd
> 
> seem to be UTF-16 LE encoded

So we should convert them to UTF-8 and commit them, right?

> - some EOL changes in a bunch of files that are probably either harmless 
> or an improvement
Some text files in the svn repo have been converted from DOS line ends
to Unix line ends, indeed this can be considered as an improvement as
this is what we wanted to have in our code repository anyway.
Interestingly some files have been converted in the opposite way: "dsp"
file for the MS Developer Studio. As these files will be used on Windows
only anyway, I don't see a problem with that.

Again some files are inside the "dictionaries" folder and don't matter
anyway.

Regards,
Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Mathias Bauer <Ma...@gmx.net>]

On 18.08.2011 01:58, Rob Weir wrote:

>>> /ooo/trunk/core/testautomation/writer/optional/input/import/mactext.txt
>>
>> this one is called "mactext", maybe it wants mac EOL.
>> there is a "dostext.txt" "wintext.txt" "unixtext.txt" in the same dir.
>>
> 
> Presumably we want these to be come down as-is without any EOL conversion.
> 
> The options for the svn:eol-style property are:
> 
> native -- store in normalized format, and bring down in client's native style
> 
> CRLF -- bring down always with DOS/Windows convention
> 
> LF -- bring down in Unix convention
> 
> CR -- not sure who uses that? Is that Mac?
> 
> But odd that dostext.txt and wintext.txt are different files.  Perhaps
> it is testing character set as well?  Might be safer to just treat
> these test files as binary files, e.g., set svn:mime-type to
> "application/octet-stream".

Indeed we should try to transfer them without EOL conversion. In the
worst case we could create new files later on, as they are not necessary
for a build.

Regards,
Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

[eric b <er...@free.fr>]

Hi Rob,

Le 18 août 11 à 01:58, Rob Weir a écrit :
>
> The options for the svn:eol-style property are:
>
> native -- store in normalized format, and bring down in client's  
> native style
>
> CRLF -- bring down always with DOS/Windows convention
>
> LF -- bring down in Unix convention
>
> CR -- not sure who uses that? Is that Mac?
>


If this can help ( I hope I'm not off topic) end lines are 0x0A on  
mac OS X, so I'd say it's Unix too for Mac OS X (tested with Midnight  
Commander).

And building on a lot of OS's ( Windows, Mac, Linux ... and so on), I  
see only two cases in the sources : DOS endlines ( 0x0A 0x0D)  and  
Unix one ( 0x0A ), both present




> But odd that dostext.txt and wintext.txt are different files.   
> Perhaps it is testing character set as well?  Might be safer to  
> just treat
> these test files as binary files, e.g., set svn:mime-type to  
> "application/octet-stream".
>


Using svn with OOo4Kids, I do not remember what has been choosen (it  
was Cedric Bosdonnat who tweaked the thing, not me), but you could  
checkout one or two modules per see ?

The repo is  svn://svn.adullact.net/svnroot/ooo4kids1/trunk


I have no problem building anywhere (Windows, Mac and Linux)


Notes: some other files hosted in the sources, are UTF-8 and UTF-16  
as mentionned below.


>
>>> /ooo/trunk/core/hwpfilter/source/hwpeq.cpp
>>
>> this one has comments with Korean characters in some annoying  
>> encoding.
>> perhaps we should just remove the offending comments for now.
>>
>>>
>>> /ooo/trunk/core/writerfilter/source/odiapi/qname/resource/ 
>>> office2003/WordprocessingML
>>> Schemas/xsdlib.xsd
>>>
>>> /ooo/trunk/core/writerfilter/source/odiapi/qname/resource/ 
>>> office2003/WordprocessingML
>>> Schemas/wordnetaux.xsd
>>
>> seem to be UTF-16 LE encoded


On my side (OOo4Kids sources), I got this :

truc:~/Desktop/r1238/writerfilter/source/odiapi/qname/resource/ 
office2003/WordprocessingML Schemas ericb$ file *

wordnetaux.xsd: Little-endian UTF-16 Unicode English character data,  
with very long lines, with CRLF, CR line terminators
xsdlib.xsd:     Little-endian UTF-16 Unicode English character data,  
with very long lines, with CRLF, CR line terminators


I hope this can help you ...


Eric

-- 
qɔᴉɹə
Education Project:
http://wiki.services.openoffice.org/wiki/Education_Project
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Mathias Bauer <Ma...@gmx.net>]

On 18.08.2011 18:20, Larry Gusaas wrote:

> On 2011-08-17 5:58 PM  Rob Weir wrote:
>> CR -- not sure who uses that? Is that Mac?
> Mac OS X uses LF (Unix) line endings. Pre OS X systems used CR line endings.

Indeed, and the "mactext" test file needs this "old style" CR line
endings so that it could be tested if OOo can cope with such files.

As written in my last post, we can deal with that later.

Regards,
Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Larry Gusaas <la...@gmail.com>]

On 2011-08-17 5:58 PM  Rob Weir wrote:
> CR -- not sure who uses that? Is that Mac?
Mac OS X uses LF (Unix) line endings. Pre OS X systems used CR line endings.

_________________________________
Larry I. Gusaas
Moose Jaw, Saskatchewan Canada
Website: http://larry-gusaas.com
"An artist is never ahead of his time but most people are far behind theirs." - Edgard Varese

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ro...@robweir.com>]

On Wed, Aug 17, 2011 at 5:15 PM, Michael Stahl <ms...@openoffice.org> wrote:
> On 16.08.2011 20:41, Rob Weir wrote:
>>
>> During local svn import I received several error messages like this:
>>
>> "svn: Inconsistent line ending style"
>>
>> The following files gave this error:
>>
>> /ooo/trunk/core/dictionaries/de_DE/README_hyph_de_DE.txt
>> /ooo/trunk/core/dictionaries/de_CH/README_hyph_de_CH.txt
>> /ooo/trunk/core/dictionaries/de_AT/README_hyph_de_AT.txt
>> /ooo/trunk/core/gettext/gettext-0.18.1.1.patch
>> /ooo/trunk/core/apache-commons/patches/codec.patch
>> /ooo/trunk/core/libcroco/libcroco-0.6.2.patch
>> /ooo/trunk/core/graphite/graphite-2.3.1.patch
>
>> /ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/body.xsl
>>
>> /ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/style_mapping_css.xsl
>> /ooo/trunk/core/solenv/bin/cwstouched.pl
>> /ooo/trunk/core/readlicense_oo/html/THIRDPARTYLICENSEREADME.html
>> /ooo/trunk/core/writerfilter/source/doctok/escher.html
>
> guess these just need proper consistent EOL.
>
>> /ooo/trunk/core/testautomation/writer/optional/input/import/mactext.txt
>
> this one is called "mactext", maybe it wants mac EOL.
> there is a "dostext.txt" "wintext.txt" "unixtext.txt" in the same dir.
>

Presumably we want these to be come down as-is without any EOL conversion.

The options for the svn:eol-style property are:

native -- store in normalized format, and bring down in client's native style

CRLF -- bring down always with DOS/Windows convention

LF -- bring down in Unix convention

CR -- not sure who uses that? Is that Mac?

But odd that dostext.txt and wintext.txt are different files.  Perhaps
it is testing character set as well?  Might be safer to just treat
these test files as binary files, e.g., set svn:mime-type to
"application/octet-stream".


>> /ooo/trunk/core/hwpfilter/source/hwpeq.cpp
>
> this one has comments with Korean characters in some annoying encoding.
> perhaps we should just remove the offending comments for now.
>
>>
>> /ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML
>> Schemas/xsdlib.xsd
>>
>> /ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML
>> Schemas/wordnetaux.xsd
>
> seem to be UTF-16 LE encoded
>
>> Whereas previously I tried to fix these files with dos2unix, this time
>> I simply omitted them from the import.   The automated "one size fits
>> all" approach did not seem right since some of these files, e.g., the
>> mactext.txt, appear to be intentionally using weird EOL conventions.
>>
>> We'll need to resolve these cases individually and add them to the new
>> repository, eventually.  In some cases we might decide to treat them
>> as binary files, in other cases we could dos2unix them, in other cases
>> we'll need to convert the character encoding from UTF-16 to UTF-8.
>> But we can figure that out later.
>>
>> You can download the new dump file from:  www.robweir.com/ooo-dump-new.gz
>>
>> md5sum of the unzipped ooo-dump file is:
>> a6651e98b1a92f5158a08921e85a7a3a
>>
>> -Rob
>
> had a look at it:
>
> - unsurprisingly the files you listed are missing
>
> - some EOL changes in a bunch of files that are probably either harmless or
> an improvement
>
> - similar number of executable files
>  (why the heck are there 8425 of these???)
>
> - also missing: Repository.mk from the l10n toplevel
>  don't actually know if we need that; probably not until the l10n module is
> converted to gbuild, and in any case i guess it could live inside the l10n
> module directory as well.
>
> regards,
>  michael
>
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Michael Stahl <ms...@openoffice.org>]

On 18.08.2011 10:31, Mathias Bauer wrote:
> Hi Michael,
>
> On 17.08.2011 23:15, Michael Stahl wrote:

>> - some EOL changes in a bunch of files that are probably either harmless
>> or an improvement
>
> We should decide how to deal with it, as it might make merging from cws
> harder. As my favorite approach for bringing over the cws still is to
> create patches (either one per cws or one for every change set in the
> cws), we could create a diff from the svn repo, apply it to the hg
> OOO340m1 repo and create the patches against this version.

that's a good point.

but doesn't patch have an option to ignore whitespace differences?

git-apply seems to have various options including --ignore-whitespace.

>> - also missing: Repository.mk from the l10n toplevel
>>     don't actually know if we need that; probably not until the l10n
>> module is converted to gbuild, and in any case i guess it could live
>> inside the l10n module directory as well.
>
> Whereever it is, it's enough that we have brought it over.

well we haven't, but that's not a big problem given that the entire 
actual content is this line:

$(eval $(call gb_Helper_register_repository,LOCDIR))

> Regards,
> Mathias
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Mathias Bauer <Ma...@gmx.net>]

Hi Michael,

On 17.08.2011 23:15, Michael Stahl wrote:

> had a look at it:

You beat me to it. :-)
Due to some hardware problems I needed more time than expected.

> - unsurprisingly the files you listed are missing
> 
> - some EOL changes in a bunch of files that are probably either harmless 
> or an improvement

We should decide how to deal with it, as it might make merging from cws
harder. As my favorite approach for bringing over the cws still is to
create patches (either one per cws or one for every change set in the
cws), we could create a diff from the svn repo, apply it to the hg
OOO340m1 repo and create the patches against this version.

> - also missing: Repository.mk from the l10n toplevel
>    don't actually know if we need that; probably not until the l10n 
> module is converted to gbuild, and in any case i guess it could live 
> inside the l10n module directory as well.

Whereever it is, it's enough that we have brought it over.

Regards,
Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Michael Stahl <ms...@openoffice.org>]

On 16.08.2011 20:41, Rob Weir wrote:
> During local svn import I received several error messages like this:
>
> "svn: Inconsistent line ending style"
>
> The following files gave this error:
>
> /ooo/trunk/core/dictionaries/de_DE/README_hyph_de_DE.txt
> /ooo/trunk/core/dictionaries/de_CH/README_hyph_de_CH.txt
> /ooo/trunk/core/dictionaries/de_AT/README_hyph_de_AT.txt
> /ooo/trunk/core/gettext/gettext-0.18.1.1.patch
> /ooo/trunk/core/apache-commons/patches/codec.patch
> /ooo/trunk/core/libcroco/libcroco-0.6.2.patch
> /ooo/trunk/core/graphite/graphite-2.3.1.patch
 > /ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/body.xsl
 > 
/ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/style_mapping_css.xsl
 > /ooo/trunk/core/solenv/bin/cwstouched.pl
 > /ooo/trunk/core/readlicense_oo/html/THIRDPARTYLICENSEREADME.html
 > /ooo/trunk/core/writerfilter/source/doctok/escher.html

guess these just need proper consistent EOL.

 > /ooo/trunk/core/testautomation/writer/optional/input/import/mactext.txt

this one is called "mactext", maybe it wants mac EOL.
there is a "dostext.txt" "wintext.txt" "unixtext.txt" in the same dir.

> /ooo/trunk/core/hwpfilter/source/hwpeq.cpp

this one has comments with Korean characters in some annoying encoding.
perhaps we should just remove the offending comments for now.

> /ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML
> Schemas/xsdlib.xsd
> /ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML
> Schemas/wordnetaux.xsd

seem to be UTF-16 LE encoded

> Whereas previously I tried to fix these files with dos2unix, this time
> I simply omitted them from the import.   The automated "one size fits
> all" approach did not seem right since some of these files, e.g., the
> mactext.txt, appear to be intentionally using weird EOL conventions.
>
> We'll need to resolve these cases individually and add them to the new
> repository, eventually.  In some cases we might decide to treat them
> as binary files, in other cases we could dos2unix them, in other cases
> we'll need to convert the character encoding from UTF-16 to UTF-8.
> But we can figure that out later.
>
> You can download the new dump file from:  www.robweir.com/ooo-dump-new.gz
>
> md5sum of the unzipped ooo-dump file is:   a6651e98b1a92f5158a08921e85a7a3a
>
> -Rob

had a look at it:

- unsurprisingly the files you listed are missing

- some EOL changes in a bunch of files that are probably either harmless 
or an improvement

- similar number of executable files
   (why the heck are there 8425 of these???)

- also missing: Repository.mk from the l10n toplevel
   don't actually know if we need that; probably not until the l10n 
module is converted to gbuild, and in any case i guess it could live 
inside the l10n module directory as well.

regards,
  michael

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Stephan Bergmann <st...@googlemail.com>]

On Aug 16, 2011, at 8:41 PM, Rob Weir wrote:
> By request I've created a new SVN dump file, this time from Linux.

I would make the commit log more detailed than just "initial import," maybe something like

  Initial import of the old OOo hg repository tip revision.

  .../trunk/main is a copy of (currently tip-most) http://hg.services.openoffice.org/OOO340/rev/c904c1944462
  .../trunk/extras/l10n is a copy of (currently tip-most) http://hg.services.openoffice.org/master_l10n/OOO340/rev/af6bc9467af5
  expect that the following files with line-end anomalies were left out (they are supposed to be handled separately):
  .../trunk/main/dictionaries/de_DE/README_hyph_de_DE.txt
  …

-Stephan

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ap...@robweir.com>]

By request I've created a new SVN dump file, this time from Linux.

As before, I brought down the OOO340 trunk and the language repositories:

hg clone http://hg.services.openoffice.org/OOO340
hg clone http://hg.services.openoffice.org/master_l10n/OOO340/

I then moved these into a common directory structure

ooo/trunk/main --- all the OOO340 stuff
ooo/trunk/extras/l10n -- all the language stuff

Note that, based on feedback, this differs from the directory
structure I had previously.

I removed the .Hg directories before proceeding, so I had a clean local copy.

I then created a local SVN repository, enabled auto-props to get the
proper EOL treatment and imported the project.

During local svn import I received several error messages like this:

"svn: Inconsistent line ending style"

The following files gave this error:

/ooo/trunk/core/dictionaries/de_DE/README_hyph_de_DE.txt
/ooo/trunk/core/dictionaries/de_CH/README_hyph_de_CH.txt
/ooo/trunk/core/dictionaries/de_AT/README_hyph_de_AT.txt
/ooo/trunk/core/gettext/gettext-0.18.1.1.patch
/ooo/trunk/core/apache-commons/patches/codec.patch
/ooo/trunk/core/libcroco/libcroco-0.6.2.patch
/ooo/trunk/core/testautomation/writer/optional/input/import/mactext.txt
/ooo/trunk/core/graphite/graphite-2.3.1.patch
/ooo/trunk/core/hwpfilter/source/hwpeq.cpp
/ooo/trunk/core/solenv/bin/cwstouched.pl
/ooo/trunk/core/readlicense_oo/html/THIRDPARTYLICENSEREADME.html
/ooo/trunk/core/writerfilter/source/doctok/escher.html
/ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML
Schemas/xsdlib.xsd
/ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML
Schemas/wordnetaux.xsd
/ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/body.xsl
/ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/style_mapping_css.xsl

Whereas previously I tried to fix these files with dos2unix, this time
I simply omitted them from the import.   The automated "one size fits
all" approach did not seem right since some of these files, e.g., the
mactext.txt, appear to be intentionally using weird EOL conventions.

We'll need to resolve these cases individually and add them to the new
repository, eventually.  In some cases we might decide to treat them
as binary files, in other cases we could dos2unix them, in other cases
we'll need to convert the character encoding from UTF-16 to UTF-8.
But we can figure that out later.

You can download the new dump file from:  www.robweir.com/ooo-dump-new.gz

md5sum of the unzipped ooo-dump file is:   a6651e98b1a92f5158a08921e85a7a3a

-Rob

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Eike Rathke <oo...@erack.de>]

Hi Daniel,

On Tuesday, 2011-08-16 20:03:38 +0300, Daniel Shahaf wrote:

> > I'm assuming that on the Infra side, they would first lock SVN from
> > writes, do a dump of the existing AOOo repository, as a backup, then
> > load my dump file.  That way, if anything goes wrong, they can restart
> > from a known state.
> 
> Essentially, yes.  Except that there is no "AOOo repository" --- all of
> /repos/asf is one repository.

I noticed that when I initially did git svn clone "the ooo part of the
repo", it took a while until it scanned the some 100000 revisions, and
I thought that was for the incubator podlings' site/www/wiki only. But,
is it really wise to have even the actual source code all in one repo?
Given that AOOo will add 76k files and in future lots of change sets are
to be expected, won't that affect the overall repo too much in the sense
that it will add revisions for everyone not involved with AOOo code?
Just thinking of future git svn clone approaches and the like.

What's the reason to have all in one repository?

  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: [Repo][Proposal] OOO340 SVN Dump file import

[Daniel Shahaf <d....@daniel.shahaf.name>]

Rob Weir wrote on Tue, Aug 16, 2011 at 12:53:12 -0400:
> I'm not certain whether I have permissions to load the dump file
> directly, without going through Apache Infra.  I'd like to avoid doing
> this as a giant commit of 76K files because of difficulty of dealing
> with partial failures.  I also want to avoid sending a 1.8 GB commit
> note to your inbox!
> 

Don't worry about the commit mails; the mailer has an upper size limit.

But a 1.8GB commit will mean that everyone in Europe who commits after
you and before your commit has synced won't be able to update to the
revision they just committed, which will cause some problems.

> I'm assuming that on the Infra side, they would first lock SVN from
> writes, do a dump of the existing AOOo repository, as a backup, then
> load my dump file.  That way, if anything goes wrong, they can restart
> from a known state.

Essentially, yes.  Except that there is no "AOOo repository" --- all of
/repos/asf is one repository.

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ap...@robweir.com>]

On Tue, Aug 16, 2011 at 12:27 PM, Pedro Giffuni <gi...@tutopia.com> wrote:
> On Tue, 16 Aug 2011 18:44:30 +0300, Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
> ...
>>>
>>> Perhaps I am missing something, but couldn't you just go ahead
>>> and commit it directly in the server?
>>
>> No, the two copies Rob mentioned are the dump and the repository, but
>> you could
>>
>> curl | gzip -dc | svnadmin load
>>
>> to avoid one of them.
>
> I meant that, given that we are not preserving any history a dump seems
> overhead. Instead of having people downloading dumps, setting up their
> own repositories and presumably have infra@ load it afterwards, we
> should just commit it (assuming initial issues were fixed).
>

Consider this to be a form of Review-Then-Commit (RTC).  Those who
wish to review the dump file are welcome to do so.  Those who wish to
object to the approach are welcome to do so take the lead on an
alternative approach.  But if I don't receive objections, then I'll
assume lazy consensus and go forward with this.

Since we are talking about 76 thousand files, it did not seem like the
best place to apply CTR.

I'm not certain whether I have permissions to load the dump file
directly, without going through Apache Infra.  I'd like to avoid doing
this as a giant commit of 76K files because of difficulty of dealing
with partial failures.  I also want to avoid sending a 1.8 GB commit
note to your inbox!

I'm assuming that on the Infra side, they would first lock SVN from
writes, do a dump of the existing AOOo repository, as a backup, then
load my dump file.  That way, if anything goes wrong, they can restart
from a known state.


> cheers,
>
> Pedro.
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Daniel Shahaf <d....@daniel.shahaf.name>]

Pedro Giffuni wrote on Tue, Aug 16, 2011 at 11:27:47 -0500:
> On Tue, 16 Aug 2011 18:44:30 +0300, Daniel Shahaf
> <d....@daniel.shahaf.name> wrote:
> ...
> >>
> >>Perhaps I am missing something, but couldn't you just go ahead
> >>and commit it directly in the server?
> >
> >No, the two copies Rob mentioned are the dump and the repository, but
> >you could
> >
> >curl | gzip -dc | svnadmin load
> >
> >to avoid one of them.
> 
> I meant that, given that we are not preserving any history a dump seems
> overhead. Instead of having people downloading dumps, setting up their
> own repositories and presumably have infra@ load it afterwards, we
> should just commit it (assuming initial issues were fixed).
> 

Don't commit a 350MB commit without talking to infra first, so as to
avoid having the EU mirror be behind HEAD for too long, thanks.

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Pedro Giffuni <gi...@tutopia.com>]

 On Tue, 16 Aug 2011 18:44:30 +0300, Daniel Shahaf 
 <d....@daniel.shahaf.name> wrote:
 ...
>>
>> Perhaps I am missing something, but couldn't you just go ahead
>> and commit it directly in the server?
>
> No, the two copies Rob mentioned are the dump and the repository, but
> you could
>
> curl | gzip -dc | svnadmin load
>
> to avoid one of them.

 I meant that, given that we are not preserving any history a dump seems
 overhead. Instead of having people downloading dumps, setting up their
 own repositories and presumably have infra@ load it afterwards, we
 should just commit it (assuming initial issues were fixed).

 cheers,

 Pedro.

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Daniel Shahaf <d....@daniel.shahaf.name>]

Pedro F. Giffuni wrote on Tue, Aug 16, 2011 at 08:18:39 -0700:
> Hi again;
> 
> 
> ----- Original Message -----
> > On Tue, Aug 16, 2011 at 9:06 AM, Rob Weir <ap...@robweir.com> wrote:
> ...
> >> 
> >>  We're only checking in the tip of the trunk into SVN.  The history is
> >>  going to Apache-Extras, and remaining in Hg.  I don't see how you
> >>  would use the history to verify a SVN repository that does not contain
> >>  the history.  But if you think you really need to reference it for
> >>  verification purposes, you can get it at:
> >> 
> >>  http://hg.services.openoffice.org/OOO340
> >> 
> >>  and
> >> 
> >>  http://hg.services.openoffice.org/master_l10n/OOO340/
> >> 
> >>  Obviously the SVN dump does carry a history as well, but it is
> >>  trivial:  Revision 1 "Initial Import"
> >> 
> >>>  Second, it would be very useful if someone did that on an
> >>>  Internet-accessible box; it's MUCH easier to review a dump
> >>>  after it has been loaded somewhere.
> >>> 
> >> 
> >>  Making a local svn repository and loading the dump file is easy:
> >> 
> >>  svnadmin create aooo
> >> 
> >>  svnadmin load aooo <ooo-dump
> >> 
> >>  You don't need much free disk space for this.  2 GB should be 
> > sufficient.
> >> 
> > 
> > Actually, double that since you'll need, during the import process,
> > disk space for both the dump file and the repository.
> > 
> 
> 
> Perhaps I am missing something, but couldn't you just go ahead
> and commit it directly in the server?

No, the two copies Rob mentioned are the dump and the repository, but you could

curl | gzip -dc | svnadmin load

to avoid one of them.

Re: [Repo][Proposal] OOO340 SVN Dump file import

["Pedro F. Giffuni" <gi...@tutopia.com>]

Hi again;


----- Original Message -----
> On Tue, Aug 16, 2011 at 9:06 AM, Rob Weir <ap...@robweir.com> wrote:
...
>> 
>>  We're only checking in the tip of the trunk into SVN.  The history is
>>  going to Apache-Extras, and remaining in Hg.  I don't see how you
>>  would use the history to verify a SVN repository that does not contain
>>  the history.  But if you think you really need to reference it for
>>  verification purposes, you can get it at:
>> 
>>  http://hg.services.openoffice.org/OOO340
>> 
>>  and
>> 
>>  http://hg.services.openoffice.org/master_l10n/OOO340/
>> 
>>  Obviously the SVN dump does carry a history as well, but it is
>>  trivial:  Revision 1 "Initial Import"
>> 
>>>  Second, it would be very useful if someone did that on an
>>>  Internet-accessible box; it's MUCH easier to review a dump
>>>  after it has been loaded somewhere.
>>> 
>> 
>>  Making a local svn repository and loading the dump file is easy:
>> 
>>  svnadmin create aooo
>> 
>>  svnadmin load aooo <ooo-dump
>> 
>>  You don't need much free disk space for this.  2 GB should be 
> sufficient.
>> 
> 
> Actually, double that since you'll need, during the import process,
> disk space for both the dump file and the repository.
> 


Perhaps I am missing something, but couldn't you just go ahead
and commit it directly in the server?

Pedro.

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ap...@robweir.com>]

On Tue, Aug 16, 2011 at 9:06 AM, Rob Weir <ap...@robweir.com> wrote:
> On Tue, Aug 16, 2011 at 8:48 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> Rob Weir wrote on Tue, Aug 16, 2011 at 08:32:19 -0400:
>>> Is anyone planning on actually reviewing the dump file, e.g., loading
>>> it into a local repository, checking it out and looking at the
>>> resulting source tree?
>>
>> First, need to review history too, not just a checkout of HEAD.
>>
>
> We're only checking in the tip of the trunk into SVN.  The history is
> going to Apache-Extras, and remaining in Hg.  I don't see how you
> would use the history to verify a SVN repository that does not contain
> the history.  But if you think you really need to reference it for
> verification purposes, you can get it at:
>
> http://hg.services.openoffice.org/OOO340
>
> and
>
> http://hg.services.openoffice.org/master_l10n/OOO340/
>
> Obviously the SVN dump does carry a history as well, but it is
> trivial:  Revision 1 "Initial Import"
>
>> Second, it would be very useful if someone did that on an
>> Internet-accessible box; it's MUCH easier to review a dump
>> after it has been loaded somewhere.
>>
>
> Making a local svn repository and loading the dump file is easy:
>
> svnadmin create aooo
>
> svnadmin load aooo <ooo-dump
>
> You don't need much free disk space for this.  2 GB should be sufficient.
>

Actually, double that since you'll need, during the import process,
disk space for both the dump file and the repository.

> Of course, if someone can do that on a server, it is even easier.
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ap...@robweir.com>]

On Tue, Aug 16, 2011 at 8:48 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Rob Weir wrote on Tue, Aug 16, 2011 at 08:32:19 -0400:
>> Is anyone planning on actually reviewing the dump file, e.g., loading
>> it into a local repository, checking it out and looking at the
>> resulting source tree?
>
> First, need to review history too, not just a checkout of HEAD.
>

We're only checking in the tip of the trunk into SVN.  The history is
going to Apache-Extras, and remaining in Hg.  I don't see how you
would use the history to verify a SVN repository that does not contain
the history.  But if you think you really need to reference it for
verification purposes, you can get it at:

http://hg.services.openoffice.org/OOO340

and

http://hg.services.openoffice.org/master_l10n/OOO340/

Obviously the SVN dump does carry a history as well, but it is
trivial:  Revision 1 "Initial Import"

> Second, it would be very useful if someone did that on an
> Internet-accessible box; it's MUCH easier to review a dump
> after it has been loaded somewhere.
>

Making a local svn repository and loading the dump file is easy:

svnadmin create aooo

svnadmin load aooo <ooo-dump

You don't need much free disk space for this.  2 GB should be sufficient.

Of course, if someone can do that on a server, it is even easier.

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Daniel Shahaf <d....@daniel.shahaf.name>]

Rob Weir wrote on Tue, Aug 16, 2011 at 08:32:19 -0400:
> Is anyone planning on actually reviewing the dump file, e.g., loading
> it into a local repository, checking it out and looking at the
> resulting source tree?

First, need to review history too, not just a checkout of HEAD.

Second, it would be very useful if someone did that on an
Internet-accessible box; it's MUCH easier to review a dump
after it has been loaded somewhere.

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ap...@robweir.com>]

On Tue, Aug 16, 2011 at 8:59 AM, Mathias Bauer <Ma...@gmx.net> wrote:
> On 16.08.2011 14:32, Rob Weir wrote:
>
>> I've uploaded the dump file.  There are no abstract, non-specific
>> risks there.  There may be errors.  But those would be the kind of
>> errors that could be described in detail.  And they may be the kind of
>> errors that could be easily fixed.  But we won't know until someone
>> reviews the dump file.
>>
>> I could certainly repeat the steps on Linux, but that does not
>> eliminate risk from misusing hg, svn or any other source of human
>> error.  We'll need to do more than poke a stick at the dump file to
>> really understand what is in there.
>
> OK, let's be optimistic that besides missing executable bits everything
> will work fine.
>
>> Is anyone planning on actually reviewing the dump file, e.g., loading
>> it into a local repository, checking it out and looking at the
>> resulting source tree?
> Yes, I have planned to do so. I wanted to do it tomorrow (I'm in CEST
> time zone).
>

Ok.  If you are planning on looking at it tomorrow I will redo this
conversion from Linux overnight and post a new ooo-dump.gz.

If anyone else has suggestions on directory structure or SVN options,
etc., please let me know today.

> Regards,
> Mathias
>
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Mathias Bauer <Ma...@gmx.net>]

On 16.08.2011 14:32, Rob Weir wrote:

> I've uploaded the dump file.  There are no abstract, non-specific
> risks there.  There may be errors.  But those would be the kind of
> errors that could be described in detail.  And they may be the kind of
> errors that could be easily fixed.  But we won't know until someone
> reviews the dump file.
> 
> I could certainly repeat the steps on Linux, but that does not
> eliminate risk from misusing hg, svn or any other source of human
> error.  We'll need to do more than poke a stick at the dump file to
> really understand what is in there.

OK, let's be optimistic that besides missing executable bits everything
will work fine.

> Is anyone planning on actually reviewing the dump file, e.g., loading
> it into a local repository, checking it out and looking at the
> resulting source tree?
Yes, I have planned to do so. I wanted to do it tomorrow (I'm in CEST
time zone).

Regards,
Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ap...@robweir.com>]

On Tue, Aug 16, 2011 at 2:38 AM, Mathias Bauer <Ma...@gmx.net> wrote:
> On 15.08.2011 23:48, Michael Stahl wrote:
>
>> On 15.08.2011 18:46, Rob Weir wrote:
>>> We've been discussing for two months now how to get Hg over to SVN.
>>> There have been several suggestions for how the CWS's and complete
>>> revision history could be migrated over, but little progress has been
>>> made.  Either the proposals didn't work, or no volunteers stepped
>>> forward to implement them.
>>>
>>> The alternative proposal was to just check in the tip of the trunk,
>>> without history, and then migrate Hg to Apache-Extras.org, where Hg is
>>> supported.  I've made some progress on this proposal.
>>
>> very good!
>>
>>> Here's what I did.  I'd like some review, to make sure I didn't screw
>>> anything up. I am neither an Hg nor a SVN expert.  But I do have a big
>>> harddrive.
>>>
>>> I used Subversion command-line client, version
>>> 1.6.17-SlikSvn-tag-1.6.17@1130896-WIN32.
>>>
>>> I first brought down OOo, both the trunk and the language stuff, into
>>> separate directories:
>>>
>>> hg clone http://hg.services.openoffice.org/OOO340
>>> hg clone http://hg.services.openoffice.org/master_l10n/OOO340/
>>>
>>> I then moved these into a common directory structure, as Ingrid had
>>> earlier suggested:
>>>
>>> ooo/trunk/core --- all the OOO340 stuff
>>> ooo/trunk/l10n -- all the language stuff
>>>
>>> I removed the .Hg directories before proceeding, so I had a clean local copy.
>>>
>>> I then created a local SVN repository, enabled auto-props to get the
>>> proper EOL treatment and imported the project:
>>>
>>> svn import c:\merged file:///c:/svn-repo/ -m "initial import"
>>
>> a potential issue when doing the import on windows is that the execute
>> bit of the files may get lost (i think windows filesystems don't support
>> that natively).
>
> Ah, yes, that's a good point. From past experience I don't recommend
> doing any critical work on OOo repositories on Windows. Even cygwin is
> just a crudge and there are many pitfalls. As this should be the base
> work for the new project we definitely should take no risk here and do
> the import and create the svn dump on Linux or Mac OSX.
>

I've uploaded the dump file.  There are no abstract, non-specific
risks there.  There may be errors.  But those would be the kind of
errors that could be described in detail.  And they may be the kind of
errors that could be easily fixed.  But we won't know until someone
reviews the dump file.

I could certainly repeat the steps on Linux, but that does not
eliminate risk from misusing hg, svn or any other source of human
error.  We'll need to do more than poke a stick at the dump file to
really understand what is in there.

Is anyone planning on actually reviewing the dump file, e.g., loading
it into a local repository, checking it out and looking at the
resulting source tree?


> Regards,
> Mathias
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Mathias Bauer <Ma...@gmx.net>]

On 15.08.2011 23:48, Michael Stahl wrote:

> On 15.08.2011 18:46, Rob Weir wrote:
>> We've been discussing for two months now how to get Hg over to SVN.
>> There have been several suggestions for how the CWS's and complete
>> revision history could be migrated over, but little progress has been
>> made.  Either the proposals didn't work, or no volunteers stepped
>> forward to implement them.
>>
>> The alternative proposal was to just check in the tip of the trunk,
>> without history, and then migrate Hg to Apache-Extras.org, where Hg is
>> supported.  I've made some progress on this proposal.
> 
> very good!
> 
>> Here's what I did.  I'd like some review, to make sure I didn't screw
>> anything up. I am neither an Hg nor a SVN expert.  But I do have a big
>> harddrive.
>>
>> I used Subversion command-line client, version
>> 1.6.17-SlikSvn-tag-1.6.17@1130896-WIN32.
>>
>> I first brought down OOo, both the trunk and the language stuff, into
>> separate directories:
>>
>> hg clone http://hg.services.openoffice.org/OOO340
>> hg clone http://hg.services.openoffice.org/master_l10n/OOO340/
>>
>> I then moved these into a common directory structure, as Ingrid had
>> earlier suggested:
>>
>> ooo/trunk/core --- all the OOO340 stuff
>> ooo/trunk/l10n -- all the language stuff
>>
>> I removed the .Hg directories before proceeding, so I had a clean local copy.
>>
>> I then created a local SVN repository, enabled auto-props to get the
>> proper EOL treatment and imported the project:
>>
>> svn import c:\merged file:///c:/svn-repo/ -m "initial import"
> 
> a potential issue when doing the import on windows is that the execute 
> bit of the files may get lost (i think windows filesystems don't support 
> that natively).

Ah, yes, that's a good point. From past experience I don't recommend
doing any critical work on OOo repositories on Windows. Even cygwin is
just a crudge and there are many pitfalls. As this should be the base
work for the new project we definitely should take no risk here and do
the import and create the svn dump on Linux or Mac OSX.

Regards,
Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Michael Stahl <ms...@openoffice.org>]

On 15.08.2011 18:46, Rob Weir wrote:
> We've been discussing for two months now how to get Hg over to SVN.
> There have been several suggestions for how the CWS's and complete
> revision history could be migrated over, but little progress has been
> made.  Either the proposals didn't work, or no volunteers stepped
> forward to implement them.
>
> The alternative proposal was to just check in the tip of the trunk,
> without history, and then migrate Hg to Apache-Extras.org, where Hg is
> supported.  I've made some progress on this proposal.

very good!

> Here's what I did.  I'd like some review, to make sure I didn't screw
> anything up. I am neither an Hg nor a SVN expert.  But I do have a big
> harddrive.
>
> I used Subversion command-line client, version
> 1.6.17-SlikSvn-tag-1.6.17@1130896-WIN32.
>
> I first brought down OOo, both the trunk and the language stuff, into
> separate directories:
>
> hg clone http://hg.services.openoffice.org/OOO340
> hg clone http://hg.services.openoffice.org/master_l10n/OOO340/
>
> I then moved these into a common directory structure, as Ingrid had
> earlier suggested:
>
> ooo/trunk/core --- all the OOO340 stuff
> ooo/trunk/l10n -- all the language stuff
>
> I removed the .Hg directories before proceeding, so I had a clean local copy.
>
> I then created a local SVN repository, enabled auto-props to get the
> proper EOL treatment and imported the project:
>
> svn import c:\merged file:///c:/svn-repo/ -m "initial import"

a potential issue when doing the import on windows is that the execute 
bit of the files may get lost (i think windows filesystems don't support 
that natively).

this could perhaps work by using Cygwin tools (Hg and SVN), because 
Cygwin has to emulate it somehow anyway.

or of course it could be fixed later, there shouldn't be many files that 
need it...

regards,
  michael

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Mathias Bauer <Ma...@gmx.net>]

On 15.08.2011 18:46, Rob Weir wrote:

> We've been discussing for two months now how to get Hg over to SVN.
> There have been several suggestions for how the CWS's and complete
> revision history could be migrated over, but little progress has been
> made.  Either the proposals didn't work, or no volunteers stepped
> forward to implement them.
> 
> The alternative proposal was to just check in the tip of the trunk,
> without history, and then migrate Hg to Apache-Extras.org, where Hg is
> supported.  I've made some progress on this proposal.

Until now nobody tried the other way and after some thinking and trying
I think that it is not doable, at least not with reasonable effort. IMHO
you just did the right thing.

I will have a look on the results soon.

Regards,
Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ap...@robweir.com>]

On Tue, Aug 16, 2011 at 1:29 PM, Ingrid von der Mehden
<In...@gmx-topmail.de> wrote:
> Am 16.08.2011 19:04, schrieb Rob Weir:
>>
>> On Tue, Aug 16, 2011 at 12:45 PM, Ingrid von der Mehden
>> <In...@gmx-topmail.de>  wrote:
>>>
>>> Am 16.08.2011 16:21, schrieb Rob Weir:
>>>>
>>>> On Tue, Aug 16, 2011 at 10:02 AM, Ingrid von der Mehden
>>>> <In...@gmx-topmail.de>    wrote:
>>>>>
>>>>> Am 15.08.2011 18:46, schrieb Rob Weir:
>>>>> [...]
>>>>>>
>>>>>> ooo/trunk/core --- all the OOO340 stuff
>>>>>> ooo/trunk/l10n -- all the language stuff
>>>>>>
>>>>>
>>>>> Actually I would suggest to name the directory 'main' instead of
>>>>> 'core'.
>>>>> The term 'core' is used already in several modules within the OOo
>>>>> source
>>>>> code, where it does imply that this is something without user interface
>>>>> (more the model part in MVC pattern). So using the term 'core' for the
>>>>> whole
>>>>> office (including user interface) is misleading and could create
>>>>> confusion.
>>>>>
>>>>
>>>> Note what we already have in SVN:
>>>>
>>>> https://svn.apache.org/repos/asf/incubator/ooo/
>>>>
>>>> We're mixing site files, and source in the same repository.
>>>>
>>>> I wonder if we want a "src" directory that is a sibling of "site".
>>>> And then "main" and "extras" under that?
>>>>
>>>
>>> I just searched through the different Apache projects and the scheme as
>>> we
>>> have it is quite common:
>>>
>>> 'Apache Project'/site
>>> 'Apache Project'/trunk
>>> 'Apache Project'/branches
>>> 'Apache Project'/tags
>>>
>>> Those directories can be found very often. I think it is not too bad to
>>> stay
>>> with the common scheme. This makes it easier to switch between projects
>>> for
>>> all Apache committers.
>>>
>>> ------
>>>
>>> If we instead choose to have a src directory next to site, I would vote
>>> to
>>> put trunk, branches and tags into it. All the different code lines are
>>> all
>>> src, they belong together. So we would have:
>>>
>>> ooo/site
>>> ooo/src/trunk/main
>>> ooo/src/trunk/extras
>>> ooo/src/branches
>>> ooo/src/tags
>>>
>>> This will lead to an additional directory in the path. But the logical
>>> grouping is cleaner. A pitfall might be that some people might expect
>>> only
>>> source code in a directory called src and not things like help content or
>>> translation.
>>>
>>> So I still prefer:
>>> ooo/trunk/main --- all the OOO340 stuff
>>> ooo/trunk/extras/l10n -- all the language stuff
>>>
>>
>> OK.  I'll do that for the the next run.  This will be Linux, with your
>> directory structure.   Should be ready in 3 hours or so.
>>
>
> Cool, thanks a lot!
> My svn repository from the previous dump file is still in load process, so I
> haven't seen the concrete structure in l10n so far.
> Is there a directory duplication l10n/l10n?
>

I don't think so.  In the new version I'm dumping right now we have:

ooo/trunk/extras/l10n

and then under there we have:

ooo/trunk/extras/l10n/prj
ooo/trunk/extras/l10n/source
ooo/trunk/extras/l10n/util


> I think it should be sufficient if we technically import the l10n repository
> directly into the extras directory. This should then lead to pathes like
> this:
> ooo/trunk/extras/l10n/source
> and not
> ooo/trunk/extras/l10n/l10n/source
>

Right.

> Kind regards,
> Ingrid
>
>>> Kind regards,
>>> Ingrid
>>>
>>>>> I would also put the l10n stuff into a further directory. Those people
>>>>> who
>>>>> have no idea what l10n might be, could benefit from a simpler name
>>>>> 'extras'.
>>>>> This makes the first browsing experience in the source code less
>>>>> frightening.
>>>>>
>>>>> So I would suggest:
>>>>> ooo/trunk/main --- all the OOO340 stuff
>>>>> ooo/trunk/extras/l10n -- all the language stuff
>>>>>
>>>>> The full proposal was here:
>>>>>
>>>>>
>>>>> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3C4E3D07B7.8080101@gmx-topmail.de%3E
>>>>>
>>>>> Kind regards,
>>>>> Ingrid
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Ingrid von der Mehden <In...@gmx-topmail.de>]

Am 16.08.2011 19:04, schrieb Rob Weir:
> On Tue, Aug 16, 2011 at 12:45 PM, Ingrid von der Mehden
> <In...@gmx-topmail.de>  wrote:
>> Am 16.08.2011 16:21, schrieb Rob Weir:
>>>
>>> On Tue, Aug 16, 2011 at 10:02 AM, Ingrid von der Mehden
>>> <In...@gmx-topmail.de>    wrote:
>>>>
>>>> Am 15.08.2011 18:46, schrieb Rob Weir:
>>>> [...]
>>>>>
>>>>> ooo/trunk/core --- all the OOO340 stuff
>>>>> ooo/trunk/l10n -- all the language stuff
>>>>>
>>>>
>>>> Actually I would suggest to name the directory 'main' instead of 'core'.
>>>> The term 'core' is used already in several modules within the OOo source
>>>> code, where it does imply that this is something without user interface
>>>> (more the model part in MVC pattern). So using the term 'core' for the
>>>> whole
>>>> office (including user interface) is misleading and could create
>>>> confusion.
>>>>
>>>
>>> Note what we already have in SVN:
>>>
>>> https://svn.apache.org/repos/asf/incubator/ooo/
>>>
>>> We're mixing site files, and source in the same repository.
>>>
>>> I wonder if we want a "src" directory that is a sibling of "site".
>>> And then "main" and "extras" under that?
>>>
>>
>> I just searched through the different Apache projects and the scheme as we
>> have it is quite common:
>>
>> 'Apache Project'/site
>> 'Apache Project'/trunk
>> 'Apache Project'/branches
>> 'Apache Project'/tags
>>
>> Those directories can be found very often. I think it is not too bad to stay
>> with the common scheme. This makes it easier to switch between projects for
>> all Apache committers.
>>
>> ------
>>
>> If we instead choose to have a src directory next to site, I would vote to
>> put trunk, branches and tags into it. All the different code lines are all
>> src, they belong together. So we would have:
>>
>> ooo/site
>> ooo/src/trunk/main
>> ooo/src/trunk/extras
>> ooo/src/branches
>> ooo/src/tags
>>
>> This will lead to an additional directory in the path. But the logical
>> grouping is cleaner. A pitfall might be that some people might expect only
>> source code in a directory called src and not things like help content or
>> translation.
>>
>> So I still prefer:
>> ooo/trunk/main --- all the OOO340 stuff
>> ooo/trunk/extras/l10n -- all the language stuff
>>
>
> OK.  I'll do that for the the next run.  This will be Linux, with your
> directory structure.   Should be ready in 3 hours or so.
>

Cool, thanks a lot!
My svn repository from the previous dump file is still in load process, 
so I haven't seen the concrete structure in l10n so far.
Is there a directory duplication l10n/l10n?

I think it should be sufficient if we technically import the l10n 
repository directly into the extras directory. This should then lead to 
pathes like this:
ooo/trunk/extras/l10n/source
and not
ooo/trunk/extras/l10n/l10n/source

Kind regards,
Ingrid

>> Kind regards,
>> Ingrid
>>
>>>> I would also put the l10n stuff into a further directory. Those people
>>>> who
>>>> have no idea what l10n might be, could benefit from a simpler name
>>>> 'extras'.
>>>> This makes the first browsing experience in the source code less
>>>> frightening.
>>>>
>>>> So I would suggest:
>>>> ooo/trunk/main --- all the OOO340 stuff
>>>> ooo/trunk/extras/l10n -- all the language stuff
>>>>
>>>> The full proposal was here:
>>>>
>>>> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3C4E3D07B7.8080101@gmx-topmail.de%3E
>>>>
>>>> Kind regards,
>>>> Ingrid
>>>>
>>>>
>>>>
>>>
>>
>>
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ap...@robweir.com>]

On Tue, Aug 16, 2011 at 12:45 PM, Ingrid von der Mehden
<In...@gmx-topmail.de> wrote:
> Am 16.08.2011 16:21, schrieb Rob Weir:
>>
>> On Tue, Aug 16, 2011 at 10:02 AM, Ingrid von der Mehden
>> <In...@gmx-topmail.de>  wrote:
>>>
>>> Am 15.08.2011 18:46, schrieb Rob Weir:
>>> [...]
>>>>
>>>> ooo/trunk/core --- all the OOO340 stuff
>>>> ooo/trunk/l10n -- all the language stuff
>>>>
>>>
>>> Actually I would suggest to name the directory 'main' instead of 'core'.
>>> The term 'core' is used already in several modules within the OOo source
>>> code, where it does imply that this is something without user interface
>>> (more the model part in MVC pattern). So using the term 'core' for the
>>> whole
>>> office (including user interface) is misleading and could create
>>> confusion.
>>>
>>
>> Note what we already have in SVN:
>>
>> https://svn.apache.org/repos/asf/incubator/ooo/
>>
>> We're mixing site files, and source in the same repository.
>>
>> I wonder if we want a "src" directory that is a sibling of "site".
>> And then "main" and "extras" under that?
>>
>
> I just searched through the different Apache projects and the scheme as we
> have it is quite common:
>
> 'Apache Project'/site
> 'Apache Project'/trunk
> 'Apache Project'/branches
> 'Apache Project'/tags
>
> Those directories can be found very often. I think it is not too bad to stay
> with the common scheme. This makes it easier to switch between projects for
> all Apache committers.
>
> ------
>
> If we instead choose to have a src directory next to site, I would vote to
> put trunk, branches and tags into it. All the different code lines are all
> src, they belong together. So we would have:
>
> ooo/site
> ooo/src/trunk/main
> ooo/src/trunk/extras
> ooo/src/branches
> ooo/src/tags
>
> This will lead to an additional directory in the path. But the logical
> grouping is cleaner. A pitfall might be that some people might expect only
> source code in a directory called src and not things like help content or
> translation.
>
> So I still prefer:
> ooo/trunk/main --- all the OOO340 stuff
> ooo/trunk/extras/l10n -- all the language stuff
>

OK.  I'll do that for the the next run.  This will be Linux, with your
directory structure.   Should be ready in 3 hours or so.

> Kind regards,
> Ingrid
>
>>> I would also put the l10n stuff into a further directory. Those people
>>> who
>>> have no idea what l10n might be, could benefit from a simpler name
>>> 'extras'.
>>> This makes the first browsing experience in the source code less
>>> frightening.
>>>
>>> So I would suggest:
>>> ooo/trunk/main --- all the OOO340 stuff
>>> ooo/trunk/extras/l10n -- all the language stuff
>>>
>>> The full proposal was here:
>>>
>>> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3C4E3D07B7.8080101@gmx-topmail.de%3E
>>>
>>> Kind regards,
>>> Ingrid
>>>
>>>
>>>
>>
>
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

["Marcus (OOo)" <ma...@wtnet.de>]

Am 08/16/2011 06:45 PM, schrieb Ingrid von der Mehden:
> Am 16.08.2011 16:21, schrieb Rob Weir:
>> On Tue, Aug 16, 2011 at 10:02 AM, Ingrid von der Mehden
>> <In...@gmx-topmail.de> wrote:
>>> Am 15.08.2011 18:46, schrieb Rob Weir:
>>> [...]
>>>>
>>>> ooo/trunk/core --- all the OOO340 stuff
>>>> ooo/trunk/l10n -- all the language stuff
>>>>
>>>
>>> Actually I would suggest to name the directory 'main' instead of 'core'.
>>> The term 'core' is used already in several modules within the OOo source
>>> code, where it does imply that this is something without user interface
>>> (more the model part in MVC pattern). So using the term 'core' for
>>> the whole
>>> office (including user interface) is misleading and could create
>>> confusion.
>>>
>>
>> Note what we already have in SVN:
>>
>> https://svn.apache.org/repos/asf/incubator/ooo/
>>
>> We're mixing site files, and source in the same repository.
>>
>> I wonder if we want a "src" directory that is a sibling of "site".
>> And then "main" and "extras" under that?
>>
>
> I just searched through the different Apache projects and the scheme as
> we have it is quite common:
>
> 'Apache Project'/site
> 'Apache Project'/trunk
> 'Apache Project'/branches
> 'Apache Project'/tags
>
> Those directories can be found very often. I think it is not too bad to
> stay with the common scheme. This makes it easier to switch between
> projects for all Apache committers.
>
> ------
>
> If we instead choose to have a src directory next to site, I would vote
> to put trunk, branches and tags into it. All the different code lines
> are all src, they belong together. So we would have:
>
> ooo/site
> ooo/src/trunk/main
> ooo/src/trunk/extras
> ooo/src/branches
> ooo/src/tags
>
> This will lead to an additional directory in the path. But the logical
> grouping is cleaner. A pitfall might be that some people might expect
> only source code in a directory called src and not things like help
> content or translation.

Yes, good thought.

> So I still prefer:
> ooo/trunk/main --- all the OOO340 stuff
> ooo/trunk/extras/l10n -- all the language stuff

Even as non-coder I support this.

Marcus



>>> I would also put the l10n stuff into a further directory. Those
>>> people who
>>> have no idea what l10n might be, could benefit from a simpler name
>>> 'extras'.
>>> This makes the first browsing experience in the source code less
>>> frightening.
>>>
>>> So I would suggest:
>>> ooo/trunk/main --- all the OOO340 stuff
>>> ooo/trunk/extras/l10n -- all the language stuff
>>>
>>> The full proposal was here:
>>> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3C4E3D07B7.8080101@gmx-topmail.de%3E
>>>
>>>
>>> Kind regards,
>>> Ingrid

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Ingrid von der Mehden <In...@gmx-topmail.de>]

Am 16.08.2011 16:21, schrieb Rob Weir:
> On Tue, Aug 16, 2011 at 10:02 AM, Ingrid von der Mehden
> <In...@gmx-topmail.de>  wrote:
>> Am 15.08.2011 18:46, schrieb Rob Weir:
>> [...]
>>>
>>> ooo/trunk/core --- all the OOO340 stuff
>>> ooo/trunk/l10n -- all the language stuff
>>>
>>
>> Actually I would suggest to name the directory 'main' instead of 'core'.
>> The term 'core' is used already in several modules within the OOo source
>> code, where it does imply that this is something without user interface
>> (more the model part in MVC pattern). So using the term 'core' for the whole
>> office (including user interface) is misleading and could create confusion.
>>
>
> Note what we already have in SVN:
>
> https://svn.apache.org/repos/asf/incubator/ooo/
>
> We're mixing site files, and source in the same repository.
>
> I wonder if we want a "src" directory that is a sibling of "site".
> And then "main" and "extras" under that?
>

I just searched through the different Apache projects and the scheme as 
we have it is quite common:

'Apache Project'/site
'Apache Project'/trunk
'Apache Project'/branches
'Apache Project'/tags

Those directories can be found very often. I think it is not too bad to 
stay with the common scheme. This makes it easier to switch between 
projects for all Apache committers.

------

If we instead choose to have a src directory next to site, I would vote 
to put trunk, branches and tags into it. All the different code lines 
are all src, they belong together. So we would have:

ooo/site
ooo/src/trunk/main
ooo/src/trunk/extras
ooo/src/branches
ooo/src/tags

This will lead to an additional directory in the path. But the logical 
grouping is cleaner. A pitfall might be that some people might expect 
only source code in a directory called src and not things like help 
content or translation.

So I still prefer:
ooo/trunk/main --- all the OOO340 stuff
ooo/trunk/extras/l10n -- all the language stuff

Kind regards,
Ingrid

>> I would also put the l10n stuff into a further directory. Those people who
>> have no idea what l10n might be, could benefit from a simpler name 'extras'.
>> This makes the first browsing experience in the source code less
>> frightening.
>>
>> So I would suggest:
>> ooo/trunk/main --- all the OOO340 stuff
>> ooo/trunk/extras/l10n -- all the language stuff
>>
>> The full proposal was here:
>> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3C4E3D07B7.8080101@gmx-topmail.de%3E
>>
>> Kind regards,
>> Ingrid
>>
>>
>>
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ap...@robweir.com>]

On Tue, Aug 16, 2011 at 10:02 AM, Ingrid von der Mehden
<In...@gmx-topmail.de> wrote:
> Am 15.08.2011 18:46, schrieb Rob Weir:
> [...]
>>
>> ooo/trunk/core --- all the OOO340 stuff
>> ooo/trunk/l10n -- all the language stuff
>>
>
> Actually I would suggest to name the directory 'main' instead of 'core'.
> The term 'core' is used already in several modules within the OOo source
> code, where it does imply that this is something without user interface
> (more the model part in MVC pattern). So using the term 'core' for the whole
> office (including user interface) is misleading and could create confusion.
>

Note what we already have in SVN:

https://svn.apache.org/repos/asf/incubator/ooo/

We're mixing site files, and source in the same repository.

I wonder if we want a "src" directory that is a sibling of "site".
And then "main" and "extras" under that?

> I would also put the l10n stuff into a further directory. Those people who
> have no idea what l10n might be, could benefit from a simpler name 'extras'.
> This makes the first browsing experience in the source code less
> frightening.
>
> So I would suggest:
> ooo/trunk/main --- all the OOO340 stuff
> ooo/trunk/extras/l10n -- all the language stuff
>
> The full proposal was here:
> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3C4E3D07B7.8080101@gmx-topmail.de%3E
>
> Kind regards,
> Ingrid
>
>
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Ingrid von der Mehden <In...@gmx-topmail.de>]

Am 15.08.2011 18:46, schrieb Rob Weir:
[...]
> ooo/trunk/core --- all the OOO340 stuff
> ooo/trunk/l10n -- all the language stuff
>

Actually I would suggest to name the directory 'main' instead of 'core'.
The term 'core' is used already in several modules within the OOo source 
code, where it does imply that this is something without user interface 
(more the model part in MVC pattern). So using the term 'core' for the 
whole office (including user interface) is misleading and could create 
confusion.

I would also put the l10n stuff into a further directory. Those people 
who have no idea what l10n might be, could benefit from a simpler name 
'extras'. This makes the first browsing experience in the source code 
less frightening.

So I would suggest:
ooo/trunk/main --- all the OOO340 stuff
ooo/trunk/extras/l10n -- all the language stuff

The full proposal was here:
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3C4E3D07B7.8080101@gmx-topmail.de%3E

Kind regards,
Ingrid

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Mathias Bauer <Ma...@gmx.net>]

On 15.08.2011 23:37, Michael Stahl wrote:

> On 15.08.2011 23:27, Mathias Bauer wrote:
>> On 15.08.2011 22:53, Rob Weir wrote:
>>> The quota is 4GB per project.  I'm not sure what the overhead from Hg
>>> is, but the file system size, uncompressed, is around 1.8 GB.  And
>>> that is just the tip of the trunk.
>>
>> hg stores compressed and according to latest estimations we should be
>> able to keep the repo under 4 GB if we pull all cws into one repo.
> 
> OOO340 HG repo with all 102 CWSes takes 2.8G
> OOO340l10n HG repo takes 198M

I don't think that we will need history for the l10n repo.

Regards,
Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Michael Stahl <ms...@openoffice.org>]

On 15.08.2011 23:27, Mathias Bauer wrote:
> On 15.08.2011 22:53, Rob Weir wrote:
>> The quota is 4GB per project.  I'm not sure what the overhead from Hg
>> is, but the file system size, uncompressed, is around 1.8 GB.  And
>> that is just the tip of the trunk.
>
> hg stores compressed and according to latest estimations we should be
> able to keep the repo under 4 GB if we pull all cws into one repo.

OOO340 HG repo with all 102 CWSes takes 2.8G
OOO340l10n HG repo takes 198M

> Regards,
> Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Mathias Bauer <Ma...@gmx.net>]

On 15.08.2011 22:53, Rob Weir wrote:

> On Mon, Aug 15, 2011 at 3:13 PM, Pedro F. Giffuni <gi...@tutopia.com> wrote:
>> Hi again;
>>
>> --- On Mon, 8/15/11, Rob Weir <ap...@robweir.com> wrote:
>>
>>>
>>> The migration to Apache-Extras is the easy part,
>>> right?  It is just Hg to Hg. So we maintain the
>>> complete revision history that way.
>>>
>>
>> Iff apache-extras offers sufficient space for the
>> repository.
>> Actually, I am not very worried about losing all the
>> history: Apache OO is rather a fresh start anyways.
>>
> 
> The quota is 4GB per project.  I'm not sure what the overhead from Hg
> is, but the file system size, uncompressed, is around 1.8 GB.  And
> that is just the tip of the trunk.

hg stores compressed and according to latest estimations we should be
able to keep the repo under 4 GB if we pull all cws into one repo.

Regards,
Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

["Pedro F. Giffuni" <gi...@tutopia.com>]

--- On Mon, 8/15/11, Rob Weir <ap...@robweir.com> wrote:
...
> 
> I look at it this way:  What do we need to do to
> "unblock" the greatest number of people on the
> project?  Getting the wiki migrated enables many
> contributors.  Getting SVN working does the same.
> Bugzilla is mainly useful once we are actively
> coding.  So I am not worried that it is not
> migrated yet.  But I will be worried if no one
> is working on it soon.
>

I agree, the repository is critical and we could
not wait any more. Bugzilla(or JIRA) are not that
useful without it, but I hope we get that soon
because some of the fixes that I think should be
committed relatively early are in there already.

The LO guys have made some nice summaries of the
bugzilla issues they have tackled already.

cheers,

Pedro.
 
> > Pedro.
> >
> >
> 
> 

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ap...@robweir.com>]

On Mon, Aug 15, 2011 at 3:13 PM, Pedro F. Giffuni <gi...@tutopia.com> wrote:
> Hi again;
>
> --- On Mon, 8/15/11, Rob Weir <ap...@robweir.com> wrote:
>
>>
>> The migration to Apache-Extras is the easy part,
>> right?  It is just Hg to Hg. So we maintain the
>> complete revision history that way.
>>
>
> Iff apache-extras offers sufficient space for the
> repository.
> Actually, I am not very worried about losing all the
> history: Apache OO is rather a fresh start anyways.
>

The quota is 4GB per project.  I'm not sure what the overhead from Hg
is, but the file system size, uncompressed, is around 1.8 GB.  And
that is just the tip of the trunk.

But one encouraging thing is mentioned in their FAQs [1]:

"What other limits exist?

There are disk-space quota limits for both issue tracker attachments
and total Subversion repository size, along with a limit on how many
total projects you are able to create. If you hit these limits, please
contact us via our Google Group or email
google-code-hosting@googlegroups.com directly to discuss the
situation."

So it is possible that we can request expanded space for this repository

If we wanted to ask for expanded space, does anyone know how much we
would need?


[1] http://code.google.com/p/support/wiki/FAQ#Hosted_Tools


>> If someone has a more elegant solution, then, as always,
>> "Patches are Welcome".
>>
>
> One thing I do suggest is to do a raw import from the Hg
> tip. You wrote:
>
>> I then moved these into a common directory structure,
>> as Ingrid had earlier suggested:
>>
>> ooo/trunk/core --- all the OOO340 stuff
>> ooo/trunk/l10n -- all the language stuff
>
> Please do the directory rearrangement in SVN. I have no
> objection to moving stuff but if it's possible to match
> the old history later on, having these changes out of SVN
> won't help.
>

I didn't change any paths within the OOo repositories.  I only placed
those entire legacy trees within the existing SVN so they patch our
existing conventions and don't conflict with each other.

>
>> > Will we also lose the bugzilla database? :-(
>> >
>>
>> Why would we loose Bugzilla?
>>
>
> Because no one is working on it? Not even the test
> import has been done.
>

I look at it this way:  What do we need to do to "unblock" the
greatest number of people on the project?  Getting the wiki migrated
enables many contributors.  Getting SVN working does the same.
Bugzilla is mainly useful once we are actively coding.  So I am not
worried that it is not migrated yet.  But I will be worried if no one
is working on it soon.

> Pedro.
>
>

RE: [Repo][Proposal] OOO340 SVN Dump file import

["Dennis E. Hamilton" <de...@acm.org>]

I think the problem with Apache extras is you get one Hg repository there and there are a bunch over at OpenOffice.org.  So some sort of merge has to happen with respect to all of those child workspaces, etc.  

Also, if I understood the discussion so far, the SVN history was not carried into the Hg repositories?

 - Dennis

-----Original Message-----
From: Rob Weir [mailto:apache@robweir.com] 
Sent: Monday, August 15, 2011 11:26
To: ooo-dev@incubator.apache.org
Subject: Re: [Repo][Proposal] OOO340 SVN Dump file import

On Mon, Aug 15, 2011 at 2:15 PM, Pedro F. Giffuni <gi...@tutopia.com> wrote:
>
>
> --- On Mon, 8/15/11, Rob Weir <ro...@apache.org> wrote:
> ...
>> We've been discussing for two months
>> now how to get Hg over to SVN.
>> There have been several suggestions for how the CWS's and
>> complete revision history could be migrated over, but
>> little progress has been made.  Either the proposals
>> didn't work, or no volunteers stepped forward to
>> implement them.
>>
>> The alternative proposal was to just check in the tip of
>> the trunk, without history, and then migrate Hg to
>> Apache-Extras.org, where Hg is supported.  I've made
>> some progress on this proposal.
>>
>
> I am afraid doing this will be an incomplete solution as
> no one seems to be doing the HG migration to Apache-Extras
> part. In sum, I suspect we will lose all history but
> there seems to be no alternative if we want to start
> development.
>

The migration to Apache-Extras is the easy part, right?  It is just Hg
to Hg. So we maintain the complete revision history that way.

If someone has a more elegant solution, then, as always, "Patches are
Welcome".

> Will we also lose the bugzilla database? :-(
>

Why would we loose Bugzilla?

> cheers,
>
> Pedro.
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

["Marcus (OOo)" <ma...@wtnet.de>]

Am 08/15/2011 10:45 PM, schrieb Pedro Giffuni:
> On Mon, 15 Aug 2011 22:27:29 +0200, Ingrid von der Mehden
> <In...@gmx-topmail.de> wrote:
>> Am 15.08.2011 21:13, schrieb Pedro F. Giffuni:
>>> --- On Mon, 8/15/11, Rob Weir<ap...@robweir.com> wrote:
>> [..]
>>>> ooo/trunk/core --- all the OOO340 stuff
>>>> ooo/trunk/l10n -- all the language stuff
>>>
>>> Please do the directory rearrangement in SVN. I have no
>>> objection to moving stuff but if it's possible to match
>>> the old history later on, having these changes out of SVN
>>> won't help.
>>>
>>
>> On 'old' OOo there are currently already two separate hg
>> repositories. No directory move within either of them was proposed.
>> Only a target directory for each repository needs to be selected. I
>> don't see how this should affect any history mapping later.
>>
>
> Ah .. It's OK then. (sorry as I'm mostly new to the codebase)
>
> Is there some development plan after the intial repo is done or
> can committers start making massive changes (merging branches,
> adding ports, etc ..) right away?
>
> Cheers,
>
> Pedro.

Yes, there should be a plan. AFAIK we have agreed that we want to make 
as less changes as possible to make a fast release of a 3.4 possible. 
After that is done we can do bigger changes (e.g., no binfilters 
anymore). Or we can do the initial import and right after that a new branch.

So, we should have one branch for the AOO 3.4 release and the other is 
the new trunk "branch".

Marcus

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Andy Brown <an...@the-martin-byrd.net>]

Pedro Giffuni wrote:
> On Mon, 15 Aug 2011 22:27:29 +0200, Ingrid von der Mehden
> <In...@gmx-topmail.de> wrote:
>> Am 15.08.2011 21:13, schrieb Pedro F. Giffuni:
>>> --- On Mon, 8/15/11, Rob Weir<ap...@robweir.com> wrote:
>> [..]
>>>> ooo/trunk/core --- all the OOO340 stuff
>>>> ooo/trunk/l10n -- all the language stuff
>>>
>>> Please do the directory rearrangement in SVN. I have no
>>> objection to moving stuff but if it's possible to match
>>> the old history later on, having these changes out of SVN
>>> won't help.
>>>
>>
>> On 'old' OOo there are currently already two separate hg
>> repositories. No directory move within either of them was proposed.
>> Only a target directory for each repository needs to be selected. I
>> don't see how this should affect any history mapping later.
>>
>
> Ah .. It's OK then. (sorry as I'm mostly new to the codebase)
>
> Is there some development plan after the intial repo is done or
> can committers start making massive changes (merging branches,
> adding ports, etc ..) right away?
>
> Cheers,
>
> Pedro.

The first thing that has to be done is to see if we do a build to make 
sure that we received all the files.  The next step then is to see what 
can be changed to AL2 license and which files will have to be replaced 
with AL2 licensed files.  In the second step builds will have to be done 
to make sure that nothing is broken in the process.

At least that is my understanding.

Andy
(non-coder)

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Pedro Giffuni <gi...@tutopia.com>]

 On Mon, 15 Aug 2011 22:27:29 +0200, Ingrid von der Mehden 
 <In...@gmx-topmail.de> wrote:
> Am 15.08.2011 21:13, schrieb Pedro F. Giffuni:
>> --- On Mon, 8/15/11, Rob Weir<ap...@robweir.com>  wrote:
> [..]
>>> ooo/trunk/core --- all the OOO340 stuff
>>> ooo/trunk/l10n -- all the language stuff
>>
>> Please do the directory rearrangement in SVN. I have no
>> objection to moving stuff but if it's possible to match
>> the old history later on, having these changes out of SVN
>> won't help.
>>
>
> On 'old' OOo there are currently already two separate hg
> repositories. No directory move within either of them was proposed.
> Only a target directory for each repository needs to be selected. I
> don't see how this should affect any history mapping later.
>

 Ah .. It's OK then. (sorry as I'm mostly new to the codebase)

 Is there some development plan after the intial repo is done or
 can committers start making massive changes (merging branches,
 adding ports, etc ..) right away?

 Cheers,

 Pedro.

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Ingrid von der Mehden <In...@gmx-topmail.de>]

Am 15.08.2011 21:13, schrieb Pedro F. Giffuni:
> --- On Mon, 8/15/11, Rob Weir<ap...@robweir.com>  wrote:
[..]
>> ooo/trunk/core --- all the OOO340 stuff
>> ooo/trunk/l10n -- all the language stuff
>
> Please do the directory rearrangement in SVN. I have no
> objection to moving stuff but if it's possible to match
> the old history later on, having these changes out of SVN
> won't help.
>

On 'old' OOo there are currently already two separate hg repositories. 
No directory move within either of them was proposed. Only a target 
directory for each repository needs to be selected. I don't see how this 
should affect any history mapping later.

Kind regards,
Ingrid

Re: [Repo][Proposal] OOO340 SVN Dump file import

["Pedro F. Giffuni" <gi...@tutopia.com>]

Hi again;

--- On Mon, 8/15/11, Rob Weir <ap...@robweir.com> wrote:

> 
> The migration to Apache-Extras is the easy part,
> right?  It is just Hg to Hg. So we maintain the
> complete revision history that way.
>

Iff apache-extras offers sufficient space for the
repository.
Actually, I am not very worried about losing all the
history: Apache OO is rather a fresh start anyways.
  
> If someone has a more elegant solution, then, as always,
> "Patches are Welcome".
>

One thing I do suggest is to do a raw import from the Hg
tip. You wrote:

> I then moved these into a common directory structure,
> as Ingrid had earlier suggested:
>
> ooo/trunk/core --- all the OOO340 stuff
> ooo/trunk/l10n -- all the language stuff

Please do the directory rearrangement in SVN. I have no
objection to moving stuff but if it's possible to match
the old history later on, having these changes out of SVN
won't help.
 
 
> > Will we also lose the bugzilla database? :-(
> >
> 
> Why would we loose Bugzilla?
>

Because no one is working on it? Not even the test
import has been done.
 
Pedro.

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Rob Weir <ap...@robweir.com>]

On Mon, Aug 15, 2011 at 2:15 PM, Pedro F. Giffuni <gi...@tutopia.com> wrote:
>
>
> --- On Mon, 8/15/11, Rob Weir <ro...@apache.org> wrote:
> ...
>> We've been discussing for two months
>> now how to get Hg over to SVN.
>> There have been several suggestions for how the CWS's and
>> complete revision history could be migrated over, but
>> little progress has been made.  Either the proposals
>> didn't work, or no volunteers stepped forward to
>> implement them.
>>
>> The alternative proposal was to just check in the tip of
>> the trunk, without history, and then migrate Hg to
>> Apache-Extras.org, where Hg is supported.  I've made
>> some progress on this proposal.
>>
>
> I am afraid doing this will be an incomplete solution as
> no one seems to be doing the HG migration to Apache-Extras
> part. In sum, I suspect we will lose all history but
> there seems to be no alternative if we want to start
> development.
>

The migration to Apache-Extras is the easy part, right?  It is just Hg
to Hg. So we maintain the complete revision history that way.

If someone has a more elegant solution, then, as always, "Patches are
Welcome".

> Will we also lose the bugzilla database? :-(
>

Why would we loose Bugzilla?

> cheers,
>
> Pedro.
>

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Mathias Bauer <Ma...@gmx.net>]

On 15.08.2011 20:15, Pedro F. Giffuni wrote:

> 
> 
> --- On Mon, 8/15/11, Rob Weir <ro...@apache.org> wrote:
> ...
>> We've been discussing for two months
>> now how to get Hg over to SVN.
>> There have been several suggestions for how the CWS's and
>> complete revision history could be migrated over, but
>> little progress has been made.  Either the proposals
>> didn't work, or no volunteers stepped forward to
>> implement them.
>> 
>> The alternative proposal was to just check in the tip of
>> the trunk, without history, and then migrate Hg to
>> Apache-Extras.org, where Hg is supported.  I've made
>> some progress on this proposal.
>>
> 
> I am afraid doing this will be an incomplete solution as
> no one seems to be doing the HG migration to Apache-Extras
> part. In sum, I suspect we will lose all history but
> there seems to be no alternative if we want to start
> development.

This is completely unrelated. We already have the hg repos of OOo and
all cws on several computers, we "just" have to put them together into
one repo so that it fits into the size limit of 4 GB.

We can do that later.

Regards,
Mathias

Re: [Repo][Proposal] OOO340 SVN Dump file import

["Pedro F. Giffuni" <gi...@tutopia.com>]

--- On Mon, 8/15/11, Rob Weir <ro...@apache.org> wrote:
...
> We've been discussing for two months
> now how to get Hg over to SVN.
> There have been several suggestions for how the CWS's and
> complete revision history could be migrated over, but
> little progress has been made.  Either the proposals
> didn't work, or no volunteers stepped forward to
> implement them.
> 
> The alternative proposal was to just check in the tip of
> the trunk, without history, and then migrate Hg to
> Apache-Extras.org, where Hg is supported.  I've made
> some progress on this proposal.
>

I am afraid doing this will be an incomplete solution as
no one seems to be doing the HG migration to Apache-Extras
part. In sum, I suspect we will lose all history but
there seems to be no alternative if we want to start
development.

Will we also lose the bugzilla database? :-(

cheers,

Pedro.