[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Fwd: How to structure nested releases?

From: Hari Kodungallur <hkodungallur_at_gmail.com>
Date: 2007-05-17 22:41:16 CEST

sorry, forgot to hit 'reply-all'.. forwarding to the list

On 5/17/07, Henrik Sundberg <storangen@gmail.com> wrote:
>
> I'd like to make releases of systems, components and subcomponents.
> I'll try to explain my self in a concise manner, but perhaps it makes
> the questions incomprehensible.
>
> A system release contains (among other things) selected component
> releases (different systems contains different selections of
> components from a large component base).
>
> A component release contains selected subcomponent releases.
>
> 1) Should all systems, components and subcomponents be located in
> parallel directories (ie on the same directory level)? Or is it
> feasible to let the subcomponents be released inside their components?

It depends on whether the said subcomponents are part of only that
component. If not (that is same subcomponent is part of multiple
components), it may be easier to look at it as a component itself and let
them be in parallel directories.

2) If I copy component releases into a system trunk, will I then be
> able to (easily) see which component releases I've copied? I don't
> want the release numbers of the components/subcomponents to be part of
> the checked out structure. Can the release numbers be visible in the
> svn structure, without being a part of the checked out structure?

Not quiet sure I understand this correctly, but may be you could have a
structure like:

/components
  - comp1/1.0.0
               /1.0.2
               /2.0.0-DEV
  - comp2/3.1.0
               /3.1.2

etc? And as you suggest later you could use judicious use of externals to
check these out. The external could refer to comp1 as
$MY_SVN_ROOT/components/comp1/1.0.2 comps/comp1
In this case the SVN structure has the version number but the checked out
source does not. You can still get the revision being used by querying the
externals (depending on the need, you will have to write a small script to
get all the externals / version info)

I think my problem is close to how mingw looks:
> http://www.mingw.org/download.shtml#hdr2
>
> It seems that consistent use of externals might do most of what I
> want, but in that case:
> 3) Is it possible to make an atomic feature commit in several
> subcomponents in one system? Will the externals break the commit, even
> though they are referring to the same repository?

This is tricky. If you want to do changes and do an atomic commit to
components checked out as externals and source code that is not checked out
as externals, I don't think it is possible. I may be wrong.
We have had situations like this, but in such situations, we checked out the
source code separately and did the changes (That is even though a component
is checked out as external, since it is in the same repository, we can check
it out as a separate folder -- the while components/ directory in the above
structure for example). It may be a little bit of a overhead though.

4) Is there any kind of support for questions like: "Is there a newer
> release of any of the subcomponents of the components that are
> included in my system?"?
>

I guess you will have to write some scripts to query externals to do this.

Hope this helps

regards,
-Hari Kodungallur
Received on Thu May 17 22:41:37 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.