Daniel Rall wrote:
> On Sun, 11 Feb 2007, Max Bowsher wrote:
>
>> Ionel GARDAIS wrote:
>>> ZeroConf ( http://www.zeroconf.org/ ) is also
>>> commercially known as 'Bonjour' (formerly
>>> 'RendezVous') by Apple.
>>>
>>> It allows 'services' to announce themselves to the
>>> world.
>>> Most new printers include this so computers are able
>>> to 'discover' their brand/model/capabilities
>>> automatically.
>> There's a fundamental difference between printers and Subversion
>> repositories. For a printer to be useful, it only needs to be near to
>> you, and support the appropriate capabilities (B&W/colour, resolution,
>> etc.) that you need. For a Subversion repository to be useful, it needs
>> to actually be the specific one you are looking for.
>
> Yes. And help finding it is always welcome, especially to newcomers
> to an organization (e.g. software development shop).
Yes. This is why I have built the Insurrection interface the way I have.
It fits right over the Subversion HTTP/DAV infrastructure and provides
seamless repository access and browsing using the exact same URLs. It also
provides repository enumeration via the web interface. As long as you
get to the front page the rest is somewhat automatic. (Repository creation
and administration is also in there)
I have deployed this in a number of corporate environments and publicly
on my server (hosting the project itself). A number of other people are
also using it. (see http://svn.sinz.com/ for a site running Insurrection
and that hosts the Insurrection development repository)
>>> Applied to SVN, compatible clients will list available
>>> repositories through an easy-to-remember name, hidding
>>> the real full path.
>> But only within some sort of local organization scope... in which case,
>> a website or wiki page describing the available repositories could be
>> just as, if not more, useful.
>
> How do you know where to find the wiki?
>
>>> An administrator could then move servers around, split
>>> repositories on different servers without notifying
>>> the users each time.
>> This doesn't seem so very different to what you could already do with
>> DNS CNAMEs.
>
> Agreed.
>
> Of course, you have to know what the CNAME is in the first place.
>
>>> In a 1projet/1repos scheme, adding a repository for a
>>> project will list it automatically for an easier user
>>> access.
>> Yet, you'd still need to tell the users about the creation of the
>> project, so you might as well just tell them about the repository URL at
>> that time.
>
> This is the type of information which is often slow to be communicated
> to the chain of people who need to know. The person announcing the
> kick-off of a project is, in my experience, typically not the person
> creating the repository. Also typically, a repository is quite likely
> not to exist at this point in a project.
The thing I tend to do at companies is to have the project owner also have
repository administration rights for that project's repository. (Be it a
shared repository or a unique repository per application)
>> I feel unconvinced that Version Control System repositories are a
>> resource suited to zeroconf-style discovery. Are there any VCSes in
>> existence which employ such a feature?
>
> I don't know of any.
>
> This is a really valid use case for small to medium-sized
> organizations using version control (e.g. doing software development,
> content management, etc.). It doesn't seem like it would scale
> gracefully as repository proliferation grew.
Zero-conf may be a nice feature but is only possible when there is a reasonable
way to identify repositories. In the HTTP/DAV case, this is easily known.
In the svn+ssh case, this is not really knowable since any place on the server
could be the repository. In fact, the "server" is not really running any
service other than "sshd" and it is via the ssh remote command execution
capabilities that the back-end of Subversion gets started with whatever path
is needed.
The svnserve case is a bit tricky but could be solved since there is a server
up and running and it *could* know all of the repositories due to configuration.
(However, the basic way svnserve works is that any path is possible for the
repository storage and that path is provided by the client at each connection,
just like via ssh only via ssh, the server is started for each connection and
not run as an actual service/server.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 22 04:40:34 2007