incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: [SVN] Structure (was Re: List of code base needed to convert from Mercurial to SVN)
Date Fri, 26 Aug 2011 19:20:22 GMT
Yes.  I used PSFTP (not SFTP as I said), which comes with PuTTY and is handy for working in
Windows as a console application.

-----Original Message-----
From: Dave Fisher [mailto:dave2wave@comcast.net] 
Sent: Friday, August 26, 2011 11:41
To: odf-dev@incubator.apache.org
Subject: Re: [SVN] Structure (was Re: List of code base needed to convert from Mercurial to
SVN)


On Aug 26, 2011, at 10:41 AM, Rob Weir wrote:
[ ... ]
> 
> With AOOo I put the dumpfile on robweir.com.  I have not identified
> where on Apache one may ftp upload files.

scp -p dumpfile <id>@people.apache.org:~/.


> 
>>> 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.
>>> 
>>> Something I've been experimenting with that might be useful to you.
>> 
>> Is the plan to release separately for each component, or should we keep each component
on its own release schedule?
>> 
>> If it is separate then Dennis's structure makes more sense. If not then the odf/trunk/
makes more sense.
>> 
> 
> Currently they are different projects, each with their own releases,
> as well as their own doc, release notes, websites, etc.  The goal (as
> I understand it) is to merge them into one Apache project.  I'd start
> with everything under a single trunk, since I don't expect we'll
> branch/release individually.  Once everything is checked in I'd like
> to see us even move these closer together, e.g., a single Java src
> directory, common build script, integrated JavaDoc, common
> FAQ's/Release Notes, etc.

Then odf/trunk it should be.

Regards,
Dave

> 
> 
>> Regards,
>> Dave
>> 
>> 
>>> 
>>> - Dennis
>>> 
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: Rob Weir [mailto:robweir@apache.org]
>>> Sent: Friday, August 26, 2011 06:49
>>> To: odf-dev@incubator.apache.org
>>> Subject: Re: List of code base needed to convert from Mercurial to SVN
>>> 
>>> On Thu, Aug 25, 2011 at 11:14 PM, Devin Han <devinhan@apache.org> 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.
>>> 
>>> 
>>>> 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
>>> https://hg.odftoolkit.org/hg/ ?
>>> 
>>> 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?
>>> 
>>> 
>>> In SVN our root will be:
>>> 
>>> https://svn.apache.org/repos/asf/incubator/odf/
>>> 
>>> 
>>> So we'll want a directory structure for the trunk that looks like:
>>> 
>>> /odf/trunk/component1
>>> /odf/trunk/component2
>>> /odf/trunk/component3, etc.
>>> 
>>> [ ... ]
>>> 
>> 
>> 


Mime
View raw message