[Greasemonkey] Greasemonkeyed.com, userscript.org, forums, source code, and the future of our community

Britt Selvitelle anotherbritt at gmail.com
Wed Aug 3 10:24:12 EDT 2005


On 8/3/05, Jeremy Dunck <jdunck at gmail.com> wrote:
> How will you handle branches?  Records have prior_script_id?  I took a
> look around for ruby bindings to subversion, and didn't find anything
> immediately useful.  You can of course compile from SWIG or use Ruby
> DL, but I was hoping for a gem.  ;-)  So, it's probably more expedient
> to do a schema that supports branching, but be aware that as we add
> features, we'll reinvent source control within the relational DB...

I had envisioned it being kept pretty simple (I think it was
originally described this way), allowing revisions in a linear
fashion, fixing small bugs and fixes for whem GM makes api changes.

IMO if there are enough changes that it is considered a branch, one
should dicuss more details commit patches back with the original
author or make it a new script. The wikified scripting interface would
really just be for tiny bugfixes to keep the script running properly
with gm.
 
> > One of the big reasons is that we need to store additional information
> > about each revision, such as whether or not it's trusted.
> 
> Storing everything -but- the source code in the DB would allow for
> this, wouldn't it?

Why store the source in svn when we are already storing per-revision
records in the database?
 
> Still, you have the issue of queryable branches.  I want to see the
> history of script X.  How do I do that?

Not considering branch trees, all the scripts would be stored linearly
in a table. We can consider branches housed under a single script's
page, but I really think this is a bad idea. If a branch is different
enough to be considered a "branch", the original script's description,
author, etc probably aren't applicable, and the branch itself really
deserves it's own page and record in the database.

Britt


More information about the Greasemonkey mailing list