On Jan 4, 2007, at 2:48 PM, 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
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.
Sure (although we won't be releasing classlib separately...)
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?
That's the beauty of it - you can make the "federation" be anything
that you want - makes it easy to work with bits you want to.
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.
I guess so.
geir
--
Mark
