Did everyone like up and decide that no one wants this? I thought I was
just hearing that no one thought the main subversion developers should
work on this. But that if someone wanted to work on it, it was swell.
I'd like to know if there is any support for this (ie, people think it's
a good idea) and if anyone wants to help talk about it in a way that
would facilitate the design and anyone that wants to help work on it in
general.
If everyone just up and decided that this is a stupid idea to even try,
please let me know, and I'll quit worrying about it. Personally, I
thought it would be a great addition.
But as just one person with no lobbying support from anyone else, I
don't see why I should work on this.
So, let me know - will this help subversion be all that it can be? Or is
it just a waste of my time.
Shamim Islam
BA BS
On Thu, 2003-09-11 at 14:49, Files wrote:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 13 14:09:51 2003