From BlenderWiki
http://lists.blender.org/pipermail/bf-committers/2011-January/030029.html
Hi,
after discussing this with Campbell in IRC, we decided to propose the schemed you find below.
For those interested in details, under the proposed scheme there is some background information that you can skip at will (the "APPENDICE: BACKGROUND ..." section)
INTRODUCTION
================================================================================
Why bf-extensions
--------------------------------------------------------------------------------
Back in 2008, after discussing with Nathan Letwory we designed the bf-extensions repository classifying as "extensions" things like:
* Python Scripts
* C/C++ Plugins
* Verse
* (in the future maybe)
* Lua Scripts
* javascript Scripts
* ?
Problem
--------------------------------------------------------------------------------
In the last 2 years there has been quite a naming misunderstanding.
"addon" = can be enabled
NO!
"addon" = comes with the Release or not? (a là Firefox)
It should be:
* an "extension":
- is pre-installed (comes with blender releases)
- can be on/off by default
- can be enabled/disabled
- Release would have NO so called "addons" in the Blender home directory
* an "addon":
- have to be downloaded
- is off by default after download
- can be enabled/disabled
- can be moderately buggy (See below)
- fix can be provided in contrib/
- fixed versions:
- shows in addons panel (or info header, to be decided)
- user can accept upgrade and download it
Proposal
So this is the proposal to put things in the right perspective.
SVN setup
bf-blender/ [1]
blender/
trunk/
release/
scripts/ ¦
core/ ¦
ui/ ¦
modules/ ¦ bf-extensions/ [2]
presets/ ¦ trunk/
extensions/ <···· svn-external ····> scripts/
io_* ¦ io_*
render_* ¦ render_*
mesh_* ¦ mesh_*
... ¦ ...
(no "addons") ¦ addons/
¦ scripts/
¦ io_*
¦ render_*
¦ mesh_*
[1] https://svn.blender.org/svnroot/bf-blender
[2] https://svn.blender.org/svnroot/bf-extensions (rename "contrib" as "addons")
User hard disk
BLENDER-HOME/
scripts/ ¦
core/ ¦
ui/ ¦
modules/ ¦ bf-extensions/
presets/ ¦ trunk/
extensions/ ¦ scripts/
io_* ¦ io_*
render_* ¦ render_*
mesh_* ¦ mesh_*
... ¦ ...
... ¦ addons/
addons/ <···· user download ····> scripts/
io_* ¦ io_*
render_* ¦ render_*
mesh_* ¦ mesh_*
same scheme in different fashion
bf-extensions/
trunk/
scripts/ <------- (svn-external)
io_* ¦
render_* ¦
mesh_* ¦
.../ ¦
addons/ ¦
scripts/ <~~~~~~~~~~~ (downloadable)
io_* ¦ |
render_* ¦ |
mesh_* ¦ |
.../ ¦ |
¦ |
scripts/ ¦ |
core/ ¦ |
ui/ ¦ |
modules/ ¦ |
presets/ ¦ |
extensions/ <--- |
io_* |
render_* |
mesh_* |
.../ |
addons/ <~~~~~~~~~~~
io_*
render_*
mesh_*
APPENDICE: BACKGROUND ABOUT BF-EXTENSIONS REPOSITORY AND PROBLEMS
Current situation
================================================================================
Currently we had a svn-external setup such as release/scripts/addon/ dir points to bf-extensions, like this:
bf-blender/
trunk/
release/
scripts/
addons/ <-- svn-external pointing to [1]
io/
keyingsets/
modules/
op/
presets/
templates/
ui/
[1] https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/addons/
Benefits
--------------------------------------------------------------------------------
Like this, people develop in bf-extensions svn and scripts that are in [1] go in release/scripts/addons.
Whatever we develop outside of bf-extensions/trunk/py/scripts/addons/ is ignored by bf-blender svn, so that we are free to develop in bf-extensions and move stuff in bf-extensions/trunk only when things are useful and stable.
Limitations
--------------------------------------------------------------------------------
When you do checkout bf-blender, you read something like:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ svn up
U release/scripts/op/io_scene_x3d/import_x3d.py
U release/scripts/op/io_scene_x3d/__init__.py
U source/blender/modifiers/intern/MOD_smoke.c
Fetching external item into 'release/scripts/addons'
Updated external to revision 1388.
Updated to revision 34281.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This means that svn go fetching addons in [1] and this takes a bit of extra time than having addons/ dir in bf-blender.
Problem
================================================================================
The svn-external property is limited to directories.
If we wanted to develop for example also io/ in bf-extensions, we would have to do this:
bf-blender/
trunk/
release/
scripts/
addons/ <-- svn-external pointing to [1]
io/ <-- svn-external pointing to [2]
keyingsets/
[2] https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/io/
but to checkout bf-blender we would get:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ svn up
U release/scripts/op/io_scene_x3d/import_x3d.py
U release/scripts/op/io_scene_x3d/__init__.py
U source/blender/modifiers/intern/MOD_smoke.c
Fetching external item into 'release/scripts/addons'
Updated external to revision 1388.
Fetching external item into 'release/scripts/io'
Updated external to revision 1388.
Updated to revision 34281.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
which would mean the extra time to fetch scripts would be doubled...
