This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Looking in a future: VCS for eCos 3.0


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]