[08:41] <ubotu> 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] <ddaa> > stgit is used to provide python parsing of the output of git commands.
[08:48] <ddaa> gack! pyarch flashback!
[08:49] <``Cube> has anyone received my mail?
[08:49] <``Cube> ddaa: ?
[08:49] <ddaa> Is that the quick hack it looks like, or is this the officially blessed way to bind to git?
[08:50] <ddaa> ``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] <ddaa> 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] <ddaa> 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] <ddaa> subject?
[08:53] <``Cube> one second, oki?
[08:53] <``Cube> Introduction + Bazaar Icon Tango Remake
[08:54] <ddaa> There's such an email
[08:54] <ddaa> 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] <ddaa> 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] <ddaa> I am in no position to make a judgement about it.
[08:56] <ddaa> 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] <ddaa> ``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] <ddaa> 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] <ddaa> 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] <ddaa> couple of things I do like
[09:00] <``Cube> I just tried to make them look close to the original ones
[09:01] <ddaa> is the lack of drop-shadow under the arrow, and the square incoming road.
[09:01] <ddaa> 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] <ddaa> 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] <ddaa> That's okay. They know how to do deal with large amount of email. I'm sure you'll receive some attention.
[09:05] <ddaa> 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] <ddaa> BTW, this crowd tend to prefer pure-text email rather than HTML.
[09:06] <ddaa> 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] <ddaa> sure
[09:07] <ddaa> they include a text/plain mime part.
[09:08] <``Cube> ah, ok
[09:08] <ddaa> 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] <lifeless> beuno: there are plugins for eclispe and visual studio for bzr :))
[09:50] <ddaa> hey lifeless
[09:54] <lifeless> hey ddaa, happy xmas stuff
[09:54] <ddaa> thank, happy yours
[09:54]  * ddaa had enough christmas for one year
[10:01] <i386> lifeless: :)
[10:02] <i386> merry xmas and all that crap :)
[10:02] <lifeless> i386: :)
[10:03]  * ddaa went out to ask about binding in #git
[10:03] <ddaa> this really gives me very strong flashbacks of GNU Arch.
[10:04] <ddaa> I hope it's just my personal prejudice.
[10:04] <lifeless> git is the new arch
[10:04] <ddaa> I'm fearing that much.
[10:04] <ddaa> This notion scares the hell outta me.
[10:05] <lifeless> libgit is internal only
[10:05] <lifeless> I investigated this when starting bzr-git
[10:05] <lifeless> anyhow, I'm not here ;), Just checking mail after 5 das without :)
[10:10] <Peng> Git is the new Arch?
[10:16] <ddaa> 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] <ddaa> Although my experience in this respect is limited to tla, I believe it's usually nowhere near that simple.
[10:17] <ddaa> 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] <ddaa> Then "since nobody has bothered to do it, it's probably not all that useful"...
[10:19] <ddaa> 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] <ddaa> Not, all of what I just said is my just my personal opinion.
[10:20] <ddaa> And not all that informed at that.
[10:47] <ddaa> It seems that git failure modes are indeed consistent with my expectations...
[10:47] <ddaa> "Fails in mysteriously arcane way for trivial mistakes."
[10:48] <Peng> Hmm. Bzr and hg are written as libraries. That's kind of an advantage, huh?
[10:48] <ddaa> 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] <Peng> So they write error messages in code. What does that have to do with librarification? :)
[10:49] <ddaa> tla tended to have the same error reporting issues
[10:50] <ddaa> 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] <ddaa> So, then tend to resort to displaying low level errors to the user.
[10:51] <Peng> Is doing it well in C harder than in Python?
[10:51] <ddaa> It's not really a matter of language.
[10:52] <Peng> Ok.
[10:52] <ddaa> Rather a matter of how people think about their software.
[10:55] <ddaa> 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] <ddaa> 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] <fullermd> All that stuff isn't important, though.  Fast is all that matters.
[11:20] <ddaa> fullermd: always the troll, aren't you? :)
[11:21] <fullermd> 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] <ddaa> in monkey island, that used to make the bridge troll happy
[11:58] <mathrick> ddaa: oh man, tla was horrible
[11:58] <mathrick> "ERROR: botched assertion (125)"
[11:59] <mathrick> though it made me learn the word "botched", so it was useful in a way
[12:03] <ddaa> that one usually meant some form of data corruption :)
[12:04] <ddaa> in bzr you'd get a traceback in similar cases, which is only marginally better
[12:17] <acuster> Hey all, with bzr-svn what's the difference between an initial 'bzr branch' and a 'bzr co'?
[12:27] <GaryvdM> acuster: branch can create a branch without a working tree.  checkout w
[12:28] <GaryvdM> checkout allways creates a branch with a working tree
[12:28]  * fullermd blinks.
[12:28] <acuster> okay, that makes sense
[12:28] <GaryvdM> checkout is also used to create a working tree for a branch that does not have a working tree
[12:28] <fullermd> Not to me it doesn't...  is bzr-svn really so different from bzr?
[12:28] <GaryvdM> no
[12:28] <acuster> do you know what format I should init-repo with for bzr-svn?
[12:29] <fullermd> Then the difference is that branch creates a branch, and co creates a checkout.
[12:29] <GaryvdM> Am I wrong fullermd?
[12:29] <acuster> fullermd, that may be entirely true but pedagogically, it's useless
[12:29] <ddaa> Ahem
[12:29] <ddaa> Okay, so a checkout (heavy checkout) is just a branch.
[12:30] <fullermd> Grr.  No it's not, it's a checkout.
[12:30]  * fullermd stabbies the branch.
[12:30] <ddaa> Except it's "bound" to a master, and when committing to a checkout, changes are automatically pushed to the master, atomically.
[12:30] <GaryvdM> Checkout = branch + working tree?
[12:30] <fullermd> A branch gives you an independent branch to work on.
[12:30] <dato> GaryvdM, nope
[12:30] <fullermd> A checkout lets you work on the branch you point it at.
[12:30] <bob2> acuster: something with rich-root support (--rich-root or --rich-root-pack)
[12:30] <ddaa> GaryvdM: I am afraid you are confused.
[12:30] <acuster> bob2, thanks
[12:31] <GaryvdM> oh
[12:31] <ddaa> GaryvdM: what you call a checkout here is a lightweight checkout.
[12:31] <ddaa> hello bob2
[12:31] <ddaa> long time no see
[12:31] <bob2> he ddaa
[12:31] <bob2> er, hey.
[12:32] <ddaa> 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] <ddaa> note, that you can turn a "checkout" into a "branch" using "bzr unbind", and conversely using "bzr bind".
[12:34] <ddaa> (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] <fullermd> I still say that definition should die a quick and painful death.
[12:37] <fullermd> It just makes everything more painful.  It's not a branch with special behavior, it's a checkout with special behavior.
[12:38] <dato> and what's a checkout without special behavior? :)
[12:38] <fullermd> Nothing, any more than an internal-combusion motor without special behavior is anything.  Everything has attributes.
[12:38] <fullermd> Heavy and light are just two different kinds of checkouts with varying attributes and behaviors in edge cases.
[13:00] <ubotu> New bug: #178722 in bzr "Wrong argument for "bzr log --timezone" triggers internal error" [Undecided,New] https://launchpad.net/bugs/178722
[14:13] <ddaa> what's the trick to make "bzr selftest" and pdb go along?
[14:14] <ddaa> 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.
[14:22] <ddaa> nevermind
[14:22] <ddaa> it was my evil psyco plugin
[14:38] <Poromenos> hi, is there a way to change a commit message?
[14:39] <dato> Poromenos: nope
[14:39] <dato> Poromenos: well
[14:39] <dato> 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] <dato> but other than that...
[14:39] <Poromenos> it's  not :/
[14:40] <Poromenos> ah well, thanks anyway
[14:41] <Poromenos> is there a way/need to specify dependencies on a project on launchpad?
[14:48] <ddaa> ah, I found how to fix the test suite on jam's branch.
[14:49] <ddaa> 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] <ddaa> that's the kind of stupid shit you get when trying to bind to a CLI
[14:51] <acuster> grrr 1000 of 7300 and already at 61% cpu,
[14:51] <``Cube> oh no
[14:51] <acuster> no way to branch that svn repo
[14:52] <``Cube> incredible
[14:52] <acuster> well, let's run until we crash.
[14:52] <acuster> Does bzr still have know memory leaks?
[15:02] <jelmer> acuster: It's subversion
[15:02] <jelmer> There was a huge memory leak in the subversion python bindings
[15:02] <acuster> hey jelmer
[15:03] <jelmer> http://subversion.tigris.org/issues/show_bug.cgi?id=3052
[15:04] <acuster> thanks
[15:13] <jelmer> hi ``Cube
[15:13] <``Cube> hi
[15:44] <ddaa> 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] <jelmer> heh, good point :-)
[15:45] <ddaa> was looking for a template transport to define a git:// transport
[15:48] <jelmer> ah, working on bzr-git ?
[15:50] <ddaa> just some holiday hacking
[15:52] <ddaa> best way to benchmark against git would be having a working bzr-git in the first place
[15:53] <ddaa> 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] <jelmer> same here
[16:02] <jelmer> now that Samba has switched to git, it would be very nice to see a working bzr-git
[16:04] <fullermd> Think it'll be good and usable in 6 months, say?
[16:04] <ddaa> there are some unique challenges
[16:05] <ddaa> such as dealing with git's approach of guessing renames instead of recording them
[16:05] <ddaa> that assumes the intelligence is in the commands, not in the data.
[16:05] <ddaa> That clashes quite badly with the bzrlib design.
[16:05] <fullermd> 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   ;)
[16:06] <ddaa> It seems quite unlikely to me that anybody would switch away from git to anything but svn or bzr.
[16:07] <ddaa> depending on where they put the blame for the pain they endured.
[16:08] <ddaa> what's this me_too thing?
[16:10] <fullermd> Can't see.  too_short.
[16:18] <jelmer> ddaa: As long as the plugin always detects renames at the same places, there's no problem :-)
[16:19] <ddaa> I mean that git has a lot of freedom to evolve their rename-guessing logic
[16:20] <ddaa> but a bzr-git plugin would be much more constrainted
[16:21] <fullermd> 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] <jelmer> ddaa: yup
[16:30] <jelmer> path tokens ftw!
[16:30] <ddaa> what's that?
[16:30]  * ddaa is hopelessly out of touch
[16:30] <jelmer> replacement for fileids proposed by robert
[16:30] <ddaa> gotta be interesting
[16:30] <jelmer> meant to solve parallel imports and copy tracking
[16:31] <jelmer> yeah, the idea is very interesting
[16:31] <jelmer> but it's also quite abstract at this point
[16:31] <jelmer> http://bazaar-vcs.org/DraftSpecs/PathTokens
[16:33] <ddaa> I regard git's support for parallel imports a very strong point for them.
[16:33]  * ddaa reads the spec
[16:34] <fullermd> git doesn't lack in strong points.  Now, if it lacked a bit more in nuttiness...
[16:35] <fullermd> The content-addressed storage is certainly a strong point.
[16:35] <ddaa> I've always felt utterly nonplussed by this.
[16:35] <fullermd> And I get to like the crypto-hash-as-revid concept better the longer I think of it.
[16:36] <ddaa> really, we only have identity problems in bzr because of limitations in how we deal with parallel imports.
[16:36] <ddaa> and content-addressing has some major drawbacks
[16:37] <fullermd> It's got major advantages too.
[16:37] <ddaa> as in making it pretty much impossible to have native checkout for foreign repository formats.
[16:37] <fullermd> 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] <ddaa> mh... this spec is pretty light on actual ideas
[16:39] <ddaa> it's just a problem statement
[16:42] <ddaa> jelmer: why does bzr-svn uses BOTH BzrDirFormat.register_control_format AND format_registry.register to register SvnRemoteFormat?
[16:44] <jelmer> Hmm, you're right, that's confusing..
[16:44] <ddaa> I guess that means only format_registry is needed, right?
[16:45] <jelmer> No, I think the first one is for the handling of ".bzr"
[16:45] <jelmer> s/.bzr/.svn
[16:45] <jelmer> while the latter is usually a combination of a branch, repository and working tree format
[16:45] <ddaa> BzrDirFormat.register_control_format(format.SvnRemoteFormat)
[16:45] <jelmer> "dirstate-with-subtree"
[16:45] <ddaa> that is not .svn stuff
[16:45] <jelmer> that's the remote stuff
[16:45] <jelmer> detecting the control dir happens by checking whether the transport is a SvnRaTransport
[16:46] <ddaa> right
[16:46] <jelmer> rather than checking for a .svn directory
[16:46] <ddaa> but then
[16:46] <ddaa> format_registry.register("subversion", format.SvnRemoteFormat,
[16:46] <ddaa>                          "Subversion repository. ",
[16:46] <ddaa>                          native=False)
[16:46] <jelmer> the format registry bit is just so it appears in the output of "bzr init --help"
[16:47] <ddaa> ok
[16:47] <jelmer> and so info knows how to call it
[16:50] <Poromenos> for some reason i can't branch from https, (launchpad), curl is giving me an error. any ideas?
[16:51] <ddaa> couple of them
[16:51] <ddaa> either use the actual http or bzr+http address of the branch
[16:52] <ddaa> https://code.launchpad.net is just a redirection to http://bazaar.launcphad.net
[16:52] <Poromenos> it redirects
[16:52] <Poromenos> hmm
[16:52] <ddaa> or do not use curl
[16:52] <Poromenos> i'm not doing it intentionally, bazaar is
[16:54] <Poromenos> http://bazaar.launchpad.net/gnuhello isn't working
[16:54] <ddaa> you can use https+urllib:// urls to stop it from using pycurl
[16:54] <Poromenos> not a branch, actually
[16:54] <Poromenos> ah
[16:54] <ddaa> or you can uninstall pycurl if nothing else is using it on your system
[16:54] <Poromenos> i don't think anything is, i'll try that, thanks
[16:55] <ddaa> btw, this url is indeed not a branch
[16:55] <Poromenos> as an aside, do you know how i can generate ssl keys?
[16:55] <Poromenos> yes, but launchpad.net/gnuhello is
[16:55] <ddaa> check https://code.edge.launchpad.net/~vcs-imports/gnuhello/trunk
[16:55] <ddaa> you'll see the download URL there
[16:55] <Poromenos> ah, urllib worked, thanks though
[16:55] <ddaa> the redirection magic only happens on code.launchpad.net, not on bazaar.launchpad.net
[16:56] <Poromenos> ah
[16:56] <ddaa> Poromenos: the command is ssh-keygen, if you are on linux
[16:56] <ddaa> if you are on Windows, I have no clue.
[16:57] <Poromenos> i'm on ubuntu, thanks
[16:57] <ddaa> Poromenos: I'm pretty sure there is extensive documentation about this stuff on help.launchpad.net
[16:57] <Poromenos> 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] <Poromenos> ssh, i mean
[16:58] <ddaa> ok
[16:58] <ddaa> maybe file a bug on launchpad-bazaar then
[16:58] <ddaa> this sort of thing should be crystal clear.
[16:58] <Poromenos> i will, thanks
[17:09] <Poromenos> can i delete a branch after i publish it?
[17:09] <Poromenos> (on launchpad)
[17:29] <dato> jelmer: did you see my mail about bzr-plugins?
[17:29] <jelmer> dato: no that I remember - where did you send it?
[17:30] <dato> bazaar@ and -maint
[17:30]  * jelmer has a look
[17:31] <GaryvdM> If I ran bzr-gtk's ./setup.py install - is there a way to uninstall?
[17:52] <Poromenos> can anyone ssh to bazaar.launchpad.net?
[17:52] <Poromenos> it's not working for me
[17:52] <ddaa> the shell is disabled
[17:52] <Poromenos> oh
[17:52] <Poromenos> temporarily?
[17:52] <ddaa> permanently
[17:53] <Poromenos> how do people upload code then?
[17:53] <ddaa> bzr push
[17:53] <Poromenos> push where...
[17:53] <ddaa> to the bzr+ssh url displayed on the branch page of a hosted branch
[17:54] <Poromenos> that's what's not working
[17:54] <Poromenos> https://code.launchpad.net/~stavrosk/gmailchecker/main
[17:54] <ddaa> please paste the bzr command you typed and the output it produced
[17:54] <Poromenos> bzr push bzr+ssh://stavrosk@bazaar.launchpad.net/~stavrosk/gmailchecker/main
[17:55] <Poromenos> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
[17:55] <Poromenos> that's it
[17:55] <ddaa> meh
[17:55] <ddaa> indeed, it's down
[17:56] <dato> Next mirror:
[17:56] <Poromenos> ah
[17:56] <dato> As soon as possible
[17:56] <dato> heh
[17:56] <Poromenos> i'll wait then, thanks
[17:56] <Poromenos> can i name a branch?
[17:56] <Poromenos> i mean in bzr
[17:56] <Poromenos> probably not, nm
[17:56] <ddaa> not sure what you mean
[17:56] <ddaa> you can specify a branch nick that will be recorded in commits
[17:57] <ddaa> otherwise, the name of a branch is its url
[17:57] <ddaa> you can change the last past of a branch url on launchpad
[17:57] <ddaa> "Edit branch details", it's the branch name field.
[17:57] <Poromenos> i just saw "branch name" on the web interface, but i realized it's what you enter
[17:57] <Poromenos> yes, thanks
[18:13] <kripken__> 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] <ddaa> apparently the ssh server is down
[18:29] <ddaa> there should be a nagios alarm ringing right now
[18:31] <foom> 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] <luks> the trick is to use shared repositories
[18:33] <ddaa> right, you don't want to duplicate 40krevs of data anyway
[18:33] <ddaa> aside from the fs bloat, it does not allow efficient use of the disk caches.
[18:34] <foom> 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] <jelmer> hi foom
[18:34] <luks> hm, what are the situations when it doesn't work?
[18:35] <foom> jelmer: hey there
[18:35] <foom> luks: branching a remote repository, for example.
[18:35] <kripken__> ddaa: thanks for the info
[18:36] <luks> foom: but you do that only once, and never again
[18:36] <luks> not such a big problem, IMO
[18:36] <luks> next time you branch you have most of the data locally
[18:37] <ddaa> 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] <ddaa> although it is planned to have shallow branches in the future
[18:37] <luks> ddaa: yes, but without a shared repository you download it over and over again
[18:38] <ddaa> so you won't HAVE to pump all the history of the server to make a local branch.
[18:38] <luks> which is that I guess foom is doing
[18:38] <luks> er, s/that/what/
[18:38] <foom> 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] <foom> and it seems quite unlikely that this would be the only too-slow operation
[18:39] <ddaa> bzr is certainly not as fast as some of the competition, but using the most recent formats, it should be fast enough.
[18:40] <ddaa> 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] <ddaa> 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] <luks> the most annoying thing to me is not the actual performance, but the startup time
[18:41] <foom> 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] <jelmer> foom: Yes, it isn't a full fix
[18:42] <foom> 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] <jelmer> foom: You need an updated version of the python-subversion bindings for all of the memory leaks to go away
[18:42] <foom> "hey look, X is taking some memory, let's kill it!". thanks linux...heh
[18:42] <jelmer> http://subversion.tigris.org/issues/show_bug.cgi?id=3052
[18:43] <foom> that's not patched in ubuntu yet is it?
[18:47] <foom> luks: startup time?
[18:54] <foom> and...'bzr log -r20000' takes 23s.
[18:57] <ddaa> jelmer: it seems pretty much impossible to implement a transparent git:// transport
[18:57] <ddaa> short of reimplementing the client code
[18:57] <ddaa> common git servers only expose git-fetch-pack and git-peek-remote services
[18:58] <ddaa> and the former requires a local git dir
[18:59]  * ddaa finds this frustratingly limited
[19:21] <ddaa> yay! git_connect dies on error :(
[19:24] <jelmer> ddaa: Are you working based on stgit?
[19:24] <ddaa> jelmer: I'm based on jam's branch
[19:24] <ddaa> it has no stgit dependency
[19:24] <ddaa> and right now, I'm staring at the git source itself
[19:24] <ddaa> and all my fears are confirmed
[19:27] <jelmer> :-/
[19:27] <ddaa> 	if (protocol == PROTO_GIT) {
[19:27] <ddaa> 		/* These underlying connection commands die() if they
[19:27] <ddaa> 		 * cannot connect.
[19:27] <ddaa> 		 */
[19:28] <ddaa> Also, all the network code seems to assume that sockets and pipe and interchangeable
[19:28] <ddaa> i.e. forget about windows
[19:29] <ddaa> At least some of the client code will have to be written from scratch.
[19:29] <ddaa> or heavily patched.
[19:36] <jelmer> ddaa: You're writing this in C or Python?
[19:36] <ddaa> just explorating
[19:36] <ddaa> Actually, I think I'm going to give up on the transparent transport.
[19:40] <jelmer> I thought Robert already had a lot of this done
[19:40] <ddaa> the bzr-git code I see is quite proof-of-concept
[19:40] <ddaa> and it only works locally
[19:40] <ddaa> i.e. it does not try to do more than git
[19:41] <ddaa> which pretty much only knows how to fetch packs over the network, then does everything locally.
[19:45] <jelmer> ah, ok
[19:45] <ddaa> unfortunately, I do not think that's an acceptable level of functionality for bzr :(
[20:07] <ddaa> Hey, bazaar.launchpad.net SFTP server is up again
[21:02] <piedoggie> I just started reading the user documentation and I am damned impressed.
[21:02] <piedoggie> 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] <eddyMul> 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`?
[23:50] <Verterok> eddyMul: take a look to the merge-into plugin <https://launchpad.net/bzr-merge-into/>, might be helpful.
[23:50] <eddyMul> Thanx, Verterok. Will look at it
[23:52] <eddyMul> 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] <Verterok> eddyMul: it's seems is broken :(
[23:54] <Verterok> it's broken against bzr.dev, probably it won't work with 1.0
[23:55] <eddyMul> Verterok: when I try merging, it kept complaining "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified."
[23:55] <eddyMul> which sounds about right
[23:56] <eddyMul> when I specify the revisions (there are 5 revs) -r1..5, bzr bombs w/ AssertionErrors
[23:56] <eddyMul> :(
[23:57] <Verterok> 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] <spiv> eddyMul: you can try "-r0..5"
[23:59] <spiv> eddyMul: also, there's a "bzr join" command, but it's still experimental.
[23:59] <Verterok> spiv: thx for the r0..x tip :-)