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 14:56:33 GMT
On Thu, Sep 22, 2011 at 9:40 AM, Shao Zhi Zhao <zhaoshzh@cn.ibm.com> wrote:

> 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?
>
> I don't think moving the tree down one level introduces any new problems
for Symphony, so long as the directories within */main. remain the same.

Of course, merging code from Symphony into AOOo will be difficult in
general.  The problem is how do we establish a common "ancestor" revision to
do a 3-way merge with?  This will really depend on whether Symphony has a
good record of what the corresponding OOo revision was for each of its
initial files.

If not, then you can do a text diff and do some merging without trouble.
But dealing with renamed files, or moved files, or deleted files, these are
trickier to process automatically.

If you don't have that history, then in theory it could be reestablished by
taking the initial revision of each file in Symphony and comparing it to
each revision of the same file in OOo Mercurial, and find which revision
matches.  It might be possible to establish enough context for a 3-way merge
that way.

-Rob


>
>
> thanks
>
> mail:zhaoshzh@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
>
> [image: Inactive hide details for Rob Weir ---2011-09-22 21:20:44---Rob
> Weir <robweir@apache.org>]Rob Weir ---2011-09-22 21:20:44---Rob Weir <
> robweir@apache.org>
>
>
>     *Rob Weir <robweir@apache.org>*
>
>             2011-09-22 21:18
>             Please respond to
>             ooo-dev@incubator.apache.org
>
>
>
> To
>
> ooo-dev@incubator.apache.org,
> cc
>
>
> Subject
>
> Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic
> approach to IP review?]
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message