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.