[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [imp-dev] Proposed reorg of IMP SVN repository structure
|
Title: Message
Hi
Jurgen
I think somewhere
in the middle achieves the worst of all possible worlds.
a) Everyone
suffers the change.
b) It's not
uniformly global (new)
c) It's not
uniformly plug-in based (old)
Developers should
check out everything anyway, so that they can assess
the impact of any
API experiments. (IMP has not been notable for its API
stability.)
Regards
Ed Willink
Hi Ed,
You can get a project
set from a wiki page for example, and then all you need to do
is "import
project set" from Eclipse.
Discussion:
I agree with you that
the proposed setup would simplify things from a certain perspective,
but I
know from experience that it will complicate things too. At least where IMP's
architecture is supposed to
support variability, like using the run-time
without having to use the meta-tools, is where its repository should
support independent branching and tagging. To alleviate some of the
overhead of modularity, we might go for
some middle-ground where each
"feature" (collection of "projects") is put into one main repository folder
with
its trunk,branches and tags. I wouldn't do that either, but
nevertheless its an idea. Its a matter of guestimating which
parts of IMP
are expected to evolve (semi-)independently and which are going to be in
complete lock-step.
One other thing; my developers only use and
depend on two or three of IMP's projects. If we reorganize the
code as
proposed, they will be presented (unnecessarily) with all of IMP if they check
out the trunk.
Cheers,
Jurgen
