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

Re: [RFC] svn propset should require 'force' to set unknown svn: propnames

From: Ben Reser <ben_at_reser.org>
Date: Fri, 23 Nov 2012 11:22:44 -0800

On Fri, Nov 23, 2012 at 9:09 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> No. The check specifically looks for a three-letter prefix ending in a
> colon, and allows only one wrong character or transposition. It will
> flag svm: but not tsvn:.

svk would pop up for anyone still using (no idea if anyone does) SVK.

> I agree that looking at the prefix is dicey, which is why I defined the
> constraints as explained above. I'm also looking at options for not
> flagging non-svn: properties that are different enough from the known
> ones; for example, these would be flagged:
>
> svm:needs-lock
> svn:global-ignore
> gvn:ignore
>
> but not
>
> gvn:defrobify
> gvn:local-ignores
>
>
> I know how to do this, but I'm not clear yet about how or where to draw
> the line.

Difficult decision here. On one hand we have something that's
probably going to help make a lot of peoples lives easier but it might
make a small minority's life harder.

I'm inclined to agree with Mark here that we shouldn't match on prefixes.

However, on the other hand, aren't most of these property names likely
only to being set by programs using our library and not the command
line client. As such they wouldn't be prone to this code since
Brane's changes are only in the command line client. In the svk
example I gave above, svk:merge is not really intended to be modified
by hand.

gvn might be the only exception to that which we've mentioned, I'm not
super familiar with it. Looking at the page it says it uses the svn
client for most operations and the python bindings for others.

It's also worth nothing that I think both gvn and svk are mostly
unused at this point. Are there other common examples out there that
would trip this?
Received on 2012-11-23 20:23:23 CET

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.