From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11366 invoked by alias); 1 Sep 2008 09:14:48 -0000 Received: (qmail 11356 invoked by uid 22791); 1 Sep 2008 09:14:47 -0000 X-Spam-Check-By: sourceware.org Received: from fg-out-1718.google.com (HELO fg-out-1718.google.com) (72.14.220.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 01 Sep 2008 09:13:41 +0000 Received: by fg-out-1718.google.com with SMTP id 16so1080095fgg.44 for ; Mon, 01 Sep 2008 02:13:37 -0700 (PDT) Received: by 10.103.218.19 with SMTP id v19mr4119790muq.110.1220260417584; Mon, 01 Sep 2008 02:13:37 -0700 (PDT) Received: by 10.103.165.8 with HTTP; Mon, 1 Sep 2008 02:13:37 -0700 (PDT) Message-ID: <270dc33e0809010213g5bb73581h4e2b1db26adb7fb6@mail.gmail.com> Date: Mon, 01 Sep 2008 09:14:00 -0000 From: "Marcos Del Puerto" To: ecos-discuss@ecos.sourceware.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080827145131.GA12261@ubuntu.local> <48B7FFC9.7040605@eCosCentric.com> <20080829160552.GA23722@ubuntu.local> X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Looking in a future: VCS for eCos 3.0 X-SW-Source: 2008-09/txt/msg00001.txt.bz2 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 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 > 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