Re: Switching to git?

2008-01-04 Thread 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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2008-01-04 Thread Otavio Salvador
Jeroen Dekkers [EMAIL PROTECTED] 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 OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-22 Thread 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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-22 Thread 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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-22 Thread 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 /.)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-22 Thread Pavel Roskin

Quoting Robert Millan [EMAIL PROTECTED]:


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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-21 Thread 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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-18 Thread Otavio Salvador
Yoshinori K. Okuji [EMAIL PROTECTED] 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 OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-18 Thread Pavel Roskin

Hello!

Quoting Yoshinori K. Okuji [EMAIL PROTECTED]:


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.



Re: Switching to git?

2007-12-18 Thread Vesa Jääskeläinen
Otavio Salvador wrote:
 Yoshinori K. Okuji [EMAIL PROTECTED] 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).



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-18 Thread 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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


RE: Switching to git?

2007-12-18 Thread 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 [EMAIL PROTECTED]
The Force will be with you always. Obi-Wan Kenobi
  


 -Original Message-
 From: [EMAIL PROTECTED]
[mailto:grub-devel-
 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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).



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-17 Thread 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



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-17 Thread Otavio Salvador
Yoshinori K. Okuji [EMAIL PROTECTED] 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 OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-17 Thread 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



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-17 Thread 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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-17 Thread willem

Otavio Salvador wrote:

Yoshinori K. Okuji [EMAIL PROTECTED] 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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-17 Thread Pavel Roskin

Quoting willem [EMAIL PROTECTED]:


Otavio Salvador wrote:

Yoshinori K. Okuji [EMAIL PROTECTED] 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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-17 Thread Otavio Salvador
Pavel Roskin [EMAIL PROTECTED] 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 OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-17 Thread 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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-16 Thread Robert Millan
On Sun, Dec 16, 2007 at 02:32:29AM -0200, Otavio Salvador wrote:
 Robert Millan [EMAIL PROTECTED] 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 /.)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-16 Thread Pavel Roskin

Quoting Robert Millan [EMAIL PROTECTED]:


On Sun, Dec 16, 2007 at 02:32:29AM -0200, Otavio Salvador wrote:

Robert Millan [EMAIL PROTECTED] 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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-16 Thread 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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-15 Thread 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 /.)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-15 Thread Otavio Salvador
Robert Millan [EMAIL PROTECTED] 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 OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-12 Thread 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 /.)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-12 Thread Pavel Roskin

Quoting Robert Millan [EMAIL PROTECTED]:


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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-12 Thread Otavio Salvador
Robert Millan [EMAIL PROTECTED] 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 OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-12 Thread Amin Azez
* Otavio Salvador wrote, On 12/12/07 15:03:
 Robert Millan [EMAIL PROTECTED] 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
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-12 Thread Robert Millan
On Wed, Dec 12, 2007 at 10:36:17AM -0500, Pavel Roskin wrote:
 Quoting Robert Millan [EMAIL PROTECTED]:
 
 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 /.)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-07 Thread Otavio Salvador
willem [EMAIL PROTECTED] writes:

 Otavio Salvador wrote:
 Pavel Roskin [EMAIL PROTECTED] 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 OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-07 Thread willem

Otavio Salvador wrote:

willem [EMAIL PROTECTED] writes:

  

Otavio Salvador wrote:


Pavel Roskin [EMAIL PROTECTED] 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  :-)


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-07 Thread Pavel Roskin
Hello!

On Fri, 2007-12-07 at 23:16 -0200, Otavio Salvador wrote:
 Vesa Jääskeläinen [EMAIL PROTECTED] 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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-07 Thread Otavio Salvador
Vesa Jääskeläinen [EMAIL PROTECTED] writes:

 willem wrote:
 Otavio Salvador wrote:
 Pavel Roskin [EMAIL PROTECTED] 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 OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-07 Thread Vesa Jääskeläinen
willem wrote:
 Otavio Salvador wrote:
 Pavel Roskin [EMAIL PROTECTED] 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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Switching to git?

2007-12-06 Thread 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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-06 Thread Otavio Salvador
Pavel Roskin [EMAIL PROTECTED] 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 OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Switching to git?

2007-12-06 Thread willem

Otavio Salvador wrote:

Pavel Roskin [EMAIL PROTECTED] 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


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel