This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Splitting the eCos repository
I don't think so - at least not for some time.
For most people having a single repository makes life simpler.
Installation is easier, you just need the one directory tree rather
than several.
It also makes life more complicated. E.g. how to manage changes to the
eCos repository.
There seems to be some belief that the average product can use eCos +
HAL's unmodified. I have seen plenty of evidence to the effect that
changes to eCos HAL & other modules will be required by non-trivial
products.
The ECOS_REPOSITORY environment variable is simpler,
with just one entry, so there is much less to worry about if that
variable gets corrupted somehow or if one of the directories gets
moved around for some reason. The single tree is what is documented,
not just in our documentation which we can change (given appropriate
effort) but also in other works like the Massa book. We do not have
problems with novice users complaining on ecos-discuss that they
cannot find e.g. microwindows because they have not installed or
checked out some optional repository. Sure, most eCos users will not
be interested in microwindows but why make life unnecessarily
complicated for the ones who are?
I view the introduction of multiple eCos repositories as a necessary
level of complexity. See above.
Yes, there are disadvantages. A single repository will contain lots of
stuff that any given developer won't need, wasting disk space. However
the average size of a hard disk is growing faster than the size of an
eCos repository so that problem is actually becoming less important
over time. Similarly bandwidth is becoming less of an issue.
I don't view harddisk space as an observable, i.e. there is no other
way that the user can tell that 10 or 100 mByte is used to store eCos
other than looking.
However, the *large* number of files becomes a performance problem.
Consider: how do I store a snapshot of eCos under source control?
Tricky. I keep a .zip of the entire eCos repository under CVS. Then I
unzip & work on the eCos repository. Once I've made changes(or
updated to the latest eCos CVS), I zip up the entire dir and place it
under CVS. CVS is terribly inefficient with this sort of
thing(sloooow), should work better with subversion that has binary
diff capability(.zip should work better than e.g. tar.bz2 for binary
diff).
Support for multiple repositories is great for experienced users. I
have about 20 different repositories at the moment, a mixture of
branches and development trees, and my ECOS_REPOSITORY path has six
entries. However I see no reason for inflicting multiple repositories
on novice users. They have enough to learn as it is.
Before any reasonably well organised(i.e. they use some source control
on their own stuff and care about eCos CVS HEAD versions/snapshots)
and non-trivial product is finished, I believe that they would have
wished that they had been introduced to multiple repositories.
--
Øyvind Harboe
http://www.zylin.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss