[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.


More information about the Greasemonkey mailing list