Re: Working copy upgrade 1.6.x to 1.8.3 removed executable bit

On Oct 24, 2013, at 06:47, Nico Kadel-Garcia wrote:

> On Thu, Oct 24, 2013 at 7:33 AM, Ryan Schmidt wrote:
>> While upgrading my laptop to OS X 10.9 Mavericks yesterday I finally took the plunge and upgraded Subversion 1.6.x to 1.8.3, using MacPorts. I had held off on the upgrade because of initial reports of working copy corruption when upgrading to the new Subversion 1.7 working copy format, especially when the working copy had been around for awhile, and I did not wish to have to recreate my MacPorts working copy, since it has years worth of uncommitted changes and half-finished updates in it. The working copy has about 20,000 files in about 13,000 directories, including innumerable unversioned items, and was originally checked out with some far-distant version of Subversion many years ago.
>
> Then, Ryan, you've got a lot more problems than just a need to upgrade,

Indeed, I have a chronic case of procrastination, which I fear may be incurable, but I’m open to suggestions.

> and I really hope you made a full tarball of that repository before you copied it, or that you have your work backed up by other means.

I do have a Time Machine backup, yes.

> Because this kind of stunt is dangerous, even with upgrade paths that have previously worked well. It's difficult indeed to test the upgrade tools from, say, a working copy in Subversion 1.4.1, which may have had bugs fixed during the 1.4 series, to Subversion 1.8.3 without the intervening steps. Some surprises are not shocking.

I’m not surprised, just trying to report the problem, get consensus on whether it is a bug in Subversion, and if so get it fixed so others don’t run into it. I don’t see any “stunt” here; I see me using Subversion in the way it was intended to be used. If it was not intended for working copies to be upgraded, there would not be an “svn upgrade” command. Indeed before 1.7 working copies upgraded themselves automatically without needing to be told to do so.

>> I discovered via a chance failed MacPorts build today that the execute bit had gotten lost on two files, even though they have the svn:executable property set to “*” like they should. I wondered if other files were also affected so I ran:
>>
>> find dports -type f -print0 | \
>> xargs -0 -n 1 svn pg -v svn:executable 2>/dev/null | \
>> sed -E -n "s/^Properties on '(.*)':$/\1/p" | \
>> xargs ls -l
>>
>> And I found that all files with the svn:executable property had indeed lost their executable bit.
>
> What happens if you delete or move aside the file, then check it out again?

Since checking out isn’t something that one repeats in an existing working copy, I assume you mean I should “svn update” the file after I move or remove it. This results in the execute bit being restored, the file being touched, and the group ownership being changed.

> And what are the permissions of the local copy in the ".svn" directory?

I’m not sure if there’s a more direct way to find this out, but I used “svn info” on the file to find its checksum, then looked for a file with that basename in .svn/pristine at the root of the working copy. This file has a recent modification time (from when I upgraded the working copy yesterday) and is also missing the execute bit.

> And what shows up in a completely clean checkout?

I didn’t wish to wait for a full checkout, but checking out just the directory containing this file resulted in the correct permissions.

> It should be possible to do a clean checkout and then copy all the files from a backup, excluding the ".svn" subdirectory, right on top and get back as close as possible to the old state.

Perhaps, but my desire to avoid having to perform this kind of “stunt” is one of the main reasons why I waited 2 years to upgrade beyond Subversion 1.6.x.

>> Is this loss-of-executable-bit-on-upgrade problem already known or should file a bug report? I did not immediately see a matching ticket in the issue tracker.
>
> It's new to me, but I'm not using a Mac right now.

It doesn’t feel like a Mac-specific problem to me, but I don’t know.
Received on 2013-10-24 14:04:37 CEST