On 9/10/06, Chia-liang Kao <clkao@clkao.org> 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.
>
> IMPLEMENTATION
>
> Property "svn:project:<projectname>" on '/', containing a spec like:
What would the project name be allowed to contain? Spaces? Newlines?
> [path]
> trunk = /path/to/trunk
> branches = /path/to/branches
> tags = /path/to/tags
> hooks = /path/to/hooks
>
> [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.
>
> * 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.
I would object strongly to such information being unversioned, and I
would object even more strongly to storing potentially large amounts
of data in revprops, simply because it's currently not very efficient
to operate on them due to the way they're stored (at least in fsfs).
If that means we need to allow things like editing of regular props
remotely, then we'll need to look into that, but I think using
revprops for this is a non-starter.
Also, I'd like some concrete examples of features that would use this
data before going much further down this path.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 13 19:13:29 2006