A final precision on this subject ... On Wed, Nov 13, 2013 at 3:08 PM, Olemis Lang <[email protected]> wrote:
> > > On Wed, Nov 13, 2013 at 3:44 AM, Olivier Mauras <[email protected]> wrote: > >> On 2013-11-12 21:41, Olemis Lang wrote: >> >>> >> >> [...] > > ... but yes , there is a reason and it's due to the Trac vs product admin >> roles mentioned above . Trac repository connectors operate on repos cloned >> in the local file systems (or equivalent ;) therefore adding a new one >> happens outside the web site boundaries is more like a task of site admins >> >> I don't think this matters much. Even if the product owner doesn't have >> access to filesystem this shouldn't prevent him to enter a path given to >> him by the "bloodhound server admin" >> > > I do think this matters . I'm not very fond of publishing server paths > (... neither do the admins in my team ;). By establishing a convention > (e.g. /opt/vcs/<vcs_type>/<repos_name> where vcs_type = hg | svn | git ... > ). The product admin wouldn't even need to worry about server-side > filesystem paths ; they'll only need to know the vcs type and repos name . > That's just an example ... > This should not be interpreted as a limitation of Bloodhound core but the lack of a repository provider providing support for such a FS layout ... > > In any case the current implementation still implies that only TRAC_ADMIN > users may create new repositories, and always outside web UI . IMO it would > be nice to integrate those operations too in forthcoming releases for an > enhanced user experience . Nonetheless in order to do so new (or enhanced) > entry points will be needed . > ... as opposite to this , which requires an upgrade . -- Regards, Olemis - @olemislc
