You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Pedro F. Giffuni" <gi...@tutopia.com> on 2011/08/09 04:05:40 UTC
[Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
Hi;
I appreciate the tough work that is being done to transfer
the Wiki, forums, etc ... but I would've thought the greatest
priority was the SVN repository.
Any reassuring comment on this? Something like "we are
working on this but the script will still require a month to
complete the conversion" is better than no news at all.
cheers,
Pedro.
--- On Mon, 8/8/11, Andrew Rist wrote:
...
>
> In the same way that the cleaning of the code and
> application of AL2 does not need to occur before anything is
> moved into Apache SVN servers, we do not need to worry about
> bringing over other content. Final resolution of
> Copyright/Licensing/Grants needs to occur before
> graduation.
>
> Andrew
>
RE: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Thanks for the clarification. That makes more sense.
My next questions are,
1. Where are the OpenOffice.org Hg repositories to be found?
2. Is anyone doing the scripted merge you speak of?
- Dennis
-----Original Message-----
From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]
Sent: Wednesday, August 10, 2011 11:10
To: ooo-dev@incubator.apache.org
Subject: Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
On 10.08.2011 19:13, Dennis E. Hamilton wrote:
> I think we agree we want a complete Hg (or git) on Apache Extras, so
> we can preserve what we can and also so we can cherry pick anything
> we find that we need to draw over to the SVN repo, to repair problems
> on the SVN, etc.
>
> Greg Stein set up one project (ooo) but nothing has been moved to it:
> <http://code.google.com/a/apache-extras.org/p/ooo/>
>
> I'm unclear what the existence of all the Child Work Spaces does to
> this - I assume we only get one Hg repo per Apache Extra Project and
> I don't understand the relationship among the multiple repos used in
> OpenOffice.org. (I've never used Git or Hg, so that is a blind spot
> for me.)
>
> [Nosing around OpenOffice.org I could find no source repositories,
> although release tarballs are stated to be available. I probably
> don't know where to look.]
>
> I'm all in favor of doing the least possible to create the Apache
> extra. "While we're at it ... " tasks tend to add too many variables
> in case there are problems and don't have a history of great
> success.
>
> Having a way to do further work at leisure is what I hope for.
>
> (I see that LibreOffice has gotten down to one, but that doesn't help
> here and I'm not sure what that means in any case.)
I think that you are confusing things here. If you are talking about the
"one git" effort from LibreOffice: for historical or other reaons
LibreOffice always had more than one repository for their code base
(IIRC even more than five), while OOo always only had one until we
separated the l10n stuff. As having more than one repository is a major
PITA for developers if you need them all for even the smalles build,
they decided to go back to one repository.
But this is only for the "trunk" (main code line).
In OOo each cws had its own repository that was created by copying the
trunk repo before new code was added to this copy as change sets. Once
the work on the cws was finished, the new change sets were pulled into
the trunk repository ("code integration") and the cws repository was
discarded after some idle time.
These cws repositories are the huge number or repos we are talking about
in the AOOo context. Moving all these repositories to one place would
eat up several hundreds of GB or - in case hard links can be used - ~80
GB. But we can do better.
As each CWS repository started as a copy of the trunk repo, it is
identical with it for more than 99% of its size, the <1% difference
being a number of change sets that make up the value of the cws. Thus
pulling all change sets from all cws into one a copy of the trunk
repository will save a huge amount of disk space, even 100 cws won't
take much more space than the single trunk repo. Such repository should
fit into the 4 GB disk space we seem to have at apache-extras.
As we want to be able to work on each of the cws later, we must be able
to identify each "tip" change set of all cws in this repo. This can be
done by keeping each cws in a separate branch or by bookmarking its tip
change set. The latter is easier to achieve by scripting, the former
probably would make it easier to work with the cws later. IIRC ease of
scripting won.
Regards,
Mathias
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki
Services web page.)
Posted by Norbert Thiebaud <nt...@gmail.com>.
On Wed, Aug 10, 2011 at 2:14 PM, Michael Stahl <ms...@openoffice.org> wrote:
> On 10.08.2011 20:10, Mathias Bauer wrote:
>>
>> On 10.08.2011 19:13, Dennis E. Hamilton wrote:
>
>>> [Nosing around OpenOffice.org I could find no source repositories,
>>> although release tarballs are stated to be available. I probably
>>> don't know where to look.]
>
> look here:
> http://hg.services.openoffice.org/
>
>>> (I see that LibreOffice has gotten down to one, but that doesn't help
>>> here and I'm not sure what that means in any case.)
>>
>> I think that you are confusing things here. If you are talking about the
>> "one git" effort from LibreOffice: for historical or other reaons
>> LibreOffice always had more than one repository for their code base
>> (IIRC even more than five), while OOo always only had one until we
>
> in my LO checkout (from before migration) i've got 18 repositories...
>
> there seems to be a script in the top-level that can run git commands across
> all repositories (guess otherwise this kind of setup would be completely
> unusable).
yes: ./g
it is a fairly simple wrapper to run the same git command on all the
repositories.
but it has still serious limitation, and the setup with split repo has
inherent pita like
making bisection extremely hard...
>
>> separated the l10n stuff. As having more than one repository is a major
>> PITA for developers if you need them all for even the smalles build,
>> they decided to go back to one repository.
>
> there still seem to be 5 repos left (but 3 of them are said to be optional:
> binfilter, dictionaries and translations).
binfilter was kept separate because it is on the chopping block...
translations was kept separate for the same reason l10n was split in OOo
dictionaries was kept separate for the same reason translations/l10n was
the last one is help. right now it is not an optional repo, but the
longer term goal is
to have the help as a separate build/package.
Norbert
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki
Services web page.)
Posted by Michael Stahl <ms...@openoffice.org>.
On 10.08.2011 20:10, Mathias Bauer wrote:
> On 10.08.2011 19:13, Dennis E. Hamilton wrote:
>> [Nosing around OpenOffice.org I could find no source repositories,
>> although release tarballs are stated to be available. I probably
>> don't know where to look.]
look here:
http://hg.services.openoffice.org/
>> (I see that LibreOffice has gotten down to one, but that doesn't help
>> here and I'm not sure what that means in any case.)
>
> I think that you are confusing things here. If you are talking about the
> "one git" effort from LibreOffice: for historical or other reaons
> LibreOffice always had more than one repository for their code base
> (IIRC even more than five), while OOo always only had one until we
in my LO checkout (from before migration) i've got 18 repositories...
there seems to be a script in the top-level that can run git commands
across all repositories (guess otherwise this kind of setup would be
completely unusable).
> separated the l10n stuff. As having more than one repository is a major
> PITA for developers if you need them all for even the smalles build,
> they decided to go back to one repository.
there still seem to be 5 repos left (but 3 of them are said to be
optional: binfilter, dictionaries and translations).
but in any case, LO uses a different model than what OOo used:
- at OOo, we used to have one repo per open feature branch (CWS);
only very recently have we actually split up the master repo by module
- at LO, all feature branches live in the same repo,
but they have always split up their code modules across several repos
> As we want to be able to work on each of the cws later, we must be able
> to identify each "tip" change set of all cws in this repo. This can be
> done by keeping each cws in a separate branch or by bookmarking its tip
> change set. The latter is easier to achieve by scripting, the former
> probably would make it easier to work with the cws later. IIRC ease of
> scripting won.
the problem with HG named branches is that they are part of the commit
metadata, so it's not possible to retroactively introduce them (without
some effort), while bookmarks are trivial to add.
otherwise, good summary :)
> Regards,
> Mathias
regards,
michael
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki
Services web page.)
Posted by Mathias Bauer <Ma...@gmx.net>.
On 10.08.2011 19:13, Dennis E. Hamilton wrote:
> I think we agree we want a complete Hg (or git) on Apache Extras, so
> we can preserve what we can and also so we can cherry pick anything
> we find that we need to draw over to the SVN repo, to repair problems
> on the SVN, etc.
>
> Greg Stein set up one project (ooo) but nothing has been moved to it:
> <http://code.google.com/a/apache-extras.org/p/ooo/>
>
> I'm unclear what the existence of all the Child Work Spaces does to
> this - I assume we only get one Hg repo per Apache Extra Project and
> I don't understand the relationship among the multiple repos used in
> OpenOffice.org. (I've never used Git or Hg, so that is a blind spot
> for me.)
>
> [Nosing around OpenOffice.org I could find no source repositories,
> although release tarballs are stated to be available. I probably
> don't know where to look.]
>
> I'm all in favor of doing the least possible to create the Apache
> extra. "While we're at it ... " tasks tend to add too many variables
> in case there are problems and don't have a history of great
> success.
>
> Having a way to do further work at leisure is what I hope for.
>
> (I see that LibreOffice has gotten down to one, but that doesn't help
> here and I'm not sure what that means in any case.)
I think that you are confusing things here. If you are talking about the
"one git" effort from LibreOffice: for historical or other reaons
LibreOffice always had more than one repository for their code base
(IIRC even more than five), while OOo always only had one until we
separated the l10n stuff. As having more than one repository is a major
PITA for developers if you need them all for even the smalles build,
they decided to go back to one repository.
But this is only for the "trunk" (main code line).
In OOo each cws had its own repository that was created by copying the
trunk repo before new code was added to this copy as change sets. Once
the work on the cws was finished, the new change sets were pulled into
the trunk repository ("code integration") and the cws repository was
discarded after some idle time.
These cws repositories are the huge number or repos we are talking about
in the AOOo context. Moving all these repositories to one place would
eat up several hundreds of GB or - in case hard links can be used - ~80
GB. But we can do better.
As each CWS repository started as a copy of the trunk repo, it is
identical with it for more than 99% of its size, the <1% difference
being a number of change sets that make up the value of the cws. Thus
pulling all change sets from all cws into one a copy of the trunk
repository will save a huge amount of disk space, even 100 cws won't
take much more space than the single trunk repo. Such repository should
fit into the 4 GB disk space we seem to have at apache-extras.
As we want to be able to work on each of the cws later, we must be able
to identify each "tip" change set of all cws in this repo. This can be
done by keeping each cws in a separate branch or by bookmarking its tip
change set. The latter is easier to achieve by scripting, the former
probably would make it easier to work with the cws later. IIRC ease of
scripting won.
Regards,
Mathias
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki
Services web page.)
Posted by Bjoern Michaelsen <bj...@canonical.com>.
Hi Rob,
On Wed, 10 Aug 2011 13:43:05 -0400
Rob Weir <ap...@robweir.com> wrote:
> At the very least, someone should download EVERYTHING in Hg and get a
> database dump or whatever other portable archive format Hg allows,
> preserving history, etc., make a tgz of that and get it seeded on
> BitTorrent.
There's an app^Wextension for that:
http://mercurial.selenic.com/wiki/BranchmirrorExtension
so I guess that has already been done by quite a few people.
Best,
Bjoern
--
https://launchpad.net/~bjoern-michaelsen
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki
Services web page.)
Posted by Bjoern Michaelsen <bj...@gmail.com>.
Hi Rob,
On Wed, 10 Aug 2011 13:43:05 -0400
Rob Weir <ap...@public.gmane.org> wrote:
> At the very least, someone should download EVERYTHING in Hg and get a
> database dump or whatever other portable archive format Hg allows,
> preserving history, etc., make a tgz of that and get it seeded on
> BitTorrent.
There's an app^Wextension for that:
http://mercurial.selenic.com/wiki/BranchmirrorExtension
so I guess that has already been done by quite a few people.
Best,
Bjoern
--
https://launchpad.net/~bjoern-michaelsen
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki
Services web page.)
Posted by Rob Weir <ap...@robweir.com>.
On Wed, Aug 10, 2011 at 1:13 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I think we agree we want a complete Hg (or git) on Apache Extras, so we can preserve what we can and also so we can cherry pick anything we find that we need to draw over to the SVN repo, to repair problems on the SVN, etc.
>
> Greg Stein set up one project (ooo) but nothing has been moved to it:
> <http://code.google.com/a/apache-extras.org/p/ooo/>
>
> I'm unclear what the existence of all the Child Work Spaces does to this - I assume we only get one Hg repo per Apache Extra Project and I don't understand the relationship among the multiple repos used in OpenOffice.org. (I've never used Git or Hg, so that is a blind spot for me.)
>
> [Nosing around OpenOffice.org I could find no source repositories, although release tarballs are stated to be available. I probably don't know where to look.]
>
> I'm all in favor of doing the least possible to create the Apache extra. "While we're at it ... " tasks tend to add too many variables in case there are problems and don't have a history of great success.
>
At the very least, someone should download EVERYTHING in Hg and get a
database dump or whatever other portable archive format Hg allows,
preserving history, etc., make a tgz of that and get it seeded on
BitTorrent.
> Having a way to do further work at leisure is what I hope for.
>
> (I see that LibreOffice has gotten down to one, but that doesn't help here and I'm not sure what that means in any case.)
>
> - Dennis
>
> -----Original Message-----
> From: Marcus (OOo) [mailto:marcus.mail@wtnet.de]
> Sent: Wednesday, August 10, 2011 09:42
> To: ooo-dev@incubator.apache.org
> Subject: Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
>
> Am 08/10/2011 06:21 PM, schrieb Pedro Giffuni:
>> On Wed, 10 Aug 2011 09:01:42 -0700, "Dennis E. Hamilton"
>> <de...@acm.org> wrote:
>>> "b) to keep the complete OOo HG repo in apache-extras to
>>> > keep the CWS developments but also to keep the repo
>>> > history for reference.
>>> >
>>>
>>> "This is correct and is done already."
>>>
>>> Where? I see that there is an ooo project there, but I see no code.
>>>
>>
>>
>> Hmm ... I thought either Marcus or Rob had done it , but I guess I
>> was wrong, so we are where we started.
>>
>> Pedro.
>
> No, my knowlegde about SVN, HG and Co. is far away from being good
> enough to do such things. ;-)
>
> But someone has written that it's on apache-extras or at least should be
> moved there, isn't it?
>
> Marcus
>
>
RE: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I think we agree we want a complete Hg (or git) on Apache Extras, so we can preserve what we can and also so we can cherry pick anything we find that we need to draw over to the SVN repo, to repair problems on the SVN, etc.
Greg Stein set up one project (ooo) but nothing has been moved to it:
<http://code.google.com/a/apache-extras.org/p/ooo/>
I'm unclear what the existence of all the Child Work Spaces does to this - I assume we only get one Hg repo per Apache Extra Project and I don't understand the relationship among the multiple repos used in OpenOffice.org. (I've never used Git or Hg, so that is a blind spot for me.)
[Nosing around OpenOffice.org I could find no source repositories, although release tarballs are stated to be available. I probably don't know where to look.]
I'm all in favor of doing the least possible to create the Apache extra. "While we're at it ... " tasks tend to add too many variables in case there are problems and don't have a history of great success.
Having a way to do further work at leisure is what I hope for.
(I see that LibreOffice has gotten down to one, but that doesn't help here and I'm not sure what that means in any case.)
- Dennis
-----Original Message-----
From: Marcus (OOo) [mailto:marcus.mail@wtnet.de]
Sent: Wednesday, August 10, 2011 09:42
To: ooo-dev@incubator.apache.org
Subject: Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
Am 08/10/2011 06:21 PM, schrieb Pedro Giffuni:
> On Wed, 10 Aug 2011 09:01:42 -0700, "Dennis E. Hamilton"
> <de...@acm.org> wrote:
>> "b) to keep the complete OOo HG repo in apache-extras to
>> > keep the CWS developments but also to keep the repo
>> > history for reference.
>> >
>>
>> "This is correct and is done already."
>>
>> Where? I see that there is an ooo project there, but I see no code.
>>
>
>
> Hmm ... I thought either Marcus or Rob had done it , but I guess I
> was wrong, so we are where we started.
>
> Pedro.
No, my knowlegde about SVN, HG and Co. is far away from being good
enough to do such things. ;-)
But someone has written that it's on apache-extras or at least should be
moved there, isn't it?
Marcus
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki
Services web page.)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/10/2011 06:21 PM, schrieb Pedro Giffuni:
> On Wed, 10 Aug 2011 09:01:42 -0700, "Dennis E. Hamilton"
> <de...@acm.org> wrote:
>> "b) to keep the complete OOo HG repo in apache-extras to
>> > keep the CWS developments but also to keep the repo
>> > history for reference.
>> >
>>
>> "This is correct and is done already."
>>
>> Where? I see that there is an ooo project there, but I see no code.
>>
>
>
> Hmm ... I thought either Marcus or Rob had done it , but I guess I
> was wrong, so we are where we started.
>
> Pedro.
No, my knowlegde about SVN, HG and Co. is far away from being good
enough to do such things. ;-)
But someone has written that it's on apache-extras or at least should be
moved there, isn't it?
Marcus
RE: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
Posted by Pedro Giffuni <gi...@tutopia.com>.
On Wed, 10 Aug 2011 09:01:42 -0700, "Dennis E. Hamilton"
<de...@acm.org> wrote:
> "b) to keep the complete OOo HG repo in apache-extras to
> > keep the CWS developments but also to keep the repo
> > history for reference.
> >
>
> "This is correct and is done already."
>
> Where? I see that there is an ooo project there, but I see no code.
>
Hmm ... I thought either Marcus or Rob had done it , but I guess I
was wrong, so we are where we started.
Pedro.
RE: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
"b) to keep the complete OOo HG repo in apache-extras to
> keep the CWS developments but also to keep the repo
> history for reference.
>
"This is correct and is done already."
Where? I see that there is an ooo project there, but I see no code.
-----Original Message-----
From: Pedro F. Giffuni [mailto:giffunip@tutopia.com]
Sent: Wednesday, August 10, 2011 08:27
To: ooo-dev@incubator.apache.org
Subject: Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
--- On Wed, 8/10/11, Marcus (OOo) <ma...@wtnet.de> wrote:
...
> >
> > Let me try to recap the consensus so far. I was on
> vaction for two
> > weeks, so I was not involved in all discussions.
> >
> > A full conversion hg -> svn for the trunk
> repo and all cws is considered
> > to be impossible, so all conversions will happen on
> the trunk repo only.
> >
> > It was mentioned that preserving history looks hard,
> so most of us
> > agreed to move over the tip from the trunk repo into
> svn only, without
> > history.
>
> I had the impression that we agreed on
>
> a) moving the OOO340m1 tip into ASF SVN and to loose
> history, so that we can start with further improvements
> very fast and
>
Lose ALL history? I was under the impression we wanted to
keep at least keep the trunk history in SVN.
> b) to keep the complete OOo HG repo in apache-extras to
> keep the CWS developments but also to keep the repo
> history for reference.
>
This is correct and is done already.
> So, at the end there is indeed a way to keep every data +
> history but also to start with new developments in ASF
> SVN.
>
I suggest that we do the CWS merge (only branch merging, no
new code) in apache-extras. Doing it there is better than just
committing a big patch in subversion and this gives a bit more
time for the SVN conversion (if it's going on).
Pedro.
RE: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I believe one speed-bump that has been raised is the maximum storage available to an Apache Extra. I'm not sure anyone has taken an action to find out if we can have an exception from Google Code. (The Terms of Use don't specify a maximum, so I don't know where that came from.)
It does look like consensus is to do the division between SVN and Hg in this manner though.
- Dennis
-----Original Message-----
From: Marcus (OOo) [mailto:marcus.mail@wtnet.de]
Sent: Wednesday, August 10, 2011 05:09
To: ooo-dev@incubator.apache.org
Subject: Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
Am 08/10/2011 01:45 PM, schrieb Mathias Bauer:
> On 09.08.2011 04:05, Pedro F. Giffuni wrote:
>
>> Hi;
>>
>> I appreciate the tough work that is being done to transfer
>> the Wiki, forums, etc ... but I would've thought the greatest
>> priority was the SVN repository.
>>
>> Any reassuring comment on this? Something like "we are
>> working on this but the script will still require a month to
>> complete the conversion" is better than no news at all.
>
> Let me try to recap the consensus so far. I was on vaction for two
> weeks, so I was not involved in all discussions.
>
> A full conversion hg -> svn for the trunk repo and all cws is considered
> to be impossible, so all conversions will happen on the trunk repo only.
>
> It was mentioned that preserving history looks hard, so most of us
> agreed to move over the tip from the trunk repo into svn only, without
> history.
I had the impression that we agreed on
a) moving the OOO340m1 tip into ASF SVN and to loose history, so that we
can start with further improvements very fast and
b) to keep the complete OOo HG repo in apache-extras to keep the CWS
developments but also to keep the repo history for reference.
So, at the end there is indeed a way to keep every data + history but
also to start with new developments in ASF SVN.
Marcus
> Then Christian Lohmaier tried to use hg convert to convert the whole
> trunk repo and for me it seemed that this was quite promising,
> especially as it seemed that the process could be accelerated by
> importing the very old stuff from the still existing OOo svn repo. Did
> someone give that a try and should we do it?
>
> In case we decided not to try that, is someone already working on
> importing the OOO340m1 repo tip?
>
> We agreed that for the time being we will move all cws into one hg repo
> based on the trunk repo, either as branches or as bookmarks (IIRC it was
> the latter we agreed on). This combined repo should be transferred to
> apache-extras and hosted there for further treatment.
>
> Sooner or later each cws will be either integrated into the main code
> line of it will be discarded in case we don't consider it worth an
> integration. I maintain my proposal to treat each cws in the following way:
>
> - review its content
> - rebase it to the tip of the trunk repo (OOO340m1)
> - create a list of change sets that are not in OOO340m1
> - convert each changeset into a patch
> - create an svn branch from the svn tag corresponding to OOO340m1
> - apply all patches one after another
> - merge with svn tip
>
> In case the cws contains merge commits, we can avoid them by re-applying
> all other patches to a OOO340m1 code line, adjusting the code in case
> the patch does not apply correctly and create new patches (very much the
> same way as you would do with mq-patches). But of course we could also
> investigate other ways to edit the hg history so that it won't contain
> merge change sets at the end.
>
> As each cws will need a review and some more testing anyway, the
> suggested patch treatment shouldn't create too much additional effort,
> except in pathologic cases.
>
> Regards,
> Mathias
RE: [Repo] SVN ETA? - directory layout
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Ingrid von der Mehden [mailto:IngridvdM@gmx-topmail.de]
> Sent: Friday, 12 August 2011 2:09 AM
> To: ooo-dev@incubator.apache.org
> Subject: Re: [Repo] SVN ETA? - directory layout
>
> Am 11.08.2011 01:28, schrieb Gavin McDonald:
> >> From: Rob Weir [mailto:apache@robweir.com]
> [...]
> >> 1) In SVN, since we have single repository, how specifically are we
> >> handling the core versus the languages? I thought the proposal was
> >> to put them in separate directories within the same repo. But we should
> be explicit.
> >
> > If the languages were separate repos, perhaps a layout suggestion
> > initially would
> > be:
> >
> > ../incubator/openofficeorg/core/[trunk|branches|tags]
> > ../incubator/openofficeorg/I10n/[trunk|branches|tags]
> > etc..
> >
> > or
> >
> > ../incubator/openofficeorg/trunk/core/..
> > ../incubator/openofficeorg/trunk/I10N/..
> >
>
> It should be L10N (for localization) not I10N.
>
> I prefer the second suggestion or similar. Please have a look at this proposal
> from last Saturday regarding this aspect:
> http://mail-archives.apache.org/mod_mbox/incubator-ooo-
> dev/201108.mbox/%3C4E3D07B7.8080101@gmx-topmail.de%3E
Yes that would work too.
It is important to decide this so that whomever ends up creating a dump
file for infra needs to do so with the agreed layout.
Gav...
>
> Kind regards,
> Ingrid
>
> [...]
Re: [Repo] SVN ETA? - directory layout
Posted by Ingrid von der Mehden <In...@gmx-topmail.de>.
Am 11.08.2011 18:34, schrieb Eike Rathke:
> Hi,
>
> On Thursday, 2011-08-11 18:09:03 +0200, Ingrid von der Mehden wrote:
>
>>> ../incubator/openofficeorg/trunk/core/..
>>> ../incubator/openofficeorg/trunk/I10N/..
>>
>> It should be L10N (for localization) not I10N.
>
> Actually it should be lower case l10n ...
Yes right. :-)
Ingrid
>
> Eike
>
Re: [Repo] SVN ETA? - directory layout
Posted by Eike Rathke <oo...@erack.de>.
Hi,
On Thursday, 2011-08-11 18:09:03 +0200, Ingrid von der Mehden wrote:
> >../incubator/openofficeorg/trunk/core/..
> >../incubator/openofficeorg/trunk/I10N/..
>
> It should be L10N (for localization) not I10N.
Actually it should be lower case l10n ...
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] SVN ETA? - directory layout
Posted by Ingrid von der Mehden <In...@gmx-topmail.de>.
Am 11.08.2011 01:28, schrieb Gavin McDonald:
>> From: Rob Weir [mailto:apache@robweir.com]
[...]
>> 1) In SVN, since we have single repository, how specifically are we handling
>> the core versus the languages? I thought the proposal was to put them in
>> separate directories within the same repo. But we should be explicit.
>
> If the languages were separate repos, perhaps a layout suggestion initially would
> be:
>
> ../incubator/openofficeorg/core/[trunk|branches|tags]
> ../incubator/openofficeorg/I10n/[trunk|branches|tags]
> etc..
>
> or
>
> ../incubator/openofficeorg/trunk/core/..
> ../incubator/openofficeorg/trunk/I10N/..
>
It should be L10N (for localization) not I10N.
I prefer the second suggestion or similar. Please have a look at this
proposal from last Saturday regarding this aspect:
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3C4E3D07B7.8080101@gmx-topmail.de%3E
Kind regards,
Ingrid
[...]
RE: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Rob Weir [mailto:apache@robweir.com]
> Sent: Thursday, 11 August 2011 12:19 AM
> To: ooo-dev@incubator.apache.org
> Subject: Re: [Repo] SVN ETA? (was Re: Request for comments: Community
> Wiki Services web page.)
>
<snip>
>
> The additional details would deal with things like:
>
> 1) In SVN, since we have single repository, how specifically are we handling
> the core versus the languages? I thought the proposal was to put them in
> separate directories within the same repo. But we should be explicit.
If the languages were separate repos, perhaps a layout suggestion initially would
be:
../incubator/openofficeorg/core/[trunk|branches|tags]
../incubator/openofficeorg/I10n/[trunk|branches|tags]
etc..
or
../incubator/openofficeorg/trunk/core/..
../incubator/openofficeorg/trunk/I10N/..
>
> 2) We want to avoid sending out gigabytes of commit notifications when we
> check in the tip. So the plan should include how we're going to avoid that.
> One idea would be to make a local working copy, commit that to a local SVN,
> get a svnadmin dump of that repository, stick it on the web someplace
> where Apache Infra can get to it, then open a JIRA ticket for them to import
> the dump.
I would say Infra should absolutely perform the initial import using a dump file.
Apart from the GB of commit notifications you'd likely screw the repo for everyone
else for hours on end until the initial commits were done. No, infra loading a dump
is the only way.
Gav...
>
> 3) The legacy history should be easier, since that is Hg -->Hg on Apache-
> extras.
>
> 4) We need names of volunteers for each of the above tasks
>
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki
Services web page.)
Posted by Rob Weir <ap...@robweir.com>.
On Wed, Aug 10, 2011 at 8:08 AM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 08/10/2011 01:45 PM, schrieb Mathias Bauer:
>>
>> On 09.08.2011 04:05, Pedro F. Giffuni wrote:
>>
>>> Hi;
>>>
>>> I appreciate the tough work that is being done to transfer
>>> the Wiki, forums, etc ... but I would've thought the greatest
>>> priority was the SVN repository.
>>>
>>> Any reassuring comment on this? Something like "we are
>>> working on this but the script will still require a month to
>>> complete the conversion" is better than no news at all.
>>
>> Let me try to recap the consensus so far. I was on vaction for two
>> weeks, so I was not involved in all discussions.
>>
>> A full conversion hg -> svn for the trunk repo and all cws is considered
>> to be impossible, so all conversions will happen on the trunk repo only.
>>
>> It was mentioned that preserving history looks hard, so most of us
>> agreed to move over the tip from the trunk repo into svn only, without
>> history.
>
> I had the impression that we agreed on
>
> a) moving the OOO340m1 tip into ASF SVN and to loose history, so that we can
> start with further improvements very fast and
>
> b) to keep the complete OOo HG repo in apache-extras to keep the CWS
> developments but also to keep the repo history for reference.
>
> So, at the end there is indeed a way to keep every data + history but also
> to start with new developments in ASF SVN.
>
That is the outline of what I understood as well. I think we just
need to write up the plan in some more detail, post it to the list (or
a link to a proposal on the wiki) in a [PROPOSAL] thread and state
that we're assuming lazy consensus, and we'll go ahead if there are no
objections in 3 days.
The additional details would deal with things like:
1) In SVN, since we have single repository, how specifically are we
handling the core versus the languages? I thought the proposal was to
put them in separate directories within the same repo. But we should
be explicit.
2) We want to avoid sending out gigabytes of commit notifications when
we check in the tip. So the plan should include how we're going to
avoid that. One idea would be to make a local working copy, commit
that to a local SVN, get a svnadmin dump of that repository, stick it
on the web someplace where Apache Infra can get to it, then open a
JIRA ticket for them to import the dump.
3) The legacy history should be easier, since that is Hg -->Hg on Apache-extras.
4) We need names of volunteers for each of the above tasks
> Marcus
>
>> Then Christian Lohmaier tried to use hg convert to convert the whole
>> trunk repo and for me it seemed that this was quite promising,
>> especially as it seemed that the process could be accelerated by
>> importing the very old stuff from the still existing OOo svn repo. Did
>> someone give that a try and should we do it?
>>
>> In case we decided not to try that, is someone already working on
>> importing the OOO340m1 repo tip?
>>
>> We agreed that for the time being we will move all cws into one hg repo
>> based on the trunk repo, either as branches or as bookmarks (IIRC it was
>> the latter we agreed on). This combined repo should be transferred to
>> apache-extras and hosted there for further treatment.
>>
>> Sooner or later each cws will be either integrated into the main code
>> line of it will be discarded in case we don't consider it worth an
>> integration. I maintain my proposal to treat each cws in the following
>> way:
>>
>> - review its content
>> - rebase it to the tip of the trunk repo (OOO340m1)
>> - create a list of change sets that are not in OOO340m1
>> - convert each changeset into a patch
>> - create an svn branch from the svn tag corresponding to OOO340m1
>> - apply all patches one after another
>> - merge with svn tip
>>
>> In case the cws contains merge commits, we can avoid them by re-applying
>> all other patches to a OOO340m1 code line, adjusting the code in case
>> the patch does not apply correctly and create new patches (very much the
>> same way as you would do with mq-patches). But of course we could also
>> investigate other ways to edit the hg history so that it won't contain
>> merge change sets at the end.
>>
>> As each cws will need a review and some more testing anyway, the
>> suggested patch treatment shouldn't create too much additional effort,
>> except in pathologic cases.
>>
>> Regards,
>> Mathias
>
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki
Services web page.)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/10/2011 05:26 PM, schrieb Pedro F. Giffuni:
>
>
> --- On Wed, 8/10/11, Marcus (OOo)<ma...@wtnet.de> wrote:
> ...
>>>
>>> Let me try to recap the consensus so far. I was on
>> vaction for two
>>> weeks, so I was not involved in all discussions.
>>>
>>> A full conversion hg -> svn for the trunk
>> repo and all cws is considered
>>> to be impossible, so all conversions will happen on
>> the trunk repo only.
>>>
>>> It was mentioned that preserving history looks hard,
>> so most of us
>>> agreed to move over the tip from the trunk repo into
>> svn only, without
>>> history.
>>
>> I had the impression that we agreed on
>>
>> a) moving the OOO340m1 tip into ASF SVN and to loose
>> history, so that we can start with further improvements
>> very fast and
>>
>
> Lose ALL history? I was under the impression we wanted to
> keep at least keep the trunk history in SVN.
No, AFAIU it's not possible to keep the history when migrate from HG
back to SVN; even not for the trunk.
However, maybe Christian Lohmaier has found now a possible way.
Marcus
>> b) to keep the complete OOo HG repo in apache-extras to
>> keep the CWS developments but also to keep the repo
>> history for reference.
>>
>
> This is correct and is done already.
>
>> So, at the end there is indeed a way to keep every data +
>> history but also to start with new developments in ASF
>> SVN.
>>
>
> I suggest that we do the CWS merge (only branch merging, no
> new code) in apache-extras. Doing it there is better than just
> committing a big patch in subversion and this gives a bit more
> time for the SVN conversion (if it's going on).
>
> Pedro.
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
--- On Wed, 8/10/11, Marcus (OOo) <ma...@wtnet.de> wrote:
...
> >
> > Let me try to recap the consensus so far. I was on
> vaction for two
> > weeks, so I was not involved in all discussions.
> >
> > A full conversion hg -> svn for the trunk
> repo and all cws is considered
> > to be impossible, so all conversions will happen on
> the trunk repo only.
> >
> > It was mentioned that preserving history looks hard,
> so most of us
> > agreed to move over the tip from the trunk repo into
> svn only, without
> > history.
>
> I had the impression that we agreed on
>
> a) moving the OOO340m1 tip into ASF SVN and to loose
> history, so that we can start with further improvements
> very fast and
>
Lose ALL history? I was under the impression we wanted to
keep at least keep the trunk history in SVN.
> b) to keep the complete OOo HG repo in apache-extras to
> keep the CWS developments but also to keep the repo
> history for reference.
>
This is correct and is done already.
> So, at the end there is indeed a way to keep every data +
> history but also to start with new developments in ASF
> SVN.
>
I suggest that we do the CWS merge (only branch merging, no
new code) in apache-extras. Doing it there is better than just
committing a big patch in subversion and this gives a bit more
time for the SVN conversion (if it's going on).
Pedro.
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki
Services web page.)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/10/2011 01:45 PM, schrieb Mathias Bauer:
> On 09.08.2011 04:05, Pedro F. Giffuni wrote:
>
>> Hi;
>>
>> I appreciate the tough work that is being done to transfer
>> the Wiki, forums, etc ... but I would've thought the greatest
>> priority was the SVN repository.
>>
>> Any reassuring comment on this? Something like "we are
>> working on this but the script will still require a month to
>> complete the conversion" is better than no news at all.
>
> Let me try to recap the consensus so far. I was on vaction for two
> weeks, so I was not involved in all discussions.
>
> A full conversion hg -> svn for the trunk repo and all cws is considered
> to be impossible, so all conversions will happen on the trunk repo only.
>
> It was mentioned that preserving history looks hard, so most of us
> agreed to move over the tip from the trunk repo into svn only, without
> history.
I had the impression that we agreed on
a) moving the OOO340m1 tip into ASF SVN and to loose history, so that we
can start with further improvements very fast and
b) to keep the complete OOo HG repo in apache-extras to keep the CWS
developments but also to keep the repo history for reference.
So, at the end there is indeed a way to keep every data + history but
also to start with new developments in ASF SVN.
Marcus
> Then Christian Lohmaier tried to use hg convert to convert the whole
> trunk repo and for me it seemed that this was quite promising,
> especially as it seemed that the process could be accelerated by
> importing the very old stuff from the still existing OOo svn repo. Did
> someone give that a try and should we do it?
>
> In case we decided not to try that, is someone already working on
> importing the OOO340m1 repo tip?
>
> We agreed that for the time being we will move all cws into one hg repo
> based on the trunk repo, either as branches or as bookmarks (IIRC it was
> the latter we agreed on). This combined repo should be transferred to
> apache-extras and hosted there for further treatment.
>
> Sooner or later each cws will be either integrated into the main code
> line of it will be discarded in case we don't consider it worth an
> integration. I maintain my proposal to treat each cws in the following way:
>
> - review its content
> - rebase it to the tip of the trunk repo (OOO340m1)
> - create a list of change sets that are not in OOO340m1
> - convert each changeset into a patch
> - create an svn branch from the svn tag corresponding to OOO340m1
> - apply all patches one after another
> - merge with svn tip
>
> In case the cws contains merge commits, we can avoid them by re-applying
> all other patches to a OOO340m1 code line, adjusting the code in case
> the patch does not apply correctly and create new patches (very much the
> same way as you would do with mq-patches). But of course we could also
> investigate other ways to edit the hg history so that it won't contain
> merge change sets at the end.
>
> As each cws will need a review and some more testing anyway, the
> suggested patch treatment shouldn't create too much additional effort,
> except in pathologic cases.
>
> Regards,
> Mathias
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki
Services web page.)
Posted by Mathias Bauer <Ma...@gmx.net>.
Hi Christian,
On 10.08.2011 16:23, Christian Lohmaier wrote:
> Hi *,
>
> On Wed, Aug 10, 2011 at 1:45 PM, Mathias Bauer <Ma...@gmx.net> wrote:
>> On 09.08.2011 04:05, Pedro F. Giffuni wrote:
>> [...]
>>
>> Then Christian Lohmaier tried to use hg convert to convert the whole
>> trunk repo and for me it seemed that this was quite promising,
>> especially as it seemed that the process could be accelerated by
>> importing the very old stuff from the still existing OOo svn repo. Did
>> someone give that a try and should we do it?
>
> Yes, indeed it is - you can import the first 263000 revisions that
> way, saving weeks of conversion.
>
> svndumpfilter is too dumb to just set a filter to only include trunk,
> as files created in a cws will break the import, thus you need to also
> include the files added in the cws.
> However svndumpfilter is again too stupid to also preserve the target
> directories, thus you have to create those initially. revision 1 of
> the origial repo only creates the trunk dir, so replace that commit
> with one that also creates the target directories for the cws-created
> ones.
>
> So conversion would be as follows:
> $ svnadmin create /tmp/targetrepo
> $ svn mkdir -m'create dirs that svndumpfilter is too stupid to
> preserve' --parents file:///tmp/targetrepo/cws/appleremote01
> file:///tmp/targetrepo/cws/aw057/drawinglayer/inc/drawinglayer/primitive3d
> [...]
> # then import the dump, moving /trunk to /
> $ svnadmin dump -r 2:277182 --incremental /tmp/svnsyncmirror |
> svndumpfilter --skip-missing-merge-sources trunk
> cws/hr43/solenv/bin/cws cws/hr43/solenv/bin/cws.btm
> cws/hr43/solenv/bin/cws.pl [...other files added on the cws...] | sed
> -e 's#^Node\(-copyfrom\)\{0,1\}-path: trunk/#Node\1-path: #' |
> svnadmin load /tmp/targetrepo
>
> Then create the checkout, run the map-revisions script, copy the
> generated mapping file to /tmp/targetrepo-wc/.svn/hg-shamap, run hg
> convert -s hg -d svn /tmp/hgrepo/ /tmp/targetrepo
>
> If you got the disspace available for doing a full checkout of the
> original svn repo, you don't restrict yourself in preserving trunk
> (and the files created on the cws) only, just moving /trunk to / would
> be enough in this case. But a full checkout is *huge*, and I don't
> have 1TB anywhere....
>
> The dump is limited to revision 277182 as that is the last svn
> revision that matches one in the hg repo (corresponds to mercurial
> revision 263205)
Thanks, seems that you have looked into that quite deeply.
The interesting question is if putting the converted stuff from hg
"trunk" on top of that svn repo will work or if we can't get a
conversion of the hg repo with bearable effort anyway - in that case
importing (checking in) just the tip repo is all we can do now anyway
and so the old svn repo wouldn't be of interest.
>From the various mails on the list I didn't get a final picture. I
thought a conversion hg->svn fails even for "trunk only" as merge
commits are not handled properly, but your mails seemed to indicate that
you have another opinion about that.
Regards,
Mathias
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki
Services web page.)
Posted by Christian Lohmaier <cl...@openoffice.org>.
Hi *,
On Wed, Aug 10, 2011 at 1:45 PM, Mathias Bauer <Ma...@gmx.net> wrote:
> On 09.08.2011 04:05, Pedro F. Giffuni wrote:
> [...]
>
> Then Christian Lohmaier tried to use hg convert to convert the whole
> trunk repo and for me it seemed that this was quite promising,
> especially as it seemed that the process could be accelerated by
> importing the very old stuff from the still existing OOo svn repo. Did
> someone give that a try and should we do it?
Yes, indeed it is - you can import the first 263000 revisions that
way, saving weeks of conversion.
svndumpfilter is too dumb to just set a filter to only include trunk,
as files created in a cws will break the import, thus you need to also
include the files added in the cws.
However svndumpfilter is again too stupid to also preserve the target
directories, thus you have to create those initially. revision 1 of
the origial repo only creates the trunk dir, so replace that commit
with one that also creates the target directories for the cws-created
ones.
So conversion would be as follows:
$ svnadmin create /tmp/targetrepo
$ svn mkdir -m'create dirs that svndumpfilter is too stupid to
preserve' --parents file:///tmp/targetrepo/cws/appleremote01
file:///tmp/targetrepo/cws/aw057/drawinglayer/inc/drawinglayer/primitive3d
[...]
# then import the dump, moving /trunk to /
$ svnadmin dump -r 2:277182 --incremental /tmp/svnsyncmirror |
svndumpfilter --skip-missing-merge-sources trunk
cws/hr43/solenv/bin/cws cws/hr43/solenv/bin/cws.btm
cws/hr43/solenv/bin/cws.pl [...other files added on the cws...] | sed
-e 's#^Node\(-copyfrom\)\{0,1\}-path: trunk/#Node\1-path: #' |
svnadmin load /tmp/targetrepo
Then create the checkout, run the map-revisions script, copy the
generated mapping file to /tmp/targetrepo-wc/.svn/hg-shamap, run hg
convert -s hg -d svn /tmp/hgrepo/ /tmp/targetrepo
If you got the disspace available for doing a full checkout of the
original svn repo, you don't restrict yourself in preserving trunk
(and the files created on the cws) only, just moving /trunk to / would
be enough in this case. But a full checkout is *huge*, and I don't
have 1TB anywhere....
The dump is limited to revision 277182 as that is the last svn
revision that matches one in the hg repo (corresponds to mercurial
revision 263205)
ciao
Christian
Re: [Repo] SVN ETA?
Posted by Mathias Bauer <Ma...@gmx.net>.
On 10.08.2011 19:29, Eike Rathke wrote:
> Hi Mathias,
>
> On Wednesday, 2011-08-10 13:45:43 +0200, Mathias Bauer wrote:
>
>> Sooner or later each cws will be either integrated into the main code
>> line of it will be discarded in case we don't consider it worth an
>> integration. I maintain my proposal to treat each cws in the following way:
>>
>> - review its content
>> - rebase it to the tip of the trunk repo (OOO340m1)
>> - create a list of change sets that are not in OOO340m1
>> - convert each changeset into a patch
>> - create an svn branch from the svn tag corresponding to OOO340m1
>> - apply all patches one after another
>> - merge with svn tip
>>
>> In case the cws contains merge commits, we can avoid them by re-applying
>> all other patches to a OOO340m1 code line, adjusting the code in case
>> the patch does not apply correctly and create new patches (very much the
>> same way as you would do with mq-patches).
>
> I don't know if there's anything like SVN queue or something to ease the
> patch set handling. In case there isn't I'd recommend to work with git
> svn (I would recommend that anyway for everything ;-) on trunk, and on
> the local git repo use stgit with imported patches from each cws.
>
> Workflow for each cws:
> * convert each changeset not in OOO340m1 into a patch and feed it to stg
> import, massage until applies cleanly
> * when all patches are in stgit, do stg commit --all
> * git svn rebase, solve merge conflicts
> * git svn dcommit
> * continue with next cws
>
> The advantages I see in this approach over the pure svn handling:
> * everything happens locally until a rebase or the final dcommit (work
> from everywhere ;-)
> * no intermediate branches needed, smaller resulting svn repo
> * work can be distributed among several people, each one cws, each
> working on the then current tip instead of OOO340m1
> * rebases and merge conflicts can be solved early against tip while
> still working on a cws if one knows a cws touches the same area of
> code as an already integrated one:
> * stg pop --all
> * git svn rebase
> * stg push --all
> (this usually is done with
> git update remote; stg rebase remotes/origin/master
> it may work with
> git svn fetch; stg rebase remotes/git-svn/master
> as well, to be tried)
Sounds interesting, but it's too much to digest for the moment. :-)
Fortunately we have time to think about that or even try it out, getting
the trunk repo to Apache is more urgent.
If noone thinks that hg convert can cope with merge change sets, we know
that only the OOO340m1 tip can be imported as a first step.
Regards,
Mathias
Re: [Repo] SVN ETA?
Posted by Eike Rathke <oo...@erack.de>.
Hi Mathias,
On Wednesday, 2011-08-10 13:45:43 +0200, Mathias Bauer wrote:
> Sooner or later each cws will be either integrated into the main code
> line of it will be discarded in case we don't consider it worth an
> integration. I maintain my proposal to treat each cws in the following way:
>
> - review its content
> - rebase it to the tip of the trunk repo (OOO340m1)
> - create a list of change sets that are not in OOO340m1
> - convert each changeset into a patch
> - create an svn branch from the svn tag corresponding to OOO340m1
> - apply all patches one after another
> - merge with svn tip
>
> In case the cws contains merge commits, we can avoid them by re-applying
> all other patches to a OOO340m1 code line, adjusting the code in case
> the patch does not apply correctly and create new patches (very much the
> same way as you would do with mq-patches).
I don't know if there's anything like SVN queue or something to ease the
patch set handling. In case there isn't I'd recommend to work with git
svn (I would recommend that anyway for everything ;-) on trunk, and on
the local git repo use stgit with imported patches from each cws.
Workflow for each cws:
* convert each changeset not in OOO340m1 into a patch and feed it to stg
import, massage until applies cleanly
* when all patches are in stgit, do stg commit --all
* git svn rebase, solve merge conflicts
* git svn dcommit
* continue with next cws
The advantages I see in this approach over the pure svn handling:
* everything happens locally until a rebase or the final dcommit (work
from everywhere ;-)
* no intermediate branches needed, smaller resulting svn repo
* work can be distributed among several people, each one cws, each
working on the then current tip instead of OOO340m1
* rebases and merge conflicts can be solved early against tip while
still working on a cws if one knows a cws touches the same area of
code as an already integrated one:
* stg pop --all
* git svn rebase
* stg push --all
(this usually is done with
git update remote; stg rebase remotes/origin/master
it may work with
git svn fetch; stg rebase remotes/git-svn/master
as well, to be tried)
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] SVN ETA? (was Re: Request for comments: Community Wiki
Services web page.)
Posted by Mathias Bauer <Ma...@gmx.net>.
On 09.08.2011 04:05, Pedro F. Giffuni wrote:
> Hi;
>
> I appreciate the tough work that is being done to transfer
> the Wiki, forums, etc ... but I would've thought the greatest
> priority was the SVN repository.
>
> Any reassuring comment on this? Something like "we are
> working on this but the script will still require a month to
> complete the conversion" is better than no news at all.
Let me try to recap the consensus so far. I was on vaction for two
weeks, so I was not involved in all discussions.
A full conversion hg -> svn for the trunk repo and all cws is considered
to be impossible, so all conversions will happen on the trunk repo only.
It was mentioned that preserving history looks hard, so most of us
agreed to move over the tip from the trunk repo into svn only, without
history.
Then Christian Lohmaier tried to use hg convert to convert the whole
trunk repo and for me it seemed that this was quite promising,
especially as it seemed that the process could be accelerated by
importing the very old stuff from the still existing OOo svn repo. Did
someone give that a try and should we do it?
In case we decided not to try that, is someone already working on
importing the OOO340m1 repo tip?
We agreed that for the time being we will move all cws into one hg repo
based on the trunk repo, either as branches or as bookmarks (IIRC it was
the latter we agreed on). This combined repo should be transferred to
apache-extras and hosted there for further treatment.
Sooner or later each cws will be either integrated into the main code
line of it will be discarded in case we don't consider it worth an
integration. I maintain my proposal to treat each cws in the following way:
- review its content
- rebase it to the tip of the trunk repo (OOO340m1)
- create a list of change sets that are not in OOO340m1
- convert each changeset into a patch
- create an svn branch from the svn tag corresponding to OOO340m1
- apply all patches one after another
- merge with svn tip
In case the cws contains merge commits, we can avoid them by re-applying
all other patches to a OOO340m1 code line, adjusting the code in case
the patch does not apply correctly and create new patches (very much the
same way as you would do with mq-patches). But of course we could also
investigate other ways to edit the hg history so that it won't contain
merge change sets at the end.
As each cws will need a review and some more testing anyway, the
suggested patch treatment shouldn't create too much additional effort,
except in pathologic cases.
Regards,
Mathias