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

Re: [PATCH] Give svnmucc ability to handle multiline properties

From: Purple Streak <mrpurplestreak_at_googlemail.com>
Date: Wed, 23 Sep 2009 17:44:33 +0100

2009/9/12 Gavin 'Beau' Baumanis <gavinb_at_thespidernet.com>:
> Hi just thought I would follow this up.
>
> The reply from Julian seem to be last one in this thread.
> Do you plan to incorporate the suggested changes?
>
>
> Gavin.
>
>
>

Hi,
Sorry. Yes I do when we've released what I'm working on currently
(whcih should be soon). Had no time to work on it :(

> On 12/08/2009, at 09:59 , Julian Foad wrote:
>
>> On Mon, 2009-08-03 at 17:01 +0100, Purple Streak wrote:
>>>
>>> 2009/7/31 Geoff Rowell <geoff.rowell_at_gmail.com>:
>>>>
>>>> Philip Martin <philip_at_codematters.co.uk> writes:
>>>>>
>>>>> When '\' escaping was added to svn:externals it changed how paths were
>>>>> interpreted by the command line client.  That provides some sort of
>>>>> precedent for simply changing the behaviour of svnmucc.  I'd prefer to
>>>>> see '\' as an escape character without any new command line option.
>>>>> I'd want enough escaping so that '\\' at the end of a line gave a
>>>>> literal '\'.
>>>>
>>>> I agree with Philip and Julian. As long as an escape is supported, I
>>>> don't
>>>> see the need for another command line argument. I'd prefer to have
>>>> backslash
>>>> as the continuation character.
>>>
>>> Sorry - but this _will_ break existing scripts on windows so I'm
>>> really not happy having I happen just by default.   Also making
>>> windows users have to adjust there .bat files to double up \
>>> characters in paths is also not making it easy.  On Unix this is the
>>> normal escape - but windows users don't have perl/python by default
>>> and a lot just use .bat files which don't have much processing power.
>>
>> Yes.
>>
>>> So I think we have to have the -c option both to enable the behaviour
>>> and to optionally specifiy a different character (I don't think this
>>> adds any complexity to usage - it's quite simple to follow and makes
>>> it more flexible).
>>
>> I agree it would be quite simple to follow. The kind of "complexity" I
>> mentioned is the (small) amount of additional complexity a configurable
>> escape character would bring to the Subversion universe: for example,
>> you couldn't so easily share svnmucc script files with other people; and
>> a syntax-highlighting editor for svnmucc script files couldn't work
>> properly unless you also tell it what escape character you're using. But
>> I think that's OK if the configurability is important, and it seems to
>> be important. Or at least I agree it's useful to be able to use a
>> character other than backslash.
>>
>>>  The escaping for whatever character used would be
>>> nice I agree, but you'd only really want it at the end of the line
>>> which would be odd, so you'd have to have it all the way along which
>>> makes the code more complex than it needs to be imo.
>>
>> I agree with Philip that '\\' at the end of a line (assuming the escape
>> character is '\') should mean a literal '\' at the end of the line, and
>> no continuation. Further, '\\\' at the end of a line should mean '\' and
>> continuation, '\\\\' should mean '\\', '\\\\\' should mean '\\' and
>> continuation, etc.
>>
>> Without that ability to "escape the escape character", there would be no
>> way for a program to generate svnmucc scripts with arbitrary text in
>> property values and, while not the end of the world, that would be a
>> shame.
>>
>> I don't see much extra code complexity in making the escape character be
>> escapable wherever it appears (not just at the end of a line), and I
>> think that would be best.
>>
>> - Julian
>>
>> ------------------------------------------------------
>>
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2382738
>
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2398981
Received on 2009-09-23 18:44:50 CEST

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.