[00:05] <Odd_Bloke> jelmer: Night!
[00:05] <awilkins> ipython is certainly... pretty
[00:43] <blueyed> well.. revision-info isn't really the last commit though..
[00:43] <blueyed> but that's ok as in "branch not updated (from both sides) in the last x minutes"
[01:16] <Peng> jelmer: I don't have PQM access.
[01:31]  * Verterok heading to bed
[02:40] <ubotu> New bug: #199712 in bzr-stats "stats plugin crashes" [Undecided,New] https://launchpad.net/bugs/199712
[03:53] <justjeff> Good morning / afternoon / evening, all. I'm seeking a little wisdom.
[03:57] <justjeff> Specifically if I were to write a GUI front-end to Bazaar in C++, would be a great benefit to using Bazaar's Python API (through, e.g., Boost.Python), or would it be perfectly reasonable to interact with Bazaar repositories / working trees solely through the bzr tool?
[03:59] <justjeff> (Most GUI front-ends or IDE plugins for CVS, SVN, etc. do the latter, no?)
[03:59] <jdong>  yes, IMO you should be using the API for serious programs
[03:59] <jdong> the API has much more stability, command line output is subject to UI change
[04:00] <justjeff> Do you know of any other programs written in C++ doing so, and if so, what path they have taken? (That is, whether they're using Boost.Python to link into Bazaar, or some other method.)
[04:01] <justjeff> Or is somebody maintaining a C++ API already?
[04:03] <justjeff> (Back in about 30, have to get lunch.)
[09:47] <scode> Is there any support for authentication/authorization with read/write 'bzr serve':s? I didn't find this mentioned in the docs, but perhaps I am missing it.
[10:02] <james_w> scode: no, I don't think so.
[10:06] <scode> Thanks!
[10:12] <asabil> scode: use bzr+ssh:// if you want auth
[10:31] <scode> asabil: Yeah, was hoping to avoid ssh though (to minimize need for integration with the host system)
[11:09] <lifeless> jdong: for ide's, we're now recomending xmloutput
[11:13] <Odd_Bloke> Morning.
[11:15] <lifeless> hi
[11:15] <lifeless> I'm about to go offline till back in au
[11:16] <Odd_Bloke> lifeless: Have a good trip! :)
[11:16] <lifeless> thanks
[11:16] <lifeless> you too :>
[11:18] <asabil> is there any way to install bzr-svn with bzr 1.2 ?
[11:18] <jelmer> not yet
[11:18] <asabil> oki
[11:18] <beuno> hey lifeless, I think most of us are. Thanks for everything  :D
[11:22] <Odd_Bloke> jelmer: Is there a plan for the next release yet?
[11:22] <jelmer> I was hoping to do it during the sprint but was distracted by other things
[11:26] <beuno> jelmer, we just need the deactivate thing in nautilus, right?
[11:26] <jelmer> beuno: yep
[11:27] <beuno> (I've been looking into it, but haven't gone as far as a patch yet)
[11:33] <Odd_Bloke> beuno: Stop distracting him! :p
[11:38]  * beuno can't understand why his suitcase won't close if there are _less_ things than when he got here
[11:39] <dato> beuno: things ate a bit too much?
[11:40] <beuno> dato, :p     english food seems to be fattening
[12:31] <ubotu> New bug: #199801 in olive "Olive translations are not being used" [Undecided,New] https://launchpad.net/bugs/199801
[17:35] <bialix> hi
[17:35] <james_w> hi bialix. How are you?
[17:35] <bialix> hi kames_w
[17:36] <bialix> sorry, james_w
[17:36] <bialix> looking for some one who help me write README for check eol pre-commit
[17:38] <james_w> bialix: I can probably do that.
[17:39] <bialix> I think this document need to describe format of .checkeol file
[17:39] <bialix> now it sectioned
[17:40] <bialix> and I hope it's valuable improvements
[17:41] <bialix> here is my branch: https://code.launchpad.net/~bialix/+junk/checkeol
[17:42] <bialix> I'm again starting to get English courses, so I hope to improve my skill during this year
[17:43] <bialix> james_w: btw IPython project leaning to switch to launchpad and bzr
[17:44] <bialix> I read yesterday in their ML discussion about bzr vs hg
[17:44] <james_w> bialix: that would be cool.
[17:44] <bialix> it seems like launchpad is killer feature for them
[17:45] <bialix> Ville Vanio who made request for check eol hook is winows maintainer of ipython
[17:45] <bialix> s/winows/windows/
[17:46] <bialix> ipython guys have unresolved question about migrating their Trac tickets base
[17:47] <james_w> they should contact someone from the launchpad team, I assume there is a way for them to do it.
[17:47] <james_w> unfortunately I don't know who.
[17:48] <bialix> it seems like their already do
[17:49] <bialix> at least vcs-import mirrors their svn main branch
[17:50] <bialix> https://code.launchpad.net/~bialix/+junk/checkeol
[17:50] <bialix> sorry
[17:50] <bialix> https://launchpad.net/ipython
[17:50] <jelmer> jamesh is the person to talk to about migration of bugs to launchpad
[17:52] <bialix> hi jelmer
[17:54] <bialix> jelmer: what it means 'bzr-svn on Windows needs to rock' from brainstrom wiki page?
[17:54] <jelmer> Hi Alexander
[17:54] <jelmer> bialix: Not sure, I don't think I was there when they had that discussion
[17:55] <bialix> ok.
[17:56] <jelmer> afaik bzr-svn on windows works as long as you're willing to install .exe's from various locations
[17:56] <jelmer> but that's nothing new on Windows afaik
[17:56] <bialix> yep
[18:28] <bialix> james_w: I wrote some text or README. Could you look at it?
[18:35] <james_w> bialix: it looks good to me.
[18:36] <bialix> good :-) thanks
[19:25] <neh> hi all... I've got a bound repo that I had forgotten about, so I went and moved the remote repo. I have changes in my working tree, and need to switch to the new location of the remote repo. What's the best way? I'm thinking I should do commit --local on my changes, then do a bzr switch, then commit normally. Should that work?
[19:27] <awilkins> Add a --remember to your next pull/merge
[19:29] <Odd_Bloke> Evening.
[19:31] <neh> Ah, that will set the bound location as well? So, can I just pull --remember from the new location without losing my new changes?
[19:33] <awilkins> Maybe unbind / bind?
[19:34] <neh> I was just thinking that might be simplest...
[19:36] <neh> thanks, awilkins
[20:33] <nexus10> hi - I'm getting myself tangled up with permission/owner/group problems on an sftp repo -- can anyone suggest some best practices?
[20:35] <nexus10> I set the repo up to be g+w on everything -- and I have a cron script that commits to this repo as user cronbot group cronbot, these being the user and group who own all files in the repo
[20:36] <Odd_Bloke> nexus10: The Bazaar sprint has just finished, so the majority of the bzr development team and community are heading home or sleeping (or both) ATM.
[20:36] <Odd_Bloke> You'd probably be best off either waiting until Monday, or sending an email to the Bazaar mailing list. :)
[20:37] <nexus10> Odd_Bloke: great, thanks -- I'll direct this to mail then
[20:47] <ubotu> New bug: #199935 in bzr-dbus "bzr-dbus doesn't give its hooks names" [Undecided,New] https://launchpad.net/bugs/199935
[20:50] <jelmer> that reminds me
[20:50] <jelmer> any debian developers around that could sponsor an upload of bzr-dbus?
[21:10] <awilkins> jelmer: 0.4 r 945 isnt' comatible with 1.2 anymore because of the "hardlink" parameter
[21:12] <jankeesvwoezik> Hi Guys, Can I ask a question thats been asked a million times before?
[21:12] <Odd_Bloke> jankeesvwoezik: Don't ask to ask. :)
[21:13] <jankeesvwoezik> is there a Gui for Bazaar for Mac?
[21:13] <jankeesvwoezik> I searched but i didn't find any
[21:13] <jankeesvwoezik> only windows and linux
[21:13] <jankeesvwoezik> right?
[21:13] <Odd_Bloke> jankeesvwoezik: The main GUI project is bzr-gtk, which I know can work on Mac (though doesn't look native).
[21:13] <awilkins> Does the gtk stuff work on mac?
[21:13]  * jdong grumbles
[21:14] <jdong> a combination of merging and rebasing ruined a bzr-svn mirror
[21:14] <Odd_Bloke> awilkins: Well, phanatic uses a Mac, so I expect so. :p
[21:14] <jankeesvwoezik> Odd_Bloke: Can you give me a clue how to get it runing
[21:14] <jdong> more conflicts than a Ballmer-Theo De Raadt meeting.
[21:14] <Odd_Bloke> jankeesvwoezik: I'm afraid I really have no idea how to go about it.
[21:15] <Odd_Bloke> jelmer might have a better idea. (IMPLICIT PING)
[21:15] <Odd_Bloke> jdong: Rebasing has that effect. :(
[21:15] <awilkins> Freebasing?
[21:15] <awilkins> :-P
[21:16] <jdong> Odd_Bloke: aye, but when tracking and pushing back to svn I got to a point where I had to use rebase to push it back into svn
[21:16] <jdong> Odd_Bloke: I wish bzr-svn had a "git svn dcommit" type feature to prevent that
[21:16] <jdong> (implicit ping :D)
[21:16] <jdong> (implicit Launchpad bug)
[21:16] <jelmer> awilkins: the 0.4 branch is meant to be used with bzr.dev
[21:17] <jelmer> awilkins: the 0.4.8 branch is meant to be compatible with 1.2
[21:17] <awilkins> jelmer: Ah
[21:17] <jankeesvwoezik> doesn't anyone uses a mac over here :)
[21:17] <jankeesvwoezik> thats funny
[21:17] <jelmer> jankeesvwoezik: there are a couple of people that do
[21:17] <jankeesvwoezik> ok
[21:17] <jelmer> jankeesvwoezik: but afaik most use bzr-gtk on the mac
[21:18] <Odd_Bloke> jdong: Could you describe what dcommit does for me?  Hard though it may be to believe, the git docs aren't helping me out.
[21:18] <jankeesvwoezik> but not to many
[21:18] <jelmer> jdong: ruined in what sense?
[21:18] <jdong> jelmer: well I rebased 3 times successfully, then I believe I did a merge afterwards and attempted to rebase again...
[21:18] <Odd_Bloke> jdong: NM, jelmer is vastly more qualified to talk about bzr-svn than I am. :)
[21:18] <jelmer> jdong: rebase rewrites your history so it has to be used with care
[21:18] <jdong> jelmer: and rebase seemed to try to start at the beginning of history
[21:18] <jdong> jelmer: and every step seemed to result in error
[21:18] <jdong> conflict that is
[21:19] <jdong> with it pulling what seemed to be arbitrary revisions of my code in history
[21:19] <jdong> jelmer: I'm quite sure it was user error on my part
[21:19] <jelmer> jdong: what does git svn dcommit do?
[21:19] <jankeesvwoezik> how do you run gtk on mac? Does anyone know?
[21:20] <jdong> jelmer: I believe it commits to svn by diffing each "missing" commit and pushing that commit into Subversion
[21:20] <jdong> jelmer: so all the commits get into Subversion but not the ancestry of merges
[21:20] <jelmer> jdong: that still won't work if you have used rebase
[21:20] <jelmer> jdong: also, it breaks roundtripping
[21:20] <jdong> jelmer: well.. I used rebase because bzr-svn suggested that I use rebase
[21:20] <jelmer> jdong: Where does it suggest that?
[21:21] <jdong> jelmer: it refused to push into svn after a few merge cycles
[21:21] <jelmer> jdong: that's incorrect
[21:21] <jdong> jelmer: it said something along the lines of needing to rewrite revision history
[21:21] <Odd_Bloke> So does it essentially rebase the missing revisions on top of trunk?
[21:21] <jdong> and that I needed to either rebase or push into a non-repository-root
[21:21] <Odd_Bloke> Where 'it' == 'dcommit'.
[21:21] <jdong> Odd_Bloke: yeah pretty much
[21:21] <jelmer> jdong: ah, you're not using branches in Subversion?
[21:21] <jdong> jelmer: correct
[21:23] <jelmer> jdong: I wouldn't object to supporting something like dcommit but keep in mind that you could then only push into subversion, never pull from it (you'd get a Branches diverged error)
[21:24] <jdong> jelmer: hmm, well I have no reason for wanting dcommit except for the circumstance I arrived in. Do you have a better suggestion for how I could've avoided my initial error in the first place?
[21:24] <jelmer> jdong: Actually, suggesting rebase is correct
[21:24] <jelmer> jdong: Don't use merge
[21:24] <jdong> jelmer: ok so I should use rebase instead of merge for all workflow?
[21:25] <jelmer> jdong: yes - or use branches in your subversion repository
[21:25] <jdong> jelmer: ok, gotcha
[21:25] <jdong> jelmer: does the rebase help information forewarn my disaster?
[21:27] <awilkins> cd svn
[21:27] <awilkins> oos
[21:28] <jelmer> jdong: maybe it should have a warning about not being a good idea in general to use rebase
[21:28] <jdong> jelmer: :)
[21:37] <nexus10>  I was just about to start using bzr-svn to allow topic branching, disconnected commits etc for a primary repo that needs to stay as svn -- ant pointers re rebase /merge etc? What else should I read?
[21:38] <nexus10> s/ant/any/
[21:39] <Odd_Bloke> nexus10: If you only want a single commit in the SVN repository for each of the feature/topic branches (and are happy for them not to be stored in SVN while under development) you shouldn't need to worry about merge/rebase.
[21:39] <Odd_Bloke> You'll use merge, but you won't need to worry. :p
[21:40] <nexus10> Odd_Bloke: and if I'd like to keep the commit messages for each bzr commit, and shove them all into svn, then what's the best plan?
[21:41] <Odd_Bloke> nexus10: Rebasing onto SVN trunk, I believe, but IANA bzr-svn user so am probably not the best person to let you know.
[21:43] <nexus10> Odd_Bloke: ok, thanks
[22:20] <distatica> hey folks, I'm trying to remember here, there's a way to do something similar to trac + subversion, with bzr, but it's not the trac bzr plugin..
[22:28] <distatica> loggerhead, there we go
[22:52] <Odd_Bloke> jelmer: My concern with hiding hooks under the covers is that they can be used to do quite a lot of stuff which the user might object to.  At least being able to see that _something_ other than bzrlib is doing stuff when $ACTION is performed could be valuable.
[22:53] <jelmer> Odd_Bloke: At the very least, the command should be hidden imo.
[22:56] <jelmer> Odd_Bloke: Except for user-specific hooks, I think hooks are an implementation detail
[22:57] <awilkins> jelmer: 0.4.8 test log from win32
[22:57] <awilkins> http://filebin.ca/rctjoz/test.939.zip
[22:57] <Odd_Bloke> jelmer: Well, currently, the only hook I have is being provided by a plugin (bzr-dbus, in this case), so all hooks are, to an extent, user-specific.
[22:57] <jelmer> Odd_Bloke: It could be useful to know that commit notifications by email are enabled but the fact that there is a Python "set_rh" hook registered by the "email" plugin is not all that interesting
[22:58] <jelmer> Odd_Bloke: With user-specific I mean site-specific hooks, such as the shell hooks
[22:58] <Odd_Bloke> jelmer: Sure.
[22:59] <Odd_Bloke> jelmer: So are you saying that this command in its current form should be hidden, or that any command which describes what hooks happen on particular actions should be hidden?
[23:00] <jelmer> Odd_Bloke: The command in its current form should at the very least be hidden imho
[23:01] <Odd_Bloke> OK, I accept that.
[23:01] <jelmer> Odd_Bloke: But I'd prefer to have "bzr commit" be more vocal about what hooks it's running
[23:03] <jelmer> Odd_Bloke: I guess to word it a bit better, I think this is internal data that shouldn't be exposed to the user like that but I think it's perfectly fine to have a hidden command to aid developers.
[23:05] <Odd_Bloke> jelmer: Sure.
[23:05] <Odd_Bloke> Thanks for the review. :)