hi,
Based on this result, an other trunk will be like the following if IBM
symphony checked in:
/ooo/symphony-src/trunk/main
/ooo/symphony-src/trunk/extras
/ooo/symphony-src/tags
/ooo/symphony-src/branches
thus it introduces a problem:
How to merge the two trunks of symphony-src and ooo-src?
thanks
mail:zhaos...@cn.ibm.com
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,
P.R.China
Rob Weir
<robweir@apache.o
rg> To
ooo-dev@incubator.apache.org,
2011-09-22 21:18 cc
Subject
Please respond to Re: handling of ext_sources -
ooo-dev@incubator Juergen's suggestion [was: Re: A
.apache.org systematic approach to IP review?]
2011/9/22 Jürgen Schmidt <jogischm...@googlemail.com>:
> 2011/9/22 Jürgen Schmidt <jogischm...@googlemail.com>
>
>> On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir <robw...@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
>
