On Friday 05 September 2003 06:10, [ben] wrote: > I was talking about the sever/client interoperability. For that they > as a matter of policy only guarantee compatability between one major > revision back (e.g. .27 will be compatable with .26 but .28 will not > necessarily be guaranteed).
ye, and this means that a 9.1 server is still copatible with a 9.1 client. > You can find their policy at: > http://subversion.tigris.org/project_faq.html#interop > > I was thinking this applied to the schema format but apparently they > don't apply it to that. yes, this is clearly stated in the FAQ : The repository db schema is stable now and should only undergo one more major change before 1.0. These migrations have happened before, and we already have dump/load utilities available to aid you in the migration. > However, because of this policy and > subversions instability we should encourage people to do dump/load at > upgrade time everytime. i didn't say that people should not be encouraged to do this, but, if we can help them, then we should. > This is all the better reason to urge people to use svnadmin dump > *BEFORE* upgrading. Always doing a svnadmin dump before an upgrade > and a svnadmin load after, will always avoid issues like this. > > My point is including an old svnadmin is only a solution for this > particular issue. I think that having a solution is better than having nothing. If it can help 50% of people, it is better than nothing. And, having a solution does not prevent us to warn people. In fact, you can patch svnadmin to display the messages if you want. or wrap it in a shell script that does everything. > Doing the dump before an upgrade and a load after > is the only reliable way to ensure a good clean upgrade. It's > unreasonable to carry around dozens of old svnadmin versions to help > people upgrading to deal with specific issues... dozen of old svnadmin. Do you really think that subversion people are insane ? They use their own software, and they will not break it every month. The project changed only once in a way that break everything since the beginning, in 2 years. we will need a dozen of svnadmin in 24 years, if they keep the same rate of breakage. I guess that subversion will be stable in 2 years, so, unless they break for fun, we will never have dozen of old binary. Please stop exagerating in order to convince people. i do not suggest to have it for years, only to help the upgrade from the current mandrake release, ie 9.1. > IMHO the 0.27 > svnadmin should be removed from the package. I understand it helped > you get out of a sticky situation, but having it implies that we'll > provide that sort of thing in the future. yes, it helped me. and it should not help other people ? what will be the avantage of not helping people ? forcing them to learn the hard way and to lose time, because it will be good for them. what will people learn with this ? that they should not use subversion, because they break thing ? they should not use mandrake because someone didn't want to ship a simple solution ? openldap2.1 changed the way it handle the schema, but, buchan tried to provides some migration script. I am sure it will help lot of people. This is *our* job to provide smooth upgrade. > The problem is they can choose to change the schema anytime they > want. Do we carry a svnadmin version for every schema version? I do not think that subversion project is going to change schema every month. This break too much thing for being done. I do not say we should ensure a upgrade from any release to any release. but from the 9.1 to 9.2. > I didn't intend it to be the only message. Just an extra notice... > I figure most people using subversion as a server are likely to be > using urpmi not rpmdrake... even if they do not use rpmdrake, they can miss the message. and what is the message good for ? I upgrade subversion, and it will say : "oh, you should have dumped before upgrading, sorry, that's too bad." and what will i do ? i will recompile from source. People will not blame mandrake for the error, but, if we provides them with a solution, they will appreciate the effort. Now, of course, you can do nothing. Maybe they will switch to a distro that care for them and try to make their life easier. And, if we provides this only for the release, we can drop it once cooker is unfrozen, if you think it would take too much time to maintain it. i just want to ensure that people using subversion will have a easier path for upgrading. -- Micka�l Scherer
