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.
- 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
- 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.
- 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.
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
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Nov 26 08:25:56 2006