This is the mail archive of the 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

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 etc
> projects) along with bzr, hg for discussion, as it also falls in the
> distributed version control tool.  one of site,
> 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
>>> > 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:
>>> (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, 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 (with the
>> comments). It is interesting to read too. Thank you for your link.
>> Sergei
>> --
>> Before posting, please read the FAQ:
>> and search the list archive:
> --
> Before posting, please read the FAQ:
> and search the list archive:

Before posting, please read the FAQ:
and search the list archive:

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