From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7842 invoked by alias); 1 Sep 2008 16:56:28 -0000 Received: (qmail 7832 invoked by uid 22791); 1 Sep 2008 16:56:27 -0000 X-Spam-Check-By: sourceware.org Received: from ey-out-1920.google.com (HELO ey-out-1920.google.com) (74.125.78.146) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 01 Sep 2008 16:55:27 +0000 Received: by ey-out-1920.google.com with SMTP id 4so741728eyg.24 for ; Mon, 01 Sep 2008 09:55:23 -0700 (PDT) Received: by 10.210.124.8 with SMTP id w8mr6748024ebc.194.1220288123344; Mon, 01 Sep 2008 09:55:23 -0700 (PDT) Received: from smtp.gmail.com ( [86.57.205.220]) by mx.google.com with ESMTPS id c22sm7254775ika.1.2008.09.01.09.55.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Sep 2008 09:55:22 -0700 (PDT) Date: Mon, 01 Sep 2008 16:56:00 -0000 From: Sergei Gavrikov To: Marcos Del Puerto Cc: ecos-discuss@ecos.sourceware.org Message-ID: <20080901165527.GA7801@ubuntu.local> References: <20080827145131.GA12261@ubuntu.local> <48B7FFC9.7040605@eCosCentric.com> <20080829160552.GA23722@ubuntu.local> <270dc33e0809010213g5bb73581h4e2b1db26adb7fb6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <270dc33e0809010213g5bb73581h4e2b1db26adb7fb6@mail.gmail.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) 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/msg00017.txt.bz2 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: 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. 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