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.
Received on 2014-02-04 00:06:02 CET