Hi Eric,
Thanks for your email.
Yes, there are a multitude of possible configuration combinations out
there... I feel the key with developing a tool like this would be to
define (at least initially) a standard way of providing a well defined
set of basic configuration. Trying to do everything at once is a recipe
for disaster. Hence, my initial suggestion of only managing repos served
via HTTP/HTTPS, as these access methods are not dependent on
WIndows/*nix. However, making such a tool extensible such that
particular individual cases can be implemented where reasonable to do so
at a later date (as plugin config modules for example) would be a design
goal.
Obviously one can't support every configuration permutation, but that
doesn't mean we shouldn't try to produce something that provides usable
configurations in 80% or perhaps even 90% of situations. I don't
envisage this tool removing all need for shell access and manual
tweaking in rare/unusual cases. I'd hope it would take the monotony out
of every-day Subversion administration tasks that we all do with our
eyes closed and wished we could give a trained monkey the controls to,
without giving them shell access. I feel this is very achievable.
For example, at my work, I am the only person familiar with command line
svn server admin. However, if I could give the svn users at work limited
rights to create their own repositories and manage permisissions to
those repositories themselves via a nice web interface, it would
simplify things greatly.
Integrating with something like Active Directory on windows is extremely
platform specific, and would not be something I would suggest this tool
try to integrate with initially. Perhaps writing a Windows specific
module for the project at a later date that did interface with active
directory would be how I would see such support being added. The core of
this tool should, as far as I can tell, be platform independent, as the
concepts of directories, repositories, users/groups, permissions, and
some svn access methods (e.g. HTTP/HTTPS) are inherently cross-platform
themselves.
I personally haven't run a windows based subversion server, so I'd love
to get more input from you and others about your experiences doing so
and your thoughts on what could go into a web-based server management
tool that aren't 100% windows specific (or if you have 100% windows
specific ideas, list them separately...)
I hope to distill all the ideas that come out of discussion on the list
regarding this topic into some form of project web page... so there
could be a sub section for platform specific ideas.
Regards,
Lawrence
Eric Lemes wrote:
> Hello Lawrence,
>
> I'm interested in such tool too. I think the great problem here is
> that too many different svn configuration exists, any of these
> reflecting some user needs.
>
> In my case, I have a windows server. So, it's integrated with AD. My
> hook scripts, uses some e-mail addresses that's already configurated
> in AD too, I think I can "re-generate" this post-commit hooks with the
> web based configuration.
>
> Many other people has many other kind of hooks too, and I think
> there's too many differences between Windows/Linux and other OS's
> servers...
>
>
> Eric
>
>
> On 11/26/06, *Lawrence Stewart* <lstewart@room52.net
> <mailto:lstewart@room52.net>> 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.
>
> - 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
> <mailto:users-unsubscribe@subversion.tigris.org>
> For additional commands, e-mail: users-help@subversion.tigris.org
> <mailto: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 16:02:45 2006