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.
>
> - 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.
>
> - 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.
>
> - 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).
>
>
>
> 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).
>
>
>
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 27 17:14:47 2006