[ECOS] Looking in a future: VCS for eCos 3.0

[ECOS] Looking in a future: VCS for eCos 3.0

[Sergei Gavrikov]

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

* Support for Microsoft Vista within the eCos host tools

Is it possible would you/we look on one multi-platform VCS? There is
such a Distributed VCS there. I talk about Bazaar http://bazaar-vcs.org/
There are a few nice and _short_ intros on it's frontpage.

Why the bazaar? At first, because the eCos FAQ did mention about :-)
http://ecos.sourceware.org/fom/ecos?_recurse=1&file=1#file_44 It is a
joke. Bazaar is young project and it seemed for me, it will be have a
good future, because, it is a Multi-platform and FREE VCS.

Most of the Windows users hate CLI, and you gave them eCos `configtool',
I remember about CLI magic on http://ecos.sourceware.org/anoncvs.html,
Bazaar developers offer a windows standalone installer and it is easy to
integrate the bazaar in windows explorer using Tortoise, for example:
http://bazaar-vcs.org/TortoiseBzr. (CLI guys can do no panic, bzr has
same CLI syntax as git or svn has).

Today, 2 main issues of bzr are known. The bazaar a bit more _slow_ than
git or hg, the bazaar is _young_ and less known than other (elder VCS)
http://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities
I can add third one, We have Tcl/Tk, we will have yet Python :-) But,
who knows... Should we look in a future?

Thanks,

    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

Re: [ECOS] Looking in a future: VCS for eCos 3.0

[Jonathan Larmour]

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.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Looking in a future: VCS for eCos 3.0

[Sergei Gavrikov]

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

Re: [ECOS] Looking in a future: VCS for eCos 3.0

[srinivas naga vutukuri]

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
<sergei.gavrikov@gmail.com> 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

Re: [ECOS] Looking in a future: VCS for eCos 3.0

[Marcos Del Puerto]

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
<srinivas.vutukuri@gmail.com> 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
> <sergei.gavrikov@gmail.com> 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

[ECOS] Re: Looking in a future: VCS for eCos 3.0

[Grant Edwards]

On 2008-09-01, Marcos Del Puerto <mpuertog@gmail.com> wrote:

> Of course that eCos centric has to choose the VCS that best
> fits their likes and requirements,

Why do you say that?  eCos does not belong to eCosCentric.

> but does eCos really need a distributed VCS?

Yes.

> 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?

Yes, there are developers outside eCosCentric.

> Has eCos centric outsourced parts of the development kernel to
> other companies?

You seem to be under the impression that eCos is the property
of eCosCentric.  The FSF holds the copyrights to eCos, and some
development goes on outside of eCosCentric.

I'd probably vote for Subversion, except for the fact that
Subversion is what we use internally.  Since subversion treats
the CVS directory and its contents as normal files, it's rather
handy the way it is.  I can check out a source tree from CVS
and then check it into Subversion (CVS directories and all).
Merging in changes from the "official" tree is simply a
matter of doing a "cvs update" followed by an "svn commit".
At any time I can do either a "cvs diff" or an "svn diff".

Still, if the consensus was to move to Subversion for eCos, I
wouldn't complain.

-- 
Grant




-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Looking in a future: VCS for eCos 3.0

[Marcos Del Puerto]

Sorry. I know eCos Pro is not the same as eCos. I knew that the FSF
was the copyright holder of eCos but I couldn't  find any reference to
eCos in RedHat or at the FSF page more recent than 2004.

Given that:
* John Dallaway is the eCos 3.0 release manager,
* ecos is an eCos centric's registered trademark
* The future version release announcement  "...and it is time to push
forward with our plans for a new release of eCos"
* And announcements like Ahttp one in ecosforge: "While we're waiting
for the paperwork to clear in the official eCos repository we merge
changes here."  and ecosforge's about section

I believed (mistakenly) that when he said "we" he meant the company
and that its development was mainly centralized in it (at least as far
as the CVS commits are concerned).

Best regards,
Marcos del Puerto

On Mon, Sep 1, 2008 at 4:23 PM, Grant Edwards <grante@visi.com> wrote:
> On 2008-09-01, Marcos Del Puerto <mpuertog@gmail.com> wrote:
>
>> Of course that eCos centric has to choose the VCS that best
>> fits their likes and requirements,
>
> Why do you say that?  eCos does not belong to eCosCentric.
>
>> but does eCos really need a distributed VCS?
>
> Yes.
>
>> 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?
>
> Yes, there are developers outside eCosCentric.
>
>> Has eCos centric outsourced parts of the development kernel to
>> other companies?
>
> You seem to be under the impression that eCos is the property
> of eCosCentric.  The FSF holds the copyrights to eCos, and some
> development goes on outside of eCosCentric.
>
> I'd probably vote for Subversion, except for the fact that
> Subversion is what we use internally.  Since subversion treats
> the CVS directory and its contents as normal files, it's rather
> handy the way it is.  I can check out a source tree from CVS
> and then check it into Subversion (CVS directories and all).
> Merging in changes from the "official" tree is simply a
> matter of doing a "cvs update" followed by an "svn commit".
> At any time I can do either a "cvs diff" or an "svn diff".
>
> Still, if the consensus was to move to Subversion for eCos, I
> wouldn't complain.
>
> --
> Grant
>
>
>
>
> --
> 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

Re: [ECOS] Re: Looking in a future: VCS for eCos 3.0

[Frank Pagliughi]

One thing to consider, as well, is the planned development & release 
cycle going forward. Will eCos go back to a periodic, stable release 
cycle (where the source-controlled code is considered relatively 
unstable), or continue with occasional major releases, where most people 
access the head of the development tree? I ask, because I would like to 
see a way that we could provide for multiple developers to collaborate 
on a new feature, or a way to distribute an "experimental" package for 
test and comment before committing it to the main trunk.

Currently, it can get difficult e-mailing patches back and forth, and 
this is exactly the problem that source control systems solved for us.

Frank

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Looking in a future: VCS for eCos 3.0

[Sergei Gavrikov]

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

[ECOS] Re: Looking in a future: VCS for eCos 3.0

[Dave Lawrence]

[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

I don't think "actively developed" can be read to mean "unstable".
We've been using SVN for 3 years and in my experience it is very stable.
If you do decide to stay with the client-server model I would definately
reccommend SVN.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Looking in a future: VCS for eCos 3.0

[Mike Arthur]

My vote is SVN.  SVK might be worth a look:
http://svk.bestpractical.com/view/HomePage

Mike

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Looking in a future: VCS for eCos 3.0

[Sergei Gavrikov]

On Fri, Aug 29, 2008 at 02:55:21PM +0100, Jonathan Larmour wrote:
> 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.

Hello

Just FYI: Mercurial 1.1 released 2008-12-2.  How they said, This is a
larger feature release.
http://www.selenic.com/mercurial/wiki/index.cgi/WhatsNew

Sergei

> When the time comes, we can see what it looks like then. The decision isn't
> just mine of course.
> 
> Jifl

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss