You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Lawrence Stewart <ls...@room52.net> on 2006/11/26 07:25:14 UTC
New web-based Subversion server management tool
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
Re: New web-based Subversion server management tool
Posted by Vagmi Mudumbai <va...@gmail.com>.
This would definitely be a great idea. I was infact working on a similar
concept for one of our internal tools and I am desperately trying to get the
Ruby bindings built on windows to achieve that. I am using Ruby on Rails.
Most of this project is still vaporware. In fact, I am still working on a
proof of concept which can only be possible if I ever manage to get the ruby
swig wrapper built. :-) We have some Windows specific functionality. I am
using John Lam's www.rubyclr.com to bridge the gap. I am not sure how this
would scale but I just hope that it works. If not, I would drop the RubyCLR
idea and simply work around it.
Your ideas are most welcome.
On 11/29/06, Rob van Oostrum <ro...@blastradius.com> wrote:
>
> > -----Original Message-----
> > From: Lawrence Stewart [mailto:lstewart@room52.net]
> > Sent: Tuesday, November 28, 2006 9:13 PM
> > To: Rob van Oostrum
> > Cc: users@subversion.tigris.org
> > Subject: Re: New web-based Subversion server management tool
>
> [snip]
>
> > 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?
>
> In the way that you will need a way to create/update/delete user
> accounts that are available to both SVN and this web application. Since
> Apache limits what you can do in terms of user authentication -
> basically some variation of a password file or LDAP - and the former
> doesn't allow you to store all user information in a central location
> (e.g. username/password in a file, and username/user attributes in a DB
> table) which might be construed as not elegant, and since LDAP does both
> rather well, I thought it would be an interesting approach. It would
> also enable integration with an Active Directory if and when this
> project ever reaches a point where it is deployed in a corporate
> environment.
>
> Cheers,
> Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
http://geekswithblogs.net/vagmi.mudumbai
http://installneo.blogspot.com
"Peace is its own reward." - Mahatma Gandhi
RE: New web-based Subversion server management tool
Posted by Rob van Oostrum <ro...@blastradius.com>.
> -----Original Message-----
> From: Lawrence Stewart [mailto:lstewart@room52.net]
> Sent: Tuesday, November 28, 2006 9:13 PM
> To: Rob van Oostrum
> Cc: users@subversion.tigris.org
> Subject: Re: New web-based Subversion server management tool
[snip]
> 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?
In the way that you will need a way to create/update/delete user
accounts that are available to both SVN and this web application. Since
Apache limits what you can do in terms of user authentication -
basically some variation of a password file or LDAP - and the former
doesn't allow you to store all user information in a central location
(e.g. username/password in a file, and username/user attributes in a DB
table) which might be construed as not elegant, and since LDAP does both
rather well, I thought it would be an interesting approach. It would
also enable integration with an Active Directory if and when this
project ever reaches a point where it is deployed in a corporate
environment.
Cheers,
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: New web-based Subversion server management tool
Posted by Lawrence Stewart <ls...@room52.net>.
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
Re: New web-based Subversion server management tool
Posted by Rob van Oostrum <ro...@blastradius.com>.
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
Re: New web-based Subversion server management tool
Posted by Lawrence Stewart <ls...@room52.net>.
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
> <ma...@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
> <ma...@subversion.tigris.org>
> For additional commands, e-mail: users-help@subversion.tigris.org
> <ma...@subversion.tigris.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org