On 5/17/07, Henrik Sundberg <storangen@gmail.com> wrote:
>
> 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?
If you want to be able to *check-out* only a certain version of the
subcomponent when the component builds, then you might have to resort to
externals. But if you don't mind multiple versions being checked out (even
though you may only build against one particular version), it may not be
necessary. I think it also kinda depends on the build system and how you do
the build and some of the preferences you have (like the one you suggested
that you don't want to see the version info in the checked out source).
Having said that, I think it may just be easier to just consider the
subcomponents as separate components.
<snip>
> > >
> > > 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...
You don't have to take any extra care to get it into the right place, do
you? Because its all pointing to the same thing. There is only one source.
Example, you have a directory in the repository:
$MY_SVN_ROOT/components/comp1/1.0.0
$MY_SVN_ROOT/components/comp2/2.0.0
Your product trunk is:
$MY_SVN_ROOT/trunk/myproduct/1.0
This directory has externals pointing to the components as below:
$MY_SVN_ROOT/components/comp1/1.0.0 comps/comp1
$MY_SVN_ROOT/components/comp2/2.0.0 comps/comp2
So basically when you checkout $MY_SVN_ROOT/trunk/myproduct/1.0 to
$HOME/trunk,
you will have:
$HOME/trunk/comps/comp1
$HOME/trunk/comps/comp2
AFAIK, if you try to checkin chanages from $HOME/trunk, the checkins to
component externals are not going to be atomic (in fact, I think it might
just ignore the externals and you will have to do separate check-in from
each directory).
So, what we did during development was, we checkout
$MY_SVN_ROOT/components into $HOME/components and then work from there. That
way we can do all the checkins within one revision when we need to.
For testing we also keep the trunk separately checked out as well (on your
desktop if you have enough diskspace -- or on a test system). And you can
update the trunk once the changes to the components have gone in separately
("svn update") and then do a build and / or test.
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?)?
>
>
I have had issues with switch command before and I stopped using it :( So I
won't comment on that.
thanks!
-Hari
Received on Fri May 18 02:17:18 2007