* [ECOS] Looking in a future: VCS for eCos 3.0 @ 2008-08-28 2:37 Sergei Gavrikov 2008-08-29 15:02 ` Jonathan Larmour [not found] ` <2a3305fe0809110931p4fcc42b1sffb0cc51a9e7c25b@mail.gmail.com> 0 siblings, 2 replies; 12+ messages in thread From: Sergei Gavrikov @ 2008-08-28 2:37 UTC (permalink / raw) To: eCos discuss list Hello It's possible it is an off-topic, but, looking in the nearest future of eCos project http://sourceware.org/ml/ecos-discuss/2008-07/msg00057.html I did think, It's possible, it is a good moment to change VCS (version control system) for eCos development? A couple of years it was/is CVS. The CVS has a well know limitations, and today, most of the developers select Distributed VCS. The famous are bk, git, hg. ... I do not want to fire the VCS flame here, but, if in the "eCos 3.0 planning" said * Support for Microsoft Vista within the eCos host tools Is it possible would you/we look on one multi-platform VCS? There is such a Distributed VCS there. I talk about Bazaar http://bazaar-vcs.org/ There are a few nice and _short_ intros on it's frontpage. Why the bazaar? At first, because the eCos FAQ did mention about :-) http://ecos.sourceware.org/fom/ecos?_recurse=1&file=1#file_44 It is a joke. Bazaar is young project and it seemed for me, it will be have a good future, because, it is a Multi-platform and FREE VCS. Most of the Windows users hate CLI, and you gave them eCos `configtool', I remember about CLI magic on http://ecos.sourceware.org/anoncvs.html, Bazaar developers offer a windows standalone installer and it is easy to integrate the bazaar in windows explorer using Tortoise, for example: http://bazaar-vcs.org/TortoiseBzr. (CLI guys can do no panic, bzr has same CLI syntax as git or svn has). Today, 2 main issues of bzr are known. The bazaar a bit more _slow_ than git or hg, the bazaar is _young_ and less known than other (elder VCS) http://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities I can add third one, We have Tcl/Tk, we will have yet Python :-) But, who knows... Should we look in a future? Thanks, 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] 12+ messages in thread
* Re: [ECOS] Looking in a future: VCS for eCos 3.0 2008-08-28 2:37 [ECOS] Looking in a future: VCS for eCos 3.0 Sergei Gavrikov @ 2008-08-29 15:02 ` Jonathan Larmour 2008-08-29 16:08 ` Sergei Gavrikov 2008-12-05 1:09 ` [ECOS] " Sergei Gavrikov [not found] ` <2a3305fe0809110931p4fcc42b1sffb0cc51a9e7c25b@mail.gmail.com> 1 sibling, 2 replies; 12+ messages in thread From: Jonathan Larmour @ 2008-08-29 15:02 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: eCos discuss list Sergei Gavrikov wrote: > Hello > > It's possible it is an off-topic, but, looking in the nearest future of > eCos project http://sourceware.org/ml/ecos-discuss/2008-07/msg00057.html > I did think, It's possible, it is a good moment to change VCS (version > control system) for eCos development? A couple of years it was/is CVS. > The CVS has a well know limitations, and today, most of the developers > select Distributed VCS. The famous are bk, git, hg. ... I do not want > to fire the VCS flame here, but, if in the "eCos 3.0 planning" said A switch of VCS is probably something to tackle very soon after eCos 3.0 rather than before. I agree that it's time to move forward from CVS. I've had a look at Bazaar and would need a bit of convincing personally, at the least at this stage of its development. I found this an interesting read: http://sayspy.blogspot.com/2006/11/bazaar-vs-mercurial-unscientific.html (including the comments). I'm still more inclined towards Mercurial, although SVN is an obvious possibility just really due to its more widespread use and slightly better client support (in addition both of which are available on sourceware.org, but Bazaar isn't). But I'd really really prefer to have something distributed. When the time comes, we can see what it looks like then. The decision isn't just mine of course. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ 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] 12+ messages in thread
* Re: [ECOS] Looking in a future: VCS for eCos 3.0 2008-08-29 15:02 ` Jonathan Larmour @ 2008-08-29 16:08 ` Sergei Gavrikov 2008-08-30 5:31 ` srinivas naga vutukuri 2008-12-05 1:09 ` [ECOS] " Sergei Gavrikov 1 sibling, 1 reply; 12+ messages in thread From: Sergei Gavrikov @ 2008-08-29 16:08 UTC (permalink / raw) To: Jonathan Larmour; +Cc: eCos discuss list On Fri, Aug 29, 2008 at 02:55:21PM +0100, Jonathan Larmour wrote: > Sergei Gavrikov wrote: > > Hello > > > > It's possible it is an off-topic, but, looking in the nearest future of > > eCos project http://sourceware.org/ml/ecos-discuss/2008-07/msg00057.html > > I did think, It's possible, it is a good moment to change VCS (version > > control system) for eCos development? A couple of years it was/is CVS. > > The CVS has a well know limitations, and today, most of the developers > > select Distributed VCS. The famous are bk, git, hg. ... I do not want > > to fire the VCS flame here, but, if in the "eCos 3.0 planning" said > > A switch of VCS is probably something to tackle very soon after eCos 3.0 > rather than before. I agree that it's time to move forward from CVS. > > I've had a look at Bazaar and would need a bit of convincing personally, at > the least at this stage of its development. I found this an interesting > read: > http://sayspy.blogspot.com/2006/11/bazaar-vs-mercurial-unscientific.html > (including the comments). I'm still more inclined towards Mercurial, > although SVN is an obvious possibility just really due to its more > widespread use and slightly better client support (in addition both of > which are available on sourceware.org, but Bazaar isn't). But I'd really > really prefer to have something distributed. > > When the time comes, we can see what it looks like then. The decision isn't > just mine of course. Jonathan, thank you for your responce! I have become to think what I will be alone voter :-) I would vote for either mercurial or bazaar. Both are Distributed VCS, both are cross-platforms, both are written in Python (but mercurial has `diff' is written in C, so, `hg' did penalty `bzr' in 2006, bzr'2008 is faster). I would not vote for SVN, just thinking: If it is elder, therefore, it is more stable and clever. I found again what I read about bazaar's strength in 2007 from Mark Shuttleworth http://www.markshuttleworth.com/archives/123 (with the comments). It is interesting to read too. Thank you for your link. 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] 12+ messages in thread
* Re: [ECOS] Looking in a future: VCS for eCos 3.0 2008-08-29 16:08 ` Sergei Gavrikov @ 2008-08-30 5:31 ` srinivas naga vutukuri 2008-09-01 9:14 ` Marcos Del Puerto 0 siblings, 1 reply; 12+ messages in thread From: srinivas naga vutukuri @ 2008-08-30 5:31 UTC (permalink / raw) To: ecos-discuss Why can't include git tool (which is using for linux kernel X.org etc projects) along with bzr, hg for discussion, as it also falls in the distributed version control tool. one of site, http://git.or.cz/ best regards, srinivas. On Fri, Aug 29, 2008 at 9:35 PM, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote: > On Fri, Aug 29, 2008 at 02:55:21PM +0100, Jonathan Larmour wrote: >> Sergei Gavrikov wrote: >> > Hello >> > >> > It's possible it is an off-topic, but, looking in the nearest future of >> > eCos project http://sourceware.org/ml/ecos-discuss/2008-07/msg00057.html >> > I did think, It's possible, it is a good moment to change VCS (version >> > control system) for eCos development? A couple of years it was/is CVS. >> > The CVS has a well know limitations, and today, most of the developers >> > select Distributed VCS. The famous are bk, git, hg. ... I do not want >> > to fire the VCS flame here, but, if in the "eCos 3.0 planning" said >> >> A switch of VCS is probably something to tackle very soon after eCos 3.0 >> rather than before. I agree that it's time to move forward from CVS. >> >> I've had a look at Bazaar and would need a bit of convincing personally, at >> the least at this stage of its development. I found this an interesting >> read: >> http://sayspy.blogspot.com/2006/11/bazaar-vs-mercurial-unscientific.html >> (including the comments). I'm still more inclined towards Mercurial, >> although SVN is an obvious possibility just really due to its more >> widespread use and slightly better client support (in addition both of >> which are available on sourceware.org, but Bazaar isn't). But I'd really >> really prefer to have something distributed. >> >> When the time comes, we can see what it looks like then. The decision isn't >> just mine of course. > > Jonathan, thank you for your responce! I have become to think what I > will be alone voter :-) I would vote for either mercurial or bazaar. > Both are Distributed VCS, both are cross-platforms, both are written in > Python (but mercurial has `diff' is written in C, so, `hg' did penalty > `bzr' in 2006, bzr'2008 is faster). I would not vote for SVN, just > thinking: If it is elder, therefore, it is more stable and clever. I > found again what I read about bazaar's strength in 2007 from Mark > Shuttleworth http://www.markshuttleworth.com/archives/123 (with the > comments). It is interesting to read too. Thank you for your link. > > 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 > > -- 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] 12+ messages in thread
* Re: [ECOS] Looking in a future: VCS for eCos 3.0 2008-08-30 5:31 ` srinivas naga vutukuri @ 2008-09-01 9:14 ` Marcos Del Puerto 2008-09-01 14:24 ` [ECOS] " Grant Edwards 2008-09-01 16:56 ` [ECOS] " Sergei Gavrikov 0 siblings, 2 replies; 12+ messages in thread From: Marcos Del Puerto @ 2008-09-01 9:14 UTC (permalink / raw) To: ecos-discuss Of course that eCos centric has to choose the VCS that best fits their likes and requirements, but does eCos really need a distributed VCS? I do not know how eCos is developed but I do not think there are eCos development groups sparse around the globe who commit frecuently changes? Has eCos centric outsourced parts of the development kernel to other companies? Does eCos centric uses an Agile development methodology where commits are performed several times a day by each developer and they do not have access to Internet so they want to commit locally and the merge all the changes we they get online? Do they need perform diff operations with revisions other than the checked out while working offline? Does eCos makes instensive use of branching operations? When Mark Shuttleworth talks about technical issues he must be simple ignored or at least his post should have a advisory: developers don't take this into account I really don't know what I'm talking about. At the beginning you can find his posts funny even hilarious but they are just that. For example using Ubuntu's 6 month release cycle for all distros, or being optimistic about seeing KDE running on GTK, the bad april month for ubuntu (you know, 150.000 bugs in ubuntu vs 5.000 in debian) and now this a super ultra mega app killer whose main advantage is that it renames files really fast. Is that necessary for eCos? I mean how many files in the eCos kernel have been renamed in the last years? And Bazaar is slow, very slow (I need it quite often to fetch source code from launchpad among others). One of the mayor Git problems is that it is still poor documented and the tools for windows are still in early stages. Migrating for example the Linux kernel from bitkeeper to Git when you have developed the VCS yourself is not so painful but otherwise is not precisely easy... Both of them have plugings for different IDEs but at least for Eclipse they are still buggy and poor featured whereas SVN has several ones, Subversive for example is since months in Eclipse incubation. I never worked with Mercurial. SVN is stable, fast, secure, works without problems through routers, directory structures are handled more efficiently than with CVS, file history is maintained even when files are moved or renamed, commits are atomic, branching and tagging take a constant amount of time, migrating from CVS is very easy, protocol clients available for several programming languages, Tortoise SVN, even if we remove the .svn files and make changes to the source, so there is a conflict it can be solve easily.... Even if you want to allow third parties create hal drivers and commit it into the eCos mainstream you would just need creating a new project and adding the rest of eCos code as external dependency. So I think that Bazaar, Git or Mercurial would be an option in a couple of years and if eCos centric allows third parties to add drivers to the VCS or their answer to the first questions is mainly affirmative. Right now I vote for SVN. Best regards, Marcos del Puerto On Sat, Aug 30, 2008 at 2:09 AM, srinivas naga vutukuri <srinivas.vutukuri@gmail.com> wrote: > Why can't include git tool (which is using for linux kernel X.org etc > projects) along with bzr, hg for discussion, as it also falls in the > distributed version control tool. one of site, http://git.or.cz/ > > > best regards, > srinivas. > > > On Fri, Aug 29, 2008 at 9:35 PM, Sergei Gavrikov > <sergei.gavrikov@gmail.com> wrote: >> On Fri, Aug 29, 2008 at 02:55:21PM +0100, Jonathan Larmour wrote: >>> Sergei Gavrikov wrote: >>> > Hello >>> > >>> > It's possible it is an off-topic, but, looking in the nearest future of >>> > eCos project http://sourceware.org/ml/ecos-discuss/2008-07/msg00057.html >>> > I did think, It's possible, it is a good moment to change VCS (version >>> > control system) for eCos development? A couple of years it was/is CVS. >>> > The CVS has a well know limitations, and today, most of the developers >>> > select Distributed VCS. The famous are bk, git, hg. ... I do not want >>> > to fire the VCS flame here, but, if in the "eCos 3.0 planning" said >>> >>> A switch of VCS is probably something to tackle very soon after eCos 3.0 >>> rather than before. I agree that it's time to move forward from CVS. >>> >>> I've had a look at Bazaar and would need a bit of convincing personally, at >>> the least at this stage of its development. I found this an interesting >>> read: >>> http://sayspy.blogspot.com/2006/11/bazaar-vs-mercurial-unscientific.html >>> (including the comments). I'm still more inclined towards Mercurial, >>> although SVN is an obvious possibility just really due to its more >>> widespread use and slightly better client support (in addition both of >>> which are available on sourceware.org, but Bazaar isn't). But I'd really >>> really prefer to have something distributed. >>> >>> When the time comes, we can see what it looks like then. The decision isn't >>> just mine of course. >> >> Jonathan, thank you for your responce! I have become to think what I >> will be alone voter :-) I would vote for either mercurial or bazaar. >> Both are Distributed VCS, both are cross-platforms, both are written in >> Python (but mercurial has `diff' is written in C, so, `hg' did penalty >> `bzr' in 2006, bzr'2008 is faster). I would not vote for SVN, just >> thinking: If it is elder, therefore, it is more stable and clever. I >> found again what I read about bazaar's strength in 2007 from Mark >> Shuttleworth http://www.markshuttleworth.com/archives/123 (with the >> comments). It is interesting to read too. Thank you for your link. >> >> 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 >> >> > > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss > > -- 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] 12+ messages in thread
* [ECOS] Re: Looking in a future: VCS for eCos 3.0 2008-09-01 9:14 ` Marcos Del Puerto @ 2008-09-01 14:24 ` Grant Edwards 2008-09-01 15:25 ` Marcos Del Puerto 2008-09-01 15:42 ` Frank Pagliughi 2008-09-01 16:56 ` [ECOS] " Sergei Gavrikov 1 sibling, 2 replies; 12+ messages in thread From: Grant Edwards @ 2008-09-01 14:24 UTC (permalink / raw) To: ecos-discuss On 2008-09-01, Marcos Del Puerto <mpuertog@gmail.com> wrote: > Of course that eCos centric has to choose the VCS that best > fits their likes and requirements, Why do you say that? eCos does not belong to eCosCentric. > but does eCos really need a distributed VCS? Yes. > I do not know how eCos is developed but I do not think there > are eCos development groups sparse around the globe who commit > frecuently changes? Yes, there are developers outside eCosCentric. > Has eCos centric outsourced parts of the development kernel to > other companies? You seem to be under the impression that eCos is the property of eCosCentric. The FSF holds the copyrights to eCos, and some development goes on outside of eCosCentric. I'd probably vote for Subversion, except for the fact that Subversion is what we use internally. Since subversion treats the CVS directory and its contents as normal files, it's rather handy the way it is. I can check out a source tree from CVS and then check it into Subversion (CVS directories and all). Merging in changes from the "official" tree is simply a matter of doing a "cvs update" followed by an "svn commit". At any time I can do either a "cvs diff" or an "svn diff". Still, if the consensus was to move to Subversion for eCos, I wouldn't complain. -- Grant -- 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] 12+ messages in thread
* Re: [ECOS] Re: Looking in a future: VCS for eCos 3.0 2008-09-01 14:24 ` [ECOS] " Grant Edwards @ 2008-09-01 15:25 ` Marcos Del Puerto 2008-09-01 15:42 ` Frank Pagliughi 1 sibling, 0 replies; 12+ messages in thread From: Marcos Del Puerto @ 2008-09-01 15:25 UTC (permalink / raw) To: ecos-discuss Sorry. I know eCos Pro is not the same as eCos. I knew that the FSF was the copyright holder of eCos but I couldn't find any reference to eCos in RedHat or at the FSF page more recent than 2004. Given that: * John Dallaway is the eCos 3.0 release manager, * ecos is an eCos centric's registered trademark * The future version release announcement "...and it is time to push forward with our plans for a new release of eCos" * And announcements like Ahttp one in ecosforge: "While we're waiting for the paperwork to clear in the official eCos repository we merge changes here." and ecosforge's about section I believed (mistakenly) that when he said "we" he meant the company and that its development was mainly centralized in it (at least as far as the CVS commits are concerned). Best regards, Marcos del Puerto On Mon, Sep 1, 2008 at 4:23 PM, Grant Edwards <grante@visi.com> wrote: > On 2008-09-01, Marcos Del Puerto <mpuertog@gmail.com> wrote: > >> Of course that eCos centric has to choose the VCS that best >> fits their likes and requirements, > > Why do you say that? eCos does not belong to eCosCentric. > >> but does eCos really need a distributed VCS? > > Yes. > >> I do not know how eCos is developed but I do not think there >> are eCos development groups sparse around the globe who commit >> frecuently changes? > > Yes, there are developers outside eCosCentric. > >> Has eCos centric outsourced parts of the development kernel to >> other companies? > > You seem to be under the impression that eCos is the property > of eCosCentric. The FSF holds the copyrights to eCos, and some > development goes on outside of eCosCentric. > > I'd probably vote for Subversion, except for the fact that > Subversion is what we use internally. Since subversion treats > the CVS directory and its contents as normal files, it's rather > handy the way it is. I can check out a source tree from CVS > and then check it into Subversion (CVS directories and all). > Merging in changes from the "official" tree is simply a > matter of doing a "cvs update" followed by an "svn commit". > At any time I can do either a "cvs diff" or an "svn diff". > > Still, if the consensus was to move to Subversion for eCos, I > wouldn't complain. > > -- > Grant > > > > > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss > > -- 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] 12+ messages in thread
* Re: [ECOS] Re: Looking in a future: VCS for eCos 3.0 2008-09-01 14:24 ` [ECOS] " Grant Edwards 2008-09-01 15:25 ` Marcos Del Puerto @ 2008-09-01 15:42 ` Frank Pagliughi 1 sibling, 0 replies; 12+ messages in thread From: Frank Pagliughi @ 2008-09-01 15:42 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss One thing to consider, as well, is the planned development & release cycle going forward. Will eCos go back to a periodic, stable release cycle (where the source-controlled code is considered relatively unstable), or continue with occasional major releases, where most people access the head of the development tree? I ask, because I would like to see a way that we could provide for multiple developers to collaborate on a new feature, or a way to distribute an "experimental" package for test and comment before committing it to the main trunk. Currently, it can get difficult e-mailing patches back and forth, and this is exactly the problem that source control systems solved for us. Frank -- 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] 12+ messages in thread
* Re: [ECOS] Looking in a future: VCS for eCos 3.0 2008-09-01 9:14 ` Marcos Del Puerto 2008-09-01 14:24 ` [ECOS] " Grant Edwards @ 2008-09-01 16:56 ` Sergei Gavrikov 2008-09-02 16:28 ` [ECOS] " Dave Lawrence 1 sibling, 1 reply; 12+ messages in thread From: Sergei Gavrikov @ 2008-09-01 16:56 UTC (permalink / raw) To: Marcos Del Puerto; +Cc: ecos-discuss Marcos Del Puerto wrote: > Of course that eCos centric has to choose the VCS that best fits their > likes and requirements, but does eCos really need a distributed VCS? I > do not know how eCos is developed but I do not think there are eCos > development groups sparse around the globe who commit frecuently > changes? Has eCos centric outsourced parts of the development kernel > to other companies? Does eCos centric uses an Agile development > methodology where commits are performed several times a day by each > developer and they do not have access to Internet so they want to > commit locally and the merge all the changes we they get online? Do > they need perform diff operations with revisions other than the > checked out while working offline? Does eCos makes instensive use of > branching operations? Let's clarify disputes, what does mean 'distributed' in VCS/SCM world? At the first, the world 'distributed' in the VCS/SCM world does mean a repository model: distributed model vs. client-server model. Execuse me this quotation from Wikipedia: <quotation> In a _client_-_server_ model, users access a master repository via a client; typically, their local machines hold only a working copy of a project tree. Changes in one working copy must be committed to the master repository before they are propagated to other users. In a _distributed_ model, repositories act as peers, and users typically have a local repository with version history available, in addition to their working copies. </quotation> The _consequence_ is that D-VCS repository model can/does look like a new development model or methodology. It is a certain thing, the D-VCS development flows differ from the usual VCS development flow, though the flows can be same if we need that (centralizated development flow). [snip] > Is that necessary for eCos? I mean how many files in the eCos kernel > have been renamed in the last years? Agree. A renaming is not needed for eCos project and it even is not possible, because the eCos paths/names are hard coded in eCos CDLs (for example, CDL `directory' entity locates every path under ECOS_REPOSITORY entry). > And Bazaar is slow, very slow (I need it quite often to fetch source > code from launchpad among others). A slow branch retriving... Try 'rsync' server-side CVSROOT or SVN repository with all commits :-) The first clone (branch) command for any D-VCS take more time than SVN's 'co' and 'up' duplet (if you want just to build some workcopy typing 'configure && make', you will be concerned in D-VCS). With D-VCS we get a whole project history locally. What is more important for project developers: a handy written ChangleLog of the main stream or real project history in side a VCS room? What is about a speed of local checkouts for D-VCS? If we have an import of a heritage of RHELP eCos under D-VCS... [snip] > SVN is stable, fast, secure, works without problems through routers, > directory structures are handled more efficiently than with CVS, file I've not seen a compliment "stable" for any VCS. Most of them are marked either "active developed" or "maintained but" in Wikipedia comparison: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software > Even if you want to allow third parties create hal drivers and commit > it into the eCos mainstream you would just need creating a new project > and adding the rest of eCos code as external dependency. And this above... it is a branch-hack-merge cycle in D-VCS. http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ > So I think that Bazaar, Git or Mercurial would be an option in a > couple of years and if eCos centric allows third parties to add > drivers to the VCS or their answer to the first questions is mainly > affirmative. Right now I vote for SVN. It's pitty that I did spell "Bazaar" in that my post. Today I would say, Which a repository model would you choose for a future code management: Distributed VCS or traditional (client-server, centralized) VCS? Well, aswered on this question, we will choose and development model too. How will we cook a soup? Sergei P.S. Today I found a cool on-line comparator: http://versioncontrolblog.com/comparison. -- 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] 12+ messages in thread
* [ECOS] Re: Looking in a future: VCS for eCos 3.0 2008-09-01 16:56 ` [ECOS] " Sergei Gavrikov @ 2008-09-02 16:28 ` Dave Lawrence 0 siblings, 0 replies; 12+ messages in thread From: Dave Lawrence @ 2008-09-02 16:28 UTC (permalink / raw) To: ecos-discuss [snip] >> SVN is stable, fast, secure, works without problems through routers, >> directory structures are handled more efficiently than with CVS, file > > I've not seen a compliment "stable" for any VCS. Most of them are marked > either "active developed" or "maintained but" in Wikipedia comparison: > > http://en.wikipedia.org/wiki/Comparison_of_revision_control_software I don't think "actively developed" can be read to mean "unstable". We've been using SVN for 3 years and in my experience it is very stable. If you do decide to stay with the client-server model I would definately reccommend SVN. -- 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] 12+ messages in thread
* Re: [ECOS] Looking in a future: VCS for eCos 3.0 2008-08-29 15:02 ` Jonathan Larmour 2008-08-29 16:08 ` Sergei Gavrikov @ 2008-12-05 1:09 ` Sergei Gavrikov 1 sibling, 0 replies; 12+ messages in thread From: Sergei Gavrikov @ 2008-12-05 1:09 UTC (permalink / raw) To: Jonathan Larmour; +Cc: eCos discuss list On Fri, Aug 29, 2008 at 02:55:21PM +0100, Jonathan Larmour wrote: > A switch of VCS is probably something to tackle very soon after eCos 3.0 > rather than before. I agree that it's time to move forward from CVS. > > I've had a look at Bazaar and would need a bit of convincing personally, at > the least at this stage of its development. I found this an interesting > read: > http://sayspy.blogspot.com/2006/11/bazaar-vs-mercurial-unscientific.html > (including the comments). I'm still more inclined towards Mercurial, > although SVN is an obvious possibility just really due to its more > widespread use and slightly better client support (in addition both of > which are available on sourceware.org, but Bazaar isn't). But I'd really > really prefer to have something distributed. Hello Just FYI: Mercurial 1.1 released 2008-12-2. How they said, This is a larger feature release. http://www.selenic.com/mercurial/wiki/index.cgi/WhatsNew Sergei > When the time comes, we can see what it looks like then. The decision isn't > just mine of course. > > Jifl -- 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] 12+ messages in thread
[parent not found: <2a3305fe0809110931p4fcc42b1sffb0cc51a9e7c25b@mail.gmail.com>]
* Re: [ECOS] Looking in a future: VCS for eCos 3.0 [not found] ` <2a3305fe0809110931p4fcc42b1sffb0cc51a9e7c25b@mail.gmail.com> @ 2008-09-11 16:34 ` Mike Arthur 0 siblings, 0 replies; 12+ messages in thread From: Mike Arthur @ 2008-09-11 16:34 UTC (permalink / raw) To: ecos-discuss My vote is SVN. SVK might be worth a look: http://svk.bestpractical.com/view/HomePage Mike -- 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] 12+ messages in thread
end of thread, other threads:[~2008-12-04 17:39 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-08-28 2:37 [ECOS] Looking in a future: VCS for eCos 3.0 Sergei Gavrikov 2008-08-29 15:02 ` Jonathan Larmour 2008-08-29 16:08 ` Sergei Gavrikov 2008-08-30 5:31 ` srinivas naga vutukuri 2008-09-01 9:14 ` Marcos Del Puerto 2008-09-01 14:24 ` [ECOS] " Grant Edwards 2008-09-01 15:25 ` Marcos Del Puerto 2008-09-01 15:42 ` Frank Pagliughi 2008-09-01 16:56 ` [ECOS] " Sergei Gavrikov 2008-09-02 16:28 ` [ECOS] " Dave Lawrence 2008-12-05 1:09 ` [ECOS] " Sergei Gavrikov [not found] ` <2a3305fe0809110931p4fcc42b1sffb0cc51a9e7c25b@mail.gmail.com> 2008-09-11 16:34 ` Mike Arthur
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).