tag 678203 + pending severity 678203 serious quit On Thu, 28 Jun 2012 17:08:11 -0500 Peter Samuelson <pe...@p12n.org> wrote:
> [Neil Williams] > > Frankly, the new subversion working copy structure is insane and will > > break hundreds of tools of all different kinds by removing the .svn > > directory. > > "Hundreds of tools" try to look inside the .svn directory? I didn't say inside and I wasn't just referring to tools inside Debian. There are innumerable upstreams, scripts and tools which look for (-d .svn) and change behaviour as to whether this is a test / development environment or a production / packaging one. That is *a lot* faster than spawning a process/subshell to run $(svn info). > Tools shouldn't try to frob the svn > metadata directly Agreed. > In the present case, I understand [ -d .svn ] was a handy way to tell > you were in a wc, but it was still a hack and a layering violation. I disagree that it was a violation merely to look at the presence of absence of a directory. I also don't see why the conversion had to remove every .svn directory rather than just offer the choice to leave 99.9% of them in place and svn could just ignore them. Migrations of working copies are a *big deal* - far more serious than migrations on the server. (There's little point having VCS if the only instance is the server + 1 working copy so there are usually lots more copies than servers.) On Wed, 20 Jun 2012 20:14:11 +0200 Daniel Leidert <daniel.leid...@wgdd.de> wrote: > Am Dienstag, den 19.06.2012, 23:32 +0100 schrieb Neil Williams: > > I'd rather just remove svn-do. > > Please don't. This tool is very useful for me, especially for creating > patches via quilt. Would you consider applying the attached patch > instead? Turns out that #678845 is a failure of a single mode of operation for a non-essential part of the svn-buildpackage source too, albeit a relatively commonly used one. My own problems with svn 1.7.* are separate - we'll just move the old svn checkouts into squeeze chroots. It's quicker than 'upgrading'. A handful of individual developer machines will have to rm -rf ; svn co in the absence of a usable upgrade tool. So, I'm reverting this bug to serious severity because there's no particular reason why this bug wouldn't need a fix in wheezy if #678845 also gets a fix. It's not a "real" justification IMHO but the release team seem open to getting subversion 1.7.5 into Wheezy despite the other RC bugs which were caused so late in the cycle. It wouldn't be sensible to do that without svn-buildpackage having these relatively minor fixes. (Neither of which are actually dependent on subversion 1.7.* and therefore are not, themselves, going to cause any problems with migrations from Squeeze.) AFAICT there's nothing intrinsically wrong with svn-bp itself on svn 1.7.* working copies. I ran out of time to fix other bugs in svn-bp before the freeze (I knew this was v.likely to happen), so it's important that those changes can be backported to Squeeze once Wheezy is released, on top of these changes. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgpIFKvji0exN.pgp
Description: PGP signature
