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
