[Nitro] Revisiting some Og issues again: RFC

Trans transfire at gmail.com
Wed Nov 28 23:22:28 EST 2007



On Nov 28, 8:37 pm, "Judson Lester" <nya... at gmail.com> wrote:

> I very much want to see Og as a separate project.  I think it's a very
> useful library, with a excellent philosophic basis.  I remain eager to
> commit to it's development, specs and doc.  On the other hand, I candidly
> have little interest in Nitro, and Og's coupling with Nitro both frustrates
> and distances me.  I do thank the Nitro project for engendering in me a keen
> dislike for Darcs though.
>
> I realize that I've contributed only a little to Og, and it was a long time
> ago, but I'm a little in love with it as a library, and I feel strongly
> about it.
>
> So the idea then is that we have a central svn repo and we us git, via
>
> > svn-git, to work with it. I realize it's off the beaten track, but I
> > think in the end it's probably the best all around solution.
>
> All that in mind, my thought is this: what does a hybrid svn/git SCM
> solution get us?  Is it that difficult to set up a head git repo?  I'd argue
> against using the Rubyforge Nitro SVN specifically because I'd prefer to see
> Og take off as a separate project.
>
> I tentatively agree that it would be preferable not to create a complete
> fork of Og as it stands, with regards to limited developer resources.  But I
> wonder if there might be more potential devs for a standalone Og than there
> are for Og-in-Nitro.

I understand you're take here. It's different with SVN in that one
repository can house many separate projects. For instance my ProUtils
repo has a number of projects and the layout of the repo clearly
demonstrates the fact:

  proutils/svn/
    box/
      branches
      tags
      trunk
    icli/
      branches
      tags
      trunk
    mint/
      branches
      tags
      trunk
    ...

This is what I'd like to do with Nitro's repo and start thinking of
Nitro as an umbrella repo which contains a number of separate projects
instead of a project in itself. But this would mean that Raw would
become more of what Nitro is considered today. Maybe that's not
reasonable, but I was hoping to keep the all the Nitro projects under
one "roof" while having independent dev tracks at the same time.

The downside of a pure Git repo is that it would have to be hosted by
a private system (no public "forges" I know of support git) and also
anyone on Windows would not have access to the repo (maybe not that
big a deal, but something to be considered nonetheless).

T.


More information about the Nitro-general mailing list