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