[00:00] jelmer: You might want to look at https://dev.launchpad.net/Code/BzrSend [00:00] abentley: some nicer errors might be nice :) [00:00] jelmer: ping [00:01] jelmer: did you see the thread asking for bzr-git help ? [00:01] abentley: ah, cool [00:01] thumper: I suppose, but soon it will not be an error. [00:01] davidstrauss: in all your branches? [00:01] abentley: :) [00:02] lifeless, hi [00:02] lifeless, no, I'll have a look now, thanksw [00:06] lifeless: I've only tried that in the problem branch. [00:08] davidstrauss: please try your other branches [00:09] the file in question - modules/trigger/trigger.info [00:11] lifeless: I can't pull that revision from any branch. [00:12] lifeless: i can access trigger.info from older branches [00:13] davidstrauss: you checked cat-revision for that rev in all your branches? [00:14] davidstrauss: did you have anything odd happen two days ago? all the references to the missing revision start on the 28th of jan [00:14] was it a loom branch [00:15] (I'm trying to track down the reason this happened) [00:15] lifeless: I didn't hear any reports of problems [00:15] lifeless: And "bzr check" runs fine on yesterday's branches [00:16] brb [00:17] back === mtaylor_ is now known as mtaylor [00:23] lifeless: the branch works properly through rev 520 [00:25] davidstrauss: yes, thats consistent with my analysis [00:26] davidstrauss: something cause bzr, in rev yched-20090128232212-lnh21io5dqaikdeo, to insert a reference to a text version that isn't in the branch, coming from a revision you don't appear to have [00:26] that commit was done by yched [00:27] lifeless: yes, and he uses a windows client over bzr+ssh [00:28] lifeless: i've emailed him to ask the specific version [00:28] spiv: ping [00:28] davidstrauss: also any plugins, and did he have *any* issues - confusing behaviour, a merge he cancelled, etc - at that time [00:29] lifeless: he has whatever is packaged with the windows bzr installer [00:29] lifeless: and he's using a checkout/update/commit workflow [00:29] lifeless: the server-side is running bzr 1.11 [00:30] lifeless: on RHEL 5 [00:30] lifeless: pong [00:30] spiv: please read the discussion david and I have been having [00:30] lifeless: I haven't heard if Yves did or encountered anything unusual. [00:31] davidstrauss: regardless; there is a bug here, if it was commot we'd see this all the time, so its uncommon / corner case [00:31] lifeless: Hmm. Summary: missing revision, there's a text delta against that rev, the missing revision was created on windows over bzr+ssh? [00:32] its a pretty serious bug to introduce bad references like this [00:32] spiv: missing rev; the inventory in rev yched-20090128232212-lnh21io5dqaikdeo adds a reference to [1-or-more] texts added by the missing rev [00:32] rev yched-20090128232212-lnh21io5dqaikdeo was pushed to the server by the windows client over bzr+ssh [00:33] spiv: The branch is downloadable from http://straussd.fourkitchens.com/7-fic-broken.tgz [00:35] davidstrauss: let me know when he gets back to you [00:35] davidstrauss: I'll start looking at the code he's running at that point to see if I can find a potential cause [00:36] lifeless: Sounds like a plan. :-) [00:37] lifeless: An interesting issue... and the second one involving bzr+ssh & windows in the last week. [00:38] spiv: I smell a commit issue for the inventory data; but I also am concerned about the smart server letting this in [00:39] Well, the smart server is still mostly acting like a VFS server as far as pack data goes. [00:39] isn't there a ref check now ? [00:39] Hmm. I think the client is still doing that, I'll refresh my memory. [00:42] Yeah, the Packer on the client still does _check_references. After that point the autopack occurs (and may be done via RPC), but the InterPackRepo code path leading to _check_references is the same for HPSS and non-HPSS. [00:42] spiv: so, somehow this passed the check [00:43] likely because the rev being added doesn't add the ref; but the mismathc between inv content and rev parents led to a skew [00:43] I'm really wondering if there is a third party commit code involved [00:43] something in bzr-gtk or qbzr perhaps [00:44] That's an interesting thought! [00:44] because of course the core code is bugfree ;P [00:45] :) [00:45] markh: what does gui commits on windows do [00:46] um - the qbzr plugin calls "bzr commit" as a subprocess, if that is what you are asking === dereine is now known as dereine[OFF] [00:48] ok, so we should have the command line in bzr.log [00:49] lifeless: He may be using TortoiseBzr [00:49] davidstrauss: Tortoise uses qbzr [00:50] lifeless: There's also a chance he's using the Eclipse extension [00:50] davidstrauss: we'll know soon enough :) [00:50] I'm mostly concerned that the smart server allowed this. [00:51] davidstrauss: so are we ;) [00:52] * spiv goes back to working on a truly smart push... [00:59] lifeless: Yves is running Tortoise Bazar 0.1 / bzr 1.9 [01:00] did he notice anything out of the orderinary? [01:01] can we get his bzr.log [01:01] lifeless: He didn't mention anything unusual. [01:01] ok, looking a little more, qbzr actually executes a sub-process with a command-line that looks like 'bzr qsubprocess commit ..." - the qsubprocess command still just does a "normal" checkout or whatever sub-command is issues, but qsubprocess allows for progress info to be sent back IIUC [01:01] davidstrauss: please ask him explicitly [01:01] lifeless: Where is bzr.log for Windows clients? [01:02] davidstrauss: in "my documents" [01:02] bzr --version lists the location [01:05] lifeless: I've asked him. [01:05] davidstrauss: thanks [01:06] I want to be clear - I don't think hes done anything wrong; this is a software issue we just need to fine the bug [01:11] lifeless: of course :-) === kiko-afk is now known as kiko-zzz === abentley1 is now known as abentley [01:48] * igc lunch & doctor appointment [03:29] lifeless: I'm assuming this is known about: /home/tim/.bazaar/plugins/loom/revspec.py:64: DeprecationWarning: Modifying SPEC_TYPES was deprecated in version 1.12. [03:36] thumper, yeah, John posted a patch to the list [03:37] and I approved it :P [03:38] cool [03:38] is it on trunk yet? [03:39] <_Andrew> I just made this diff on a file but I feel like it's not generated the patch correctly on one file because it's removed a ton of code I haven't edited and then added it back in. Should I report it as a bug? [03:40] _Andrew: you can if you like, but diff is actually really hard to get 'right' all the time: oftimes when we get a report like that we can track it down to the alternative being larger or less useful - but not always [03:40] _Andrew: you probably moved an anchor line from below to above the code that got shown as a delete+add [03:43] _Andrew: we do care about making diff as useful as possible [03:43] <_Andrew> You might be right.. [03:43] <_Andrew> one second let me revert the change and add what I changed === mtaylor_ is now known as mtaylor [04:02] <_Andrew> My fault.. [04:02] <_Andrew> I ran one of the files through qt designer which changed it all [04:11] <_Andrew> Thanks for all the help. === abentley1 is now known as abentley [04:31] anyone know what a bad protocol version marker would be? [04:32] bzr: ERROR: Received bad protocol version marker: '2428\nbzr message 3 (bzr 1.6)' [04:34] A good protocol version marker would be "bzr message 3 (bzr 1.6)\n" [04:34] This is over bzr+ssh? [04:34] yes [04:34] Can you reproduce with -Dhpss? What version on the server? [04:35] bzr -Dhpss ci -m "testing" [04:35] bzr: ERROR: Received bad protocol version marker: '1772\nbzr message 3 (bzr 1.6)' [04:35] 1.6.1 on both [04:35] although the server was created at 1.3.1 [04:36] I tried doing a bzr upgrade on the server and it says its all up to date [04:36] tjs: what does the log file (~/.bzr.log) show for the -Dhpss command? [04:36] tjs you have noise from somewhere [04:37] Interesting that it's so consistent (4 bytes each time)... [04:37] Do you have any plugins on the server that would write to stdout? [04:37] aah [04:37] possibly o.O [04:37] one sec [04:38] Hmm, perhaps bzr serve should smash sys.stdout to discourage that... [04:38] Er, bzr serve --inet, I mean. [04:38] crisis averted [04:38] *halo* [04:38] thanks guys [04:40] tjs: bzr+ssh doesn't care about stderr, so you can abuse that if you want ;) [04:41] was just some debugging cruft, is there a way to use pdb in a hook script? [04:47] You can do the usual "import pdb; pdb.set_trace()" trick. [04:48] It won't work so well if it's running on the remote end, though... [04:49] (Incidentally, hitting SIGQUIT, usually C-\, will drop you into the debugger too) [05:10] jelmer: Congrats on the release (candidate). :) [06:59] lifeless, there? [06:59] well anyone actually... [06:59] I am trying to see what the changes are between two branches [07:00] via merge /path/to/dev/branch [07:00] this only merges the last checkin... [07:02] bzr merge will merge all changes that aren't already in your branch. [07:04] You could also do bzr diff -r -1..branch:/path/to/dev/branch [07:05] But typically "bzr merge --preview /path/to/dev/branch" is what you want. [07:05] spiv, but that's just it [07:05] there are more changes that are not being merged [07:06] for example, I made some changes to the 'website' directory in my 'next' branch, yet when I switch to master and merge from next... nothing [07:07] What does "bzr missing /path/to/dev/branch" report? [07:08] spiv, "You are missing 1 revision" [07:08] I have no ide ahow [07:08] I never merged [07:08] hi all [07:08] spiv, I am looking at bzr log [07:09] all the checkins are to branch nick: next [07:09] yet some of the changes are actually in my master branch already [07:09] wtf [07:27] ah spiv I think I may have figured it out... I had the working copy bound to /path/to/master [07:28] so I guess when I did bzr switch next, it was still submitting to master? [07:28] weird [07:30] sohail: bzr switch changes the branch that the working copy is bound to. [07:30] spiv, then what's going on? [07:32] No idea. [07:33] this sucks... [07:33] I need to do a release but wanted to work on some next version stuff! [07:34] oh well... bed time :-( [08:45] have a good weekend all [08:52] I've inadvertently bzr rm'd an (empty) folder (called "tmp") in my branch. I did it a while ago, and I'd like to get it back. "bzr revert tmp" complains that tmp is not versioned (which it isn't, because I bzr rm'd it). How do i get it back? I could just bzr add it again, but that seems wrong... [08:52] If I did a 'bzr merge ' on a given branch, and now 'bzr st' shows 'pending merges', how do I "call off" the merge, and go back to how it was before I had typed 'bzr merge'? [08:53] edgimar: bzr revert [08:53] Lo-lan-do: I think I tried that -- are there special flags to add to it? [08:53] aquarius: bzr revert, too :-) [08:53] edgimar: Not as far as I know [08:54] Lo-lan-do: bzr revert will just remove everything changed since my last commit, won't it? [08:54] Lo-lan-do: and bzr revert tmp says that tmp isn't versioned [08:54] aquarius: Correct. If you want to save some of these changes, you might try to shelve them, then revert the rest, then unshelve. [08:55] Ok, maybe the problem was that I specified something like '*' as an argument, and should have had no arguments. [08:56] edgimar: Possibly, yes. [09:02] By default, I think revert only removes pending merges when you don't specify any files. That's what the --forget-merges argument is for. :) [09:06] Lo-lan-do: aha, I removed it in r570. So, bzr merge -r 570..569 will reverse that merge, yes? [09:07] aquarius: Ah, if you've committed the removal, then yes, you'll need to do something like that. [09:07] revert only reverts uncommitted changes :-) [09:08] Lo-lan-do: yep :) [09:09] Lo-lan-do: OK, confused. bzr log -v -r 570 shows that all I did in that revision was remove tmp/. But bzr merge -r 570..569 changes a load of other files. What am I doing wrong? [09:12] Lo-lan-do! [09:12] good to see you here [09:13] aquarius: Not sure... it may be a different syntax. [09:13] kiko-zzz: Hi :-) [09:15] kiko-zzz: How are things? [09:15] how's bzr working for you? [09:15] I'm great. a bit sleepy [09:15] busy this week with a plan for bzr :) [09:16] It's working great for me, and I'd love to have time to learn how to hack it in order to fix a few problems I still have. [09:17] Lo-lan-do, hey, if you have some time free talk to me :) [09:18] Free time. Haha. [09:21] I am very confused. bzr log -v -r 570 shows that all I did in that revision was remove tmp/. But bzr merge -r 570..569 changes a load of other files. What am I doing wrong? [09:21] aquarius, interesting -- in what revision did those files change? [09:22] kiko-zzz: I don't know... [09:22] kiko-zzz: probably 571 (I did a merge from trunk then) [09:23] aquarius, try changing the revisions in your merge command slightly and seeing if something makes sense [09:24] kiko-zzz: it doesn't seem to. (This is more complex because 571 was the merge from trunk, so loads of files that I have nothing to do with changed...but merge -r 570..569 does not seem to be everything from trunk.) [09:24] If I committed something before setting my username properly (with 'whoami'), can I go back and change the username of the commit? [09:25] edgimar, bzr uncommit and commit [09:25] ok, so uncommit will leave the working directory in the state right before it was committed? [09:25] and shelve if you don't want to lose that [09:26] yes [09:26] exactly [09:27] aquarius, I can totally reproduce what you are saying [09:27] aquarius, I'm not sure exactly why it happens, but I can tell you this [09:28] kiko-zzz: what if I committed more than one revision? [09:28] edgimar, uncommit, shelve, uncommit, shelve, etc [09:28] ok. thanks. [09:28] kiko-zzz: aha! I have worked it out, because I was stupid. bzr merge -r 570..569 . [09:29] I was unmerging from trunk, not from myself. forgot the . on the end :) [09:29] aquarius, heh, but tricky eh? [09:29] might be worth filing a bug [09:29] okay, time for some cycling [09:29] before I go pumpkin :) [09:29] * kiko-zzz waves and will bbl [09:29] kiko-zzz: I shall do, although it may be closed with EYOUARESTUPID :) [09:30] aquarius, /msg me the bug number so I make sure it doesn't ;) [09:39] kiko-zzz: It seems that doing uncommit / commit requires you to re-enter your commit message and doesn't retain the original commit time -- is there a way to *only* change the username? [09:40] edgimar, well, you're asking to rewrite history. there may be a history rewriting plugin but I don't know 100% [09:40] need to run, ttyl [09:44] edgimar: by uncommitting, you're asking bzr to forget about your commit. So it does indeed forget username, message, etc. [09:45] edgimar: If you really want that behaviour, write yourself a script. It's not behaviour I'd imagine the bzr team wanting to promote === asabil_ is now known as asabil [10:08] Hello [10:12] I have yet another problem with bzr on windows [10:12] I can't locate where the configuration files are [10:13] bzr version [10:16] Oh got it [10:16] man, it's easier on GNU/Linux [10:21] During disconnected operation I committed code to a local branch "bzr ci --local". If I "bzr update" will that propogate to the non-local branch it was checked out from? [10:21] james_w: arf :) [10:22] aquarius: I couldn't resist [10:22] aquarius: Long time no see. Happy birthday. [10:23] ah, happy birthday aq [10:23] balor: I'm not completely sure, but I believe it won't propagate at update time [10:24] james_w: hmmm..... [10:25] balor, james_w: cheers :) [10:29] aquarius: Which reminds me that I should go up north to spill another pint on you some time soon. [10:30] etenil: `bzr qconfig` may help [10:34] balor: when you're around here, say the word :) === asac_ is now known as asac [10:44] balor: no, bzr update will turn the local commits into pending merges in your working copy. When you do "bzr commit" they'll propagate to the master branch. [10:44] spiv: Will they commit with the commit messages I've previously given them? [10:44] spiv: i.e. the changelog entries [10:45] Nope, they'll commit as one revision merging all your local commits into one. [10:45] hmm.... [10:46] Is there any way to get all my local commits to commit to the master branch? [10:46] Unless you rebase them on the updated tree, but I'm not sure how to do that (I believe it is possible though). [10:46] Yes, rebase :-) [10:46] balor: all the commits will still be there, but not on the mainline. [10:47] You could probably "bzr unbind" and then "bzr push" to push them as mainline commits, assuming the master hasn't diverged. [10:48] spiv: I think I may just push them up to a new location and use that as the new mainline [10:48] And if it has diverged, then unbind, rebase, push, bind. [10:48] Lo-lan-do: er [10:48] Lo-lan-do: well, I guess. Or just merge the master back in and push. [10:49] (If you want the individual commits to still appear linearly) [10:49] I personally wouldn't worry so much about which commits are mainline and which aren't. [10:49] They're all still there, whether they're on the left-hand side of the graph isn't really a big deal generally. [10:49] spiv: I sometimes do, when mainline is stored on SVN. [10:50] Ah. Poor you :) [10:50] Yeah. === kiko-zzz is now known as kiko-afk [12:32] I've got a silly windows problem to start olive [12:33] I have made a shortcut to 'bzr olive', but it always shows the terminal windows to which the program is attached [12:33] is there any way around? === thekorn_ is now known as thekorn [13:56] Is there a known issue with bzr-git right now? [13:56] I branched it to take a look, but bzr whinges: [13:56] __init__() takes exactly 2 arguments (1 given) [13:57] which appears to be caused by the last line in mapping.py [14:10] Kinnison, you need bzr.dev [14:11] lol [14:11] Format for file:///home/jelmer/hg/dovecot/.hg/ is deprecated - please use 'bzr upgrade' to get better performance [14:11] * jelmer fixes bzr-hg [14:11] jelmer: :-) [14:12] jelmer: I just did pull in my bzr.dev [14:12] * Kinnison boggles and tries again [14:13] No revisions to pull [14:13] jelmer: regarding bug marked as fixed released for bzr-gtk, there seemed to be consensus on the ML, should we start to apply it now ? [14:13] Kinnison, oh, and I should be pushing to lp:bzr-git rather than my private bzr-git branch [14:13] Kinnison, sorry [14:14] should I re-pull bzr-git ? [14:14] Kinnison, pushed, please repull bzr-git [14:14] yep [14:14] vila: yeah, I think so [14:14] ok, great [14:15] What is dulwich and where do I get it? [14:16] Kinnison, it's a Python module that implements the git file formats/protocols [14:16] Kinnison, there's a PPA at launchpad.net/~dulwich [14:19] Kinnison, the performance sucks a bit at the moment, so I wouldn't try it on the Linux kernel but it should be fine for smaller projects [14:19] jelmer: I'm interesting in bzr-git. I'll try to start test it on win32. Do you have any particular advices? [14:20] bialix: Ah, cool! I would be interested to hear about portability or other bugs you encounter [14:21] I don't have any particular git project I want to track. Do you have any testing one or I need to create local repo? [14:21] jelmer: amusingly I hadn't read that performance warning and wandered off to branch linux-2.6 [14:21] jelmer: It crashed [14:22] the guys that where developing the bzr textmate bundle don't whant to continue to develop it. If I were to work on it do you guys think using the bzr api is a better idea or using the bzr client is ok? [14:22] Hi! I'm using ubuntu intrepid and the launchpad bzr ppa. [14:23] how could I show progress bar is I use the bzr client? [14:23] Since some time, I can't update the bzr package: Update manager always prompts me to do a "partial update", as bzr can't be installed. [14:23] homy: you are having problems with bzr-tools right [14:23] ? [14:23] santagada: how do I find out if that's the case? [14:24] homy: I think noone updated it yet... the last 2 days people came here all the time complaining about it [14:24] homy: you can search for bzr-tools on synaptic I think... [14:25] bzrtools (without dash, IMO) [14:25] bialix: thanks :) [14:25] at least it's the official name [14:25] yes. The square is green. The square next to bzr is green but has a star [14:26] santagada: what bzr version are you using ? There is a new pb implementation under work in bzr.dev [14:26] vila: pb? [14:26] what is that [14:26] progress bar [14:27] vila: I plan to develop the textmate bundle to work with the released bazaar... or when is 1.12 going to be released? [14:27] the rc should be out next friday or something [14:27] homy: bzrtools is 1.10 right? and bzr can be updated to 1.11 [14:28] vila: so I should probably target it [14:28] santagada: what is textmate ? [14:28] vila: one of the most used text editors for osx [14:28] bialix, a good one is e.g. etckeeper [14:28] santagada: I thought is was emacs, sorry about that :) [14:28] santagada: bzrtools: installed version = latest version = 1.10.-1~bazaar1~intrepid1 bzr: installed version 1.10-1~bazaar1~intrepid and latest version 1.11.1 [14:29] bialix, bzr branch git://git.kitenet.net/etckeeper [14:29] Kinnison, whoa :-) [14:29] jelmer: ok [14:29] vila: I think the order is: textmate, bbedit, aquamacs, vim [14:29] Kinnison, Hopefully that should be fixed soon, there are just two places where we do things *really* inefficiently [14:29] santagada: so regarding pb, it depends a lot on how you interface between textmate and bzr [14:30] vila: I was plaining to use the bzr client directly thru shell scripts [14:30] * bialix hope etckeeper don't have versioned symlinks [14:30] jelmer: http://rafb.net/p/881AAH60.html [14:31] jelmer: if it's something you know, I'll wait. otherwise if you want, I can file a bug. [14:31] help? [14:31] How do you "program" (?) textmate ? [14:31] Kinnison, please file a bug [14:31] homy: you have to wait [14:31] santagada: by the way, I thought Xcode was the most commonly used... [14:32] homy: while bzrtools is not updated [14:32] vila: xcode is not a text editor... well emacs isn't either :) [14:32] vila: tm uses shell scripts mostly [14:33] Is there any particular reason for bzrtools not being up-to-date in the ubuntu ppa? [14:34] jelmer: filed: #323190 [14:34] * bialix mutters bzr-git and dulwich could be married with scmproj [14:34] homy: ppa I think is updated by people... and some people didn't update it [14:34] Kinnison, thanks [14:35] * Kinnison goes back to git for now [14:35] * Kinnison sobs [14:35] homy: why he didn't I don't know... but doing debian packages is a hard process [14:35] jelmer: what is the right way to run selftest fro dulwich [14:35] ? [14:35] s/fro/for/ [14:35] jelmer: the PPA packages are not automated or are they? [14:35] bialix, e.g. "trial dulwich" [14:36] trial? [14:36] bialix, it's part of twisted [14:36] oh, no [14:36] hi folks, i'm having trobles using trac-bzr on freebsd. Is there a better channel for this issue? [14:36] bialix, I think there are other test runners as well, but don't know any others off the top of my head [14:37] if there is nothing unusual in dulwich test suite I can port my own runner, if you dont mind [14:37] speakman: I'm using trac-bzr, but on Windows [14:37] bialix, I'd rather keep it as generic as possible [14:38] I get "AttributeError: 'int' object has no attribute 'isdigit'" when running latest trac-bzr (from trunk today) and Trac 0.11.2, bzr 1.11 (how do I check bzrlib version?) [14:38] speakman, please file a bug [14:38] >>> bzrlib.version_info [14:38] (1, 11, 0, 'final', 0) [14:38] ok, so I guess I'll just have to wait. [14:39] jelmer: how test runner will make the dulwich test suite less general? [14:39] or generic, whatever [14:39] speakman: int has isdigit right? [14:39] speakman: try it in python [14:39] isdigit seems to be string method [14:39] heh, didn't look that far. Strange! Python is 2.5 btw [14:39] speakman: (1).isdigit() or int.isdigit() [14:40] bialix: right again [14:40] speakman: it is a function from string, bialix is right [14:41] The line of the error is 213 in backend.py: "if rev.isdigit():" [14:41] speakman: paste your full traceback somewhere [14:41] bialix: basically dulwich just uses the standard unittest python module that's included in python itself [14:41] santagada: will do, w8 [14:41] bialix, so any test runner that can use that should work [14:41] jelmer: yes, I understand [14:41] I have a simple test runner implementation so one can run `python setup.py test` [14:41] speakman: I think you should open a ticket on the bzr bug tracker... [14:41] bialix, ah, ok [14:42] bialix, That's of course useful :-) [14:42] http://pastebin.com/m609db24c [14:42] jelmer: something wrong: ImportError: No module named dulwich.protocol [14:42] santagada: bzr or bzr-trac ? [14:42] speakman: good question [14:43] speakman: I'm thinking it is a problem with the trac integration [14:43] rats [14:43] but let me look [14:43] jelmer: I've put dulwich lib inside git plugin directory because I'm running bzr.exe [14:43] speakman: it is a problem with tracbzr [14:44] and this import does not work for me: from dulwich.protocol import Protocol, TCP_GIT_PORT, extract_capabilities [14:44] speakman: what is it by the way? it is a plugin for versioncontrol for trac? where can I find its homepage? [14:44] bialix, Yeah, you'll probably need to have it in PYTHONPATH [14:45] jelmer: oh, yes. we have similar trick in qbzr [14:45] Changing repository_dir to point at parent dir killed the error..! [14:45] speakman: maybe there is someone on #trac that could help you [14:45] santagada: https://launchpad.net/trac-bzr [14:46] jelmer: I'll send you a patch shortly [14:47] jelmer: isn't you the author of trac-bzr? [14:47] jelmer: in qbzr we put additional libs in the _lib directory. if I'll use the same approach for bzr-git -- it'll be ok for you? [14:47] bialix, as long as it doesn't modify sys.path [14:48] it indeed modified sys.path [14:48] but only if user run bzr.exe [14:48] hmm [14:48] there is no way otherwise [14:48] bialix, Can you send me the patch? I'm not completely sure about this, but I'll have a look [14:48] trac-bzr looks cool! wish lp was free :) [14:48] This seems to fixed it. I'll just keep it like that. [14:48] jelmer: for bzr.exe sys.path points only to bundled libs in exe's library.zip [14:49] santagada, I seem to be the maintainer by default [14:50] jelmer: good luck fixing speakman bug :). I might be abble to help [14:51] jelmer: it will looks something like this: http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk/annotate/head%3A/lib/__init__.py (lines 23-25) [14:51] I don't know anything about bzr but I do understand trac code [14:51] bialix, Ah, that looks reasonable [14:51] hmm -- I was just plugging Bundle Buggy in #qemu (as there's been talk on the mailing list on wanting a patch-tracking system), and Patchwork [http://ozlabs.org/~jk/projects/patchwork/] came up as an SCM-agnostic competitor; I didn't actually know there were other tools in the same space. [14:51] nDuff, I think bzr used patchwork for a while [14:52] nDuff, it doesn't track when things have been merged though, exactly because it's SCM agnostic [14:52] santagada: trac-bzr mainly needs a testsuite :-( [14:52] can someone tell me why im getting this error? http://pastebin.mozilla.org/612641 [14:53] jelmer: why not just reuse trac testsuite? [14:53] gnomefreak, you can't push to http locations [14:53] santagada, That doesn't setup bzr repositories, etc [14:53] i used the lp: [14:53] oops wriong link [14:53] thanks [14:57] jelmer: adapting version_control/tests/svn_fs.py for bzr doesn't seem impossible... [14:59] There's alot more bugs with trac-bzr. Nonworking URLs to files in specific revisions seems common. I might get back to help out fix some of it, but I'm currently in a hurry. [14:59] Thanks alot for your time! [15:00] vila: ping [15:01] jam: pong, can we talk now or a bit later ? (I need to switch machine if we talk) [15:01] speakman: this seems to be a problem with having evolving versions of trac and bzr and not having automated test cases... it probably works for some versions of bzr and trac :| [15:01] jelmer: bzr selftest git fails very quickly: http://pastebin.com/m516466ff [15:02] bialix, can you be more specific ? :-) [15:02] santagada: yes, probably. My other installations works pretty good. [15:02] jelmer: that's all I get [15:02] (another thing is the null: revision which keeps showing on top on Timeline.) [15:03] bialix, Any chance you can file a bug ? I'll have a look at it later [15:03] it seems like bzr test suite crashed [15:03] santagada, that still means somebody has to put effort in, and I doubt it would be much quicker than writing a testsuite for bzr from scratch [15:04] I don't have usual stack trace in the end [15:07] speakman: file a bug on trac-bzr [15:07] jelmer: maybe [15:12] hmm, lazy commands already landed ! [15:12] I never noticed [15:15] jelmer: bug 323207 [15:15] Launchpad bug 323207 in bzr-git "`bzr.exe selftest git` fails" [Undecided,New] https://launchpad.net/bugs/323207 [15:15] bialix, thanks! [15:16] * bialix pushing the branch with bzr.exe support patch to lp [15:18] jelmer: the patch: https://code.launchpad.net/~bialix/bzr-git/bzr.exe/+merge/3258 [15:24] speakman: did you reported your bug on trac-bzr? === dereine[OFF] is now known as dereine === dereine is now known as dereine[OFF] === dereine[OFF] is now known as dereine [16:06] santagada: sorry, no time for that at the moment :( [16:06] santagada: will get back to it later, or other bugs (there are some in that package) [16:06] now have to leave, thanks for your time [16:29] lifeless, awake? [16:36] hi rockstar [16:36] hi rocky [16:36] heyo ;) [16:37] Peng_, thanks! [16:37] jelmer, turn my tab blue... [16:37] rockstar: Sorry :-) [16:37] jelmer, :) [16:38] jelmer, for the bzr-stats changes, should I request a review from you? [16:38] rockstar: yeah, from either me or John [16:39] perhaps we should create a team for bzr-stats. are you in the bzr developers team? [16:39] jelmer, I don't think so. I don't think I've made many contributions to bzr. [16:51] rockstar, I've created a bzr-stats team that now owns bzr-stats; you should be able to request review from that team [16:55] jelmer, can you set the default review team for lp:bzr-stats to be that team? [16:57] rockstar, how do I do that? [16:58] jelmer, I did it. [16:59] jelmer: dulwich/test/__init__.py uses only test_objects, test_repository and test_pack as modules for testing. but test_index and test_object_store are not. should I update this? [17:01] bialix: thats fixed in my branch already (i added another test as well) [17:01] Jc2k: I'd like to add test runner for dulwich. What is your branch? [17:03] bialix: you mean instead of make check? [17:04] my branch is at lp:~johncarr/dulwich/git-serve [17:04] (shy) yes, sir [17:04] i think jelmer has merge it, but maybe not pushed yet [17:05] like this: http://bazaar.launchpad.net/~bialix/intelhex/trunk-w-tags/annotate/head%3A/setup.py (lines 75-99) [17:05] I don't have twisted [17:06] ah i see [17:06] i use nosetests instead of twisted [17:07] do you think my test runner will be too much of trouble for you and jelmer? [17:07] though it's optional [17:07] its not up to me, but i have no objections to it. [17:08] what it means "up to me"? [17:08] its not my decision [17:09] jelmer said: "ah, ok". so I'll prepare the patch then [17:34] Can anyone think of a workaround for bug #97715 ("bzr log DIR should show changes under DIR")? [17:34] Launchpad bug 97715 in bzr "bzr log DIR should show changes under dir" [Medium,Confirmed] https://launchpad.net/bugs/97715 [17:34] I ask because 'bzr log -v' (the obvious workaround) is too slow. [17:34] I can't think of any other workarounds, but maybe someone here can? === kiko is now known as kiko-afk === bac is now known as bac_afk [18:03] I need help... I have two branches, master and next... I was doing work in the "next" branch by switching to it.. However when I switch back to the master branch, the next changes are in this branch! The log however says that the changes were made to branch nick "next". So lost.. Help... please... [18:05] how can I get a machine readable log from bzrlib? Do I have to write a log formatter? [18:38] Can anyone think of a workaround for bug #97715 ("bzr log DIR should show changes under DIR")? [18:38] Launchpad bug 97715 in bzr "bzr log DIR should show changes under dir" [Medium,Confirmed] https://launchpad.net/bugs/97715 [18:38] I ask because 'bzr log -v' (the obvious workaround) is too slow. [18:38] I can't think of any other workarounds, but maybe someone here can? [18:42] Hi. Quick & noob question: [18:42] I've two branchs: mainline (main branch) and working (the branch I work on) [18:43] When I do changes and commits on my working branch then I call: cd ../mainline && bzr merge ../working [18:43] but I figured out that I lose all commits I did on my working branch [18:43] you do not lose them [18:43] luks well yes I know [18:44] But what I want to do is to apply changes on mainline and also commits with commits messages I wrote while commting in working [18:44] Is there a way to do that ? [18:44] are you planning to remove the working branch after merging it? [18:44] kfogel, I don't think there is a good way to work around that. brisbane-core will be *some* help I think [18:45] luks no I just work on it everytime, and use the mainline one to apply patchs... etc [18:46] jelmer: thanks [18:46] Goundy: then there is no good way [18:46] ha :/ [18:46] Goundy: there is a way if you don't mind destrying the working branch [18:46] luks well no way ^^ [18:46] thank you :-) [18:46] but if you intend to continue to work in it, it would cause problem [18:46] +s [18:47] I see yea [18:48] luks then is there a good & quick way to specify commit message for each change ? [18:48] btw, what I meant was "bzr rebase ../mainline && cd ../mainline && bzr pull ../working" [18:48] Goundy: specify? [18:48] where? [18:49] luks well atm I do: bzr commit -m "my message" [18:49] and this message applies to all my changes [18:49] kfogel, are the emacs-related bugs tagged in launchpad, or is there a list of emacs-related bugs? [18:49] for example if I want a different message for each file is there another way than bzr commit /path/to/file/file.c -m "message" ? [18:50] jelmer: look for "emacs-adoption" tag, I think [18:50] I don't know, I personally use qcommit which is a window that allows me to select files and type the message [18:51] easier to pick which files you want to commit, but probably not what you are looking for [18:52] luks I hate UI for DVCS softwares ^^ [18:52] but thanks for the tip ;) [18:52] well, it's easier than typing and tab-completing the filenames [18:53] jelmer: I've just add bug #246891 to that list, and see this comment: [18:53] Launchpad bug 246891 in bzr "bzr log -v is slow" [High,Confirmed] https://launchpad.net/bugs/246891 [18:53] usually I also hate the gui for all vcs [18:53] https://bugs.edge.launchpad.net/bzr/+bug/246891/comments/8 [18:53] Launchpad bug 246891 in bzr "bzr log -v is slow" [High,Confirmed] [18:53] but during commit they help a lot [18:54] luks sure but I really think DVCS shouldn't be used through GUI front ends... that really sucks [18:54] And sometimes you get hard bugs I hate that >< [18:54] Goundy: what's so special about DVCSes? [18:54] luks DVCSes are fine but not GUI front ends written for them that's it [18:55] well not all DVCSes are cool of course (CVS and SVN -> trash :P) [18:55] And that was the troll of the day \o/ === bac_afk is now known as bac [18:56] Eh. CVS isn't so bad, really... It's very clear upfront about what it can and can't do. Of the things it can do, it does very well [18:57] heh might be true but as I said: that's a troll :P [18:57] personnaly I was using svn, but once I discovered bazaar >_<' I really liked it ! that's an awesome release [18:57] Fast, simple and powerful (nothing missing) [18:59] jelmer: hunh. In launchpad's bzr bug tracker, I just did "Search: Enter bug ID or keywords:" and entered "emacs-adoption". Now, I *know* there's at least one bug with that tag, because I just tagged 246891 with it, and there should be four others from before as well. But nothing came up. [18:59] kfogel, if you go to the "bugs" tab in zbr [18:59] jelmer: ooooooh [18:59] there's a list of links on the right with tags [18:59] advanced search [19:00] So "tags" are different from "keywords". [19:00] yeah, found it [19:06] anyone have an idea about: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/51820 [19:38] lifeless: I have Yves's bzr.log when you're ready. === mtaylor_ is now known as mtaylor [20:16] lifeless: so... bzr uncommit gives me a confirmation dialog [20:16] lifeless: bzr revert, on the other hand, happily just works [20:16] lifeless: except that sometimes I've accidentally hit enter after the word revert when I just meant to revert one file [20:16] and have lost an entire tree's worth of changes [20:17] perhaps a config option to turn on revert confirmation dialogs? [20:17] bzr uncommit has a way to undo - bzr revert doesn't [20:17] Goundy: so, there's a patch to gcommit that allows per-file commit messages [20:18] damn [20:18] just missed him === thekorn_ is now known as thekorn [21:44] is there a flag or something to tell bzr-email to send from the server vs. from the client? [22:04] i have two identically configured servers and branches. committing to a branch on one sends email from the server process itself (apache), committing to a branch the other sends (or tries and fails) from the client. === kiko is now known as kiko-afk === mark2 is now known as markh === cody-somerville_ is now known as cody-somerville === edcrypt_ is now known as edcrypt === dereine is now known as dereine[OFF]