[00:07] Done. [00:12] awmcclain: thanks :-) [00:15] New bug: #216542 in bzr "unable to do merge on windows" [Undecided,New] https://launchpad.net/bugs/216542 [00:16] New bug: #216541 in bzr "bzr mv dies when using a checkout over http://" [Undecided,New] https://launchpad.net/bugs/216541 [00:29] Hey guys, I'm using Bazaar on Ubuntu 7.10. I'm trying to use the gui (Olive) to view a diff of a file, but the diff window simply shows up blank [00:29] Linnk: how are you using it exactly? [00:30] I click the file I want to see a diff for and click the Diff button in the toolbar [00:31] I figured that I would then be asked which versions to diff, but apparently not [00:36] Linnk: I think that just checks what changes there are in the working tree [00:36] so on a fresh checkout it's correct the window is empty [00:37] ah yeah, that explains why it suddenly works now that I've changed some files [00:38] so I'll have to use the terminal for diff's between revisions? [00:47] Linnk: You can use "bzr viz" to find a revision to show the diff for [00:48] jelmer: Ok, thanks a lot :) [01:28] Guys! How do I change the "remembered location" of a branch so I don't have to specify it on every "bzr merge" call? [01:30] awmcclain: use --remember [01:30] s/awmcclain/antoranz/ [01:31] antoranz: or edit .bzr/branch/branch.conf [01:31] what does bzr bind do? [01:32] jelmer: what you said worked. Thanks [01:33] binds a local branch to a remote one [01:33] making it a checkout (ie commits go to both immediately) [01:36] ok [02:06] New bug: #216586 in bzr "annotate removed-revision feature" [Undecided,New] https://launchpad.net/bugs/216586 [02:10] I'm really at a loss here... I cannot get the bzr-email plugin to work for the life of me. No log entries, nothing. I'm flummoxed. [02:19] awmcclain: What did you do to set it up? [02:27] jelmer: I've installed the plugin into my site packages. I've verified that it shows up until the bzr commands [02:27] ... [02:27] and [02:28] I've set the post_commit_to config variable in the branch.conf, and in ~/.bazaar/.bazaar.conf [02:30] awmcclain: it shows up in "bzr plugins" you mean? [02:30] correct [02:31] i can also do bzr help email [02:31] what os are you on? [02:31] ubuntu gutsy [02:31] it iddn't work in 1.2, and still doesn't work on 1.4r1 [02:32] what should my config file look like, do you know? [02:32] i have [02:32] [DEFAULT] [02:32] post_commit_to = admin@fluther.com [02:34] yeah, that should be sufficient I think [02:34] running bzr commit doesn't trigger it? [02:46] New bug: #181534 in bzr-svn "Discards credentials specified in URL" [Medium,Fix committed] https://launchpad.net/bugs/181534 [03:54] if i have bzr 1.3 installed what repo format should i use? [03:54] it seems to default to pack [03:54] the default, unless you have some special requirement (e.g. working with branches from svn) [03:54] bob2: thanks! [03:55] New bug: #216614 in bzr "should not immediately abort of .bzr/format can't be opened" [Undecided,New] https://launchpad.net/bugs/216614 [03:59] there is an annotation cache, right? [03:59] does it get corrupted? if so, how do you force it to be regenerated? [04:00] AfC: not (yet) for pack formats. === BasicMac is now known as BasicOSX [05:51] jelmer: Hi there. Any news on the issue with svn+https and bzr? [06:30] jelmer: No, running bzr commit doesn't trigger it. At all. [06:30] Are there any hidden log files I should check? [06:32] awmcclain: ~/.bzr.log, maybe try "bzr -Dhooks commit ..." too. [06:35] hrm [06:35] the -D switch is complaining [06:36] oh oh,never mind [06:38] A ha! Ok. It seems like the email only works if I commit ON the machine, not through SSH [06:43] Why would it not work over bzr+ssh://? Is there a different way to configure the post_commit_to? === mwhudson_ is now known as mwhudson [10:24] morning [12:45] is their a bzr equivalent of 'git add -i' (it allows you to select particular hunks of a file to add) [12:47] wildfire: check out the interactive plugin at http://bazaar-vcs.org/BzrPlugins [12:47] wildfire: git add is different from bzr add [12:47] the interactive plugin adds a -i to commit [12:48] thanks for the advertisement oleavr :D [12:49] asabil: "uncle software, coming to a store near you" ;D [12:49] lol [12:51] shelve kinda does the opposite [12:53] * asabil needs to implement bzr revert -i when he gets free time and motivation [12:54] oleavr, and I just copy the *.py into ~/.bazaar/plugins/ and it'll work? [12:55] wildfire: copy the directory in there, yes [12:55] wildfire: cd ~/.bazaar/plugins [12:56] bzr branch lp:bzr-interactive interactive [12:56] wildfire: you will need to have a subfolder inside plugins [12:58] asabil, thanks - that branch command seemed to do the trick [13:00] great [13:02] let me know if there is any problem with it [13:11] asabil, *** Bazaar has encountered an internal error. [13:12] wildfire@muspell:/etc/bind$ sudo bzr record-patch [13:12] bzr: ERROR: bzrlib.patches.MalformedHunkHeader: Malformed hunk header. Does not match format. [13:12] 'Binary files postfix/virtual.db\t2008-04-04 01:58:00 +0000 and postfix/virtual.db\t2008-04-10 09:06:09 +0000 differ\n' [13:12] can you paste the traceback somewhere please [13:14] asabil, http://pastebin.com/m15c6399a [13:14] hmm, when recording the changes I have to give it a patch-name [13:15] never tried with bzr 1.0.0 actually [13:15] and record-patch is a different thing than commit -i [13:16] both bzr commit -i and record-patch are working here [13:16] using bzr 1.3.1 [13:17] they also worked with 1.1 and 1.2 iirc [13:17] does bazaar support perforce foreign branches? [13:17] as in actual perforce branches, or something like them? [13:18] matthewlmcclure: you can try bzr-fastimport, but never tested it myself === mario_ is now known as pygi [13:18] an actual perforce branch [13:18] wildfire: ?? can you upgrade bzr ? [13:19] asabil: i saw that, but i'm unclear how to provide input to bzr-fastimport [13:20] matthewlmcclure: http://bazaar-vcs.org/BzrFastImport/FrontEnds [13:20] one of the wiki pages recommends git-p4, but it looks like that tool is hardcoded to git [13:21] if git-p4 outputs in git-fast-import format, bzr-fastimport should do (or attempt to) do something useful with it [13:21] right [13:21] but I think that'll be for importing only, not to work with them as foreign branches (like bzr-svn does with subversion's) [13:21] dato: seems like git-p4 runs git commands [13:21] aha [13:21] proc = subprocess.Popen(["git", "rev-parse", branch], ... [13:22] matthewlmcclure: git-p4 can be a good starting point for hacking a bzr-p4 [13:22] asabil: that's what i thought; thanks for confirming [13:23] matthewlmcclure: but as dato said, fastimport is only about importing [13:23] I don't know if that's enough for you [13:23] right, i'd really prefer two-way foreign branch support [13:23] someone needs to step up and implement it then [13:24] i'm looking for an interesting project to hack on, so i may give it a shot [13:24] great :) [13:24] asabil, I'm not sure what version of ubuntu this machine is running [13:25] asabil, and this is a server [13:25] :/ [13:25] asabil, so an upgrade needs to be co-ordinated amongst a larger set of people than just me [13:25] I understand [13:26] but isn't it for your own usage ? [13:26] I mean, why would you need to install bzr on the server ? [13:28] wildfire: you don't really need bzr on the server [13:29] we do if we manage /etc with it [13:30] wait wait [13:30] you seem to have called record patch on a binary file [13:31] that's a bug in bzr-interactive I guess [13:31] let me try to fix [13:37] Hi there. [13:37] A quick question - what does bzr up do on an unbound branch? [13:40] updates the working tree [13:41] this is useful when you push to a server [13:41] you can run update on the server to update the working tree [13:41] So it's only useful if someone pushes code to my branch, right? [13:42] yep [13:42] for unbound branches of course [13:42] Yeah, I know. [13:43] And would bzr pull on an unbound branch be any different from bzr up on a checkout or a bound branch? [13:43] (svn convert here, still failing to grasp all the differences ;)) [13:46] it may be different if you pull from a different url [13:46] and a pull may not work if the branches have diverged [13:47] (in which case you need to merge) [13:47] You may need to merge with bzr up too, right? [13:48] didn't use bzr up extensively, but I think it will merge automatically [13:48] it would work as in svn [13:48] if you see what I mean [13:48] OK, thanks. [13:48] I kinda get it now ;) [13:48] whereas bzr pull fails even when there are no conflicts [13:49] it fails simply because the code has diverged and requires a merge [13:49] Ahh... So up would be like pull + merge in case pull fails. [13:49] something like that [13:49] *I think* [13:50] asabil: Thanks a lot. [13:50] you're welcome [15:21] Guys, can somebody help me with this? I'm trying to update a repository to a specific tag, but I don't get how to do this. What seems obvious to me (bzr up -r tagname) doesn't seem to be the way to do this [15:23] And I'm lost finding this in the docs - though it has to be something easy. :/ [15:27] dwt: can you give more details ? [15:28] is it a checkout or a branch ? [15:28] I'm a bit new, I think its a branch, i.e. it has full history [15:28] If thats what you meant. [15:28] and what do you mean to update to a specific tag ? [15:28] yes that's what I meant :) [15:29] :-) [15:29] so you branched from somewhere [15:29] Jes. [15:29] and you want to rollback to a specific tag ? [15:29] Well, I am playing around with bzr-svn and have a checkout of the 0.4 branch [15:29] yes! [15:30] bzr help revert [15:30] :) [15:30] ahhhh [15:30] or you can crate a new branch from that one [15:30] (that's generally better) [15:30] So the best way would be to move this directory aside [15:30] bzr branch -r tag:mytag . ../branch-mytag [15:31] branch from it, and only get revision up to the tag from the revision [15:31] yep [15:31] Why exactly is that better? I mean, I don't want to start developing on this checkout just yet [15:31] (and probably never) [15:32] so that you don't need to checkout again too many revisions [15:32] if you want to go ahead [15:32] if you see what I mean [15:32] So revert really removes the revisions from the repository? [15:32] uh, thats nastsy. [15:32] from your local branch [15:32] Is there not a simpler way to just go back in the history to a specific time? [15:33] While still retaining all the revisions in the repository? [15:35] actually I am not sure if revisions are removed from the branch [15:35] * dwt is currently reading the revert docs [15:36] I'l look this up a bit and come back to tell what I found. [15:36] oki [15:36] Thansk anyway for the help so far. :) [16:30] asabil: Well, the documentation in in bzr help revert is not completely clear on this, but says that it only throws away local commits. [16:31] I'm not sure what I should make of this [16:31] anyway for my usecase revert seems like the right thing for me [16:31] k [16:35] revert only modifies your working tree [16:35] so it won't delete revisions [16:35] so also local commits are not deleted? [16:36] thanks for the clarification radix! [16:36] sure thing [17:37] ok, thanks and cu! [18:25] anyone know if there is an equivalent to tag_svn_revision for bzr in setup.cfg (ala python setuptools) ? [19:22] if I have a remote machine from which I need code updated from a bzr repository, but the machine only has incoming traffic and no outgoing traffic, can I update the remote machine from my local machine using push or somesuch? [19:22] when I actually did try push, I get the error that the remote machine does not have a .bzr directory, which kinda makes sense because it's not a repository [19:25] I wonder if I need the bzr-push-and-update plugin, but I think there's a way to make this work somehow [20:27] jelmer: Hi there! [20:27] jelmer: I've got a question regarding bzr-svn, got a minute? [20:28] matid: sure [20:28] matid: I posted a patch to the subversion development list that fixes the https issue, btw [20:29] jelmer: Oh, cool. [20:29] jelmer: Thanks a lot. [20:29] jelmer: The question is - what is a preferred way of dealing with diverged branches in svn? [20:30] matid: There is no preferred way; it's up to you, what do you like best? [20:30] matid: You can merge and push, but that may potentially change your existing revision history in svn [20:30] matid: Some people prefer rebasing before pushing [20:30] jelmer: Let's say, I branch some code, work with it, but in the meantime someone updates svn. I did bzr pull but I asked me to merge. And so did I, but after a push a strange commit appeared in svn. [20:31] jelmer: It was a duplicate of the commit that was done in between my branch and the push. [20:32] jelmer: And to be honest with you I don't even know how subversion will cope with it. If it's diff based then it should simply ignore it. [20:32] jelmer: So I was supposed to rebase, right? [20:34] jelmer: Oh, in fact it reverted the changes, it's not the same. [20:40] jelmer: Eh, it's the same after all. I don't get it... [20:54] matid: "bzr push" will push the current mainline in your bzr branch [20:55] jelmer: Let's say with got a situation like this: [20:55] New bug: #216924 in bzr "Push failed using (bzr push lp:). On windows machine" [Undecided,New] https://launchpad.net/bugs/216924 [20:55] matid: That may involve changing the current mainline in Subversion [20:56] jelmer: I branch the svn code at revision 154. Now another person submits revision 155 and 156 to svn, whereas I make one commit in my bzr branch. [20:57] jelmer: Now what I did was a bzr merge followed by bzr commit and bzr push. [20:57] jelmer: Which resulted in a new svn revision containing duplicated 155, 156 and my bzr changes. [20:57] jelmer: Is this expected behaviour? [20:59] matid: Yes, because that's what's in your local bzr mainline [20:59] matid: If you want to push something on top of what's in svn, use rebase [21:00] jelmer: Is there a change what I just did (bzr merge and push) broke something? [21:01] jelmer: Or is it just an innocent duplication? [21:01] matid: It still contains the same data as is in your local bzr branch [21:02] jelmer: But well, if I did a merge before I pushed it should also contain all the changes that were made in svn in the meantime, right? [21:02] matid: yes [21:02] jelmer: Which means that bzr pushed a some diffs which applied to svn trunk simply didn't do a thing, am I right? [21:03] jelmer: I'm not really used to this kind of behaviour :) [21:03] you'll notice the same revisions are in the svn branch as are output by "bzr log --line" [21:04] matid: Not sure I understand what you mean by "Which means that bzr pushed a some diffs which applied to svn trunk simply didn't do a thing, am I right?" [21:05] Hmm... [21:05] jelmer: It seems like bzr log --line shows some differences between svn and bzr. [21:05] can you be more specific? [21:06] jelmer: I mean, there's one extra commit in svn between the moment I branched the code and the moment I pushed it. [21:06] jelmer: This is a commit that I merged in bzr by using `bzr merge` [21:06] matid: and it's still there if you use "svn log" on the full branch url? [21:07] jelmer: Eee... It disappeared... How come? [21:07] matid: it's not part of the mainline [21:08] jelmer: You can't delete changesets in plain svn, or can you? [21:08] matid: it's part of the right hand side history. You'll see if you run "bzr log" on the remote svn branch it'll show up indented [21:08] matid: Nope, it's still part of the repository, just not part of the mainline history of that branch [21:10] jelmer: Guess I've never stumbled upon this kind of thing in svn... [21:11] jelmer: Which means that both solutions (rebase and merge&push) are going to result in the same code state in svn. [21:11] jelmer: Yet push will rearrange the revision history. [21:12] matid: After rebase, you still have to push [21:12] jelmer: Yeah, it's not going to change anything in svn though. Just append new changesets, right? [21:12] matid: yep [21:12] jelmer: I guess I'll use rebase then. [21:13] jelmer: I mean for me it makes no difference, but other people are not going to frown upon some strange things going on in svn :) [21:15] matid: :-) [21:15] jelmer: It's kinda strange since it looks like I committed changes someone else made earlier. [21:16] matid: It matches the behaviour of merge, commit and push for native bzr branches [21:16] and that's what bzr-svn tries to do [21:17] jelmer: To me it looks like I'm trying to make others' changesets look like mine :D [21:18] matid: the same thing will happen if you use svn merge with a subversion branch [21:18] jelmer: Hm... It's just that in svn I used to do it the other way round. [21:19] jelmer: Work on a branch, then merge changes into trunk and commit there. [21:19] jelmer: I think this would also be possible if I simply kept one clean checkout of svn trunk and merge other bzr branches into it, right? [21:23] abentley: ping [21:23] morning y'all [21:23] lifeless: pong [21:24] I'm trying to get BB up and running again on squid-cache.org [21:24] I'm a little confused by your response to the bug I filed [21:24] matid: yes - but if you do that, each merged bzr branch will only show up as a single commit in svn [21:24] matid: (since a bzr merge puts only one revision on mainline) [21:24] I understood you were running TG 1.02 and SQLAlchemy 0.4.4. Is that right? [21:25] did you mean that if I downgrade sqlalchemy somehow, it will fix the error, or that 1.0.4.3 is a hard dependency now [21:25] jelmer: That's what I'd do in svn, but it seems like using rebase is a better solution. [21:25] matid: yeah, rebase makes snese in this case [21:26] abentley: yes, thats what freebsd ships [21:26] jelmer: Cool. Is there any case in which bzr-like merge and push will prove superior to rebase? [21:27] lifeless: for revno 249 and later, 1.0.4.x is a hard dependency. [21:27] matid: It will probably give better results combining two branches [21:27] matid: Rebase simply does diff + patch for each of the revisions you have that aren't in upstream [21:27] abentley: you wouldn't happen to know if loggerhead is compatible with 1.0.4.x ? [21:28] At least, in my experience, TG 1.0.2 did not work properly with SQLAlchemy 0.4 [21:28] jelmer: OK. Which means that in case of not-so-complicated merges it should work the same. [21:28] lifeless: Sorry, I don't know that. [21:29] thats ok, wishful thinking :P [21:29] I find myself thinking unpleasant thoughts towards the turbogears maintainers [21:30] the dependency tree seems unpleasant [21:30] I'm quite disheartened about the whole thing. [21:30] Especially that SQLAlchemy managed to ship two releases which had blatent bugs that my measly test suite caught. [21:30] tests FTW [21:31] mwhudson: ping [21:31] lifeless: hi [21:31] This was stupid stuff where they failed to import a symbol they used. [21:32] !!! [21:32] thats apalling [21:32] you've got that right. [21:36] I do want to talk about the tension that bubbled out on thursday; however sunday morning I woke up with a head cold [21:36] matid: yeah [21:37] I'd rather be at my best when debugging important things [21:43] abentley: welcome back [21:43] thanks. Last thing I saw was "I'd rather be at my best when debugging important things" [21:43] abentley: that was the last thing I wrote [21:44] Cool. [21:59] aarrgghh [22:00] abentley: you'll love this. I'm trying to update the turbogears package for freebsd [22:00] 1.0.4.3 wants turbojson 1.1.2 [22:00] there is no egg for 1.1.2 [22:01] That's nutsy [22:01] http://files.turbogears.org/eggs/ is where the package is looking [22:02] 1.1.2 is available on PyPI, though. It doesn't fall pack to that? [22:02] s/pack/back [22:02] no [22:03] Strange. I thought it did. [22:03] easyinstall may [22:04] Oh. [22:04] Yes, that's what I was talking about. [22:05] I'm really not sure what to do at this point [22:06] I'm trying to get bzr-svn going on Windows using Python 2.5(.2). I have svn 1.4.6 installed, an have installed bzr 1.3 and bzr-svn 0.4.9 using the binary installers, and installed the updated svn 1.4.6 python bindings. `bzr version` now crashes for me. Have I missed something I need to install? [22:08] lifeless, i think going back to linux is the answer ;-) [22:09] wildfire: this machine has never been linux :( [22:09] squid-cache.org [22:09] threeve: How did you install svn 1.4.6 ? [22:09] jelmer: windows binary installer from Tigris, iirc. [22:10] interesting coincidence, I'm installing squid as we speak [22:10] lifeless, ahh, right. well that's nothing a chroot couldn't solve if you get really stumped [22:10] wildfire: but even if I did that, this points out a generic problem for folk that are not on development editions of linux [22:10] threeve: You can't use a stock subversion 1.4. You need either the one with the patches linked from the bzr-svn wiki page or Subversion 1.5. [22:11] lifeless, i don't think developers will ever be 'generic folk' personally. Most people never miss the 'new' [22:12] wildfire: EPARSE ? [22:13] jelmer: Okay, I thought that might be the case but I thought maybe only the patched bindings were necessary. Building a new Subversion now. Thanks [22:13] cr3: :P [22:16] lifeless, most people are not neophiliac's like you and I and most other developers. People who are not on development editions will never, generally, run into the issue since "shiny" isn't what they care about - they are 'generic folk'. [22:16] Therefore the problems of generic folk and development folk are not normally intertwingled. [22:17] wildfire: I think more people care about "shiny" than just a couple of developers :-) [22:17] wildfire: for this discussion, I'm wearing the hat of generic folk [22:17] wildfire: I don't want a shiny bb, I want a working bb. [22:18] wildfire: dependency issues between components used by bb have forced bb to require versions that are not available on freebsd; either by being too old, or once fixed, by being too new. [22:21] lifeless, with my (slight-tipsy) sysadmin hat on, I'd suggest the best thing would be a specific python chroot devoted to have the right dependancies for tg, sqlalchemy and bb all installed at the specific versions [22:21] s/to have/to having/ [22:21] once they OS has the appropriate ones you can always migrate it back out of the chroot [22:22] wildfire: I don't want to sysadmin this service :P. So I'm simply punting the problem to the -noc team there [22:25] hi all [23:08] this is strange, right: [23:08] mwh@grond:debian-packaging$ cat .bzr/branch/last-revision [23:08] 2 ted@canonical.com-20080401051631-3zsnbir02j3c0ihp [23:08] mwh@grond:debian-packaging$ bzr revision-history | wc -l [23:08] 30 [23:08] ? [23:08] mwhudson: yeah, that's very weird [23:13] the cached revcount would appear to be wrong [23:14] sure looks like it [23:15] i can try and grab ted and ask what he did i guess [23:15] (it's this branch) [23:15] https://code.edge.launchpad.net/~ted-gould/gnome-power/debian-packaging [23:15] abentley: so the api I proposed in my new stream doco doesn't work [23:16] I guess we're all a bunch of boobs, then. [23:16] abentley: I think it will work better if rather than returning the bytes, I return a factory object that can return as_knit, as_fulltext, etc. [23:16] I mean, it works ok in the common case [23:17] but isn't able to handle the iter_rev_trees thing. I tink that the small change above will. [23:17] so I'm doing a hallway test :P [23:18] breakfast [23:20] I don't get it. Isn't this just for fetch? [23:22] its for fetch including the case of plain -> rich roots [23:23] I have a call in ~8 minutes with thumper and an errand to run first, back to chat after that [23:53] morning [23:54] Hi Ian! [23:55] hi jelmer - I'm back from holidays [23:55] fiji was awesome [23:55] :-)