>The big new secret project Nick Sieger has worked on for well over a year has >launched! > >http://www.kenai.com > >Project Kenai is a project-hosting site that aims to solve some of the biggest >hassles of other sites. It will support multiple SCMs, various bug trackers, a >wiki with MediaWiki formatting, and a lot of other stuff. And there's another >nice twist: > >It's a JRuby on Rails application. > >Now that the site is launched, we're going to be starting the process of >migrating JRuby's project services to Kenai. We've already done a partial >migration of the Wiki content there, but we're waiting for a couple services >to land to make a full-scale move of JRuby. At the moment it looks like we'll >be migrating to Mercurial, since that's the DSCM currently supported by Kenai >(Git is coming, but we'd like to move sooner rather than later). We're also >waiting to see if JIRA will be added as a bug-tracking option, since we're >definitely *not* migrating to Bugzilla. > >What will this mean for you all? Nothing right now. We want to do the move en >masse so there's no need to be hopping back and forth between sites to get at >JRuby stuff. And obviously we'd want to make a clean break from the old SVN >repo on Codehaus to the Hg repository on Kenai. > >If there are any concerns, please raise them here. We're pretty excited to >move JRuby to a service built upon JRuby, and I think Kenai is going to be a >really nice project-hosting site in general. Check it out, and contact me >privately if you have a project you think you might like to migrate there.
While I have a up-to-date version of Mercurial installed and use it occasionally I like using git for my projects better. At this point I'd be a bit disappointed if the jruby project moved to mercurial -- I know I can use git easily with jruby now -- either with the existing svn repo using git svn or using VVS's mirror at github. I haven't looked into whether I can clone a mercurial repo with git yet -- probably doesn't make any sense. First comments about Kenai: There is a long (about 12s) delay time to authenticate (on my long-latency satellite broadband) logging into github is about 6s. I've heard that kenai will support git as another scm in the future. That's great. Supporting bazzar would be nice also. I would like to have effective ways to categorize and sequence content from the wiki and be able to generate a structured pdf document. In effect a JRuby book. I wonder if someone has come up with a way to combine both a wiki and a distributed repository of sample code such that comments/documentation could be edited and rendered both locally and on the network. Does hg have a local browser similar in function to gitk? I have become extremely dependent on gitk to help me follow changes in external projects. While gitk is primitive and could be much better -- it's much like git -- it's VERY fast. Having experienced *VERY FAST* muchmore often using git and git-related tools I'm both becoming addicted AND it's generating new innovation. I use trac and fisheye much less than I used to. I am often working with sub-optimal networks so git/hg are both much better than svn. I'd like to be able to use kenai to fork projects already hosted in a git repo just to try kenai out. Just in relation to SCMs and mindspace there is another reason I am quite interested in git which complements my use of it as an SCM. I am experimenting with using jgit (java implementation of git) for distributing compiled java code. See: https://confluence.concord.org/display/CCTR/Storing+Java+jars+and+classes+in+git for some early tests examining the possible advantages of replacing Java web start with with another implementation that uses jgit for much faster incremental updating of code resources over a network. Some tests show a factor of 50x improvement in size of data transferred over the network compared to a jardiff produced using the ava web start servlet. A variation of the same technique could be used (for example) to hold all of the JRuby compiled artifacts tagged by commit. This would make testing using git bisect EXTREMELY fast because checking out a local branch would update all the compiled code practically instantly. The key to making either of these implementations efficient in git (and presumably hg) is to store not large opaque binary blobs (jars) in the repo -- but to instead unpack the jar(s) and store all the individual directories and class files in the repo. I'm speculating that I might also be able to use jgit as a layer in a distributed object/content system where one of my needs is to be able to efficiently keep track of all the changes to objects over time. This work is helping me learn much more about git and complements my use of it as an SCM. Anyway -- that's only indirectly related to kenai. It's just information about why I am interested in having Kenai support git for more reasons than just having an another SCM to choose from. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
