incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pedro F. Giffuni" <>
Subject Re: single repository status
Date Wed, 20 Jul 2011 04:30:47 GMT

When merging the branches most of the CWS information will be
lost anyways .. won't it? I have seen other projects using
subversion that take a snapshot and eventually update stuff
from trunk, but when the project is finished and merged back
the branch history is not viewable from the trunk, the
commit message is normally the only trace left.

Perhaps we should do a "simple" trunk conversion and identify
the branches that are useful to merge them one by one? We
could even set a schedule for branch merging and after certain
date just don't look back.

While here.. what tool are you using to do the conversion?
A quick look would indicate

hg convert --dest-type svn hgreponame svnreponame

would do the trick, but then some people just write scripts
for this:


--- On Tue, 7/19/11, Michael Stahl <> wrote:

> On 14.07.2011 18:03, Michael Stahl
> wrote:
> > On 09.07.2011 07:57, Greg Stein wrote:
> >> Once the tags are properly marked, then we can
> start testing the
> >> conversion to Subversion. Please note, however:
> the hg conversion
> >> script does *not* process tags. We will have to
> write that. We will
> >> also have to somehow manage construction of
> branches. We may also have
> >> to update the conversion tool to properly handle
> the "merge"
> >> changesets that Hg records.
> > 
> > after looking at the HG convert svn_sink a little,
> this looks rather
> > difficult to me.
> > 
> > well, tags should be easy.
> > 
> > but how to reconstruct the branching is kind of
> unclear to me.
> > the first ~260k changesets are linear and were
> initially taken from SVN,
> > so that shouldn't be a problem.
> > but then there are lots of HG merge changesets.
> 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...
> > in the HG repo there is sort of a "master" history
> that is basically a
> > sequence of CWS integration merge changesets, with the
> occasional
> > masterfix thrown in.
> > but this is not explicit: these are all just merges
> with 2 parents, and
> > it's not guaranteed which of these 2 is the CWS and
> which the master.
> > basically the requirement is to convert one of the
> thousands of paths
> > through this DAG from the common ancestor revision
> ~260k to revision
> > c904c1944462 (OOO340 head) into a SVN trunk.
> to be more specific, the last revision from OOo SVN was the
> tag "last_svn_milestone" (263206  d0058b5891eb)
> (which is not actually a common ancestor, as some CWSes are
> based on older milestones)
> the following merge commits are those on the DEV300
> master/"trunk" where i've noticed the "follow the first
> parent" heuristic would fail, and the second parent (after
> the arrow) should be taken instead.
> 90552a19cdc4 -> dae1ffc5c15d
> 9572400cd241 -> ce1b12199f72
> c33f611c4373 -> 5d0c069f2570
> 13b3d2dae916 -> 62bf02dff30b
> 37dc1e423a1e -> 664c5f3a9291
> 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
> option 1. seems to be too much effort to me, and would have
> to be implemented by a real SVN wizard.
> option 2. requires some effort, but should be doable; we
> still lose all CWS internal history though (e.g. CWS undoapi
> becomes a single 57,788 line changeset against 562 files).
> after thinking about it for a while, a trunk-only history
> in SVN doesn't seem to be all that useful to me (you need to
> go over the network to access something incomplete...).
> far more useful would be to have a read-only HG/git
> repository available that contains the _full_ history and
> all open CWS branches, which can be cloned and examined
> off-line.
> opinions?
> regards,
>  michael
> =n

View raw message