=== Kissaki is now known as Kissaki^0ff === cody-somerville_ is now known as cody-somerville [00:37] Glenjamin: still having that move problem? [00:37] nah, i figured it out [00:37] although i reckon there's scope to make bazaar smarter about moving directories [00:38] the short version is that you cant move things into a non-versioned directory [00:39] so dir1 => dir2/dir3 doesnt just work [00:43] morning [00:55] What's the status of bzr-tools vs. bzr-1.15? [00:58] nevermind [01:49] lifeless: hi [02:52] Why would bzr (talking to Launchpad) have to do ~ 300 kB of data to transmit a single revision with about 1 lines of changed code in it? [03:03] recent branch format? [03:11] bob2: certainly [03:12] It's been the same for each of several single revision pulls over the last few days. [03:12] I don't normally interact with Launchpad (or use http), so this is all a bit of a surprise. [03:13] But that's where the contributor put their branch, so {shrug} [03:13] I have the opportunity to enjoy the experience. [03:47] is there a way for bzr log to only show the log for the last revision? [03:47] bzr log --limit 1 [03:48] thanks gutworth [04:13] krisfremen: bzr log -r-1 will do the trick as well [04:13] * igc lunch [04:14] hmm, indeed [04:14] thanks [06:25] I have some problem getting the latest from a launchpad bzr branch. I have the error pasted at http://dpaste.com/hold/47393/ any directions? [06:26] profchaos: double check that link [06:30] profchaos: if that is the right one, it's unrelated to bzr, but you need to install cdbs (and build-essential and fakeroot and anything else listed in the Build-dep line in debian/control) [06:31] I'm new to bzr, i might well be wrong [06:32] I mean, check the link to see if it is the one you meant to paste, since it'z not a bzr problem :) [06:32] yes that's my paste for sure [06:32] odd, what was the command line of that paste? [06:33] * bob2 guesses bzr-buildpackage [06:33] ./debian/rules get-orig-source LOCAL_BRANCH=../upstream/chromium-browser.svn [06:34] apt-get build-dep? [06:34] only if the package is in Debian (and has the same build-deps) [06:34] agreed. [06:34] I'm not sure i was trying to follow https://wiki.edubuntu.org/Chromium/Build [06:35] ... interesting ... then why ask in #bzr? ;-} [06:35] I'm just trying to get the current source from lp:chromium-browser [06:36] I don't think that command produced that error [06:36] more likely the next one [06:37] @bob2 normally, how do we get the latest of a bzr launchpad branch? [06:37] what? [06:37] 'bzr branch lp:whatever' [06:38] let me try that now [06:38] qanyway, if the instructions don't work, best to contact the people who wrote them [06:38] yeah, the instructions obviously don't work on your system. [06:40] @bob2, bzr branch lp:chromium-browser seemed to work. it copied some files to my system now, but i see just a couple of files in the target folder. [06:41] as above [06:41] bzr got you the files you asked for - anything beyond that is up to the scripts you're running [06:41] it could potentially bea problem in bzr-buildpackage, but you'd need to pastebin your shell session [06:43] okay, let me check what else has gone wrong [06:43] thanks anyways [06:44] ls [06:54] guhi [06:54] lifeless: back to work [07:13] hi lifeless - morning! [07:14] hi [07:15] we should have sprint stuff happening in a few hours at most === abentley1 is now known as abentley === jml changed the topic of #bzr to: Bazaar version control system | 1.15final released 22 May, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | Sprinting in Barcelona [08:12] Peng: of course, what we need is a generic transport-to-http adapter :) :) [08:16] Hi All [08:16] I have a question [08:17] Hi Youssef [08:17] it is about the bzr add command [08:17] check this [08:17] === modified file 'index.html' [08:17] --- index.html 2009-05-13 11:38:13 +0000 [08:17] +++ index.html 2009-05-22 19:18:00 +0000 [08:17] @@ -1,1 +1,2 @@ [08:17] Hello World!!! [08:17] +"I'm a new line" [08:18] what does mean @@ -1,1 +1,2 @@ [08:18] mwhudson: Serving a remote branch would be terribly inefficient, though. [08:18] Youssef: it's a diff [08:19] yes but [08:19] Peng_: pfff, such a boring objection [08:19] Youssef: That line shows the location of the change in the file. [08:19] Youssef: it is indicating where in the file the edit is (line 1, in this case) [08:19] but i see -1,1 +1,2 [08:19] mwhudson: :D [08:20] Youssef: And? [08:20] precisly what is it [08:20] Youssef: http://www.artima.com/weblogs/viewpost.jsp?thread=164293 [08:21] bob2: Thanks [08:21] guys im making a user guide of bzr for windows in french [08:21] im contributing in hehe [08:45] bbiab [08:57] * igc dinner - bbl === ja1 is now known as jam [10:03] beuno: Got logerhead branched. ./serve-branches works. What was the other was to serve? [10:09] GaryvdM, ./start-loggerhead [10:09] but it's complicated [10:10] and the fix is 'bzr rm' [10:11] :) [10:11] soon [10:11] maybe this sprint [10:11] after this session [10:11] I'm hiding in the bzr room [10:11] find me a good place to hide [10:11] yeah, good luck with that [10:11] you can probably go behind the screen [10:13] beuno: so ./server-branches is what I should use? [10:13] GaryvdM, yes [10:37] bbiab [10:54] beuno: how outrageously booked are you today? [10:54] mwhudson, I'm on my way NOW [10:54] beuno: that's not actually an answer to my question :) [10:57] mwhudson, I will try to spend 50% of my time with you guys [10:57] at least 50% [10:57] beuno: cool [10:59] abentley: ping [11:04] hi igc? [11:05] igc: notes from our session in here http://bazaar.launchpad.net/~bzr/bzr/devnotes/changes [11:11] LarstiQ: ping [11:13] hey folks - is bzr a good candidate for a small workgroup managing a set of OpenOffice.org documents and some maps in .jpg? I'm interested in how it deals w/ blobs. [11:19] gkahla: Current disk formats do line-based deltas, so storage efficiency might not be ideal, but it will work fine. [11:20] gkahla: Aside from that, you obviously won't get the benefit of looking at diffs, and merges will be more manual, but you can do it. [11:20] Peng- it'll be a 4 ~ 5 person group, so merges are not critical [11:21] i'll just smack the appropriate person with a hammer [11:21] so long as I could "roll back" to a previous version of a given .odt, that's really all the functionality I need at this point. [11:21] thanks for the feedback, Peng [11:22] poolie: commit & push please [11:23] thx folks - later [11:50] poolie: M-x insert-table >:) [12:06] lifeless: Just kept my side of the bargain. Patch for ppa.txt and tools/packaging/* just emailed [12:07] poolie: thanks [12:37] poolie, lifeless: I'm heading off for the night [12:37] Hi Ian [12:38] igc: g'night [12:38] I've emailed the list with what I'm working on in case anyone wants to tweak those [12:38] I think poolie and lifeless are still at lunch [12:38] hi jelmer. How are you? [12:38] Good! Sorry to hear you couldn't make it to the sprint. [12:39] jelmer: me too! It would have been great to catch up [12:40] jelmer: hope you're enjoying the sprint. I'll be back tomorrow. night [12:41] igc: gnight === abentley1 is now known as abentley === abentley1 is now known as abentley [13:45] abentley: you back? === Kissaki^0ff is now known as Kissaki [14:29] johnf: pong [14:30] LarstiQ: will you have time to do create bzr-svn packages? [14:31] johnf: there is a new bzr-svn version? [14:31] * LarstiQ looks at announce [14:31] LarstiQ: I didn't see an annouonce but there is one on the web page [14:31] 0.6.1 [14:33] johnf: it seems so [14:33] jelmer: did you intentionally not announce bzr-svn 0.6.1 on bazaar-announce? [14:34] johnf: I can do it in ~5 hours [14:34] (start on it that is) [14:34] cool. I'm waiting on abentley to surface again so we can get a bzrtools release as well [14:34] johnf: isn't everyone at UDS? [14:35] yes I think so [14:35] except for us ;) [14:37] * fullermd is currently hacking around the missing bzrtools... [14:40] http://projects.serverzen.com/pm/p/cluemapper/wiki/ClueBzrServer [14:55] poolie: ciao; leaving you my double-adapter as I recall your second power adapter doesn't fit the wall sockets. [14:56] * lifeless -> door [15:19] hi guys, I've been looking at this: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style Which workflow do you think is recommended for web development? [15:22] btw hi KX [15:36] if I merge a feature branch into the trunk branch, can I delete the folder with the feature branch? === tchan1 is now known as tchan [15:37] spirov92: If you want to. I don't, though. [15:37] helmer: hi [15:37] sorry [15:37] jelmer: hi [15:38] I've branched svn repo from http://projects.serverzen.com/pm/p/cluemapper/browser/ClueBzrServer/trunk [15:38] I can see the log of the branch [15:38] but when I'm trying to see diff I've got: NoSuchRevision: KnitPackRepository('file:///C:/Temp/ClueBzrServer/trunk/.bzr/repository/') has no revision rocky@serverzen.com-20090226184017-m3cemyrz487uxhg3 [15:39] jelmer: is it known problem or? [16:22] Hi bialix [16:50] How should integration branches be used? When you want to, uh, integrate a branch, should you merge or pull it? [16:51] ISTM both are used by you guys. [16:52] What about "merge --pull"? [16:57] Peng_: merge --pull is a shortcut for 'bzr pull. Oh, it failed, bzr merge.' [16:57] Peng_: or 'bzr pull. It worked' in the other case [16:58] Peng_: integrating will mean, I think, in most cases that the branches are diverged, which would mean merge [17:46] hi! is there a way to preserve the executable bit when committing to a subversion repository? [18:12] servilio: you mean, using bzr-svn? [18:46] LarstiQ: On a slow-paced project, they may not be diverged. [18:59] jml: yes, using bzr-svn [19:00] Peng_: ok, so what is your definition of an integration branch? [19:01] The complement to a differentiation branch. Duh. [19:01] LarstiQ: I dunno. I've never used one. That's why I'm curious! :D [19:01] Heh. [19:01] Yes, that's a better answer. [19:01] fullermd: and indeed, it is! [19:01] * fullermd is full of smart answers. Or smart _something_ answers, anyway... [19:01] to multiple differentation branches though. [19:02] yo [19:02] Peng_: afaik/imo integration becomes interesting when there are multiple differentiation branches you want to incorporate. [19:02] anyone got a quick programmatic way to create a workdir with branch/repo [19:02] Peng_: at the start one of them might not be diverged, but after that all of them are. [19:02] ronny: bzrdir.sprout? [19:03] Ah. [19:03] ronny: or BzrDir.create_branch_convenience? [19:03] LarstiQ: thats new, isnt it? its in my system [19:04] LarstiQ: something like that [19:04] LarstiQ: im just getting started with anyvc's repo/branch stuff [19:05] ronny: lots of the creating/copying of different kind of bzr objects happens in bzrlib/bzrdir.py [19:05] Eh, I'm interested in integration branches because I'd like to make final tweaks to other peoples' branches, without putting them in the top level of history, and using one branch for it would be easier. :D [19:05] LarstiQ: the first looks cry terrrible complicated [19:06] ronny: it is for if you have a bzrdir you want to branch of off (hence, sprouting a branch) [19:06] LarstiQ: i want to make a new one [19:06] ie create a fresh branch [19:08] ronny: import bzrlib.bzrdir; bzrlib.bzrdir.BzrDir.create_branch_convenience('/tmp/new-branch') [19:09] Peng_: 'top level of history'? [19:09] hmm [19:10] * LarstiQ goes get some dinner [19:13] LarstiQ: ok, got it now, thanks [19:13] hmm, still the apis make me cry [19:28] LarstiQ: "bzr log -n 1" [19:30] Peng_: hmm. [19:31] Peng_: in some branch your tweaks will be there. Which one do you envision them not being? [19:31] ronny: especially bzrdir has grown gnarly bits, yes [19:31] ronny: I suppose your anyvc design will be close to what you'd like the interface to be? [19:35] LarstiQ: What do you mean? [19:38] Peng_: I'm not clear on what you're aiming to do :) [19:38] Ehh. [19:38] Peng_: if you say mirror brisbane-core, and then do a commit on top of that, yours will be the toplevel commit there [19:39] so, there then has to be another branch you merge that into for it not to be? [19:40] I want to merge other peoples' branches into the trunk of whatever without polluting the "log -n 1" history with my random review bits and NEWS stuff. [19:40] I can make a branch of the other person's branch to do that, but it would be less hassle and overhead to just re-use one. [19:42] ah [19:42] Peng_: I see what you mean now. [19:42] LarstiQ: i'll try to get anyvc close to a nice interface [19:42] Peng_: I don't know if there is a better term for that, but I'd call it a review branch or somesuch [19:43] LarstiQ: i will publish it as explicitly unstable api, then iterate till im nice with it [19:43] ronny: alternatively, if you can articulate what makes you cry, maybe that can serve as input to reworking things [19:43] * LarstiQ nods at ronny [19:44] ronny: I do hope it will converge :) [19:45] LarstiQ: mostly the amount of words in method names, and the java-style layout of things [19:45] LarstiQ: its python, start to embrace that already [19:46] ronny: it is python afaik [19:46] LarstiQ: OK, that term makes sense. What's an integration branch, then? [19:46] Peng_: an analogue to the -mm linux tree [19:47] Ehh. [19:47] What about in the bzr project? [19:47] ronny: in my experience with both, bzr code style looks nothing like java [19:47] LarstiQ: it still reminds me of many java patterns [19:48] ronny: ok, since I don't see that, can you point out an example and how you would write it? [19:48] Peng_: a branch that collects various other branches [19:49] Peng_: say the old hpss one [19:50] Peng_: trunk/bzr.dev also fit the integration bill, except (I) normally reserve that naming explicitly for non-trunk/pre-trunk staging [19:50] Okay. [19:50] Peng_: the key as fullermd joked, is to bring together various topical pieces of work. [19:50] * Peng_ nods. [19:52] LarstiQ: not sure, bascially get many of the classmethod/staticmethod factories out to some simple paces [19:53] LarstiQ: i'll know better after a few onyvc iterations [19:53] *anyvc [19:53] ronny: ok [19:54] LarstiQ: im kinda scared by the amount of factories [19:55] there are a lot of interfitting parts [19:57] LarstiQ: imho the api is just one order of magnitude too big, hg is a lot closer to what i consider good size of the api [19:58] Thanks for the info, LarstiQ. :) [19:58] well and git is close to what i consider reasons to stab people [19:58] Who needs reasons? [19:58] people that like to act by reason [19:59] needing 3 subprocess calls and lots of guessing what they could have meant with those character combinations just for getting complete enough status data is well - generating hate [20:01] ronny: what are you invoking with subprocess? [20:02] surely git can't be that convoluted? [20:02] I hope? [20:02] LarstiQ: ls-tree -r head, ls-files -c - and ls-files - [20:02] LarstiQ: i need workdir, index and tree data to infer status [20:02] LarstiQ: git is a major pain === krisfree is now known as krisfremen [20:05] bzr-git? [20:05] Or dulwich directly? [20:06] ronny: right, as Peng_ said, would working with the datastructures directly be less painful? [20:09] Peng_: dulwich is incomplete for the task [20:09] and semms to be weird [20:09] +bzr-git [20:29] LarstiQ: also bzr isnt supposed to become a mandatory dependency [20:30] ronny: I agree. If I implied it should that is not what I intended. [20:33] LarstiQ: well, also supporting the vcs implementations of bzr is probably a good thing [20:33] but its not supposed to be the main backend implemenations for other vcs's [20:33] more like nice to have fallbacks [20:33] ah ok [20:37] is there any way I can store the revno in a file, preferably with a hook? I'm guessing a post_commit hook wouldn't work as the revno file would then be outside the current revision? [20:37] I use bzr-upload once committed if that makes any difference [20:38] hi hi [20:38] ronny: you're again talking about anyvc? [20:38] pygi: yeah, finally started with the repository/history stuff [20:39] after some killing fun with git [20:39] vxnick: `bzr version-info`? [20:39] vxnick: Looking for svn-like keywords? [20:39] LarstiQ: ideally I'd like to do it as part of the commit so bzr-upload uploads it to the server with the rest of the changes [20:40] Peng_: that's a good point, there's a plugin for that isn't there? [20:40] vxnick: Yep. [20:40] vxnick: hmm hmm, I guess bzr-upload might have/need support for a processing step prior to deployment [20:41] slightly annoying as it uploads a .bzr-upload-revid file, but that doesn't contain the revno >.< [20:41] vxnick: it has the revid though ;P [20:42] true, but I need the revno for various bits [20:43] hmm [20:43] clients prefer a nice readable number ;) [20:43] anyone aware of a quick way to ask for the amount of revisions in a branch [20:43] ronny: mainline, or all? [20:44] LarstiQ: all [20:44] LarstiQ: im not not sure if i should like or hate the mainline feature [20:44] ronny: like ;) [20:45] LarstiQ: its your right to like it, its mine to evaluate before i decide how much i hate it [20:45] * LarstiQ nods [20:45] hmm [20:45] ronny: I seriously dislike not having it in hg/git [20:45] LarstiQ: im wondering if i sould ad it to anyvc [20:46] it a adapter that views mainlines and pushes merges/branches kind of away [20:46] Quick in what way? Counting the number of revisions would probably be a full-history operation. [20:47] Peng_: in hg its O(1) [20:47] in svn its O(1) [20:47] in git/bzr i might have to cache [20:48] are you sure about svn, now that it has some form of merging? [20:48] How's it O(1) in svn? [20:48] LarstiQ: svn still has linear revision numbers [20:48] ronny: not entirely [20:48] Sure, the current revno is the total number of revisions in the repo, but not the current branch. [20:48] ronny: you can switch heads away from branches in svn [20:49] ronny: but still include revisions as merged [20:49] that aren'y linearly visible in svn log [20:49] oh damn [20:49] hmm, svn really does everything to suck in hellish ways [20:49] ronny: I'll give you it doesn't occur much, since svn itself can't really display it nicely [20:52] ronny: Well duh. What kind of successor would it be to CVS otherwise? :D [20:53] * LarstiQ stares at the thunder and hailstorm outside. [20:53] hmm [20:53] i'll certainly use subvertpy for my svn stuff tho [20:53] aronny: len(branch.repository.get_ancestry(branch.last_revision()) [20:54] ronny: quite a bit slower than branch.last_revision_info() [20:54] LarstiQ: will that make a list? [20:54] ronny: yeah [20:54] ew [20:54] hmm [20:54] seems like hg is the only one able to give me O(1) there [20:54] last_revision_info() on the other hand will read a number from disk [20:55] and is O(1) [20:55] hmm, waht is last_revision_info? [20:55] ronny: revid, revno tuple [20:55] oh, other order [20:56] ronny: so yeah, mainline [20:57] hmk [20:57] hmm, well, hg is better at whole repo ops [20:58] mainlines would be expensive there [20:59] ronny: yeah, hg's repository plays a role more on the frontlines [21:00] hmm, i developed a general preference for hg, it does things more simple and faster [21:00] there is something to be said for that [21:00] * LarstiQ still has to get to grips with it's ui [21:03] some things about mq are a bit unfortunate, but thats about it [21:04] hg's codebase it a lot better for getting into it than bzr's [21:27] ronny: hi [21:28] ronny: what's weird about dulwich? [21:28] I think he meant bzr-git is weird [21:31] ah, ok [21:35] jelmer: dulwich is pretty ok, just not yet ready for my needs [21:35] jelmer: bzr-git is well, wkinda weird [21:37] ronny: weird for anyvc to use? (I'd agree on principal) or weird in general? (I don't know the code) [21:39] hi jelmer, poolie [21:39] others :) [21:39] LarstiQ: weird in general, when i last tried it with bzr it was all weird [21:42] ronny: k [21:42] hi jelmer, pygi, poolie1 [21:42] this was the first day? [21:42] LarstiQ: yup [21:42] how was it? [21:43] pretty good, I even got some work done :P [21:43] too bad windows is so broken, so there are all sorta weird bugs :-/ [21:44] hello LarstiQ, it was good [21:44] pygi, poolie1: good to hear [21:44] * LarstiQ wouldn't mind a blog post ;) [21:45] LarstiQ: I think poolie microblogged everything [21:45] does that counts? :p [21:46] Oh? URL? [21:46] pygi: maybe if I knew where to find that :P [21:46] (Eh, I guess that's what the search pages are for.) [21:47] LarstiQ: http://twitter.com/sourcefrog [21:49] pygi: thanks. I wonder if I could fit this into identi.ca somehow [21:50] LarstiQ: he also has an identi.ca acc :P [21:53] http://identi.ca/sourcefrog fwiw [21:55] * LarstiQ subscribed [22:06] sigh, I botched that slightly [22:06] * LarstiQ goes to bed [22:11] ronny: ah, right [22:11] ronny: bzr-git is about as weird as hg-git I would expect :-) [22:12] ronny: The working tree status update stuff will be introduced at some point, when I get around to improving the speed of "bzr st" [22:13] * knielsen hopes this bug doesn't mean our trees are corrupted: https://bugs.launchpad.net/bzr/+bug/375898 [22:13] Ubuntu bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [Undecided,New] [22:14] knielsen: I think I have seen that bug report before somewhere [22:15] jelmer: not sure, hg git seems to do fine as it doesnt enable support for git workdirs/repos, just communication to them [22:15] at least thats my understanding [22:20] ronny: How is that less weird though/ [22:20] ? [22:30] jelmer: the really weird behaviour i kinda saw was when running bzr commands within a git dir, i cant recall it atm and i wont reinstall [22:30] hmm [22:31] is there a way to use bzrdir create_branch_convience and get a branch back? [22:31] or should i just add an extra open_containing? === Kissaki is now known as Kissaki^0ff [23:38] morning [23:52] hi Ian