[ruby-core:21039] Happy new year and... moving Ruby development to Git?

[evolving_jerk]

On 05.01.2009, at 18:11, M. Edward (Ed) Borasky wrote:

> eanwhile, the "language itself" discussion seem to take
> place (in English, anyhow) here on ruby-core. Maybe there should be a
> "ruby-infrastructure" list for those who want to talk about workflows,
> benchmark suites, test suites, version control systems, etc.


Obviously Python development discussions take place on python-dev the  
similar way.
But! They got eventually posted as PEPs and everyone can read a  
summary instead of digging in the mailing list.

Why cannot Ruby do the same, getting away with a wiki and a common  
format for these proposals (so they don't turn into disorganized mess)?
It is why PEPs are useful: summary and "official response" for every  
significant change ever proposed can be found by everyone on the web.

MK

[M. Edward (Ed) Borasky]

Luis Lavena wrote:

> gitk is great for quick looking, is not like TortoiseSVN or anything like that.
>
> Anyhow, what is the point of this discussion? How many Windows users
> will hack in the Ruby source code?
>
> And those who does, I guess they are quite command-line savvy.
>
> I know Git has a complex and less userfriendly command line interface,
> but the whole discussion was not Git alone but the set of tools around
> it.
>

Well, the whole "Ruby on Windows" discussion probably needs its own
mailing list. :) And *your* repository is already on Github, so I count
that as a strong vote in favor of Git(hub).

By the way, I had occasion to poke around on my Github repo last night
and discovered that I'm at 13 MB of my 100 MB free account limit. 100 MB
ain't a whole lot of disk space. It's probably fine for my two tiny
projects, but I think Ruby might need more. So "financial support" is
going to be a consideration in any repo migrations.

[James Gray-7]

On Jan 5, 2009, at 9:20 AM, M. Edward (Ed) Borasky wrote:

> By the way, I had occasion to poke around on my Github repo last night
> and discovered that I'm at 13 MB of my 100 MB free account limit.  
> 100 MB
> ain't a whole lot of disk space. It's probably fine for my two tiny
> projects, but I think Ruby might need more. So "financial support" is
> going to be a consideration in any repo migrations.

Github will usually raise the limit for open source projects.  All we  
need to do is ask.

James Edward Gray II

[Tommy Morgan]

On Tue, Jan 06, 2009 at 12:20:12AM +0900, M. Edward (Ed) Borasky wrote:
> By the way, I had occasion to poke around on my Github repo last night
> and discovered that I'm at 13 MB of my 100 MB free account limit. 100 MB
> ain't a whole lot of disk space. It's probably fine for my two tiny
> projects, but I think Ruby might need more. So "financial support" is
> going to be a consideration in any repo migrations.

It's hard to say, but it looks like Github did the official perl mirror pro
bono: http://github.com/blog/276-perl-mirror-on-github

Of course, I think the perl repo is only 80MB, judging from the comments.

A good point, though. If we get there, we may want to discuss options directly
with the Github guys - they may do something better than make ruby buy an
appropriately-sized account.

--Tommy M.
http://www.duwanis.com

[evolving_jerk]

On 05.01.2009, at 18:12, Paul Brannan wrote:

> The bigger problem with keeping separate copies of each branch is that
> it forces the user to do a full recompile when a new branch is made  
> (*).
> This discourages short-lived development branches.


If you do a lot of work on multiple branches, yes. I am not sure how  
often it is the case, and for two branches (1.8.x and 1.9.x) one can  
use two local Git clones.
Two, not 5 or 6.

MK

[Florian Gilcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 5, 2009, at 4:12 PM, Paul Brannan wrote:

> On Sat, Jan 03, 2009 at 12:48:09PM +0900, Michael Klishin wrote:
>> Darcs has idea of "every branch is a separate directory" (or used to
>> have it). I can't say it is a problem but you will end up having 3-5
>> copies of the pretty much the same code, and if you repository is 600
>> megs, not all movies you try to  download from iTunes may fit into
>> your HD.
>
> The bigger problem with keeping separate copies of each branch is that
> it forces the user to do a full recompile when a new branch is made  
> (*).
> This discourages short-lived development branches.
>
> Paul
>
>
> (*) at least, this is true when using make -- a build system that uses
> md5sums makes this less of an issue

Darcs still has no concept of branches. I quite like that. It gives a  
better overview on your file system. Every "branch" is still laid out  
like you would have it in SVN or something like that.

I would mark that problem as a problem of you build-system or you  
workflow.

If I want to branch, I usually don't create a new repos as my branch  
and start working there, instead I put the momentary state away in  
another repos and continue working on my active repos. Then, I push  
patches back to the "old repository" or pull patches from somewhere  
else. This ensures that all "temporary data" is still in my active  
"working repository". Sure, it only goes so far until I merge the  
branches changes back into the "old repository", but thats when I  
prefer to do a full check (and eventually rebuild) anyways.

My biggest problem with Darcs is that I have yet to run into the  
dreaded merge problem. It is said not to be rather tame in > 2.0, but  
I have yet to experience it. So I can't make an assessment on that.
The Darcs command line interface is one of the best I ever  
experienced. At least when it comes to my workflow, you mileage may  
(and will!) vary.

Regards,
Florian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkliLl4ACgkQyLKU2FMxSOK7DQCeL8g0i05pEclkmW79MfoIa86x
2ggAnRsmdx+RutwBGjTdt9DFPjlqfZGX
=K54Y
-----END PGP SIGNATURE-----

On Mon, Jan 5, 2009 at 4:59 PM, Florian Gilcher <flo@...> wrote:
> Darcs still has no concept of branches. I quite like that. It gives a better
> overview on your file system. Every "branch" is still laid out like you
> would have it in SVN or something like that.

Although I've never used darcs, the inability to properly handle
branches was actually one of the reasons why I gladly moved away from
mercurial (my first dscm).

The upside of git is that it doesn't _force_ you to work with separate
checkouts for separate branches, although you _can_ do it: just clone
the local repo --git is even smart enough to hardlink blobs when
possible. I say this is a strong vote in favour of git, as it allows
both branching workflows (in-place and separate checkout).

--
Giuseppe "Oblomov" Bilotta

[Florian Gilcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 5, 2009, at 5:29 PM, Giuseppe Bilotta wrote:

> On Mon, Jan 5, 2009 at 4:59 PM, Florian Gilcher  
> <flo@...> wrote:
>> Darcs still has no concept of branches. I quite like that. It gives  
>> a better
>> overview on your file system. Every "branch" is still laid out like  
>> you
>> would have it in SVN or something like that.
>
> Although I've never used darcs, the inability to properly handle
> branches was actually one of the reasons why I gladly moved away from
> mercurial (my first dscm).
>
> The upside of git is that it doesn't _force_ you to work with separate
> checkouts for separate branches, although you _can_ do it: just clone
> the local repo --git is even smart enough to hardlink blobs when
> possible. I say this is a strong vote in favour of git, as it allows
> both branching workflows (in-place and separate checkout).

I'm on the "i don't want to think to much about it" or "lazy bastard"  
side. For example, one of my main reasons for darcs is it's nice  
cherry-picking interface that is the _default_ way of handling it.  
Sure, i could use git cherry-pick and friends, but Darcs gives me the  
collection of features I really like at my fingertips.
Also, I tend not to play with branches too much, but only push the  
patches I really want back to upstream/trunk. Thats the default way in  
darcs.
Sure, I could push git into my workflow, but that would mean I would  
have to costumize git everytime I change computers. It does a lot, but  
i only need half of it and it always takes me time to figure out which  
half I wanted to use.

Also, if you allow both workflows, which link will you put on your  
website? ;)

As I said before: your mileage may vary. I don't like git that much  
and I also have a problem with hypes. So I would tend to wait until  
the "revolution" is over.
But I support the democratic process ;).

Regards,
Florian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkliRyQACgkQyLKU2FMxSOJzcwCgh9c5WlHX8LOcImLFpBRMY3qD
qVkAnjX/3PbnABGSog7IaZnjC37TvXef
=dhTY
-----END PGP SIGNATURE-----

[Thomas Enebo]

M. Edward (Ed) Borasky wrote:

> Eustáquio Rangel wrote:
>  
>> remember that
>> Git is used to keep projects like the Linux kernel and take a look
>> again on it.
>>    
>
> I am remembering a line from AWDR -- something about everything being
> done for historical reasons. That's precisely why there is a Git and why
> the Linux kernel uses it. The Linux kernel used to be maintained in a
> system called BitKeeper. Linus Torvalds asked the developer(s) of
> BitKeeper to release it as an open source project. They either couldn't
>  
> or wouldn't, so Linus developed Git as a replacement.
>  

[Off-topic but the drama of the BitKeeper wars compells me]

Not to nitpick, but Linus never asked Bitkeeper to open source itself.

 From my armchair, with a snifter of Cognac,  I would read the BitKeeper
threads on LKML when I wanted a soap opera.

Linus knew the Bitkeeper guy and the Bitkeeper guy decided to let Linus
use Bitkeeper free (as in beer).  All other developers could get a free
copy of the client so long as they agreed to some licensing terms.  Some
people (Tridgell) felt it was heinious to build a GPL kernel using a
commerical SCM.   They also did not like the terms of the free license
of BitKeeper (like if you use it you cannot work on your own SCM).   So
people kept trying to reverse engineer Bitkeeper protocols and inner
workings and it eventually boiled to a head when the BitKeeper guy
(Larry?) decided no more free licenses (especially to OSDL where Linus
and Tridgel worked).   This forced Linus into a corner, because up until
that point because he only liked BitKeeper.  That was the seed for Git.

I suspect there were some technical motivations for git getting created
as well, but I personally think it was mostly Linus just getting fed up
with the endless BitKeeper wars.

-Tom

[Eric Hodel]

On Jan 2, 2009, at 17:25 PM, Nikolai Weibull wrote:

> On Sat, Jan 3, 2009 at 00:34, Eric Hodel <drbrain@...> wrote:
>> git is the most user-unfriendly a piece of software I've had the  
>> misfortune
>> of using.
>
> Enough with the comments without actual substance already.  This is
> getting us nowhere.
>
> Do some actual research, or take part of some of the research that has
> already been done by people who actually know what they're talking
> about, for example, http://whygitisbetterthanx.com/#easy-to-learn.
>
> I don't really care what SCM the MRI developers use and I don't
> understand why everyone seems to think that they are entitled to an
> opinion about it, but it's time to get over this meaningless and
> repeated discussion.

I think I'm entitled to an opinion on the subject because I am a  
committer, and I cited my experiences in forming my opinion.  (It  
turns out that I'm not alone in this opinion.)

> So can we please have a long discussion about how people like me
> shouldn't try to stifle discussions on mailing lists instead?

I think your email is useful and relevant.

> Or at least get our facts straight and present valid cases for the
> SCMs that we prefer?

Part of one paragraph in the message you responded to straightened  
facts.  I prefer that things stay as they are (using subversion).

["Martin J. Dürst"]

At 22:59 09/01/05, Michael Klishin wrote:

>It would require a shift in perspective about the process though. My  
>observations so far (3+ years with Ruby)
>are that Ruby people are a bit like children (in a good sense, and  
>myself included). They like playing and not necessary like keeping  
>things organized.

Very well put. Also, the whole PEP business doesn't exactly match
agile development. From http://agilemanifesto.org/:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
Sometimes, it's important to think something through very well
and to have everybody agree. Sometimes, it's important to fix
something quickly. For some things, there are only very few
people who care, or who understand what's involved. Sometimes
(often), it's easier or more important to actually try things
out than to describe them in detail.

For some changes, in particular for the move to Strings tagged
with Encoding when going from 1.8 to 1.9, there have been
very detailled wiki pages, but they were less formal than
PEPs, and they were in Japanese.


>Python people are more "boring", and this is why �IMO �they have PEP  
>and really well thought out process of 2.5 => 3.0 migration,
>  and we don't have REP and any 1.8.x => 1.9.x migration plans. I am  
>not bitching/complaining here, I just want to say, this would be a way  
>more significant move for Ruby community that a switch from Subversion  
>to Git. This is it.

Another difference is that Python is basically monolingual (only English),
but Ruby development is bilingual (Japanese and English). Currently,
this seems to work reasonably well for bugs: People have an idea
of who might be responsible for a bug, and accordingly post in English
or Japanese. Most Japanese developers read English well enough to feel okay
with English bug reports (a good bug report usually has very little text,
and lots of data).

For PEP-like proposals, my guess is that it would be quite a different
story. Abstract text takes quite a bit more time to read and digest
in a foreign language, and proposals tend to be way longer than bug
reports.

Code is one way to lower language barriers!

A third point is that the Ruby community doesn't have an unlimited
amount of resources (read: people). It's not just a question of
doing REPs or not doing REPs, but of doing REPs or doing something
else (such as testing, bug fixing, additional features, better docu,...).

My conclusion is that something REP-like could work for some aspects
of Ruby development, but expecting that every change in the language
is documented by a REP is going way too far.

Regards,    Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@...    

> I think I'm entitled to an opinion on the subject because I am a  
> committer, and I cited my experiences in forming my opinion.  (It turns
> out that I'm not alone in this opinion.)

Of course, but the experience of being a non-committer who still tries
to improve ruby is also important. Honestly, I think it is even more
important. The basic asymmetry of centralized VCSs makes the workflow of
a committer always much better than the one of a non-commiter since the
non-commiters have little access to the VCS services. And one experience
of one non-committer is: it sucks badly.

This is mainly because non-trivial patches (and even trivial ones) tend
to stay quite long in the bug tracker. Which means that you basically
have, as a non-committer, to update your patch over and over again to
the newest HEAD. I did that with svn, it is horrible (you have to do it
by hand). I do that now with git and it works like a charm (thanks to
rebase).

Another thing: maintaining the ChangeLog file. This thing looks very
stupid, and makes merging horrible (you basically always have a conflict
on ChangeLog, for obvious reasons). I thought first that it was a
workaround from the good'ol days of CVS and even started to write a
script that would generate it. Then I realized that it was not doable
with SVN since there are no merges. Stupid.

Sylvain

[Florian Gilcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 6, 2009, at 10:29 AM, Sylvain Joyeux wrote:

>> I think I'm entitled to an opinion on the subject because I am a
>> committer, and I cited my experiences in forming my opinion.  (It  
>> turns
>> out that I'm not alone in this opinion.)
>
> Another thing: maintaining the ChangeLog file. This thing looks very
> stupid, and makes merging horrible (you basically always have a  
> conflict
> on ChangeLog, for obvious reasons). I thought first that it was a
> workaround from the good'ol days of CVS and even started to write a
> script that would generate it. Then I realized that it was not doable
> with SVN since there are no merges. Stupid.

I don't know about you specific problems with that, but SVN 1.5 knows  
about
merging. I don't know which version the ruby repos is running, but  
this is
one of the best reasons for 1.5.

Regards,
Florian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkljNVUACgkQyLKU2FMxSOLb8QCglOIqXCGmC+5FZQP4vjY/jxb9
s6IAnRxRNmcLEpldGpG/0Z8cQU2AeCGS
=ndcr
-----END PGP SIGNATURE-----

On Sun, Jan 4, 2009 at 13:08, Michael Klishin <michael.s.klishin@...> wrote:

On 04.01.2009, at 21:53, mathew wrote:

Yes, we should definitely take advice on working practices from the people developing Perl 6...

If you read the post, it was Perl 5 that moved to Git.

Well, in that case... We should definitely take advice on working practices from the people maintaining a project which is in maintenance mode and no longer undergoing heavy refactoring.

On Mon, Jan 5, 2009 at 05:09, Luis Lavena <luislavena@...> wrote:

Anyhow, what is the point of this discussion? How many Windows users
will hack in the Ruby source code?

And those who does, I guess they are quite command-line savvy.

I nominate you to tell Austin Ziegler that he needs to start using Cygwin. I'll be over here behind the plexiglass shielding.


mathew

[Brent Roman]

+1

Sylvain describes my situation exactly.
I'm a CVS dinosaur whose recently realized that I've got to evolve to survive.
And, like many other Ruby "non-committers", the hassle of tracking the moving target
at HEAD seriously dampens my enthusiasm.

Git may or may not be the best distributed source management tool, but it would
be silly to choose some other DSCM for the core interpreter given that
many of the large Ruby apps and libraries have already moved to git.

- brent

P.S.  Can anyone suggest a good, gentle introduction to git for mere mortals, lest
I repeat Eric Hodel's negative experiences with it?

Bugzilla from [e-mail] wrote:

Of course, but the experience of being a non-committer who still tries
to improve ruby is also important. Honestly, I think it is even more
important. The basic asymmetry of centralized VCSs makes the workflow of
a committer always much better than the one of a non-commiter since the
non-commiters have little access to the VCS services. And one experience
of one non-committer is: it sucks badly.

This is mainly because non-trivial patches (and even trivial ones) tend
to stay quite long in the bug tracker. Which means that you basically
have, as a non-committer, to update your patch over and over again to
the newest HEAD. I did that with svn, it is horrible (you have to do it
by hand). I do that now with git and it works like a charm (thanks to
rebase).

Another thing: maintaining the ChangeLog file. This thing looks very
stupid, and makes merging horrible (you basically always have a conflict
on ChangeLog, for obvious reasons). I thought first that it was a
workaround from the good'ol days of CVS and even started to write a
script that would generate it. Then I realized that it was not doable
with SVN since there are no merges. Stupid.

Sylvain

[Joel VanderWerf]

Brent Roman wrote:
> P.S.  Can anyone suggest a good, gentle introduction to git for mere
> mortals, lest
> I repeat Eric Hodel's negative experiences with it?

It comes with a tutorial and manual, which are not too bad. I'm getting
started with it too. Maybe we can move this discussion to a thread on
ruby-talk, and get a little git-for-rubyists support group going?

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

[James Gray-7]

On Jan 6, 2009, at 12:16 PM, Brent Roman wrote:

> P.S.  Can anyone suggest a good, gentle introduction to git for mere
> mortals, lest
> I repeat Eric Hodel's negative experiences with it?

Here's what I liked:

http://blog.grayproductions.net/articles/getting_git_thanks_to_peepcode

James Edward Gray II

[Yukihiro Matsumoto]

Hi,

In message "Re: [ruby-core:21165] Re: Happy new year and... moving Ruby development to Git?"
    on Tue, 6 Jan 2009 18:29:44 +0900, Sylvain Joyeux <sylvain.joyeux@...> writes:

|This is mainly because non-trivial patches (and even trivial ones) tend
|to stay quite long in the bug tracker. Which means that you basically
|have, as a non-committer, to update your patch over and over again to
|the newest HEAD. I did that with svn, it is horrible (you have to do it
|by hand). I do that now with git and it works like a charm (thanks to
|rebase).

As far as I believe issues and patches posted Redmine need not to
update to the latest.  The committers will do.  Most of left out
changes are just posted to the list.

|Another thing: maintaining the ChangeLog file. This thing looks very
|stupid, and makes merging horrible (you basically always have a conflict
|on ChangeLog, for obvious reasons). I thought first that it was a
|workaround from the good'ol days of CVS and even started to write a
|script that would generate it. Then I realized that it was not doable
|with SVN since there are no merges. Stupid.

We have a tool to do the ChangeLog merge, so let us do the merge, just
post the ChangeLog entry for the patch.

None the less, we could prepare the git repository synchronized with
the central repository.  Yugui already has one anyway.

                                                        matz.

> In message "Re: [ruby-core:21165] Re: Happy new year and... moving Ruby development to Git?"
>     on Tue, 6 Jan 2009 18:29:44 +0900, Sylvain Joyeux <sylvain.joyeux@...> writes:
>
> |This is mainly because non-trivial patches (and even trivial ones) tend
> |to stay quite long in the bug tracker. Which means that you basically
> |have, as a non-committer, to update your patch over and over again to
> |the newest HEAD. I did that with svn, it is horrible (you have to do it
> |by hand). I do that now with git and it works like a charm (thanks to
> |rebase).
>
> As far as I believe issues and patches posted Redmine need not to
> update to the latest.  The committers will do.

I'm not seeing a committer update 100+ lines of code that are 6 to 12
months old (or he will ignore it right away, because it is too much
work). Yes, that's how long some patches bit-rot on the bugtracker.

And given that I actually *use* the patches I post, I still have to
update it if I want to benefit from new Ruby version. You still see
everything from the point of view of core Ruby. Patches bitrot for long.
Some functionalities are experimental (the MBARI patches or my own GC
patches) and cannot be committed. We can't commit them on SVN because we
are not SVN committer.  Still, we need to keep them up to date, because
*we use them* and because it would be too much work for committers to
update them (and therefore the patches will be thrown away after a
while).

It is perfectly sensible to reduce the commit rights to the core
repository, but the use of a centralized VCS is an "all-or-nothing":
either you are committer, or you can't use the VCS.

> None the less, we could prepare the git repository synchronized with
> the central repository.  Yugui already has one anyway.
Fine, I'll just rebase mine on it then ...

Sylvain

[evolving_jerk]

On 07.01.2009, at 3:59, Yukihiro Matsumoto wrote:

> None the less, we could prepare the git repository synchronized with
> the central repository.


Matz,

But what repository will core committers check into? Subversion or  
Git? Read-only clone of Git is far less useful than a Git repository  
where development happens,
because it means changes are still shared as patches, so when people  
apply them, there is no history of changes, and it is always a lot of  
manual work for people
who want to try out those changes.

I just decided to ask so there are no fault expectations set.

MK