[00:00] AfC: So, 1) the rich root format should become the default so there's no need for users to know about rich root anymore 2) there should be a way to enable an auto-upgrade mode in bzr [00:00] fullermd: :) [00:01] AfC, ? [00:01] AfC: If that's what you're saying, I completely agree. [00:01] jelmer: yup [00:02] jelmer: (and then the nuance that I would argue that auto-upgrade should be default, with much larger teams dealing with potential compatibility problems by disabling it, thereby leaving a "better" user experience for people using it in smaller contexts / just learning) [00:03] That would work nicer if the last default-upgrade hadn't blown fiery chunks on me :p [00:03] fullermd: were they tasty? :) [00:04] I dunno. I force-fed them to lifeless. [00:17] dato: ah well; I'll hope bzr is something you try again from time to time [00:18] AfC: svn does a mandatory upgrade; users complain bitterly in nearly every IRC channel I'm in, on *every* svn release. [00:22] lifeless: interesting [00:23] lifeless: I think automatic upgrades should be optional, but they would be nice [00:23] A somewhat different question is "should I have upgraded to --format=1.6?" No idea, other than the general notion that newer formats are hopefully better maintained code paths, etc. [00:24] git changes the data structures as new versions come in silently; for instance, using a submodule in git adds pointers that will confuse older git clients, but nothing to help the user using that older client figure out whats wrong [00:24] lifeless, after all, bzr introduces new formats more often than svn with its 2 year major release cycle [00:24] AfC: unless a plugin or documentation tells you to, you should never need to type --format in annywhere [00:24] jelmer: I could buy into that, with some study on version propogation [00:25] note that 1.6 isn't a 'default' yet. It's used by bzr as-needed, and when a few months have past and everyone is likely to have a build available, then we'll make it the default [00:25] lifeless: (sorry, but I really believe that `bzr upgrade --1.6.1-rich-root` looks terrible) [00:26] AfC: so do I === kiko is now known as kiko-fud [00:27] lifeless: er, so why did you just state not to use --format=1.6.1-rich-root? Sorry bud, you lost me [00:28] AfC: 1.6.1-rich-root is mentioned in the documentation because we had a brown paper bag bug in 1.6. Its why there is a 1.6.1. [00:28] I got that part [00:28] the only people affected by the bug are bzr-svn users that have run bzr branch --stacked [00:29] noone else in the world needs to run upgrade --1.6.1-rich-root [00:29] It seemed like you were saying "never use the --format" form of specifying a format version [00:29] I was referring to both --format=X and --X [00:30] So you're saying we _shouldn't_ have upgraded to X=1.6? [00:30] the use of parameters to choose a version is a sign of needing to do something at least slightly unusual, and most folk should never need to do that [00:30] AfC: are you using bzr-svn ? [00:30] In this particular repo, no [00:30] lifeless: ^ [00:30] AfC: then there is no motivation for you to change your format [00:31] oh shit [00:31] um, should I downgrade back to --default then? [00:31] the 1.6 family of formats add the logic to support stacked branches (on the side doing the stacking) [00:32] they are no faster or more efficient than the '0.92-pack' family of formats [00:32] ah [00:32] well shit. [00:32] That was a waste of time, then [00:32] if you went to '--1.6' then just leave it, its fine. or go back to --default if you like [00:32] I'll stick with "leave it" [00:32] if you were on default and went to --1.6.1-rich-root, then you're in the wide wide world of rich roots now, and can't go back to default anyhow. [00:33] 1.6 [00:33] cool [00:33] That'll teach me to be proactive. [00:33] Clearly, I should not be doing systems administration before I've had a cappuccino. [00:33] And so with that, I go out into the hurricane. [00:34] if you are passing a format parameter to any bzr command, its most likely that you are either a) using bzr-svn or b) experimenting with a development format to give feedback or c) doing something you do not need to do [00:34] AfC: ^ future reference [00:34] * AfC celebrates (c) [00:34] this will always be the case [00:35] AfC: You should figure out how to upgrade to btrees. :D [00:35] I don't think btrees go very well in espresso [00:40] lifeless: What happened to rich-root-pack as default format? [00:40] jelmer: thats how we'll get rid of a) from that list [00:41] jelmer: I don't know precisely whats left on the TODO list to achieve that, I thought we were pretty close at one point. [00:50] jelmer: Looks like my large SVN repo is nearly done [00:50] awilkins, cool [00:50] About 100 revs to go (it's a bit slow now) [00:51] I'm being a bit rubbish at reading this task manager [00:51] It says "Private bytes 506MB" [00:51] "Virtual Size 1.1GB" [00:52] I have no idea which one is the memory consumption :-) [00:53] But it's definitely the first time I've tried it and it's got this far without a) an error or b) running out of memory [01:15] Someone explain what a rich root is because I can't find a definition in the wiki [01:15] what I kept looking for as a younger man.... [01:16] Heh. I had the opposite, a girl I had no chance with because her boyfriend was a millionaire... [01:16] * markh expects only the Aussies will understand that... [01:16] bugger! [01:17] 9647/9699! exciting [01:23] * awilkins is bored waiting for it and will now try Bazaar on IronPython 2.- b4 [01:26] ooh, generating file id map [01:26] New steps [01:33] awilkins: [01:33] mistype, sorry [01:42] So, incase anyone is interested, bzr.dev's selftest on windows now results in "FAILED (failures=55, errors=50, known_failure_count=14)". 47 or so of the errors are the LockContention issue - so once we knock that off it will almost be manageable. [01:45] How do I cancel a bzr mv? [01:45] mkanat: bzr revert? [01:46] markh: I don't want to revert everything, just the mv. [01:46] specify the old name? [01:46] It says my new name isn't versioned. [01:46] or maybe even the new name? :) [01:47] Oh, nevermind. [01:47] Specify the old name was right. :-) [01:47] I was just in the wrong directory. [01:47] yeah, it just worked for me :) [01:47] hello [01:47] g'day martin [01:49] and the next most common test failure is related to URLs not being put together correctly [01:49] eg: [01:49] File "O:\src\bazaar\bzr\bzr.work\bzrlib\tests\test_transport_implementations.py", line 1339, in test_abspath [01:49] transport.abspath("/foo")) [01:49] AssertionError: not equal: [01:49] a = 'unlistable+file:///O:/window%7E1/testbzr-t4cckw.tmp/test_abspath%28UnlistableServer%29/work/foo' [01:49] b = 'unlistable+file:///O:/foo' [01:52] jam, hi? === mw is now known as mw|out [02:05] null pulls seem to have become absurdly fast [02:13] so does anyone understand transport.abspath? [02:16] markh: hi, i think i do [02:17] poolie_: so a test is calling 'transport.abspath("/foo")'. Best I can tell, that boils down basically to 'abspath(transport._rootpath, "/foo")' [02:17] and as the second path is absolute, that always returns '/foo' - ie, the _rootpath is ignored [02:17] that seems plausible [02:17] but, kind odd to be passing that tbh [02:17] normally we should only be working relative to the transport [02:17] which test [02:18] on windows, I'm seeing just /foo - and the test is failing - its expecting to see _rootpath [02:18] (i have to go in a minute but i'll be back) [02:18] I'm wondering how it works on Linux [02:18] test_transport_implementations.TransportTests.test_abspath$ReadonlyServer$ [02:18] (but many of the test_abspath variations fail) [02:18] * awilkins keeps meaning to set up an Ubuntu image for seeing what Linux does for particular test cases [02:19] In [4]: get_transport('file:///home/').abspath('/goo') [02:19] Out[4]: 'file:///goo' [02:19] I've got one, just done have my debugger of choice and never mastered pdb ;) [02:19] Heh, I just insert 'print "bumhole : " + relpath [02:20] Highly unprofessional to use rude words in debug messages but it relieves the tension [02:20] that assertion at line 1338 does seem plausible to me [02:20] heh :) - print "WTF - ", blah is my usual :) [02:20] so it looks like the problem is that transport.clone('/') is not really taking you up to the root [02:21] sorry i need to go or i will miss the shops [02:21] biab [02:21] poolie_: that test works for you though? [02:21] no probs [02:21] on linux, yes [02:21] that is what I don't grok :) [02:21] ttu later [02:21] markh, i'd suspect clone('/') has some kind of bug [02:21] would drill into that [02:21] markh: At least linux HAS a "/" [02:21] Windows doesn't have one, but it does contain drives... [02:22] awilkins: its time you got over your fascination with roots ;) [02:22] * markh ducks [02:23] ok, so clone being wrong is the clue I needed [02:23] Meh, I had to tinker with the local transport to treat "/" specially on Windws [02:23] Hmm. [02:26] hrmph [02:26] Which test is it? [02:26] I think its stranger than that. It doesn't make sense to me that 'transport.abspath('foo') returns me at the root of the transport, while transport.abspath('/foo') gives me the root of the file-system? [02:27] test_abspath in test_transport_implementations [02:27] maybe that is by design. I better understand things more before I jump to conclusions... [02:28] It's my fault [02:28] heh - handy you are here :) [02:28] bisect 3549 and 3550 [02:29] that would be 3549.5? [02:29] 3549 is clean, 3550 introduces the bug [02:29] 3550 fixes SSHD support on windows [02:30] I'm not sure it causes problems for anything but the test, noone has complained [02:30] It doesn't fail on Linux because it's platform specific behaviour [02:31] that path is handling "/" as a special case, but the test isn't testing specifically that - so it might be possible to fix without reverting what you added? [02:31] s/path/patch/ [02:31] I think we can fix the test, probably [02:32] there are quite a few like it actually [02:32] Yipe [02:32] test_has_root_works, test_clone_to_root [02:33] and test_clone_from_root seems about it [02:48] markh: The problem seems to be that abspath makes use of the concept of "root", which windows doesn't have [02:48] well, it does and it doesn't [02:48] (the test, that is) [02:48] \foo does mean something on Windows - its just that '\' doesn't make every file available [02:48] Yes, I exploited the "doesn't" part [02:49] How would a windows server prevent, say, the CD drive from being shared? [02:49] or network shares [02:50] By not sharing them? [02:50] Access control lists? [02:50] hi poolie_ [02:51] jam: hi - poolie ran out to the shops [02:51] Regardless of the merits of one approach over another, /foo is a different idea to \foo because \foo requires you to know what pwd is [02:51] Whereas /foo is always /foo [02:52] awilkins: yeah - but trying to pretend windows is otherwise might be a can of worms [02:52] I'm not a windows server admin would expect '/' to share every mapped drive [02:52] The only case where '/' is allowed as a transport base on windows is when you are executing "bzr serve" [02:53] but - I don't really want to start a debate over that :) [02:53] All other routes in go through checks that prevent you using '/' [02:54] hi markh [02:54] It's the only way that sshd works because the --inet call uses '/' as a transport base [02:54] markh: using anything but a relative path for Transport gets you into the wide world of undefined [02:54] Otherwise you can only server repos that are on the same drive [02:54] as python.exe [02:54] yeah, I'm happy to accept that requirements. I don't quite understand why the tests are failing though when they aren't explicitly testing '/' [02:54] so ".get('/foo')" is ... ? [02:54] I eventually wanted to forbid it [02:54] I don't think we got that far [02:55] It's because on windows, a transport with base '/' is actually '' [02:55] but - these tests don't have a base of '/' do they? They have a base in the temp dir. [02:56] These tests don't have any dir - they are testing path math, not file io [02:57] markh: I believe spiv introduced a test on the behavior of passing '/' [02:57] at the time, I believe I wanted it to abort, but he was fixing some other bug [02:57] and we didn't want to do both. [02:57] jam: the issue is many windows tests are failing, along the lines of: [02:58] File "O:\src\bazaar\bzr\bzr.work\bzrlib\tests\test_transport_implementations.py", line 1295, in test_clone_from_root [02:58] root_transport.clone('.bzr').base) [02:58] AssertionError: not equal: [02:58] a = 'readonly+.bzr/' [02:58] b = 'readonly+file:///O:/window%7E1/testbzr-t4cckw.tmp/lone_from_root%28ReadonlyServer%29/work/.bzr/' [02:58] I'm happy to avoid a debate about the correct semantics for serving '/' at the current time :) [02:58] I apologize for causing this bug by the way :-) [02:59] awilkins: and accept the thanks for fixing the bug :) [02:59] * awilkins is thinking [02:59] no - sorry [02:59] I meant the *original* bug [02:59] it was obviously a real requirement [02:59] markh: so the problem is about ".clone('/')" is returning 'readonly+' instead of returning "readonly+file:///" [03:00] I think it should strip the O: [03:00] The o:// is correct [03:00] o:/ [03:00] I think the *test* is about not doing two '//' [03:00] so you don't get file://// [03:00] well, file:////.bzr [03:01] and the same for [03:01] http://host/.bzr being correct [03:03] a couple of other similar failures also have '+file' and '+.bzr' different in the scheme portions of the URLs, which I suspect is a different problem (but they *also* have the path portion wrong) [03:04] markh: o:/ is where your python.exe is, yes? [03:04] yes, and the source tree and the temp dir [03:05] o:\window%71 is %temp% [03:05] window%71... seems like an interesting temp dir [03:06] o:\Windows_Temp_Files - I've changed %TEMP% in my global environment. I keep getting sick of going digging for it :) [03:06] ahh, o:Window~1 [03:06] and "\temp" has kinda been abused by me over the years to mean more like "scratch" [03:06] the dreaded 8.3 name [03:07] funny story... I worked for a while at a company that tracked stocks [03:07] We had a feed that came in, ~2GB per day [03:07] and o: is my fastest dsik :) [03:07] and it would sort the stocks by prefix a/ b/ c/ etc [03:07] the "D" directory got filled with "DE:foo" because we got the german stocks [03:08] Which caused you to end up with D~1324234 style names [03:08] disabling the 8.3 names made the whole thing go *tremendously* faster [03:08] because you didn't end up with a path collision for *every* file in the directory [03:08] interesting! [03:09] I wonder if it makes things just go faster anyway, it must eliminate a pointless check [03:09] %temp% could end up suffering a similar problem I guess with too many similarly prefixed temp files that don't get cleaned up [03:09] I can't think of anything I use now that needs 8.3. names [03:09] awilkins: yeah, but in this case it is at least O(N) to insert a new file [03:09] because it has to find a new unique 8.3 name [03:09] Nasty [03:10] And when you have 100,000 german stocks... N gets big [03:10] if you disable short paths, I could imagine a few things failing [03:11] markh: yeah, things that don't like spaces, etc. But most *new* programs should do fine [03:11] Then again for %temp% maybe not [03:11] I recall some issue where its extremely hard to use an argv[0] with spaces in it to some exec/spawn function, for example. [03:11] I've personally written code that will fail if win32api.GetShortPathName() fails :( [03:12] but in all cases I've used it, its been the last alternative I could think of [03:13] markh: ah, and tla/baz-1.0 used 8.3 in creative ways [03:13] Specifically, Arch had a really bad habit of repeating itself in path names [03:13] Last I checked it would create a 13-layer deep path structure [03:13] with a lot of redundancy [03:13] Which could easily put you over the 260 char limit [03:13] so we hacked in code [03:13] that would *create* the paths with the full name [03:13] and then remember it as the 8.3 name [03:14] 12 * 13 = 156 chars [03:14] so we would stay underneath MAXPATH [03:14] ugly hack, but it worked [03:14] NTFS can actually use much longer filenames, I think it's just the userland that won't use more than 260 chars [03:14] (academic) [03:14] awilkins: you have to disable the checking [03:14] using \\?\full\path\to\the\file [03:15] You a) can't use a relative path anymore [03:15] and b) cygwin didn't support it [03:15] heh - interesting hack :) [03:15] and Arch only compiled on cygwin [03:15] and most apps don't support it! [03:15] markh: right, Explorer didn't support it [03:15] in XP [03:15] Or at least win 2k [03:15] no point passing a "\\?\" huge string on the command-line to an app that just uses open() on it, for example [03:15] so you couldn't "del" the directory [03:16] you had to rename them [03:16] until it was short enough [03:16] yes [03:16] and *then* delete it [03:16] I've been stuck with exactly that when testing the same issue :) [03:16] And I think explorer actually segfaults trying to browse to the dir [03:16] not "sorry I cannot do that" but actually hangs and dies [03:16] and the cmdprompt failed in creative ways [03:16] I ended up doing the renames under the cmdprompt [03:17] awilkins: so the answer is a "sorta" for paths > 260 [03:17] technically yes, practically no in general :) [03:17] Hg was running into that the last time I used it [03:17] for paths that only you ever work with, yes [03:17] awilkins: yeah, one of the problems with re-using the paths given to you by the user [03:17] it escapes capitals with underscores [03:17] so for long paths with lots of caps in.... [03:18] awilkins: I remember someone who was versioning their Moin, which used capital letters for the hex hashes [03:18] ... nested in c:\Documents and Settings\user\Application Data\Hg [03:18] so you had 40 characters all caps [03:20] at least vista has changed back to reasonable paths in most cases [03:20] So has WinXP when you diddle the install disk [03:21] markh: yeah, I do like C:\Users\username again [03:21] Documents and Settings crummy to type [03:21] awilkins: so without your patch I hate to report I get 26 more tests passing [03:21] I mostly expand env variables when working in those folders these days [03:21] lots of $env:appdata [03:22] markh: 'tis a dilemma [03:23] and it we knock off the LockContention errors we will be down to ~25 errors, which is getting good [03:23] I think that might help some of the errors I've been seeing on auto-packs on SMB shares [03:24] Might be down to bloody oplocks though [03:24] I've seen something similar, but the error is too transient to be locks IMO [03:24] well - bzr's use of locks anyway [03:24] Where you commit to a bound branch and get error 17 [03:24] (you can fix by packing the branch, even over the network) [03:25] can't recall the exact details now [03:25] Neither can I, I must grab the log from the affected users [03:28] awilkins: autopacks don't trigger SMB issues [03:28] IIRC, the problem is that the network stack on win32 doesn't let you write > ~10MB at a time [03:28] and we were expecting normal file operations [03:28] which lets you write say 100MB [03:29] I thought we had a patch for that sort of thing, to "spool" out to files chunks at a time [03:29] should be in either 1.6 or 1.7 [03:29] jam: Would that only work over network transports? [03:29] awilkins: so it happens when writing on SMB [03:29] because apparently the psuedo file [03:29] writes into the network stack [03:29] So we changed it for *all* writes to the filesystem [03:29] Aha [03:30] This is a 1.6 client [03:30] awilkins: we first encountered the issue on networking stuff like bzr+ssh and socket.recv() [03:30] It has my switch sibling patch, but otherwise it's release (I think) [03:30] * Pack operations on windows network shares will work even with large [03:30] files. (Robert Collins, #255656) [03:30] that will be in 1.7rc1 this monday [03:31] bug #255656 [03:31] Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New] https://launchpad.net/bugs/255656 [03:31] THat seems familiar [03:31] Although I seem to remember an error with a "7" in the code as well [03:31] speaking of which, markh, any chance to get a 1.6.1 final build uploaded? [03:31] I'll pull those logs if I recall [03:31] awilkins: well markh mentioned error 17. [03:31] But it certainly sounds like what you were running into [03:36] jam: it actually just finished uploading recently! [03:36] markh: If you change that transport.clone('/') to clone('/bar') and the next line to /bar/foo it fixes those 7 failures. Where are the rest? [03:36] I used the '-1' convention you suggested [03:37] awilkins: of course, you just broke the *point* of that test [03:37] markh: sounds good. Actually, can you update the bazaar-vcs.org/WindowsDownload page as well? [03:39] jam: I confess, I don't understand the point of that line if it's not to check that cloning /bar and getting a relative foo is equivalent to an absolute /bar/foo [03:39] (or / + foo == /foo ) [03:39] awilkins: it is to check that for "/" + "foo" == "/foo" and not "//foo" [03:40] versus '/foo' + 'bar' == '/foo/bar' [03:40] basically it is testing the edge case of when we need to insert an extra slash, and when we don't [03:45] It's 0342 and I'm not functioning. Bedtime. I'm not sure there is a simple way out of this anyway... it's one of those cogitive dissonance/ impedance mismatch/ tomato tomato things [03:46] I always like how "tomato tomato" doesn't work at *all* in print. [03:46] I've see "tomatoe tomato" but then you're just misspelling [03:51] Hi... I'm new to bzr and I'm looking for some help with bzr-svn and ssh tunnels. [03:51] harbinger0x7c0, hi [03:53] jam: updated the wiki [03:53] thx [03:54] Hi, jelmer! So, would you like to hear what I'm trying to do? [03:54] harbinger0x7c0, sure [03:56] There's a svn server I'd like to be able to connect to, but it's behind a firewall I can only bypass by connecting to another machine. I set up a 2-hop ssh tunnel to get through, but I think I'm missing something in the syntax for connecting to it because I get an error about an unsupported protocol. [03:58] The URL I provided was "svn+ssh://alt255@localhost:8080/home/alt255/SemanticAnalysis" [04:02] harbinger0x7c0: well, the first thing to test with any of this, is whether *svn* connects correctly [04:06] That makes sense... I'll try it out and report back. [04:08] Okay. I was able to successfully check out using svn over the same tunnel. [04:11] jam: so best I can tell, the awilkin's patch changed things to that osutils._win32_local_path_to_url('/') no longer includes the current drive in the URL. That doesn't sound good to me. [04:11] markh: the change seems fine to me, as long as it gets expanded to the rest of the code correctly [04:11] I have no problem faking "file:///" on windows when we need to [04:12] I *believe* we already use file://host/ to translate for \\network\drives [04:12] so should "/foo" get the drive back in the URL? [04:12] ie, is only '/' special? [04:12] markh: no "/foo" should just be an illegal filesystem path [04:12] since it doesn't have a drive lettr [04:13] but that doesn't mean we can't create a path file:///foo [04:13] well, we can't create the *file* but we [04:13] can make the string [04:13] yeah - its not an illegal filesystem path :) I understand bzr wants to treat it as special. But that would mean all tests that use '/foo' are invalid on windows? [04:14] and does it mean those tests should actually be throwing an "illegal path" type exception? [04:15] markh: we should *never* be trying to open('/foo') on any system [04:15] markh: no tests should be doing /foo anywhere :P [04:15] so just representing it in memory... seems fine to me [04:16] So I see tests like: [04:16] # the abspath of "/" and "/foo/.." should result in the same location [04:16] self.assertEqual(transport.abspath("/"), transport.abspath("/foo/..")) [04:16] self.assertEqual(transport.clone("/").abspath('foo'), [04:16] transport.abspath("/foo")) [04:16] (sorry for flooding) [04:16] what about tests like 'transport.abspath("/foo")'? [04:17] but that doesn't seem like anything that would really break anywhere [04:17] well - isn't "/foo" an invalid abspath on windows? [04:17] markh: LocalTransport.abspath('/foo') => file:///foo [04:17] markh: it *is* but so is "C:/not/a/direcotry/foo" [04:17] (again, I personally think the transport api should all be relative paths *anyway*, but that is a deeper change) [04:18] so when you say "/foo" is an illegal filesystem path, what's that mean? [04:18] I took it as meaning its an invalid abspath [04:18] markh: so my point is... we don't need to detect that it is invalid until we try to *do* something with it [04:18] because we have to detect when a path doesn't exist anyway [04:18] if its invalid, shouldn't we detect that early? [04:19] again, real code shouldn't be making up paths [04:19] it should take them from the FS with stuff like 'abspath()' etc [04:19] so - getting back on topic - if "/foo" is invalid, the tests should not be using it on windows, right? [04:19] regardless of when it is checked [04:19] hi [04:19] markh: the tests are only testing the join() etc logic, I don't think '/foo' is a problem. [04:20] how can I copy a directory to another directory? [04:20] not move, but copy. I want to copy a directory and make modifications [04:20] and that join logic makes no sense on windows as the path is invalid [04:20] right? [04:21] we don't need to test the "/" edge case for invalid paths - we don't care *what* it returns for practical purposes. [04:23] markh: well, we also are testing http transport etc. There is at least an argument about not running that test for LocalTransport and win32, except we still need to handle join("file:///' , 'C:') correctly, because of things like "bzr serve" [04:24] yes, some new tests are probably needed I agree [04:25] markh: tests that actually do IO shouldn't be using /foo [04:25] markh: I don't think any are [04:26] markh: tests that test url joining logic it should not matter regardless of platform [04:27] markh: and if it does matter, I don't understand why [04:31] sohail: 'cp' - we don't have a copy operation in bzr today [04:31] sohail: (other than 'bzr branch' to make a full new branch [04:31]