Tags:
archive_me1Add my vote for this tag create new tag
view all tags

Question


Much has happened since the discussion below. Please refer to SubversionReadme for up to date instruction how to use Subversion.

All plugins are maintained in one place only: http://svn.twiki.org/svn/twiki/trunk


Several plugins (those packaged with the release) are in the plugins CVS repository but also in the SVN repository. I'm confused as to the status of the different repositories. Where exactly is the master source? Some plugins actually have three sets of inconsistent source; the source in CVS, the source in the zip attached to the plugins topic, and the source in subversion.

Can we please, please, please rationalise this? The master source of a plugin should always be the source in the CM repository. The source should only be in one repository, and should be removed from the other to avoid confusion. The zip should always be generated from repository source, so should be a derived object.

TBH it doesn't make sense to me to have two different repositories. Why do we still keep plugins in CVS? (it's a PITA, IMHO).

-- CrawfordCurrie - 22 Nov 2004

If they are in a different repository, I see no problem. That way we can keep the plugin repository "open" enough, and restrict access to DEVELOP.

Or, if they are in the same repository/different branch, a script that check access right must be put in place.

-- RafaelAlvarez - 22 Nov 2004

Use a separate Subversion repository if you want to maintain separate access control and you don't need code sharing. You can have multiple Subversion repositories on the web server. If each plugin in maintained by a different author, it can be in a different repository. If you want to pull in common library code, look at the external mechanism.

-- KennethPorter - 23 Nov 2004

right now it is trivial to have different user rights in the same SVN repository - thats how the DEVELOP user accesses are done, so don't worry about that smile

-- SvenDowideit - 23 Nov 2004

Are plugins part of core or released as separate packages? If the latter, I'd recommend pushing the top-level trunk/branches/tag paradigm down a level and putting project names (ie. core and each plugin) at the top level. Take a look here: http://svnbook.red-bean.com/en/1.1/ch05s04.html#svn-ch-5-sect-6.1

-- KennethPorter - 23 Nov 2004

I was thinking with twiki @ svn/twiki, the plugins would be @ svn/twikiplugins, so its easy to grab all the plugins, and easy to wholesale branch plugins when there's a branch of twiki... though i do wonder if plugins shouldn't maybe be kept in svn/twiki/branches/DEVELOP/lib/TWiki/lib/plugins. that would ensure that there they can be easily tested together smile

I'd like to raise the suggestion that plugin authors with commit access should actually be DEVELOPer's with commit access, to remove the artificial seperation between the two, as both require similar skills and have similar resposibilities.

-- SvenDowideit - 24 Nov 2004

If you have fine-grained access control, you can give each plugin author his own tree with write access.

-- KennethPorter - 24 Nov 2004

  1. yes, we have fine grained access control set up using the http permissions system in Subversion

-- SvenDowideit - 25 Nov 2004

  1. define new svn based processes - including how people can get commit access, and how we integrate that access with DevelopBranch
    • I'm hoping that we can create a safe & secure way for the TWikiComunity to give its users commit access (rather than Peter & Sven being the major portal holders
  2. work out how we do the Release / Develop Branches for the plugins - especially when the APIs are as divergent as now

-- SvenDowideit - 22 Jun 2005

I'm assuming that the plugins/contribs will be checked into the same repository as the core, so we don't have to muck about with multiple repositories (which is doing my head in). Please tell me this is correct!

I have just put BuildContrib into SVN, modified as follows: tests are now in test/unit, as per the standard. I have removed the fixtures, as DEVELOP supports building test fixtures in the TWiki directly, DEPENDENCIES and MANIFEST have now moved to the plugin directory. TEMPLATE_installer.pl has moved to the BuildContrib area.

This is a bit of an upheaval, but it does mean that we can safely build plugins out of the same tree as subversion. All that is needed (WillNorris take note) is a manifest-driven build for building TWikiFors.

-- CrawfordCurrie - 29 Jun 2005

Yes. the TWikiPlugins will be running from the same repository - there will be "one version number to rule them all".

i'm assuming at the moment that we will put the plugins in

but this is still negotiable - i've only listed this as a starting point - please comment on this proposal!!!

-- SvenDowideit - 29 Jun 2005

I like that layout. Currently I found myself having the position to maintain a plugin for Cairo and develop the Dakar version of the same plugin, so I would propose a small change in the layout:

-- RafaelAlvarez - 29 Jun 2005

Having a Plugins branch is a great idea.

Putting the plugins that are converted into DEVELOP as a matter of course is NOT a good idea.

-- AntonAylward - 29 Jun 2005

Anton - i dissagree with you, but would you like to expand on your statement so we can see why?

personally i hope that the pluginarchitecture changes at some stage to allow the delivery of a plugins pack, where all plugins are installed, but disabled - which could be implememted by removing the magic search of the plugins dir (replacing it with a confgiuration setting that explicetly lists the plugins to load, and from where..)

-- SvenDowideit - 30 Jun 2005

Sorry, why do we have to have a different root? Why can't the plugins be in the same place as the rest of the code? I thought you said the plugins area could be selectively protected? I've been checking plugins into DEVELOP, alongside the core code, as it's the only option I have at the moment and I need a way to work with plugins in SVN right now!

I prefer to work directly in the current checkout tree. That should be perfectly feasible, and also desireable, as:

  1. any plugins that add files to other parts of the tree just get them ignored by the MANIFEST-driven release build,
  2. any changes they make to files (e.g. patches) need to be checked in and only applied when the plugin is installed, so there should never be a need for a plugin to touch a core file,
  3. all plugins are thereby automatically in the development tree, so when tests are run they are run with all (most) plugins in-situ, thus increasing feedback on errors and test coverage of the code,
  4. if plugins are that close to the core, it increases the probability that they will be properly maintained. No more hoops to jump through to get access to them.

BTW I totally agree with your statement above about replacing the magic search and enabling plugins from $TWiki::cfg.

  1. it would be a lot more efficient,
  2. it would be a lot more secure,
  3. it would be significantly easier to use,
  4. it would allow support of plugin config from configure,
  5. it would remove the need for local edits of plugin topics, which are currently written to a RO documentation web frown

-- CrawfordCurrie - 30 Jun 2005

OK - so to be totally obvious for me, you want the Plugins to be checked into subdirectories under http://svn.twiki.org/svn/twiki/branches/DEVELOP/lib/TWiki/Plugins/ and http://svn.twiki.org/svn/twiki/trunk/lib/TWiki/Plugins/ and therefore when we branch / tag the plugins will go with the release.

This is my favourite solution IFF I can run the plugins directly from an SVN checkout of the twiki .

but:

  1. what are the specifics of the layout

please - i'd like to hear more opionions, and reasonings :)

-- SvenDowideit - 30 Jun 2005


ok - Crawford & I talked it over on IRC, and here's another proposal

  • plugins go each into their own directory under http://svn.twiki.org/svn/twiki/branches/DEVELOP/lib/TWiki/Plugins/
  • we remove te preformance drain of run time discovery, replacing it with
    • $TWiki::cfg{Plugins}{MyPlugin}{Enabled} in LocalSite.cfg for each plugin
    • $TWiki::cfg{Plugins}{MyPlugin}{MyConfigVariable} for settings..
    • $TWiki::cfg{Plugins}{MyPlugin}{PmLocation} if the main pm file is not in the standard place.
    • initially this would be done by hand, but i'm sure someone can add a discover button on for the configure script.
    • this means that there can be a plugins section (tab?) in the configure script to allow the admin to edit the settings.
  • we insist that the file structure of a plugin is set
    • Plugins/MyPlugin/lib, Plugins/MyPlugin/data, Plugins/MyPlugin/ Please add more.. as needed
  • plugins have data that configure can use to determine if pre-requisites are met (see the web based install for CvsMonitor)
    • this will alow admins to satisfy plugin pre-requisitest without haing to run the plugin author's install script, and get environment feedback.
  • the end result is that we could provide a version of twiki that shipps with all plugins, and the user could enable any and all plugins by simply ticking / unticking a checkbox for each plugin. (using configure)

the development cycle would be

  1. svn co http://svn.twiki.org/svn/twiki/trunk (or DEVELOP)
  2. cvs trunk/lib/Plugins/MyPlugin
  3. edit away
  4. goto http://mytwiki/cgi-bin/configure, and enable the plugins that i want to test... (with indicators which i can't enable as they have unment pre-reques) (like GD, cpan stuff etc)
  5. commit changes.

This layout makes it trivial for PluginDevelopers to test and fix how their plugins interact with other plugins, and make its trivial for us to release a TWikiPluginsPackage that can then be unzipped, discovered, configured and enabled.

I can easily configure commit access to plugin developers to these directories...

-- SvenDowideit - 30 Jun 2005

I can think two reasons for having different roots for the "core" branches and the plugins:

  • Security Control: Plugins authors will need checkin access to the repo. That mean that if you want to prevent them to patch the core "accidentally" you'll need to configure security setting for each TWiki/Plugins directory in each branch (maintenance hell).
    • No - all we will do is give plugin authors commit access to the twiki/lib/Plugins directory. Subversion allows us a very fine grained control of who can do what in which directory. (this is how you have access to DEVELOP) -- SD
  • Release Control for Plugins: The same TWikiRelease can see several releases of the same plugin. As SVN manage "tags" as branches, there would be no way to mark a release of a plugin in the repo, unless the packaged Zip is uploaded someplace.
    • thats fine - there is nothing stopping us from adding a svn/twiki/branches/twikiplugins (or something similar)

I can see the advantages on Crawford approach, and actually there IS a way to have different roots for "core" and "plugins" and t have the advantages of having them under the same root: In SVN you can make a "link" between two directories in different roots (see http://svnbook.red-bean.com/en/1.1/ch07s04.html). This way we can have separate roots for the core and for plugins, and link lib/TWiki/Plugins, data/Plugins and pub/plugins directories in the trunk/DEVELOP branch to the plugins (or released plugins) root. So:

  • When you checkout the core, the plugins are checked out automatically to the same working copy.
  • If you commit the core, plugins are NOT commited. An explicit commit on TWiki/Plugins is needed for that.
  • Plugins authors do not need checkin privileges on the core.
  • If a plugin author want to make a release, he must do a svn copy operation on all the plugin-related files.

Note that this approach assumes that the plugins branch layout mirrors that of the core in the main development branch. Also, this approach won't work for addons, for those a "Branch-per-AddOn" approach is better.

-- RafaelAlvarez - 30 Jun 2005

Sven, Crawford:

I'm running a 'live' site.

Every time I do a svn up I get everything.

I get all those plugins I don't want.

I understand your points about a single store.

If I understand subversion correctly it is possible to set the svn location of each file.

I take this to mean that the basic DEVELOP branch can be minimalist. The kernel and the core plugins -- Default, Empty, Comment, Interwiki, Spreadsheet -- and only those 'essential' ones go there.

However on CrawfordCurrie's development machine at home, there are also the other plugins in the same directory tree. However their .svn files indicate that they go somewhere else.

As a result, this looks transparent to CC. He still does the svn ci. It looks transparent to me. I still do the svn up. But I never get the non-core plugins unless I specifically requre them. And once I do, I get the specific .svn information too, so my next svn up will get the updates.

But until I specifically request them they are not forced on me. right now they are being forced on me.

As the man said, so many years ago:

"We have the technology"
So why not let us use it in a way that doens't inconvenience others? (I.e. me)

-- AntonAylward - 30 Jun 2005

Your points are fair, Anton, and a good part of Sven and I's discussion related to this particular problem. As Sven is stating in the proposal above we are proposing to move the plugins into a separate tree, which would restore the status quo from your perspective, though it would introduce a new problem for you, as the CommentPlugin and other "standard" plugins will migrate out of the Core repository and into the plugins repository.

It was never anticipated (and still isn't) that end users would run directly off the SVN repository, so you are a rather special case; no less special for all that, but your environment is not typical, so we have to be careful about letting it influence the setup too much. Despite that I think what we are proposing should work better for you, as I guess you can use the svn links that Rafael describes within your SVN checkout area to pick and choose the plugins you want. The approach of having all the plugins in the same tree as the core has certain advantages for the developer, because it gives immediate feedback on unwanted interactions between plugins, but I can reluctantly live without that, despite the quality risk.

What we are working towards is a configure where you can select the plugins you want, and download and configure them all from the same interface. Anyone familiar with the firefox plugins support will have an idea of where we want to get to.

-- CrawfordCurrie - 30 Jun 2005

Rafael - i don't like SVN links as much, as i'm hoping that with more regular releases, we'd tag core and all functioning plugins at once, and I really would like to encourage developers to work on fixing everything, and not just check out the small part (that the core is)

Anton - yes, you get all the plugins, but they are all disabled - which is the same as you would get if you installed my mythical try-TWiki-out system that has all plugins (but also disabled)

we're trying to re-jig the way twiki development is done by making it clear to the developer that they are responsible for the entire system (in a way i'm deprecating the importance of the core - as it is an enabling technology)

wrt Addons - we have alot of work to do before they can be dealt with in a maintainable and extendable fashion. however, the current system fails badly (what do you do when both addons want to replace the view script?) and have you seen TWikiCacheAddon?) - its going to be better to force them to conform to the plugin layout, and then to re-do how addons work so they too can be called dynamically (which is made easier by the UiDotPm work that CDot did)

-- SvenDowideit - 30 Jun 2005

For the interested reader, Sven and I don't see eye to eye on the Add-Ons point. I see add-ons as a mixture of subclassing, injections into the chain of responsibility, and factoried objects, to mention but a few of the patterns. Trying to force add-ons to conform to a single rigid pattern is never going to work.

-- CrawfordCurrie - 30 Jun 2005

actually - i suspect we do see eye to eye Crawford smile - the thing that will not work in the current model (and is un-necessary) is the adding of files to the cgi-bin dir. Instead it is quite possible for the core to support the subclassing / calling of addon code from a distributed script - through more configuration..

for eg, instead of TWikiCacheAddOn replaceing view, our architecture should be able to have the view script know from config that instead of calling TWiki::UI::View() it calls TWiki::Plugin::TWikiCacheAddOn::View()

or even better - as you say, it would use subClassing to acheive the same thing. (either way we neatly sidestep the current issue where addons have file level conflicts)

-- SvenDowideit - 30 Jun 2005

Sven: It seems that we don't have the same concept of what a "tag" means in the TWiki world. For what I understand from your comment, each tag correspond to a TWikiRelease. For me, tagging the TWikiCore means: "we finished the base for this TWikiRelease. Packagers, start packaging", while tagging a TWikiPlugin means that another version was released.

IMHO, when "tagging" the TWikiCore, the Plugins shoulnd't be "tagged" as they actually live in different development lines (the same version of a plugin can work on several versions of the core, and viceversa) That's true even for the "core" plugins (perhaps with the exception of EmptyPlugin).

-- RafaelAlvarez - 30 Jun 2005

If this means that I have to set up my suytem with the .svn files to pull some plugins form the plugins part of the tree, so be it.

What I don't want is to have everything pulled. The idea of pulling everyting but having the plugins disbaled in TWikiPreferences is too prone to an oversight error.

-- AntonAylward - 30 Jun 2005

Oh, and by the way.

Forget about designing with the assumption that the sources will be pulled and then configured.

I'm already running a live, configured system!

In fact anyone who has been running Dakar for a while probably doesn't want to wipe it all and run configure every time he does an svn up..

-- AntonAylward - 30 Jun 2005

Anton, while i symapthise - DEVELOP is NOT the same thing as a DakarRelease. Dakar is expected to be released from the DakarReleaseTag, and DEVELOP will continue on after that... (the plan is for the DEVELOP branch to be merged into the svn/twiki/trunk and then the new release tag would be made from there.

(we do need to be able to inconvenience people running DEVELOP to improve the long term layout of the system)

though i must admit that if possible we will not kill your curent setup when we make this sort of change (you are being overly dramatic smile )

-- SvenDowideit - 30 Jun 2005

I did an experiment. I changed Plugins.pm and Plugin.pm over to using an Enabled flag from TWiki.cfg and moved plugins discovery to configure. Works like a charm, except that the current (Cairo) tags for managing plugins no longer function - specifically INSTALLEDPLUGINS and DISABLEDPLUGINS. I can't think of any way to automate the upgrade of these tags. Is this a big problem for people?

I wish we could get rid of the need to read the plugin topic in the TWiki web, though. It is now the next biggest time-chomper in the initialisation process, after compilation of the plugin itself.

BTW as a side-effect of the way I did it, you don't actually have to have Plugins in the TWiki/Plugins directory any more. You could actually put them anywhere......

-- CrawfordCurrie - 02 Jul 2005

Brilliant smile I'm sure we can think of something that will remove the plugin topic read & a once off script to troll the INSTALLEDPLUGINS / DISABLEDPLUGINS (that would be a job for the upgrade Sctipt right?)

-- SvenDowideit - 02 Jul 2005

Clarification: for the sake of simplicity, we are proposing the following structure in the SVN repository for MyPlugin:

While this isn't ideal, it does minimise the amount of extra work we have to do to make this happen.

-- CrawfordCurrie - 05 Jul 2005

this does not address any of the things that i want - but Crawford tells me that what i want requires too much code change for Dakar frown

-- SvenDowideit - 05 Jul 2005

What's the status of this?

Anyway, there is one issue that I don't see (explained) how will be managed in SVN: How to manage the "release" of different version of a plugin? More so, how to maintain a version for Cairo and a version for Dakar while developing a version for Edinburg (for example)?

-- RafaelAlvarez - 14 Jul 2005

after maturing the idea a little more, I think it's implicitly stated that the plugins for a release will be in http://svn.twiki.org/svn/twiki/trunk/plugins/ and http://svn.twiki.org/svn/twiki/tag/RELEASETAG/plugins/

Am I right?

-- RafaelAlvarez - 14 Jul 2005

yep smile that way stuff can be tracked together with a release, and will have some small chance of being tested if changes are made to that release.

-- SvenDowideit - 14 Jul 2005

Good! cool!

-- RafaelAlvarez - 15 Jul 2005

ok, i'm "done" checking the plugins into CVS.

there are a few stragglers and some topics which don't even have a plugin/addon attached to them... a lot of the remaining stragglers are vbscript stuff for office and no place in the hierarchy to put the files and i'm not qualified to know where they should go, either...

see PluginsInCVS for a "concise" status report (note that that topic does generate a lot of false negatives, including *Dev topics and ObsoletePluginPackage et al topics)

btw, here's a list of the plugins/addons which haven't been checked into CVS:

ApplicationAuthenticationAddOn, CopyMsOfficeTableAddOn, DiscussionForumAddOn, EditorDaemonAddOn, ExcelExportTwikiTableAddOn, ImmediateNotifyPlugin, IndexServerSearchForMsIisAddOn, JSCalendarAddOn (only contains patches), MailInAddOn, MultiSearchAddon, MsWordToTWikiMLAddOn, PerlSamplePlugin, PopUpCalculatorAddOn, ProgramsPlugin, SwiPrologToPostgreSqlAddOn, TWikiSDKAddOn, WebServicesAddOn, WorkFlowAddOn

(no attachment on plugin page) EditTWikiExternalEditorAddOn, GuestBookPlugin, MozillaSidebarAddon, ReStructuredTextPlugin, ZwikiToTWikiAddOn

(oh, and i haven't checked in any of the skins which weren't already checked in)

-- WillNorris - 19 Jul 2005

  1. download the backup/dump of cvs for twikiplugins from http://cvs.sourceforge.net/cvstarballs/twikiplugins-cvsroot.tar.bz2
  2. add a broadcast message (as i can't edit the page) to Plugins.WebPreferences telling/asking people not to checkin files to CVS during the transition, and that after the transition, SVN should be used instead
  3. it would be preferable to also lock down CVS, but i don't know if sourceforge provides a mechanism to do that or not
  4. cvs2svn
  5. import into SVN
  6. update docs
  7. send out email to all plugin authors letting them know of the change
    • also encourage them to checkin plugins which haven't been checked in
    • and, generally, tidying up the plugin and dev pages, including bringing good patches up-to-date w.r.t. the SVN repository
    • and, and, making sure the .zip is up-to-date, produced from the SVN sources
  8. grant plugins authors write access to the twikiplugins directories

-- WillNorris - 21 Jul 2005

Something just dawn on me: The plugins that are "packaged" with the core (EditTablePlugin, CommentsPlugin, etc) will be maintained in it's own directory (twikiplugins/EditTablePlugin) or where they are now (lib/TWiki/Plugins)?

-- RafaelAlvarez - 22 Jul 2005

they will be moved into the new structure

-- CrawfordCurrie - 22 Jul 2005

on SubversionReadme, BillSkellenger wrote:

"I did a SVN checkout of the DEVELOP branch, but didn't want all of the plugins, so I ended up checking out the root directory (svn co -N) and then individually checking out lib, bin, and templates, using data and pub from my working site."

This is the same issue that AntonAylward was describing.

That got me thinking: I don't mind to inflict all the plugins on DEVELOP users, but after we release, how will a DakarRelease user perform a svn up without downloading all the plugins in the process? Will we provide a script to perform the "selective =svn up=" as described by Bill? Would the installer take care of it?

-- RafaelAlvarez - 22 Jul 2005

they can individually svn up lib, bin and templates, and simply not svn up twikiplugins, I guess.

-- CrawfordCurrie - 22 Jul 2005

So, is up to the TWikiAdministrator to be careful enough not to do an svn up in the root of the TWiki installation?

-- RafaelAlvarez - 23 Jul 2005

Aye

-- CrawfordCurrie - 23 Jul 2005

Synching with all the plugins has become unacceptably slow.

I also think that it is not a good idea to require the TWikiAdministrator to synch multiple directories separately. The plugins should be in a separate repository.

-- ThomasWeigert - 06 Aug 2005

Also, having the plugins that "ship" with TWiki not in the appropriate places for the plugin to load is not appropriate. What does a user now have to do to get a plugin to supposedly comes with TWiki to work?

-- ThomasWeigert - 06 Aug 2005

there has been a change to from the ideal last week, and now for developers that run from svn, there is a mklinks script (one in shell, one in perl) that make linkes / copies of the plugins into the old structure, and from what I understand, we are going to be building the release with the plugins in the CairoRelease location.

the reason for this is that we simply have not solved all the issues that are created by moving their location.

I personally am strongly against moving the plugins into a seperate repository - I contend that a small amount of pain for developers will reap benifits wrt testing - in fact, because it was trivial to do so I have tried quite a number of plugins in the last week, and have fixed a few issues that they had. If they were still in a seperate repository, this would never happen.

please remember that ALL the upheaval is happening only to the people that are developing (ie using the DevelopBranch from svn), and none of the problems that you are talking about are intended to occur in the final release.

Also: I am quite strongly against the idea that the release contains .svn dirs - this not only clashes with debain policy, but worse, makes it incredibly difficult for an admin to commit the tool they are managing into their own svn repository (which is one technique I use for Configuration Management)

-- SvenDowideit - 06 Aug 2005

Sven, agreed on not shipping .svn dirs. That would be a huge nuisance.

However, I cannot agree with your statement about the separate repository. Nothing that you cite above as pros for having the plugins in the same repository as the core code really holds water, I think (unless by separate repository you mean one in CVS and the other in SVN).

It is fine having everything in SVN, but an update in the core directory should not trigger an update of all the plugins. I strongly think we need to have the following structure:

  • /twikiroot
    • /twiki
    • /twikiplugins

This would give the best of both worlds: If you want to keep everything updated, then go to /twikiroot. If you want to update only the core, then go to /twiki .

I find it completely unacceptable that I need to scan the huge plugins directory just to be able to update the core. I am not willing to accept the "little pain" you quote above, for no apparent benefit.

Please explain what problem the current situation solves that my proposal would not solve. Otherwise, please move the directories accordingly.

-- ThomasWeigert - 06 Aug 2005

Further, it is inappropriate to require that an Item label from the Bugs web has to be given when checking in updates to a plugin. If we want plugins to be maintained on SVN, we cannot put inappropriate barries up.

-- ThomasWeigert - 06 Aug 2005

excellent point, thomas. we should not require that checkins to the twikiplugins area be subjected to LockDownDakar restrictions.

-- WillNorris - 07 Aug 2005

actually, we were wondering when someone would 1) realise it, and 2) when someone would actually be affected by it..

please understand that my opinion only counts as much as each of you. This means that if you get a 'number' of people agreeing with you, I will implement it (even if i dissagree (which i don't exactly))

-- SvenDowideit - 07 Aug 2005

Thanks, Sven, but you have not answered my question. What is wrong with the proposal that I made of organizing the sources as follows:

  • /twikiroot
    • /twiki
    • /twikiplugins
I believe that my proposal would make everybody's life easier.

If you read the whole topic, you will find that the following have made similar proposals: KennethPorter, RafaelAlvarez, AntonAylward. How many more do you need to accept that the current way is not acceptable?

-- ThomasWeigert - 07 Aug 2005

Thomas, sorry, I was rushing to reply while at Wikimania, so missed the important part of your post. frown

the Crux of the layout we have now, is to ensure that TWikiPlugins are tested and maintained by those people that take the responsibility of becoming involved in DevelopBranch. It was not intended to be convenient (by me at least), but rather an 'in your face' reminder that existing TWikiPlugins are not able to be considered as secondary when changes are made by Developers. Similarly, for testers of the live DevelopBranch, it is to make following the entire DevelopBranch (which has to include the development head of TWikiPlugins).

When we release, there are currently intended to be a considerably reduced group of TWikiPlugins to be shipped, and for now, the layout is expected to be like that of Cairo (as we don't have time to complete the re-organisation at the moment).

i notice that you say 'similar' proposals, and I guess that makes it reasonably obvious that those of you who dissagree need to refactor them into one unified proposal, thus trumping the opinions of those of use who support this one smile

I'm similarly aware that I/CDot/Will need to refactor thie information of what actually IS implemented, but we are truly struggling with the choice of working on Develop, or working on TWiki.org (have you seen how huge the bugs list is?)

I also wonder about the slowdown you are refering to, as after the first initial checkout, my svn up's appear to be as fast as they were previously (but my system might well be different from yours)

-- SvenDowideit - 08 Aug 2005

Every operation on svn needs to scan the whole tree and that takes forever on my system. Doing a diff or up is unacceptably slow.

I must also say that your arguments above don't resonate with me. Basically you are saying "let's annoy everybody, maybe they will look at the plugins". In fact, just forcing everybody to check out the plugins will not cause anybody to look at them, I would think. Also, it is no more in the face than in my proposal, but wastes everybody's time.

Also, I find it somewhat upsetting that you would require me to assemble a party that votes against the setup somebody (it is not even clear to me who) has imposed on us without having any reasonable support for the current setup.

And you still have not told me why my proposal above would not accomplish the same thing as the current implementation, without the nuisances associated with it.

-- ThomasWeigert - 09 Aug 2005

ok, i think I have only one more thing to say on this matter, and that is this:

stop debating, and simply change it. you have commit rights, and in subversion it is trivial to move directories. I personally try to make sure that I 'feel' (i know this is fuzzy) that I have the support of a large enough group of the people actively working on DevelopBranch (and I do give significant, and possibly too much precedence to those commiting) to feel comfortable (as I want to avoid imposing 'my way' on them, but other than that, the idea of Develop is that all Develop'ers work together to do stuff. I am not supposed to be important in this process - it is entirely up to you guys (where to me 'you guys' means those people actually doing the work!)

the current setup was developed by me, Crawford and Will, though quite honestly, we all dissagree with parts of it, but we are not trying to be perfect, just simply to have a start that can be refined as people figure out issues.

as you can read in the history above, we are trying to

  1. increase the testing of TWikiPlugins
    • I now have more plugins enabled all the time, so there are more plugins that I will notice what breaks, and I am more likeley to fix those i've enabled and commit the fix
  2. we want to have TWikiPlugins relevant to each branch with the branch in some way.

there might be more, but Crawford and Will will have to remind me smile

-- SvenDowideit - 09 Aug 2005

Thanks, I did not realize that I had rights to move directories around.

On the plugins, I agree that it is good to have them in subversion, but I still don't understand how they end up in the right place. They are all in the /twikiplugins directory, but to be active, they need to be in the right place within the /lib and /data (and maybe /pub) directories. How does this happen (other than be manually moving them)?

-- ThomasWeigert - 09 Aug 2005

Thomas, that happens using the mklink script (either shell or perl versin), that can either create symlink or copy the content of the plugin directory into the twiki installation.

OTOH, I still think that having two separate roots/directories/whatever for twiki and twikiplugins and using the repository link described in the Redbook is the best approach. That way, people doing svn co will get the whole stuff, but doing svn up, svn diff and svn ci will operate only on the right root (svn up in twiki will update only twiki, not twikiplugins).

On of the "dangers" with this layout is that you can accidentaly update a plugin in the repository when doing an svn ci, or worse, update the core when you just want to update a plugin. With separate roots linked at the repository level, this just can't happen.

-- RafaelAlvarez - 09 Aug 2005

> [...] how they end up in the right place. They are all in the /twikiplugins directory, but to be active, they need to be in the right place within the /lib and /data (and maybe /pub) directories.

Actually I think the key here would be a new store (for data/pub) and a rewired plugins.pm (for lib) - this would provide both a clean separation of TWiki and its plugins and easy working with SVN

-- MartinCleaver - 09 Aug 2005

one of the dangers of giving anyone checkin rights is that they don't check carefully and properly what they are checking in. this applies irrespective of whether twikiplugins is in the same space as twiki.

but hey, personally i like the current setup, and recon that the time to do an svn up is more to do with having a too small server running an svn repository thats getting bigger all the time.

-- SvenDowideit - 16 Aug 2005

But the danger is greater if:

  1. There number of people with checkin rights increases too much (like giving checkin rights to casual plugins authors so they can maintain their plugins)
  2. The changes can be over several directories. On my development machine at work, I have changes to the SEARCH tag, to Forms (waiting for EdinburghRelease), changes to some "abandoned" plugins, changes to BuildContrib and changes to TWikiShellContrib. I have to maintain them on separate checkout areas (one for each core changes, and one for the plugin changes) to prevent any mishap doing svn ci on the root.

If DEVELOP and twikiplugins where separate roots (linked in the Subversion way), doing a svn ci at the root would be safer to do.

Notice that I like the layout too (twikiplugins under the twikiroot), my complain is that hey should be separate svn roots with a link between them.

-- RafaelAlvarez - 16 Aug 2005

  1. like i said before, plugin authors will not be given rights to anything but the twikiplugins dir.
  2. you really really need to start specifying each file that you check in, otherwise you are always hoping that you don't check in something unintentionally. this applies irrespective of whether the plugins are in a seperate place to the core code of not.

from what you've said so far, seperating out twikiplugins is a crutch because you are not appropriately careful when you check in.

i'm awfully sorry if i'm not symapthetic to this reasoning

-- SvenDowideit - 17 Aug 2005

well, having (1.) at mitigates a lot of the risk. Doing a svn ci on root will get you an error message from the pre-commit hook and rollback the whole thing.

Having different separate co areas for each functional change to the core (and it corresponding change to plugins if needed), and one exclusive to work with (all) plugins has the advantage to allow you to test your changes in a clean enviroment.

Anyway, I'm happy with the way I'm working, I'm happy with the layout, and I'm happy that the plugins will have one branch per release, so I'll stop complaining about it's implementation.

-- RafaelAlvarez - 17 Aug 2005

Just occured to me: Will plugins authors have access to all the twikiplugins directories in all the branches (trunk, DEVELOP, tags(?))

-- RafaelAlvarez - 17 Aug 2005

yes

-- SvenDowideit - 24 Aug 2005

Edit | Attach | Watch | Print version | History: r80 < r79 < r78 < r77 < r76 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r80 - 2008-09-15 - TWikiJanitor
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.