This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

eCos operations w/DVCS


Here is an incomplete list of some operations that I'll
need to perform when writing eCos applications.

These requirements have nothing to do with DVCS as such,
but when I consider how "simple" a version control system
is to use, then I think about the operations below.

- version control. We must be able to pull out a particular
version of the app, build it and create service packs.
We need to be able to easily build bug-by-bug compatible
firmware & service packs. The version control choice
is decided by the client in question or me(in that order).
cvs is pretty much off the radar these days, but svn is
the most popular choice.

- any project we work on has a *modified* snapshot of the
official eCos. Today this is done by tar'ing up a particular
snapshot of eCos and keeping that tar in the same version
control system as the app. (I'd love to see more maintainers,
more contributors and more effective patch processing in
eCos...)

- all projects I work on use *multiple* eCos repositories
and other non-eCos libraries. Version control system for each
repository and module varies, but I'm hopeful that
DVCS could handle them all via submodules. I'm not
sure how well cross DVCS submodules work... CVS is
getting increasingly rare out there, svn is very much
alive. svn is used extensively "in-house" because it's
so much easier to understand for non-sw developers
/ project participants. Encountering a new version control
system in this case is ... more work.

- any scripts and binaries used to build the app & eCos
is kept under version control together with the app.
Binaries include, but is not limited to GCC toolchain,
ecosconfig, etc. We must have the *same* bug-by-bug
compatible GCC toolchain binaries when we build
service packs as when we built the app version
we're branching off.

- side-by-side build capability of multiple applications
and service packs, e.g. "installing" eCos in a fixed
location ruins this. In the course of a day I can
easily work for multiple customers and multiple
versions of each app.

- we need to support multiple customers with very
different life cycles, hardware targets and
application types.

- bisection capability. We need to be able to relatively
easily rebuild apps to find where a bug was introduced.
bisection capability would be broken if we didn't commit
gcc tools, modified eCos versions, etc.





-- 
Ãyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]