[00:00] http://www.pastebin.ca/1030503 [00:01] Ah, you need "from bzrlib.workingtree import WorkingTree" [00:02] oh, ok [00:02] let me try [00:03] ok.... I got another error mesage... let's see where I get to. :-) [00:12] OK.... I got the working tree.... how could I ask for added files? [00:13] is there a "getting started with Bazaar" doc that I'm missing? [00:13] in bazaar's docs you can see the five minute intro doc... which is a nice crash course [00:14] antoranz: maybe take a look at how bzrlib.status.show_tree_status is implemented, or how bzrlib.builtins.cmd_added is implemented. [00:15] well.... that's quite reasonable.. let me see the show_tree_status [00:54] is it possible to set the public_branch on a branch using the CLI? [00:55] jml: the help for bzr send claims that it will remember the public branch, i think [00:55] mwhudson: it appears that my trunk has no public branch set. [00:56] jml: bzr send ../trunk http://whatever --remember [00:56] and then it will [00:56] if the docs are correct anyway :) [00:56] mwhudson: so the public_branch arg to 'send' is the public_branch of the submit branch? [00:56] not the public branch of the branch being sent? [00:58] jml: oh i see [00:58] i guess you can run send -o/dev/null in the trunk branch to set it [00:58] or maybe there's some more sensible way [01:06] got it! [01:06] * jml does the up-thread; commit dance [01:06] but I worry about the way the working tree tells me about changed files [01:07] antoranz: how so? [01:07] Let me paste the code in the pastebin so you can see. [01:10] http://www.pastebin.ca/1030550 [01:11] I get the filename from an array [01:12] I wonder if that structure changes often. I think an object would be more "elegant" [01:13] jml: see what I mean? [01:13] antoranz: kind of. [01:14] antoranz: the return type doesn't change very often at all (grep NEWS for iter_changes) [01:15] antoranz: unfortunately, objects are considerably slower than tuples :( [01:15] right. [01:15] well... speed is a nice explanaition for it... the code is working though. :-) [01:15] all things being equal, I'd use an object instead of a tuple. However, given that this is performance critical code, there'd need to be some obvious benefit for using an object. [01:16] how's the code? A1? :-D [01:16] considering it's my first python program [01:16] OTOH, in Python 2.5 (I think), you can 'name' the fields of a tuple. So eventually, perhaps... :p [01:17] antoranz: it's ok. [01:17] ok [01:17] will ./ work in windows? [01:17] antoranz: if you bump into a really big file, you'll have memory problems. [01:17] or is there a straight way to get the pwd? [01:18] antoranz: os.getcwd() [01:18] well.... file are not so big right now.... so I guess it's ok for the foreseeable future [01:18] antoranz: also, you want to make sure you don't run convert2unix on binary files. [01:18] if file start to grow, II'll change it to process line by line instead of loading the whole file into memory [01:18] antoranz: there's no need for the exit(0) at the end also, [01:19] is there a piece of information that tells me if the file is binary? [01:19] Odd_Bloke: 2.6 has collections.namedtuple [01:21] I guess "kind".... but what are the possible values? [01:21] antoranz: not that I know of. (but I'm pretty ignorant in this area) [01:21] antoranz: "kind" is for distinguishing files/directories/symlinks etc [01:22] also, I shouldn't work on directories. [01:22] it's cambio[6][1] [01:22] There's nothing in bzr at the moment that tracks if a file is meant to be "text" vs. "binary". igc is working on adding a feature like that, though. [01:23] ok.... I'm working on text file for now... so I guess that's not a problem actually. [01:25] spiv: Ah, perhaps that's what I meant. [01:25] I just remember being given some code which used them and it not working for me. [01:25] Which suggests that it wouldn't work in 2.5, now I reflect on it. [01:25] Odd_Bloke: :) [01:26] how do you say "!=" in python? [01:27] Just like that. [01:28] ok... the problem was that I'm forgetting about using ":" at the end of the conditional. [01:31] antoranz: oh, that reminds me: use 'fileName is None' rather than 'fileName == None' [01:31] for reasons that have long since escaped my mind. [01:33] ok [01:33] Faster, more precise, less punctuation. [01:34] spiv: thanks. [01:34] poolie: any thoughts on whether filtering ought to be applied to .bzr* files? [01:34] (In particular, it's immune to a weird __eq__ or __cmp__ that might claim that a non-None object is equal to None) [01:35] abentley asked in his review whether it ought to be skipped for .bzrignore [01:35] I wonder whether Windows users would expect .bzrignore to have crlf or not [01:40] igc: make a compromise, use crlf every second line ;) [01:41] or go for the annoy everyone approach, and just use \r :) [01:42] TheSheep, mwhudson: interesting ideas. That ought to maximise the confusion. Maybe we could combine those ideas ... [01:42] and have lf, crlf, cr alternating [01:43] or make it random at the end of each line - better still :-) [01:43] guys, thanks 4 ur kind help [01:44] C ya later! [01:45] igc, i would say it probably should be applied for consistency; if the user configures it to be broken it's their responsibility [01:45] uh, we should probably accept either separator in those files [01:45] spiv, just trying to wrap up here then will leave [01:47] * beuno waves [01:47] hi everyone [01:48] hi beuno [01:49] LP code scanner still seems lagged [01:49] hello beuno [01:49] hello mwhudson [01:49] I wonder how big the branches that where added really are... [01:50] hello poolie [01:51] so... mwhudson... I've been thinking performance all day [01:52] aside from switching the templating engine, I've been thinking that, even if we improve the cost of rendering, it will still be rather expensive for some operations [01:52] so it got me thinking how we can avoid that cost [01:54] anyway, what do you think of adding a json generator, that we can can ask for via ajax, and refresh the screen's information with that? [01:54] we would only render the HTML once, and the client will render from then on [01:55] it can be added to the current code base, and used optionally (we would still be able to render all pages) [01:56] and cache the jsons on the client side, so once he retrieves a set of information, we can avoid as much as possible to hit the server again [01:57] beuno: do you know that roundtrips are the main bottleneck? [01:57] and, if performance still is a bottle-neck for repeated request for the same screen, we can still implement a server side cache [01:58] jml, I have no information at all of what the real bottlenecks are, just guesses from playing around with the code [01:58] it's almost as expensive to render an annotated file than it is to annotate it with bzr [01:58] that seems like something we need to solve [01:59] (no information on LP, that is) [01:59] beuno: sure. That said, it's worth spending some time profiling to be certain that you are solving the right problem. [01:59] jml, right, I have been profiling the code, and rendering *is* the main problem curently [02:00] just not what specifically is bashing the LP so hard [02:00] ok. [02:01] so, while we may find a better templating engine, it will still be a cost we will pay [02:01] *nod* [02:02] and we can generate json files without rendering them through it, and serve them (maybe even avoiding turbogears, and get one step closer to get rid of so many dependencies) [02:07] beuno: it's certainly an interesting idea :) [02:09] mwhudson, :) so, my next still is profiling with different templating engines, unless you have a different request [02:10] beuno: i think that's sensible yes [02:24] what should I do to work around this? bzr: ERROR: Repository KnitPackRepository('file:///home/jml/Code/gtimelog/.bzr/repository/') is not compatible with repository SvnRepository('http://mg.pov.lt/gtimelog/svn') [02:25] oh, I see, there's a Subversion repo format now [02:26] has that always been there? [02:28] jml: bzr-svn? [02:28] Peng: yes. [02:28] jml: I dunno. It's been there as long as I can remember, but that's only a few months. [02:34] The Bazaar slogan should be "Make like a tree and branch" [02:35] jml: probably "bzr upgrade --rich-root-pack" [02:40] rockstar: Heh. [02:41] rockstar: I'm not sure that's a very good slogan, but I definitely like it. :) [02:42] Peng, what's so bad about it? :) [02:45] Wait a minute. Slogans don't need to be a pile of information. Never mind about not thinking it's a good slogan. :) [02:45] But it could say more about bzr's focus. [02:46] the error I get now is: http://pastebin.ubuntu.com/14954/ [02:47] SubversionException: ("REPORT request failed on '/gtimelog/svn/!svn/vcc/default'", 0) [02:49] jml: random guess: retry [02:51] spiv: it's happened 3/3 times [02:53] jml: bzr -Dtransport -Dhttp perhaps. [02:53] jml: but basically I think you're in bug report territory. [02:53] ok. [02:54] I'm using whatever bzr-svn that 'bzr branch lp:bzr-svn' gives me. Is there another branch I should be using? (maybe the one called 'trunk'?) [02:55] jml: Try using a release. (bzr revert -r tag:bzr-svn-0.4.10) [02:58] abentley, I sent a merge request which was rather large (1.7mb), and it seems BB hasn't picked it up yet. https://lists.ubuntu.com/archives/bazaar/2008q2/042455.html [02:59] jml: I strongly recommend sticking to released versions, or at least the "stable" branch. [03:00] spiv: it's not clear what the "stable" branch is, looking at lp.net/bzr-svn [03:01] There isn't a stable branch, really. [03:01] 0.4 is the stable branch [03:01] (most of the time) [03:02] Yeah, but wasn't it unstable from 0.4.9 to 0.4.10? Like, for 6 weeks? [03:02] yeah, it tends to regress from time to time [03:02] I run bzr.dev, but bzr-svn 0.4.10. [03:03] at the moment, the 0.4 branch passes all tests though so it should be considered stable [03:10] jelmer: does http://pastebin.ubuntu.com/14954/ [03:12] jml: hmm, that is a regression [03:13] I have a local clone of gtimelog here made with an earlier release of bzr-svn [03:13] unfortunately the testsuite doesn't catch this as we don't test svn over http (because it requires setting up apache) [03:14] that shouldn't matter as the subversion libraries promise one API for all three protocols, but there are subtle differences [03:14] jml: please file a bug [03:14] jelmer: will do. === mwhudson__ is now known as mwhudson [03:31] Is there a trac equivalent for bazaar? I found the bzr-trac plugin, but I wondered if there was something different [03:55] chmac: there's also 'cart' [03:56] poolie: Sweet, thanks, I'll check it out [03:57] poolie: Any idea how far along it is? [03:59] given a .bzr repository, is it possible to find out what branches are in it? [04:02] uniscrip1: You can use the heads plugin to see the current heads. [04:12] Thanks for that. I notice that if I delete subdir branches from a repo they become dead [04:12] is there any way to revive them? [04:13] uniscrip1: Find the revid, and bzr branch -r revid:... [04:15] * igc lunch [04:16] Peng: returns "ERROR: Not a branch" [04:16] uniscrip1: You need to do it from a branch. [04:16] and lists the path to where I want to put the new (old) branch under the repo [04:17] I have a repo with a bunch of dead branches how do I revive one (get it out into a full branch)? [04:17] if I have no branch how do I 'do it from a branch'? [04:19] cd /repo ; bzr branch -r revid:23890174kj234h1k2j34hk1l24h12kj4123l47897 /somewhere/to/put/it [04:20] bzr branch -r revid:mhosken@sil-mh4-20080527025333-o3z49yp16xykkwg6 ../test_branch [04:20] bzr: ERROR: Not a branch: "/home/mhosken/Work/dev/shorts/repos/repo_test/test_branch/". [04:20] same if I change ../test_branch to fred [04:20] or . fred [04:21] bzr 1.3.1 btw [04:22] oops [04:23] Ideally that should work. Probably worth a bug report. In the meantime, do it from any branch in the repo (even if you just create an empty one with "bzr init"). [04:24] OK. Thanks for that [04:45] beuno: Appears to have been caught by my spam filter. I don't get much legitimate email in spanish. [04:52] abentley, lol, understandable [04:52] beuno: I should have it processed in the next few hours [04:53] abentley, thanks [05:52] * igc pick up kids [05:55] beuno: so i checked out the latest version of your branch, it looks fine [05:56] well, apart from using log._strip_NULL_ghosts [07:21] "bzr check" has been stuck in "checking versionedfile" for several hours. Should I leave it for a couple days? ;) [07:26] Rhamphoryncus: how big a branch is it, and how are you accessing it? [07:27] previous step said 40000. Fairly large project [07:28] local files [07:32] oh, current step says 0/10727 [08:35] * igc dinner === yacc_ is now known as yacc [10:32] * gour likes --lightweight checkouts with treeless repo and using 'switch' to change working branches [10:43] gour: is there a good description of that online somewhere? [10:43] Jc2k: see paragraph in http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#checkouts section [10:45] gour: can this work like Gits branches? or is there still a directory for each branch? [10:45] Jc2k: i created (for a test) shared repo (--no-trees), then one branch within it and then did some 'hacking' in another dir after checking out. created another 'feature' branch and then was able to 'switch' between the two. [10:46] Jc2k: no idea. git is not on my todo list...i'm coming from darcs [10:46] Jc2k: still one directory per branch, but you normally don't see those directories [10:46] Jc2k: there is only one 'working' directory and bzr switch populates it with appropriate working tree [10:47] background here is that i'm wanting to extend the Bazaar/GNOME documentation, and Git people cite this as something important to them [10:47] luks: where would the directories be? [10:48] repo/branch1, repo/branch2, repo/working_copy ? [10:48] repo/working can be anywhere === weigon_ is now known as weigon [10:49] Jc2k: anywhere under the shared repository [10:49] Jc2k: you can put them to a dotted directory and never see them [10:50] so i could: [10:50] bzr init-repo . [10:51] bzr branch some/branch . [10:51] whoops [10:51] i meant [10:51] bzr branch some/branch .branches/trunk [10:51] bzr co --lightweight-command-foo .branches/trunk . [10:51] so the repo and working copy are in same folder [10:52] you can do that, but it's probably not the best layout [10:52] better to have the repo with branches outside of the working copy [10:52] Jc2k: i'd keep working dir out of shared repo [10:52] i agree [10:53] the git people likely won't buy it, though :) [10:53] Jc2k: you buy it ;) [10:54] it would be nice for jhbuild integration their way, though [10:55] any news about emacs' adoption of bzr? [11:01] its integrated into it already ? [11:01] at least i can use it easily [11:02] well, except for diffs [11:02] gour: nothing yet. I think they are waiting on savannah and a couple of specific performance improvements. [11:03] jml: let's hope it will happen soon [11:03] trepca: I use dvc in emacs with bzr and use it to get diffs all the time. [11:05] oh! [11:05] how did you install it [11:06] i use aquamacs [11:06] didn't manage to get it working [11:06] trepca: I just dropped it into my load-path [11:07] damn [11:07] (load-file "/home/jml/Code/dvc/++build/dvc-load.el") [11:07] trepca: I just have that in my .emacs [11:07] trepca: and followed whatever build instructions were in the tarball. [11:08] is aquamacs any good? [11:08] i've always been quite suspicious of it on principle [11:09] hm, there is not dvc-load in my tarball [11:09] aquamacs works great for me [11:11] jml: btw, where did you get the tarball ... seemed to me that you can only checkout the source form the DVC site [11:12] hmm, i put: checkout=checkout --lightweight in ALIASES section of conf file. however, if i use bzr co it is not in effect although i might expect it to be? [11:12] trepca: by "tarball", I meant "checkout" it appears. "bzr branch http://bzr.xsteve.at/dvc/" [11:14] mhm [11:16] trepca: I just pulled the latest -- './configure; make' builds a dvc-load.el in the top-level directory for me [11:25] woohoo! works! [11:25] thanks! [11:43] jml: how do you view the log with dvc ? [11:44] trepca: uhh, I don't generally. [11:44] ok [11:45] hey jml [11:45] james_w: hi [11:45] did you get back ok? [11:45] james_w: sorry I had to bolt before your set the other day [11:45] no problem. [11:46] james_w: yeah, I got back fine. Had to fight a couple of bears to get past the checkin desk, but that's no big deal [11:54] jml: what about creating diffs with another revision...not head [11:54] trepca: I use the command line for that too :) [11:55] trepca: basically, both of those ops are outside my normal dev cycle. [11:55] trepca: so I don't mind switching out of emacs [11:55] so what is the purpose of dvc then :) ? === sabdf1 is now known as sabdfl [12:56] * gour is fetching emacs from bzr repo === Pilky_ is now known as Pilky [13:36] Last night I asked about the Python installers for bzr/win32 : since I had most of the dependencies anyway I built my own ; would they be wanted/trusted for the downloads page? [13:55] awilkins: I'm not sure, though I don't see why not. [13:55] perhaps mailing to the list first would be a good idea. [14:02] Hey guys, I'm trying to push to launchpad, but I keep getting a message about being unable to obtain a lock, and that it's help by me on "host vostok" [14:02] how can I get rid of that lock, and why did that happen [14:08] lamalex: bzr break-lock [LOCATION] [14:16] merci beaucoup [14:32] is there a way to check if it's locked? I just tried to push again and it still said it was locked === kiko-afk is now known as kiko [14:44] lamalex: launchpad is a bit weird here [14:44] you probably need to run the break-lock command a few times. [14:45] and use sftp:// rather than bzr+ssh:// as well I believe. [14:47] * bimberi takes note - for next time :) [14:47] weird [14:47] I'll try that [14:47] it's not even showing up as locked in bzr info [14:48] so just s/bzr+ssh/sftp [14:49] iirc you need to run break-lock twice [14:49] and it doesn't matter if using sftp or bzr+ssh [14:52] Is that a bug? [14:53] don't know [14:53] sounds like it [14:54] there we go, it's pushing now. Thanks guys [15:02] * lamalex wants to kill bzr [15:02] It's telling me the branches have diverged, and to merge, but when I do a merge, it says nothing to do [15:03] Are the two branches public, can we see? [15:04] the one branch is local on my hd [15:04] do you want the output of bzr info or somethign? [15:05] It was more for me to try the pull/merge/diverge check [15:05] are you sure you are merging from the same branch you are trying to push to? [15:05] can you please run 'bzr missing url-to-push-location' ? [15:05] I fixed it, I don't know how this happened but it dropped /trunk off of the url [15:07] pushed now :) thanks guys. I really love how helpful #bzr is, compared to many other freesoftware irc channels [15:36] night all === kiko is now known as kiko-phone === kiko-phone is now known as kiko [16:08] why I've to commit to use bzr upload -r [16:08] make no sens [16:09] visik7, please file a bug [16:09] where ? [16:10] https://launchpad.net/bzr-upload I think [16:10] visik7, well, there is a specific reason for that [16:10] ah, well, no [16:10] why ? [16:10] not for -r [16:10] as jelmer says, file a bug, we'll get it fixed :) [16:10] my mistake, misread too fast [16:12] jelmer: I have a small problem with pushing into a svn-tree (bzr-svn 0.4.10) [16:12] bzr: ERROR: Tags not supported by SvnBranch(...) [16:13] $ bzr info [16:13] Standalone tree (format: dirstate-with-subtree) [16:13] weigon: bzr-svn doesn't support tags [16:13] (yet) [16:14] that's fine [16:14] lp: use a specific port ? [16:14] but how can I move in from there ? [16:15] jelmer: looks like this happens at the end of the push [16:16] weigon: you're trying to push a branch with tags into svn [16:16] yep, can I remove the tags somehow and get a successful push ? [16:19] bzr tag --delete [16:21] could you get http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/ working ? [16:21] I can't [16:27] jelmer: thanks [16:29] visik7, loggerhead must be down again [16:30] oh, it's not: http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/trunk/files [16:30] visik7, what are you trying to find? [16:30] pull from http [16:30] 'couse lp: is firewalled [16:30] here [16:33] visik7, try: http://bazaar.launchpad.net/%7Ebzr-upload-devs/bzr-upload/trunk/ [16:33] yes [16:35] visik7, did you get around to filing that bug? I can look at it after work if you do :) [16:36] yes patch added [16:36] check if it's correct [16:36] jelmer: $ for t in `bzr tags | awk '{print $1}'`; do bzr tag --delete $t; done does the trick [16:36] weigon: :-) [16:38] beuno: is ok ? [16:39] visik7, you rock :) [16:39] :) [16:39] it's damn easy with python and bzr [16:39] combo killer [16:39] visik7, do you think you can use bzr send, so you can get attribution for you work? [16:40] yes I maybe need to setup bzr for launchapd [16:42] beuno: commit has an --author option exactly for this :) [16:42] but anyway I'm behind a firewall that suck [16:42] and doesn't work for lp: [16:43] luks, ah, right, thanks [16:43] visik7, I'll use that and make it easier for you [16:43] thanks a lot. You'll see it i trunk in a while [16:45] thanks [16:45] is there a way to commit into a branch only some files ? [16:45] yes [16:45] stupid me [16:49] jelmer: Where bzr-svn has changed it's mind about file-id values is there a way of upgrading a branch to the new file-id mapping? [16:49] awilkins: bzr-svn shouldn't change its mind about file ids, that would be a critical bug [16:49] anybody know why when I commit a checkout to launchpad it doesn't update on the launchpad pages? (does update in loggerhead) [16:50] Pilky, code scanning is behind [16:50] so it will take a while for LP to pick it up [16:50] jelmer: Well then, I think I may have hit a bug.... [16:50] jelmer: What about revision-ids which is what aI actually meant ... [16:51] awilkins: they shouldn't change either, unless you change the branching scheme or are branching from a different path [16:51] which happens rather frequently [16:51] beuno: well it's showing my last commit as revision 9, 3 days ago. I switched to using checkouts with revision 10 and it never updated, and I just commited revision 11 about 10 minutes ago [16:51] jelmer: Ah, I changed the branching scheme, because the structure of the repo was confusing the auto-scheme code [16:51] (revision 10 was committed 2 days ago) [16:54] jelmer: Problem was that I had a vendor-branch folder, which itself was a container for a project/branch tree, as well as a root level project/branch hierarchy === kiko is now known as kiko-fud [17:00] will bzr let me replicate data between two bazaar servers? [17:01] Chris12349: Well, that's what "push" and "pull" are for, but they only operate on single branches. [17:01] Peng: gotcha, thanks [17:37] Pilky, it will get fixed, don't worrk [17:37] *worry === mw is now known as mw|food === kiko-fud is now known as kiko === mw|food is now known as mw [20:22] beuno: good modification to my patch I would suggest it to you [20:23] visik7, you're fast :) [20:23] I thought it would be clearer [20:23] good good [20:24] I hope I got your name right, it isn't very clear in LP [20:24] CamelCase [20:24] :) [20:25] yes, I guessed as much, but I wasn't sure if it was FirstnameLastname [20:25] or the other way around [20:25] the other :P my fault [20:25] aaah, I suspected [20:26] thanks for the bug report/fix, btw [20:27] you know I've never commited a bugreport/fix but with LP and python and bzr it's dead easy [20:27] great tools [21:25] Is there a way to find out the nearest ancestor branch for a branch you're working in? [21:27] Like, I have branch A and then I create branch B from A. And later on inside B I want to do "bzr diff -r ancestor:A" [21:28] I do this type of thing -all- the time, and I don't want to have to type in the URL for A. Is there an obvious way to get that URL from bzr? [21:29] I do it all the time too, where "A" is something like "../otherbranch" [21:29] so it doesn't seem so bad [21:32] Mine is remote, and at the moment I just have a bash script setup to do "bdiff --repo-A" or something to tell it which repo to diff against. [21:33] But I'd rather not even have to do that much by hand.. if I could get bzr to return the nearest ancestor branch then the script could figure out where to diff against for me. [21:33] bratsche: "bzr info" shows the parent branch, btw [21:33] I don't know how to get that out in a simple way to include on the command line [21:33] or to include in `` or whatever [21:33] bratsche: bzr help revisionspec ? [21:33] radix: It doesn't always show it. [21:34] Oh, I want submit: [21:34] I didn't know about that. Thanks. [21:35] Oh, it doesn't seem to always work though. [21:35] np [21:35] you probably need to pull from the remote branch once [21:35] so that it stores the parent branch [21:35] i dont know why parent isnt set when you branch, tho [21:35] bzr: ERROR: No submit branch available for branch "/home/bratsche/bzr/my-branch" [21:36] right. it says it falls back to parent branch. so is there a parent branch in bzr info? [21:36] I'll play with this some more later and see if I can figure out why this is happening. [21:36] No. [21:36]