Ok. You all realize that there is a really simple answer to all of this.
I volunteer to head up the task force to assemble a single point of administration
for subversion. This administration interface will accomplish a few things (feel
free to add as needed).
It will provide HTTP access to a list of repositories.
Other access methods may be added later.
It will maintain the list of repositories (creation, deletion etc).
It will maintain security on these repositories.
It will be implemented on generic HTTP as well as custom PHP/Perl/Python/tcltk
scripts.
It will work with ANY subversion repository.
In addition, it will interface with any SCM that is willing to have someone write a
plugin module for it.
It will be architecture neutral so it should work on any system that supports the
general interface.
It will use only BDB since Subversion already uses it.
It can be used in addition to subversion as an addon-tool.
It will use subversion itself.
It will NOT be a filesystem intereface to subversion.
It will NOT provide a gui to subversion. There are enough projects to do this.
It will establish a controlled protocol to repository maintenance that allows for
automated listing of all repositories under it's direct control.
It will only be a centralized administrative interface to locate respositories.
I am volunteering because of a number of reasons:
1. Subversion is the best thing since sliced bread.
2. I think if this is a show-stopper for bigger collections of repositories,
meta-administration is a good idea.
3. I think subversion itself doesn't have to change to provide this functionality.
4. I would like to help subversion take over the world (although it's unlikely).
5. I have the years and architectural experience to pull this off.
I am willing to take any volunteers for this job.
We will need a requirements team. An architectural committee. And a number of actual
coders for particular flavors of each backend language.
Anyone wishing to help, feel free to reply.
I would like the blessing of the Subversion team to embark on this project.
I would also like the privilege of discussing this topic in this forum. I doubt we
will have a lot of traffic past the initial requirements phase.
I would also like the privilege of including this as a subproject in subversion and
hosting it that way. If that's not acceptable, I can host it locally but I'm not
sure how to disemminate the project as time goes on. I would like to be able to
delegate individual parts to different people.
So I'm guessing I would also need a little direction on how best to go about doing
this.
I don't think this is a big enough project to warrant it's own project status.
Someone let me know if I have a "go" on this.
So long and thanks for all the fish.
Shamim Islam
BA Life Sci
BS Comp Sci
Ronald Cannes (roncannes@hotmail.com) wrote:
>
>>From: SLOGEN <jensen@slog.dk>
>>2. How would this be ensured to be upto-date?
>
>See my previous about that.
>
>>3. The feature should be disabled by default
>
>No way.
>
>>>>You can file this as a post 1.0 feature request if you'd like, but this
>>>>is so low priority, I've got to sit on the floor to write this mail. ;-)
>>
>>>I don't understand why this has such a low priority.
>>
>>Because you haven't convinced people it's usefull,
>
>Perhaps they are handling only a couple of repositories and few users? A lot
>organization are used to this basic capability (typically in terms of GUI
>clients) and I promise you - they will miss this!
>
>>and there are many open questions about it's semantices and implementation.
>
>This feature sound like a simple thing to do, compared to some of the other
>stuff you guys are doing.
>
>>Have you thought about not making that many repositories? just create one
>>(or a few) repositor(y|ies), and make subdirs.
>
>We have as few repositories as possible.
>
>>>There is a reason why most SCM systems have this capability...
>>
>>Huh? which ones? must have overlooked it.
>
>I am not aware of any commercial SCM system that is not capable of listing
>repositories. Can you provide examples?
>
>>>Doing a "svn list repos" would be very helpful to the users and would take
>>>a burden of the admin (especially if you could attach comments to the
>>>repositories which would appear in this listing.)
>>
>>how abot, a common repos at svn.foo.bar, an svn_list script, implemented
>>as:
>>[neat script]
>
>A server-side script is not what I'm looking for. I'm looking for new client
>API functionality + a "svn list-repos" function for our users.
>
>>Are you really sure it's SVN's responsibility to solve this problem?
>
>Since I'm asking for client API changes: Yes.
>
>_________________________________________________________________
>Sign-up for a FREE BT Broadband connection today!
>http://www.msn.co.uk/specials/btbroadband
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 11 20:51:13 2003