Christian Boos wrote: > Hello, > > I'd like to clarify the structure of the code repository by moving our > plugins to a dedicated place, instead of the sandbox: > > /plugins > /0.10 > /WebAdmin > /0.11 > /mercurial-plugin > /spam-filter > /0.12 > /spam-filter > /multirepos > /mercurial-plugin > >
As of r8950, this is now completed. > The sandbox would then only contain active branches, inactive or dormant > ones could stay in the /sandbox/Attic. > I kept the old plugin folders in the sandbox, they now only contain a README with an advise to "svn switch" to the new location. This will make things easier for those having svn checkouts of those plugins, as after an "svn up" they'll get that README instead of an svn error about non-existing paths... After a while, we can remove those folders entirely. For dangling links, there will still be the option to "search for previously existing path", in the corresponding Trac error page, which will lead to this (then) deleted README. I also keep in this mail the part of the original message that was explaining the purpose of maintaining those plugins on t.e.o, as some apparently missed it when they were asking why the plugins were not moved outside of the t.e.o repository: > ... > > The point of having some plugins here is a matter of commodity. We could > host plugins elsewhere (and I indeed have some in trac-hacks), but > having a few key plugins on t.e.o makes it more practical for a couple > of situations: when there's a change in the interface in trunk or in an > experimental branch that should immediately be reflected in the plugins, > or conversely when changes in the plugin need to be preceded by a change > in the interfaces. The primary example is the mercurial plugin, which > helped the evolution of our versioncontrol API to be more DVCS friendly, > and will continue do so in the future (merge, branch-y log, etc.). > > We could also use this as an alternative migration path if a small > plugin from sample-plugins grows, so that it can either become part of > tracopt (when it's an optional feature that just needs to be activated) > or a full-fledge plugins (e.g. if it needs more dependencies). > ... to which I'll add: - the convenience of keeping the full development history of those plugins, useful when doing a blame view, for example (the move to an other repository would have split the history in two) - no obvious advantage of /doing/ the move instead of continuing the development as usual on t.e.o, which has the advantages cited above -- Christian -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
