fredagen den 5 september 2003 10.31 skrev Michael Scherer: > 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.
Well said Michael. I don't want to have endless discussions about this, I realized the problem and I just f*cking fixed it. Until the subversion code can handle upgrades we need to provide a solution (as mandrake allways do), otherwise we can just dump this software. Please note that I added this text in the description to my latest (my last?) packages, relevant to the corresponding subpackage(s): "NOTE: Make sure to read: /usr/share/doc/subversion-repos-0.28.1/repos_upgrade_HOWTO And use the /usr/bin/svnadmin-0.27 binary when migrating." People will read the description I presume, a %post message is easily lost. -- Regards // Oden Eriksson, Deserve-IT.com
