river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: [PROPOSAL] Source drop and bug database
Date Thu, 04 Jan 2007 19:48:27 GMT
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.

View raw message