Hi Greg,
On 06/29/2011 07:14 AM, Greg Stein wrote:
On Sat, Jun 25, 2011 at 08:48, Jens-Heiner Rechtien<[email protected]> wrote:
On 06/24/2011 09:07 AM, Stephan Bergmann wrote:
...
Which gets me thinking of the next topic, how exactly to import the
current OOo Hg repository into SVN. While Hg has the concept that a
revision can have two parents (so the revision graph need not be
After my investigation into Hg, I've found out about this. The
two-parent concept is nice. Subversion *does* have merge-tracking now,
so it understands when you merge another item into the working copy's
"parent", and it will record that fact.
I will note that the primary Hg repository has 2005 of these merge commits.
These merge commits will need to be handled during the Hg->svn
conversion. I don't know if the code does this today.
linear), SVN only supports a single parent per revision (so has a
strictly linear graph). Import of Hg into SVN will have to map the
non-linear graph to a linear one. I think an automatic approach
(which is the only feasible one) in general can only work as follows:
Walking backwards from the head (assuming there is only one),
transfer the current revision to SVN and proceed to its first parent
(if there is one; otherwise we reached the bottom and are done).
Since CWS have (hopefully) always been merged into the master as the
second parent of a merge revision (if a merge was necessary), this
will loose the detailed history of most CWS. (And if a CWS ever got
merged as the first parent of a merge revision, and master as second,
we will loose history big time.)
Most of the time the CWS is the second parent. Unfortunately there is no way
that we can rely on that. I'm almost certain that there are cases where
first and second parent are switched.
Couldn't we just set a bookmark for the DEV300 tip? Or use one of the
tags? I don't understand how merging CWS's with "strange" parenting
would cause us a problem. I'm a Mercurial n00b, so maybe I'm missing
something?
So from a history-preserving point
of view, moving from Hg to SVN is bad. Or am I missing something?
Actually I wouldn't even try to do it with a history preserving approach.
Just import it flat and have a hg repository on the side for reference. That
That is incredibly difficult for developers who would like to explore.
For researchers look at our code. For people trying to find "why"
something exists. ... any number of reasons. It seems that we can
bring over history. Maybe some more work, but it is a one-time cost
compared to the many, MANY years that OOo will exist.
way we get rid of all problems regarding broken/missing/wrong copyrights of
old files. If there ever was a time to do a clean start, it's now. Remember,
we did the same thing when we open sourced OOo back in 2000.
And I've seen people wishing that all the history was present. We can
do it! No reason to give up :-)
If it's possible than it would be great, no doubt! It's just that I have
done one SCM migration to many over the last years and know how
difficult it can be to get the details right. BTW, you do know that the
old SVN repository which was the basis of the 2009 migration to HG is
still online? You can find it here:
http://svn.services.openoffice.org/ooo/
Only /trunk was migrated, we used 'hg convert'.
Heiner
--
Jens-Heiner Rechtien
