A big note to packagers of subversion! New (1.5) version introduces new storage format to which all old repositories are *transparently* converted *on first use*. I hope I shouldn't mention that this is a very drastic issue, so subversion-1.5 should be masked ASAP, before users inadvertently make irreversible changes to their code. Additionally, preparation should be made for subversion to be SLOTted in the future, if we are to handle this format change correctly. Below I included two relevant paragraphs from the release note for 1.5_pre4. As one can see, upstream does not even want this version packaged. At the very least it should stay masked, not in the testing, as upstream clearly not intended this one for "production use". "As a note to operating system distro packagers: while we wish to have this release candidate widely tested, we do not feel that it is ready for packaging and providing to end-users through a distro package system. Packaging a release candidate poses many problems, the biggest being that our policy lets us break compatibility between the release candidate and the final release, if we find something serious enough. Having many users depending on a release candidate through their distro would cause no end of pain and frustration that we do not want to have to deal with. However, if your distro has a branch that is clearly labeled as containing experimental and often broken software, and explicitly destined to consenting developers and integrators only, then we're okay with packaging the release candidate there. Just don't let it near the end users please. Please note that due to various improvements made to the working copy library, the working copy format has changed. Using Subversion 1.5.0-rc4 on any working copy created by previous versions of Subversion will TRANSPARENTLY upgrade your working copy, which means that production-ready versions of Subversion will no longer be able to read it! Please be careful, if you have two versions of Subversion running on your machine, to not use the wrong version on a production working copy. If you inadvertently do upgrade your working copy, you can use the new tools/client-side/change-svn-wc-format.py script to restore working copy compatibility with previous versions of Subversion." George PS I assigned this bug directly to apache-bugs, as this is who handled subversion previously and the issue is rather urgent. However I CC'd bug-wranglers in case this is not the right assignment. Please remove yourself or reassign properly. PPS As the issue indeed is rather urgent, I would even consider masking 1.5_pre4 myself, but wanted to give a short note to packagers. If no action is taken until tomorrow morning UTC I'll mask it myself.
(In reply to comment #0) > I would even consider masking 1.5_pre4 myself, but wanted to give a short > note to packagers. If no action is taken until tomorrow morning UTC I'll > mask it myself. Please don't mask it. It would cause needless problems for people who had upgraded Subversion to 1.5*. Even Subversion trunk is more stable than 1.4*.
There may also be issues packages that depend on svn, kdesvn is one such (I'll soon post a comment to bug #219505), but, as long as subversion itself is not in world, portage may be able to deal with this nicely it seems. So, sorry for pressing the issue. However, (at least) the point with upstream not having intended this version to hit the users stands. It may still be better to keep this version in p.mask. But I'll not act myself on this issue and will leave it to the maintainers instead. George
I can't build sphinx, python's documentation generator, when I check it out using the svn release candidate. Setuptools complains about "unrecognized .svn/entries format in" ... in what? Setuptools doesnt say, it apparently doesn't know how to handle subversion-1.5 checkouts, or even how to report the errors. It gets better. I can't revert to subversion-1.4.6, because it is not compatible with libtool-2.2 (bug 212718) and fails to merge. If this was an intentional decision to ignore the declared warning by the subversion developers, I'd like to point out that the timing was terrible, and some gentoo users might find themselves in a bit of a fix. If the decision was made to add the release candidate without knowing that the subversion developers had warned against it, I can understand. If the warning was simply disregarded, well, I object.
(In reply to comment #3) > I can't build sphinx, python's documentation generator, when I check it out > using the svn release candidate. Setuptools complains about "unrecognized > .svn/entries format in" ... in what? Setuptools doesnt say, it apparently > doesn't know how to handle subversion-1.5 checkouts, or even how to report the > errors. It is completely wrong and unacceptable to directly access anything inside .svn directory.
(In reply to comment #0) > I assigned this bug directly to apache-bugs, as this is who handled subversion > previously and the issue is rather urgent. However I CC'd bug-wranglers in case > this is not the right assignment. Please remove yourself or reassign properly. Your assignment is fine, thanks for saving us some work :).
> It gets better. I can't revert to subversion-1.4.6, because it is not > compatible with libtool-2.2 (bug 212718) and fails to merge. since libtool fails on so many packages, i'd rather mask libtool, instead of masking subversion in panic because some random package fails to build ... it's ~arch after all
oh, right ... won't be masked
