[ECOS] Splitting the eCos repository

Øyvind Harboe oyvind.harboe@zylin.com
Sun Aug 13 19:50:00 GMT 2006


> 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



More information about the Ecos-discuss mailing list