Re: [ECOS] eCos VCS switch

Re: [ECOS] eCos VCS switch

[Alex Schuilenburg]

[Apologies to Daniel for the repost - my original email to ecos-discuss
was bounced]

Daniel Néri wrote on 2009-09-17 15:01:
> Alex Schuilenburg <alexs@ecoscentric.com> writes:
>
>   
>> I cannot speak for these tools, other than to say I have tried to
>> import our internal CVS repository and anoncvs into all three and not
>> one of them worked. git did the worst job, followed by bazaar then
>> mercurial. And yes, I have tried cvs2svn to go via svn as well :-(
>>     
>
> I've been tracking the eCos anoncvs using Mercurial for more than 3
> years. At first I was using Tailor for conversion, but I'm currently
> using the bundled "convert" extension.
>
> The main problem for me was always the somewhat strange "grafting" of
> the 'net' sub-directory into 'packages' using CVS module magic. I worked
> around that by converting 'net' and 'packages' into separate Mercurial
> repositories which I then merge (i.e. "hg merge -f") to make my own
> working repository.
>   
Unsurprisingly, this was also the first problem I encountered using the
hg convert extension.

The next problem was exactly how faithfully you wanted to make the
conversion.  Unfortunately, the hg convert's version of cvsps is pretty
basic and will fail on all but the simplest of repositories.  Hence I
had to switch, eventually, the the 2.2beta of cvsps proper. Also, use
cvs admin in earnest once and you can kiss goodbye any chances of a
faithful reproduction without manual fixes. 

In addition, the early version of cvs used in the anoncvs repository
never handled files being introduced on a branch properly, so when you
checkout against specific dates, you get unexpected results on the trunk :-(


> A switch of the public CVS repository to Mercurial would be a major
> improvement.
>   
Agreed.  My initial findings are also that mercurial is the preferred
solution.  It is not as powerful as git, or even as fast, but it is
easier to work with and has better documentation.  Besides, the speed
differences were not that great (just google and you can get 100's of
independent comparisons), and I would rather not trip over the rope. 
IMHO, nothing we do in eCos development warrants the use of git over
that of mercurial (or bazaar).  90% of the features of git probably
would not be used, even once you figured them out ;-)

-- Alex Schuilenburg

   >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
   >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

          **** Visit us at ESC-UK  http://www.embedded.co.uk ****
          **** Oct 7-8 on Stand 433 at FIVE ISC, Farnborough ****



-- 
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] eCos VCS switch

[Jonathan Larmour]

Alex Schuilenburg wrote:
> 
>>A switch of the public CVS repository to Mercurial would be a major
>>improvement.
>>  
> 
> Agreed.  My initial findings are also that mercurial is the preferred
> solution.  It is not as powerful as git, or even as fast,

By "more powerful", do you mean git allows you to do anything of 
significance that hg/bzr doesn't? I didn't think there was from my own 
checking, but I'm prepared to be corrected.

Or by any chance do you mean that it's more powerful/fast if you have the 
ability to remember which of the gazillion different git commands to use 
with precisely which set of arcane options. Then it's a speedy one-liner!

Personally I would need a lot of convincing to use git. Or more precisely, 
to make the eCos community with its breadth of users with varying 
experience do so. I think it would raise the bar to using eCos in a very 
negative way.

The only thing that might ameliorate it would be something like 
http://code.google.com/p/tortoisegit/ but it seems like early days for 
that, I'm not impressed by their webpage, it seems to have restricted 
capabilities (but I may well be wrong on this count), and at best it's 
playing catch-up with the others.

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- 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] eCos VCS switch

[Alex Schuilenburg]

Jonathan Larmour wrote:
> Alex Schuilenburg wrote:
>>
>>> A switch of the public CVS repository to Mercurial would be a major
>>> improvement.
>>>  
>>
>> Agreed.  My initial findings are also that mercurial is the preferred
>> solution.  It is not as powerful as git, or even as fast,
>
> By "more powerful", do you mean git allows you to do anything of
> significance that hg/bzr doesn't? I didn't think there was from my own
> checking, but I'm prepared to be corrected.
>
> Or by any chance do you mean that it's more powerful/fast if you have
> the ability to remember which of the gazillion different git commands
> to use with precisely which set of arcane options. Then it's a speedy
> one-liner!
Neither. Some complex jobs may take a couple of commands in hg, but a
single command may exist in git to do that job.  That kind of "more
powerful".  Certainly there is nothing I have seen that you cannot do in
hg that you can in git.

As for the gazillion commands, I agree with your sentiments. However, I
have seen git users defend this by saying that the same exists of hg,
only you type hg before the command.  hg extensions are a simple example
:-)  However, hg help is a lot easier than "now what command was it to
..." 

>
> Personally I would need a lot of convincing to use git. Or more
> precisely, to make the eCos community with its breadth of users with
> varying experience do so. I think it would raise the bar to using eCos
> in a very negative way.
>
> The only thing that might ameliorate it would be something like
> http://code.google.com/p/tortoisegit/ but it seems like early days for
> that, I'm not impressed by their webpage, it seems to have restricted
> capabilities (but I may well be wrong on this count), and at best it's
> playing catch-up with the others.
I agree.  The learning curve of git is very steep which IMHO will just
get in the way of development and ease of use for the average user.  hg
have a simple set which is close to CVS anyway, so there is an ease and
familiarity of use for CVS users using hg.  I also strongly recommend
the hg book "Mercurial: The Definitive Guide" since it has a well
written explanation that helps those entrenched with CVS and SVN models
to get their head around the distributed RCS model.  Available online at
http://hgbook.red-bean.com/ and most decent bookstores.  I have found no
equivalent for git or bazaar.

We could always wait for something better to come along - this is
software, so something normally does - but then we would wait forever
and stay with an 80's RCS while the rest of the world progress.

-- Alex Schuilenburg

   >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
   >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

          **** Visit us at ESC-UK  http://www.embedded.co.uk ****
          **** Oct 7-8 on Stand 433 at FIVE ISC, Farnborough ****


-- 
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: eCos VCS switch

[Sergei Organov]

Jonathan Larmour <jifl@jifvik.org> writes:

[...]

> Personally I would need a lot of convincing to use git. Or more
> precisely, to make the eCos community with its breadth of users with
> varying experience do so. I think it would raise the bar to using eCos
> in a very negative way.

Then just go with mercurial or bazaar for now, as all they are still so
much better than CVS anyway.

And then, in 2--3 years, after a taste in DVCS evolves, it will be much
easier to finally switch to git ;-)

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

[ECOS] Re: eCos VCS switch

[Sergei Organov]

Jonathan Larmour <jifl@jifvik.org> writes:

> Alex Schuilenburg wrote:
>>
>>>A switch of the public CVS repository to Mercurial would be a major
>>>improvement.
>>>  
>>
>> Agreed.  My initial findings are also that mercurial is the preferred
>> solution.  It is not as powerful as git, or even as fast,
>
> By "more powerful", do you mean git allows you to do anything of
> significance that hg/bzr doesn't? I didn't think there was from my own
> checking, but I'm prepared to be corrected.

git rebase

is my favorite and is very handy to maintain changes w.r.t official
repository to be then contributed back. BTW, rebasing is what CVS
actually does with your local changes when you do 'cvs update'. Except
git rebase is much more safe and convenient. I can't tell if hg or bzr
already have something similar though as they seem to borrow features
from each other rather quickly.

My personal order of preference is: git, hg, bzr. But once again, the
differences between those 3 are minor compared to advantages any of them
has compared to CVS ;-)

-- 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] Re: eCos VCS switch

[Alex Schuilenburg]

Sergei Organov wrote on 2009-09-18 11:40:
> Jonathan Larmour <jifl@jifvik.org> writes:
>
>   
>> Alex Schuilenburg wrote:
>>     
>>>> A switch of the public CVS repository to Mercurial would be a major
>>>> improvement.
>>>>  
>>>>         
>>> Agreed.  My initial findings are also that mercurial is the preferred
>>> solution.  It is not as powerful as git, or even as fast,
>>>       
>> By "more powerful", do you mean git allows you to do anything of
>> significance that hg/bzr doesn't? I didn't think there was from my own
>> checking, but I'm prepared to be corrected.
>>     
>
> git rebase
>
> is my favorite and is very handy to maintain changes w.r.t official
> repository to be then contributed back. BTW, rebasing is what CVS
> actually does with your local changes when you do 'cvs update'. Except
> git rebase is much more safe and convenient. I can't tell if hg or bzr
> already have something similar though as they seem to borrow features
> from each other rather quickly.
>   

hg rebase [--source rev | --base rev] [--dest rev] | [--collapse] | [--continue] | [--abort] | [--keep]


The rebase extension is distributed as part of the standard mercurial
release :-)

As I said, I have not found any additional functionality provided by git
that you cannot do in mercurial ;-)

My favourite hg extension is forest which allows you to create a single
repository consisting of several other repositories, kind of like CVS
modules. In other words, you can work with all the repositories, or just
with subsets.  This means that multiple changes can be push/pulled
into/from multiple repositories, using a single standard hg push/pull
commands, as well as all the usual hg commands and functionality.  I
have not heard of equivalent functionality in git ;-)

-- Alex Schuilenburg

   >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
   >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

          **** Visit us at ESC-UK  http://www.embedded.co.uk ****
          **** Oct 7-8 on Stand 433 at FIVE ISC, Farnborough ****



-- 
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: eCos VCS switch

[Daniel Néri]

Alex Schuilenburg <alexs@ecoscentric.com> writes:

> My favourite hg extension is forest which allows you to create a single
> repository consisting of several other repositories, kind of like CVS
> modules.

Note that Mercurial version 1.3 includes an experimental subrepository
core feature. This might eventually make the forest extension obsolete.

  http://mercurial.selenic.com/wiki/subrepos

> In other words, you can work with all the repositories, or just with
> subsets. This means that multiple changes can be push/pulled into/from
> multiple repositories, using a single standard hg push/pull commands,
> as well as all the usual hg commands and functionality. I have not
> heard of equivalent functionality in git ;-)

Git has submodules, which is a similar feature.


Regards,
Daniel


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