incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Devin Han <>
Subject Re: [SVN] Structure (was Re: List of code base needed to convert from Mercurial to SVN)
Date Mon, 29 Aug 2011 06:25:48 GMT
2011/8/27 Dennis E. Hamilton <>

> Another place to put SVN dump files is on an account@people.apache.orgwhere others can
reach it.  This is apparently one way to deliver to Apache
> Infrastructure when the time comes. (Did you do that with the
> Head, Rob?)
> Because of potentially separate projects having separate releases, it might
> be useful to consider,
> /odf/simple/trunk/...
> /odf/toolkit/trunk/...
> /odf/subproject3/trunk/...
> and the peers of each trunk are releases or, if you prefer the /tag and
> /branch structures that hold such things.  (I favor releases being siblings
> of trunk, but that's not typical.)
> My criterion is that /trunk/ and its peers are where the license and notice
> files show up applicable to the particular releasable,
> configurable/buildable/deployable component.
> As fa as I know, ODF Toolkit has 4 subproject and 9 code bases. The list as
   Code Generation (Revision 27):
   Code Generation(deprecated) (Revision 153):
   ODFDOM Developer Repository(Revision 133):
   JavaDoc Taglets(Revision 37):

2.Simple API (Revision 105):

3.Conformance Tools
ODF Validator (Revision 34):
ODF Validator is also available as an online service, but we don't have the
code of this component.

4.XSLT Runner
ODF XSLT Runner (Revision 67):
ODF XSLT Runner Task (Revision 18):

5.AODL - the .Net module of the ODFToolkit (Revision 13):

There are two code base for ODFDOM dom element and attribute generation,
Code Generation and Code Generation(deprecated). Both of them are only used
by ODFDOM developer for dom and package layers code generation. Should not
be included in the release jar of ODFDOM. And Code Generation(deprecated)
has been deprecated we will not use it in future code, just keeping the code
history for possible use.
JavaDoc Taglets is used by ODFDOM for JavaDoc tag.
The combine of ODFDOM  and SImple API has been accepted by most people.
Based on these reasons I suggest ODFDOM Developer Repository,  Simple API
and JavaDoc Taglets merged as a single respository.  Code Generation should
be kept single.
Conformance Tools and XSLT Runner  can keep no change.
We don't consider AODL now.
So the final code base structure should be ODFDOM&SIMPLE&Taglets,  Code
Generation, Code Generation(deprecated),  ODF Validator, ODF XSLT Runner and
ODF XSLT Runner Task, six code bases.

Something I've been experimenting with that might be useful to you.
>  - Dennis
> -----Original Message-----
> From: Rob Weir []
> Sent: Friday, August 26, 2011 06:49
> To:
> Subject: Re: List of code base needed to convert from Mercurial to SVN
> On Thu, Aug 25, 2011 at 11:14 PM, Devin Han <> wrote:
> > Hi all,
> >
> > I have converted the repository of Simple API from Mercurical  to SVN
> with
> > the help of  the modified shell script I mentioned before.  The other
> code
> > bases will be converted later.
> Great!
> I can help review this if you upload the dumpfile.
> 1) svnadmin dump file:///local-repo > dumpfile
> 2) gzip or zip the dumpfile
> 3) Upload someplace, maybe to ODF Toolkit Union website
> 4) I can then download and load the dumpfile into a local respository.
> Thanks for the guide. I am submitting the dump file to When finish, I will post another message to
explain it.

> > In order to avoid omit, it is necessary to make sure the code base list
> with
> > your guys.
> >
> Today we have a separate Hg repository per project, right?  Or is it
> possible to clone the entire project, via
> ?
> I tested this way, but it doesn't work. So I converted and dumped them

In the end we want to end up with a single SVN repository at Apache.
> What will be easier to accomplish this:
> 1) Combine everything into a single Hg project and then convert to SVN?
> or
> 2) Convert separate Hg projects to SVN and then merge them together in SVN?
> Which makes it easier to preserve history?
> I converted and dumped them separately, so the 2) may be easier.

> In SVN our root will be:
> So we'll want a directory structure for the trunk that looks like:
> /odf/trunk/component1
> /odf/trunk/component2
> /odf/trunk/component3, etc.
> [ ... ]
> That will be easy for separate dump files.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message