incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
Date Thu, 22 Sep 2011 13:18:19 GMT
2011/9/22 Jürgen Schmidt <jogischmidt@googlemail.com>:
> 2011/9/22 Jürgen Schmidt <jogischmidt@googlemail.com>
>
>> On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir <robweir@apache.org> wrote:
>>
>>>
>>> I was thinking something similar.  We only need to use the SVN
>>> interface to the files when we're adding or updating.  But we can have
>>> bootstrap continue to download via http.  The location, using
>>> Juergen's proposed location, would be
>>> http://svn.apache.org/repos/asf/incubator/ooo/trunk/ext-sources
>>>
>>> yes, this is the correct URL, the URL that i have posted wouldn't work
>>
>> Juergen
>>
>>
>>> This would save having a duplicate local SVN working copy of the file,
>>> right?
>>>
>>>
> mmh, no or i understand something wrong. People checkout .../trunk and would
> get "ext_sources", "main" and "extras". To benefit from the modified script
> we have to put "ext_sources" besides "trunk"
>
> .../ooo/ext_sources
> .../ooo/trunk/main
> .../ooo/trunk/extras
>
> Means back to my initial proposal, right?
>

I think the idea is this:  Everything under ooo represents what goes
into a release.  It can be tagged and branched.  trunk/ is a peer to a
tags/ and branches/ directory.

It is possible that we have this wrong.  Adding in site/ and ooo-site/
brings in a different convention.  They have are set up to have
trunk/tags/branches underneath them.  That is fine, because the
website does not "release" in synch with an OOo release.  It makes
sense for them to be able to tag and branch independently.

We should also consider how the project grows going forward.  We know
that other code bases will be checked in, like Symphony.  And there
are other, small, but disjoint contributions that I'm working on as
well.

So it might make sense to move trunk down one level:

/ooo/ooo-src/trunk/main
/ooo/ooo-src/trunk/extras
/ooo/ooo-src/trunk/ext-sources
/ooo/ooo-src/tags
/ooo/ooo-src/branches

That would make more sense then, as a unit, since we would want to tag
the across all of /ooo/ooo-src/ to define a release.

I assume a developer still just checks out ooo/ooo-src/trunk/main.  If
they need the additional "extras" then they check that out separately.
 I don't think most users will want to check out the entire trunk all
the time.   We should consider also how we want this tree to grow over
time, as other related

In the end, I think we want to preserve the ability to:

1) Preserve an audit trail of all changes that went into a release

2) Do be able to tag and branch a release and everything that is in the release

3) Restore the exact state of a previous tagged release, including the
exact ext-sources used in that release

I'm certain that my proposal will enable this.  There may be other
approaches that do as well.

Another thing to keep in mind is the SVN support for "externals":

http://svnbook.red-bean.com/en/1.0/ch07s03.html

This might make some things easier.

-Rob

> Juergen
>

Mime
View raw message