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