The first version of the site got blasted by spam, so we lost a lot of stuff, and I moved it to a download site for packages. However, I've now updated it so that we can build a repository of markdown documents, using Subversion to handle the content. Here's the plan.

To contribute to the documents on this site, you'll need to be a contributor to the package collection. If so, you'll be largely set.

At the very root of the subversion tree, there is a directory called `sublimetextwiki`. This is the full content of the site. To edit, you'll need to;

The site is set up to receive a callback every time the subversion repository, and this callback should refresh the site automatically. It may take 30 seconds or so for changes to appear -- more if you've committed something large like a screencast, so you may need to be a little patient.

Editing the site is just a matter of knowing the subversion structure. The page content is build in Markdown; all the page content is stored in `sublimetextwiki/pagesource`, and translated into html pages in `sublimetextwiki/pages`.

I suppose I could put up an upload page for big resources, but the thing I like about SVN as the authentication system is that there's a relatively small, trusted set of folks. Submitting to the site involves exactly the same permissions as uploading new packages.

How's this for a first pass?

We start using SVN to see if it does cause problems on large commits. If not, we're good and can continue. If so, we'll look at putting something else in place.

tgkeul wrote:Good to hear about the upgrade of the package download site.

Please forgive my two vicious remarks:

sadly, this is no wiki - and I'm too lazy to fool around with subversion. I'll stick to my tiddlywiki at home.

Why the css template Unnamed(I need sunglasses) while Reinvent will better suite the spirit of sublime?

Hi. I think I can take the criticism

- no, it's not a wiki, but I owned the domain and I didn't want to buy SublimeTextDocumentationContributedByDevelopers.com. - the CSS template was me grabbing the first one I found and slapping together some build scripts. Luckily, the templates are in the subversion repository so anyone else can have a go at replacing them. I like Reinvent, though, and if I update the site, it'll be to this, or I'll ask Jon for the templates for his site.

sublimator wrote:Personally, I never really use the xxxxxx.sublime-package files and therefore the wiki/package site.

a) svn is more convenient, especially if you are developingb) updates, while infrequent, require a restart of Sublime.

That's true -- I don't really use it, either, because I use Subversion too. That makes me wonder if what we'd really benefit from is a simpler way to check for and update all packages direct from the repo, the way Firefox has an addin page and a 'Find Updates' button. The site would not be quite as necessary for package distribution.

I did write a package downloader package, but this was limited because it would conflict with a SVN checkout, so you couldn't use it if you were also developing. Which means that as the package downloader developer, I couldn't use the package downloader... hence the stall. I think that now that we've got the quickpanel, we could make a very nice package downloader, which would find the list of packages and update them directly from subversion. It would require a copy of svn to be installed on the user's system, but my guess is that that's legal. I'll check before I get into anything.

I could just mirror this wiki at sublimetextwiki.com, which would mean that you edit using the site at google code. More wiki-like, but text-only, and so offers no real support for embedded resources like images and screencasts.

Custom Wiki

This is the one that most intrigues me, but would be the most work. The features would be;

- ST as the editor -- no editing in cramped little textareas; the 'edit' link spawns ST, and saving in ST submits the page content back to the site. This gives you syntax highlighting and the power of packages.

- Editing locked to ST owners -- to combat spam, all submissions would have to come from a purchased copy of Sublime Text. This should block all spam but not block any user who had something to contribute.

- local SVN storage. Rather than using Google Code, I'd set up a SVN repo on my web host, and any submission would go through that. Large resources could be uploaded without going into Subversion.

Thoughts?

Those are the ideas I've had so far. I knocked up the current system knowing that it would take me about an hour and would do the job. If we want something better, I'll happily ponder it.

I don't have a lot of time to think about this properly right now, but here's some thoughts -- see if any of them seem

Subversion does allow you to add metadata to folders, so we could use that as a way of tagging a plugin as working with one version or another.

Possibly better would be to copy the way firefox addins work; they have an XML file, I believe, which declares the range of versions they work with.

Now, that might be tricky to handle -- if I upgrade a plugin to 1.2, we still want people to be able to pull out the 1.0 version if it is around. So maybe the thing to do is tie a subversion revision number to a Sublime version; something like adding a text file to the plugin that is structured like this;