Working copy upgrade 1.6.x to 1.8.3 removed executable bit

[Ryan Schmidt <su...@ryandesign.com>]

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.

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.

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.

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

[Branko Čibej <br...@wandisco.com>]

On 24.10.2013 14:12, Ryan Schmidt wrote:
> On Oct 24, 2013, at 07:02, Philip Martin wrote:
>
>> I don't think upgrade is resposible.
> You are correct; sorry for the noise. I have consulted my backups from before upgrading Subversion and verified that the permissions are wrong there too, and I now recall having recursively changed the permissions on that directory recently.

I'll also note that I've seen the Mac OS upgrade fiddle with file
permissions ... dropping exectuable bits, changing symlinks to whole
copies of directories, and similar unprintable unmentionables. It
happened when I upgraded to Lion, and again with Mountain Lion ...
clearly Apple QA needs its collective rear booted every so often.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

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

[Ryan Schmidt <su...@ryandesign.com>]

On Oct 24, 2013, at 07:02, Philip Martin wrote:

> I don't think upgrade is resposible.

You are correct; sorry for the noise. I have consulted my backups from before upgrading Subversion and verified that the permissions are wrong there too, and I now recall having recursively changed the permissions on that directory recently.

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

[Philip Martin <ph...@wandisco.com>]

Ryan Schmidt <su...@ryandesign.com> writes:

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

I don't think upgrade is resposible.  Can you be certain that the files
had the execute bit before the upgrade?  Perhaps a bug in the old client
caused the problem before the upgrade?  What other operations did you
do after the upgrade?

Upgrade doesn't modify working files, it only modifies the database in
the .svn directory.  Upgrade doesn't even look at the working files, it
never accesses them.  The working files could be absent, owned by root
and unreadable, replaced by directories, etc. and it doesn't affect
upgrade.  I don't see how upgrade could be responsible for the loss of
executable bits.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

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

[Branko Čibej <br...@wandisco.com>]

On 24.10.2013 14:03, Ryan Schmidt wrote:
> 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.

FWIW, the pristine files will never have the executable bit set.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

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

[Ryan Schmidt <su...@ryandesign.com>]

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.

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

[Nico Kadel-Garcia <nk...@gmail.com>]

On Thu, Oct 24, 2013 at 7:33 AM, Ryan Schmidt <
subversion-2012c@ryandesign.com> 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, 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. 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 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? And what are the permissions of the local copy in the ".svn"
directory? And what shows up in a completely clean checkout? 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.

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.