[ECOS] Re: Replacing CVS - decision time

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Jifl" == Jonathan Larmour <jifl@jifvik.org> writes:

    <snip>
    Jifl> * Submodules

    Jifl> Both hg and git support submodules, which are a way to nest
    Jifl> repositories inside other repositories. For example, we
    Jifl> could consider separating out the host tree into its own
    Jifl> repo, and for those that do need it, they can integrate it
    Jifl> as a submodule so make the "whole" tree again. Or we could
    Jifl> consider separate repos for architecture-specific
    Jifl> components, which is more blue sky. The rationale to
    Jifl> splitting things up more is not just smaller repository
    Jifl> downloads, but so that when people are tracking repository
    Jifl> changes they are more likely to be seeing changes relevant
    Jifl> to them, and not for example a plethora of MIPS changes when
    Jifl> they'll never ever be working on MIPS. Or target side
    Jifl> developers rarely get heavily involved in host tool
    Jifl> development or vice versa. Submodules have the potential to
    Jifl> be a lot of use I think, but nothing's likely to happen soon
    Jifl> though because we'd have problems with some of our
    Jifl> monolithic files like the top level ecos.db. Also to really
    Jifl> separate the host stuff, we should remove host tools from
    Jifl> the package repository (instead having an analogous host
    Jifl> package repository) which would IMHO be a good thing.

ecos.db may be less of an issue than you think. The key is that it is
really a Tcl script, not just a text file. Hence you should be able to
do something like (untested):

  set mips_db [file join $::component_repository "hal/mips/mips.db"]
  if { [file exists $mips_db] }
      source $mips_db
  }

in the toplevel ecos.db and keep all the entries for MIPS-related HALs
and drivers in a separate .db file in the mips submodule.

There would be an impact on the documentation. More seriously
ecosadmin.tcl would probably need a lot of attention, if not a
rewrite, but it is problematical anyway when dealing with a database
held in a version control system. A possible solution may be for
ecosadmin.tcl to operate on its own database ecosadmin.db, sourced
from the main ecos.db

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
  ** Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv> **
  ** 27-29 April 2010, Booth 640, San Jose McEnery Convention Center **

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