Re: [PROPOSAL] Source drop and bug database

[Mark Brouwer]

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

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

    harmony/trunk/working_classlib

is the same as working in

    harmony/classlib/trunk

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

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? In other words will
harmony/trunk/working_classlib actually be
harmony/classlib/release/1.5/0, or am I screwing things up?

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.
arranges with clientviews that maps various locations of the repository
under a common root in your workspace, but that is not reflected in the
repository itself.
--
Mark