Merge points in Hg repository (was: An svn question)

[Greg Stein <gs...@gmail.com>]

On Sat, Jun 25, 2011 at 08:48, Jens-Heiner Rechtien <jh...@web.de> 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 :-)

>...

Cheers,
-g

Re: Merge points in Hg repository (was: An svn question)

[Stephan Bergmann <st...@googlemail.com>]

On Jun 29, 2011, at 7:14 AM, Greg Stein wrote:
> On Sat, Jun 25, 2011 at 08:48, Jens-Heiner Rechtien <jh...@web.de> 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?

Whether strange parenting causes a problem depends on how we can handle Hg merge nodes in the Hg->SVN transition.

If we need to go with what I outlined above (only follow history along the first parent's path of a merge node, effectively dropping history of the second parent's path, up to the node where those two paths originally split), we could loose large chunks of "master branch" history (and not only loose the detailed history of a CWS, only retaining the "integrated CWS so-and-so" merge commit---which would also be non-trivial loss, anyway).

However, if SVN offers a better way to map the Hg revision graph (as you suggest; need to look into that), the point about strange parenting might indeed be moot.

-Stephan

Re: Merge points in Hg repository (was: An svn question)

[Jens-Heiner Rechtien <jh...@web.de>]

Hi Greg,

On 06/29/2011 07:14 AM, Greg Stein wrote:
> On Sat, Jun 25, 2011 at 08:48, Jens-Heiner Rechtien<jh...@web.de>  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