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

Re: How to structure nested releases?

From: Henrik Sundberg <storangen_at_gmail.com>
Date: 2007-05-17 23:24:38 CEST

Thank you!
I've added a little more info/questions below.

2007/5/17, Hari Kodungallur <hkodungallur@gmail.com>:
> 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.

The subcomponents are part of only one component. I would prefer to
have them located inside their respective component. Having them
nested still means that I should let the components refer to their
subcomponents using externals, doesn't it?

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

This seems doable.

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

When you do this separate check out, how do you get the changes to the
correct place? Do you test them locally, and check them in before you
copy them to the system structure? I'm completely new to svn, and
rather lost here...

Would careful use of switch be better than externals, or would I just
end up in a big mess?
Or would the trick be to use switch at the moment I would like to do
changes? I.e. I use externals for a complete system, but since
changing in those files would mean that I would be changing tags,
instead of trunks, I should do a switch to the trunk of the
subcomponent?
(And I would need to do a switch on the component level, as well, to
be able to perform feature-commits?)

Branching of systems will not help me, will it? The branch will just
contain the same externals as the system trunk, and since all changes
will be in the subcomponents there will be no connection to the
system, will it?
Shall I both branch and switch?

Is this nesting a bad idea? Or is it normal in larger systems (KDE?)?

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

Thanks a lot!
/$

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 17 23:24:58 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.