incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <>
Subject Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
Date Thu, 22 Sep 2011 13:56:18 GMT
On Thu, Sep 22, 2011 at 3:18 PM, Rob Weir <> wrote:

> 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.
agree, from this perspective it make sense. The question then is when we
want to introduce this further level?

> 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

i assumed that a developer will check out trunk, maybe a wrong assumption

> 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.

i think so too. And with my changed mindset to not always check out trunk
completely i am fine with this approach.

> Another thing to keep in mind is the SVN support for "externals":
interesting, i didn't know that before


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