openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Herbert Duerr <>
Subject Re: (was: Building a single Hg repository)
Date Tue, 05 Jul 2011 09:16:22 GMT
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.

> 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.

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.


View raw message