[00:14] fullermd: isn't it spelled aluminium rather than aluminum? [00:15] http://en.wikipedia.org/wiki/Aluminium [00:15] Of course not. [03:41] When browsing a bzr repository in a non-CLI UI, would you expect the "last revision" to be the last physical change to the file, like 'bzr log' does which includes merges, or the revision number that corresponds to the last physical change? [03:42] It seems loggerhead shows the last physical change, omitting revisions where a changed file was merged into the mainline, while 'bzr log' is aware of merges. [03:42] To me, it seems a little confusing but not being a long-time bzr user, I figured I'd ask you guys. [04:21] hi everyone :) === jfroy_ is now known as jfroy [07:25] peitschie: hey ! Don't lose hope, VCS is a life-time memory thing, the tool itself matters less than the organization, keep fighting for the organization, your choice of tool will follow :-) [07:25] vila: thanks for the support :). I suspect this "revolution" is just starting to gain a little momentum [07:26] as I alluded to in the email, bazaar has really opened up the dev practices of a lot of the other programmers [07:26] peitschie: indeed, it's far too soon to declare the game is over [07:26] it was almost satisfying to hear them complaining continually about the features svn lacked in comparison... and this is only after around 2months of dvcs use [07:27] and the decision was to keep svn right ? [07:28] we never truly left svn [07:28] The sucky part is where ugly fallout from the limitations of svn become recycled as arguments against bzr-sans-svn. [07:28] we used bazaar to supplement the main dev activities in svn [07:28] so, *you* can still use bzr-svn transparently [07:28] that was part of the challenge actually... the svn core changed some things and caused us a little extra heart-ache than pure bzr likely would have [07:29] with the new ghost handling that jelma was saying is in bzr-svn, quite likely :) [07:29] initially, I had some major issues with logs and such when trying to have multiple devs privately using bzr-svn [07:29] ghost support is here to stay [07:29] unless our changes synced up, annotate and log would crash most of the time [07:30] so file bugs and tag them with ghost [07:30] already have :)... i even started fixing one but just keep running out of time to see it through to teh end [07:30] python +qt is not my usual dev stack so it takes me a bit to get my way around still right now [07:31] at the moment i am definitely still using bzr at work... i suspect a few other programmers will continue as well [07:31] hehe [07:31] main trick is keeping my head out of the firing line if another dev gets a little stuck... it seems a lot of this flack was simply because i was the highest profile user of said system [07:32] yeah, with great power come great responsibility :-P [07:32] Ah, but this is a corporation. With great responsibility comes no real power at all :p [07:33] lol... aint that the truth! [07:33] Ah, but the world is changing, everyday :) [07:34] A new power is raising... err wait, no, I didn't say that, far too risky to be wrongly quoted :) [07:34] the kind of infuriating part is that i'm a junior dev... and at least 3 other seniors signed off on this move... gah... dev life was never going to be fair though... I should know enough from teh flack that flies around open-source projects [07:34] We fear change. [07:34] aint that the truth [07:34] Now, that's a fundamental truth [07:35] And this explain a lot why DVCS is hard to deploy (so to speak) [07:35] That's why I choose to use bzr; that way I don't have to worry about changing :p [07:35] lol fullermd :P [07:35] or any VCS for that matter [07:35] Oh, no, a VCS is easy to deploy. As long as it's the one you're already using. [07:36] yes... in many ways it is understandable [07:36] The nuclear strong force is not the greatest force in the universe. Inertia takes it out behind the woodshop and stomps it silly. [07:36] in the case of my recent experience with bzr, those are expensive failures for the company... having said that, the major impossibility is showing the efficiency improvements from use a distributed workflow [07:37] ha ha, expensive failures. Tsk, tsk, the costs you can't prove don't exist :) [07:37] oh yes [07:38] it's easy so say that half a day for 15devs being unable to commit is expensive [07:38] doesn't exist ! [07:38] hehe [07:38] They have so many other things to do, they are just whining, come on guys [07:38] my thoughts exactly [07:39] anyway, my point was: we welcome refugees (cough, and I'm not saying this to cover my French president :-/) [07:40] so much of it was pure knee-jerk as the project schedule is slipping for some very large architectural reasons (and incomplete designs)... which have wasted far more than this hiccup did [07:41] ha ha, but *here* it's easy to see who the culprit is ! [07:41] vila: i can tell :)... it's been nice to hang out here and chill with some people that aren't claiming bzr just ate some babies when it clearly didnt lol [07:41] >.<... oh yes [07:41] Don't be silly. _Important_ people make architectural decisions. They surely don't make mistakes. It's those little people screwing with development tools (and unapproved dev tools, at that! Damn unlicensed hackery...) [07:41] cough, chicken and goats on the other hand [07:42] oh yes [07:42] yeah, those hippies... and communists I heard.... [07:42] and the occasional snake i'm told [07:43] snake ? Sacrificing snakes works ? Nobody ever tell me anything ! [08:53] fullermd: That's __Important__ not _Important_, the former carries the idea that they can't be modified while the later is only a convenience that can be worked around with a simple #pragma [08:54] rofl [08:54] it took you 70mins to come up with that?! :P [08:54] * fullermd looks around for something to smack vila with. [09:06] peitschie: yeah, I'm notoriously slow :) [09:07] lol :) [09:07] peitschie: and properly killing a snake takes time [09:07] ahh... of course of course! how thoughtless of me... wouldn't want you to rush that just for a good one-liner! [09:10] avoiding typos (my #1 ruining-joke weakness) is best addressed by staring at them for *at least* 20 minutes too [09:10] fullermd: don't try with a goat, I've got some new very powerful protective spells [09:11] That's the sort of statement best taken way out of context :p [09:12] lol === martineo_ is now known as martineo [11:41] wow... http://www.alltelleringet.com/ totally off-topic, sry, but I think a few of you may appreciate [11:45] hi [11:45] vila, are you familiar with bzr-pipe? [11:49] vila: Very cool. :-) [11:50] zyga_: nope, I use looms, but ask your question anyway or I can't try to answer it ;-) [11:50] mkanat: glag you liked it ;) [11:50] glad even [11:50] * vila back to regular typos... [11:50] :-) [11:50] Ah, good. The world is back on its axis. [11:55] vila, I just noticed bzr switch-pipe does not store local changes [11:55] vila, perhaps the version I'm using is not compatible with bzr (on 10.10) [12:09] zyga_: by store local changes you mean shelve ? [12:11] zyga_: keeping uncommitted changes in the working tree while switching is a feature, I often need to commit code I just wrote while not being in the :right" thread (or pipe) [12:11] "right" (I try to keep the world on its axis, excuse my typos ;) === Daviey- is now known as Daviey === zyga_ is now known as zyga [13:07] vila, no I mean bzr switch-pipeline [13:07] vila, I found the issue [13:07] vila, bzr-pipeline is _fantastic_ [13:07] vila, the issue was, untracked files are _not_ stored/restored by the pipeline [13:08] vila, so if you add a new file and start hacking on it (but not bzr add it) it will not be hidden by bzr switch-pipeline [13:45] zyga: that's a bzr issue then, there are still unversioned files that you want to keep with you (even if there are unversioned files that you want to hide) [13:47] zyga: examples at https://code.edge.launchpad.net/~vila/bzr/323111-orphan-config-option/+merge/35690 [13:47] zyga: comments or bugs with your use case welcome === tchan1 is now known as tchan [14:24] hai [14:25] quick question. i have a branch and modified+commited a file, now the maintainer of the parent branch cherry picked some changes but did so by putting those things in by hand. [14:25] whats now the best way to revert those files back to the parent? [14:31] revisionspec is my friend i guess :) [19:42] 'evening [19:51] hi all, using centralized workflow model and bzr+ssh:// access, is it possible to restrict user which have write access to only use particular username/email as commitor? i.e. to have a binding between the commitor and ssh login user to prevent people faking as another commitor? [20:25] nope [20:25] and that would also prevent the use of push [20:25] and merge [20:26] use gpg-signed commits for authentication [20:26] using the committer for authentication is as safe as using the From: header in email. [20:28] hingwah: Yeah, I have a plugin that does it. [20:28] hingwah: It does prevent use of push. [20:28] (If the push contains other people's commits.) [20:29] hingwah: http://bzr.mozilla.org/bzr-plugins/enforcecommitter [20:30] hingwah: It's not a security mechanism, though--it's just a way of making sure that people have set their "whoami" properly. [20:34] ddaa, thx, I didn't know there is commit signing [20:34] ddaa, bzr sign-my-commits ? [20:34] mkanat, let me check,thx [20:38] hingwah: also check http://wiki.bazaar.canonical.com/ConfiguringBzr#check_signatures [20:39] then there's the entire topic of configuring and using gpg [20:39] but this chat window is a bit too small for that :-) [23:54] hey guys, in maverick what happened to olive-gtk? [23:55] it doesn't appear to be in the bzr-gtk package anymore [23:57] err... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598703 [23:57] Debian bug 598703 in wnpp "RFP: olive-gtk - Graphical frontend for Bazaar" [Important,Open] [23:57] that's not good