2011/8/23 Rob Weir <[email protected]> > On Mon, Aug 22, 2011 at 6:21 AM, Devin Han <[email protected]> wrote: > > Hi all, > > > > I am doing the test that move code repository from Mercurial to SVN with > > patch history information. > > I found a shell script to finish this job: > > > http://qa-ex-consultant.blogspot.com/2009/10/converting-mercurial-repo-to-subversion.html > > Now I am preparing the SVN environment and familiar with the script file. > > Hope it works well. > > > > Good luck. > > Have you seen the Mecurial "convert" extension? I have not tried it, > but it looks interesting: > > > http://stackoverflow.com/questions/1898994/converting-from-mercurial-to-subversion > > I test this extention. But it doesn't work... Firstly, I faced an error info that "NameError: global name 'transport' is not defined ". The reason is: The standalone Mercurial installers on Windows do not include Subversion python bindings. However the TortoiseHg installers do include them. After I installed this binding, it start to work. But it was failed by another exception "abort: svn exited with status 1". No more information, so I can't find the reason... Does anyone else face the same issue before?
-Rob > > > > 2011/8/20 Rob Weir <[email protected]> > > > >> On Wed, Aug 17, 2011 at 7:28 PM, Dave Fisher <[email protected]> > >> wrote: > >> > > >> > On Aug 17, 2011, at 1:34 PM, Rob Weir wrote: > >> > > >> >> There is a page that gives basic guidelines for Podling Websites [1], > >> >> including some recommended links. It also refers us to the branding > >> >> guidelines [2]. > >> >> > >> >> Looking at the POI website [3] I see that it has a section in the > >> >> navigator for "Component APIs". That might be a good model for us to > >> >> follow. Overtime we might combine our pieces more tightly, but I > >> >> think that for now we are starting with distinct pieces: > >> >> > >> >> 1) ODFDOM > >> >> 2) Simple API > >> >> 3) ODF Conformance checker > >> >> 4) ODF XSLTRunner and servlet > >> >> > >> >> I thought initially we could copy the POI website directly, as a > basis > >> >> for ours, but it does not appear to use the Apache CMS and markdown. > >> >> Is that correct? > >> > > >> > That is correct. It uses an old version of Forrest. You have to build > the > >> site separately and then stage it into production from your people > account. > >> > > >> > We should copy the Apache CMS setup from AOOo. With that current > >> framework we can wrap both markdown and html. > >> > > >> >> > >> >> If so, then I'd propose that we "svn copy" the markdown from the > >> >> Apache OpenOffice.org podling's website [4], and rebrand it for our > >> >> ODF Toolkit website. That will give us the basic boilerplate for the > >> >> podling website. > >> >> > >> >> Proposed directory structure: > >> >> > >> >> For the source code: > >> >> > >> >> asf/incubator/odf/trunk > >> >> asf/incubator/odf/branches > >> >> asf/incubator/odf/tags > >> >> > >> >> I don't think we should go immediately to a common tree for the Java > >> >> source. But maybe have something like this initially: > >> >> > >> >> asf/incubator/odf/trunk/odfdom/ > >> >> asf/incubator/odf/trunk/simple/ > >> >> > >> >> and so on. We can always move things around once we have it in SVN. > >> >> Of course, I'm open to other ideas on this as well. But the sooner > we > >> >> get the code into SVN, the sooner we can engage and grow a broader, > >> >> more diverse community around this code. > >> >> > >> >> And then for the website we would start with: > >> >> > >> >> asf/incubator/odf/site/trunk > >> >> asf/incubator/odf/site/branches > >> >> asf/incubator/odf/site/tags > >> >> > >> >> We probably don't need a deep directory structure there. But we > could > >> >> have a subdir for each component, e.g.: > >> >> > >> >> asf/incubator/odf/site/trunk/odfdom > >> >> asf/incubator/odf/site/trunk/simple > >> > > >> > OK, if we go with the Apache CMS then there is an implied structure > under > >> asf/incubator/odf/site/trunk > >> > > >> > asf/incubator/odf/site/trunk/content/odftoolkit/ > >> > asf/incubator/odf/site/trunk/lib > >> > asf/incubator/odf/site/trunk/templates > >> > > >> > >> Good catch. We want this to have a single root from the CMS > perspective. > >> > >> > So, > >> > > >> > asf/incubator/odf/site/trunk/content/odftoolkit/odfdom > >> > asf/incubator/odf/site/trunk/content/odftoolkit/simple > >> > > >> >> > >> >> etc. > >> >> > >> >> Any thoughts on this? Any alternative proposals? > >> >> > >> >> Since people are still signing up on the list, and we're just getting > >> >> started, I'd like to give a good amount of time for comments. But if > >> >> there are no objections by Monday at 1200 UTC, then I'll assume Lazy > >> >> Consensus" [5] and request Apache CMS support from Apache > >> >> Infrastructure and start checking in the website framework. > >> > > >> > >> Anyone have any other comments? I just checked, and we now have all > >> of the initial committers signed up on the list. So if you did not > >> see the proposal when initially posted, please take a look. > >> > >> > Once we are enabled for svn I can adapt and check in the CMS framework > >> from AOOo. Then whenever we get the ability to stage and go to > production > >> we'll be ready. > >> > > >> > Regards, > >> > Dave > >> > > >> >> > >> >> A question: Is there anything we need to do to enable SVN? I don't > >> >> see anything at http://svn.apache.org/repos/asf/incubator/odf/ right > >> >> now. I assume someone with karma for > >> >> http://svn.apache.org/repos/asf/incubator/ needs to bootstrap us? > >> >> > >> >> -Rob > >> >> > >> >> > >> >> > >> >> [1] http://incubator.apache.org/guides/sites.html > >> >> [2] http://incubator.apache.org/guides/branding.html > >> >> [3] http://poi.apache.org/ > >> >> [4] http://incubator.apache.org/openofficeorg/ > >> >> [5] http://www.apache.org/foundation/glossary.html#LazyConsensus > >> > > >> > > >> > > > -- -Devin
