Re: 1.3.2 bzr 'fixes' - still can't deal with exec bit changes

[Kai <kai willadsen gmail com>]

On 13 July 2010 08:29, Steve Franks <bahamasfranks gmail com> wrote:
> On Mon, Jul 12, 2010 at 3:18 PM, Kai <kai willadsen gmail com> wrote:
>> On 13 July 2010 07:49, Steve Franks <bahamasfranks gmail com> wrote:
>>> Quite simply, if the exec bit changes, bzr flags this with a '*'
>>> (using an important character like that as status was probably a
>>> whopper of a mistake in the first place, imho).  Meld then picks that
>>> up as part of the filename, and subsequent bzr actions on the file
>>> fail, because the asterisk is not actually part of the filename, but
>>> status.
>>
>> Okay, so we can't actually tell from the output of bzr status whether
>> a file has had its exec bit changed, or whether it's a changed file
>> that happens to end in a "*"...
>>
>> ...excellent.
>>
>>> If I use bzr from the command line, and (i.e.) commit the file without
>>> the * in the name, it works fine.  The quoted stderr in my origonal
>>> email is from meld's status pane when I try to commit the same file
>>> within meld.
>>
>> Ah right. Yeah - you can tell I'm not a bzr user.
>>
>> So the quick solution to this is to trim a "*" off the end of
>> filenames we get from bzr status, and figure out what status to use
>> for those. This is guaranteed to break on perfectly valid filenames,
>> but I'm sure that exec bit changes are more common than filenames that
>> end in an asterisk, so that sounds like an acceptable short-term
>> trade-off.
>>
>> Unless someone knows of a better option, it looks to me like the only
>> actual solution is to do a wholesale port to bzrlib.
>>
>> cheers,
>> Kai
>>
>
> re: perfectly valid filenames: Isn't it a really *bad* idea to name a
> filename a wildcard anyhow?  I accidentally made a folder with a '?'
> in it (who put that on the same key as '/' anyway?), and I've yet to
> research how to delete the thing...

Oh, I'd agree that it's a bad idea. However, that won't stop people
from doing it, and it's still a valid filename, so we *should* deal
with it correctly.

Kai