[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PROPOSAL] Project meta-data in subversion repositories

From: Denis N. Antonioli <denis.antonioli_at_canoo.com>
Date: 2006-09-12 22:51:58 CEST


On 11 sept. 06, at 01:08, Chia-liang Kao wrote:

> To allow high-level applications create "projects" and
> "branches or tags within project", in the location by an agreed and
> configurable convention. This would also allow hook scripts, such as
> those preventing modification of /tags, to be written more portably.

Worthy goal.
It is indeed troublesome that I have now to give the same information
at different places, respectively to different tools.

> Property "svn:project:<projectname>" on '/', containing a spec like:
> [path]
> trunk = /path/to/trunk
> branches = /path/to/branches
> tags = /path/to/tags
> hooks = /path/to/hooks

At least one of the project I helped set up decided to have two
branch and two tag
directories for a project with a possible third!
We have one branch and tag directory each for internal and released

How would I be able to describe this?

> [address]
> admin = admin@host.org
> commit_url = svn+ssh://svn.host.org/project
> public_url = svn://svn.host.org/project
> There should be a list of standard names of commonly used meta-data,
> including at least those listed above. None of these meta-data
> should be
> mandatory.
> Where to put the property:
> * Versioned property on '/',
> - Pros: Versioned.
> - Cons: Requiring read access on '/' to make use of the meta data.

Cons: doesn't work if the access rights are not the same everywhere.
Consider the case of a repository that contains public and restricted

We would like to restrict the acces right of root in such a way that
the persons
that have access to the openSourceProjects cannot see the private
That means that the openSourceProjects can't have access to /, and
can't get
project names listed from a property there.

> * Unversioned property on r0
> - Pros: Works out-of-box with repository that has acl.
> - Cons: Unversioned.
> Personally I'd prefer the r0 one, as versioning such properly is
> actually not so interesting, while having the properties more
> accessible would make it easier to build applications on it.


You can sometimes write faster code in C, but
you can always write code faster in Perl.
   -- Moral from perlembed
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 12 22:52:49 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.