incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Stahl <...@openoffice.org>
Subject Re: single repository status
Date Tue, 19 Jul 2011 21:26:48 GMT
On 14.07.2011 18:03, Michael Stahl wrote:
> On 09.07.2011 07:57, Greg Stein wrote:
>> Once the tags are properly marked, then we can start testing the
>> conversion to Subversion. Please note, however: the hg conversion
>> script does *not* process tags. We will have to write that. We will
>> also have to somehow manage construction of branches. We may also have
>> to update the conversion tool to properly handle the "merge"
>> changesets that Hg records.
>
> after looking at the HG convert svn_sink a little, this looks rather
> difficult to me.
>
> well, tags should be easy.
>
> but how to reconstruct the branching is kind of unclear to me.
> the first ~260k changesets are linear and were initially taken from SVN,
> so that shouldn't be a problem.
> but then there are lots of HG merge changesets.

unfortunately it seems none of the tools that convert from HG or git to 
SVN can create SVN branches with SVN mergeinfo (necessary in order to be 
able to merge the branches back into the trunk).

there are some tools to convert from git that can create SVN branches, 
but they leave out the SVN mergeinfo; apparently the intent is to 
maintain a read-only mirror...

> in the HG repo there is sort of a "master" history that is basically a
> sequence of CWS integration merge changesets, with the occasional
> masterfix thrown in.
> but this is not explicit: these are all just merges with 2 parents, and
> it's not guaranteed which of these 2 is the CWS and which the master.
> basically the requirement is to convert one of the thousands of paths
> through this DAG from the common ancestor revision ~260k to revision
> c904c1944462 (OOO340 head) into a SVN trunk.

to be more specific, the last revision from OOo SVN was the tag 
"last_svn_milestone" (263206  d0058b5891eb)
(which is not actually a common ancestor, as some CWSes are based on 
older milestones)

the following merge commits are those on the DEV300 master/"trunk" where 
i've noticed the "follow the first parent" heuristic would fail, and the 
second parent (after the arrow) should be taken instead.

90552a19cdc4 -> dae1ffc5c15d
9572400cd241 -> ce1b12199f72
c33f611c4373 -> 5d0c069f2570
13b3d2dae916 -> 62bf02dff30b
37dc1e423a1e -> 664c5f3a9291


basically we have these options for converting to SVN:

1. convert full history
    requires writing tool to create SVN branches and mergeinfo

2. convert trunk only, using follow-first-parent heuristic
    with hacks where we want to follow second parent instead

3. no history in SVN, just check in OOO340 tip

option 1. seems to be too much effort to me, and would have to be 
implemented by a real SVN wizard.

option 2. requires some effort, but should be doable; we still lose all 
CWS internal history though (e.g. CWS undoapi becomes a single 57,788 
line changeset against 562 files).

after thinking about it for a while, a trunk-only history in SVN doesn't 
seem to be all that useful to me (you need to go over the network to 
access something incomplete...).

far more useful would be to have a read-only HG/git repository available 
that contains the _full_ history and all open CWS branches, which can be 
cloned and examined off-line.

opinions?

regards,
  michael


Mime
View raw message