we could have done this from the beginning, but lets better do i now than later.
with already 8 plugins written (and i know of some more that just have not yet been checked in) the repository is getting a bit messy so i added a structuring hierarchy based on node categories and i would like the individuals responsible for the codes move their nodes as follows:
via TortoiseSVN->Repo-browser you can simply drag/drop your nodes directory to its new destination
then on your locally checked out version of the node TortoiseSVN->Switch: just enter the new url
note that when now opening your solution it will not find the _PluginInterfaces and _Utils projects (they appear grayed out). RightClick-Remove them and RightClick-Solution-Add those existing projects again
now in your projects References also don’t forget to remove the old references (which the compiler would complain about not being able to find them) and add the references to the \Projects: _PluginInterfaces and _Utils again (which are now one directory up of your nodes directory)
saveall. see if it builds and commit your solution/project to have the changes reflected in the repository.
if you have troubles doing this please come to ##vvvv on irc.freenode.net to discuss.
following the same thought: would it be possible to (automatically) create some kind of inventory at top level which lists all the plugins in development/available and a short function description (maybe from a readme file in the plugin’s dir)?
this would facilitate oversight and a plugin newb like me wouldn’t have to dig/crawl through the SVN to find out the names of some plugins, and the guessing functions and capabilities.
also, maybe a collection of the plugins’ dll’s in their latest compilation, which you could link to in the bazaar/download section similar to user modules, patches, shaders?
@bilderbuchi: agreed. for now it is a mess. but please give us some time in that respect. am still thinking about a way for best practice to make plugins available for endusers.
hello,
i think this has already been suggested in some thread, but i can’t find it right now. anyway, how about restructuring the repo so that under plugins/, there is one trunk/, with ready-for-release, tested versions of all plugins, then something like plugins/branches/dev, where more experimental things could take place? the advantages:
possibility to checkout the whole trunk/ without breaking references
if trunk/ is guaranteed to be stable, then we could use a build script like vux’s to have the addon pack update itself automatically. would also make it easier to figure out when to set off the automatic creation of reference pages, as suggested here (option 2) :)
we are actually aware of those troubles and are working on them. probably we’ll be able to circumvent the restructuring of the whole repo by providing simple scripts to get the right things downed easily with only a few clicks.
also the process of creating referencepages for addons is still being discussed. bear with us…
