Re: [PROPOSAL] Source drop and bug database

[Craig L Russell]

This is a test to see if I understand the Harmony strategy (I'm not involved in the Harmony project...)

On Jan 4, 2007, at 11:48 AM, Mark Brouwer wrote:

Geir Magnusson Jr. wrote:

We have something similar in harmony - we have the main components distinct because they can be versioned separately

   harmony/classlib/trunk
   harmony/drlvm/trunk
   etc
and then a "federated build point" :
   harmony/trunk
which uses the magic of svn to create
   harmony/trunk
               /working_classlib
               /working_vm
               /working_jdktools
               /commonresources

    harmony/trunk/working_classlib
is the same as working in
    harmony/classlib/trunk

so from the POV of trunk, you have one big tree, yet each of those subdirs had a svn switch done to them so working in It works very nicely - its very convenient to work in, and means that in the future, other VMs or such can be swapped in w/o disruption of the current subprojects.

Let me try to understand the implications of all this.

Say classlib is getting ready for a release.

Independent of a Harmony release, which isn't quite ready for release due to non-classpath issues.

At that time you branch to
(forgive me the use of perforce conventions)
harmony/classlib/version/1.5/ , most people keep working on the trunk
line and a few keep working on stabilizing the version/1.5 line.

Yes.

After a
certain point in time, a decision has been reached and

harmony/classlib/release/1.5/0 is created to reflect the final release.

It might be better to just tag the release/1.5 branch by creating yet another branch that by convention is read-only. That way, after release you can continue to work in the 1.5 branch for maintenance of that branch but if you need to check out what you released, you check out the tag.

When you are about to branch the harmony/trunk will you alter the
'mappings' so the release or version branch of the individual projects
are mapping to the harmony trunk?

When you are getting ready to release Harmony, you create a new releases/3.0 from the Harmony trunk. You create new classlib/releases/ 1.6 from the classlib trunk and so forth for each of the sub projects. You update the Harmony/releases/3.0 to refer to the stabilizing branches for each of the sub projects. Harmony trunk continues to refer to the sub projects' trunks.

In other words will
harmony/trunk/working_classlib actually be
harmony/classlib/release/1.5/0, or am I screwing things up?

I think the working_classlib in the Harmony/releases/3.0 branch will be changed to refer to the classlib/releases/1.6 branch. So the stabilizing activities of each sub project will be folded into the stabilizing Harmony/releases/3.0 branch.

Should I see the magic of SVN as a sort of symbolic links to get a
'virtual' view on the actual repository. Something that perforce e.g.

repository itself.

arranges with clientviews that maps various locations of the repository under a common root in your workspace, but that is not reflected in the

Don't know perforce well enough to comment. :-(

Craig

--
Mark

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature