On Tue, Jan 5, 2010 at 4:58 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: pburba_at_apache.org [mailto:pburba_at_apache.org]
>> Sent: maandag 4 januari 2010 22:39
>> To: commits_at_subversion.apache.org
>> Subject: svn commit: r895794 - in /subversion/trunk/subversion:
>> libsvn_wc/props.c tests/cmdline/prop_tests.py
>> Author: pburba
>> Date: Mon Jan 4 21:38:41 2010
>> New Revision: 895794
>> URL: http://svn.apache.org/viewvc?rev=895794&view=rev
>> Consider non-inheritable mergeinfo on a non-directory as non-canonical.
>> Wow, that was a lot of "nons".
>> This prevents us from doing things like using svn propset to set non-
>> inheritable mergeinfo on a file. At best this mergeinfo is meaningless
>> and confusing, at worst it is a bizarre bug waiting to happen.
>> * subversion/libsvn_wc/props.c
>> (svn_wc_canonicalize_svn_prop): Error out when trying to set
>> non-inheritable mergeinfo on anything other than a directory.
>> * subversion/tests/cmdline/prop_tests.py
>> (inappropriate_props): Expand test to cover this use case.
>> Modified: subversion/trunk/subversion/libsvn_wc/props.c
>> --- subversion/trunk/subversion/libsvn_wc/props.c (original)
>> +++ subversion/trunk/subversion/libsvn_wc/props.c Mon Jan 4 21:38:41
>> @@ -2444,6 +2444,15 @@
>> apr_hash_t *mergeinfo;
>> svn_string_t *new_value_str;
>> + /* Non-inheritable mergeinfo is only valid on directories. */
>> + if (kind != svn_node_dir
>> + && strstr(propval->data, SVN_MERGEINFO_NONINHERITABLE_STR))
>> + return svn_error_createf(
>> + SVN_ERR_MERGEINFO_PARSE_ERROR, NULL,
>> + _("Cannot set non-inheritable mergeinfo on a non-directory ('%s')"),
>> + svn_dirent_local_style(path, pool));
> Doesn't this make "*" a character that can't be used in paths that are used for merging?
Well they could be used, but the merge results might likely be wrong
and/or the wrong mergeinfo might be recorded describing the merge. My
overly-simplistic approach using strstr interprets mergeinfo with a
'*' in the merge source path as non-inheritable, whether or not it
actually is. In r896115 I fixed this case and two other places where
the same faulty assumption was made.
> From a few recent mails I know there are users that have '>', '<' and ':' in their paths, so I'm thinking maybe there are users that really have a '*' in their path. We can't support these paths on Windows, but on unix we can.
Received on 2010-01-05 17:23:35 CET