| jelmer | 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 |
|---|---|---|
| AfC | fullermd: :) | 00:00 |
| jelmer | AfC, ? | 00:01 |
| jelmer | AfC: If that's what you're saying, I completely agree. | 00:01 |
| AfC | jelmer: yup | 00:01 |
| AfC | 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:02 |
| fullermd | That would work nicer if the last default-upgrade hadn't blown fiery chunks on me :p | 00:03 |
| AfC | fullermd: were they tasty? :) | 00:03 |
| fullermd | I dunno. I force-fed them to lifeless. | 00:04 |
| lifeless | dato: ah well; I'll hope bzr is something you try again from time to time | 00:17 |
| lifeless | AfC: svn does a mandatory upgrade; users complain bitterly in nearly every IRC channel I'm in, on *every* svn release. | 00:18 |
| AfC | lifeless: interesting | 00:22 |
| jelmer | lifeless: I think automatic upgrades should be optional, but they would be nice | 00:23 |
| AfC | 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:23 |
| lifeless | 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 |
| jelmer | lifeless, after all, bzr introduces new formats more often than svn with its 2 year major release cycle | 00:24 |
| lifeless | AfC: unless a plugin or documentation tells you to, you should never need to type --format in annywhere | 00:24 |
| lifeless | jelmer: I could buy into that, with some study on version propogation | 00:24 |
| lifeless | 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 |
| AfC | lifeless: (sorry, but I really believe that `bzr upgrade --1.6.1-rich-root` looks terrible) | 00:25 |
| lifeless | AfC: so do I | 00:26 |
| === kiko is now known as kiko-fud | ||
| AfC | lifeless: er, so why did you just state not to use --format=1.6.1-rich-root? Sorry bud, you lost me | 00:27 |
| lifeless | 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 |
| AfC | I got that part | 00:28 |
| lifeless | the only people affected by the bug are bzr-svn users that have run bzr branch --stacked | 00:28 |
| lifeless | noone else in the world needs to run upgrade --1.6.1-rich-root | 00:29 |
| AfC | It seemed like you were saying "never use the --format" form of specifying a format version | 00:29 |
| lifeless | I was referring to both --format=X and --X | 00:29 |
| AfC | So you're saying we _shouldn't_ have upgraded to X=1.6? | 00:30 |
| lifeless | 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 |
| lifeless | AfC: are you using bzr-svn ? | 00:30 |
| AfC | In this particular repo, no | 00:30 |
| AfC | lifeless: ^ | 00:30 |
| lifeless | AfC: then there is no motivation for you to change your format | 00:30 |
| AfC | oh shit | 00:31 |
| AfC | um, should I downgrade back to --default then? | 00:31 |
| lifeless | the 1.6 family of formats add the logic to support stacked branches (on the side doing the stacking) | 00:31 |
| lifeless | they are no faster or more efficient than the '0.92-pack' family of formats | 00:32 |
| AfC | ah | 00:32 |
| AfC | well shit. | 00:32 |
| AfC | That was a waste of time, then | 00:32 |
| lifeless | if you went to '--1.6' then just leave it, its fine. or go back to --default if you like | 00:32 |
| AfC | I'll stick with "leave it" | 00:32 |
| lifeless | 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:32 |
| AfC | 1.6 | 00:33 |
| lifeless | cool | 00:33 |
| AfC | That'll teach me to be proactive. | 00:33 |
| AfC | Clearly, I should not be doing systems administration before I've had a cappuccino. | 00:33 |
| AfC | And so with that, I go out into the hurricane. | 00:33 |
| lifeless | 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 |
| lifeless | AfC: ^ future reference | 00:34 |
| * AfC celebrates (c) | 00:34 | |
| lifeless | this will always be the case | 00:34 |
| Peng_ | AfC: You should figure out how to upgrade to btrees. :D | 00:35 |
| AfC | I don't think btrees go very well in espresso | 00:35 |
| jelmer | lifeless: What happened to rich-root-pack as default format? | 00:40 |
| lifeless | jelmer: thats how we'll get rid of a) from that list | 00:40 |
| lifeless | 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:41 |
| awilkins | jelmer: Looks like my large SVN repo is nearly done | 00:50 |
| jelmer | awilkins, cool | 00:50 |
| awilkins | About 100 revs to go (it's a bit slow now) | 00:50 |
| awilkins | I'm being a bit rubbish at reading this task manager | 00:51 |
| awilkins | It says "Private bytes 506MB" | 00:51 |
| awilkins | "Virtual Size 1.1GB" | 00:51 |
| awilkins | I have no idea which one is the memory consumption :-) | 00:52 |
| awilkins | 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 | 00:53 |
| awilkins | Someone explain what a rich root is because I can't find a definition in the wiki | 01:15 |
| markh | what I kept looking for as a younger man.... | 01:15 |
| awilkins | 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 | |
| markh | bugger! | 01:16 |
| awilkins | 9647/9699! exciting | 01:17 |
| * awilkins is bored waiting for it and will now try Bazaar on IronPython 2.- b4 | 01:23 | |
| awilkins | ooh, generating file id map | 01:26 |
| awilkins | New steps | 01:26 |
| lifeless | awilkins: | 01:33 |
| lifeless | mistype, sorry | 01:33 |
| markh | 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:42 |
| mkanat | How do I cancel a bzr mv? | 01:45 |
| markh | mkanat: bzr revert? | 01:45 |
| mkanat | markh: I don't want to revert everything, just the mv. | 01:46 |
| markh | specify the old name? | 01:46 |
| mkanat | It says my new name isn't versioned. | 01:46 |
| markh | or maybe even the new name? :) | 01:46 |
| mkanat | Oh, nevermind. | 01:47 |
| mkanat | Specify the old name was right. :-) | 01:47 |
| mkanat | I was just in the wrong directory. | 01:47 |
| markh | yeah, it just worked for me :) | 01:47 |
| poolie_ | hello | 01:47 |
| markh | g'day martin | 01:47 |
| markh | and the next most common test failure is related to URLs not being put together correctly | 01:49 |
| markh | eg: | 01:49 |
| markh | File "O:\src\bazaar\bzr\bzr.work\bzrlib\tests\test_transport_implementations.py", line 1339, in test_abspath | 01:49 |
| markh | transport.abspath("/foo")) | 01:49 |
| markh | AssertionError: not equal: | 01:49 |
| markh | a = 'unlistable+file:///O:/window%7E1/testbzr-t4cckw.tmp/test_abspath%28UnlistableServer%29/work/foo' | 01:49 |
| markh | b = 'unlistable+file:///O:/foo' | 01:49 |
| poolie_ | jam, hi? | 01:52 |
| === mw is now known as mw|out | ||
| bob2 | null pulls seem to have become absurdly fast | 02:05 |
| markh | so does anyone understand transport.abspath? | 02:13 |
| poolie_ | markh: hi, i think i do | 02:16 |
| markh | poolie_: so a test is calling 'transport.abspath("/foo")'. Best I can tell, that boils down basically to 'abspath(transport._rootpath, "/foo")' | 02:17 |
| markh | and as the second path is absolute, that always returns '/foo' - ie, the _rootpath is ignored | 02:17 |
| poolie_ | that seems plausible | 02:17 |
| poolie_ | but, kind odd to be passing that tbh | 02:17 |
| poolie_ | normally we should only be working relative to the transport | 02:17 |
| poolie_ | which test | 02:17 |
| markh | on windows, I'm seeing just /foo - and the test is failing - its expecting to see _rootpath | 02:18 |
| poolie_ | (i have to go in a minute but i'll be back) | 02:18 |
| markh | I'm wondering how it works on Linux | 02:18 |
| markh | test_transport_implementations.TransportTests.test_abspath\(ReadonlyServer\) | 02:18 |
| markh | (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:18 | |
| poolie_ | In [4]: get_transport('file:///home/').abspath('/goo') | 02:19 |
| poolie_ | Out[4]: 'file:///goo' | 02:19 |
| markh | I've got one, just done have my debugger of choice and never mastered pdb ;) | 02:19 |
| awilkins | Heh, I just insert 'print "bumhole : " + relpath | 02:19 |
| awilkins | Highly unprofessional to use rude words in debug messages but it relieves the tension | 02:20 |
| poolie_ | that assertion at line 1338 does seem plausible to me | 02:20 |
| markh | heh :) - print "WTF - ", blah is my usual :) | 02:20 |
| poolie_ | so it looks like the problem is that transport.clone('/') is not really taking you up to the root | 02:20 |
| poolie_ | sorry i need to go or i will miss the shops | 02:21 |
| poolie_ | biab | 02:21 |
| markh | poolie_: that test works for you though? | 02:21 |
| markh | no probs | 02:21 |
| poolie_ | on linux, yes | 02:21 |
| markh | that is what I don't grok :) | 02:21 |
| markh | ttu later | 02:21 |
| poolie_ | markh, i'd suspect clone('/') has some kind of bug | 02:21 |
| poolie_ | would drill into that | 02:21 |
| awilkins | markh: At least linux HAS a "/" | 02:21 |
| awilkins | Windows doesn't have one, but it does contain drives... | 02:21 |
| markh | awilkins: its time you got over your fascination with roots ;) | 02:22 |
| * markh ducks | 02:22 | |
| markh | ok, so clone being wrong is the clue I needed | 02:23 |
| awilkins | Meh, I had to tinker with the local transport to treat "/" specially on Windws | 02:23 |
| awilkins | Hmm. | 02:23 |
| markh | hrmph | 02:26 |
| awilkins | Which test is it? | 02:26 |
| markh | 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:26 |
| markh | test_abspath in test_transport_implementations | 02:27 |
| markh | maybe that is by design. I better understand things more before I jump to conclusions... | 02:27 |
| awilkins | It's my fault | 02:28 |
| markh | heh - handy you are here :) | 02:28 |
| awilkins | bisect 3549 and 3550 | 02:28 |
| markh | that would be 3549.5? | 02:29 |
| awilkins | 3549 is clean, 3550 introduces the bug | 02:29 |
| awilkins | 3550 fixes SSHD support on windows | 02:29 |
| awilkins | I'm not sure it causes problems for anything but the test, noone has complained | 02:30 |
| awilkins | It doesn't fail on Linux because it's platform specific behaviour | 02:30 |
| markh | 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 |
| markh | s/path/patch/ | 02:31 |
| awilkins | I think we can fix the test, probably | 02:31 |
| markh | there are quite a few like it actually | 02:32 |
| awilkins | Yipe | 02:32 |
| markh | test_has_root_works, test_clone_to_root | 02:32 |
| markh | and test_clone_from_root seems about it | 02:33 |
| awilkins | markh: The problem seems to be that abspath makes use of the concept of "root", which windows doesn't have | 02:48 |
| markh | well, it does and it doesn't | 02:48 |
| awilkins | (the test, that is) | 02:48 |
| markh | \foo does mean something on Windows - its just that '\' doesn't make every file available | 02:48 |
| awilkins | Yes, I exploited the "doesn't" part | 02:48 |
| markh | How would a windows server prevent, say, the CD drive from being shared? | 02:49 |
| markh | or network shares | 02:49 |
| awilkins | By not sharing them? | 02:50 |
| awilkins | Access control lists? | 02:50 |
| jam | hi poolie_ | 02:50 |
| markh | jam: hi - poolie ran out to the shops | 02:51 |
| awilkins | 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 |
| awilkins | Whereas /foo is always /foo | 02:51 |
| markh | awilkins: yeah - but trying to pretend windows is otherwise might be a can of worms | 02:52 |
| markh | I'm not a windows server admin would expect '/' to share every mapped drive | 02:52 |
| awilkins | The only case where '/' is allowed as a transport base on windows is when you are executing "bzr serve" | 02:52 |
| markh | but - I don't really want to start a debate over that :) | 02:53 |
| awilkins | All other routes in go through checks that prevent you using '/' | 02:53 |
| jam | hi markh | 02:54 |
| awilkins | It's the only way that sshd works because the --inet call uses '/' as a transport base | 02:54 |
| jam | markh: using anything but a relative path for Transport gets you into the wide world of undefined | 02:54 |
| awilkins | Otherwise you can only server repos that are on the same drive | 02:54 |
| awilkins | as python.exe | 02:54 |
| markh | 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 |
| jam | so ".get('/foo')" is ... ? | 02:54 |
| jam | I eventually wanted to forbid it | 02:54 |
| jam | I don't think we got that far | 02:54 |
| awilkins | It's because on windows, a transport with base '/' is actually '' | 02:55 |
| markh | but - these tests don't have a base of '/' do they? They have a base in the temp dir. | 02:55 |
| awilkins | These tests don't have any dir - they are testing path math, not file io | 02:56 |
| jam | markh: I believe spiv introduced a test on the behavior of passing '/' | 02:57 |
| jam | at the time, I believe I wanted it to abort, but he was fixing some other bug | 02:57 |
| jam | and we didn't want to do both. | 02:57 |
| markh | jam: the issue is many windows tests are failing, along the lines of: | 02:57 |
| markh | File "O:\src\bazaar\bzr\bzr.work\bzrlib\tests\test_transport_implementations.py", line 1295, in test_clone_from_root | 02:58 |
| markh | root_transport.clone('.bzr').base) | 02:58 |
| markh | AssertionError: not equal: | 02:58 |
| markh | a = 'readonly+.bzr/' | 02:58 |
| markh | b = 'readonly+file:///O:/window%7E1/testbzr-t4cckw.tmp/lone_from_root%28ReadonlyServer%29/work/.bzr/' | 02:58 |
| markh | I'm happy to avoid a debate about the correct semantics for serving '/' at the current time :) | 02:58 |
| awilkins | I apologize for causing this bug by the way :-) | 02:58 |
| markh | awilkins: and accept the thanks for fixing the bug :) | 02:59 |
| * awilkins is thinking | 02:59 | |
| markh | no - sorry | 02:59 |
| markh | I meant the *original* bug | 02:59 |
| markh | it was obviously a real requirement | 02:59 |
| jam | markh: so the problem is about ".clone('/')" is returning 'readonly+' instead of returning "readonly+file:///" | 02:59 |
| jam | I think it should strip the O: | 03:00 |
| awilkins | The o:// is correct | 03:00 |
| awilkins | o:/ | 03:00 |
| jam | I think the *test* is about not doing two '//' | 03:00 |
| jam | so you don't get file://// | 03:00 |
| jam | well, file:////.bzr | 03:00 |
| jam | and the same for | 03:01 |
| jam | http://host/.bzr being correct | 03:01 |
| markh | 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:03 |
| awilkins | markh: o:/ is where your python.exe is, yes? | 03:04 |
| markh | yes, and the source tree and the temp dir | 03:04 |
| markh | o:\window%71 is %temp% | 03:05 |
| jam | window%71... seems like an interesting temp dir | 03:05 |
| markh | o:\Windows_Temp_Files - I've changed %TEMP% in my global environment. I keep getting sick of going digging for it :) | 03:06 |
| jam | ahh, o:Window~1 | 03:06 |
| markh | and "\temp" has kinda been abused by me over the years to mean more like "scratch" | 03:06 |
| jam | the dreaded 8.3 name | 03:06 |
| jam | funny story... I worked for a while at a company that tracked stocks | 03:07 |
| jam | We had a feed that came in, ~2GB per day | 03:07 |
| markh | and o: is my fastest dsik :) | 03:07 |
| jam | and it would sort the stocks by prefix a/ b/ c/ etc | 03:07 |
| jam | the "D" directory got filled with "DE:foo" because we got the german stocks | 03:07 |
| jam | Which caused you to end up with D~1324234 style names | 03:08 |
| jam | disabling the 8.3 names made the whole thing go *tremendously* faster | 03:08 |
| jam | because you didn't end up with a path collision for *every* file in the directory | 03:08 |
| markh | interesting! | 03:08 |
| awilkins | I wonder if it makes things just go faster anyway, it must eliminate a pointless check | 03:09 |
| markh | %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 |
| awilkins | I can't think of anything I use now that needs 8.3. names | 03:09 |
| jam | awilkins: yeah, but in this case it is at least O(N) to insert a new file | 03:09 |
| jam | because it has to find a new unique 8.3 name | 03:09 |
| awilkins | Nasty | 03:09 |
| jam | And when you have 100,000 german stocks... N gets big | 03:10 |
| markh | if you disable short paths, I could imagine a few things failing | 03:10 |
| jam | markh: yeah, things that don't like spaces, etc. But most *new* programs should do fine | 03:11 |
| jam | Then again for %temp% maybe not | 03:11 |
| markh | 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 |
| markh | I've personally written code that will fail if win32api.GetShortPathName() fails :( | 03:11 |
| markh | but in all cases I've used it, its been the last alternative I could think of | 03:12 |
| jam | markh: ah, and tla/baz-1.0 used 8.3 in creative ways | 03:13 |
| jam | Specifically, Arch had a really bad habit of repeating itself in path names | 03:13 |
| jam | Last I checked it would create a 13-layer deep path structure | 03:13 |
| jam | with a lot of redundancy | 03:13 |
| jam | Which could easily put you over the 260 char limit | 03:13 |
| jam | so we hacked in code | 03:13 |
| jam | that would *create* the paths with the full name | 03:13 |
| jam | and then remember it as the 8.3 name | 03:13 |
| jam | 12 * 13 = 156 chars | 03:14 |
| jam | so we would stay underneath MAXPATH | 03:14 |
| jam | ugly hack, but it worked | 03:14 |
| awilkins | NTFS can actually use much longer filenames, I think it's just the userland that won't use more than 260 chars | 03:14 |
| awilkins | (academic) | 03:14 |
| jam | awilkins: you have to disable the checking | 03:14 |
| jam | using \\?\full\path\to\the\file | 03:14 |
| jam | You a) can't use a relative path anymore | 03:15 |
| jam | and b) cygwin didn't support it | 03:15 |
| markh | heh - interesting hack :) | 03:15 |
| jam | and Arch only compiled on cygwin | 03:15 |
| markh | and most apps don't support it! | 03:15 |
| jam | markh: right, Explorer didn't support it | 03:15 |
| jam | in XP | 03:15 |
| jam | Or at least win 2k | 03:15 |
| markh | no point passing a "\\?\" huge string on the command-line to an app that just uses open() on it, for example | 03:15 |
| jam | so you couldn't "del" the directory | 03:15 |
| jam | you had to rename them | 03:16 |
| jam | until it was short enough | 03:16 |
| markh | yes | 03:16 |
| jam | and *then* delete it | 03:16 |
| markh | I've been stuck with exactly that when testing the same issue :) | 03:16 |
| jam | And I think explorer actually segfaults trying to browse to the dir | 03:16 |
| jam | not "sorry I cannot do that" but actually hangs and dies | 03:16 |
| markh | and the cmdprompt failed in creative ways | 03:16 |
| markh | I ended up doing the renames under the cmdprompt | 03:16 |
| jam | awilkins: so the answer is a "sorta" for paths > 260 | 03:17 |
| markh | technically yes, practically no in general :) | 03:17 |
| awilkins | Hg was running into that the last time I used it | 03:17 |
| markh | for paths that only you ever work with, yes | 03:17 |
| jam | awilkins: yeah, one of the problems with re-using the paths given to you by the user | 03:17 |
| awilkins | it escapes capitals with underscores | 03:17 |
| awilkins | so for long paths with lots of caps in.... | 03:17 |
| jam | awilkins: I remember someone who was versioning their Moin, which used capital letters for the hex hashes | 03:18 |
| awilkins | ... nested in c:\Documents and Settings\user\Application Data\Hg | 03:18 |
| jam | so you had 40 characters all caps | 03:18 |
| markh | at least vista has changed back to reasonable paths in most cases | 03:20 |
| awilkins | So has WinXP when you diddle the install disk | 03:20 |
| jam | markh: yeah, I do like C:\Users\username again | 03:21 |
| jam | Documents and Settings crummy to type | 03:21 |
| markh | awilkins: so without your patch I hate to report I get 26 more tests passing | 03:21 |
| awilkins | I mostly expand env variables when working in those folders these days | 03:21 |
| awilkins | lots of $env:appdata | 03:21 |
| awilkins | markh: 'tis a dilemma | 03:22 |
| markh | and it we knock off the LockContention errors we will be down to ~25 errors, which is getting good | 03:23 |
| awilkins | I think that might help some of the errors I've been seeing on auto-packs on SMB shares | 03:23 |
| awilkins | Might be down to bloody oplocks though | 03:24 |
| markh | I've seen something similar, but the error is too transient to be locks IMO | 03:24 |
| markh | well - bzr's use of locks anyway | 03:24 |
| awilkins | Where you commit to a bound branch and get error 17 | 03:24 |
| awilkins | (you can fix by packing the branch, even over the network) | 03:24 |
| markh | can't recall the exact details now | 03:25 |
| awilkins | Neither can I, I must grab the log from the affected users | 03:25 |
| jam | awilkins: autopacks don't trigger SMB issues | 03:28 |
| jam | IIRC, the problem is that the network stack on win32 doesn't let you write > ~10MB at a time | 03:28 |
| jam | and we were expecting normal file operations | 03:28 |
| jam | which lets you write say 100MB | 03:28 |
| jam | I thought we had a patch for that sort of thing, to "spool" out to files chunks at a time | 03:29 |
| jam | should be in either 1.6 or 1.7 | 03:29 |
| awilkins | jam: Would that only work over network transports? | 03:29 |
| jam | awilkins: so it happens when writing on SMB | 03:29 |
| jam | because apparently the psuedo file | 03:29 |
| jam | writes into the network stack | 03:29 |
| jam | So we changed it for *all* writes to the filesystem | 03:29 |
| awilkins | Aha | 03:29 |
| awilkins | This is a 1.6 client | 03:30 |
| jam | awilkins: we first encountered the issue on networking stuff like bzr+ssh and socket.recv() | 03:30 |
| awilkins | It has my switch sibling patch, but otherwise it's release (I think) | 03:30 |
| jam | * Pack operations on windows network shares will work even with large | 03:30 |
| jam | files. (Robert Collins, #255656) | 03:30 |
| jam | that will be in 1.7rc1 this monday | 03:30 |
| jam | bug #255656 | 03:31 |
| ubottu | 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 |
| awilkins | THat seems familiar | 03:31 |
| awilkins | Although I seem to remember an error with a "7" in the code as well | 03:31 |
| jam | speaking of which, markh, any chance to get a 1.6.1 final build uploaded? | 03:31 |
| awilkins | I'll pull those logs if I recall | 03:31 |
| jam | awilkins: well markh mentioned error 17. | 03:31 |
| jam | But it certainly sounds like what you were running into | 03:31 |
| markh | jam: it actually just finished uploading recently! | 03:36 |
| awilkins | 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 |
| markh | I used the '-1' convention you suggested | 03:36 |
| jam | awilkins: of course, you just broke the *point* of that test | 03:37 |
| jam | markh: sounds good. Actually, can you update the bazaar-vcs.org/WindowsDownload page as well? | 03:37 |
| awilkins | 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 |
| awilkins | (or / + foo == /foo ) | 03:39 |
| jam | awilkins: it is to check that for "/" + "foo" == "/foo" and not "//foo" | 03:39 |
| jam | versus '/foo' + 'bar' == '/foo/bar' | 03:40 |
| jam | basically it is testing the edge case of when we need to insert an extra slash, and when we don't | 03:40 |
| awilkins | 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:45 |
| jam | I always like how "tomato tomato" doesn't work at *all* in print. | 03:46 |
| jam | I've see "tomatoe tomato" but then you're just misspelling | 03:46 |
| harbinger0x7c0 | Hi... I'm new to bzr and I'm looking for some help with bzr-svn and ssh tunnels. | 03:51 |
| jelmer | harbinger0x7c0, hi | 03:51 |
| markh | jam: updated the wiki | 03:53 |
| jam | thx | 03:53 |
| harbinger0x7c0 | Hi, jelmer! So, would you like to hear what I'm trying to do? | 03:54 |
| jelmer | harbinger0x7c0, sure | 03:54 |
| harbinger0x7c0 | 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:56 |
| harbinger0x7c0 | The URL I provided was "svn+ssh://alt255@localhost:8080/home/alt255/SemanticAnalysis" | 03:58 |
| jam | harbinger0x7c0: well, the first thing to test with any of this, is whether *svn* connects correctly | 04:02 |
| harbinger0x7c0 | That makes sense... I'll try it out and report back. | 04:06 |
| harbinger0x7c0 | Okay. I was able to successfully check out using svn over the same tunnel. | 04:08 |
| markh | 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 |
| jam | markh: the change seems fine to me, as long as it gets expanded to the rest of the code correctly | 04:11 |
| jam | I have no problem faking "file:///" on windows when we need to | 04:11 |
| jam | I *believe* we already use file://host/ to translate for \\network\drives | 04:12 |
| markh | so should "/foo" get the drive back in the URL? | 04:12 |
| markh | ie, is only '/' special? | 04:12 |
| jam | markh: no "/foo" should just be an illegal filesystem path | 04:12 |
| jam | since it doesn't have a drive lettr | 04:12 |
| jam | but that doesn't mean we can't create a path file:///foo | 04:13 |
| jam | well, we can't create the *file* but we | 04:13 |
| jam | can make the string | 04:13 |
| markh | 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:13 |
| markh | and does it mean those tests should actually be throwing an "illegal path" type exception? | 04:14 |
| jam | markh: we should *never* be trying to open('/foo') on any system | 04:15 |
| lifeless | markh: no tests should be doing /foo anywhere :P | 04:15 |
| jam | so just representing it in memory... seems fine to me | 04:15 |
| jam | So I see tests like: | 04:16 |
| jam | # the abspath of "/" and "/foo/.." should result in the same location | 04:16 |
| jam | self.assertEqual(transport.abspath("/"), transport.abspath("/foo/..")) | 04:16 |
| jam | self.assertEqual(transport.clone("/").abspath('foo'), | 04:16 |
| jam | transport.abspath("/foo")) | 04:16 |
| jam | (sorry for flooding) | 04:16 |
| markh | what about tests like 'transport.abspath("/foo")'? | 04:16 |
| jam | but that doesn't seem like anything that would really break anywhere | 04:17 |
| markh | well - isn't "/foo" an invalid abspath on windows? | 04:17 |
| jam | markh: LocalTransport.abspath('/foo') => file:///foo | 04:17 |
| jam | markh: it *is* but so is "C:/not/a/direcotry/foo" | 04:17 |
| jam | (again, I personally think the transport api should all be relative paths *anyway*, but that is a deeper change) | 04:17 |
| markh | so when you say "/foo" is an illegal filesystem path, what's that mean? | 04:18 |
| markh | I took it as meaning its an invalid abspath | 04:18 |
| jam | 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 |
| jam | because we have to detect when a path doesn't exist anyway | 04:18 |
| markh | if its invalid, shouldn't we detect that early? | 04:18 |
| jam | again, real code shouldn't be making up paths | 04:19 |
| jam | it should take them from the FS with stuff like 'abspath()' etc | 04:19 |
| markh | so - getting back on topic - if "/foo" is invalid, the tests should not be using it on windows, right? | 04:19 |
| markh | regardless of when it is checked | 04:19 |
| sohail | hi | 04:19 |
| jam | markh: the tests are only testing the join() etc logic, I don't think '/foo' is a problem. | 04:19 |
| sohail | how can I copy a directory to another directory? | 04:20 |
| sohail | not move, but copy. I want to copy a directory and make modifications | 04:20 |
| markh | and that join logic makes no sense on windows as the path is invalid | 04:20 |
| markh | right? | 04:20 |
| markh | we don't need to test the "/" edge case for invalid paths - we don't care *what* it returns for practical purposes. | 04:21 |
| jam | 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:23 |
| markh | yes, some new tests are probably needed I agree | 04:24 |
| lifeless | markh: tests that actually do IO shouldn't be using /foo | 04:25 |
| lifeless | markh: I don't think any are | 04:25 |
| lifeless | markh: tests that test url joining logic it should not matter regardless of platform | 04:26 |
| lifeless | markh: and if it does matter, I don't understand why | 04:27 |
| lifeless | sohail: 'cp' - we don't have a copy operation in bzr today | 04:31 |
| lifeless | sohail: (other than 'bzr branch' to make a full new branch | 04:31 |
| sohail | lifeless, doh :-( | 04:31 |
| sohail | I have a presentation that I want to rip up | 04:31 |
| sohail | I guess I can just do a file system copy | 04:32 |
| jelmer | harbinger0x7c0, sorry, was away for a bit | 04:42 |
| jelmer | harbinger0x7c0, what's the error you get with bzr-svn? | 04:42 |
| harbinger0x7c0 | jelmer: the error is 'bzr: ERROR: Unsupported protocol for url "svn+ssh://alt255@localhost:8080/home/alt255/SemanticAnalysis"' | 04:48 |
| jelmer | harbinger0x7c0, is bzr-svn listed if you run "bzr plugins" ? | 04:48 |
| harbinger0x7c0 | jelmer: heh... no. :-[ | 04:50 |
| jelmer | harbinger0x7c0, so it looks like bzr-svn isn't installed correctly | 04:54 |
| harbinger0x7c0 | jelmer: it looks like I'm short the svn development files. Do you know what they would be named for Fedora? | 05:12 |
| jelmer | harbinger0x7c0, on Debian/Ubuntu it's libsvn-dev, not sure about fedora | 05:12 |
| harbinger0x7c0 | jelmer: I got 'make' to finish, but now when I use 'bzr plugins' it says "Unable to load plugin 'svn' from '/home/tomas/.bazaar/plugins'". | 05:23 |
| jelmer | harbinger0x7c0, please check ~/.bzr.log | 05:24 |
| harbinger0x7c0 | There's an "AttributeError: 'module' object has no attribute 'properties_handler_registry'" from line 160 of __init__.py | 05:28 |
| jelmer | harbinger0x7c0, your version of bzr is too old | 05:38 |
| harbinger0x7c0 | jelmer: so I need an older svn-bzr? | 05:39 |
| jelmer | harbinger0x7c0: yeah - see the list on bzr-svn's wiki page | 05:39 |
| harbinger0x7c0 | jelmer: lol, now it's unhappy about the python bindings. It's starting to look like maybe 'yum' isn't always as convenient as I thought. | 05:45 |
| jelmer | harbinger0x7c0, you can't use the vanilla python bindings with fedora if you're using bzr-svn < 0.4.11 | 05:46 |
| harbinger0x7c0 | jelmer: I need to find the Fedora analog to the 'python-subversion' package, right? | 05:48 |
| jelmer | harbinger0x7c0, if you have bzr-svn < 0.4.11 you need to apply certain patches to python-subversion as well | 05:49 |
| jelmer | you can't just use the released version of python-subversion, since fedora doesn't carry the required patches afaik | 05:49 |
| harbinger0x7c0 | jelmer: I think I'm going to see about just getting a more recent version of bzr instead... That's seeming a little simpler just now. | 05:50 |
| markh | jam: you still here? | 05:56 |
| harbinger0x7c0 | jelmer: thanks for your help. I think I'm done playing with this for tonight. | 05:57 |
| clemente | The release notes for 1.6.1 are not linked in the home page; is this intended? | 08:41 |
| poolie__ | clemente: they probably should be hey? | 08:42 |
| clemente | poolie__: I think so. Lots of people want to see what's new | 08:43 |
| poolie__ | how's that? | 08:43 |
| === poolie__ is now known as poolie | ||
| markh | poolie: found a 2 line patch to solve 32 of those LocalTransport test failures :) | 08:44 |
| clemente | I think that many people are waiting for bzr to greatly improve and become better than the others :-) | 08:44 |
| clemente | therefore they are curious about the new improvements | 08:45 |
| poolie | markh, nice | 08:46 |
| markh | so if we get rid of the lock contention, we will be close to 20 errors left!! | 08:48 |
| LarstiQ | sweet! | 08:50 |
| jml | lifeless: thanks for the review | 08:56 |
| jml | lifeless: but you are never, ever going to convince me that adsorbSuite is a good name for anything :) | 08:56 |
| poolie | really 'adsorb'? | 09:00 |
| mwhudson | my word, jml on a weekend | 09:01 |
| markh | heh - and a 1 character change for the other last 3 :) | 09:05 |
| * markh mutters about linux people forgetting the 'b' in the file-mode... ;) | 09:05 | |
| jml | poolie: really. | 09:11 |
| jml | mwhudson: yes! I have internet at home | 09:11 |
| poolie | aside from anything else that distracted me into wikipedia description of material science | 09:11 |
| poolie | :) | 09:11 |
| mwhudson | jml: congratulations | 09:11 |
| poolie | Adsorption is a process that occurs when a gas or liquid solute accumulates on the surface of a solid or a liquid | 09:11 |
| mwhudson | yeah, adsorb is something to do with catalysts, isn't it? | 09:11 |
| jml | I suggest "test_suite_nomnomnom" as an alternative | 09:12 |
| mwhudson | jml: ha | 09:12 |
| poolie | i guess it's just possible that the tests accumulate on the surface of the other test | 09:12 |
| LarstiQ | markh: ai, I may be guilty of that myself. | 09:12 |
| * jml goes to watch film | 09:14 | |
| lifeless | jml: I'm not defending adsorb | 09:15 |
| lifeless | jml: I appreciate that making people read dictionaries is not a goal of testresources :). But the replacement name has its own issues, which is what I focused on, I thought | 09:16 |
| LarstiQ | what's wrong with nomnomnom? | 09:16 |
| lifeless | LarstiQ: too many things | 09:17 |
| * LarstiQ ducks for cover | 09:17 | |
| poolie | night all | 10:23 |
| poolie | lifeless: did you mean absorb or adsorb? | 10:23 |
| poolie | anyhow, night! | 10:23 |
| fullermd | Mmph. So, are we really seriously not putting releases in bazaar-vcs.org/releases/src/ anymore? | 10:30 |
| * markh learnt today that adsorb was a word! | 10:40 | |
| AfC | Aren't we just the Oxford English Dictionary today. | 10:45 |
| * AfC just looked it up. I had no idea that was a word either | 10:46 | |
| poolie | fullermd: yes, we should be | 10:49 |
| poolie | there is a makefile rule to do it and it's in the process doc | 10:50 |
| poolie | there may have been a technical issue | 10:50 |
| poolie | anyhow, seriously goodnight! | 10:50 |
| fullermd | Oddly enough, I knew that word, though for the life of me I can't think of any good reason why I would. | 10:54 |
| pfeil | Hi, I would like to set up a bzr server for an open source project. I will push the inital source code, every body else can branch. When someone has modifyed the source, he/she should be able to commit, but without touching my stable branch. I will then review the changes and merge when appropiate to the release trunk. (This model is described as "1.3.7 Decentralized with human gatekeeper" in the Bazaar User Guide). Can someone point me to where | 11:16 |
| AfC | to where...? | 11:17 |
| fullermd | To where! | 11:18 |
| Odd_Bloke | pfeil: You got cut off at 'to where'. :) | 11:18 |
| pfeil | Can someone point me to where I find instructions on how to set up the server? | 11:19 |
| pfeil | And - especially - the permission rights. | 11:19 |
| mwhudson | well, this sort of thing is extremely easy on launchpad | 11:19 |
| AfC | If you have a server where they have (or you can create) normal user accounts for each committer, it's pretty easy too. | 11:20 |
| pfeil | I have already lokked into that, but I have a very restrict OpenSource licences, so Launchpad is not right for me. | 11:20 |
| AfC | "restrictive" and "open source" do not go in the same sentence. | 11:21 |
| pfeil | I have a ubuntu 8.04 server running ssh+sftp + whatever I will need... | 11:21 |
| pfeil | AfC: Well to be more precisely: Its Open SOurce, Users may not make money with it and are foreced to submit ALL changes. | 11:22 |
| AfC | pfeil: so for what it's worth, we have the setup you require in the repository we host. It does work to isolate one group of developers from another. You just use unix permissions and an appropriate umask. Frankly it's got nothing to do with bzr and everything to do with systems administration. | 11:26 |
| Odd_Bloke | pfeil: What license is it under? | 11:27 |
| pfeil | It is a propriate license, I am working on just right now - no official or approved Open Source License. | 11:28 |
| Odd_Bloke | OK. | 11:28 |
| Odd_Bloke | As AfC said, if you have a server where users have a login, then the problem is trivial. | 11:29 |
| AfC | Odd_Bloke: (well, not quite - he wants isolation. That makes it trickier) | 11:29 |
| pfeil | Odd_bloke: Yes I have a server. When I understand the abouve posting right, I will have to add a user account for every subsriber to the project? | 11:29 |
| Odd_Bloke | AfC: "restrictive" and "open source" often go together. The GPL is very restrictive, in order to ensure that the four freedoms aren't compromised. | 11:30 |
| Odd_Bloke | AfC: Well, they just push to a world-readable branch in a well defined place in their home directory. | 11:30 |
| AfC | Odd_Bloke: sure sure. But you know what I was talking about. And so does he. It's either Open Source or it isn't. It's not really something we need to quibble about. | 11:30 |
| Odd_Bloke | Which you can easily setup in locations.conf. | 11:31 |
| fullermd | Not something we have to quib... dude, it's IRC! | 11:32 |
| pfeil | Well is there any docu about setting this up. I am not expreienced with seiitng bzr up on a server at all and i dont want to open wide security holes. | 11:33 |
| AfC | fullermd: :) | 11:33 |
| kowey | howdy, #bzr folks! is one of the organisers for the previous bzr sprint around, please? | 11:34 |
| Odd_Bloke | pfeil: If you are happy to use separate account for each user, then just treat bzr branches as directories in terms of security. | 11:34 |
| AfC | Making that work with a shared repository takes a bit of care but is a nice touch. | 11:38 |
| pfeil | I would like to read a howto. Without, I will have to try around. This will take time. If there is a doc out there, I would be more than happy if someone can point me to it. | 11:47 |
| === fta_ is now known as fta | ||
| === kowey is now known as koweywork | ||
| AfC | Pardon the dumb question, but I'm not a regular Ubuntu/Debian user these days. What do I have to do after adding the PPA line to a sources.list to make apt-get upgrade not ignore it? | 12:40 |
| AfC | (something about accepting a signature?) | 12:40 |
| AfC | Hm. Forget it. I guess it works anyway | 12:41 |
| ronny | hi | 13:13 |
| ronny | anyone knows if "Javier Derderian" shows up here from time to time? | 13:13 |
| === jelmer is now known as Guest2056 | ||
| hsn_ | python based installer for 1.6 available? | 14:17 |
| Kamping_Kaiser | if i want to export a bzr repo into something i can make .debs out of, what tool do i need? i cant seem to see one in the bzrtools package. | 14:28 |
| Odd_Bloke | hsn_: What do you mean by 'python based installer'? | 14:32 |
| Odd_Bloke | Kamping_Kaiser: 'bzr export'. | 14:32 |
| Kamping_Kaiser | hm. ok, thanks Odd_Bloke | 14:34 |
| Odd_Bloke | Kamping_Kaiser: Alternatively, use 'bzr-buildpackage --split'. | 14:39 |
| Kamping_Kaiser | Odd_Bloke, hm. thank you. i think thats wha ti was after | 14:42 |
| Kamping_Kaiser | Odd_Bloke, yes, thats what i was after. thanks very much :) | 14:48 |
| Odd_Bloke | Kamping_Kaiser: No worries. | 14:48 |
| hsn_ | Odd_Bloke: installer without included python | 14:58 |
| Odd_Bloke | hsn_: Presumably you mean for Windows. I'm afraid I don't know. | 15:02 |
| Odd_Bloke | markh and bialix are the two primary Windows people. | 15:02 |
| Odd_Bloke | But I don't know if markh is around over weekends. | 15:03 |
| === Stellaris_ is now known as Stellaris__ | ||
| === Stellaris__ is now known as Stell23 | ||
| Peaker | hey, isn't "lp://proj-name/branch-name" an acceptable URL for bzr? (Launchpad) | 15:58 |
| Peaker | oh nm, found the right URL | 15:59 |
| Odd_Bloke | Peaker: lp:proj-name/branch-name is presumably what you found. | 16:05 |
| Peaker | Yeah, dropping the // | 16:05 |
| Peaker | also registered the project properly | 16:05 |
| Odd_Bloke | :D | 16:05 |
| Peaker | I just registered xpdb - forking pdb to fix its troubles | 16:05 |
| Peaker | (pdb.py) | 16:05 |
| === kiko is now known as kiko-afk | ||
| wolever | I'm having a weird problem where `bzr log $FILE` seems to show _all_ revisions (that is, the same as `bzr log`) instead of just the revisions in which $FILE is changed... Any advice? | 17:05 |
| beuno | wolever, that *is* odd | 17:06 |
| beuno | what version of bzr are you using? | 17:06 |
| wolever | 1.6 | 17:07 |
| wolever | This is a branch which was created with bzr-svn, if that's relevant | 17:07 |
| beuno | ah, that could be why | 17:07 |
| beuno | wolever, are you subscribed to our mailing list? | 17:07 |
| wolever | No, but I could be | 17:08 |
| beuno | because it's the weekend, and all the relevant people seem to be resting for some reason | 17:09 |
| beuno | or, you could file a bug/question in Launchpad | 17:09 |
| beuno | whichever you rpefer | 17:09 |
| beuno | prefer even | 17:09 |
| wolever | Ok | 17:09 |
| wolever | I'll try my luck on the mailing list -- thanks | 17:09 |
| beuno | welcome' | 17:09 |
| wolever | I presume the users list would be more appropriate than the developers? | 17:11 |
| beuno | we actually don't have a users list | 17:12 |
| beuno | we're one big family | 17:12 |
| beuno | and all developers are very friendly | 17:12 |
| wolever | Ah, good stuff -- and I guess that's this one: https://lists.ubuntu.com/mailman/listinfo/bazaar ? | 17:12 |
| beuno | yeap | 17:12 |
| wolever | Yes, this is defiantly a problem with bzr-svn... I'll post to their bug tracker instead. | 17:35 |
| Guest2056 | wolever, what verison of bzr-svn are you using? | 17:39 |
| wolever | Guest2056: I'm just in the middle of updating to the newist version -- lemme check and get back to you | 17:40 |
| wolever | Dang | 17:45 |
| wolever | After updating to the newest bzr-svn it's just erroring out | 17:45 |
| Guest2056 | wolever, you updated to 0.4.12 ? | 17:45 |
| wolever | I'm running the HEAD of http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.4/ | 17:46 |
| wolever | Here are the commands I'm running: http://pastebin.com/d73819fb1 | 17:49 |
| wolever | Before everything was dying, the `bzr log a` would show both revisions -- not just the revision which 'a' was added. | 17:50 |
| wolever | Darn -- the last line should be `bzr log a` :P | 17:50 |
| Guest2056 | wolever, "bzr log a" shows just one revision here | 17:53 |
| wolever | Which version of bzr-svn are you using? | 17:53 |
| Guest2056 | the 0.4 branch | 17:53 |
| wolever | Blast... | 17:53 |
| wolever | Which rev? | 17:53 |
| wolever | It's possible that something is broken with my build of SVN... So I can look at that too | 17:55 |
| Guest2056 | wolever, 0.4 revision 1708 | 17:55 |
| wolever | Darn, ok -- then something is wrong with my svn. When I run `bzr co file://...`, it says "bzr: ERROR: a is already versioned" | 17:56 |
| hsn_ | !help | 18:06 |
| ubottu | Hi! I'm #bzr's favorite infobot, you can search my brain yourself at http://tinyurl.com/5zfb6t - Usage info: http://wiki.ubuntu.com/UbuntuBots | 18:08 |
| hsn_ | wow 2 minute botlag | 18:09 |
| Guest2056 | wolever, still there? | 18:46 |
| wolever | Yup | 18:46 |
| Guest2056 | wolever, have you tried refetching the branch after removing the svn cache? | 18:46 |
| wolever | Yup | 18:46 |
| wolever | Same deal | 18:46 |
| Guest2056 | and the branch you're checking out is just created with those commands you pasted earlier? | 18:47 |
| wolever | Yup | 18:49 |
| Frenzel | hi all | 18:51 |
| Frenzel | I have a quick question with hopefully a simple answer. In our project there are lots of people commiting but not all enter a good descriptive commit description. Can I edit commit descriptions? | 18:53 |
| Guest2056 | hi Frenzel | 18:55 |
| Frenzel | Hi | 18:56 |
| Guest2056 | Frenzel, not at the moment, there is an open bug report that discusses the implications of supporting this. | 18:56 |
| Frenzel | I would say, make it possible because now it is a mess | 18:56 |
| Guest2056 | Frenzel, it's not trivial to support | 18:57 |
| Frenzel | That I understand :) | 18:57 |
| Guest2056 | I certainly see the use case for it, though | 18:57 |
| Frenzel | but eventhough I would like to have this feature | 18:57 |
| Frenzel | Where can I find this open bug report? | 18:58 |
| Frenzel | you have a URL/bugid? | 18:59 |
| Guest2056 | Frenzel, it should be in launchpad, not sure what the bug id is | 19:00 |
| Guest2056 | Frenzel, there has been some discussion about changing commit messages on the bazaar mailing list earlier, it mayve been mentioned there | 19:01 |
| Guest2056 | Search for the subject "Changing a commit message" | 19:01 |
| Frenzel | ok | 19:01 |
| Frenzel | thanks a lot | 19:01 |
| * Peng_ has been pulling from lp:bzr-svn for 7 minutes . . . . . | 20:40 | |
| Peng_ | Oh, it's done. | 20:44 |
| Peng_ | Oh, lp:bzr-svn points to a different branch now. That'd explain it. Never mind. :) | 20:48 |
| LarstiQ | oh, which one? | 20:50 |
| Peng_ | LarstiQ: It changed from 0.4 to the trunk. | 20:52 |
| LarstiQ | what, that thing lives again? :) | 20:52 |
| Peng_ | I think I can pull from http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ without a traceback now too. Yay. | 20:53 |
| === abentley changed the topic of #bzr to: current topic is: Bazaar version control system | http://bazaar-vcs.org | Bundle Buggy under maintenance | bzr-1.6.1 now available ! | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| Stellaris | Good evening, does anybody know of a (free) bzr hosting like launchpad, but with private repos/accounts? I looked at the tour on their site, but didn't see anything about private branches/hosting | 21:28 |
| Stellaris | Did I miss it? | 21:28 |
| Guest2056 | Stellaris, Afaik launchpad doesn't have that, at least not for free | 21:32 |
| Guest2056 | Stellaris, (the folks in #launchpad know more about this, probably) | 21:33 |
| Guest2056 | Stellaris, you should be able to use any sftp/ssh shell server for private hosting though | 21:33 |
| Stellaris | Guest2056, okay, will look into that, thanks | 21:36 |
| bud3030 | Hi, I have be looking for some time to delete bzrlib to upgrade but can't find enough to make this change | 21:39 |
| LarstiQ | bud3030: you probably shouldn't do that. | 21:41 |
| bud3030_ | hi lost the window | 21:42 |
| LarstiQ | 22:41:31 < LarstiQ> bud3030: you probably shouldn't do that. | 21:42 |
| LarstiQ | bud3030: do you want to use a newer version of bzr? | 21:42 |
| bud3030_ | yes | 21:42 |
| LarstiQ | bud3030: where does your current one come from, package manager, run it from source? | 21:42 |
| bud3030_ | just leave the dir and run source | 21:43 |
| bud3030_ | thank I guest my ID should be ID iot | 21:44 |
| bud3030_ | login out thanks | 21:45 |
| * LarstiQ blinks | 21:46 | |
| Guest2056 | rockstar, fwiw, branching KDE branches with bzr-svn now works | 22:52 |
| === Guest2056 is now known as jelmer | ||
| Peng_ | abentley: I guess you can take the Bundle Buggy thing out of the topic now. | 23:41 |
| Peng_ | abentley: What was the old server it was on? What's the new one? | 23:41 |
| abentley | Peng_: Yes. | 23:42 |
| === abentley changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.6.1 now available ! | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| Peng_ | I don't use BB much, but it definitely feels fast. Nice. :) | 23:43 |
| Peng_ | Yay Linode? | 23:43 |
| abentley | Peng_: The old server was a Feisty Xen virtual machine hosted by unixshell. The new one is a Hardy Xen virtual machine hosted by linode.com | 23:43 |
| Peng_ | How large is the Linode? | 23:45 |
| abentley | Peng_: a Linode 360 | 23:46 |
| Peng_ | ok :) | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!