* [ECOS] eCos submodule support [not found] <c09652430910191038m6ddd7153gcb6d7616719a72c9@mail.gmail.com> @ 2009-10-19 21:17 ` Øyvind Harboe 2009-10-20 7:50 ` [ECOS] " Daniel Néri ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Øyvind Harboe @ 2009-10-19 21:17 UTC (permalink / raw) To: eCos Disuss I've been tinkering w/git submodules and it really is a killer feature for the typical eCos application we work on: - we'll clone eCos repository and keep a modified version of that repository on our servers. Here we track various modifications in eCos until those modifications eventually make it back into the official eCos tree, or for those modifications that never should be made part of the main tree we keep it on our servers. This eCos repository is shared between clients/projects. - we'll clone the eCos repository onto *our* server in-house, yielding super fast checkout times. (git submodule update). This also does not waste bandwidth of official servers. - git submodules are also used for other eCos repositories that e.g. keep a specific HAL or some other feature. - this also works fine w/projects that use svn as a server, e.g. libmicrohttpd which is a module we use, but it's not actually an eCos project. - when various people work on the same project, we don't have to write scripts to set up the build environment(e.g. extract a specific version of eCos snapshot). It's clone + submodule init + submodule update => voila! At this point I have no idea what happens when throwing mercurial into the mix here, but "easy" isn't the first word that comes to mind :-) When choosing DVCS I hope that non-trivial operations are considered more than trivial ones. Trivial operations, like cloning, is trivial with git & mercurial both. For the most trivial operations downloading and untarring is probably the way to go rather than introducing version control at all. -- Ø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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ECOS] Re: eCos submodule support 2009-10-19 21:17 ` [ECOS] eCos submodule support Øyvind Harboe @ 2009-10-20 7:50 ` Daniel Néri 2009-10-20 10:47 ` Øyvind Harboe 2009-10-20 14:37 ` [ECOS] " Alex Schuilenburg 2 siblings, 0 replies; 15+ messages in thread From: Daniel Néri @ 2009-10-20 7:50 UTC (permalink / raw) To: ecos-discuss Ãyvind Harboe <oyvind.harboe@zylin.com> writes: > - when various people work on the same project, we don't > have to write scripts to set up the build environment(e.g. > extract a specific version of eCos snapshot). It's > clone + submodule init + submodule update => voila! > > At this point I have no idea what happens when > throwing mercurial into the mix here, but "easy" > isn't the first word that comes to mind :-) With hg it's just "clone" and the subrepos are automagically pulled and updated. How is that harder? Regards, Daniel -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ECOS] Re: eCos submodule support 2009-10-19 21:17 ` [ECOS] eCos submodule support Øyvind Harboe 2009-10-20 7:50 ` [ECOS] " Daniel Néri @ 2009-10-20 10:47 ` Øyvind Harboe 2009-10-20 14:45 ` Sergei Organov 2009-10-20 23:19 ` Alex Schuilenburg 2009-10-20 14:37 ` [ECOS] " Alex Schuilenburg 2 siblings, 2 replies; 15+ messages in thread From: Øyvind Harboe @ 2009-10-20 10:47 UTC (permalink / raw) To: eCos Disuss 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. So, eCos choosing "the other DVCS" would make my life harder even if that "other DVCS" is better. Does anyone have experience managing non-trivial hg projects as git submodules? -- Ø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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ECOS] Re: eCos submodule support 2009-10-20 10:47 ` Øyvind Harboe @ 2009-10-20 14:45 ` Sergei Organov 2009-10-20 21:37 ` Alex Schuilenburg 2009-10-20 23:19 ` Alex Schuilenburg 1 sibling, 1 reply; 15+ messages in thread From: Sergei Organov @ 2009-10-20 14:45 UTC (permalink / raw) To: ecos-discuss Ãyvind Harboe <oyvind.harboe@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. -- Sergei. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Re: eCos submodule support 2009-10-20 14:45 ` Sergei Organov @ 2009-10-20 21:37 ` Alex Schuilenburg 0 siblings, 0 replies; 15+ messages in thread From: Alex Schuilenburg @ 2009-10-20 21:37 UTC (permalink / raw) To: Sergei Organov; +Cc: ecos-discuss Sergei Organov wrote: > Ãyvind Harboe <oyvind.harboe@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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Re: eCos submodule support 2009-10-20 10:47 ` Øyvind Harboe 2009-10-20 14:45 ` Sergei Organov @ 2009-10-20 23:19 ` Alex Schuilenburg 2009-10-21 6:47 ` Øyvind Harboe 1 sibling, 1 reply; 15+ messages in thread From: Alex Schuilenburg @ 2009-10-20 23:19 UTC (permalink / raw) To: Øyvind Harboe; +Cc: eCos Disuss Ãyvind Harboe wrote: > [...] > I have never tried to manage hg as a submodule in git. > > So, eCos choosing "the other DVCS" would > make my life harder even if that "other DVCS" is > better. > I missed this bit :-/ I dont believe it will be harder - in fact I dont think it will make any difference if hg were chosen because hg plays nicely with git. More like the other way round - if git were chosen it would make proper use of a DRCS harder on the majority of the eCos community. git may be mainstream to Linux users, but is IMHO is not as user friendly as what the majority of eCos users and contributors should expect from a DRCS. I believe that it will make life harder than it ought to be when converting to a DRCS model, and particularly to anyone who is not familiar with Linux (Windows users, and the average eCos user). Think about it. Most eCos users and developers use Windows for their development, yet most contributors are Linux power users. Surely we want something that would encourage and make it easier for Windows hosted eCos developers to contribute, yet does not inhibit those Linux power users and existing regular eCos contributors (and of course the eCos maintainers) in any way? -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Re: eCos submodule support 2009-10-20 23:19 ` Alex Schuilenburg @ 2009-10-21 6:47 ` Øyvind Harboe 0 siblings, 0 replies; 15+ messages in thread From: Øyvind Harboe @ 2009-10-21 6:47 UTC (permalink / raw) To: Alex Schuilenburg; +Cc: eCos Disuss > Think about it. Most eCos users and developers use Windows for their > development, yet most contributors are Linux power users. Surely we > want something that would encourage and make it easier for Windows > hosted eCos developers to contribute, yet does not inhibit those Linux > power users and existing regular eCos contributors (and of course the > eCos maintainers) in any way? I think we should break out contribution in a separate topic.... Consider: http://sourceware.org/ml/ecos-patches/2009-10/msg00006.html http://sourceware.org/ml/ecos-patches/2009-07/msg00002.html No responses. Patches don't come much simpler than that... -- Ø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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] eCos submodule support 2009-10-19 21:17 ` [ECOS] eCos submodule support Øyvind Harboe 2009-10-20 7:50 ` [ECOS] " Daniel Néri 2009-10-20 10:47 ` Øyvind Harboe @ 2009-10-20 14:37 ` Alex Schuilenburg 2009-10-20 14:50 ` Øyvind Harboe 2009-10-20 23:55 ` Jonathan Larmour 2 siblings, 2 replies; 15+ messages in thread From: Alex Schuilenburg @ 2009-10-20 14:37 UTC (permalink / raw) To: Øyvind Harboe; +Cc: eCos Disuss Ãyvind Harboe wrote: > I've been tinkering w/git submodules and it really is > a killer feature for the typical eCos application we > work on: > hg is no different from git in this regard. > - we'll clone eCos repository and keep a modified > version of that repository on our servers. Here we > track various modifications in eCos until those > modifications eventually make it back into the official > eCos tree, or for those modifications that never should > be made part of the main tree we keep it on our > servers. This eCos repository is shared between > clients/projects. > > - we'll clone the eCos repository onto *our* server in-house, > yielding super fast checkout times. (git submodule update). > This also does not waste bandwidth of official servers. > > - git submodules are also used for other eCos repositories > that e.g. keep a specific HAL or some other feature. > > - this also works fine w/projects that use svn as a server, > e.g. libmicrohttpd which is a module we use, but it's > not actually an eCos project. > > - when various people work on the same project, we don't > have to write scripts to set up the build environment(e.g. > extract a specific version of eCos snapshot). It's > clone + submodule init + submodule update => voila! > > At this point I have no idea what happens when > throwing mercurial into the mix here, but "easy" > isn't the first word that comes to mind :-) > Then why are you using git? Everything you describe above regarding interoperability of DRCS with other RCS systems says you should be using hg. hg not only plays nicely with all the major RCS, distributed and centralised, but because git does not, hg has a git interface that not only allows it to push/pull to git repos, but also makes it look like a git repo. Don't believe me? Then go to: http://mercurial.selenic.com/wiki/HgGit#Using_hg-git_to_interact_with_a_hg_repository_with_git The more you talk about your requirements, the more convinced I am that not only eCos should use hg, but you should as well. > When choosing DVCS I hope that non-trivial operations > are considered more than trivial ones. > Such as? There is very little difference between hg and git as has been said time and time again, and not only on this list... > Trivial operations, like cloning, is trivial with git & mercurial > both. > > For the most trivial operations downloading and > untarring is probably the way to go rather than introducing > version control at all. > > Eh? How do you figure that? Working in a distributed environment with as many different RCS versions as you claim, updating on a weekly basis should not require you to download the whole 22MB of eCos every time or any other RCS (distributed or otherwise), especially if you just want to see what has changed. If git is reducing you to downloading tarballs for the simplest of operations, then you are either not using it properly or are using the wrong tool. hg provides incremental updates from CVS, svn, etc, as well as allowing two-way operations between git, bzr etc. In fact hg IMHO provides the widest and strongest RCS interoperability features of all the DRCS options on the table here. From what I have seen, most git users are just so arrogant that they think everyone should be using git, regardless of an individual's actual requirements, so there is no need to play nicely in the pool that is open source. Everyone should play nicely with them. hg-git is a good example that the hg team recognises that everyone has their own requirements and is entitled to their own choice, rather than having git rammed down your throat. So if you want to use git instead of hg, sure, hg will play nicely. And if you think that if you have to use git to do Linux development, think again. The Linux-HA projects uses hg. So do a whole host of other open source projects with more complex requirements than you have shown. I am *not* saying that git could not do a good job as well, but when you investigate why each of these projects chose hg over git and all the other options, the same old recurring theme comes to the fore time and time again. Simplicity, ease of use, documentation, and "it just works". Here are some examples: Open Office: http://blogs.sun.com/GullFOSS/entry/openoffice_org_development_switches_to FireFox: http://hg.mozilla.org/mozilla-central/ Google Code: http://googlecode.blogspot.com/2009/04/mercurial-support-for-project-hosting.html Python: http://mail.python.org/pipermail/python-dev/2009-March/087931.html Linux-HA: http://hg.linux-ha.org/ NetBeans: http://wiki.netbeans.org/HgHowTos OpenSolaris: http://opensolaris.org/ XEmacs: http://www.xemacs.org/ XEN: http://xenbits.xensource.com/ For a bigger list, see http://mercurial.selenic.com/wiki/ProjectsUsingMercurial -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] eCos submodule support 2009-10-20 14:37 ` [ECOS] " Alex Schuilenburg @ 2009-10-20 14:50 ` Øyvind Harboe 2009-10-20 19:22 ` Alex Schuilenburg 2009-10-21 0:00 ` Jonathan Larmour 2009-10-20 23:55 ` Jonathan Larmour 1 sibling, 2 replies; 15+ messages in thread From: Øyvind Harboe @ 2009-10-20 14:50 UTC (permalink / raw) To: Alex Schuilenburg; +Cc: eCos Disuss On Tue, Oct 20, 2009 at 4:37 PM, Alex Schuilenburg <alexs@ecoscentric.com> wrote: > Øyvind Harboe wrote: >> I've been tinkering w/git submodules and it really is >> a killer feature for the typical eCos application we >> work on: >> > hg is no different from git in this regard. Precisely. > Then why are you using git? Because, @ work, I have to learn and understand it, as the projects that I work & interact with use it. That hg is "better" doesn't mean that much. I have other projects I work on where e.g. git submodules are used extensively. There just isn't any way around learning about git in detail. hg I could potentially not learn, so far. At home I might have preferred hg. I've very glad to see that hg provides a good interface to git according to your description. I haven't tried it yet though. I'd love to hear about it if someone has taken it for a spin against the eCos hg test repository. -- Ø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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] eCos submodule support 2009-10-20 14:50 ` Øyvind Harboe @ 2009-10-20 19:22 ` Alex Schuilenburg 2009-10-20 19:36 ` Øyvind Harboe 2009-10-21 0:00 ` Jonathan Larmour 1 sibling, 1 reply; 15+ messages in thread From: Alex Schuilenburg @ 2009-10-20 19:22 UTC (permalink / raw) To: Øyvind Harboe; +Cc: eCos Disuss Ãyvind Harboe wrote: >> Then why are you using git? >> > > Because, @ work, I have to learn and understand it, as the projects > that I work & interact with use it. That hg is "better" doesn't mean that > much. > > I have other projects I work on where e.g. git submodules are used > extensively. There just isn't any way around learning about git in detail. > hg I could potentially not learn, so far. > Is it the git application or git format of repos that is mandated, or both? Because if your work also mandates you to work with other format repos, or sources in other formats, I would use whatever application could interact with them all the best, whether that was git, hg or whatever. If the git application is unable to interface with all of them, then that surely is a reason why I would use something that could (NB. I am not talking about switching repo format, just the tool that interacts with them). Just the same for hg - if hg could not do some operation I could do with git, I would use git. I kinda just see git and hg as tools that interact with repos, just as vim and emacs are editors that allow you to develop code. The underlying language of the source is the same, just the tool used to develop the source different and which one I use depends on what the requirements are of what I am developing. e.g. I might use vim to do merges, but emacs to do builds. Anyway, it seems that you are more reluctant in having to learn to use a different tool and would rather put up with the issues in the tools you know and feel most comfortable with. And there is nothing wrong with that. Whatever gets the job done quickest sometimes is all that is required. But if I felt always that way, I might never have switched away from CVS and converted our own internal repo or the eCos CVS repo. In the long run I have no doubt that the effort in learning another RCS tool and the effort in breaking away from CVS, a tool I was comfortable using and whose foibles I understood, would be worthwhile and will save me stress and time. And is already already has. It took me just under over an hour to upgrade the ecos bugzilla from 3.0.4 to 3.4.2 using hg, excluding the bugzilla facelift. And most of that time was spent removing own improvements that clashed with the same improvements made by bugzilla. e.g. removing email addresses from public viewing of bugs, which is now a feature of bugzilla. And FWIW, this was all done on XP (shock, horror!!!) - I wanted to taste my own medicine to see exactly how easy hg merge work was on Windows. And I am pleased to report it was easy. TortoiseHg on Windows is really neat! > At home I might have preferred hg. > > I've very glad to see that hg provides a good interface to git according > to your description. I haven't tried it yet though. I'd love to hear about it > if someone has taken it for a spin against the eCos hg test repository. > Me too! Of course it would also be upto the maintainers if they wanted to provide two interfaces to the same repo on sourceware, but from what I undertsand, this would also require an upgrade to the version of hg running on sourceware. At least hg offers that option. But then there really also is not much need since you can always run your own hg-git server locally if you were required or preferred to use git. Open source - is it not great? -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] eCos submodule support 2009-10-20 19:22 ` Alex Schuilenburg @ 2009-10-20 19:36 ` Øyvind Harboe 0 siblings, 0 replies; 15+ messages in thread From: Øyvind Harboe @ 2009-10-20 19:36 UTC (permalink / raw) To: Alex Schuilenburg; +Cc: eCos Disuss > Is it the git application or git format of repos that is mandated, or > both? It's the git skills. I have to, eventually, become fluent in them. It's not a matter of choice. -- Ø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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] eCos submodule support 2009-10-20 14:50 ` Øyvind Harboe 2009-10-20 19:22 ` Alex Schuilenburg @ 2009-10-21 0:00 ` Jonathan Larmour 1 sibling, 0 replies; 15+ messages in thread From: Jonathan Larmour @ 2009-10-21 0:00 UTC (permalink / raw) To: Øyvind Harboe; +Cc: Alex Schuilenburg, eCos Disuss Ãyvind Harboe wrote: > On Tue, Oct 20, 2009 at 4:37 PM, Alex Schuilenburg >>Then why are you using git? > > Because, @ work, I have to learn and understand it, as the projects > that I work & interact with use it. That hg is "better" doesn't mean that > much. That's primarily Linux presumably. > I have other projects I work on where e.g. git submodules are used > extensively. There just isn't any way around learning about git in detail. > hg I could potentially not learn, so far. Whichever VCS is chosen, we would intend to put up some documentation and "recipes" so that people can get going with it. So basic use should be no problem. I would also hope that even if it's not git, we'd be able to show git users how to interface with it (although that will require someone to do it the first time to write it up!). Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] eCos submodule support 2009-10-20 14:37 ` [ECOS] " Alex Schuilenburg 2009-10-20 14:50 ` Øyvind Harboe @ 2009-10-20 23:55 ` Jonathan Larmour 2009-10-21 1:43 ` Alex Schuilenburg 1 sibling, 1 reply; 15+ messages in thread From: Jonathan Larmour @ 2009-10-20 23:55 UTC (permalink / raw) To: Alex Schuilenburg; +Cc: eCos Disuss Alex Schuilenburg wrote: > From what I have seen, most git users are > just so arrogant that they think everyone should be using git, > regardless of an individual's actual requirements, Please be civil on this list. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] eCos submodule support 2009-10-20 23:55 ` Jonathan Larmour @ 2009-10-21 1:43 ` Alex Schuilenburg 0 siblings, 0 replies; 15+ messages in thread From: Alex Schuilenburg @ 2009-10-21 1:43 UTC (permalink / raw) To: Jonathan Larmour; +Cc: eCos Disuss Jonathan Larmour wrote: > Alex Schuilenburg wrote: >> From what I have seen, most git users are >> just so arrogant that they think everyone should be using git, >> regardless of an individual's actual requirements, > > Please be civil on this list. Sorry, I never meant to imply that anyone on this list was arrogant. I had just come off a list where I simply seeked clarification what RCS interoperability support was available in git and was "strongly criticised" for not simply converting to git and then only using git. My comment was directed at those on that list where I guess it is OK to flame those who don't drink their flavour cool-aid. -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Re: eCos submodule support
@ 2009-10-23 8:54 Alex Schuilenburg
0 siblings, 0 replies; 15+ messages in thread
From: Alex Schuilenburg @ 2009-10-23 8:54 UTC (permalink / raw)
To: eCos Disuss
Alex Schuilenburg wrote on 2009-10-20 22:37:
> Sergei Organov wrote:
>
>> Ãyvind Harboe <oyvind.harboe@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.
>
Just to update on this.
It appears you are able to use git to push/pull to/from a hg repo using
the hg-git plugin, it is just a bit convoluted to set up.
From the author of hg-git at:
http://github.com/blog/439-hg-git-mercurial-plugin#comment_1933
"technically, you /can/ use this to use Git to collaborate on Hg
hosted projects - there are 'gimport' and 'gexport' commands that
will just do the object translations - but it's a bit more
convoluted. i'll try to write up a guide on how to do that at some
point after this is all settled down."
-- 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
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2009-10-23 8:54 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <c09652430910191038m6ddd7153gcb6d7616719a72c9@mail.gmail.com> 2009-10-19 21:17 ` [ECOS] eCos submodule support Øyvind Harboe 2009-10-20 7:50 ` [ECOS] " Daniel Néri 2009-10-20 10:47 ` Øyvind Harboe 2009-10-20 14:45 ` Sergei Organov 2009-10-20 21:37 ` Alex Schuilenburg 2009-10-20 23:19 ` Alex Schuilenburg 2009-10-21 6:47 ` Øyvind Harboe 2009-10-20 14:37 ` [ECOS] " Alex Schuilenburg 2009-10-20 14:50 ` Øyvind Harboe 2009-10-20 19:22 ` Alex Schuilenburg 2009-10-20 19:36 ` Øyvind Harboe 2009-10-21 0:00 ` Jonathan Larmour 2009-10-20 23:55 ` Jonathan Larmour 2009-10-21 1:43 ` Alex Schuilenburg 2009-10-23 8:54 [ECOS] " Alex Schuilenburg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).