[00:00] <dOxxx> verterok: what would you say the state of bzr-java-lib is? Enough to create a bzr client for an IDE?
[00:01] <RenatoSilva> dOxxx: don't you like eclipse?
[00:01] <verterok> dOxxx: it should be enough :) and if it's not is a bug ;-)
[00:01] <verterok> dOxxx: there is a lot of room ofr improvements
[00:01] <verterok> *for
[00:02] <dOxxx> RenatoSilva: nope, I've been using IDEA for a very long time. I've tried Eclipse a few times and I've never liked it. No offense intended, it just doesn't suit me I guess :)
[00:02] <dOxxx> verterok: cool. maybe I can massage bzr4idea into a working state. haha.
[00:03] <verterok> heh, cool! :-D
[00:04] <RenatoSilva> dOxxx: I like eclipse very much
[00:05] <dOxxx> RenatoSilva: Each to his own :)
[00:05] <dOxxx> hopefully we can both use bzr with our favourite IDE
[00:07] <RenatoSilva> verterok: didn't work changing the permissions :(
[00:18] <RenatoSilva> verterok: didn't work changing redstone to 1.1 :(
[00:18] <verterok> RenatoSilva: :(
[00:18] <RenatoSilva> I'm getting now org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: unknown command "C:\Arquivos de programas\Bazaar\bzr.exe"
[00:20] <verterok> don't make any sense :(
[00:20] <dOxxx> I got that one a few times when I was running mvn test repeatedly
[00:20] <RenatoSilva> If the errors were not random, I would be able to debug it in eclipse at least :(
[00:21] <dOxxx> before I updated my local branch and xmloutput plugin
[00:21] <RenatoSilva> I just branched a new copy of java lib, and xmloutput is up-to-date
[00:24] <dOxxx> weird
[00:26]  * RenatoSilva is crying
[00:35] <RenatoSilva> when you do any bzr operation, does any file involved is OUT of the branch?
[00:36] <RenatoSilva> for example, does bzr create a lock file in tmp dir or user's profile, rather than inside the branch?
[00:36] <lifeless> no
[00:36] <RenatoSilva> I suspect some lock is lost somewhere, even in Windows registry
[00:44] <RenatoSilva> verterok: permission r/w to all in mvn dir, c:/mt (temp), and c:/bzr-java-lib, still failing
[00:57] <dOxxx> verterok: any idea what happened to CygwinFilePathAdapter?
[01:03] <dOxxx> what date format does IBazaarAnnotation return from getDate(linenumber)?
[01:07] <RenatoSilva> verterok: oh that patch for redstone wasn't necessary, the dev version fixed that in 2007 http://xmlrpc.svn.sourceforge.net/viewvc/xmlrpc/trunk/source/redstone/xmlrpc/XmlRpcClient.java?r1=28&r2=32
[01:08] <RenatoSilva> and didn't release it since that o.O
[01:17] <dOxxx> bah... looks like bzr4idea was using a forked version of bzr-java-lib :P
[01:17] <dOxxx> it's referencing stuff that's never existed
[01:18] <wgrant> Java developers love to do that :(
[01:26] <dOxxx> I'll be damned if I can find it.
[01:27] <dOxxx> aha
[01:53] <verterok> dOxxx: if the changes are good, I'll be happy to merge them in bzr-java-lib, I'll take a look to their branch
[01:54] <verterok> RenatoSilva: thanks for the bug triage ;-)
[01:56] <dOxxx> verterok: the branch is lp:~bzr4idea/bzr-java-lib/trunk. I merged trunk into my localy copy of it and there are a few conflicts but I think I sorted them out. The changes seem to be mostly minor adjustments of the interface to suit the bzr4idea developer
[01:57] <RenatoSilva> verterok: np, btw can't find any reference to redstone.xmlrpc in bzr-java-lib/bzr-eclipse, just like it's not used o.O
[01:57] <dOxxx> verterok: although, there is one fix to the Ls command for a bug in xmlls, which when given the parameters "." and "--non-recursive" returns an empty list
[01:57] <dOxxx> well, workaround, not fix :)
[01:58] <dOxxx> and I checked, the bug still exists in 2.0.1
[01:58] <RenatoSilva> dOxxx: be careful to not make it compatible with idea, but break eclipse :)
[01:58] <verterok> dOxxx: and in bzr-xmloutput trunk I assume :)
[01:59] <dOxxx> RenatoSilva: nah, the changes aren't that major.
[01:59] <verterok> RenatoSilva: from the top of my head: XMLRPCCommandRunner
[02:00] <dOxxx> verterok: oh, yeah, since I just checked using my normal bzr install with the xmloutput trunk I installed earlier this evening
[02:00] <RenatoSilva> verterok: yeah, just found it :)
[02:00] <dOxxx> verterok: basically, the following command returns an empty list: bzr xmlls . --non-recursive
[02:00] <RenatoSilva> verterok: I wanted to know if bzr-eclipse itself also used redstone lib, but no it doesn't
[02:01] <verterok> RenatoSilva: no, bzr-eclipse only uses bzr-java-lib...or should :)
[02:01] <verterok> dOxxx: oh, ok. sounds like a bug :)
[02:02] <verterok> RenatoSilva: as I merged your encoding-fixes branch in trunk, it's ok to delete the jobs from hudson?
[02:02] <RenatoSilva> verterok: ok
[02:02] <dOxxx> verterok: yes, I think it's a bug in the underlying bzr ls though, which is just reflected in xmlls
[02:02] <verterok> dOxxx: oh, that's bad...but good catch :)
[02:03] <dOxxx> verterok: well, I think :)
[02:03] <dOxxx> hmm
[02:03] <dOxxx> "bzr ls ." works
[02:04] <dOxxx> there is no --non-recursive option for bzr ls
[02:04] <dOxxx> so maybe it is specific to xmlls
[02:04] <verterok> dOxxx: probably the option name changed, and xmloutput is still using the old name
[02:05] <dOxxx> aha: https://bugs.launchpad.net/bzr/+bug/158690
[02:05] <verterok> RenatoSilva: if you need to run a new branch on hudson, just create a new job, but copying bzr-java-lib[-xp] job and change the branch url ;)
[02:05] <dOxxx> so it looks like that bug was "solved" by removing the option :P
[02:11] <verterok> dOxxx: heh, looking a the bzr code, ls changed a lot since I worked on xmlls, probably I introduced that bug :)
[02:12] <RenatoSilva> verterok: ok thanks
[02:12] <dOxxx> verterok: it happens :) I'm filing a bug on xmloutput now
[02:12] <verterok> dOxxx: ok, thanks!
[02:13] <dOxxx> verterok: https://bugs.launchpad.net/bzr-xmloutput/+bug/482901
[02:14] <verterok> dOxxx: I "think" I have a fix :)
[02:14] <verterok> but no tests :/
[02:14] <dOxxx> woot :)
[02:14] <RenatoSilva> verterok: from where did you take xmlrpc 1.1.1, and even 1.1? didn't find it in SF
[02:14] <RenatoSilva> verterok: latest release there is 1.0 I think
[02:14] <dOxxx> verterok: should be simple enough to write a test for it, if you have a framework for creating a temp branch with some files
[02:14] <verterok> RenatoSilva: 1.1 from the redstone page, 1.1.1 build it myself from a svn checkout
[02:15] <verterok> dOxxx: bzr test framework! ;-)
[02:15] <dOxxx> aha!
[02:15] <dOxxx> if you want, I can take a crack at writing the test
[02:15] <dOxxx> I have a little experience with the bzr test framework
[02:15] <verterok> dOxxx: be my guest, and to get the fix too ;)
[02:16] <dOxxx> verterok: have you already made the fix? or can you send me a patch?
[02:16] <RenatoSilva> verterok: ah ok, just a suggestion, instead of 1.1.1, use 1.1_custom0, or 1.1_verterok0 etc... (not sure if mvn can deal with that though)
[02:16] <verterok> RenatoSilva: but it's 1.1.1, they tagged/commited the version bump
[02:17] <RenatoSilva> verterok: ah ok
[02:17] <verterok> RenatoSilva: but I can change it to 1.1.1-dev or something
[02:17] <verterok> RenatoSilva: I pushed the xmlrpc-1.1.1 to my maven repo @ verterok.com.ar
[02:17] <RenatoSilva> verterok: ok, just a suggestion to clearly identify that 1.1.1 is not released yet :)
[02:18] <verterok> RenatoSilva: yeap, good point :)
[02:18] <verterok> dOxxx: sort of a fix, mostly a hack...gimme 1' and I'll pastebin it
[02:19] <dOxxx> k
[02:19] <verterok> dOxxx: also, xmlls is one of the xml commands that don't have tests :/
[02:19] <dOxxx> verterok: I see.
[02:20] <dOxxx> verterok: maybe I can steal the bzr ls tests :)
[02:20] <verterok> dOxxx: I did that for most of the xml* commands :)
[02:20] <verterok> dOxxx: http://pastebin.ubuntu.com/319005/
[02:22] <verterok> ok, guys, I need to leave for a while. see you later!
[02:22] <verterok> dOxxx: thanks for taking that bug ;)
[02:23] <verterok> RenatoSilva: apologize the delay to get the encoding fix merged, thanks a lot for getting it done and poking me :)
[02:23] <dOxxx> seeya verterok
[02:23]  * verterok away not here right now
[02:23] <verterok> ooops, wrong command :p
[02:33]  * RenatoSilva just had a big battle with a roach
[02:35] <dOxxx> RenatoSilva: bug "fixing" ? ;)
[02:39] <RenatoSilva> no, a real roach
[02:40] <RenatoSilva> I could kill it, but not the tests bug :(
[02:42] <dOxxx> :(
[02:51] <dOxxx> Hmmm... I'm getting a popup dialog when running bzr selftest which says "This application has failed to start because QtHelp4.dll was not found." I wasn't getting this earlier...
[02:51] <bob2> --no-plugins
[02:58] <dOxxx> yeah except I'm tyring to test a plugin :)
[02:59] <dOxxx> oh well, it's not stopping the tests from running, it's just annoying
[03:17] <RenatoSilva> dOxxx: you created a patch for the test failure I've reported? nice :)
[03:18] <RenatoSilva> verterok: when you are back here, the update site didn't work in galileo. I've extracted features and plugins, it works nice, but the build does not contain the redstone patch
[03:18] <dOxxx> RenatoSilva: yeah, it was pretty simple as far as I could see
[03:19] <RenatoSilva> verterok: by work nice I mean no error in log view when opening eclipse
[04:16] <seiflotfy> hey guys
[04:17] <seiflotfy> quick question
[04:17] <seiflotfy> i uncommited and unreverted locally
[04:17] <seiflotfy> not i want to change the state of trunk on launchpad
[04:17] <seiflotfy> to the old state
[04:18] <beuno> seiflotfy, you want Launchpad's branch to have the same state as you do locally?
[04:19] <seiflotfy> yeah
[04:19] <beuno> seiflotfy, bzr push --overwrite
[04:19] <seiflotfy> the branch on launchpad had 1292
[04:19] <seiflotfy> and i want it back on 1278
[04:21] <beuno> seiflotfy, bzr push --overwrite will do it
[04:22] <seiflotfy> thx
[04:22] <seiflotfy> worked
[12:32] <thrope> hi - when using bzr-git is there a way to specify the remote git branch to use for pull or dpush (or the original branch)
[14:22] <dOxxx> Good morning.
[15:02] <maxb> I would like to learn more about the bzrlib python api ... is there a good place to get started? Perhaps some pointers to key concepts / methods to look at first?
[15:20] <dOxxx> maxb: try having a look at bzrlib/builtins.py. It contains all the bzr commands and should give you a general idea of where to go for a specific feature.
[15:27] <maxb> thanks
[15:55] <maxb> When 'bzr rebase' drops you back to the shell for conflict resolution, is there any way to find out which revision it dropped you at?
[16:33] <dOxxx> maxb: I'm just guessing here, but try 'bzr revno' ?
[17:12] <maxb> dOxxx: This seems to tell you about the last revision that completed rebasing. That's not really all that helpful unless the history is non-branchy *and* you know it well.
[17:13] <dOxxx> maxb: ah, sorry, was just a guess. I'm fairly new to bzr myself.
[17:14] <maxb> No problem. It seems that bzr-rebase needs a bit of work to bring it up to the standards of hg's offering
[17:17] <dOxxx> it's a plugin, not a core command, so it may not be receiving the same level of attention
[17:21] <dOxxx> however, if you file bugs or ask a question at the project page (https://answers.launchpad.net/bzr-rewrite/+addquestion) you may get a better reply than mine :)
[17:22] <dOxxx> asking on the bazaar mailing list may also work
[17:23] <LarstiQ> maxb: all I know is bzr-rebase has been renamed bzr-rewrite
[17:24] <maxb> LarstiQ: Indeed. A bit odd. Especially since it still needs to be imported as 'rebase'
[17:26] <jelmer> maxb, It's slowly being renamed
[17:28] <maxb> jelmer: Hi. Would you happen to know why rebase attempts to only rebase a left-most path of revisions? That seems fundamentally incorrect to me
[17:28] <jelmer> maxb, I've just replied to your email
[17:29] <maxb> ah, thanks :-)
[17:29] <jelmer> maxb: Basically bzr-rebase was written as a tool to rebase a small local branch on top of an upstream bzr-svn branch
[17:29] <jelmer> maxb: not really as a suisse army knive to do large-scale history rewriting
[17:30] <jelmer> maxb: Not that I object to improvements of course :-)
[17:31] <jelmer> some of the other commands in bzr-rebase do rewrite more (e.g. rebase-foreign)
[17:31]  * maxb will wait for your respose to percolate through the internet and read that first
[18:08] <Xello> Hello
[18:08] <Xello> How would I change a file to say its rev 39?
[18:09] <Xello> and then I could comit the changes
[18:11] <maxb> You wish to alter a file to be the same as it was in a previous revision and then commit that as a change?
[18:11] <maxb> bzr revert
[18:11] <Xello> Well I made changes to a file over many commits
[18:11] <Xello> Then I realized the way I was doing it was correct
[18:12] <Xello> so I would like to replace the file thats there with rev 39 of that file
[18:12] <Xello> then make changes and / or commit
[18:12] <LarstiQ> Xello: bzr revert -r 39 <file>
[18:12] <Xello> cool
[18:12] <Xello> LarstiQ: Thanks
[18:13] <LarstiQ> Xello: don't forget to thank maxb too :)
[18:13] <Xello> whops im an ass
[18:13] <Xello> maxb: Thanks for the help
[18:16] <Xello> Yes! it worked
[18:16] <Xello> I <3 bzr
[18:17] <Xello> In celebration I give to you all a link to some music
[18:17] <Xello> http://www.jamendo.com/en/album/44337
[18:17] <LarstiQ> Xello: heh, thank you :)
[18:17] <Xello> its free and legal (creative commons)
[18:18] <Xello> I like to feel like I'm an adventure movie when I'm coding sometimes
[19:42] <theAdib_> I want to see what is the last commit message. bzr log gives me everything. How can I limit bzr log to only give me the very last one?
[19:42] <dOxxx> bzr log -r-1
[19:42] <theAdib_> dOxxx, ah thx. (I tried bzr log -1 with no success)
[19:42] <dOxxx> np
[22:38] <eMerzh> what is the best way to nest an external svn tree into a bzr branch? ... i've checkout my svn tree into a branch A and joined it into my main branch ...
[22:38] <jelmer> eMerzh: Ideally the solution would be nested tree support in bazaar
[22:38] <eMerzh> is there a way to do it without the branch 'A' ?
[22:38] <jelmer> until then there are a couple of 3rd-party solutions
[22:39] <jelmer> using e.g. config-manager, scmproj or bzr-externals
[22:39] <eMerzh> what are the pbm with join ?
[22:39] <jelmer> eMerzh, join basically merges in the svn tree
[22:39] <jelmer> meaning your local repository would basically include the contents of the svn one
[22:40] <eMerzh> ok jelmer... thanks
[22:40] <jelmer> you can then do merges from the svn branch whenever you need to update it
[22:41] <eMerzh> ok.. dumb question but.. is there a plan (date?) to support Real nested tree so?
[22:44] <jelmer> eMerzh: I'm not aware of any specific plans
[22:59] <spiv> Good morning.
[23:03] <jelmer> hi spiv
[23:13] <igc1> medical stuff for a few hours - bbl