Sergei Organov wrote: > Øyvind Harboe <oyvind.har...@zylin.com> writes: > >> To be a bit more clear: >> >> My assumption is that there is no appreciable difference >> between hg/git for the case when *all* modules are >> either git/hg. >> >> The problem is with heterogeneous projects. >> >> When working with eCos I've only ever encountered >> git, cvs and svn as version controls. CVS very rarely >> these days. I'm sure there are eCos relevant projects >> that use hg, I just haven't encountered them. >> >> Managing svn as a submodule in git is easy enough. >> >> I have never tried to manage hg as a submodule in git. >> > > Probably the best bet is to keep your own git repository of eCos > (automatically and incrementally) converted from the official hg one, > then use those git repo as a submodule in your project utilizing git. > Or even better, a local hg repository providing a git interface. That way you could locally push changes upstream from the local hg repo (since I dont know if git can push to hg) as if it were a git repo, you would need upstream shell access to the remote hg repo to pull from your local git repo (since hg can pull and push to git). You could then stick to using git locally as mandated by your company, and still benefit from proper DRCS flow rather than a one-way downstream only flow.
-- Alex Schuilenburg Managing Director/CEO eCosCentric Limited www.ecoscentric.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
