Hi
On 11 sept. 06, at 01:08, Chia-liang Kao wrote:
> GOAL
>
> 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.
>
> IMPLEMENTATION
>
> 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
development.
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
projects:
/openSourceProject1
/openSourceProject2
/privateProject1
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
projects.
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.
>
Best
dna
--
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