[00:08] poolie: good morning! [00:11] hello jml === mw is now known as mw|out === BasicMac is now known as BasicOSX [02:33] * ToyKeeper discovers, after typing a very long change log, that Escape means "abort NOW" in "bzr gci" [02:33] ... poor fingers can't unlearn "esc :w" [02:33] ouch [02:34] * ToyKeeper files a bug about it [02:40] hey lifeless [02:42] hi i386_ [02:42] lifeless: good news - as of next week im an Apache committer :) [02:42] and we need you over for dinner [02:42] indeed [02:49] `bzr checkout`ing from a Subversion repository that has only a trunk and then unbinding is effectively a full migration of the repository to Bazaar, right? [02:49] yes [02:49] you may as well just bzr branch :P [02:50] ah [02:50] even better [02:50] thanks lifeless [02:56] New bug: #218986 in bzr "Escape aborts 'bzr gcommit'" [Undecided,New] https://launchpad.net/bugs/218986 [03:01] * i386_ wants to use bzr over at this apache project [03:01] hows the svn plugin these days? [03:02] i386_: I like it very very much. [03:02] Works well? [03:02] i386_: I'm using it to track banshee development & do some hacking, and it works just fine there. [03:02] cool [03:03] how does it deal with repositories with huge histories ? [03:04] Slowly on the initial branch (obviously), and then just fine from there. [03:04] Banshee is on svn revision > 10K, IIRC. (I don't know, my checkout is on bzr revision 1024 :)) [03:05] RAOF: can you push back to svn? [03:05] i386_: I _believe_ so, but I don't have banshee svn acces, and I haven't tried with anything else. [03:05] i386_: by default commits occur like SVN commits, immediately sent over the network to the SVN repo [03:05] RAOF: we suffer from a slow checkout time [03:06] gotgenes: Really? I suppose that depends on how you checked it out, though, since it didn't seem to try for me. [03:07] RAOF: I did a bzr checkout and it's acting as a bound branch [03:07] I think that's the right term [03:08] gotgenes: Oh, of course it would, since that'd be the behaviour for checking out a bzr branch. [03:08] gotgenes: I did 'bzr branch', and my commits are local. [03:09] RAOF: I assume you just do a bzr push to get the commits out to SVN? [03:09] gotgenes: Yes. If I had write access to that repository. [03:09] sure [03:27] how long does bzr branch lp:bzr usually take? [03:29] nm i'll just get from my branch [03:33] would there be a reason why this works fine: bzr branch http://bazaar.launchpad.net/~bzr/bzr/trunk [03:33] but lp:bzr just sits [03:34] What about "bzr branch bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk" ? [03:34] Is that the same as lp:bzr? [03:35] If so, it's nothing do with lp:bzr, it's just poor progress reporting when using the bzr protocol rather than plain HTTP. [03:35] i will check it out when this download ends. [03:35] oh yes, who do i punch about that [03:35] * mwhudson downloaded a 400 meg branch from launchpad over bzr+ssh yesterday [03:35] ouch [03:36] 'watch du -s' is not really a good progress bar :) [03:36] yeah...should break out into metallica videos or something [03:37] mwhudson: bzr -Dhpss ... + tail -f ~/.bzr.log ;) [03:37] with SSH...bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) [03:38] problem on my config [03:38] spiv: not much better [03:38] Oh, bzr+ssh://YOUR-LP-USER-NAME@bazaar.launchpad.net/~bzr/bzr/trunk, sorry. [03:38] <------i should have noticed that [03:38] Assuming you have your SSH public key in your launchpad account (and assuming you have a launchpad account) [03:39] (I just have my ~/.ssh/config set use the right username for bazaar.launchpad.net automatically, so I keep forgetting that bit) [03:40] no...with username i get the same ...just sits [03:40] need to check config and ssh [03:40] is there a plugin around that lets you interactively select hunks to commit (ala shelve in reverse)? [03:42] somehow we need to do something about google search [03:42] type lauchpad bzr and you get massive bug listing [03:42] not good PR [03:44] Well, that's like typing 'bugzilla gnome', really :) [03:44] ouch [03:44] but true [03:45] Although when I 'launchpad bzr' into google, I don't get bug reports. [03:46] add ssh [03:47] Ah, some bugs start appearing. [03:49] nevermind i found the problem...it was between my keyboard and chair [03:50] forgot to register my new keygen [03:59] I'm trying to use the bzr fast-export plugin. I have bzr fast-import installed... but I have this error [03:59] bzr: ERROR: unknown command "fast-export" [03:59] fast-export is a sub of fast-import [03:59] any ideas? [04:37] xenoterracide: bzr-fast-export.py is a script bundled with the fast-import plugin [04:38] you want something like ~/.bazaar/plugins/fastimport/exporters/bzr-fast-export.py ... [04:38] (no promises that path is correct but you get the idea I hope) [04:38] so I should just run the file directly? [04:38] yes [04:39] I ought to turn it into a proper command but that's how it is right now [04:55] igc: hmm... I'm not that familliar with bzr (or how git fast-import works) I'm in the bzr checkout dir and I know the name of the branch I checked out... running bzr-fast-export.py branch |git fast-import ../project doesn't seem to work [04:56] xenoterracide: let's take it one step at a time [04:56] you should be able to redirect the output of bzr-fast-export.py [04:57] and check that it looks right [04:57] I'd have to read the git-fast-import man page but ... [04:58] you probably need to be in the dir holding the .git directory? [04:59] I'm not sure... looks docs over [04:59] there's some notes at the top of the python file too [05:00] i.e. the top of bzr-fast-export.py [05:02] right. I totally hate sounding like an ungrateful ass, but these progs really, really need better docs [05:02] xenoterracide: true [05:03] I'll have to write something up once I figure it out [05:03] :P [05:03] please do - thank would be good [05:04] what does --export-marks=marks.bzr doe the name matter? or is it just a file? [05:04] just a file [05:05] see the git-fast-export man page for an explanation [05:05] sorry - git-fast-import [05:09] waits... hopefully thats working [05:35] ok... export seems to have went well now I have an import error [05:35] question is where is the problem [05:42] http://vim.pastey.net/85948 git import who should I be bugging the bzr repo owners? git? or the bzr-fast-export maintainer [05:54] xenoterracide: my guess is that the bug is most likely in bzr-fast-export [05:54] so who do I complain at? you? [05:55] dato was the original author of it, though it's now part of bzr-fastimport so probably me [05:55] can you raise a bug in lp? [05:56] the project should be bzr-fastimport [05:56] lp=launchpad? [05:56] yes [05:56] either james_w or myself will look into it for you [05:57] others might too [05:59] igc: yeah I've filed a couple hundred bugs before. but never where I had 3 possible parties who could be at blame... [06:00] actually 4 [06:00] :-) [06:00] although I have one that I've yet to file thats worse [06:00] it affects every browser in linux [06:00] and most programs, except a few... [06:01] could be the font yet some programs handle it correctly [06:01] so who's problem is it [06:01] yuk [06:01] I really should report it to mozilla because it crashes ff 100% of the time [06:01] but no browser renders it right [06:02] but OOo and the font browsers handle it fine [06:03] oh and it only affect *nix systems [06:03] windows ff does it fine [06:03] but was reproducable on mac [06:04] who would you bother first? [06:05] who's most likely to care about getting it fixed? [06:06] I don't know... [06:08] igc hmm... it says project doesn't exist in gentoo.... this may rank as my new top crappy bug tracker [06:09] xenoterracide: does it crash Epiphany? Konqueror? [06:09] wait I figure lp out [06:09] mneptok: doesn't crash konq or opera but it is rendered improperly [06:09] I haven't tried epiphany [06:10] sounds like X font rendering, killing Gecko and not playing nicely with KHTML. can the font be used locally in, say, OO.org docs without issue? [06:11] yep [06:11] not X [06:11] I haven't tried X directly [06:11] it's broswer rendering. report the crasher against Gecko if it kills Epiphay. [06:12] (now *there's* some half-assed triaging!) [06:12] * mneptok flexes [06:12] well it wasn't just browser I had a problem in another kde program [06:12] * xenoterracide doesn't remember which one [06:12] prolly kwrite [06:13] well, to be fair, it's not a bzr issue, so ... [06:14] I know [06:14] just talking about haywire bugs [06:14] and i supposedly quit working 2h ago. [06:14] and now, i shall. g'night xenoterracide. hello PS3. [06:15] heh [06:18] https://bugs.launchpad.net/bzr-fastimport/+bug/219042 poof [06:18] Launchpad bug 219042 in bzr-fastimport "fast-export doesn't export right" [Undecided,New] [06:19] ;P [06:21] night mneptok [06:58] the crashing stuff could be pango, though if it doesn't crash normal gtk apps maybe not directly [06:58] (and I'd expect it to crash the gnome font viewer if it was pango too) [06:58] oops, he's gone [07:07] spiv: how is the patch for the line delta bug? [07:08] poolie: just pushed a new version of it, was about to send to the list after selftest passes. [07:09] get_revision_file returns a KnitVersionedFile where delta=True, which is wrong. So the patch just forces delta=False, and teaches insert_data_stream how to convert a line-delta record to fulltext if not self.delta [07:10] This fixes the bug with the test branch, as well as giving a local repo with a clean (i.e. all fulltext) revision knit. [07:11] I don't have tests in my patch yet, but the approach is still reviewable without that, so I'll send to the list first before worrying about that. [07:15] ok, thanks [07:15] i'll look at it [07:23] Ok, selftest with the existing suite passes, bundle sent to the list. [07:23] i'm just writing a mail about 1.4, [07:24] i think we should merge these things and do a 1.4rc2 this afternoon [07:24] but leave final for next week [07:24] what do you think? [07:24] I'm inclined to agree. [08:07] poolie: I agree. I think we need an rc2 for 1.4. We want those people who went back to 1.3.1 when they found problems to kick the tires again. [08:08] or "tyres" in the case of us Aussies :-) === quicksil1er is now known as quicksilver [08:29] igc, thansk [08:30] igc, spiv, i don't think i'll have time to make it today though, i have a commitment with stephane [08:30] i will try to do it on the weekend [08:30] poolie: ok. I'm heading off rsn also fwiw [08:31] poolie: ok. enjoy your weekend (well, the non-work bits at least :) [08:46] Hi ! What is submit branch: in bzr info ? [08:47] matkor_: it's the public url of the branch you want to merge into [08:47] typically the main branch of your project [08:49] poolie: Hmm, I do not remember me merging into remote branch ... usually I merge to local checkout of main branch, resolve conflicts and commit ... How could I create it ? [08:50] matkor_: iirc the submit branch just controls the default for bzr send [08:51] poolie: Thnx a lot ! I will read on about bzr send [08:53] night all - have a good weekend [08:57] hello james_w [08:57] (leaving soon) [08:57] hi poolie [08:58] have a good weekend [09:26] igc: I'm happy to look at bzr-fast-export bugs too [09:28] igc: though if you prefer to look into this one, I'm happy to. the problem seems to be that we're instructing git-fast-import to rename a directory, when we shouldn't be doing that. [09:31] hi dato [09:31] hello james_w [09:32] if that is the issue then it may be worth talking to Shawn, as it seems that possibly should be allowed. [09:32] well, git should just ignore it, but I don't see why it should reject it. [09:36] uhm, no, I'm mistaken [09:36] path/dir1 was renamed to path/dir2, and it seems that was accepted (of course) [09:37] and then path/dir1/fileX was renamed to path/dir2/fileY, and that boomed [09:38] so a directory rename is recursive to git-fastimport? [09:39] well, it is to bzr as well, ain't it? [09:40] I'm not sure how it's represented internally [09:40] I would expect bzr-fastimport to do that though [09:43] maybe bzr-fast-export should do some ordering, I'm not sure [10:46] mwhudson: hi [10:46] mwhudson: should pydoctor work on .so files? [11:02] hey, i had a bzr server to which we did 'bzr update' and 'bzr commit' every once in a while [11:02] but it's down, so i got a new one [11:03] and i have the last commit on my computer [11:03] so i coppied it to the new server [11:03] and now i want everyone to 'bzr update' from it and 'bzr commit' to it. [11:04] the thing is - it always tries to connect to the old server [11:04] and since the old server is down, i can't seem to use the new one. [11:05] bjesus: try `bzr unbind; bzr bind new_server_address_and_path` [11:05] how can i make a directory created from a 'bzr checkout' and 'bzr update' to something i can checkout and update from? [11:05] thanks i'll try [11:06] 'bzr unbind' gives me a long error ending with: [11:06] RuntimeError: maximum recursion depth exceeded [11:06] i can't even see where it's starting [11:08] the thing is - if 'a' is the old server, 'b' is my user pc, and 'c' is the new server - b used to do checkouts and updates from a, but what if c wants to checkout and update from b? is that possible? to change the centeral location? [11:08] c wants to update from b? [11:09] I thought you wanted b to update from c... [11:10] basically yes, but it seems like simply copying the directory doesn't work, so if i'll update c from b, i'll surely be able to afterward update b from c, and every other computer from c [11:13] it seems like it's all about changing the central server, since if i could make the latest-updated-computer a new server, i could checkout it from everyother location and then make the new location the new server. === mrevell is now known as mrevell-luncheon === mrevell-luncheon is now known as mrevell [13:28] larstiq: i had a couple of questions so i could proceed working on the bug i'm working on [13:28] jdobrien: shoot [13:30] what commands should the change i am making effect? [13:30] status is obvious, diff too? [13:30] cat? [13:32] larstiq: nm not cat [13:34] jdobrien: ignore perhaps [13:34] larstiq: other question is, you mention may have already created some unit tests. can't remember who you said and not sure where to look for them [13:35] jelmer: ? [13:35] not here though, send email [13:35] k [13:36] jdobrien: can't find it at the moment, but it wasn't much [13:36] jdobrien: I'd focus on status first though [13:38] i was relying on the online log and we apparently were in a private chat when you gave me the name :-/ [13:38] k [13:39] i was going to create a separate test for the expected behaviour first, then i would assume i should mod the existing tests for status [13:41] larstiq: opinion? [13:43] jdobrien: previous tests might not be needed to modified [13:43] jdobrien: bzrlib/tests/blackbox/test_status.py is where I'd add them [13:43] k [13:44] so no reason to create 'new' tests [13:44] just put them in the status black box testing [13:46] larstiq: thanks. im still obsorbing python so i appreciate the patience. [13:46] jdobrien: at first, for testing that the commandline status output is what you expect, certainly in the status blackbox [13:46] jdobrien: np, have a look at the rest of the tests to get an idea [13:47] yeah i have been [13:47] cool [13:47] larstiq: im used to using nunit/junit so it's not a big leap [13:49] larstiq: the diff between staticmethod & classmethod had me spinning for a few hours last night...different behaviours in c# === ja2 is now known as jam === mw|out is now known as mw [16:20] New bug: #219246 in bzr "exceptions.KeyError on log" [Undecided,New] https://launchpad.net/bugs/219246 [16:53] Hey, guys, how can I see what will be pushed to a remote location when I say "bzr push"? [16:54] without pushing it [16:54] isn't there a option to do this? [16:54] dwt: bzr missing --mine-only [16:55] seems to work [16:55] great! [17:00] thanks guys === weigon_ is now known as weigon [17:15] Is there any good solution for pushing code from a bzr branch to a webhost via ftp? I've been looking at rsync and lftp, but rsync has to use curlftpfs which is not reliable, and lftp depends on date stamps, which bzr trashes. I seem to remember mention of a plugin? [17:20] moin === kiko-afk is now known as kiko === mario_ is now known as pygi [17:32] VSpike: bzr can push to ftp [17:33] however it doesn't update/create the working tree, meaning your files won't be visible on disk, you'll only see a .bzr [17:33] there is a plugin to work around that, but it uses ssh, so you're back to square one if you need it. [17:45] james_w: ah yeah, that's my problem in a nutshell [17:48] so, no way around it at present? I guess I just have to ftp up everything every time. [17:50] hello [17:51] suppose there is a branch to which i only have read-only access, but i want to add a patch, would it be feasible/sane to keep a local copy with the patch indefinitely and still merge the changes from the remote branch in it? [17:53] Stavros, you should be able to just branch [17:53] add your path [17:53] *patch [17:53] and keep on merging indefinitely, yes [17:53] ah, great [17:53] many of us do it on a daily basis [17:53] would this be easy? [17:53] or would every patch need manual adjustments? [17:53] err [17:53] every merge [17:53] Stavros, nope, you should be fine [17:53] ah, that's great [17:54] I do regular: bzr merge && bzr ci -m'Merge from trunk' [17:54] you might have occasional conflicts [17:54] that solves the big problem of adding features to various 3rd party packages [17:54] but you might not :) [17:54] well yes, true [17:54] but overall, it sounds much easier [17:54] Stavros, yeap, I think that's one of the ideas behind DVCS [17:55] great great [17:55] not needing write access to the main branch to work on it and use version control [17:55] yes, i was more worried about the "indefinitely" part :P [17:55] you'll just have to merge n commit instrad of pulling [17:55] *instead [17:55] isn't too painful [17:55] yes [17:56] i agree [17:56] great great [17:56] i love bzr [17:56] welcome to the club :) [17:56] i have been a member for a while :p [17:57] i use it rather exclusively [17:57] does bzr-svn with authentication work in linux? [18:04] Stavros, I don't use it, but AFAIK, yes [18:04] jelmer would know more about this [18:05] ah, thanks [18:09] <[cliff]> hi all! [18:10] <[cliff]> is it possible to use, or somehow simulate, nested branches with bzr? [18:10] [cliff], LarstiQ is the man to answer that [18:11] <[cliff]> so I'll have: branch1, which contains references to branch2 and branch3 [18:11] he hides sometimes, but if you win the waiting game, you'll eventually get a good answer for that :) [18:11] <[cliff]> thanks beuno [18:11] <[cliff]> lol [18:11] <[cliff]> thanks [18:12] [cliff], alternatively, you can email the list [18:12] <[cliff]> yeah, but I was trying to avoid subscribing to yet another mailing list :-) [18:14] [cliff], right, then "waiting game" seems like your best option for a good answer [18:26] <[cliff]> right... subscription is it :-) [18:26] <[cliff]> cheer-io-s [18:36] right, right [18:36] LarstiQ, don't hate me :) [18:37] beuno: I don't :) [18:37] beuno: more myself really [18:37] LarstiQ: well, it was unclear if he was willing to "fake" it, or if he needed the real thing [18:38] jam: right. But regardeless of what he wants, it still needs to be done [18:38] LarstiQ, it's just a recurring ping to either iron out the remaining failing tests, or start merging parts of the code so someone else could potentially take over :) [18:39] beuno: thank you for doing that [18:39] LarstiQ, it's a selfish thing, I've got a use case for it at work :p [18:47] jam: I believe you sent a mail related to it? I haven't yet looked at that [18:48] beuno: that's ok [18:48] I don't remember sending anything but a ping [18:48] Folks! Is there a way to merge a bunch of commits into one commit? [18:49] jam: ok [18:49] In other words: bzr branch local, commit 1, commit 2, commit 3, then merge those as one big commit/patchset? [18:49] tolstoy: and you're not meaning a regular merge? :) [18:49] tolstoy: depends what you think that is [18:49] tolstoy: generally a regular merge will add 1 new commit to signify the joining [18:49] and 'bzr log --short' will only show that. [18:50] If you want to completely remove commits 1,2,3 from the history you can: [18:50] bzr revert --forget-merges [18:50] after the merge [18:50] so it looks like it was all freshly done [18:50] or you can [18:50] I could make lots of little "daily back up commits", then branch at some early point, and merge a big diff and commit that, and toss the original, but was wondering if there was something less clever. [18:50] jam: forget merges, ah, okay. [18:50] commit 1, 2, 3; bzr uncommit -r -3; bzr commit -m "this is the new tip for 1,2,3" [18:50] tolstoy: you probably want 'uncommit' then [18:51] jam: Oooo, I like that. Cool. [19:17] is there a way to change the email used in previous commits ? [19:17] asabil, unfortunetly, no [19:17] the previous commits are immutable [19:17] :/ [19:18] asabil, I'm working on bug 215334 to try and avoid committing with the wrong info [19:18] Launchpad bug 215334 in bzr "Bzr shouldn't permit users to commit without setting author info" [Wishlist,Confirmed] https://launchpad.net/bugs/215334 [19:19] beuno: that's the not the problem [19:19] I really think that bzr needs something like git-filter-branch [19:19] asabil, right, then it's a different use case :) [19:20] I think the versioned properties bit would be what would solve this [19:20] some work was done towards it [19:20] but I'm not sure what the status is [19:20] ok :/ [20:17] beuno: how would versioned properties solve this? [20:19] lifeless, unless I'm completely lost on what it is, wouldn't the committer be a property which could be changed, with the change being versioned so we still have the original information preserved [20:19] IIRC, something like this was discussed in the sprint, although I might be confused :) [20:21] New bug: #219334 in bzr "Texinfo version of the documentation" [Undecided,New] https://launchpad.net/bugs/219334 [20:22] beuno: this is exactly why I object to 'generic versioned properties' [20:22] beuno: the answer is no, because its a chicken and egg problem [20:23] beuno: revisions contain the committer; the revision graph describes the tree [20:24] beuno: log would be at least twice as slow if every lookup had to indirect back into the tip revision tree; and the proposed single file property store would fall over cold on something like ooo [20:24] lifeless, I see. In which cases would versioned properties be applied then? [20:25] beuno: I don't know of any other than eol; and I don't htink its a good fit there. [20:25] beuno: I want eol badly; I just think this generic versioned property is a dead end introduced because 'svn has them' back at some point in design discussions [20:26] lifeless, seems reasonable. Although, the issue about changing previous commits comes up too often for us not to look into some kind of workaround. There might not be any, but still, we should keep on trying [20:27] lifeless, right, I think it's an overkill too, if it's just going to be used for EOL [20:27] beuno: if we want to allow changing of commits we just add another authoritative timeline === mw is now known as mw|lunch [20:28] one that is not human derived; but this adds massive complexity in design (e.g. which attributes can be edited; is there security; how to deal with conflicts) [20:28] as well as performance considerations, and the issues of explaining that this is going on [20:28] right, a heap load of work [20:28] this is why none of darcs/git/monotone/hg allow it [20:28] and there are much important issues ATM [20:30] lifeless, I'm working on being more verbose to people about what info they are committing with [20:30] to try and narrow that down a bit [20:30] cool [20:30] well 5:30, I am going to take a couple of panadol and try to sleep [20:30] but I suspect this will just keep coming up :) [20:30] heh [20:30] ok [20:30] sleep well! [20:31] the generic answer to 'I want to rewrite my history' is 'ok rewrite your history' [20:31] bye [20:31] beuno: I wasn't asking really about changing the previous commits [20:31] but about creating a new filtered branch from the original one [20:33] asabil, right, but in order to change previous authors, you change the commit metadata, so it's more or less the same. You might be able to use rebase plugin and some other black magic to do that, but this is really out of my knowledge :) [20:34] thanks anyway for the tips [20:34] asabil, :) [20:38] the problem with "ok rewrite your history" is that afaik you can't do that without screwing over all your developers. it would be nice to be able to rewrite your history and not have it blow up everyone's checkouts. If the history you're rewriting doesn't end up affecting the current revision, that should at least be theoretically possible. [20:52] * beuno wonders where jelmer is with the new bzr-gtk release [21:00] foom: well [21:01] asabil: I think a filter branch command might be useful; it does need to rewrite the graph though as in git [21:01] foom: indeed; thats why rewriting history isn't part of regular bzr workflows, and why looms does not do it. [21:01] lifeless: yes I think so as well [21:01] beuno: I think you've got the wrong end of asabil's stick. [21:01] lifeless: a solution to the "Nuclear Launch Codes" problem would be nice, though... [21:02] beuno: asabil means 'create a new branch with history derived from the old one (synonymous graph, but different ids), and some other arbitrary differences besides' [21:02] foom: indeed. I believe heavy radiation is the cure :P [21:02] lifeless, right, so they become different branches. It's different from what I meant [21:03] I was looking at preserving it for other derived branches to keep working [21:03] I don't minds having different branches [21:03] * beuno wonders how long lifeless's panadol takes to kick in :) [21:03] as long as the filtered one retain the time stamp and the commit messages [21:03] beuno: its failing to [21:04] lifeless, double or nothing? :p [21:04] beuno: anyhow, consider the problem of indexing a database with two different values for the same unique key :P [21:04] shortly, you'll be sharing my headache [21:04]