On 07/23/2011 03:46 PM, Rob Weir wrote:
On Sat, Jul 23, 2011 at 8:22 AM, florent andré
<[email protected]> wrote:
Hi,
I also think that we need codebase in svn soon.
Yes.
Following your all pretty good comments, import a "perfect" hg history into
svn seems not to be quite easy... and will require works and effort.
As Michael Stahl says "Hg/git/otherDSCMs and SVN have fundamentally
different data models for representing branching/merging".
So hg --> svn is complicated but hg --> git seems to works pretty well.
The main point is to have a way to lurk the history, and to host this
history into Apache infra in order to be Oracle's server shut down tolerant.
So, what about this proposal ? :
- ask infra to set up a special git ooo-history
I'm assuming that ooo-history would be read-only?
yep, as all existing git repo.
The only "special" things is that this git repo isn't link with an
existing svn repos (actual apache git repo are read-only mirror of svn).
- import only the main hg branch into svn
- if someone interested in a specific hg branch :
** git checkout theBranch (from ooo-history)
** svn create branch from trunk ( Btrunk)
** diff Btrunk / theBranch for creating patch
** apply patch on Btrunk
** commit Btrunk
Sure we will lost a lot of history in svn... but we still have it in git
ooo-history...
... And a new (hi)story begin in Apache svn ! :)
This will require infra to set up a special ooo-history git repos... but if
we are kind they may accept :).
What do you think ?
I like the "lazy" approach. Defer the branch conversion work until it
is actually needed. It puts the human judgement in the loop at the
time when it is needed. If we believed that 100% (or even 80% or 90%)
of the CWS would be needed immediately for integration into our first
release, then it might make sense to do all that work up front. But
if we believe that only a few are needed, then it doesn't make sense
to hold up the entire project for this.
hg repos seems hudge and if we all import in one shoot there is - IMO -
a risk of being lost in this ocean of code.
Begin with the more "almost ready" hg branch and then import code after
human judgement could be a more step by step and manageable processing.
One concern would be on the IP perspective. Before we can have a
release or graduate from Podling, we need to review our source code
and remove all incompatible 3rd party components. We're also working
to ensure that the Oracle SGA is updated to contain all the files we
need for AOOo. If we have two repositories, a "clean" one in SVN and
an "unreviewed" version in git that we occasionally dip into for
unintegrated branches, then IP compliance becomes more difficult.
Maybe not impossible, but certainly more complicated.
Oracle SGA is for sure a things to fix first.
Considering 2 repositories and release/graduation :
- we have to *check it carefully*, but from my POV the "official" repos
will be the svn one, ooo-history is just a backup one, so might not be
considered for release / graduate
- the IP / incompatible 3rd party, could be more easily manageable I
think because :
* we first working on one hg branch/trunk and not on all the code ocean.
So it will be more easy to get rid of IP and 3rd because less place to
get them hidden.
* integration of a new svn branch (from ooo-history) will be a patch to
the clean svn trunk. This patch / new branch will be first checked by
the "human behind the commit" and after by others ooo commiters...
Code added will me less, more that double checked, so ip/3rd will have
less chances to use the black door.
++
-Rob
++
On 07/21/2011 03:16 PM, Jens-Heiner Rechtien wrote:
On 07/20/2011 12:05 PM, Eike Rathke wrote:
Hi Michael,
On Tuesday, 2011-07-19 23:26:48 +0200, Michael Stahl wrote:
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...
I didn't dug deeper into this, but conversion from hg to git should be
pretty straight forward and then there's git-svn, would that be viable
to import branches as well?
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
I'd prefer #3 and have a read-only hg/git repository for cases where one
really wants to lookup history. AOOo needs to get its code base going.
+1 for #3. We need the repository ASAP to get going. If we have to write
the conversion tools first we'll loose way to much time which could be
spent better on getting AOOo 3.4 (or whatever the first AOOo release
will be called) out of the door. A pity that Apache git support is not
ready for prime time ... would make things so much easier.
Heiner
