Hi Rob,
Thanks very much for your reply.
See comments in-line...
Rob van Oostrum wrote:
>
> On 26-Nov-06, at 2:25 AM, Lawrence Stewart wrote:
>
>> Hi all,
>>
>> Further to an initial email I posted to the list on the 25th Nov,
>> I'd like to start a thread to discuss this idea further. I feel such
>> a tool, with more functionality than the current offerings, could be
>> extremely useful to a lot of people out there, and would also fill a
>> current need that I have. As such, developing it as an open-source
>> project would, I feel, be beneficial to the Subversion community,
>> and so this email is to try and get the ball rolling.
>>
>> The idea has been percolating in my head since the beginning of this
>> year, but I've only been able to find the time now to really begin
>> making steps towards getting the project off the ground. I'd really
>> like to get ideas from everyone out there to form some basic
>> requirements for the project. From there, selection of
>> implementation technologies and perhaps expressions of interest from
>> people interested in getting involved in some shape/form would be cool.
>>
>> So to seed discussion, here are my initial thoughts and ideas that
>> I've jotted down and in some cases researched over the past year (in
>> no particular order):
>>
>>
>>
>> - Must be web based.
>>
>> - Should at a minimum manage the configuration of repos served via
>> HTTP/HTTPS, but be extensible to be able to mange repos served via
>> other means in the future.
>>
>> - Should provide most (if not all) the standard things you can do
>> with svnadmin, and perhaps some things you would do in a shell e.g.
>> repo deletion, etc.
>
>
> Repo deletion through a web interface should probably be implemented
> as moving a repository to a non-hosted 'to-be-deleted' directory. The
> whole premise of a version control system like SVN is that nothing
> you do is non-reversible (especially deletion). Nothing is ever
> permanently gone. Adding hard-deletion capability to something as
> inherently non-secure as a web interface would not really jive with
> any operational common sense IMHO. Not physically deleting repos
> would also leave the possibility of un-deleting them at some point.
>
This is a great idea... it certainly fits in well with the Subversion
"ethos" and shouldn't be difficult to implement either.
>>
>> - Should be able to simplify repo level tasks e.g. setting up
>> certain hooks (perhaps have a couple of nice automated web frontends
>> for common hook configuration, and provide a generic interface to
>> allow custom hook creation)
>>
>> - Provide some sort of user class/permissions system. e.g. a site
>> admin controls the interface itself and can do everything, repo
>> admins could be given rights to create/manage repos at a certain
>> point within a directory hierarchy for example, a backup user class
>> could be granted rights to perform dump/restores of repos
>>
>> - Should support hierarchical directory and repo layout and
>> permissions based on that hierachy e.g. if we said /home/svn was an
>> svn "root dir", then from the management interface, we should be
>> able to create a normal directory /home/svn/container and also
>> create a repo /home/svn/container/repo1, and perhaps create a
>> subcontainer normal directory /home/svn/container/subcontainer. Then
>> we could do things like allow user1 to create repos/new directories
>> that live in/below /home/svn/container/ and user2 could only be
>> given rights to create repos that live in /home/svn/
>> container/subcontainer.
>>
>> - Should manage repos served from multiple directory trees on the
>> local filesystem. i.e /home/svn could be a "root dir", as could /
>> home/user1/svn and /home/user2/svn. Each of these root dirs could
>> then be used with the hierarchical directory and repo layout
>> discussed in the previous point. All of these root dirs should be
>> able to be managed from the interface.
>>
>> - Should provide full user management support i.e. create/delete
>> users, assign users rights to repository access, assign permissions
>> to users in terms of what they can do via the interface
>
>
> You should consider LDAP support here.
>
In what ways are you thinking LDAP should be integrated? I think this is
an interesting idea, and given the flexibility of LDAP, could bring some
useful benefits. Would you be thinking LDAP could be used as a potential
user/group/permissions "backend" instead of an SQL DB for example?
>>
>> - Should integrate with existing repo browsers. I currently use a
>> manually maintained HTML front end that provides links to my HTTPS
>> repos and websvn front end to view the repos. I think having a
>> mangement tool that could provide config to an external repo browser
>> to allow a newly created repo to be visible in something like websvn
>> would be extremely useful. Making this extensible to allow other
>> repo browsers e.g. viewvc, etc. would be awesome.
>
>
> Leveraging SVNParentPath here would greatly simplify this type of
> thing. Any need for layering/categorization in terms of who can
> create/manage which repositories where could be isolated to the web
> interface layer to simplify some of the underlying implementation
> details. Keep in mind that adding repositories any other way will
> involve Apache configuration changes, which involves restarting
> Apache, which you really shouldn't make available through a web
> interface.
>
This is obviously a must for repos that are served via HTTP/HTTPS. I
would also, during the design, like to try and figure out how to make
this extensible so that eventually, support for repos served via
svnserve for example could also be (somewhat?) managed using this tool.
Having not really used access methods other than FILE, HTTP and HTTPS,
I'm not sure how much management could be made available in a web
interface for repos served via svnserve, svn+ssh etc.
>>
>> - Should be as widely accessible and deployable as possible. This is
>> definitely a "well duh" point, but it does have some impact on
>> things like implementation technologies, that I know I said wasn't
>> the focus of this email, but I've been investigating possibilities
>> nonetheless. Using a development framework would, I feel, make sense
>> for such a project. In terms of what technologies would allow most
>> people to make use of this project on the widest range of platforms
>> and with minimal additional effort, I shortlisted Ruby on Rails and
>> CakePHP. I'm not fixed on either of these by any means, but just
>> throwing them out there to let you know what I've been thinking.
>
>
> - If this interface is going to give access to so much, security is
> obviously going to be a big thing. Not knowing as much about Ruby or
> PHP I can't speak to how much of that is available out of the box,
> but I would recommend you add Java to that list if for no other
> reason the availability of the Spring/Acegi declarative security API.
> Why reinvent the wheel? As valid as you requirement to appeal to an
> as-wide-as-possible audience is, I don't think it should be THE
> requirement, and it's not like Java would be an obscure choice nor
> would it be all that difficult for anyone to run. Spring would also
> help swap certain implementation variations in and out (think OS-
> specific support, different authentication mechanisms - AD, LDAP, etc).
>
Security is indeed going to be an extremely important factor with such a
tool. I haven't done any server side web based dev in Java, but I'll be
looking into it and investigating this Spring/Acegi declarative security
API you speak of. Consider Java added to the candidate list :)
Whilst mass-appeal is, as you say, perhaps not THE requirement, I still
think it is very high up on the list... this is all stuff I think needs
to be worked out a bit later though once all the ideas have been fleshed
out.
>>
>>
>>
>> For some slightly more abstract, perhaps crazy/unnecessary ideas...
>>
>> - Could have some nice usage/commit graphs, stats pages, per user
>> activity stats... something of that nature would be cool.
>>
>> - Could also integrate somehow a front end to configuring automated
>> build/test environments
>
>
> - integration of unit test, code coverage etc. reports with revision
> history (i.e. a continuous integration build runs after a commit, and
> the results of that build are cross-referenced to the repository URL
> @ revision that was built)
> - open and modular API to allow for extension with other types of
> tools based on the same platform (e.g. issue tracking with cross-
> references to revision history a la Trac).
>
I like it. Being up the more "if there is lots-o spare time" end of the
ideas to implement spectrum, they may not see the light of day for a
while. But coming up with these sorts of ideas now still helps with some
longer term goals and thoughts which is cool. Very happy to hear more
ideas of this variety.
>>
>>
>>
>>
>> It may turn out that extending a tool like SVNManager is the way to
>> go, or it may be better to leverage code snippets from SVNManager
>> into a new project... not sure. As I said though, I'd like the ideas
>> to be discussed first irrespective of what already exists
>> implementation wise. This will ensure we don't limit creativity in
>> terms of what we could get out of such a tool, and will help make
>> the decision about how to implement the project more justifiable
>> later (if an idea we come up with is just not possible to implement
>> in an existing tool easily, we can justify creating a new project
>> for example).
>>
>> I think that's a decent start... I am by no means a Subversion guru,
>> so I'm sure I've missed obvious and useful things that others will
>> think of. I'm therefore very much looking forward to hearing back
>> from anyone/everyone, getting some discussion going, and perhaps
>> fleshing out or adding more points to my initial list of ideas.
>>
>> Cheers,
>> Lawrence
>>
I'm still very interested to receive and discuss input from anyone else
out there, so keep the ideas rolling in.
Cheers,
Lawrence
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 29 03:13:49 2006