Open Sourcing our Add-Ons

klip

well, I'm little bit scared of anybody making changes in "my" add-ons.
Everybody can whenever contact me with a patch or anything and if I don't agree adding it to the code, everybody can make another add-on based on my latest version. Though I don't know how does user system on Google Code work.
Anyway I feel much better using my own subversion repositories than third-party's one.

So at the moment I use my own repositories which have also anonymous read-only access:
svn://tomas.klapka.cz/var/svn-repos/vanilla/extensions/FixLanguageDefinitions/
svn://tomas.klapka.cz/var/svn-repos/vanilla/extensions/ExtensionLanguageLoader/
svn://tomas.klapka.cz/var/svn-repos/vanilla/languages/Cestina (not yet released complete czech dictionary definitions)


also I guess it is possible to use subversion externals to link subversion repositories so it is at least checkoutable/updatable


@MySchizoBuddy: svn implementations in IDEs are often buggy, I recommend using svn in a command line or to use TortoiseSVN (only on windows).

MySchizoBuddy

klip the idea to have all of them in one place. not hundred different ones.
although your more than welcome to use your own svn

MySchizoBuddy

How to upload files to Google code using TortoiseSVN http://code.google.com/apis/gadgets/docs/tools.html

MySchizoBuddy

instead of /trunk use /extensions like below
svn checkout https://vanilla-friends.googlecode.com/svn/extensions/ vanilla-friends --username myschizobuddy

MySchizoBuddy

dinoboof would u mind if i change the directory structure
the current one is nonstandard, i cannot checkout trunks of extensions in one command i have to do that manually for each extension

Dinoboff

I set it like that so that each extension is independent from each other, so that each extension has its own branches and tags.

What structure could we use?

MySchizoBuddy

default one
/trunk/extensionName/
/branches/extensionName/
etc

klip

maybe you can make a project containing "all extensions" by linking them to the same svn server but different repository folder by svn externals. This reminds me I wanna try it, but I'm too tired right now. 1:20AM here.

Dinoboff

@myschizobudy: ok. jQuery seems to do that.

Add the trunk, branches and tag folders and put your extensions there, I will put mine when I have some time for.

Leave the vendor and wiki folder, and leave the extension folder for now.

About the comments... Try to always add a comment to your commit. If it's about an extension, start the comment with "MyExtension: blah blah..."

MySchizoBuddy

i spend the whole day and all i could do was add a empty folder.
svn on mac seem to suck really bad. i cannot understand how to use them.
gonna fire up windows and hopefully i'll be able to put my extensions on google code

klip

so finally I found some time and tried svn externals and it works just nice, though I haven't tested commit changes in code of fetched parts, but I think everybody can use direct repository if needs to do changes there, if externals is not working.

so I have different repository for each of my projects:
svn://tomas.klapka.cz/vanilla/extensions/FixLanguageDefinitions/ svn://tomas.klapka.cz/vanilla/extensions/ExtensionLanguageLoader/ svn://tomas.klapka.cz/vanilla/languages/Cestinaand I need one repository where is all of it and maybe also some other extensions not from me.

so I followed this article

I created empty repository svn://tomas.klapka.cz/vanilla_resources/ with trunk in it (svn://tomas.klapka.cz/vanilla_resources/trunk)
then checkouted it somewhere:svn co svn://tomas.klapka.cz/vanilla_resources/trunk ./vanilla_resources_from_klipthen I run svn propedit:
svn propedit svn:externals ./vanilla_resources_from_klip
Now it opened a system editor with empty file so I filled it by this content:
languages/Cestina svn://tomas.klapka.cz/vanilla/languages/Cestina/trunk extensions/FixLanguageDefinitions svn://tomas.klapka.cz/vanilla/extensions/FixLanguageDefinitions/trunk extensions/ExtensionLanguageLoader svn://tomas.klapka.cz/vanilla/extensions/ExtensionLanguageLoader/trunk
Then you have to cd ./vanilla_resources_from_klip svn update and it should fetch/checkout all repositories you set as external. Now you only svn commit -m "Added externals for my czech language add-on 'Cestina', and extensions FixLanguageDefinitions and ExtensionLanguageLoader"
and that's it. so if I want to fetch all my stuff now, I just do:
svn co svn://tomas.klapka.cz/vanilla_resources/trunk ./vanilla_resources_from_klip

Max_B

BTW, the "trunk/branches" scheme is not mandatory at all. SVN is just a directory tree. You can do it as it fit best your need.

MySchizoBuddy

yeah just that every one does it this way, the documentation on google code all assume trunk, that was my first stumble block, i kept looking for trunk but it wasn't there

MySchizoBuddy

apparently tortoiseSVN is able to detect the directory names. As I was committing the /tags directory it gave me a warning that I should first switch to the /branches or /trunk , and asked me to confirm that i want to commit the tags directory anyway. So apparently the names are sort of important

Dinoboff

It would have warm as well if you have tried to commit to /path/to/something/tag/something

TomTester

Note: After some bad experiences with Tortoise (slowwww PC) I'm quite pleased with RapidSVN. Check it out and see if it works for you: http://www.rapidsvn.org/

mxsquare

Are all the add-ons for vanilla open source? Can they be used as part of a commercial site or product offering?

MySchizoBuddy

they are all GPL as far as I know. If you use it for commercial site and you amke changes to the code, you have to give the changes back to us.

Dinoboff

Not exactly. You can do what ever you what want with them on your site, commercial or not. But if you are distributing a product using them, you have to use the same licence.

Dinoboff

Also, you should ask the author how does he want to licence his add-on if he didn't state it. The ones in the Vanilla-friends repository are GPL v2; and if you put your add-on in it you should check everything is compatible with GPL. BSD-like licences are compatible.