On Fri, Nov 23, 2012 at 9:09 AM, Branko Čibej <br...@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?
