Switching to git?

Switching to git?

[Pavel Roskin]

Hello!

This is a reaction to the "BTS overhaul" post, I just don't want to
hijack the thread with a separate topic.

If someone asked me what is the project that is not using git but would
benefit from it most, I would say it's GRUB.

First and foremost, git (together with StGIT and other tools) relieves
the pressure to commit.  CVS and Subversion allow to work with only one
patch at a time.  I can have only one patch applied to the working
directory if I want to commit one of the patches safely.  There is no
support for refining series of patches.  StGIT exists precisely for
that, and even bare git is getting better at that.

Another closely related advantage is that git allows parallel
development.  Branching is built in from the beginning.  There are
unofficial forks of GRUB 1 already (such as grub4dos).  git would help
turn forks into branches, bring them under one roof and eventually allow
merging all useful features together.

Not to be overlooked it the git-bisect command.  No amount of code
review can prevent bugs, especially for software that interacts with
"black box" firmware and hardware.  Having an effective mechanism for
bug isolation is essential.

Tools for viewing history of the git repository, such as qgit, gitk and
tig have no equivalents for CVS.  And the tools for mailing series of
patches are great time savers.  git is actively developed and has a
vibrant community.  Yet it's well past the point where major
incompatibilities are routinely introduced.

Other GNU projects have switched to git.  Savannah supports git.  The
list of the GNU projects using git is pretty impressive:
http://git.sv.gnu.org/gitweb/

I think GNU GRUB would be a welcome addition.

-- 
Regards,
Pavel Roskin

Re: Switching to git?

[Otavio Salvador]

Pavel Roskin <proski@gnu.org> writes:

> Other GNU projects have switched to git.  Savannah supports git.  The
> list of the GNU projects using git is pretty impressive:
> http://git.sv.gnu.org/gitweb/
>
> I think GNU GRUB would be a welcome addition.

+1. I brought this up to discussion some time ago here but hadn't much
feedback. I hope we can move forward this time :-D

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: Switching to git?

[willem]

Otavio Salvador wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
>   
>> Other GNU projects have switched to git.  Savannah supports git.  The
>> list of the GNU projects using git is pretty impressive:
>> http://git.sv.gnu.org/gitweb/
>>
>> I think GNU GRUB would be a welcome addition.
>>     
>
> +1. I brought this up to discussion some time ago here but hadn't much
> feedback. I hope we can move forward this time :-D
>
>   
I did look at git.
I agree , git is better than svn.

regards

Re: Switching to git?

[Otavio Salvador]

willem <wli222@casema.nl> writes:

> Otavio Salvador wrote:
>> Pavel Roskin <proski@gnu.org> writes:
>>
>>   
>>> Other GNU projects have switched to git.  Savannah supports git.  The
>>> list of the GNU projects using git is pretty impressive:
>>> http://git.sv.gnu.org/gitweb/
>>>
>>> I think GNU GRUB would be a welcome addition.
>>>     
>>
>> +1. I brought this up to discussion some time ago here but hadn't much
>> feedback. I hope we can move forward this time :-D
>>
>>   
> I did look at git.
> I agree , git is better than svn.

It's much better and makes the integration work much easier to the
team too.

People can start to provide GIT trees, instead of patches, for review
and once it has been accepted, and paper work done, a single git merge
does the magic :-)

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: Switching to git?

[Vesa Jääskeläinen]

willem wrote:
> Otavio Salvador wrote:
>> Pavel Roskin <proski@gnu.org> writes:
>>> Other GNU projects have switched to git.  Savannah supports git.  The
>>> list of the GNU projects using git is pretty impressive:
>>> http://git.sv.gnu.org/gitweb/
>>>
>>> I think GNU GRUB would be a welcome addition.
>>
>> +1. I brought this up to discussion some time ago here but hadn't much
>> feedback. I hope we can move forward this time :-D
>>   
> I did look at git.
> I agree , git is better than svn.

Git indeed has some nice features, but why I would hesitate its usage is
that it does not integrate well with some IDE's like Eclipse. I know
there has been some plugin (dead now?), but that is not ready for
mainstream use. Where as CVS and SVN works nicely. If I am not mistaken,
git is quite platform dependant... at least last time I looked at it, it
was coded like it.

That being said... I am not too strongly against switching to it.

Re: Switching to git?

[Otavio Salvador]

Vesa Jääskeläinen <chaac@nic.fi> writes:

> willem wrote:
>> Otavio Salvador wrote:
>>> Pavel Roskin <proski@gnu.org> writes:
>>>> Other GNU projects have switched to git.  Savannah supports git.  The
>>>> list of the GNU projects using git is pretty impressive:
>>>> http://git.sv.gnu.org/gitweb/
>>>>
>>>> I think GNU GRUB would be a welcome addition.
>>>
>>> +1. I brought this up to discussion some time ago here but hadn't much
>>> feedback. I hope we can move forward this time :-D
>>>   
>> I did look at git.
>> I agree , git is better than svn.
>
> Git indeed has some nice features, but why I would hesitate its usage is
> that it does not integrate well with some IDE's like Eclipse. I know
> there has been some plugin (dead now?), but that is not ready for
> mainstream use. Where as CVS and SVN works nicely. If I am not mistaken,
> git is quite platform dependant... at least last time I looked at it, it
> was coded like it.
>
> That being said... I am not too strongly against switching to it.

That's why GIT has git-cvsserver so you can use plain CVS tools to
commit in a GIT repository. ;-)

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: Switching to git?

[Pavel Roskin]

Hello!

On Fri, 2007-12-07 at 23:16 -0200, Otavio Salvador wrote:
> Vesa Jääskeläinen <chaac@nic.fi> writes:

> > Git indeed has some nice features, but why I would hesitate its usage is
> > that it does not integrate well with some IDE's like Eclipse. I know
> > there has been some plugin (dead now?), but that is not ready for
> > mainstream use.

If you mean egit, it doesn't look dead to me with the last commit two
weeks ago and the last release two months ago:
http://repo.or.cz/w/egit.git

I'm not sure about the mainstream use, but projects in useless state
don't normally make releases.

> > Where as CVS and SVN works nicely. If I am not mistaken,
> > git is quite platform dependant... at least last time I looked at it, it
> > was coded like it.

Things are much better now, as far as I can tell.

> > That being said... I am not too strongly against switching to it.
> 
> That's why GIT has git-cvsserver so you can use plain CVS tools to
> commit in a GIT repository. ;-)

Yes, that may work too.  The git-cvsserver even mentions the Eclipse
plugin.  But perhaps we shouldn't enable git-cvsserver support in the
main repository.  It would be useful on local branches that get reviewed
before merging.

-- 
Regards,
Pavel Roskin

Re: Switching to git?

[willem]

Otavio Salvador wrote:
> willem <wli222@casema.nl> writes:
>
>   
>> Otavio Salvador wrote:
>>     
>>> Pavel Roskin <proski@gnu.org> writes:
>>>
>>>   
>>>       
>>>> Other GNU projects have switched to git.  Savannah supports git.  The
>>>> list of the GNU projects using git is pretty impressive:
>>>> http://git.sv.gnu.org/gitweb/
>>>>
>>>> I think GNU GRUB would be a welcome addition.
>>>>     
>>>>         
>>> +1. I brought this up to discussion some time ago here but hadn't much
>>> feedback. I hope we can move forward this time :-D
>>>
>>>   
>>>       
>> I did look at git.
>> I agree , git is better than svn.
>>     
>
> It's much better and makes the integration work much easier to the
> team too.
>
> People can start to provide GIT trees, instead of patches, for review
> and once it has been accepted, and paper work done, a single git merge
> does the magic :-)
>
>   
OOH you are very clever  :-)

Re: Switching to git?

[Robert Millan]

On Thu, Dec 06, 2007 at 12:45:48PM -0500, Pavel Roskin wrote:
> 
> Other GNU projects have switched to git.  Savannah supports git.  The
> list of the GNU projects using git is pretty impressive:
> http://git.sv.gnu.org/gitweb/

Savannah support was the main concern raised by Okuji last time a proposal
to switch away from CVS was brought up.  It's good that this is solved.

I myself have no objection.  I'd prefer svn, but that's not supported by
Savannah yet, and anything is better than CVS IMO.  In the event that we
decide to migrate to svn in the future, though, is there an easy path
from git to svn?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Switching to git?

[Otavio Salvador]

Robert Millan <rmh@aybabtu.com> writes:

> I myself have no objection.  I'd prefer svn, but that's not supported by
> Savannah yet, and anything is better than CVS IMO.  In the event that we
> decide to migrate to svn in the future, though, is there an easy path
> from git to svn?

I doubt that you'll want to come back to SVN after you get used to
GIT.

I thought it was going to be hard to learn but it was really easy and
there's a lot of documentation about it available.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: Switching to git?

[Pavel Roskin]

Quoting Robert Millan <rmh@aybabtu.com>:

> I myself have no objection.  I'd prefer svn, but that's not supported by
> Savannah yet, and anything is better than CVS IMO.  In the event that we
> decide to migrate to svn in the future, though, is there an easy path
> from git to svn?

I believe git-svn (included with git) should be able to do it.  I'm  
quite sure it would work fine for linear history, but things may be  
trickier if branches are used.

However, I think nobody would want to go from git to svn.  Alone the  
ability to work on more than one patch at once is like getting an  
extra dimension, something that very few would want to give up.

-- 
Regards,
Pavel Roskin

Re: Switching to git?

[Robert Millan]

On Wed, Dec 12, 2007 at 10:36:17AM -0500, Pavel Roskin wrote:
> Quoting Robert Millan <rmh@aybabtu.com>:
> 
> >I myself have no objection.  I'd prefer svn, but that's not supported by
> >Savannah yet, and anything is better than CVS IMO.  In the event that we
> >decide to migrate to svn in the future, though, is there an easy path
> >from git to svn?
> 
> I believe git-svn (included with git) should be able to do it.  I'm  
> quite sure it would work fine for linear history, but things may be  
> trickier if branches are used.
> 
> However, I think nobody would want to go from git to svn.  Alone the  
> ability to work on more than one patch at once is like getting an  
> extra dimension, something that very few would want to give up.

Just to make myself clear, I didn't mean to argue that we'll want to migrate
from git to svn (I have yet to build an opinion of git myself).  However,
I think it's very important that we have the option to do it in case we
want to.  Being trapped somewhere you're not fond of is, like, bad thing
you know :-)

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Switching to git?

[Amin Azez]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

* Otavio Salvador wrote, On 12/12/07 15:03:
> Robert Millan <rmh@aybabtu.com> writes:
>
>   
>> I myself have no objection.  I'd prefer svn, but that's not supported by
>> Savannah yet, and anything is better than CVS IMO.  In the event that we
>> decide to migrate to svn in the future, though, is there an easy path
>> from git to svn?
>>     
>
> I doubt that you'll want to come back to SVN after you get used to
> GIT.
>
> I thought it was going to be hard to learn but it was really easy and
> there's a lot of documentation about it available.
>
>   

Git was very hard a while ago, but the porcelain (as it is called) is
much improved.

Sam

[-- Attachment #2: Type: text/html, Size: 1120 bytes --]

Re: Switching to git?

[Robert Millan]

So it seems nobody objected.  What do we need to proceed?


On Thu, Dec 06, 2007 at 12:45:48PM -0500, Pavel Roskin wrote:
> Hello!
> 
> This is a reaction to the "BTS overhaul" post, I just don't want to
> hijack the thread with a separate topic.
> 
> If someone asked me what is the project that is not using git but would
> benefit from it most, I would say it's GRUB.
> 
> First and foremost, git (together with StGIT and other tools) relieves
> the pressure to commit.  CVS and Subversion allow to work with only one
> patch at a time.  I can have only one patch applied to the working
> directory if I want to commit one of the patches safely.  There is no
> support for refining series of patches.  StGIT exists precisely for
> that, and even bare git is getting better at that.
> 
> Another closely related advantage is that git allows parallel
> development.  Branching is built in from the beginning.  There are
> unofficial forks of GRUB 1 already (such as grub4dos).  git would help
> turn forks into branches, bring them under one roof and eventually allow
> merging all useful features together.
> 
> Not to be overlooked it the git-bisect command.  No amount of code
> review can prevent bugs, especially for software that interacts with
> "black box" firmware and hardware.  Having an effective mechanism for
> bug isolation is essential.
> 
> Tools for viewing history of the git repository, such as qgit, gitk and
> tig have no equivalents for CVS.  And the tools for mailing series of
> patches are great time savers.  git is actively developed and has a
> vibrant community.  Yet it's well past the point where major
> incompatibilities are routinely introduced.
> 
> Other GNU projects have switched to git.  Savannah supports git.  The
> list of the GNU projects using git is pretty impressive:
> http://git.sv.gnu.org/gitweb/
> 
> I think GNU GRUB would be a welcome addition.
> 
> -- 
> Regards,
> Pavel Roskin
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
> 

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Switching to git?

[Otavio Salvador]

Robert Millan <rmh@aybabtu.com> writes:

> So it seems nobody objected.  What do we need to proceed?

Prepare a file with authors names to be used during the conversion and
a run to git-cvsimport using it? :-)

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: Switching to git?

[Robert Millan]

On Sun, Dec 16, 2007 at 02:32:29AM -0200, Otavio Salvador wrote:
> Robert Millan <rmh@aybabtu.com> writes:
> 
> > So it seems nobody objected.  What do we need to proceed?
> 
> Prepare a file with authors names to be used during the conversion and
> a run to git-cvsimport using it? :-)

I mean in the context of Savannah.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Switching to git?

[Pavel Roskin]

Quoting Robert Millan <rmh@aybabtu.com>:

> On Sun, Dec 16, 2007 at 02:32:29AM -0200, Otavio Salvador wrote:
>> Robert Millan <rmh@aybabtu.com> writes:
>>
>> > So it seems nobody objected.  What do we need to proceed?
>>
>> Prepare a file with authors names to be used during the conversion and
>> a run to git-cvsimport using it? :-)
>
> I mean in the context of Savannah.

This page has the necessary information:
http://savannah.gnu.org/maintenance/UsingGit

You'll probably need to enable Git support on Savannah first (I don't  
see it mentioned, but it should be easy), just to make sure it's OK  
and you have the necessary permissions.

Next step is the conversion.  That page tells how to get the CVS  
repository from Savannah.  I would probably use git-cvsimport from the  
latest git for the conversion.  Or maybe I would try parsecvs as well  
and check the results.  It's very important to verify the repository  
with gitk and qgit.

Then push the repository to Savannah as described.  Make sure you can  
check out.  If you have anything to commit and push, check it too  
(maybe some documentation change mentioning git).  Once everything is  
working, disable CVS support for the project.

-- 
Regards,
Pavel Roskin

Re: Switching to git?

[Yoshinori K. Okuji]

On Saturday 15 December 2007 11:54, Robert Millan wrote:
> So it seems nobody objected.  What do we need to proceed?

I do object. Personally, I believe that git is inferior to other modern 
version control systems, thus I don't want to move. If we do, I prefer to go 
with something better.

Okuji

Re: Switching to git?

[Markus Elfring]

> I do object. Personally, I believe that git is inferior to other modern 
> version control systems, thus I don't want to move. If we do, I prefer to go 
> with something better.

Which features are you missing?
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

Which management software do you prefer at the moment?

Regards,
Markus

Re: Switching to git?

[Tomáš Ebenlendr]

Dne 17 Prosinec 2007, 08:02, Yoshinori K. Okuji napsal(a):
> I do object. Personally, I believe that git is inferior to other modern
> version control systems, thus I don't want to move. If we do, I prefer to
> go with something better.
>
> Okuji

Inferior? I see the disadvantage, that now it works only on unix.
But I think that Linuz had very good reasons to write git.
Git is young, but it was/is written with very deep knowledge of
development process, which is not true for other free version systems. (It
also uses ideas from BitKeeper, which is commercial, as linux developers
were using it before.) Git does not need 'server' so it is simple for
users to clone git repository and track their changes there. (This holds
not for subversion.)

I took a look on wikipedia's comparison of rcs:
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
E.g. the table 'Features' is interresting. There are very few totally
green rows, git is one of them. (mercurial is the other noncomercial green
row).

-- 

                            Tomas Ebenlendr
                            http://drak.ucw.cz/~ebik

Re: Switching to git?

[Otavio Salvador]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Saturday 15 December 2007 11:54, Robert Millan wrote:
>> So it seems nobody objected.  What do we need to proceed?
>
> I do object. Personally, I believe that git is inferior to other modern 
> version control systems, thus I don't want to move. If we do, I prefer to go 
> with something better.

Please cite the ones you think are superior so we all can discuss it.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: Switching to git?

[Markus Elfring]

> Inferior? I see the disadvantage, that now it works only on unix.

This view is incomplete.
http://en.wikipedia.org/wiki/Git_%28software%29#Portability

There might be some inconvenience so far. TortoiseSVN is nice because it works
as a shell extension for the Windows Explorer.
Trac can provide a web interface to several source control systems.

Regards,
Markus

Re: Switching to git?

[willem]

Markus Elfring wrote:
>> I do object. Personally, I believe that git is inferior to other modern 
>> version control systems, thus I don't want to move. If we do, I prefer to go 
>> with something better.
>>     
>
> Which features are you missing?
> http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
>
> Which management software do you prefer at the moment?
>
> Regards,
> Markus
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   
There are so many version control systems under active development, so 
it is hard to
choose the best one.

Re: Switching to git?

[willem]

Otavio Salvador wrote:
> "Yoshinori K. Okuji" <okuji@enbug.org> writes:
>
>   
>> On Saturday 15 December 2007 11:54, Robert Millan wrote:
>>     
>>> So it seems nobody objected.  What do we need to proceed?
>>>       
>> I do object. Personally, I believe that git is inferior to other modern 
>> version control systems, thus I don't want to move. If we do, I prefer to go 
>> with something better.
>>     
>
> Please cite the ones you think are superior so we all can discuss it.
>
>   
Sun did choose Mercurial

Re: Switching to git?

[Pavel Roskin]

Quoting willem <wli222@casema.nl>:

> Otavio Salvador wrote:
>> "Yoshinori K. Okuji" <okuji@enbug.org> writes:
>>
>>
>>> On Saturday 15 December 2007 11:54, Robert Millan wrote:
>>>
>>>> So it seems nobody objected.  What do we need to proceed?
>>>>
>>> I do object. Personally, I believe that git is inferior to other   
>>> modern version control systems, thus I don't want to move. If we   
>>> do, I prefer to go with something better.
>>>
>>
>> Please cite the ones you think are superior so we all can discuss it.
>>
>>
> Sun did choose Mercurial

We are limited by what Savannah provides, unless some other place is  
found to host the project, which would complicate things.

If there are any specific problems with git pertinent to GRUB or  
preferences of the GRUB developers, I'm ready to convey them to the  
git developers and take the blame (if any).

We don't have to look for the best tool, just for the best tool for  
this particular project and those working on it.

-- 
Regards,
Pavel Roskin

Re: Switching to git?

[Otavio Salvador]

Pavel Roskin <proski@gnu.org> writes:

> If there are any specific problems with git pertinent to GRUB or
> preferences of the GRUB developers, I'm ready to convey them to the
> git developers and take the blame (if any).

Personally I'm very happy with GIT and I'm using it in daily basis for
most of project I'm active on.

The easy merging and the wonderful workflow it allow is really
nice. Besides that, it's really active and rapidly improving.

> We don't have to look for the best tool, just for the best tool for
> this particular project and those working on it.

For me, it fits very well.

I think it's worth to cite about http://packages.debian.org/sid/mr
that allows to abstract the SCM and use a single command set for daily
uses.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: Switching to git?

[Yoshinori K. Okuji]

On Tuesday 18 December 2007 02:20, Pavel Roskin wrote:
> If there are any specific problems with git pertinent to GRUB or
> preferences of the GRUB developers, I'm ready to convey them to the
> git developers and take the blame (if any).
>
> We don't have to look for the best tool, just for the best tool for
> this particular project and those working on it.

I bet that you under-estimate the pain of migrating to another SCM. I have 
experienced such migrations twice, and they were always a pain, something 
that nobody wants to repeat.

Some reasons:

- The repository will be temporarily down (negligible in a long term).

- All developers are forced to install new software and learn it (always a 
pain).

- All local (pending) changes in working copies become very hard to merge 
(extremely painful).

- It is hard to re-select yet another SCM later, because old software is 
usually better supported for migrations, i.e. it's not cheap to migrate back 
and forth (very painful).

Since Robert was in a hurry so much, I had to stop it immediately with very 
terse words. I am sorry about that, but please do not make a haste. I have 
discussed (and objected to) possibilities to move to another SCM in the IRC, 
the mailing list, etc., but it seems that people forget my words at every 
time. It's sad to me, as I must repeat the same thing again and again.

First of all, this is not a hurry at all. CVS is far from nice, but it has 
worked well for GRUB for the past 10 years, and we haven't had any critical 
problem with it. This is because GRUB is a very simple project from the 
viewpoint of source code management.

You might be excited with technical innovations, but please don't forget that 
it costs to change things. Note that I don't mean that we should't change, 
but that we must be a bit more conservative with regard to SCM. Since we are 
not developing SCM itself, we should consider carefully pros and cons, before 
making an action.

Ok, now about the git. As Tomáš pointed out, the lack of portability is 
regression from CVS. If you think, for example, grub4dos is important, why 
can you choose git?

Besides the portability, I don't like the merging algorithm. If my knowledge 
is not completely outdated yet, git still uses 3-way merging, right? I don't 
describe the math here, as it is (a little) documented in the revctrl wiki:

http://revctrl.org/CategoryMergeAlgorithm

As long as git uses this naive algorithm, I am not willing to use it.

CVS's merging algorithm is also very simple and stupid, but it is not a big 
problem, because CVS is centralized. When getting distributed, things get far 
more complicated and critical, since there are so many corner cases where one 
cannot see in a centralized SCM.

These are the requirements for a new SCM in the context of GRUB from my point 
of view:

- Free Software (definitely!)
- Good merging algorithm (if distributed)
- Good web interface (as good as viewvc)
- Commit notification by email at the server side
- Good portability (as good as CVS)
- Ability to track changes efficiently, i.e. annotation (probably supported by 
most SCMs)
- Usable interface (not like arch)
- Good user document (like svnbook)
- No conflict in a (main) repository (not like monotone)

Other features are not so important, since GRUB is small.

Here are some examples:

- Subversion (+ svk) is good enough, if we only sometimes want to work 
offline.

- Bazaar looks good, if we believe that their claim is all correct.

Okuji

Re: Switching to git?

[Otavio Salvador]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Tuesday 18 December 2007 02:20, Pavel Roskin wrote:
>> If there are any specific problems with git pertinent to GRUB or
>> preferences of the GRUB developers, I'm ready to convey them to the
>> git developers and take the blame (if any).
>>
>> We don't have to look for the best tool, just for the best tool for
>> this particular project and those working on it.
>
> I bet that you under-estimate the pain of migrating to another SCM. I have 
> experienced such migrations twice, and they were always a pain, something 
> that nobody wants to repeat.

I experienced such migrations a lot of times and have moved projects
from:

 - CVS -> SVN
 - SVN -> Bzr
 - SVN -> GIT
 - CVS -> Darcs

And others too.

> - All developers are forced to install new software and learn it (always a 
> pain).

Developers are used (or ought to) to learn new things since it's of
programming art. I guess learning wouldn't be a problem.

> - All local (pending) changes in working copies become very hard to merge 
> (extremely painful).

Just a "cvs diff > /tmp/foo ; cd ~/newrepo ; patch -p1 < /tmp/foo"
works for most of cases and then it's not a really big problem from my POV.

> - It is hard to re-select yet another SCM later, because old software is 
> usually better supported for migrations, i.e. it's not cheap to migrate back 
> and forth (very painful).

I guess nobody wants to come back to CVS after getting out from it.

> First of all, this is not a hurry at all. CVS is far from nice, but it has 
> worked well for GRUB for the past 10 years, and we haven't had any critical 
> problem with it. This is because GRUB is a very simple project from the 
> viewpoint of source code management.

Sure it's. But all developers want to use more time working on code
then dealing with the bad merging of CVS and dealing with cvsps to
identify when something has been fixed and like.

> You might be excited with technical innovations, but please don't forget that 
> it costs to change things. Note that I don't mean that we should't change, 
> but that we must be a bit more conservative with regard to SCM. Since we are 
> not developing SCM itself, we should consider carefully pros and cons, before 
> making an action.

Agree on that. However since git does offer a CVS server this can be
reduced a lot allowing you and anyother that don't want to move to it
to stay using CVS for hacking.

> Ok, now about the git. As Tomáš pointed out, the lack of portability is 
> regression from CVS. If you think, for example, grub4dos is important, why 
> can you choose git?

Agree on that too.

It's not that bad[1] and users can use git with cygwin or via git-cvspserver.

1. http://git.or.cz/gitwiki/WindowsInstall

> Besides the portability, I don't like the merging algorithm. If my knowledge 
> is not completely outdated yet, git still uses 3-way merging, right? I don't 
> describe the math here, as it is (a little) documented in the revctrl wiki:
>
> http://revctrl.org/CategoryMergeAlgorithm
>
> As long as git uses this naive algorithm, I am not willing to use it.

While I agree that it's not the best merging algorithm I also fail to
see why it could be a blocker.

I've been using GIT for a while and I do not see conflicts very
ofthen. Linux kernel also does it and I don't see people complaining
about it.

Personally I don't like bazaar due performance problem. It's really
slow for big projects (it wouldn't be a big problem since GRUB is a
small one) and it changes its data format too ofthen.

If I'd going to choose, I'd go to GIT or Mercurial.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: Switching to git?

[Pavel Roskin]

Hello!

Quoting "Yoshinori K. Okuji" <okuji@enbug.org>:

> I bet that you under-estimate the pain of migrating to another SCM. I have
> experienced such migrations twice, and they were always a pain, something
> that nobody wants to repeat.

I went through some migrations (CVS to Subversion and CVS to git), and  
it's not a trivial task, but it's not a big deal for other developers  
who are not doing the migration.

> Some reasons:
>
> - The repository will be temporarily down (negligible in a long term).

Yes, negligible.

> - All developers are forced to install new software and learn it (always a
> pain).

We can alleviate it by switching to software that is already widely  
used, so that the time invested into learning can be used on other  
projects.  Mercusial and git are good examples, as they are used in  
many other projects.  Monotone and darcs are not so popular; learning  
them would give less benefits.

> - All local (pending) changes in working copies become very hard to merge
> (extremely painful).

Actually, the great thing about git (especially when used with StGIT)  
is that the changes can sit in the local tree without any problem.   
CVS, on the other hand, doesn't allow any organization of the local  
changes.  They can be exported to a diff file and applied to the new  
repository, perhaps as more than one patch.

> - It is hard to re-select yet another SCM later, because old software is
> usually better supported for migrations, i.e. it's not cheap to migrate back
> and forth (very painful).

That's true, but only to a degree.  Any serious contender would have  
to support migration from git.  Mercurial had it from the first months  
if not days of development.

I don't see why we would need to migrate from git.  It's good for  
Linux, which is a much bigger project.  It's under development, which  
mean that it will improve.

Speaking of CVS, since it doesn't record the changesets, migrating  
from it to anything will require some guesswork.

> Since Robert was in a hurry so much, I had to stop it immediately with very
> terse words. I am sorry about that, but please do not make a haste. I have
> discussed (and objected to) possibilities to move to another SCM in the IRC,
> the mailing list, etc., but it seems that people forget my words at every
> time. It's sad to me, as I must repeat the same thing again and again.

I didn't know that.

> First of all, this is not a hurry at all. CVS is far from nice, but it has
> worked well for GRUB for the past 10 years, and we haven't had any critical
> problem with it. This is because GRUB is a very simple project from the
> viewpoint of source code management.

The problem is, some patches need to be split into series.  For  
example, one patch prepares ground, the other makes the radical  
switch, the third carries on some simplifications that become possible.

People who learned working with patch series are annoyed by a version  
control system that doesn't provide facilities for that.

Another problem is bisecting bugs.  git makes is possible in a simple,  
effective and formal way, so that I don't have to look at the dates in  
the changelog and guess where the next test point should be.  I'm not  
aware of any other version control system providing that feature.  The  
bisecting facility is important to assure code quality.

Finally, things like grub4dos should not be forks, they should be  
branches.  This would give then a better exposure.  CVS branch support  
is pathetic, and the same applies to Subversion, although for  
different reasons.

> You might be excited with technical innovations, but please don't forget that
> it costs to change things. Note that I don't mean that we should't change,
> but that we must be a bit more conservative with regard to SCM. Since we are
> not developing SCM itself, we should consider carefully pros and cons, before
> making an action.

I see serious advantages when it comes to attracting developers,  
fixing existing bugs and improving future changes.

> Ok, now about the git. As Tomáš pointed out, the lack of portability is
> regression from CVS. If you think, for example, grub4dos is important, why
> can you choose git?

I understand you are concerned about for Windows portability, not about DOS.

git works with Cygwin, and it's not an unrealistic requirement.   
Looking at the amount of recent changes in git for things like newline  
conversion, I'm sure that they come from the developers actually  
working on Windows.  An active development community assures code  
quality and minimal bit rot.

> Besides the portability, I don't like the merging algorithm. If my knowledge
> is not completely outdated yet, git still uses 3-way merging, right? I don't
> describe the math here, as it is (a little) documented in the revctrl wiki:
>
> http://revctrl.org/CategoryMergeAlgorithm
>
> As long as git uses this naive algorithm, I am not willing to use it.

No, git uses recursive merge by default.  But I don't see why it's important.

> CVS's merging algorithm is also very simple and stupid, but it is not a big
> problem, because CVS is centralized. When getting distributed, things get far
> more complicated and critical, since there are so many corner cases where one
> cannot see in a centralized SCM.

I'm afraid I don't understand this argument.  Linux trees are merged  
all the time, and nothing particularly bad happens.  GRUB should heve  
less corener cases, not more.

> These are the requirements for a new SCM in the context of GRUB from my point
> of view:
>
> - Free Software (definitely!)
> - Good merging algorithm (if distributed)
> - Good web interface (as good as viewvc)
> - Commit notification by email at the server side
> - Good portability (as good as CVS)

All this is present in git.

> - Ability to track changes efficiently, i.e. annotation (probably   
> supported by
> most SCMs)

I don't know what it means.

> - Usable interface (not like arch)
> - Good user document (like svnbook)

git is very close, although the work is underway

> - No conflict in a (main) repository (not like monotone)

I think it's a policy issue.  In any case, I don't see it as a problem  
with git.

> Other features are not so important, since GRUB is small.
>
> Here are some examples:
>
> - Subversion (+ svk) is good enough, if we only sometimes want to work
> offline.
>
> - Bazaar looks good, if we believe that their claim is all correct.

I agree, but in both cases developers will have to learn something  
they won't be using elsewhere, unlike git.

Last time I tries svk, it was adding some useless (for other  
developers) annotations to the commit messages, so I thought it would  
be impolite to others to commit directly from svk to the main  
repository.  StGIT keeps all marks to itself.

-- 
Regards,
Pavel Roskin

Re: Switching to git?

[Vesa Jääskeläinen]

Otavio Salvador wrote:
> "Yoshinori K. Okuji" <okuji@enbug.org> writes:
>> Ok, now about the git. As Tomáš pointed out, the lack of portability is 
>> regression from CVS. If you think, for example, grub4dos is important, why 
>> can you choose git?
> 
> Agree on that too.
> 
> It's not that bad[1] and users can use git with cygwin or via git-cvspserver.
> 
> 1. http://git.or.cz/gitwiki/WindowsInstall

Just leave cygwin out of the box... thank you!

cygwin is one of the worst pieces of software that just does not work
correctly. In my point-of-view portability means that you can use
software natively on some platform and it does not include installing
emulators or such to run software (like cygwin, wine).

Re: Switching to git?

[Pavel Roskin]

On Tue, 2007-12-18 at 20:30 +0200, Vesa Jääskeläinen wrote:

> Just leave cygwin out of the box... thank you!
> 
> cygwin is one of the worst pieces of software that just does not work
> correctly.

I wonder if you have actually used the native Windows port of CVS.

>  In my point-of-view portability means that you can use
> software natively on some platform and it does not include installing
> emulators or such to run software (like cygwin, wine).

OK, I just checked grub4dos sources, and it looks like that it should be
compiled either under Linux or in Cygwin.  Look at the "build" script
written specifically for grub4dos - it's a shell script.  If the build
system was using native tools like Visual C or even MinGW, we would see
very different build scripts.

Therefore, I don't see how native Windows portability of the version
control system can be an issue for GRUB.

Speaking of Cygwin, my experience with it has been much more positive,
especially if it's installed for one specific purpose like compiling
some project (as opposed to a playground for UNIX wannabees).  I don't
think it's a requirement that is going to deter anyone from working on
GRUB.

The work on the native git is underway.  Many scripts have been replaced
with C sources.  I expect that effort to be completed before GRUB
actually needs that (i.e. before it compiles with Visual C or another
non-Cygwin Windows compiler).

And if you need any GUI, qgit is a native Windows application compiled
with Qt4.  The "Tortoise" like GUI doesn't make much sense for git, as
it's file oriented, and git is changeset oriented.  The Eclipse plugin
(egit) is available.

-- 
Regards,
Pavel Roskin

RE: Switching to git?

[Gregg C Levine]

Hello!
That comment about Cygwin is decidedly not true.

The collection is unstable as designed. It is an evolving collection of
ports based within reason on the same framework we have on Linux, and yes on
the BSD family. The big problem is what it's sitting on, and that's why it
is a moving target. The groups behind it are continuing to update and revise
the compatibility layer behind it.

I am afraid it will continue to be unstable as it continues to be evolving.

I should also add that the people behind my distribution do not like git
much either, however but they also include it. I've used it a few times. I
also do not like it much either.

I also have ambivalent feelings behind SVN and CVS. 

Both have their good points and their bad points. 

Bazaar and mercurial I am not at all fond of. 
--
Gregg C Levine hansolofalcon@worldnet.att.net
"The Force will be with you always." Obi-Wan Kenobi
  


> -----Original Message-----
> From: grub-devel-bounces+hansolofalcon=worldnet.att.net@gnu.org
[mailto:grub-devel-
> bounces+hansolofalcon=worldnet.att.net@gnu.org] On Behalf Of Vesa
Jääskeläinen
> Sent: Tuesday, December 18, 2007 1:30 PM
> To: The development of GRUB 2
> Subject: Re: Switching to git?
> 
> Otavio Salvador wrote:
> > "Yoshinori K. Okuji" <okuji@enbug.org> writes:
> >> Ok, now about the git. As TomC!E! pointed out, the lack of portability
is
> >> regression from CVS. If you think, for example, grub4dos is important,
why
> >> can you choose git?
> >
> > Agree on that too.
> >
> > It's not that bad[1] and users can use git with cygwin or via
git-cvspserver.
> >
> > 1. http://git.or.cz/gitwiki/WindowsInstall
> 
> Just leave cygwin out of the box... thank you!
> 
> cygwin is one of the worst pieces of software that just does not work
> correctly. In my point-of-view portability means that you can use
> software natively on some platform and it does not include installing
> emulators or such to run software (like cygwin, wine).

Re: Switching to git?

[Vesa Jääskeläinen]

Pavel Roskin wrote:
> On Tue, 2007-12-18 at 20:30 +0200, Vesa Jääskeläinen wrote:
> 
>> Just leave cygwin out of the box... thank you!
>>
>> cygwin is one of the worst pieces of software that just does not work
>> correctly.
> 
> I wonder if you have actually used the native Windows port of CVS.

Do you want my copy of it ? CVS is quite freely available as native
version. And what the better, CVS integrates quite nicely to Eclipse.
Same goes for Subversion too.

>>  In my point-of-view portability means that you can use
>> software natively on some platform and it does not include installing
>> emulators or such to run software (like cygwin, wine).

> Speaking of Cygwin, my experience with it has been much more positive,
> especially if it's installed for one specific purpose like compiling
> some project (as opposed to a playground for UNIX wannabees).  I don't
> think it's a requirement that is going to deter anyone from working on
> GRUB.

You answered it yourself ;) IT just doesn't work for doing multiple
things. You have to carefully keep settings in working order if you want
to use it for multiple projects. Ever tried to compile Mozilla
Thunderbird under Windows?

> And if you need any GUI, qgit is a native Windows application compiled
> with Qt4.  The "Tortoise" like GUI doesn't make much sense for git, as
> it's file oriented, and git is changeset oriented.  The Eclipse plugin
> (egit) is available.

And have you really used the egit ? Eg. how well it works and so on. I
prefer not to jump between programs... It is just awkward.

Re: Switching to git?

[Yoshinori K. Okuji]

On Tuesday 18 December 2007 13:05, Otavio Salvador wrote:
> > - All developers are forced to install new software and learn it (always
> > a pain).
>
> Developers are used (or ought to) to learn new things since it's of
> programming art. I guess learning wouldn't be a problem.

From a theoretical point of view, you're definitely right, but the reality 
looks reverse to me. For instance, look at the inability of developers to 
editors... Even if Emacs is far superior when writing GNU-style C code, vi 
users never try to learn how to use Emacs. When it comes to command-line 
utilities vs. graphical applications, the situation is even worse.

In my experience, (unfortunately) developers are too lazy to change tools. 
They change, only when they are forced or excited for some (geeky) reason. 
This includes myself.

> > - All local (pending) changes in working copies become very hard to merge
> > (extremely painful).
>
> Just a "cvs diff > /tmp/foo ; cd ~/newrepo ; patch -p1 < /tmp/foo"
> works for most of cases and then it's not a really big problem from my POV.

It is a problem. It is catastrophic, especially when an original repository is 
down.

BTW, I have 4 different working copies of GRUB locally. All of them have 
small, different changes not committed. Do you think I would be happy to deal 
with these changes with a "mostly-working" solution? If I don't see more 
benefit from migrating to another SCM, I really don't want.

> > - It is hard to re-select yet another SCM later, because old software is
> > usually better supported for migrations, i.e. it's not cheap to migrate
> > back and forth (very painful).
>
> I guess nobody wants to come back to CVS after getting out from it.

You need it, if a new SCM does not have a converter directly.

> Agree on that. However since git does offer a CVS server this can be
> reduced a lot allowing you and anyother that don't want to move to it
> to stay using CVS for hacking.

This is nice.

> > Ok, now about the git. As Tomáš pointed out, the lack of portability is
> > regression from CVS. If you think, for example, grub4dos is important,
> > why can you choose git?
>
> Agree on that too.
>
> It's not that bad[1] and users can use git with cygwin or via
> git-cvspserver.
>
> 1. http://git.or.cz/gitwiki/WindowsInstall

I can't say if it is good or not, since I myself does not use Windows at all 
these days. I leave the evaluation to someone who uses Windows every day.

> While I agree that it's not the best merging algorithm I also fail to
> see why it could be a blocker.
>
> I've been using GIT for a while and I do not see conflicts very
> ofthen. Linux kernel also does it and I don't see people complaining
> about it.

The problem is not conflicts but merging. Usually, people don't understand the 
importance, until they get weird merging results, and spend several days only 
to fix up wrong results. However, if you notice a merging problem, you are 
still lucky; in particular when you merge big changes, it is not easy to see 
how merging went well. Sometimes, having conflicts is much better, because 
you obtain a chance to see what your SCM thinks. When merging is done 
silently, and it is wrong, the effort on finding mistakes is tremendous.

> Personally I don't like bazaar due performance problem. It's really
> slow for big projects (it wouldn't be a big problem since GRUB is a
> small one) and it changes its data format too ofthen.

Hmm, I thought they have fixed the performance issues already? About the data 
format, I have no idea. jbailey, do you have any comment? ;)

>
> If I'd going to choose, I'd go to GIT or Mercurial.

Mercurial is not bad, except for the 3-way merging.

Okuji

Re: Switching to git?

[Yoshinori K. Okuji]

On Tuesday 18 December 2007 17:29, Pavel Roskin wrote:
> We can alleviate it by switching to software that is already widely
> used, so that the time invested into learning can be used on other
> projects.  Mercusial and git are good examples, as they are used in
> many other projects.  Monotone and darcs are not so popular; learning
> them would give less benefits.

I don't admit that git is popular, personally. It is famous only among Linux 
fans. If we talk about popularity, CVS and Subversion outperform. Everything 
else is not popular enough to expect that one already has some experience or 
can reuse experience with something else.

> Actually, the great thing about git (especially when used with StGIT)
> is that the changes can sit in the local tree without any problem.
> CVS, on the other hand, doesn't allow any organization of the local
> changes.  They can be exported to a diff file and applied to the new
> repository, perhaps as more than one patch.

This is about git itself. I was talking about remaining changes against the 
CVS repository.

> I don't see why we would need to migrate from git.  It's good for
> Linux, which is a much bigger project.  It's under development, which
> mean that it will improve.

Much bigger does not mean that it is suitable for everything, as well as 
supercomputer does not fit into mobile usage.

Please note that Linux has been developed in a very weird way for a long time. 
For many, many years, Linus refused to use any kind of SCM, but he used a 
different kind of SCM, named Alan Cox. Since Alan did many clever things 
autonomously, like choosing a subset of patch set, on-the-fly merging, etc., 
their usage pattern of git is still very much affected by the development 
model in the early days.

You can see a lot of other differences as well. For example, GRUB uses 
autoconf. Linux does not. This has a good reason, as the configuration of 
Linux is involved with many dependencies, and it is not easy to track such a 
graph with autoconf. But this does not mean anything like GRUB shouldn't use 
autoconf.

> The problem is, some patches need to be split into series.  For
> example, one patch prepares ground, the other makes the radical
> switch, the third carries on some simplifications that become possible.
>
> People who learned working with patch series are annoyed by a version
> control system that doesn't provide facilities for that.
>
> Another problem is bisecting bugs.  git makes is possible in a simple,
> effective and formal way, so that I don't have to look at the dates in
> the changelog and guess where the next test point should be.  I'm not
> aware of any other version control system providing that feature.  The
> bisecting facility is important to assure code quality.
>
> Finally, things like grub4dos should not be forks, they should be
> branches.  This would give then a better exposure.  CVS branch support
> is pathetic, and the same applies to Subversion, although for
> different reasons.

Sure.

> > You might be excited with technical innovations, but please don't forget
> > that it costs to change things. Note that I don't mean that we should't
> > change, but that we must be a bit more conservative with regard to SCM.
> > Since we are not developing SCM itself, we should consider carefully pros
> > and cons, before making an action.
>
> I see serious advantages when it comes to attracting developers,
> fixing existing bugs and improving future changes.

It's difficult to answer. In my case, it is the most important that I have a 
tool in my computer to check out a working copy, and I know how to use it 
already. Otherwise, I tend to just give up. (In fact, I never try to 
contribute to a project which uses darcs...)

> > Ok, now about the git. As Tomáš pointed out, the lack of portability is
> > regression from CVS. If you think, for example, grub4dos is important,
> > why can you choose git?
>
> I understand you are concerned about for Windows portability, not about
> DOS.

:)

> No, git uses recursive merge by default.  But I don't see why it's
> important.

It's interesting to know. Thank you very much. Do you have any pointer to 
learn their algorithm for more details?

> > - Free Software (definitely!)
> > - Good merging algorithm (if distributed)
> > - Good web interface (as good as viewvc)
> > - Commit notification by email at the server side
> > - Good portability (as good as CVS)
>
> All this is present in git.

When coming to good web interface, I feel that gitweb is so difficult to 
understand... For now, the only "acceptable" ones are viewvc and websvn for 
me.

> > - Ability to track changes efficiently, i.e. annotation (probably
> > supported by
> > most SCMs)
>
> I don't know what it means.

cvs annotate, svn blame, like that.

> > - Usable interface (not like arch)
> > - Good user document (like svnbook)
>
> git is very close, although the work is underway
>
> > - No conflict in a (main) repository (not like monotone)
>
> I think it's a policy issue.  In any case, I don't see it as a problem
> with git.

I simply don't know if git supports this policy.

> I agree, but in both cases developers will have to learn something
> they won't be using elsewhere, unlike git.

Again, git is not that popular.

> Last time I tries svk, it was adding some useless (for other
> developers) annotations to the commit messages, so I thought it would
> be impolite to others to commit directly from svk to the main
> repository.  StGIT keeps all marks to itself.

Right.

Okuji

Re: Switching to git?

[Robert Millan]

On Sat, Dec 22, 2007 at 09:28:28AM +0100, Yoshinori K. Okuji wrote:
> On Tuesday 18 December 2007 13:05, Otavio Salvador wrote:
> > > - All developers are forced to install new software and learn it (always
> > > a pain).
> >
> > Developers are used (or ought to) to learn new things since it's of
> > programming art. I guess learning wouldn't be a problem.
> 
> From a theoretical point of view, you're definitely right, but the reality 
> looks reverse to me. For instance, look at the inability of developers to 
> editors... Even if Emacs is far superior when writing GNU-style C code, vi 
> users never try to learn how to use Emacs. When it comes to command-line 
> utilities vs. graphical applications, the situation is even worse.
> 
> In my experience, (unfortunately) developers are too lazy to change tools. 
> They change, only when they are forced or excited for some (geeky) reason. 
> This includes myself.

Maybe you find interesting to know that I never use RCS (any of them) merging
feature at all.  I prefer to extract patches from RCS and manage them myself.
I often even manage branches by hand as well.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Switching to git?

[Robert Millan]

On Sat, Dec 22, 2007 at 09:50:50AM +0100, Yoshinori K. Okuji wrote:
> > Finally, things like grub4dos should not be forks, they should be
> > branches.  This would give then a better exposure.  CVS branch support
> > is pathetic, and the same applies to Subversion, although for
> > different reasons.

What's wrong with Subversion branching ?  Or did you mean merging?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Switching to git?

[Yoshinori K. Okuji]

On Saturday 22 December 2007 12:20, Robert Millan wrote:
> On Sat, Dec 22, 2007 at 09:50:50AM +0100, Yoshinori K. Okuji wrote:
> > > Finally, things like grub4dos should not be forks, they should be
> > > branches.  This would give then a better exposure.  CVS branch support
> > > is pathetic, and the same applies to Subversion, although for
> > > different reasons.
>
> What's wrong with Subversion branching ?  Or did you mean merging?

Subversion's branches are as stupid as CVS's, because they don't remember what 
have been merged by themselves.

Okuji

Re: Switching to git?

[Pavel Roskin]

Quoting Robert Millan <rmh@aybabtu.com>:

> Maybe you find interesting to know that I never use RCS (any of them) merging
> feature at all.  I prefer to extract patches from RCS and manage them myself.
> I often even manage branches by hand as well.

Just to clear any misunderstanding, extracting a patch and applying to  
another file is still merging.  Unlike the 3-way merge, the patch  
command won't generate a merged file with conflicts that require  
manual editing.  But more trivial kinds of merging will happen is the  
patch command considers it safe.  Applying a patch cleanly doesn't  
guarantee that the resulting file will compile and/or work properly.

Some bugs caused by merging can be avoided like other bugs, i.e. by  
using sane programming and testing practices.  Some bugs just need to  
be tracked down.  That's just a fact of life.  For instance, some code  
could be duplicated in one branch and fixed in another, resulting in  
one copy being unfixed.  A patch could introduce a call to a function  
that changed its semantic after the base revision of the patch.  Both  
can be prevented, but only to a degree.

-- 
Regards,
Pavel Roskin

Re: Switching to git?

[Jeroen Dekkers]

At Sat, 22 Dec 2007 09:28:28 +0100,
Yoshinori K. Okuji wrote:
> 
> On Tuesday 18 December 2007 13:05, Otavio Salvador wrote:
> > Personally I don't like bazaar due performance problem. It's really
> > slow for big projects (it wouldn't be a big problem since GRUB is a
> > small one) and it changes its data format too ofthen.
> 
> Hmm, I thought they have fixed the performance issues already? About the data 
> format, I have no idea. jbailey, do you have any comment? ;)

I've used bzr when working on my summer of code project 1.5 years ago
and didn't have any issues with performance. And this was before they
did all the performance improvements. Maybe with big source trees like
Linux it's still too slow, but for GRUB this is really no problem.

The changes in data format shouldn't really be any problem in
practice, because newer versions can still read the older disk format
and the network protocol doesn't change most of the time.


Jeroen Dekkers

Re: Switching to git?

[Otavio Salvador]

Jeroen Dekkers <jeroen@vrijschrift.org> writes:

> At Sat, 22 Dec 2007 09:28:28 +0100,
> Yoshinori K. Okuji wrote:
>> 
>> On Tuesday 18 December 2007 13:05, Otavio Salvador wrote:
>> > Personally I don't like bazaar due performance problem. It's really
>> > slow for big projects (it wouldn't be a big problem since GRUB is a
>> > small one) and it changes its data format too ofthen.
>> 
>> Hmm, I thought they have fixed the performance issues already? About the data 
>> format, I have no idea. jbailey, do you have any comment? ;)
>
> I've used bzr when working on my summer of code project 1.5 years ago
> and didn't have any issues with performance. And this was before they
> did all the performance improvements. Maybe with big source trees like
> Linux it's still too slow, but for GRUB this is really no problem.

I'm not talking about working locally (looks like this is what you've
done) but pulling and pushing changes remotely.

> The changes in data format shouldn't really be any problem in
> practice, because newer versions can still read the older disk format
> and the network protocol doesn't change most of the time.

I think it's. If you want to gain their performance improvements you
_need_ to upgrade. So _all_ people involved will need to have the need
version installed too.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."