[00:05] jelmer: Night! [00:05] ipython is certainly... pretty [00:43] well.. revision-info isn't really the last commit though.. [00:43] but that's ok as in "branch not updated (from both sides) in the last x minutes" === mw is now known as mw|out [01:16] jelmer: I don't have PQM access. [01:31] * Verterok heading to bed [02:40] New bug: #199712 in bzr-stats "stats plugin crashes" [Undecided,New] https://launchpad.net/bugs/199712 [03:53] Good morning / afternoon / evening, all. I'm seeking a little wisdom. [03:57] 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] (Most GUI front-ends or IDE plugins for CVS, SVN, etc. do the latter, no?) [03:59] yes, IMO you should be using the API for serious programs [03:59] the API has much more stability, command line output is subject to UI change [04:00] 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] Or is somebody maintaining a C++ API already? [04:03] (Back in about 30, have to get lunch.) [09:47] 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] scode: no, I don't think so. [10:06] Thanks! [10:12] scode: use bzr+ssh:// if you want auth [10:31] asabil: Yeah, was hoping to avoid ssh though (to minimize need for integration with the host system) [11:09] jdong: for ide's, we're now recomending xmloutput [11:13] Morning. [11:15] hi [11:15] I'm about to go offline till back in au [11:16] lifeless: Have a good trip! :) [11:16] thanks [11:16] you too :> [11:18] is there any way to install bzr-svn with bzr 1.2 ? [11:18] not yet [11:18] oki [11:18] hey lifeless, I think most of us are. Thanks for everything :D [11:22] jelmer: Is there a plan for the next release yet? [11:22] I was hoping to do it during the sprint but was distracted by other things [11:26] jelmer, we just need the deactivate thing in nautilus, right? [11:26] beuno: yep [11:27] (I've been looking into it, but haven't gone as far as a patch yet) [11:33] 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] beuno: things ate a bit too much? [11:40] dato, :p english food seems to be fattening [12:31] New bug: #199801 in olive "Olive translations are not being used" [Undecided,New] https://launchpad.net/bugs/199801 === weigon_ is now known as weigon === pmezard_ is now known as pmezard [17:35] hi [17:35] hi bialix. How are you? [17:35] hi kames_w [17:36] sorry, james_w [17:36] looking for some one who help me write README for check eol pre-commit [17:38] bialix: I can probably do that. [17:39] I think this document need to describe format of .checkeol file [17:39] now it sectioned [17:40] and I hope it's valuable improvements [17:41] here is my branch: https://code.launchpad.net/~bialix/+junk/checkeol [17:42] I'm again starting to get English courses, so I hope to improve my skill during this year [17:43] james_w: btw IPython project leaning to switch to launchpad and bzr [17:44] I read yesterday in their ML discussion about bzr vs hg [17:44] bialix: that would be cool. [17:44] it seems like launchpad is killer feature for them [17:45] Ville Vanio who made request for check eol hook is winows maintainer of ipython [17:45] s/winows/windows/ [17:46] ipython guys have unresolved question about migrating their Trac tickets base [17:47] they should contact someone from the launchpad team, I assume there is a way for them to do it. [17:47] unfortunately I don't know who. [17:48] it seems like their already do [17:49] at least vcs-import mirrors their svn main branch [17:50] https://code.launchpad.net/~bialix/+junk/checkeol [17:50] sorry [17:50] https://launchpad.net/ipython [17:50] jamesh is the person to talk to about migration of bugs to launchpad [17:52] hi jelmer [17:54] jelmer: what it means 'bzr-svn on Windows needs to rock' from brainstrom wiki page? [17:54] Hi Alexander [17:54] bialix: Not sure, I don't think I was there when they had that discussion [17:55] ok. [17:56] afaik bzr-svn on windows works as long as you're willing to install .exe's from various locations [17:56] but that's nothing new on Windows afaik [17:56] yep [18:28] james_w: I wrote some text or README. Could you look at it? [18:35] bialix: it looks good to me. [18:36] good :-) thanks === weltende is now known as welterde [19:25] 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] Add a --remember to your next pull/merge [19:29] Evening. [19:31] 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] Maybe unbind / bind? [19:34] I was just thinking that might be simplest... [19:36] thanks, awilkins [20:33] hi - I'm getting myself tangled up with permission/owner/group problems on an sftp repo -- can anyone suggest some best practices? [20:35] 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] 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] You'd probably be best off either waiting until Monday, or sending an email to the Bazaar mailing list. :) [20:37] Odd_Bloke: great, thanks -- I'll direct this to mail then [20:47] New bug: #199935 in bzr-dbus "bzr-dbus doesn't give its hooks names" [Undecided,New] https://launchpad.net/bugs/199935 [20:50] that reminds me [20:50] any debian developers around that could sponsor an upload of bzr-dbus? [21:10] jelmer: 0.4 r 945 isnt' comatible with 1.2 anymore because of the "hardlink" parameter [21:12] Hi Guys, Can I ask a question thats been asked a million times before? [21:12] jankeesvwoezik: Don't ask to ask. :) [21:13] is there a Gui for Bazaar for Mac? [21:13] I searched but i didn't find any [21:13] only windows and linux [21:13] right? [21:13] jankeesvwoezik: The main GUI project is bzr-gtk, which I know can work on Mac (though doesn't look native). [21:13] Does the gtk stuff work on mac? [21:13] * jdong grumbles [21:14] a combination of merging and rebasing ruined a bzr-svn mirror [21:14] awilkins: Well, phanatic uses a Mac, so I expect so. :p [21:14] Odd_Bloke: Can you give me a clue how to get it runing [21:14] more conflicts than a Ballmer-Theo De Raadt meeting. [21:14] jankeesvwoezik: I'm afraid I really have no idea how to go about it. [21:15] jelmer might have a better idea. (IMPLICIT PING) [21:15] jdong: Rebasing has that effect. :( [21:15] Freebasing? [21:15] :-P [21:16] 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] Odd_Bloke: I wish bzr-svn had a "git svn dcommit" type feature to prevent that [21:16] (implicit ping :D) [21:16] (implicit Launchpad bug) [21:16] awilkins: the 0.4 branch is meant to be used with bzr.dev [21:17] awilkins: the 0.4.8 branch is meant to be compatible with 1.2 [21:17] jelmer: Ah [21:17] doesn't anyone uses a mac over here :) [21:17] thats funny [21:17] jankeesvwoezik: there are a couple of people that do [21:17] ok [21:17] jankeesvwoezik: but afaik most use bzr-gtk on the mac [21:18] 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] but not to many [21:18] jdong: ruined in what sense? [21:18] jelmer: well I rebased 3 times successfully, then I believe I did a merge afterwards and attempted to rebase again... [21:18] jdong: NM, jelmer is vastly more qualified to talk about bzr-svn than I am. :) [21:18] jdong: rebase rewrites your history so it has to be used with care [21:18] jelmer: and rebase seemed to try to start at the beginning of history [21:18] jelmer: and every step seemed to result in error [21:18] conflict that is [21:19] with it pulling what seemed to be arbitrary revisions of my code in history [21:19] jelmer: I'm quite sure it was user error on my part [21:19] jdong: what does git svn dcommit do? [21:19] how do you run gtk on mac? Does anyone know? [21:20] jelmer: I believe it commits to svn by diffing each "missing" commit and pushing that commit into Subversion [21:20] jelmer: so all the commits get into Subversion but not the ancestry of merges [21:20] jdong: that still won't work if you have used rebase [21:20] jdong: also, it breaks roundtripping [21:20] jelmer: well.. I used rebase because bzr-svn suggested that I use rebase [21:20] jdong: Where does it suggest that? [21:21] jelmer: it refused to push into svn after a few merge cycles [21:21] jdong: that's incorrect [21:21] jelmer: it said something along the lines of needing to rewrite revision history [21:21] So does it essentially rebase the missing revisions on top of trunk? [21:21] and that I needed to either rebase or push into a non-repository-root [21:21] Where 'it' == 'dcommit'. [21:21] Odd_Bloke: yeah pretty much [21:21] jdong: ah, you're not using branches in Subversion? [21:21] jelmer: correct [21:23] 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] 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] jdong: Actually, suggesting rebase is correct [21:24] jdong: Don't use merge [21:24] jelmer: ok so I should use rebase instead of merge for all workflow? [21:25] jdong: yes - or use branches in your subversion repository [21:25] jelmer: ok, gotcha [21:25] jelmer: does the rebase help information forewarn my disaster? [21:27] cd svn [21:27] oos [21:28] jdong: maybe it should have a warning about not being a good idea in general to use rebase [21:28] jelmer: :) [21:37] 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] s/ant/any/ [21:39] 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] You'll use merge, but you won't need to worry. :p [21:40] 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] 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] Odd_Bloke: ok, thanks [22:20] 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] loggerhead, there we go [22:52] 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] Odd_Bloke: At the very least, the command should be hidden imo. [22:56] Odd_Bloke: Except for user-specific hooks, I think hooks are an implementation detail [22:57] jelmer: 0.4.8 test log from win32 [22:57] http://filebin.ca/rctjoz/test.939.zip [22:57] 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] 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] Odd_Bloke: With user-specific I mean site-specific hooks, such as the shell hooks [22:58] jelmer: Sure. [22:59] 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] Odd_Bloke: The command in its current form should at the very least be hidden imho [23:01] OK, I accept that. [23:01] Odd_Bloke: But I'd prefer to have "bzr commit" be more vocal about what hooks it's running [23:03] 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] jelmer: Sure. [23:05] Thanks for the review. :)