Hi Robert, On Mon, 2009-11-16 at 00:48 +0100, Robert Millan wrote: > On Mon, Nov 16, 2009 at 12:11:41AM +0100, Jelmer Vernooij wrote: > > I'm not sure what the best thing is to do here. > > > > This situation should be unusual, and it does not corrupt any of the > > data in the original Subversion or Bazaar repositories. It's only a > > problem if you push introduce a new file in a merged revision that is > > not changed by the merging revision and then try to pull those changes > > down to a bzr repository that is older than 2a. Even after that, bzr > > will complain but the data should be ok. > > > > Putting a newer version of bzr-svn into Lenny wouldn't really be an > > option, as this would require us to put newer versions of bzr, bzr-gtk, > > etc in as well. This would be too risky. > > > > I don't think removing bzr-svn completely would be necessary. Another > > alternative would be to simply disable the ability to do round-tripping > > pushes (or round-tripping pushes of merges?) into Subversion and only > > allow dpush. > > Note that the second time we experienced repository corruption, we were > using bzr-svn 1.0.0 and only for pulls, never for pushing to svn. This > was with a pre-2a format though. > > I'm not sure what's the cause anymore. It could also have been related to > our use of bzr+ssh (see https://savannah.gnu.org/support/index.php?107077) > with an old (1.6) bzr daemon. What sort of problems did you hit the second time around?
Were all of the bzr: revision and file properties before you had problems with this repository the second time, and were all of the caches/old bzr repositories removed? Perhaps this was just another problem created by the invalid data set by the older version of bzr-svn? Cheers, Jelmer
signature.asc
Description: This is a digitally signed message part
