=== me_too is now known as too_short === too_short is now known as me_too [08:41] New bug: #178695 in bzr-cvsps-import "Problem when trying to import CVS module" [Undecided,New] https://launchpad.net/bugs/178695 [08:48] * ddaa starts looking at bzr-git [08:48] > stgit is used to provide python parsing of the output of git commands. [08:48] gack! pyarch flashback! [08:49] <``Cube> has anyone received my mail? [08:49] <``Cube> ddaa: ? [08:49] Is that the quick hack it looks like, or is this the officially blessed way to bind to git? [08:50] ``Cube: using CLI spawning/parsing as a library binding is evil. [08:50] <``Cube> huh? [08:50] <``Cube> just asked about the icon mail [08:50] <``Cube> I didn't get any feedback yet [08:51] dunno what you asked about, I just got in. This was an unrelated comment. [08:51] <``Cube> ah ok :D [08:51] <``Cube> well, so I'll ask again: I sent a mail with icons [08:52] <``Cube> did you get it? [08:52] <``Cube> some days ago [08:52] I have 4764 unread mails in my bzr folder. [08:52] <``Cube> WOO [08:52] <``Cube> lol nice [08:53] <``Cube> could you search for mine? [08:53] subject? [08:53] <``Cube> one second, oki? [08:53] <``Cube> Introduction + Bazaar Icon Tango Remake [08:54] There's such an email [08:54] with one giant png that collates a bunch of icon [08:54] <``Cube> heh ;) [08:54] <``Cube> yea [08:54] <``Cube> thanks it [08:54] <``Cube> *that's it [08:54] not really usable as is [08:55] <``Cube> hmm :S [08:55] <``Cube> it was just a propose [08:55] <``Cube> hmm, you don't like it, ok [08:55] <``Cube> looks like its not gonna pass [08:56] I am in no position to make a judgement about it. [08:56] It just looks kind of weird to me that you submit tango icons to upstream. Shouldn't this be packaging in the tango theme package, instead of bzr? [08:56] <``Cube> well, I wanted to replace the current icons with tango icons [08:57] <``Cube> on launchpad, the webpage and so on [08:57] ``Cube: Also, all the Canonical folks are on holiday ATM, so you should wait until January for an authoritative reply. [08:57] <``Cube> oh, ok [08:58] <``Cube> but you don't think they'll pass it? [08:58] <``Cube> by the way, the 16x16 isn't ready yet [08:59] They sure look nice. My private opinion is that they are too low-contrast for use as the main icons. But they are a great fit to tango-like themes. [09:00] But it's only my private opinion, the people in charge may very well think differently. [09:00] <``Cube> oh ok [09:00] <``Cube> I mean, I can change them completely [09:00] couple of things I do like [09:00] <``Cube> I just tried to make them look close to the original ones [09:01] is the lack of drop-shadow under the arrow, and the square incoming road. [09:01] Please do not change them because of my feedback. Wait for authoritative feedback. [09:02] <``Cube> heh ;) ok sure [09:02] <``Cube> well, are the canonical very... [09:02] <``Cube> lets say [09:02] <``Cube> professional? [09:02] <``Cube> or do they accept lil mistakes at the beginning [09:02] <``Cube> and similar stuff? [09:03] Being professional and being welcoming to new community contributors do not have to be mutually exclusive. [09:03] <``Cube> hmm, you're right... [09:03] <``Cube> well ok, thanks a lot, ill wait until they come back [09:03] <``Cube> in JAN [09:04] <``Cube> ehm, do you have someones IM? [09:04] <``Cube> I'd like to contact them personally [09:04] <``Cube> because, if there are so many mails coming in [09:04] <``Cube> mine will probably go under [09:04] That's okay. They know how to do deal with large amount of email. I'm sure you'll receive some attention. [09:05] Nagging is not a good idea at first. You did the right thing by posting to the mailing list and by asking here. [09:06] BTW, this crowd tend to prefer pure-text email rather than HTML. [09:06] Just for the future. [09:06] <``Cube> hmm ok [09:06] <``Cube> thanks [09:07] <``Cube> but someone with pure-text, can he receive my mails at all? [09:07] sure [09:07] they include a text/plain mime part. [09:08] <``Cube> ah, ok [09:08] they do not look optimal (too many blank lines) but they are perfectly readable. [09:08] <``Cube> oh yes, heard about that blank line issue somewhere [09:49] beuno: there are plugins for eclispe and visual studio for bzr :)) [09:50] hey lifeless [09:54] hey ddaa, happy xmas stuff [09:54] thank, happy yours [09:54] * ddaa had enough christmas for one year [10:01] lifeless: :) [10:02] merry xmas and all that crap :) [10:02] i386: :) [10:03] * ddaa went out to ask about binding in #git [10:03] this really gives me very strong flashbacks of GNU Arch. [10:04] I hope it's just my personal prejudice. [10:04] git is the new arch [10:04] I'm fearing that much. [10:04] This notion scares the hell outta me. [10:05] libgit is internal only [10:05] I investigated this when starting bzr-git [10:05] anyhow, I'm not here ;), Just checking mail after 5 das without :) [10:10] Git is the new Arch? [10:16] Apparently they seem to have this notion that "writing a library interface" is something you can slap over an existing codebase designed to be CLI-driven. [10:16] Although my experience in this respect is limited to tla, I believe it's usually nowhere near that simple. [10:17] Small things like error reporting and resources handling you need not worry much about in small one-off processes are critical to making a good library API. And a huge pain in the ass to retrofit. [10:18] Then "since nobody has bothered to do it, it's probably not all that useful"... [10:19] GNU Arch had a way to twist people perceptions. I'm scared that similar things might be at work in the git community. [10:20] Not, all of what I just said is my just my personal opinion. [10:20] And not all that informed at that. [10:47] It seems that git failure modes are indeed consistent with my expectations... [10:47] "Fails in mysteriously arcane way for trivial mistakes." [10:48] Hmm. Bzr and hg are written as libraries. That's kind of an advantage, huh? [10:48] Trying to clone from something that's is not a git repo yields "fatal: Not a valid object name HEAD". That's git-speak for "Not a branch." [10:49] So they write error messages in code. What does that have to do with librarification? :) [10:49] tla tended to have the same error reporting issues [10:50] things written to be a bunch a scripts seem to tend to suck at propagating error conditions and displaying meaningful context-sensitive messages. [10:51] So, then tend to resort to displaying low level errors to the user. [10:51] Is doing it well in C harder than in Python? [10:51] It's not really a matter of language. [10:52] Ok. [10:52] Rather a matter of how people think about their software. [10:55] Though, good error reporting is much harder in C than in Python. Exception was one of the great advances in programming languages that occured after C. [10:56] But it seems good C programmers are kind of used to setting up whole frameworks to give C things like exceptions, managed memory and run-time polymorphism. And I assume that git programmers are good C programmers. [11:19] All that stuff isn't important, though. Fast is all that matters. [11:20] fullermd: always the troll, aren't you? :) [11:21] I'm trying to reach my quota so I can leave my bridge for a few hours today. [11:21] * ddaa gives fullermd a red herring [11:21] * fullermd chops down a tree with it. [11:21] in monkey island, that used to make the bridge troll happy [11:58] ddaa: oh man, tla was horrible [11:58] "ERROR: botched assertion (125)" [11:59] though it made me learn the word "botched", so it was useful in a way === GaryvdM_ is now known as GaryvdM [12:03] that one usually meant some form of data corruption :) [12:04] in bzr you'd get a traceback in similar cases, which is only marginally better [12:17] Hey all, with bzr-svn what's the difference between an initial 'bzr branch' and a 'bzr co'? [12:27] acuster: branch can create a branch without a working tree. checkout w [12:28] checkout allways creates a branch with a working tree [12:28] * fullermd blinks. [12:28] okay, that makes sense [12:28] checkout is also used to create a working tree for a branch that does not have a working tree [12:28] Not to me it doesn't... is bzr-svn really so different from bzr? [12:28] no [12:28] do you know what format I should init-repo with for bzr-svn? [12:29] Then the difference is that branch creates a branch, and co creates a checkout. [12:29] Am I wrong fullermd? [12:29] fullermd, that may be entirely true but pedagogically, it's useless [12:29] Ahem [12:29] Okay, so a checkout (heavy checkout) is just a branch. [12:30] Grr. No it's not, it's a checkout. [12:30] * fullermd stabbies the branch. [12:30] Except it's "bound" to a master, and when committing to a checkout, changes are automatically pushed to the master, atomically. [12:30] Checkout = branch + working tree? [12:30] A branch gives you an independent branch to work on. [12:30] GaryvdM, nope [12:30] A checkout lets you work on the branch you point it at. [12:30] acuster: something with rich-root support (--rich-root or --rich-root-pack) [12:30] GaryvdM: I am afraid you are confused. [12:30] bob2, thanks [12:31] oh [12:31] GaryvdM: what you call a checkout here is a lightweight checkout. [12:31] hello bob2 [12:31] long time no see [12:31] he ddaa [12:31] er, hey. [12:32] acuster: so, with bzr-svn, you only really want to use "bzr checkout" to create a branch that you will use only to merge your bzr work into the svn repository. [12:33] note, that you can turn a "checkout" into a "branch" using "bzr unbind", and conversely using "bzr bind". [12:34] (those are fairly obscure commands, but they are useful to illustrate that a heavyweight checkout is just a branch with some special behaviour) [12:36] I still say that definition should die a quick and painful death. [12:37] It just makes everything more painful. It's not a branch with special behavior, it's a checkout with special behavior. [12:38] and what's a checkout without special behavior? :) [12:38] Nothing, any more than an internal-combusion motor without special behavior is anything. Everything has attributes. [12:38] Heavy and light are just two different kinds of checkouts with varying attributes and behaviors in edge cases. === me_too is now known as too_short === too_short is now known as me_too [13:00] New bug: #178722 in bzr "Wrong argument for "bzr log --timezone" triggers internal error" [Undecided,New] https://launchpad.net/bugs/178722 === me_too is now known as too_short === too_short is now known as me_too [14:13] what's the trick to make "bzr selftest" and pdb go along? [14:14] I stuck a "import pdb; pdb.set_trace()" in some method called from a test, but it seems pdb is confused by the test runner. === me_too is now known as too_short === too_short is now known as me_too [14:22] nevermind [14:22] it was my evil psyco plugin === me_too is now known as too_short === too_short is now known as me_too === me_too is now known as too_short === too_short is now known as me_too === me_too is now known as too_short === too_short is now known as me_too === me_too is now known as too_short === too_short is now known as me_too [14:38] hi, is there a way to change a commit message? [14:39] Poromenos: nope [14:39] Poromenos: well [14:39] Poromenos: if it's the latest entry, and you haven't pushed to a remote place, you could uncommit, and commit again with a fixed message [14:39] but other than that... [14:39] it's not :/ [14:40] ah well, thanks anyway [14:41] is there a way/need to specify dependencies on a project on launchpad? [14:48] ah, I found how to fix the test suite on jam's branch. [14:49] It seems that git-fast-import --export-marks=foo now actually changes the foo file instead of just writing to it (hardlink breaking), so it defeats the use of NamedTemporaryFile in the GitBranchBuilder. [14:49] * ddaa grumbles [14:50] that's the kind of stupid shit you get when trying to bind to a CLI [14:51] grrr 1000 of 7300 and already at 61% cpu, [14:51] <``Cube> oh no [14:51] no way to branch that svn repo [14:52] <``Cube> incredible [14:52] well, let's run until we crash. [14:52] Does bzr still have know memory leaks? === me_too is now known as too_short === too_short is now known as me_too === me_too is now known as too_short === too_short is now known as me_too [15:02] acuster: It's subversion [15:02] There was a huge memory leak in the subversion python bindings [15:02] hey jelmer [15:03] http://subversion.tigris.org/issues/show_bug.cgi?id=3052 [15:04] thanks [15:13] hi ``Cube [15:13] <``Cube> hi === me_too is now known as too_short === too_short is now known as me_too [15:44] jelmer: I think the SvnRaTransport docstring "This implements just as much of Transport as is necessary to fool Bazaar." is a tad bit outdated now :) [15:44] heh, good point :-) [15:45] was looking for a template transport to define a git:// transport [15:48] ah, working on bzr-git ? [15:50] just some holiday hacking [15:52] best way to benchmark against git would be having a working bzr-git in the first place [15:53] also, git is not going to away anytime soon, so it will be useful, and help some ubuntu folks that need to deal with git upstreams. [16:02] same here [16:02] now that Samba has switched to git, it would be very nice to see a working bzr-git [16:04] Think it'll be good and usable in 6 months, say? [16:04] there are some unique challenges [16:05] such as dealing with git's approach of guessing renames instead of recording them [16:05] that assumes the intelligence is in the commands, not in the data. [16:05] That clashes quite badly with the bzrlib design. [16:05] I just need a planning number, so I can figure out when it'll be time to get samba to switch to the next VCS I want foreign branch support for ;) === me_too is now known as too_short === too_short is now known as me_too [16:06] It seems quite unlikely to me that anybody would switch away from git to anything but svn or bzr. [16:07] depending on where they put the blame for the pain they endured. === me_too is now known as too_short === too_short is now known as me_too [16:08] what's this me_too thing? === me_too is now known as too_short === too_short is now known as me_too [16:10] Can't see. too_short. === me_too is now known as too_short === too_short is now known as me_too === me_too is now known as too_short === too_short is now known as me_too === me_too is now known as too_short === too_short is now known as me_too [16:18] ddaa: As long as the plugin always detects renames at the same places, there's no problem :-) [16:19] I mean that git has a lot of freedom to evolve their rename-guessing logic [16:20] but a bzr-git plugin would be much more constrainted [16:21] Yeah. They've got all the time in the world to try and come up with a herustic to figure out the information that the user could just provide at the time :p [16:30] ddaa: yup [16:30] path tokens ftw! [16:30] what's that? [16:30] * ddaa is hopelessly out of touch [16:30] replacement for fileids proposed by robert [16:30] gotta be interesting [16:30] meant to solve parallel imports and copy tracking [16:31] yeah, the idea is very interesting [16:31] but it's also quite abstract at this point [16:31] http://bazaar-vcs.org/DraftSpecs/PathTokens [16:33] I regard git's support for parallel imports a very strong point for them. [16:33] * ddaa reads the spec [16:34] git doesn't lack in strong points. Now, if it lacked a bit more in nuttiness... [16:35] The content-addressed storage is certainly a strong point. [16:35] I've always felt utterly nonplussed by this. [16:35] And I get to like the crypto-hash-as-revid concept better the longer I think of it. [16:36] really, we only have identity problems in bzr because of limitations in how we deal with parallel imports. [16:36] and content-addressing has some major drawbacks [16:37] It's got major advantages too. [16:37] as in making it pretty much impossible to have native checkout for foreign repository formats. [16:37] Though I see it as fairly orthogonal to the identity issue (at least, insofar as I'd mentally want to take it; file texts) [16:39] mh... this spec is pretty light on actual ideas [16:39] it's just a problem statement [16:42] jelmer: why does bzr-svn uses BOTH BzrDirFormat.register_control_format AND format_registry.register to register SvnRemoteFormat? [16:44] Hmm, you're right, that's confusing.. [16:44] I guess that means only format_registry is needed, right? [16:45] No, I think the first one is for the handling of ".bzr" [16:45] s/.bzr/.svn [16:45] while the latter is usually a combination of a branch, repository and working tree format [16:45] BzrDirFormat.register_control_format(format.SvnRemoteFormat) [16:45] "dirstate-with-subtree" [16:45] that is not .svn stuff [16:45] that's the remote stuff [16:45] detecting the control dir happens by checking whether the transport is a SvnRaTransport [16:46] right [16:46] rather than checking for a .svn directory [16:46] but then [16:46] format_registry.register("subversion", format.SvnRemoteFormat, [16:46] "Subversion repository. ", [16:46] native=False) [16:46] the format registry bit is just so it appears in the output of "bzr init --help" [16:47] ok [16:47] and so info knows how to call it [16:50] for some reason i can't branch from https, (launchpad), curl is giving me an error. any ideas? [16:51] couple of them [16:51] either use the actual http or bzr+http address of the branch [16:52] https://code.launchpad.net is just a redirection to http://bazaar.launcphad.net [16:52] it redirects [16:52] hmm [16:52] or do not use curl [16:52] i'm not doing it intentionally, bazaar is [16:54] http://bazaar.launchpad.net/gnuhello isn't working [16:54] you can use https+urllib:// urls to stop it from using pycurl [16:54] not a branch, actually [16:54] ah [16:54] or you can uninstall pycurl if nothing else is using it on your system [16:54] i don't think anything is, i'll try that, thanks [16:55] btw, this url is indeed not a branch [16:55] as an aside, do you know how i can generate ssl keys? [16:55] yes, but launchpad.net/gnuhello is [16:55] check https://code.edge.launchpad.net/~vcs-imports/gnuhello/trunk [16:55] you'll see the download URL there [16:55] ah, urllib worked, thanks though [16:55] the redirection magic only happens on code.launchpad.net, not on bazaar.launchpad.net [16:56] ah [16:56] Poromenos: the command is ssh-keygen, if you are on linux [16:56] if you are on Windows, I have no clue. [16:57] i'm on ubuntu, thanks [16:57] Poromenos: I'm pretty sure there is extensive documentation about this stuff on help.launchpad.net [16:57] i can't find it, i'm following the tutorial but i couldn't find help on either the tutorial or the ssl keys page [16:58] ssh, i mean [16:58] ok [16:58] maybe file a bug on launchpad-bazaar then [16:58] this sort of thing should be crystal clear. [16:58] i will, thanks [17:09] can i delete a branch after i publish it? [17:09] (on launchpad) [17:29] jelmer: did you see my mail about bzr-plugins? [17:29] dato: no that I remember - where did you send it? [17:30] bazaar@ and -maint [17:30] * jelmer has a look [17:31] If I ran bzr-gtk's ./setup.py install - is there a way to uninstall? [17:52] can anyone ssh to bazaar.launchpad.net? [17:52] it's not working for me [17:52] the shell is disabled [17:52] oh [17:52] temporarily? [17:52] permanently [17:53] how do people upload code then? [17:53] bzr push [17:53] push where... [17:53] to the bzr+ssh url displayed on the branch page of a hosted branch [17:54] that's what's not working [17:54] https://code.launchpad.net/~stavrosk/gmailchecker/main [17:54] please paste the bzr command you typed and the output it produced [17:54] bzr push bzr+ssh://stavrosk@bazaar.launchpad.net/~stavrosk/gmailchecker/main [17:55] ssh: connect to host bazaar.launchpad.net port 22: Connection refused [17:55] that's it [17:55] meh [17:55] indeed, it's down [17:56] Next mirror: [17:56] ah [17:56] As soon as possible [17:56] heh [17:56] i'll wait then, thanks [17:56] can i name a branch? [17:56] i mean in bzr [17:56] probably not, nm [17:56] not sure what you mean [17:56] you can specify a branch nick that will be recorded in commits [17:57] otherwise, the name of a branch is its url [17:57] you can change the last past of a branch url on launchpad [17:57] "Edit branch details", it's the branch name field. [17:57] i just saw "branch name" on the web interface, but i realized it's what you enter [17:57] yes, thanks [18:13] Since an hour ago I get an error when I try to use bazaar to update my branches on launchpad, "connection refused: please check connectivity and permissions". Any idea how to do that? (it says "try -Dhpss", but that doesn't help) [18:29] apparently the ssh server is down [18:29] there should be a nagios alarm ringing right now [18:31] are there any speed improvements on the horizon? bzr still (1.0; rich-root-pack source format) seems to be unusably slow (20 minutes, local disk) at making a branch of a 40krev repository. [18:32] the trick is to use shared repositories [18:33] right, you don't want to duplicate 40krevs of data anyway [18:33] aside from the fs bloat, it does not allow efficient use of the disk caches. [18:34] sure, that's a nice trick when it works. but it doesn't work in all situations, and 20 minutes is *reaaaallly* long. [18:34] hi foom [18:34] hm, what are the situations when it doesn't work? [18:35] jelmer: hey there [18:35] luks: branching a remote repository, for example. [18:35] ddaa: thanks for the info [18:36] foom: but you do that only once, and never again [18:36] not such a big problem, IMO [18:36] next time you branch you have most of the data locally [18:37] luks: normally, remote branch should be essentially limited by how fast you can pump data off the server. Anything else is a bug. [18:37] although it is planned to have shallow branches in the future [18:37] ddaa: yes, but without a shared repository you download it over and over again [18:38] so you won't HAVE to pump all the history of the server to make a local branch. [18:38] which is that I guess foom is doing [18:38] er, s/that/what/ [18:38] luks: well, okay, you've got me, if this was the only slow thing in bzr, I guess that might be okay. I dunno if it is or not, it's just the first thing I've tested this go-around. [18:38] and it seems quite unlikely that this would be the only too-slow operation [18:39] bzr is certainly not as fast as some of the competition, but using the most recent formats, it should be fast enough. [18:40] i.e. the time should be a small multiple of the time of other tools, not orders of magnitudes slower as it used to be. [18:41] We think it's more important to have "merge" and "commit" be reliable and easy to use, than to have them run in 0.5 second instead of 2 seconds. [18:41] the most annoying thing to me is not the actual performance, but the startup time [18:41] jelmer: i saw you found the (a?) memory leak in svn python bindings and said you worked around it in bzr-svn; is that workaround expected to not be a full fix? [18:41] foom: Yes, it isn't a full fix [18:42] jelmer: okay, cause bzr crashed my machine converting a svn repository by running it out of memory and invoking the OOM killer which killed half the important processes. :( [18:42] foom: You need an updated version of the python-subversion bindings for all of the memory leaks to go away [18:42] "hey look, X is taking some memory, let's kill it!". thanks linux...heh [18:42] http://subversion.tigris.org/issues/show_bug.cgi?id=3052 [18:43] that's not patched in ubuntu yet is it? [18:47] luks: startup time? [18:54] and...'bzr log -r20000' takes 23s. [18:57] jelmer: it seems pretty much impossible to implement a transparent git:// transport [18:57] short of reimplementing the client code [18:57] common git servers only expose git-fetch-pack and git-peek-remote services [18:58] and the former requires a local git dir [18:59] * ddaa finds this frustratingly limited [19:21] yay! git_connect dies on error :( [19:24] ddaa: Are you working based on stgit? [19:24] jelmer: I'm based on jam's branch [19:24] it has no stgit dependency [19:24] and right now, I'm staring at the git source itself [19:24] and all my fears are confirmed [19:27] :-/ [19:27] if (protocol == PROTO_GIT) { [19:27] /* These underlying connection commands die() if they [19:27] * cannot connect. [19:27] */ [19:28] Also, all the network code seems to assume that sockets and pipe and interchangeable [19:28] i.e. forget about windows [19:29] At least some of the client code will have to be written from scratch. [19:29] or heavily patched. [19:36] ddaa: You're writing this in C or Python? [19:36] just explorating [19:36] Actually, I think I'm going to give up on the transparent transport. [19:40] I thought Robert already had a lot of this done [19:40] the bzr-git code I see is quite proof-of-concept [19:40] and it only works locally [19:40] i.e. it does not try to do more than git [19:41] which pretty much only knows how to fetch packs over the network, then does everything locally. [19:45] ah, ok [19:45] unfortunately, I do not think that's an acceptable level of functionality for bzr :( [20:07] Hey, bazaar.launchpad.net SFTP server is up again [21:02] I just started reading the user documentation and I am damned impressed. [21:02] it is the clearest description I have ever seen up any revision control system. [21:03] * piedoggie thinks everybody is out at Boxing Day parties [23:39] hi. I have a bzr branch in my ${HOMEDIR}. I also have another bzr branch in my ${HOMEDIR}/Desktop/vision/proj2/. If I want to graft/merge proj2 to ${HOMEDIR}, should I use `bzr merge`? === Verterok_ is now known as Verterok [23:50] eddyMul: take a look to the merge-into plugin , might be helpful. [23:50] Thanx, Verterok. Will look at it [23:52] Verterok: looks like this is what I'm looking for. There's a bug againts bzr-0.90. Do I need bzr-1.0? [23:53] eddyMul: it's seems is broken :( [23:54] it's broken against bzr.dev, probably it won't work with 1.0 [23:55] Verterok: when I try merging, it kept complaining "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified." [23:55] which sounds about right [23:56] when I specify the revisions (there are 5 revs) -r1..5, bzr bombs w/ AssertionErrors [23:56] :( [23:57] eddyMul: I just found find-merge-base command, it's part of the hidden commands, take a look to that maybe it can help you to find a base revision to merge [23:58] eddyMul: you can try "-r0..5" [23:59] eddyMul: also, there's a "bzr join" command, but it's still experimental. [23:59] spiv: thx for the r0..x tip :-)