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
