New svn client format (1.7+) breaks when checkout crosses filesystems

[Marc MERLIN <ma...@merlins.org>]

Howdy,

On my personal system, I got a new svn and as prompted by "your repo is
too old", upgraded it to the new format (svn 1.7.13).

And now I'm very hosed.

legolas:/var/local/scr# svn update
svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted
legolas:/var/local/scr# svn cleanup
svn: E000018: Can't move '/.svn/tmp/svn-1FyLjO' to '/var/local/scr/btrfs-subvolume-backup': Invalid cross-device link

Indeed, I use svn across my entire system to keep track of changed files, and this
goes across filesystems. Been doing this for years, well until now I guess.

/ is my root
/var/local/scr is 2 levels of filesystems mounted on top
svn now keeps everything in /.svn it seems and naively assumes it can rename files across locations

I don't really want to rebuild my entire svn checkout in 7 different ones (one
per filesystem), not counting that I'd have to manually fix what svn state that
isn't synced on each of my client checkouts.

What are my options?
1) revert to svn 1.6 but I don't think I can revert my svn repo state
without going back to backups, I'm assuming it's a one way upgrade.

2) split my repo in 7 pieces, which sucks as explaine above (going to be hours of
manual work and checking over multiple systems) and reverting/rolling this out.

3) other :)

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/

Re: New svn client format (1.7+) breaks when checkout crosses filesystems

[Marc MERLIN <ma...@merlins.org>]

First, thanks for your answer, and sorry my late answer

On Mon, Feb 03, 2014 at 03:05:28PM -0800, Ben Reser wrote:
> On 2/3/14, 2:26 PM, Marc MERLIN wrote:
> > On my personal system, I got a new svn and as prompted by "your repo is
> > too old", upgraded it to the new format (svn 1.7.13).
> 
> You mean working copy, there is no such message about repositories.  We support
> repositories all the way back to 1.0.

Yes, I did. After working with svn, p4, and git, I tend to confuse the
terms a bit, sorry.

> It's no longer supported for a working copy to cross file systems.
> Unfortunately, doesn't look like we documented that fact in our release notes:
> http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng

So be it. Maybe it would be good for svn upgrade to notice this and
fail, or at least print a warning?
 
> This has caused some issues on Windows as well where permissions become
> problematic because the files are not made under the same directory as their
> destination.  So it's possible we might change this in the future.  But that
> does nothing to help you right now.

Indeed :) but I appreciate the info nonetheless.

> > I don't really want to rebuild my entire svn checkout in 7 different ones (one
> > per filesystem), not counting that I'd have to manually fix what svn state that
> > isn't synced on each of my client checkouts.
> > 
> > What are my options?
> > 1) revert to svn 1.6 but I don't think I can revert my svn repo state
> > without going back to backups, I'm assuming it's a one way upgrade.
> 
> Before starting it would be a good idea to take a backup of the files if you
> have concerns about local modifications.

Sound advise.

> Note what revision you're at in your working copy with svnversion (I'll assume
> $WC is your $WC root from here on out)
> svnversion $WC

Good idea, but:
legolas:/var/local/scr# svnversion 
svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted
legolas:/var/local/scr# svnversion  /
svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted

> Hopefully that's not a mixed revision range, if it is you may have some issues
> with the following.  If it's locally modified that should be ok.
> 
> Remove the .svn working copy metadata directory:
> rm -rf $WC/.svn
> 
> Run the checkout again with 1.6 client where $REV is the revision you got from
> svnversion and $URL is the $URL to your repo:
> svn-1.6 checkout --force -r $REV $URL $WC
> 
> You'll get a lot of E lines (which is the client saying the file already
> exists).  It'll still have your local modifications.

Thanks for the tip. I'll try some of that on one client, but on the
others I probably 

> However, we no longer support 1.6, so you probably want to upgrade to 1.7/1.8
> at some point or you're going to be stuck in the past.

I know, I lose, I'll have to rebuild my entire system. Maybe I'll just
switch away from svn considering how much work it'll be anyway.

> This (splitting your working copy) is probably your best bet.  However, to be
> honest with you this was never a task to which Subversion was made for.  I'm

Apparently not. I used to do this with cvs, then upgraded to svn, now
maybe to something else. I understand that my use case is clearly not a
majority so I'll deal.

> guessing you're already using some sort of wrapper to deal with permissions.

actually I don't because I only check config files and scripts that do
not need special owners or permissions.

> So it seems to me you need to extend the wrapper to deal with multiple working
> copies on each file system and keeping them in sync.  More than likely you need
> to request the latest revision from the server (1.7/1.8: use svn info $URL and
> pull out the Revision: field; 1.9 will have svn youngest for this purpose).
> Then run svn up -r $REV on each working copy.
> 
> > 3) other :)
> 
> I don't see any other choices.

Thanks for laying down the options, it definitely helps me plan about
what I should do next.

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901

Re: New svn client format (1.7+) breaks when checkout crosses filesystems

[Ben Reser <be...@reser.org>]

On 2/3/14, 2:26 PM, Marc MERLIN wrote:
> On my personal system, I got a new svn and as prompted by "your repo is
> too old", upgraded it to the new format (svn 1.7.13).

You mean working copy, there is no such message about repositories.  We support
repositories all the way back to 1.0.

> And now I'm very hosed.
> 
> legolas:/var/local/scr# svn update
> svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted
> legolas:/var/local/scr# svn cleanup
> svn: E000018: Can't move '/.svn/tmp/svn-1FyLjO' to '/var/local/scr/btrfs-subvolume-backup': Invalid cross-device link
> 
> Indeed, I use svn across my entire system to keep track of changed files, and this
> goes across filesystems. Been doing this for years, well until now I guess.
> 
> / is my root
> /var/local/scr is 2 levels of filesystems mounted on top
> svn now keeps everything in /.svn it seems and naively assumes it can rename files across locations

It's no longer supported for a working copy to cross file systems.
Unfortunately, doesn't look like we documented that fact in our release notes:
http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng

This has caused some issues on Windows as well where permissions become
problematic because the files are not made under the same directory as their
destination.  So it's possible we might change this in the future.  But that
does nothing to help you right now.

> I don't really want to rebuild my entire svn checkout in 7 different ones (one
> per filesystem), not counting that I'd have to manually fix what svn state that
> isn't synced on each of my client checkouts.
> 
> What are my options?
> 1) revert to svn 1.6 but I don't think I can revert my svn repo state
> without going back to backups, I'm assuming it's a one way upgrade.

Before starting it would be a good idea to take a backup of the files if you
have concerns about local modifications.

Note what revision you're at in your working copy with svnversion (I'll assume
$WC is your $WC root from here on out)
svnversion $WC

Hopefully that's not a mixed revision range, if it is you may have some issues
with the following.  If it's locally modified that should be ok.

Remove the .svn working copy metadata directory:
rm -rf $WC/.svn

Run the checkout again with 1.6 client where $REV is the revision you got from
svnversion and $URL is the $URL to your repo:
svn-1.6 checkout --force -r $REV $URL $WC

You'll get a lot of E lines (which is the client saying the file already
exists).  It'll still have your local modifications.

However, we no longer support 1.6, so you probably want to upgrade to 1.7/1.8
at some point or you're going to be stuck in the past.

> 2) split my repo in 7 pieces, which sucks as explaine above (going to be hours of
> manual work and checking over multiple systems) and reverting/rolling this out.

This (splitting your working copy) is probably your best bet.  However, to be
honest with you this was never a task to which Subversion was made for.  I'm
guessing you're already using some sort of wrapper to deal with permissions.
So it seems to me you need to extend the wrapper to deal with multiple working
copies on each file system and keeping them in sync.  More than likely you need
to request the latest revision from the server (1.7/1.8: use svn info $URL and
pull out the Revision: field; 1.9 will have svn youngest for this purpose).
Then run svn up -r $REV on each working copy.

> 3) other :)

I don't see any other choices.