incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BRM <bm_witn...@yahoo.com>
Subject Re: single repository status
Date Tue, 19 Jul 2011 21:52:01 GMT
----- Original Message ----

> From: Michael Stahl <mst@openoffice.org>
> 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?
> 

I at least lurk on the SVN and TSVN lists where similar kinds of questions come 
up on occasion as people convert to/from SVN.

#1 is probably simpler than one may think as it could be a basic shell script 
that simply iterates over every revision in HG and makes the equivalent commit 
to SVN.
People have used that approach to convert CVS repositories to SVN where the 
conversion was not very simple. This method does maintain all the merge info for 
branching.
For comparisons sake, cvs2svn extracts the data from the CVS/RCS repository and 
builds an SVN Dump File with the equivalent data, which I doubt contains the 
merge info, to be loaded into SVN.
Both processes are rather time-consuming.

If this was desired, then I would suggest whoever spearheads this talk with the 
SVN and HG developers. I don't know what the API/interface for HG is, but SVN 
has a nice library that can be utilized if a tool was being built.
Further the cvs2svn project may be of interest as they do support cvs2hg, so it 
may provide at least some insight into a hg2svn tool.

$0.02

Ben


Mime
View raw message