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

[Steve Franks <bahamasfranks gmail com>]

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...

Steve