Dear John,
> Solvable yes, but I don't think it is reasonable. The current log-message
> template discussion might require a new property in the svn: namespace. Once
> the keywords-as-hash patch gets committed, I'm hoping to prod things in the
> direction of inherited properties, which would almost certainly require a new
> svn: property. I don't think the new property case is nearly as rare as you
> think. And breaking compatibility between backrev'd client and server (even
> if there is a workaround) is a really important consideration.
I sure agree that compatibility is an important issue to consider. But I
don't see a required '--force' in some case as a real incompatibility, as
it does not forbid the move.
>> The next level is to have a new 'special' property that would list the
>> allowed property names, a little bit like svn:ignore, and could be fetched
>> by the client.
>
> That would be this issue:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1974
That would require the 'client broadcast settings' to include the list of
allowed svn properties, which is not the case at the time with the current
client settings, otherwise my problem would be solved.
I could devise another patch with an improved client-side setting which
could list all allowed svn properties instead of the static list I put. So
an old client could update this list to match new server requirements and
that would provide some better 'compatibility' as you view it.
Would it be more acceptable with a client-side configuration, which
could be update as necessary~? Something like :
enable-check-svn-props = yes
[check-svn-props]
svn:keywords
svn:externals
svn:executable
..
Or maybe with some kind of regular expression, but that would be harder to
implement, and I don't have much time.
>> But it seems as a lot of work for a small problem.
>
> I think you are trying to solve the "problem" in the wrong way.
> You should be able to write a pre-commit hook which checks for
> properties that do not correspond to the set you wish to support.
> Until such time as issue #1974 is resolved, adding validation to the
> client only is just asking for trouble.
I already looked at the pre-commit-hook solution which was suggested on
the list. Getting the list of properties added by a patch is *not easy*
with sh/svnlook at least, I haven't looked at python.
Moreover, the user would get the failure much later at commit time, where
I wish I would have been warned on the spot when I typed the wrong name.
The pre-commit-hook would implement a repository policy, but I'm just
looking at client-side spell-checking, which seems to me simpler an issue.
Have a nice day,
--
Fabien.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 23 16:42:50 2005