http://qa.mandrakesoft.com/show_bug.cgi?id=5308
------- Additional Comments From [EMAIL PROTECTED] 2003-09-09 03:06 ------- I think I am missing something here, because I do not see where you (Oden) read that 0.29.0 can handle old repositories. So just to be sure: In 0.28.0 an incompatible database format change has been introduced, changing the format from version 1 to 2. A 0.29.0 svnadmin can only handle format version 2, i.e. all repositories created by 0.28.0 or later, but will fail on those created by 0.27.0 or earlier. (insert disclamer about about coming changes). The same goes the other way around, e.g. 0.26.0 can only read format version 1, that is repositories created by versions up to 0.27.0, not any created by 0.28.0 or later. So, in order to upgrade, every format version 1 repository has to be dumped, preferably with the version it has been last used with. And has to be re-created with the new version of svnadmin. The official announcement can be found here: http://subversion.tigris.org/servlets/NewsItemView?newsItemID=461 This behaviour is by intention. The dump format has been chosen as the invariant in the upgrade process, so that upgrades to Subversion's internals are possible without having to carry around compatibility layers around for the centuries to come (well, that's my interpretation, the Subversion developers wording would probably differ ;-). With the tarballs, it is not much of a problem, because if one reads the release announcement, and learns about the dump-load cycle, the old svnadmin is usually still lying around. It mainly becomes a problem with automatic package updates, because it may be difficult to downgrade again. Sorry, if all this was already obvious to you all. I had the impression it might not and thought the explanation can't hurt. I have no solution to offer, either. One idea would be to create a subversion-admin0.27 package, i.e. a special package only containing everything needed for executing "svnadmin dump" (statically compiled?). Could be a complete subversion, if it is easier to do for you. Disadvantage is that it is not the recommended procedure (which is to use the currently used version for the dump, which is not necessarily 0.27.0), but is probably better than nothing. Best would be if you could "save" the installed svnadmin before installing the new version, but with an dynamic binary, that will be too cumbersome, I fear (all the dependencies - particularly the repos lib has to be the "format 1" one). Thinking about it, it would be probably had been good, if it was like a major version upgrade (like gnome1.2 and gnome2.0), so that we got subversion0.28 instead of subversion-0.28.0 and people would have to take an active role for the upgrade (and the old version would still be installed). Yes, I am aware that the subversion0.28 name is already non-fitting anymore. Call it after0.27 or so. You are the bright guys here, I am sure you can come up with something. ;-) Anyhow, that doesn't help us now, because the packages are already out. The good news is, that they don't plan (but give no guarantee either) another incompatible format change up to, and including, 1.0 (hopefully out on sylvester ;-). The compatibility garantuee is only given for the coming 1.x series. Oops, that got a bit longer, than I meant. I am always a bit too wordy. Sorry. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------- Reminder: ------- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: trying to do a dump and restore svnadmin create etc [EMAIL PROTECTED] svn]# svnadmin load etc < /mnt/disk/backups/etc.svn.dmp.20030906 svn: Unsupported repository version svn: Expected version '2' of repository; found version '1' [EMAIL PROTECTED] svn]# looking at etc/format shows a format number of 1 and not 2
