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
