openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Stahl <>
Subject Re: (was: Building a single Hg repository)
Date Wed, 06 Jul 2011 11:50:27 GMT
On 05.07.2011 11:16, Herbert Duerr wrote:
> On 05.07.2011, Rob Weir wrote:
>> Is the Hg ==> Git conversion easier/cleaner than the conversion to SVN?
> Yes. Having the CWSs in SVN would only increase the size of the
> repository considerably without providing benefits after they get
> merged. Speaking of merges in SVN we regularly had the problem that a
> file was renamed in one CWS and changed in another CWS and the result
> was that the change got lost. HG or GIT handle this scenario much more
> gracefully, so there was less risk to do big merges.

indeed, which led to effectively forbidding moving files in SVN...
i hope SVN has learned to signal a merge conflict for this nowadays?

>> I notice that Apache Infrastructure does support *read-only* Git
>> repositories:
>> Would it be any simpler to move the enter Oracle-hosted project,
>> including all CWS's to a read-only Git, and then create a dump of just
>> the integrated trunk (with history) for the project's SVN repository?
>> Then, we'll have ongoing access to the CWS's in Git until such point
>> as they are ready to be integrated. In other words, treat the Git
>> version as a read-only archive.
> If the goal is to just merge the outstanding CWSs into trunk I'd suggest
> to stay with hg, merge all good CWSs into trunk and start the apache-ooo
> SVN repository from that trunk.
> If the goal is to preserve the trunk and CWSs of the old-OOo project
> then the idea to provide it as a read-only git repository is great,
> especially since it would work in the current infrastructure. With
> the conversion could be easy.
> Unfortunately that tool hasn't been extended to handle hg-bookmarks yet
> but it handles hg-branches just fine. So if someone more experienced
> with HG can rewrite the latest fetch-all-cws script posted here from
> hg-bookmarks to its hg-branches equivalent we would be only one step
> away from such a "status-quo" repository. I guess the resulting bare
> repo would only consume about 1.5GB for everything.

this is a very interesting idea, so i've tried to figure out how to do 

found this article most helpful:

unfortunately, (in contrast to HG bookmarks) it doesn't seem to be 
possible to retroactively move HG commits onto a HG named branch.
for a HG named branch the branch is part of the commit metadata, so this 
would need modifying the existing commits, and i've not found a tool 
that can do this (the HG convert extension allows for renaming branches, 
but in this case we'd need to move _some_ commits from the default 
branch to a CWS branch, and i can't see how that could be done).

there is another tool, a HG extension called hg-git, which can convert 
HG bookmarks to git branches.

so my current plan is this:
1. convert OOO340 repo to git via
2. pull all CWSes into OOO340 repo and create bookmarks
3. use hg-git to push all of them into the converted git repo

it would also be possible to use hg-git to convert the whole HG repo 
with bookmarks in one step; don't know which is the better way, and the 
hg-git homepage mentions the word "slow" somewhere, while we have 
"", so i'll try this route first :)

> For a more complete history we could then also add the >1000 CWSs from
> the svn period. I found that having the individual instead of the big
> merge-hunks was invaluable for understanding the status of some code.
> Even with these many CWSs the result will probably stay under 2.0GB.

hmm... could be useful :)

"The 'sound' banker, alas! is not one who sees danger and avoids it,
  but one who, when he is ruined, is ruined in a conventional and
  orthodox way along with his fellows so that no one can really
  blame him." -- John Maynard Keynes

View raw message