[00:00] It might be easier to throw in some sort of JavaScript syntax highlighting. [00:01] yeah, I toyed with that too, but it was too hard on thw browser [00:01] I keep on wanting more and more to develope a "loggerheadlib" [00:01] from scratch [00:01] and start building on top of that [00:02] something that spits out html or json [00:02] and then possibly have multiple frontends to that [00:02] bzr branches have metadata, right? [00:03] epsy: What do you mean? [00:04] sorry, that's the wrong way to ask my question [00:05] Can I retrieve info about a branch, such as remembered pull location or parent branch location in a way that's easily readable by a machine? [00:05] epsy: It's stored in the .bzr/branch files [00:06] Or in ~/.bazaar/locations.conf. [00:06] epsy: The best bet is running a bzr command and parsing the output [00:06] Or using bzrlib. [00:07] davidstrauss, meh :\ [00:07] epsy, if you're in python, you can get it through bzrlib [00:07] if not, you also have the xmloutput plugin [00:07] I'm in bash [00:07] bash can run Python. :D [00:08] so I can use grep/awk/sed, but an easy way would have been nicer(to me and to the aspect of the code) [00:08] epsy: In that case, I would implement a large set of shell scripts that transparently replicate and reimplement Bazaar's capabilities [00:08] epsy: But only for repo versions .92 and newer [00:09] epsy: Supporting anything older with bash-bzr would be ridiculous [00:09] would you? [00:09] I'm kidding :-) [00:09] But I've seen some pretty ridiculous shell scripts [00:10] Is awk turing-complete? Could we rewrite bzr in it? [00:11] All repo database manipulations would be written as sed regexes [00:11] (And by "we" I mean "someone completely insane".) [00:11] ("who is not me") [00:12] Peng: You haven't ruled out that you're completely insane; you'd only established that, despite your potential insanity, you wouldn't write bash-bzr [00:12] you've* [00:12] Peng: But what about in Windows PowerShell? [00:12] I like to think I still cling to a few...somethings of sanity. [00:16] Who is it that tries once in a while to use bzrlib in perl via Inline::Python or something? [00:16] * fullermd always finds that really neat. === pmezard is now known as pmezard|afk === Quadduc1 is now known as Quadduc [00:47] hey james_w, do you expect to have any time soon to review my branch? [00:48] hi rexbron, I'll do it tomorrow. [00:48] rexbron: thanks for the reminder [00:49] what can I use with bzr log --log-format= ?? [00:55] epsy: by default "line" "log" and "short", but plugins can add others [00:55] oh, that was the purpose, heh [00:56] how would one count how many revisions, including merged revisions are in a branch? [00:57] "bzr revision-history | wc -l" perhaps [00:58] "bzr log | grep " *revno:" | wc -l" [00:58] bzr log | grep -P '^ *revno: [0-9]+$' | wc -l [00:59] that's what I came up with, but it can be spoofed [00:59] yeah, not sure if "revision-history" lists merged revisions [00:59] it does not, sadly [00:59] even with -v [01:00] try bzr info [01:00] perhaps with -v [01:01] the repo part shows something that seems to be a correct number, but it probably wont be on other configurations [01:01] yeah, it's for the repo, so it's not what you want [01:02] a couple of lines of python would do it [01:02] heh [01:03] would a couple of lines fit into one line ? [01:03] it could [01:04] right, I'll dig the bzrlib doc then..where is it? [01:04] http://starship.python.net/crew/mwh/bzrlibapi/ this? [01:05] yep [01:06] you need to use Graph methods, using the graph from the repo, and the tip revision of the branch as a starting place [01:06] and keep a set of visited revisions, and walk the graph [01:06] graph ? tip revision? [01:06] it might be a very long single line :-) [01:06] ah [01:06] heh [01:07] hm, at that rate I'll still be in bzrlib's doc tomorrow [01:07] I'll head for the spoof-able way [01:08] (in the secret hope a perfectionnist comes around and fixes it) [01:12] hrm, -d is lacking on bzr missing [01:14] epsy: "bzr ancestry | wc -l" maybe [01:16] spiv, ah, exactly! [01:31] I still don't understand why `bzr info -v` doesn't report that number instead of the number of left hand revisions. Since the revno is the latter, it's really quite silly to report the number again, and meanwhile everyone wants to know the former. [01:40] * fullermd blames the gnomes. [01:55] what does bzr missing return when you use --this and there are missing revisions(on but not on ) ? [02:31] Stupid question, when bzr says "parsers.expat", what package is it referring to, as in: mcfletch@sturm:~/OpenGL-dev/simpleparse$ bzr ls [02:31] bzr: ERROR: No module named parsers.expat [02:31] You may need to install this Python library separately. [02:35] I'd thought it would be python-xml (on Ubuntu), but that doesn't eliminate the error. === thumper_laptop is now known as thumper [11:17] hi there [11:18] if I do a bzr merge, but then want to revert it, how do I do that? I see that bzr revert still leaves me with a "pending merge" === asac_ is now known as asac [11:20] ah, running bzr revert a second time has done the trick [11:20] ignore me :) [11:25] mdke: bzr revert with no arguments will revert pending merges (and changes to files) [11:25] mdke: you can also do "bzr revert --forget-merges" [11:29] spiv: yeah, the first time I ran it I had done "bzr merge .", which i guess is why it didn't revert the merge, but only the files [11:43] mdke: right === fawek_ is now known as fawek [12:56] hey..still working out stuff with bzr.. [12:56] I'm setting my branches to use a shared repo [12:57] but somehow, when using bzr reconfigure --use-shared, it tells me both repositories(branch's personal and shared) aren't compatible: [12:57] bzr: ERROR: KnitPackRepository('file:///home/epsy/CODE/armagetron/.bzr/repository/') [12:57] is not compatible with [12:57] KnitPackRepository('file:///home/epsy/CODE/armagetron/0.2.8/.bzr/repository/') [12:57] different rich-root support [13:05] LarstiQ: any idea where jelmer is? [13:09] ronny: no, his server froze on the 31st, I would have expected him back by now [13:09] ronny: but maybe he is also suffering from a case of the flu [13:10] hmk [16:19] i'm getting "no repository found" when i try to add the bzr-eclipse update site to eclipse 3.4; what's going on? [16:22] Hi - I'm having trouble getting bzr to notice BZR_PLUGIN_PATH. [16:22] see http://pastebin.com/d38d129ee [16:22] I'm must be making a mistake some where. [16:24] garyvdm: This isn't really an answer, but I'd just put a symlink to the plugin in ~/.bazaar/plugins. [16:25] The reason I want to change it is I want to test some changes I'm making to bar-upload, with out affecting my installation. ~/bzr-upload/wd/upload is my test area. [16:26] *bzr-upload [16:26] export BZR_PLUGIN_PATH=... [16:27] without export it sets it only for the current command, which is nothing [16:27] Oh - thanks [19:59] have a question... how to continue a new branch creation [20:00] i was downloading the mysql source from bazaar [20:00] and it got interrupted in between [20:00] i have already downloaded 300mb ... dont want to redo it again [20:02] this is the command and its output [20:02] $ bzr branch lp:mysql-server/6.0 mysql-6.0 [20:02] bzr: ERROR: Target directory "mysql-6.0" already exists. [20:08] virtuoso015: cd into your branch and then pull. [20:08] cd mysql-6.0 [20:08] bzr pull [20:09] it is saying that its not a branch [20:10] bzr: ERROR: Not a branch: "/mysql-server/mysql-6.0/.bzr/branch/". [20:11] Is mysql-server a shared repository? [20:12] sorry, i am a beginner at this... [20:12] although i can tell you the command i have used [20:12] Ok no problem. [20:12] Give me a sec. [20:12] shell> mkdir mysql-server shell> bzr init-repo --trees mysql-server Once you have an initialized directory, you can branch from the public MySQL server repositories. To create a branch of a specific version: shell> cd mysql-server shell> bzr branch lp:mysql-server/6.0 mysql-6.0 [20:12] sorry... let me format that [20:13] shell> mkdir mysql-server [20:13] shell> bzr init-repo --trees mysql-server [20:13] shell> cd mysql-server [20:13] shell> bzr branch lp:mysql-server/6.0 mysql-6.0 [20:13] Ok - mysql-server IS a shared repository [20:14] meaning it can store more than one version of mysql at a time ?? [20:14] virtuoso015, meaning that if you branch again, it will probably only bring in the revisions you don't have [20:15] You can delete /mysql-server/mysql-6.0 and then branch again [20:15] a shared repo is a common database of revisions, indipendant of branches [20:16] You won't delete the data allready downloaded, because it is stored in mysql-server/ [20:16] i seem to have a very big file , of size 300 MB, in /.bzr/repository/upload [20:16] its a .fetch file [20:17] oh... ok. So, all i need to do is to delete the mysql-6.0 folder [20:17] Just a sec [20:17] and redo the branch command again ?? [20:17] no prob [20:17] What is the full path to that 300mb file? [20:18] ./mysql-server/.bzr/repository/upload [20:18] mysql-server is in my home directory [20:19] Ok - I just wanted to check that it was not in the /mysql-server/mysql-6.0 dir. [20:19] so, i now delete the mysql-6.0 dir and retry ?? [20:19] Yes [20:20] I'm not 100% sure if it will continue with that .fetch file. I think it will. [20:20] It won't redo the other data that was downloaded. [20:21] ok... the command is working [20:21] the progress bar has not yet come [20:22] Maybe someone else can let us know if it will continue with the .fetch file. [20:22] ok, it seems to be working [20:23] the size of the .fetch file hasnt diminished [20:23] and the progress bar is starting from half way [20:25] hmmm... it seems to have created a new fetch file [20:25] lets see how this goes [20:26] I've been checking out the annotate of the code to see who might be able to answer, and none of them are here :-( [20:27] no problem... live and learn... or is it, screw up and learn :D [20:28] Yhea === fawek__ is now known as fawek === fawek_ is now known as fawek [22:04] is it safe to use 'bzr branch' as an import method? eg, branch and then delete the origin? [22:06] yes, but it will only contain comitted stuff [22:06] A branch is a complete copy of all history, yes. It doesn't refer to the origin [22:06] AmanicA: eh? [22:06] I normally have suff in there which I don't commit. [22:07] well, in this case, the origin is svn [22:07] like ide files [22:08] also I normally don't delete anything without making a backup [22:53] how can I specify the format of a branch? [22:57] bzr upgrade [23:00] garyvdm: can't do it at branch-time? [23:00] why does bzr tell me --dirstate-with-subtree is deprecated? [23:00] is there a replacement? [23:02] luke-jr: You can't do it at branch time, which I find irritating. [23:03] another question, slightly off-topic: can I have Launchpad automatically pull from a parent branch? [23:07] dirstate-with-subtree: [23:07] This format was introduced as a hidden format in Bazaar 0.15. It is an experimental format, not recommended for use. [23:07] (http://bazaar-vcs.org/BazaarFormats) [23:07] d-w-s is a knit format, so yeah, it's old and deprecated. [23:08] sup jelmer [23:09] jelmer: whats the state on your leak-free svn bindings - i could really use them in anyvc [23:10] luke-jr: to have launchpad pull your branch: https://code.launchpad.net/+code-imports/+new [23:13] garyvdm: any idea if that has bzr-svn? [23:13] garyvdm: dirstate-with-subtree is about the only format I could find that supports nested trees [23:13] fullermd: can you recommend another one? [23:14] Well, there's a pack subtree variant. [23:14] is there? [23:15] pack-0.92-subtree [23:17] wait, pack is > dirstate? [23:19] mu [23:19] In this sense, yes. [23:20] dirstate = dirstate + knit [23:20] pack-0.92 = dirstate + pack [23:20] pack > knit [23:20] Hope that makes sense [23:21] i c [23:22] is pack-0.92-subtree as tested as dirstate-with-subtree ? [23:22] Well, I suspect the answer is "yes", but I'm not sure how much comfort can be drawn from that ;) [23:23] grr, it says pack-0.92-subtree is deprecated too [23:24] and pack-0.92-subtree is broken -.- [23:31] or maybe nested trees is just broken in general ☹ [23:41] luke-jr, right, bzr doesn't really support nested trees [23:41] beuno: why not? [23:41] it was working in 0.4… [23:42] it's also a very necessary functionality [23:43] 0.4? [23:43] 0.4? [23:43] * fullermd winz! :p [23:44] damn! lost the first round of the year [23:44] bzr has never _supported_ nested trees. It's always been a half-formed future feature. [23:44] That's why the formats are squirreled away in a dark corner. [23:44] ah, maybe he means bzr-svn? [23:45] Oh, that could be. [23:45] beuno: no, I mean bazaar I think [23:46] luke-jr, I hope you don't [23:46] There was never a bzr 0.4. [23:46] oh :/ [23:46] It went from 0.1.1 to 0.6 [23:46] so what do I do if I need nested trees? :/ [23:47] use Subversion? [23:47] talk to LarstiQ ;) [23:47] I think then you bug LarstiQ; he was the last one that touched it. [23:47] LarstiQ: hi? [23:47] 1-1 [23:47] Blast! [23:47] He may have a branch around that's more solid; not sure. [23:48] a branch :x [23:48] * luke-jr DOES want other people to be able to checkout his code [23:48] Pfft. Other people just cause problems. [23:48] luke-jr, if you where using nested trees, then you where using bzr-svn [23:49] beuno: oh? [23:49] which also went recently from 0.4 -> 0.5 [23:49] Why, I've got all sorts of programs that were totally bug-free until other people starting using them... [23:49] nested trees don't exist w/o bzr-svn? [23:49] luke-jr, I suspect that's the reality, but only jelmer can confirm that [23:50] Er, no, just that bzr-svn is the primary reason anybody ever used a subtree format (and shouldn't be nowadays anyway) [23:50] fullermd: how about a real need for it? [23:50] my project uses code from 2 other repositories [23:50] Nested tree support has never existed beyond a few low-level bits with a molecularly-thin UI on top of them. [23:50] luke-jr, the answer always ends up with [23:50] fullermd: it seems to be working, except for checkouts [23:50] Well, with a real need for it, you need the actual feature, not just the format. [23:51] "bug LarstiQ" [23:51] fullermd: yes, I do [23:51] A lot of the low-level stuff was written. The higher-level glue, UI, polishing, etc, hasn't been done. [23:51] that's fine [23:52] my only requirement is that it works for third-party checkouts [23:52] Well, no, it's not fine. It _doesn't work_. It's never worked. First steps were taken, and nobody has had the combination of interest and time to finish it. [23:52] sigh [23:53] There's a fair continuing current of interest. It's not like we _want_ it to be sitting around teasing people. [23:53] Just that it doesn't top anybody's priority list, so it sits around not really moving. That's why it's hidden. [23:55] AFAIK, LarstiQ _is_ still working on it, but he's had something approaching 0 time for the last $WHILE. [23:55] sigh [23:55] so a Makefile that fetches the subtrees for now? ☹ [23:56] luke-jr, or maintain all of them in the same tree [23:56] beuno: the subtrees are from different projects [23:56] luke-jr, it's still legal... ;) [23:57] …