incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shao Zhi Zhao <>
Subject Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
Date Thu, 22 Sep 2011 13:40:03 GMT


Based on this result, an other trunk will be like the following if IBM
symphony checked in:

thus it introduces a problem:
How to merge the two trunks of symphony-src and ooo-src?

Address:2/F,Ring Bldg. No.28 Building, Zhong Guan Cun Software Park, No.8,
Dong Bei Wang West Road, ShangDi, Haidian District, Beijing 100193,

             Rob Weir                                                      
             rg>                                                        To 
             2011-09-22 21:18                                           cc 
             Please respond to         Re: handling of ext_sources -       
             ooo-dev@incubator         Juergen's suggestion [was: Re: A    
                  systematic approach to IP review?]  

2011/9/22 Jürgen Schmidt <>:
> 2011/9/22 Jürgen Schmidt <>
>> On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir <> 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
>>> 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
> get "ext_sources", "main" and "extras". To benefit from the modified
> 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

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


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

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":

This might make some things easier.


> Juergen

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