[Greasemonkey] Greasemonkeyed.com, userscript.org, forums,
source code, and the future of our community
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
> > 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