[00:17] <bob2> haha
[00:18] <lifeless> I wrote it in 2002, it got package by dato in late 2007 :P
[00:19] <lifeless> no idea why
[02:34] <NfNitLoop> Saluton?
[02:35] <NfNitLoop> durr, wrong channel.
[02:45] <dfrbn> are there any options for integrating netbeans with bazaar currently?
[02:45] <dfrbn> (aside from writing a plugin ;)
[02:51] <NfNitLoop> Last I checked (which, admittely, was a while ago), no.
[02:51] <NfNitLoop> There *is* an Eclipse plugin.
[02:52] <NfNitLoop> and the eclipse plugin is modularized in a way that should be mostly reusable if someone wanted to make a Netbeans plugin.
[02:52] <NfNitLoop> (ie: POJOs and communicating w/ bzr via XML output)
[02:52] <NfNitLoop> again, all this is a bit dated.  I just use the commandline. :p
[02:53] <NfNitLoop> dfrbn: are you developing on *nix by any chance?
[02:53] <dfrbn> NfNitLoop, yeap, entirely
[02:53] <NfNitLoop> I recently have become fond of a program called 'meld'.
[02:54] <NfNitLoop> it's a visual diff analizer, but it works with svn and bzr to show you local changes in your working copy.
[02:54] <NfNitLoop> and resolve conflicts.
[02:54] <NfNitLoop> I find meld + command-line bzr better than any IDE plugins I've used.
[02:54] <dfrbn> nice, tks for that, I'll check it out.
[02:55] <NfNitLoop> hint w/ meld though, for bzr it always wants you to run it pointing at the root dir of your repo.
[02:55] <dfrbn> right on. I do like using svn in netbeans, I find the ui very comfortable to use
[02:55] <NfNitLoop> which you can handly do with:  meld `bzr root`
[02:55] <NfNitLoop> :)
[02:56] <dfrbn> I'm debating on where to host a project and am leaning to mercurial just cuz of the netbeans integration. But I don't have any experience with either.
[02:57] <NfNitLoop> I've been keeping an eye on mercurial...
[02:57] <NfNitLoop> as an openly biased bzr groupie, here are the reasons I stick with bzr:
[02:57] <NfNitLoop> 1) bzr keeps things simpler.  (without actually lacking features)
[02:58] <NfNitLoop> 2) bzr-svn is the best svn integration I've seen.
[02:58] <NfNitLoop> 3) the bzr team has been really responsive to my questions/bug-reports/etc.
[02:59] <NfNitLoop> Oh, and launchpad.net is pretty spiffy.  :)
[02:59] <dfrbn> So I could have my own master repo in subversion for the project (which I already do), and  merge my changes into bzr and use both?
[03:00] <NfNitLoop> dfrbn: Yep!
[03:00] <dfrbn> agreed on launchpad :)
[03:00] <NfNitLoop> you can do 'bzr branch' from a svn repo and it is a fully fledged bzr repo.
[03:00] <NfNitLoop> which just happens to have enough metadata to merge back into a svn repo.
[03:01] <dfrbn> interesting
[03:01] <dfrbn> I like the idea of keeping my own master repo
[03:02] <dfrbn> as long as it's easy to merge back and forth
[03:03] <NfNitLoop> There are a couple caveats...
[03:03] <NfNitLoop> SVN can't represent nonlinear history.
[03:04] <NfNitLoop> so it's best to keep a bzr branch that mirrors svn, then merge (or rebase) onto that, then push that up to SVN to keep things linear.
[03:04] <NfNitLoop> you wouldn't lose any data doing it another way...
[03:04] <NfNitLoop> but your svn history would be...
[03:04] <NfNitLoop> not what svn users expect. :)
[03:04] <dfrbn> gotcha
[03:04] <NfNitLoop> (This applies to any DSCM that interfaces with SVN)
[03:05] <dfrbn> I see. the only kinda distributed one I've ever worked with was a windows email based on called code coop by relisoft. it was actually pretty cool, but that was a long time ago
[03:06] <NfNitLoop> hopefully you'll find that things have improved quite a bit since then. :)
[03:06] <dfrbn> :)
[03:07] <NfNitLoop> the bzr wiki has a great into to different distributed workflows.
[03:07] <NfNitLoop> let me find it...
[03:07] <NfNitLoop> http://bazaar-vcs.org/Workflows
[03:07] <NfNitLoop> heh, easy enough.
[03:07] <dfrbn> I use subversion at work at am not a fan. Hopefully if I get some experience with something new I can persaude them to switch :)
[03:08] <NfNitLoop> SVN is exactly what it intended to be -- better than CVS. :p
[03:08] <dfrbn> haha, that I is true
[03:09] <NfNitLoop> or, if they're reluctant to switch, you can just push for using bzr to manage branching/merging.
[03:09] <NfNitLoop> or, if they're very opposed, you can do what I do and just use it without telling anyone.
[03:09] <NfNitLoop> hehe
[03:11] <dfrbn> heh. cheers
[04:32] <Peng_> jml: You should check out ack as an alternative to grep. http://betterthangrep.com/
[04:32] <Peng_> Oh, uh. The URL used to be a bit less...arrogant. :P
[04:35] <jml> Peng_: one day :)
[04:35]  * Peng_ pokes at Google Code.
[04:35] <Peng_> jml: Only takes 30 seconds.
[05:00] <NfNitLoop> Peng_: oh, cool, I'm so installing that at work.
[05:01] <NfNitLoop> Our codebase is so... disorganized that I *constantly* just grep the entire codebase to see where a function is being called.  :/
[05:01] <lifeless> don't you have tags ?:P
[05:01] <NfNitLoop> LOL.
[05:01] <NfNitLoop> We don't even have /** code docs */
[05:01] <NfNitLoop> *sigh*
[05:02] <lifeless> I mean etags -r .
[05:02] <lifeless> or something equivlaent
[05:03] <NfNitLoop> aah.  That... might work, but...
[05:03] <NfNitLoop> our include paths are nonstandard and don't match how things are organized in SVN.
[05:03] <NfNitLoop> It's all a sad mess.
[05:04] <NfNitLoop> But it pays well and looks good on the resume. :p
[05:15] <Peng_> For searching a *lot* of data, ack is probably slower than grep, since it's Perl.
[05:16] <Peng_> It's smart exclude rules usually make up for that, and anyway, it's usually fast enough.
[05:16] <NfNitLoop> I don't mind waiting 2 more seconds if it takes me 2 seconds less to type out the command. :p
[05:17] <Peng_> Right.
[05:28] <Peng_> jelmer_: ping
[09:38] <lifeless> jelmer_: gimme a shout when you're around re bug 185200
[11:10] <lifeless> svnvie damage...
[11:10] <lifeless> clicking on a dirname - contents, filename - log activity'
[11:11] <lifeless> dirname revno - log activity, filename revno - contents
[15:11] <fbond> Hi.  I've seen some odd conflict representations using bzr-rebase.  With normal merges, the conflicting areas in the file are always well-constructed.  If I remove one side of the conflict, the other fits back into the context the way it should.  But I've seen some conflict representations with bzr-rebase that would result in dropped lines if I remove one side of the conflicting area.
[15:11] <fbond> Is this a known issue?  I'm having a hard time characterizing it completely.  I'll probably have to spend a bit of time experimenting to reproduce it.
[15:14] <jelmer> fbond: bzr-rebase basically does a set of "bzr merge -c" commands
[15:14] <fbond> jelmer: Does it sound like what I'm saying would have any validity at all?
[15:15] <jelmer> fbond: oh, the situation you are seeing might be correct
[15:16] <jelmer> fbond: but inherit to the way rebase works
[15:16] <fbond> jelmer: As in rebase is unable to get it right due to the nature of what it is doing?
[15:17] <jelmer> fbond: it can get it right but you're seeing the conflict of one of those cherrypicks, not of the whole rebase operation
[15:17] <fbond> Right, I see these conflicts along the way as I rebase several revisions.
[15:18] <fbond> The conflict is correct, but the textual representation of it is missing lines on one side or the other.
[15:19] <fbond> jelmer: I'll see if I can produce a good example and create a bug report, I guess.
[15:22] <jelmer> fbond: yeah, it's much easier to talk about a specific situation
[18:03] <ElMonkey> hola
[18:07] <ElMonkey> anyone got some tips for installing loggerhead on debian lenny?
[18:07] <ElMonkey> i am currently failing to grasp the process
[18:09] <SamB> isn't that, like, stable or something now?
[18:10] <ElMonkey> there's no loggerhead package in stable apparently
[18:12] <ElMonkey> quite possibly i am overlooking something, though
[18:13]  * SamB always uses testing
[18:15] <ElMonkey> my sysadmin skills are a bit rusty
[18:15] <ElMonkey> also, as this is a remote machine i am trying to get things to work on, i'd rather not nuke it
[18:19] <ElMonkey> i just thought things would be simpler
[18:19] <ElMonkey> but alas, looks like there's no way without jumping hoops
[18:45] <vadi2> how can I make bzr delete all ignored files? it seems clean-tree doesn't do that
[18:58] <LarstiQ> vadi2: clean-tree has an --ignored option
[18:58] <LarstiQ> ElMonkey: there is no backport?
[19:03] <ElMonkey> LarstiQ, none that i'd discovered
[19:03] <ElMonkey> i installed bzr from lenny-backports, but i didnt find loggerhead
[19:11] <vadi2> LarstiQ: thank you
[20:11] <jelmer_> ElMonkey: I might upload a backport to lenny-backports at some point
[21:00] <klbate> Is there some command to make 'bzr push' always run 'bzr sign-my-commits' before pushing?
[21:00] <klbate> Just so I know before I hack up something of my own.
[21:16] <jkakar> klbate: I have this http://pastebin.ubuntu.com/149103/ in my ~/.bazaar/locations.conf which makes Bazaar sign my changes when I 'bzr commit'.  Not quite what you're asking for, but it may be a potential solution.
[21:27] <klbate> jkakar: Yeah, that works too. Thanks!
[21:27] <klbate> I didn't find anything about those config options in 'man bzr'.
[21:28]  * klbate puts that in [DEFAULT].
[22:15] <jkakar> klbate: 'bzr help configuration' has a bunch of useful information, including the details about creating signatures.
[22:16] <jkakar> klbate: If you haven't discovered them yet, the following commands are very helpful for discovering Bazaar's functionality: 'bzr help commands', 'bzr help topics' and 'bzr help hidden-commands'.
[23:11] <ElMonkey> jelmer, it would certainly be appreciated, at least by me :)