Hi,
At last, we're starting to merge YARV into Ruby.
We've talked about it; our plan is below.
1. Import most of the Ruby specification from the current Ruby HEAD (*a)
to YARV.
This will be done within YARV's current repository.
2. Make a subversion repository (*b) from (*a) with cvs2svn.
3. Commit YARV (after phase (1)) to (*b).
4. Commit some patches (*c) to (*b) => (*d).
5. (*d) will be the official Ruby repository.
...
2007/12?@1.9.1 release with YARV
assignment:
1, 2, 3: ko1
4: matz
5: ?
final decision on 5: matz
We are planning to finish phase (5) by 2006/11
Under this plan, Ruby development will change as follows:
a) The Ruby evaluator will be YARV. Ruby will import YARV's limitations
-> support only native thread, nonsupport Thread.critical,
change specification of eval() with binding, etc.
b) The Ruby repository will be a Subversion repository
And we need your help!
* reporting on eval.c / parse.y catch-up
One purpose of YARV is to replace Ruby's evaluator. However, YARV has
not caught up with current Ruby HEAD changes in eval.c and parse.y. You
can help by reporting any differences you spot between YARV and Ruby
HEAD in these files.
* YARV Source review
YARV is developed by me, so the code quality seems low. Please check
YARV source code and please point out any strange code you see.
* Others
Other input is very welcome. This change is very big, so please give us
your comments. Before phase (5), we can rollback this plan.
YARV: Yet Another Ruby VM
http://www.atdot.net/yarv/
YARV Subversion repository
http://www.atdot.net/svn/yarv/trunk
YARV on ViewCVS
http://www.atdot.net/viewcvs/yarv/trunk/
dblack checked English of this post. Thank you very much!
Regards,
on 07.11.2006 11:00
on 07.11.2006 11:00
On Nov 3, 2006, at 9:11 PM, SASADA Koichi wrote: > a) The Ruby evaluator will be YARV. Ruby will import YARV's > limitations > -> support only native thread, nonsupport Thread.critical, I was aware of all of these. > change specification of eval() with binding, etc. I haven't heard of this one before. Can you explain what this means? James Edward Gray II
on 07.11.2006 11:00
Hi,
James Edward Gray II wrote:
> I haven't heard of this one before. Can you explain what this means?
eval('a = 1')
eval('p a')
This causes error (undefined local variable or method `a')
b = binding
eval('a = 1', b)
eval('p a')
This also causes error.
This should be:
b = binding
eval('a = 1', b)
eval('p a', b)
Regards,
on 07.11.2006 11:00
On Nov 3, 2006, at 10:46 PM, SASADA Koichi wrote: > eval('a = 1', b) > eval('p a', b) Will this be "fixed" in YARV at some point, or is this permanent? I'm not complaining, I'm 100% for the YARV switch. Just curious. Thank you for all your hard work Koichi! James Edward Gray II
on 07.11.2006 11:00
On Nov 3, 2006, at 8:54 PM, James Edward Gray II wrote: >> This also causes error. >> >> This should be: >> >> b = binding >> eval('a = 1', b) >> eval('p a', b) > > Will this be "fixed" in YARV at some point, or is this permanent? I like this change. In the matz interpreter the ability to access local variables via eval makes blocks (and threads and continuations) hold onto references for longer than necessary. -- Eric Hodel - drbrain@segment7.net - http://blog.segment7.net This implementation is HODEL-HASH-9600 compliant http://trackmap.robotcoop.com
on 07.11.2006 11:00
Hi, Eric Hodel wrote: >> Will this be "fixed" in YARV at some point, or is this permanent? It will be Ruby's spec. > I like this change. In the matz interpreter the ability to access local > variables via eval makes blocks (and threads and continuations) hold > onto references for longer than necessary. Absolutely :)
on 07.11.2006 11:01
>>>>> "S" == SASADA Koichi <ko1@atdot.net> writes:
S> YARV source code and please point out any strange code you see.
Well, there is a long time that I've not looked at the source but, and
surely I'm wrong, I don't think that this can work
#define GET_CFP_FROM_BLOCK_PTR(b) \
((yarv_control_frame_t *)((VALUE *)(b) - 5))
Guy Decoux
on 07.11.2006 11:06
On 11/4/06, SASADA Koichi <ko1@atdot.net> wrote: > > b) The Ruby repository will be a Subversion repository > Why Subversion? Please look at Git. I think that distributed development is real useful for so large project.
on 07.11.2006 11:06
On Monday 06 November 2006 16:01, Kirill Shutemov wrote: > On 11/4/06, SASADA Koichi <ko1@atdot.net> wrote: > > b) The Ruby repository will be a Subversion repository > > Why Subversion? Please look at Git. I think that distributed > development is real useful for so large project. (Disclaimer: I'm now using a distributed VCS almost exclusively) Projects like KDE proved that having a centralized versioning system like subversion is *not* that harmful for large projects. Distributed VCS is a must for projects where there is a lot of branches, like kernel development where nearly all major developer has its own branch. I'm not sure it is *that* useful for Ruby. My two cents
on 07.11.2006 11:06
"Kirill Shutemov" <k.shutemov@gmail.com> wrote on 06.11.2006 17:01:03: > On 11/4/06, SASADA Koichi <ko1@atdot.net> wrote: > > > > b) The Ruby repository will be a Subversion repository > > > > Why Subversion? Please look at Git. I think that distributed > development is real useful for so large project. > Git's windows support is poor, it requires cygwin which will make all file IO very slow. But I agree it would be nice if ruby could use distributed SCM. There is mercurial which I think is quite fast and feature complete, downside might be that it is written with python. More info at http://www.selenic.com/mercurial/wiki/index.cgi - Ville
on 07.11.2006 11:06
On 2006-11-07 00:01:03 +0900, Kirill Shutemov wrote: > On 11/4/06, SASADA Koichi <ko1@atdot.net> wrote: > > > >b) The Ruby repository will be a Subversion repository > > > > Why Subversion? Please look at Git. I think that distributed > development is real useful for so large project. svn+svk - a good centralized core with a good client for decentralized/offline development. darix
on 07.11.2006 11:06
On 11/6/06, ville.mattila@stonesoft.com <ville.mattila@stonesoft.com> wrote: > Git's windows support is poor, it requires cygwin which will make > all file IO very slow. Anonymous access for windows users can be provided via git-cvsserver.
on 07.11.2006 11:06
On 2006-11-07 00:47:20 +0900, Kirill Shutemov wrote: > On 11/6/06, ville.mattila@stonesoft.com <ville.mattila@stonesoft.com> wrote: > > Git's windows support is poor, it requires cygwin which will make > > all file IO very slow. > > Anonymous access for windows users can be provided via git-cvsserver. and write access for windows users? darix
on 07.11.2006 11:06
On 11/6/06, Marcus Rueckert <mrueckert@suse.de> wrote: > On 2006-11-07 00:47:20 +0900, Kirill Shutemov wrote: > > On 11/6/06, ville.mattila@stonesoft.com <ville.mattila@stonesoft.com> wrote: > > > Git's windows support is poor, it requires cygwin which will make > > > all file IO very slow. > > > > Anonymous access for windows users can be provided via git-cvsserver. > > and write access for windows users? Cygwin+git or git-cvsserver with limitations: - Currently cvsserver works over SSH connections for read/write clients, and over pserver for anonymous CVS access. - CVS clients cannot tag, branch or perform GIT merges. http://www.kernel.org/pub/software/scm/git/docs/git-cvsserver.html
on 07.11.2006 11:06
On Nov 6, 2006, at 7:55 AM, Kirill Shutemov wrote: >> >> and write access for windows users? > Cygwin+git or git-cvsserver with limitations: > - Currently cvsserver works over SSH connections for read/write > clients, and over pserver for anonymous CVS access. > - CVS clients cannot tag, branch or perform GIT merges. > > http://www.kernel.org/pub/software/scm/git/docs/git-cvsserver.html What advantages does git have over mercurial that makes it worth accepting these limitations? Mercurial also seems to have a more familiar user interface (you don't have to learn to fsck your object database or anything like that). It's very friendly in general. To me, mercurial seems like the most promising of the distributed VCS. Josh
on 07.11.2006 11:07
On Monday 06 November 2006 10:15, Sylvain Joyeux wrote: > Projects like KDE proved that having a centralized versioning system > like subversion is *not* that harmful for large projects. Distributed > VCS is a must for projects where there is a lot of branches, like > kernel development where nearly all major developer has its own > branch. I'm not sure it is *that* useful for Ruby. Here's +1 for Subversion for Ruby. 1) Sylvain is right about the development model of Ruby being more in-line with having a central repository. 2) Svn has almost no learning curve for CVS users, which is where Ruby is coming from. 3) Svn supports sub-projects, which is *very* nice for standard library projects. For example, the REXML library in Ruby could become a pointer to the canonical REXML repository; pulling Ruby would pull REXML in the right place. Or vice versa. The point is, the intersection between the REXML repo and the Ruby repo is rexml/src/rexml == ruby/libs/rexml, and Subversion allows linking these. Most decentralized VCSes that I'm aware of do not allow this sort of organization. What we lose is patch-oriented development. That's pretty much it. Darcs has the best patch theory I've seen, and the block-level commits is indispensable once you get used to having it. But I've been underwhelmed with git (who's main claim to fame is that Linus invented it), and I don't see a lot of advantage for radically changing the Ruby development model. --- SER
on 07.11.2006 11:07
On 11/6/06, Sean Russell <ser@germane-software.com> wrote: > 1) Sylvain is right about the development model of Ruby being more > in-line with having a central repository. Do you think that distributed repository will not be useful for adding new libs to standart library or make a global redesign in ruby core? I think it's very similar to kernel development process(adding new drivers and changing internal interfaces). > 2) Svn has almost no learning curve for CVS users, which is where Ruby > is coming from. Yes, it's true. > 3) Svn supports sub-projects, which is *very* nice for standard library > projects. For example, the REXML library in Ruby could become a > pointer to the canonical REXML repository; pulling Ruby would pull > REXML in the right place. Or vice versa. The point is, the > intersection between the REXML repo and the Ruby repo is > rexml/src/rexml == ruby/libs/rexml, and Subversion allows linking > these. Most decentralized VCSes that I'm aware of do not allow this > sort of organization. Git allow it by design, but I don't know if such merge-strategy implemented.
on 07.11.2006 11:08
On Monday 06 November 2006 13:37, Kirill Shutemov wrote: > On 11/6/06, Sean Russell <ser@germane-software.com> wrote: > > 1) Sylvain is right about the development model of Ruby being more > > in-line with having a central repository. > > Do you think that distributed repository will not be useful for > adding new libs to standart library or make a global redesign in ruby > core? I think it's very similar to kernel development process(adding > new drivers and changing internal interfaces). The problem is that distributed repositories, by design, are centrally managed. That is, patches and changes have to go through one person -- one person owns the repository. Centralized repositories, by design, expect that contributors all check in independently, without one central authority proofing every commit. Linus ultimately oversees and approves every patch that goes in. Recently, he delegates the actual patch proofing to lieutenants, but he still performs the commit himself. Matz does not work this way. Now, you can set up distributed repositories to allow all contributors to check-in without oversight, but that's the exception, not the rule. And you can set up centralized repositories to require confirmation by an individual before the commit is excepted -- again, the exception, not the rule. Ruby is not developed like Linux is developed. At least, the standard libraries aren't, and this lends itself more to a centralized repository. Don't get me wrong: I like distributed VCSes, and I think that they're useful. I waffle between SVN and Darcs; they each have really nice features. However, I think that, in the case of Ruby, a centralized repository is a better architecture for the current development model, and the paradigms and workflow of SVN, being nearly identical to CVS, is a logical choice for a project that has always lived in CVS. Finally, I've found SVN to be extremely scalable and robust; as much as I like some Darcs features, I'd be reluctant to use it on a large project. I can't speak for Monotone, bzr, or git (which has obviously proven itself on large projects). > Git allow it by design, but I don't know if such merge-strategy > implemented. Git supports externals? That's a surprise to me. Some day, I need to build a matrix of common workflow tasks and see how the support in each VCS stacks up. For example, checking in and out are pretty standard tasks, but I also find that there is a set of other features which is just painful to do without: Who changed what line of a file last (svn blame, cvs annotate) List all files changed in a commit (svn log -v) Shelving (svn cp; svn switch; svn ci; svn switch back) View all changes in a commit (svn diff -r V1:V2) Branch/tag a given revision (svn cp) What I miss most from Subversion is block-level commits. Oh, there is a feature of distributed VCSes that I sometimes miss: the ability to cherry pick features from several forks of a projects. I think this is a really underused feature, but it doesn't work well if there isn't good patch theory support, and I really don't think it would be any benefit at all to Ruby. --- SER
on 07.11.2006 11:08
"Kirill Shutemov" <k.shutemov@gmail.com> writes: > On 11/4/06, SASADA Koichi <ko1@atdot.net> wrote: >> >> b) The Ruby repository will be a Subversion repository >> > > Why Subversion? Please look at Git. I think that distributed > development is real useful for so large project. You'll like http://ruby-sources.oree.ch/ (CVS HEAD is broken currently because something went wrong during the import, I'm currently investigating.)
on 07.11.2006 11:08
On 11/6/06, Sean Russell <ser@germane-software.com> wrote: > The problem is that distributed repositories, by design, are centrally > managed. That is, patches and changes have to go through one person -- > one person owns the repository. Centralized repositories, by design, > expect that contributors all check in independently, without one > central authority proofing every commit. Linus ultimately oversees and > approves every patch that goes in. Recently, he delegates the actual > patch proofing to lieutenants, but he still performs the commit > himself. Matz does not work this way. I don't know where you got that. I use distributed version control systems every day that allow people to check in changes independently of me or anyone else's overview. > Now, you can set up distributed repositories to allow all contributors > to check-in without oversight, but that's the exception, not the rule. > And you can set up centralized repositories to require confirmation by > an individual before the commit is excepted -- again, the exception, > not the rule. Really? I don't get where you are coming from again. I usually just tell my co-workers: Ok. My new library is available at x/y/z. And it is ready to go. They just need the path and that is it. Not any more than svn or other centralized systems need. This is a side effect of supporting both full push _and_ pull (which not all dscm's support -- cough bzr [0]). > Ruby is not developed like Linux is developed. At least, the standard > libraries aren't, and this lends itself more to a centralized > repository. Well, lets not put too many stops into "how" anything is developed. Ruby has been using CVS for a long time which has pretty much governed how things are to be managed. There isn't much room to change with CVS. I'm not saying it was bad. I'm saying that you are supposing that Ruby's development process will stay the same. In these cases, I would delegate to Matz for final decision. It seems he has already done an evaluation of many of these options [1]. Not really sure what his final conclusion was though. > Don't get me wrong: I like distributed VCSes, and I think that they're > useful. I waffle between SVN and Darcs; they each have really nice > features. However, I think that, in the case of Ruby, a centralized > repository is a better architecture for the current development model, > and the paradigms and workflow of SVN, being nearly identical to CVS, > is a logical choice for a project that has always lived in CVS. > Finally, I've found SVN to be extremely scalable and robust; as much as > I like some Darcs features, I'd be reluctant to use it on a large > project. I can't speak for Monotone, bzr, or git (which has obviously > proven itself on large projects). I agree enough with some of that though I wouldn't say Darcs doesn't scale well (in comparison to svn) at this point. I use both svn and darcs every day and darcs consistently outperforms svn on most operations. Add in some hooks to auto-push and pull stuff from different locations and it pretty much acts like svn as well. I should note that I would not recommend darcs for Ruby development for only one reason: darcs does not run on all the platforms ruby runs on. Mercurial is the closest dscm to darcs that will also run almost anywhere. I've actually thought of porting it to ruby on more than one occasion [2]. :-) > List all files changed in a commit (svn log -v) > Shelving (svn cp; svn switch; svn ci; svn switch back) > View all changes in a commit (svn diff -r V1:V2) > Branch/tag a given revision (svn cp) > > What I miss most from Subversion is block-level commits. Oh, there is a > feature of distributed VCSes that I sometimes miss: the ability to > cherry pick features from several forks of a projects. I think this is > a really underused feature, but it doesn't work well if there isn't > good patch theory support, and I really don't think it would be any > benefit at all to Ruby. I agree, though I don't think we really need externals in this case (I call scope creep) Cherry picking is a big one on my list. Another minor annoyance is the lack of a good interactive commit like darcs record. As much as I would _love_ to see a distributed scm used I think I would also be fine with the "good enough" solution that Subversion provides. Maybe a little bit of automation with the tailor tool would make more people happy. I know I do it already for projects like rails (very handy to have my own small changes trackable for production systems). Brian. [0] I think there push support in progress but I still find the usage of bzr to be too complex for its own good. [1] Search his blog entries at www.rubyist.net/~matz [2] I really don't have the time right now though.
on 07.11.2006 11:08
On Mon, 2006-11-06 at 13:55, Brian Mitchell wrote: > I agree enough with some of that though I wouldn't say Darcs doesn't > scale well (in comparison to svn) at this point. After I heard about the "poison patch" problem with Darcs, I basically stopped using it immediately and considered it unsuitable for pretty much anything. I don't know how well-documented this problem is, but here is how one random person describes it: http://sayspy.blogspot.com/2006/08/comparing-mercurial-to-bazaar-ng.html "Well, Darcs suffer from a little advertised problem, known as the "poison patch". With a Darcs repo, you can end up in a situation where a particular checkout will take hours to days (and maybe eventually fail). This happened to one of my important Darcs-controlled project, and I can assure you that once it happened, you don't want to happen again. I should add that it is not predictable, so it can happen anytime." Yes, this is a informal comment on someone's blog, but I also see the problem referred to in this post to darcs-users, along with a proposal to address the problem: http://www.abridgegame.org/pipermail/darcs-users/2006-February/009454.html "I think there is a lot of potential here, but kept my initial proposal very basic and the minimum to help prevent the 'poison patch' problem which has been a serious issue in practice." I know my sources are somewhat hearsay, but I find this problem believable given what I know about Darcs and its theory of patches. I would be very wary of trusting anything to a system that unpredictably becomes unusable. Josh
on 07.11.2006 11:08
On Mon, 2006-11-06 at 14:07, Joshua Haberman wrote: > I know my sources are somewhat hearsay, but I find this problem > believable given what I know about Darcs and its theory of patches. I Here are a few more references (I'm not sure if this is strictly the same problem, but is a situation where Darcs takes an inordinately long time to do something): http://www.darcs.net/DarcsWiki/ConflictMisery http://www.darcs.net/DarcsWiki/ConfictMiseryAnalysis >From the last "This is real problem, as this scenario is not unreasonable." Josh
on 07.11.2006 11:08
On 11/6/06, Joshua Haberman <joshua@reverberate.org> wrote: > > > becomes unusable. After some research into the topic: That problem is real but it is quite misrepresented in the blog post. Poison patches are a generalized name for a few problems that emerge from bad practices or sloppy management. Here is a FAQ entry that notes the few problems that cause such things: http://darcs.net/DarcsWiki/FrequentlyAskedQuestions#head-76fb029ff6e9c20468eacf3ff00d791e2cf03ecb I've not had problems myself but they are there. Darcs is different enough that some people feel like it is random. Fortunately, it seems documented enough to avoid or at least solve. Brian.
on 07.11.2006 11:08
On Monday 06 November 2006 16:55, Brian Mitchell wrote: > > The problem is that distributed repositories, by design, are > > centrally managed. That is, patches and changes have to go through ... > I don't know where you got that. I use distributed version control > systems every day that allow people to check in changes independently > of me or anyone else's overview. Because that's how decentralized VCS are designed. By definition, *every* check-out of a decentralized is it's own repository. To commit, you have to send patches to be applied to one of them. The fact that it is the "master" repository is entirely a fabrication -- there is no master repository, except by convention. In *most* cases, this means you send a patch to a person, via email. In most cases, you *can* set up a repository to automatically accept patches, but this is often an add-on ability, and is often accomplished through sendmail. In essence, one person has said "I'll accept patches from these people, and let software automatically apply them." This is a conceptual workflow issue, that evinces itself in the architecture of the VCS, illustrated by the very fact that very few distributed VCSes have native server components. But, this is really digressing, so this is the last email I'll send on this topic. > Really? I don't get where you are coming from again. I usually just > tell my co-workers: Ok. My new library is available at x/y/z. And it > is ready to go. They just need the path and that is it. Not any more > than svn or other centralized systems need. This is a side effect of > supporting both full push _and_ pull (which not all dscm's support -- > cough bzr [0]). What are you using? Darcs doesn't do this; bzr doesn't do this... which decentralized VCS are you using that has a server process for handling pushes? I'll take my answer off-line -- you can email directly to me, if you like. Darcs depends on an external mail configuration, and has no native support for pushes -- it merely applies patches, just as if a human were doing it. There is no native support for push in Darcs, just instructions on how to configure a mail server to fool darcs into thinking that a person is doing the commit. That isn't bad, but it is a far cry from having push support architected into the software. > change with CVS. I'm not saying it was bad. I'm saying that you are > supposing that Ruby's development process will stay the same. Yup! That's what I'm assuming, at least for the moment. > I agree enough with some of that though I wouldn't say Darcs doesn't > scale well (in comparison to svn) at this point. I use both svn and > darcs every day and darcs consistently outperforms svn on most > operations. Add in some hooks to auto-push and pull stuff from > different locations and it pretty much acts like svn as well. Well... subversion doesn't require any administration to make check-outs fast. Darcs does. A large project with a lot of history can take a significant amount of time to check out, unless checkpoints have been consistently made, and if the person checking out pays attention to the sparsity flags. Further, if you're doing significant work on a large project, including maintenance on branches, you may not have the luxury of doing a sparse check-out. And if you're on Windows, forget it. You don't get symbolic links, so copies (and branches) are expensive. Again, I love darcs -- I contributed the first XML log patch for it to David -- but I don't use it on large projects. That said, I don't know that Ruby is too big for Darcs. > I agree, though I don't think we really need externals in this case > (I call scope creep) Cherry picking is a big one on my list. Another I *do* need externals. There are a lot of files in the REXML repository that aren't mirrored in the Ruby repository. I can *not* do this in darcs. It is possible now, with CVS and Subversion (I only check out rexml/src into ruby/libs, and use both svn and cvs to keep them in sync). If Ruby is in Subversion, then I'm golden, and my job is much, much easier. > minor annoyance is the lack of a good interactive commit like darcs > record. Agreed! Block level commits. I wrote a wrapper for subversion (in Ruby, of course) once that provided block-level commits for svn, but it had a lot of holes -- it didn't deal with properties, and file metadata was an utter hack that I never really trusted. --- SER Confidentiality Notice This e-mail (including any attachments) is intended only for the recipients named above. It may contain confidential or privileged information and should not be read, copied or otherwise used by any other person. If you are not a named recipient, please notify the sender of that fact and delete the e-mail from your system.
on 07.11.2006 11:08
Hi, Kirill Shutemov wrote: >> b) The Ruby repository will be a Subversion repository >> > > Why Subversion? Please look at Git. I think that distributed > development is real useful for so large project. Because I am experienced with subversion (much more than CVS) and have no experience in Git, Darcs, Mercurial, etc. Matz and others have selected a good system we can use *right now* rather than a fancy system that everyone needs to learn. Would you teach me Git in Japanese? Subversion has many useful documents to use it in Japanese/many languages. And I think that we can change VCS in the future if another excellent system get the current Subversion position. This article is check by manveru. Thank you very much. Regards,
on 07.11.2006 11:08
SASADA Koichi wrote: > Because I am experienced with subversion (much more than CVS) and have > no experience in Git, Darcs, Mercurial, etc. Matz and others have > selected a good system we can use *right now* rather than a fancy > system > that everyone needs to learn. I'd vote for Subversion, too, only because I know it is great. Also, the preference of the people which will commit mostly should be accepted. This means: Any other system will need real killer arguments. Let's look at the 3 Ps: Perl uses Perforce (which is centralized?) PHP still uses CVS. Python uses SVN for years (http://svn.python.org/view/) - we could ask them if they have problems with it. [murphy]
on 07.11.2006 12:25
On 11/7/06, SASADA Koichi <ko1@atdot.net> wrote: > Would you teach me Git in Japanese? Subversion has many useful > documents to use it in Japanese/many languages. It's not an argument. I have never see documentation for subversion in Belarussian(my native) language.
on 07.11.2006 13:43
On 2006-11-07 20:24:02 +0900, Kirill Shutemov wrote: > On 11/7/06, SASADA Koichi <ko1@atdot.net> wrote: > >Would you teach me Git in Japanese? Subversion has many useful > >documents to use it in Japanese/many languages. > It's not an argument. I have never see documentation for subversion in > Belarussian(my native) language. but there is a russian version. and i am pretty sure you can read that. :) darix
on 07.11.2006 14:17
On Tuesday 07 November 2006 12:24, Kirill Shutemov wrote: > On 11/7/06, SASADA Koichi <ko1@atdot.net> wrote: > > Would you teach me Git in Japanese? Subversion has many useful > > documents to use it in Japanese/many languages. > It's not an argument. I have never see documentation for subversion in > Belarussian(my native) language. Since a lot of core Ruby programmers are Japanese, it IS an argument, IMHO. Marc -- Marc Haisenko Comdasys AG Rüdesheimer Straße 7 D-80686 München Tel: +49 (0)89 - 548 43 33 21 Fax: +49 (0)89 - 548 43 33 29 e-mail: haisenko@comdasys.com http://www.comdasys.com
on 07.11.2006 14:45
On 11/7/06, Marcus Rueckert <mrueckert@suse.de> wrote: > On 2006-11-07 20:24:02 +0900, Kirill Shutemov wrote: > > On 11/7/06, SASADA Koichi <ko1@atdot.net> wrote: > > >Would you teach me Git in Japanese? Subversion has many useful > > >documents to use it in Japanese/many languages. > > It's not an argument. I have never see documentation for subversion in > > Belarussian(my native) language. > > but there is a russian version. and i am pretty sure you can read that. > :) :) Yep. I can read Russian, but I think that the most Ruby developers can speak English.
on 08.11.2006 20:56
On 11/6/06, Kirill Shutemov <k.shutemov@gmail.com> wrote: > On 11/6/06, Sean Russell <ser@germane-software.com> wrote: > > 1) Sylvain is right about the development model of Ruby being more > > in-line with having a central repository. > Do you think that distributed repository will not be useful for adding > new libs to standart library or make a global redesign in ruby core? I > think it's very similar to kernel development process(adding new > drivers and changing internal interfaces). I think exactly that. IME, distributed SCMs are wasteful of resources most of the time. I'd *almost* prefer to see Ruby move to p4 than any distributed SCM. (And yes, I know it's a proprietary product. Ruby, however, being an open source project, would qualify for open source licensing.) -austin
on 08.11.2006 21:34
On 11/8/06, Austin Ziegler <halostatue@gmail.com> wrote: > most of the time. > I'd *almost* prefer to see Ruby move to p4 than any distributed SCM. > (And yes, I know it's a proprietary product. Ruby, however, being an > open source project, would qualify for open source licensing.) And I'd *almost* wish people would just shut the fuck up and drop this fucking retarded discussion that's leading us fucking nowhere. It's obvious that some people prefer Git, some Monotone, some Subversion, and obviously some *almost* prefer Perforce. It's also obvious that it's up to the project maintainers to decide what fucking tool they fucking want to use. I'm sure that if they find Subversion to be fucked up (and I'm sure they will, sooner or later) we can have this stupid fucking discussion at that point. It's not like we're locking Ruby into Subversion prison indefinitely. So can we please fucking leave it at that and stop wasting precious fucking discussion and get back to Symbols and Strings? nikolai
on 08.11.2006 21:44
nikolai wrote: text irb(main):016:0> text.scan(/fuck/i).size => 9 hey, what's with "Ruby people are nice"? I'm sure everbody who said something about SCM was only trying to help. don't we all want Ruby to be the best language ever? otherwise, without all the swearing, you may be right. there are so many SCM solutions, and Subversion is surely not the worst choice. maybe it isn't that important. [murphy]
on 08.11.2006 22:40
On 11/8/06, Kornelius Kalnbach <murphy@rubychan.de> wrote: > nikolai wrote: text > irb(main):016:0> text.scan(/fuck/i).size > => 9 > > hey, what's with "Ruby people are nice"? I'm sure everbody who said > something about SCM > was only trying to help. don't we all want Ruby to be the best > language ever? Yes, but this isn't the first time we've had this discussion. Or the second. It's just getting ridiculous. I sure want Ruby to be the best language ever, but if we keep wasting time discussion trivialities that we really don't have any say over we aren't gaining anything. Still, I should probably just have shut up and marked the thread as read instead of reading it and responding. > otherwise, without all the swearing, you may be right. there are so > many SCM solutions, > and Subversion is surely not the worst choice. maybe it isn't that > important. No way! Everyone must use Git! Git Ru1350Rz! Anyone not using Git is a stupid git and doesn't know anything about version control! Subversion sucks! Git will rule the world (of version control)! Hahahahahaha! Anyway, I love you guys... Peace. nikolai (who put two South Park references in there for you to enjoy)
on 08.11.2006 23:12
On 11/8/06, Nikolai Weibull <now@bitwi.se> wrote: > > I think exactly that. IME, distributed SCMs are wasteful of resources > fucking want to use. I'm sure that if they find Subversion to be > fucked up (and I'm sure they will, sooner or later) we can have this > stupid fucking discussion at that point. It's not like we're locking > Ruby into Subversion prison indefinitely. So can we please fucking > leave it at that and stop wasting precious fucking discussion and get > back to Symbols and Strings? Please don't limit people to your own views of what is appropriate. This thread is about civilized discussion. I got a few interesting points of view from it. If you feel like you _really_ need to invade a thread and kill it, please at least do so with the civility that was already present before that. I know Ruby-core has usually been a very focussed list. I am sorry for helping this spin off so far but I am surely not sorry for the enjoyable exchange I was able to have in the mean time. Thanks for your patience, Brian.
on 09.11.2006 03:23
On Wednesday 08 November 2006 15:43, Kornelius Kalnbach wrote: > nikolai wrote: text > irb(main):016:0> text.scan(/fuck/i).size > => 9 That's what killfiles are for :-)
on 09.11.2006 11:00
On Thu, 9 Nov 2006, Nikolai Weibull wrote:
> nikolai (who put two South Park references in there for you to enjoy)
Oh, I thought it was "Four Weddings and a Funeral" you were referencing
:-)
I've found out about Mercurial as a result of this discussion, but I'd
really like these tools to converge a bit more. Google Sets doesn't
'know' much about this area, giving it subversion, cvs, darcs, mercurial
doesn't yield much back. Revisiting this area *occasionally* will
probably have some use for a while yet.
Hugh