[00:41] <Manfre> give the following situation, I create a local branch, make changes and push those back up to lp, then some one else branches my changes and then pushing those back up to the same lp branch, how do I update my local branch without needing to do a merge?
[00:41] <hmeland> bzr pull?
[00:42] <jelmer> colbrac, still there?
[00:42] <colbrac>  yes
[00:43] <Manfre> Just tried bzr pull and got "Bazaar has encountered an internal error"
[00:43] <Manfre> i guess i'll use the work around of delete local branch and rebranch
[00:43] <bob2> well, that's a bug (or corruption), but bzr pull is generally what you want
[00:43] <colbrac> jelmer: ja
[00:43] <Odd_Bloke> Manfre: Could you pastebin the error, please?
[00:43] <Odd_Bloke> ubottu: paste
[00:44] <jelmer> colbrac: Just wanted to say thanks for the patches to bzr-gtk you sent over the last week or so.
[00:44] <colbrac> :) No problem
[00:45] <jelmer> colbrac: I'll see if I can review and merge some of them during the next couple of days
[00:45] <colbrac> It's kind of 'wetting my feet' in the world of gtk programming
[00:45] <jelmer> Ah :-)
[00:45] <colbrac> start with the launch fix :)
[00:45] <Manfre> Odd_bloke: http://pastebin.com/d54356310
[00:46] <Manfre> sorry, it was the bzr status call after the pull that caused problems
[00:46] <Manfre> ...potentially
[00:46] <colbrac> jelmer: and I try to use Olive in 'production'.. so deficiencies stand out :)
[00:48] <Odd_Bloke> Manfre: That error looks familiar.  I'm fairly sure it's been fixed in bzr.dev...
[00:49] <bob2> #235657
[00:49] <jelmer> colbrac: Yeah, that helps
[00:49] <jelmer> colbrac: Personally, I try to use nautilus-bzr on a regular basis
[00:50] <bob2> though, you seemed to have pulled and merged the same branch - maybe undoing the merge will unconfuse bzr
[00:50] <Odd_Bloke> Manfre: http://bugs.launchpad.net/bzr/+bug/235407
[00:50] <colbrac> jelmer: Good for you guys I didn't try to use nautilus-bzr yet. ;)
[00:50] <jelmer> (-:
[00:51] <colbrac> jelmer: I started on a pure PyGTK version of the olive gui.. I hope that sounds interesting?
[00:51] <jelmer> colbrac, what do you mean by that exactly?
[00:52] <colbrac> a OliveGui class that builds the main window instead of the glade one
[00:52] <Manfre> thanks Odd_bloke
[00:52] <colbrac> so self.vbox.add(menubar) etc
[00:52] <colbrac> :P
[00:52] <Odd_Bloke> Manfre: No problem.
[00:52] <jelmer> colbrac: Ahh, yeah, that is certainly interesting
[00:53] <colbrac> lp:~colbrac/bzr-gtk/noglade
[00:53] <colbrac> still very rough of course etc etc
[00:53] <jelmer> colbrac: Submitting that in small (but still usable) portions will probably help it being merged quickly, rather than a single big patch
[00:53] <colbrac> well..
[00:54] <colbrac> I can make it such that it can be a drop in replacement of the glade one
[00:54] <colbrac> I think at least :P
[00:54] <ToyKeeper> If my viz changes are accepted, that scratches most of my bzr gui itches.  :)
[00:55] <colbrac> ToyKeeper: Did you play around with the diff positioning?
[00:55] <colbrac> The unsorted bookmarks were a big itch for me personally. :)
[00:55] <ToyKeeper> Yeah, I haven't been able to find a layout I like better.
[00:56] <ToyKeeper> The main change I'd still like to see is a way to view all branches in a repo at once, using viz.
[00:56] <colbrac> jelmer: I don't really know how a full GUI can be merged in in bits..
[00:56] <jelmer> colbrac, there are different windows in olive for example
[00:56] <colbrac> oh that..
[00:56] <jelmer> it makes sense to convert one window at a time
[00:56] <colbrac> I did that
[00:56] <jelmer> and merge that separately
[00:57] <colbrac> it's 1 big patch but with commits per dialog
[00:57] <jelmer> I agree the main window is probably pretty hard to convert in stages
[00:57] <Odd_Bloke> ToyKeeper: +1 on the all branches view.
[00:57] <colbrac> most of the dialogs are done already
[00:57] <colbrac> only that info dialog looks hard so I didn't try it yet
[00:58] <colbrac> The olive dialogs cleanup -take3 message in the bzr-gtk list
[01:15] <jelmer> Odd_Bloke, still there?
[01:23] <colbrac> jelmer: I now have all widgets of the glade olive main window in a OliveGui class. Only to paste in the right signals and figure out how to properly reference the icons :)
[01:42] <Odd_Bloke> jelmer: Yeah, though I suspect you may be gone by now. :)
[01:48] <Odd_Bloke> jelmer: Now I'm going to bed, so it'll have to wait until the morning.
[01:59] <mwhudson> is bzr really going to be released with a repo format called
[02:00] <mwhudson> 'Bazaar development format 1 with subtree support (needs bzr.dev from before 1.6)\n'
[02:00] <mwhudson> ?
[03:05] <abentley> mwhudson: I hope not.
[03:06] <mwhudson> abentley: good good
[03:29]  * igc lunch
[04:42] <brmassa> guys, is there a program that tracks a CVS repo and imports the changes to bzr and the other way round?
[04:44] <mwhudson> cvs->bzr yes
[04:44] <mwhudson> not the other way
[04:45] <fullermd> Going either way is probably doable.  Both at the same time is another story.
[04:45] <brmassa> mwhudson: so its not possible to commit to a bazaar branch and it replicates/pings the CVS?
[04:46] <AfC> You can always do the "Create a Bazaar branch inside the CVS checkout and manually shuttle changes back and forth between the two systems"
[04:46] <AfC> Manual
[04:47] <brmassa> AfC: hmmm not quite what i had in mind. well... np them.
[07:06]  * mwhudson waves https://bugs.edge.launchpad.net/bzr/+bug/248604 around
[07:13] <stewart> hi! i'm trying to "bzr merge" from a file that contains a merge directive - and i get  "bzr: ERROR: bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///home/stewart/mysql/.bzr/repository/') has no revision ('volpato@cajarana-20080715052545-2fu5im6ll8o2jr6x',)"
[07:13] <stewart> now... does this mean the merge directive is incomplete, corrupt? against a tree i don't have?
[07:13] <stewart> or a bzr bug
[07:14] <lifeless> stewart: it means it was made against a rev you don't have - probably something in the 6.0 trunk to some such
[07:15] <stewart> lifeless: ahh.. okay. the error message could probably be nicer (or at least on the same screen :)
[07:15] <stewart> it's like 3 pages of python backtrace up
[07:15] <lifeless> stewart: ouch; cxare to file a bug ?
[07:15] <stewart> can do
[07:17]  * stewart field bug... waits for magic irc bot to say it's done
[08:45] <igc> night all
[08:46] <gour> igc: night
[09:19] <lifeless> poolie: ping
[09:34] <Odd_Bloke> Moin.
[09:40] <kiorky> hello, with bzr svn, is this possible to use local svn check outs as a start ?
[09:40] <lifeless> kiorky: yes
[09:40] <kiorky> lifeless: do you have any clue or pointer on how to do that?
[09:41] <lifeless> kiorky: cd to the checkout, start running bzr commands
[09:41]  * AfC does that rather frequently, not always wanting to import everything and therefore not needing to use bzr-svn et al
[09:43] <kiorky> then how can i map the svn/bzr thing for commiting back to the svn repo?
[09:43] <kiorky> when i commit on bzr
[09:43] <kiorky> s/commit/push/
[09:44] <lifeless> kiorky: 'bzr checkout svn://url FOO; cd FOO; bzr merge BZRBRANCH; bzr commit'
[09:44] <lifeless> kiorky: (you need a bzr native tree to do merges in (as far as I  know, jelmer may know more)
[09:46] <kiorky> lifeless: ha, i dont know if i was clear on what i wanted to do. I have a svn co somewhere , telling its in "foo", but not yet bzr stuff. Rather than doing bzr co svn://myuri FOO, i want to use bzr inside the svn's foo one directly, saving me from co-time as i have it allready
[09:47] <lifeless> kiorky: you can do that, but as far as I know you can't run one specific bzr command - merge - because svn checkouts don't have a place to store pending merge data
[09:49] <kiorky> lifeless: so the only way to go is to co again?
[09:49] <lifeless> kiorky: yes. but once you have done that you can branch locally from it and it won't have to fetch it over the network again
[09:57] <Odd_Bloke> ubottu: paste
[09:58] <lifeless> Odd_Bloke: ?
[10:04] <Odd_Bloke> lifeless: I was going to paste something, then changed my mind. :)
[10:05] <lifeless> Odd_Bloke: :)
[10:07] <jelmer> 'morning
[10:08] <lifeless> jelmer: can you bzr merge in a svn co?
[10:09] <jelmer> lifeless, no, since there
[10:09] <jelmer> *since it's not possible for merge to pull revisions into the local repository
[10:10] <jelmer> Odd_Bloke, still there?
[10:10] <lifeless> jelmer: righto
[10:11] <lifeless> jelmer: could create a pending-merge micro-repo :)
[10:12] <jelmer> lifeless, yes, but that requires me to detect how the repo is being used
[10:12] <Odd_Bloke> jelmer: Yup.
[10:12] <lifeless> jelmer: I mean in e.g. .svn/pending-merges-repo
[10:40] <abentley> lifeless: did you see bug 248506?
[10:41] <lifeless> abentley: no I hadn't
[10:42] <abentley> I tried to figure out the exact issue, but I got a little lost.  Can Packer use a fallback repository?
[10:43] <kiorky> jelmer: uhm i get problems
[10:43] <kiorky> jelmer: ImportError: cannot import name make_file_factory
[10:43] <kiorky> jelmer: with svn 1.5, and its binding, bzr1.6 or 1.5 and the stable branch
[10:43] <lifeless> abentley: no, what I was thinking was to use the generic VF implementation when pulling into a stacked environment; it should perform m~= these days
[10:44] <kiorky> jelmer: (when doing bzr svn-import URI)
[10:44] <abentley> lifeless: The current implementation is using Packer for fetch, so that appears to be why it's failing.
[10:45] <kiorky> jelmer: http://www.friendpaste.com/SLCdppAS
[10:51] <lifeless> abentley: I suggest doing a check that neither source nor target have fallback repos in the interpackrepo thing
[10:53] <kiorky> lifeless: do you have any idea on my import problem? ABI changed ?
[10:54] <lifeless> kiorky: svn wbzr-svn head needs bzr.dev head
[10:54] <kiorky> lifeless: Ha ok :)
[10:56] <kiorky> lifeless: there is no way to have svn integration with stable releases ? (even with previous version or bzr svn)
[11:03] <lifeless> kiorky: yes, but you can't use the head of the branch, you need some commits back; jelmer: ^^
[11:03] <lifeless> kiorky: (I really want bzr-svn in the ppa to address this, its being discussed on list at the moment)
[11:06] <kiorky> lifeless: another thing im now using bzr head
[11:06] <kiorky> lifeless: but now i cant authenticate with the svn repo
[11:06] <kiorky> it just fails :p
[11:06] <lifeless> kiorky: if you are using bzr head, then bzr-svn head should work - but you'll need to run make in the bzr-svn dir
[11:06] <kiorky> lifeless: i mean there is maybe some configuration spoemwhere to get the crendentials info?
[11:06] <kiorky> lifeless: yep, that what i had done
[11:07] <kiorky> now, on import, i cant authenticate :)
[11:23] <kiorky> lifeless: jelmer uhm, i dont suceed in making bzr svn-import run
[11:24] <kiorky> either i get authenticate problems, or when i put the creds in the url i get : "RROR: Not a branch:"
[11:25] <kiorky> even on non auth'd enabled servers
[11:25] <kiorky> (i tried to co the svn repo)
[11:35] <lifeless> kiorky: hi, have you checked the FAQ?
[13:10] <Necoro> hey - I've a project - and I deleted a file about 100revs ago.
[13:10] <Necoro> Is there a way to get it back, w/o having to scan through history manually looking for the revision where I deleted it?
[13:11] <LeoNerd> Maybe  bzr log path/to/file  will find you the commit where you removed it?
[13:12] <Necoro> nope
[13:12] <pygi> Necoro, "bzr revert file" might work
[13:12] <pygi> not 100% sure tho
[13:13] <Necoro> pygi: bzr: ERROR: Path(s) are not versioned =/
[13:14] <pygi> eh, yes, that's only for non-commited stuff
[13:14]  * pygi thinks
[13:15] <Necoro> hmm ... ok ... "bzr diff -r1.." at least gives me the date where I deleted it =)
[13:17] <Necoro> hmm ... no
[13:17] <pygi> Necoro, bzr revert -r123 some_file should actually do the trick
[13:17] <fullermd> You need to "revert -r<rev_before_deleted>" to bring it back.
[13:17] <pygi> as long as you know the revision
[13:17] <Necoro> but I do not know the revision ;) - that's the problem
[13:17] <fullermd> But there's no way to find the rev other than "log -v | less ; <search for filename>
[13:17] <Necoro> I just could use "-r1" but don't know I changed something in between -r1 and -r$deleted
[13:18] <bob2> bzr log should be ablt to take a file id
[13:22] <Odd_Bloke> Necoro: You could use the bisect plugin.
[13:23] <lifeless> Necoro: bzr revert -r -100 FOO
[13:23] <lifeless> Necoro: or bzr log -v | less, then /filename
[13:26] <Necoro> lifeless: the latter one works :) - though it isn't as automagic as I thought ;)
[13:27] <Odd_Bloke> Necoro: If you branch http://bzr.daniel-watkins.co.uk/bisect/automated/ into ~/.plugins/bisect and then do 'bzr bisect run stat <filename>'.
[13:30] <Necoro> Odd_Bloke: can't branch from inside the company (damn proxy/firewall -.-) ... is there a difference to the lp:bzr-bisect ?
[13:38] <Odd_Bloke> Necoro: Yeah, there is.  Would it help if I pushed it to LP?
[13:39] <Necoro> yes - this would be really helpful - because from LP i can branch using bzr+ssh - so there is no HTTP-Proxy in the way doing stupid things :)
[13:40] <Odd_Bloke> Necoro: https://code.launchpad.net/~daniel-thewatkins/bzr-bisect/automated
[13:41] <awilkins> Yegods, my sysadmins are morons.
[13:41] <awilkins> "Hey, poke a hole in the firewall to let SSH in or I'll have to set up a relatively insecure WSGI gateway app"
[13:42] <awilkins> "I'm sorry, we can't do that for security reasons"£
[13:42]  * awilkins slaps forehead
[13:43] <_paneb> is there a way to see the parent of a branch?
[13:43] <_paneb> (i am about to do bzr merge)
[13:44] <Necoro> Odd_Bloke: thanks - branching worked ;) - but running the command yields: http://rafb.net/p/ZDDJkI98.html
[13:45] <Necoro> or do I have to do certain things before I'm able to run it?
[13:45] <bob2> _paneb: bzr info?
[13:45] <_paneb> ok
[13:47] <Necoro> and btw:  bzr bisect deletes uncommitted changes w/o notice ;)
[13:50] <awilkins> Necoro: That's a bug ; needs reporting
[13:53] <Odd_Bloke> Necoro: Apologies, I didn't realise.
[13:54] <Necoro> Odd_Bloke: no problem - nothing lost which can't be reproduced using zsh history ^^
[13:54] <Odd_Bloke> And I probably meant 'bzr bisect run "stat <filename"'.
[13:54] <Odd_Bloke> Necoro: ^
[13:56] <Necoro> Odd_Bloke:  http://rafb.net/p/Q9POdw13.html ... still not works
[13:56] <Necoro> oh - wrong paste
[13:57] <Necoro> that's the one -> http://rafb.net/p/MrtUS580.html
[13:59] <Odd_Bloke> Necoro: OK, you actually want the opposite of what stat does.  I'm not sure of the best way to do that.
[14:01] <Odd_Bloke> Necoro: Try 'bzr bisect run "test ! -e <filename>"'.
[14:02] <Necoro> Odd_Bloke: wohoo :) works
[14:03] <Odd_Bloke> \o/
[14:03] <Necoro> thanks a lot :)
[14:03] <Odd_Bloke> Necoro: No worries.  It's nice to finally have a real-life use case for that stuff. :)
[14:04] <Necoro> hehe =D
[14:07] <Necoro> do you think it is possible to put this in one command? - so like: bzr undelete <filename> ?
[14:13] <Odd_Bloke> Necoro: I would imagine that'd be possible in a plugin, but I'm not sure if it's a common-enough use case for much more than that...
[14:15] <lifeless> Necoro: I think we should make getting at the file more easy
[14:15] <lifeless> Necoro: 'bzr revert -r xxx foo' *is* undelete already
[14:16] <lifeless> Necoro: so, I think a mode to revert to search for a file, or some means to search for it would bbe sufficient
[14:20]  * pygi thinks that might be god way to contribute something :)
[14:23]  * fullermd imagines "bzr path-history <path>"...
[14:36] <lifeless> fullermd: bzr search path
[14:54] <Necoro> lifeless: that's true -- but plugins aren't able to overload existing commands, are they?
[15:02] <LarstiQ> Necoro: they are
[15:02] <Necoro> ok :)
[15:02] <LarstiQ> Necoro: but that can be problematic if you have more than one plugin trying to override the default
[15:09] <awilkins> I think some of the builtins could stand being refactored into multiple routines that you could overload in plugins
[15:10] <awilkins> Or even provide extension points for them
[15:18] <lifeless> awilkins: indeed
[15:23] <Peng> Getting information for AnnotateUI: 118.64552807807922 secs :D
[15:24] <Peng> Hmm, how do you do a graceful shutdown of Loggerhead?
[15:24] <Peng> I managed to shut it down in the middle of a request.
[15:27] <lifeless> Peng: no idea sorry
[15:30] <awilkins> Can bzr+http:// do certificate authentication?
[15:31] <Peng> My question is probably more of a Paste question anyway.
[15:31] <lifeless> awilkins: vila: knows
[15:31] <lifeless> vila: do we have docs for easy answers on this
[15:32] <Peng> I hit Ctrl+C, and it did a mostly graceful shutdown: that 118 seconds request actually completed several seconds after all of the other worker threads had been shut down. But then the web server log reports a second request came in at the same time and got dropped on the floor.
[15:32] <uws> Hmm. bzr just ate ALL my RAM
[15:32] <uws> almost all 1280 MB of it
[15:32] <awilkins> I should learn to open my beak less on the "security" issue
[15:32] <vila> no, but hopefully I will address that soon (when I get back from vacations in 3 1/2 weeks :)
[15:32] <awilkins> vila: Can it do digest?
[15:32] <Peng> Is Python's SSL support smart enough to do that?
[15:32] <vila> awilkins: if you use the pycurl http implementation it will verify certificates
[15:33] <awilkins> vila: Server, yes, client also?
[15:33] <vila> awilkins: digest is supported
[15:34] <vila> awilkins: client certificates ? No. But I'd like to add that too once urllib https implementation knows how to do server certificate verification (including option for self-certified)
[15:34] <awilkins> Ok then, guess I'm going with digest for the time being :-)
[15:35] <uws> jelmer: bzr-svn eats all my memory
[15:35] <Peng> uws: What version?
[15:35] <uws> jelmer: Can I convert a large SVN repo to bzr+svn stuff in chunks?
[15:36] <Peng> uws: Yes. I always do that.
[15:36] <uws> 0.4.10
[15:36] <awilkins> uws: Yes, I wrote a script to do it 1000 revs at a time
[15:36] <uws> I had to hard-reset my machine
[15:36] <uws> Is there a way I can "continue" the previous branching/
[15:37] <uws> I'm using a repos --rich-root-pack and branched http://...../trunk into "project.trunk"
[15:37] <awilkins> uws: cd project.trunk ; bzr pull http://.....trunk
[15:38] <uws> webkit is quite a large project ;)
[15:39] <Peng> uws: The next version of bzr-svn (possibly paired with svn 1.5) will leak a lot less.
[15:39] <uws> I already run svn 1.5.0
[15:39] <awilkins> uws : https://launchpad.net/projects/?text=webkit
[15:42] <uws> awilkins: Hmmm. How can i branch that?
[15:43] <uws> awilkins: bzr branch lp:~vcs-imports/webkit-open-source/trunk  doesn't work
[15:44] <uws> awilkins: ah, it's not imported it seems https://code.launchpad.net/webkit-open-source
[15:45] <awilkins> Ah well, it was a good try :-)_
[15:45] <uws> so where's that rev pulling thingy?
[15:46] <awilkins> uws: It's a powershell script, you probably don't want that ; it's not hard, write a loop, initialise a value with the output of bzr revno, add a few hundred, and pull up to that value.
[15:57] <uws> awilkins: this'll do for now hopefull:      for revno in $(seq 100 1000 35000 ); do bzr pull --verbose svn+http://svn.webkit.org/repository/webkit/trunk -r $revno; done
[16:23] <Odd_Bloke> jelmer: When are you going to be arriving on Wednesday?
[18:43] <andresj> hey how do I get the latest bzr-svn for Ubuntu? The currently available is bzr-svn0.4.9, and its not compatible with bzr1.5... Can anybody add it to the PPA?
[18:46] <ToyKeeper> andresj: I know this isn't the greatest answer, but you could branch the latest versions from launchpad and use bzr.dev.
[18:47] <andresj> ToyKeeper: I don't really know what you mean. :P
[18:48] <ToyKeeper> Basically, you could install from source instead of a .deb.  But I don't know enough about your situation to know if this is appropriate.
[18:49] <andresj> ToyKeeper: oh well I guess I could do that... but is there really no bzr-svn package available?
[18:50] <ToyKeeper> There may be a newer one in debian/testing or debian/unstable, and possibly in a PPA.
[18:52] <ToyKeeper> I just havent looked, since I want the latest bzr.dev to make patches against.  It's easier for me to 'bzr pull' updates than install packages.
[18:53] <andresj> oh haha ok :) no i dont develop bzr :P   well I guess i'll keep looking or if not install from source. thanks ToyKeeper :)
[18:56] <ToyKeeper> andresj: If you decide to go that way, the "Run from source directory" section here may help: http://bazaar-vcs.org/InstallationFaq
[18:56] <andresj> ToyKeeper: allright thanks I'll check it out :)
[18:56] <ToyKeeper> You can run bzr.dev and every plugin (that I've tried) from source dirs, without needing to actually install them.  Just add a symlink and it's done.
[18:56] <lifeless> andresj: we're working on the PPA; the list has the current status
[18:58] <andresj> lifeless: oh cool where is the list? :)
[18:59] <andresj> ToyKeeper: oh wow thats cool this is one of the few programs that can do that in my expierence :D
[19:02] <ToyKeeper> In some cases, running "make" is also required.  (including bzr-svn)  And you'll of course need to provide any dependencies.
[19:02] <andresj> of course :)
[19:41] <lakshmanan> ﻿i have a problem with bazaar while pushing my changes to the launchpad branch.... thisis the error message   bzr: ERROR: Transport operation not possible: http does not support mkdir()
[19:42] <lakshmanan> ﻿i have a problem with bazaar while pushing my changes to the launchpad branch.... thisis the error message   bzr: ERROR: Transport operation not possible: http does not support mkdir()
[19:42] <beuno> lakshmanan, have you done:  bzr launchpad-login your_username?
[19:43] <lakshmanan> but the error messge is somthing different...
[19:43] <beuno> lakshmanan, yes, that error message is because you're trying to push through http
[19:43] <lakshmanan> ok.. so what should i do
[19:43] <beuno> you're probablt using lp:location
[19:43] <beuno> lakshmanan, what's your username in Launchpad?
[19:44] <lakshmanan> i enter an email id to login my account
[19:44] <beuno> lakshmanan, right, but you should also have a username
[19:45] <lakshmanan> there are two names.. that i have given.. one is display name ->lakshmanan and the other is just a name(as i see in my 'change details' page) -> lak89
[19:46] <beuno> lakshmanan, is this you?  https://launchpad.net/~lak89
[19:46] <lakshmanan> yes
[19:46] <beuno> if it is, then, run:  bzr launchpad-login lak89
[19:47] <beuno> what exact command are you using to push?
[19:48] <lakshmanan> i use bzr push <branch location>
[19:48] <luks> <branch location> is the important part you should paste :)
[19:50] <lakshmanan> beuno, i ran bzr launchpad-login lak89.... it didn't say anythng... my prompt came back
[19:51] <lakshmanan> beuno, i did paste the branch location correctly
[19:51] <beuno> lakshmanan, ok, try pushing now
[19:52] <lakshmanan> beuno,  i did it... it said this "The authenticity of host 'bazaar.launchpad.net (91.189.94.254)' can't be established. Are you sure you want to continue connecting (yes/no)?
[19:52] <lakshmanan> "
[19:53] <beuno> lakshmanan, say yes  :)
[19:54] <lakshmanan> beuno, bzr: ERROR: Target directory lp:~lak89/getedit/mine already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway.
[19:54] <lakshmanan> .............this is what it is saying
[19:55] <beuno> lakshmanan, right, do:   bzr push lp:~lak89/getedit/mine --use-existing-dir
[19:55] <beuno> this won't happen from now on, because you've specified your launchpad ID
[19:56] <lakshmanan> beuno, what is the correct way of pushn to a branch.. is this so tedious like this everytime
[19:56] <beuno> lakshmanan, no, again, this happened now because you didn't have your launchpad ID set
[19:56] <beuno> from now on, it's just:  bzr push [location]
[19:57] <lakshmanan> beuno, that is if i use that directory for all the puch operations... what if i move to another directory, initialize bzr and push from there ??
[19:58] <beuno> lakshmanan, this is system-wide
[19:58] <beuno> so it will just be push
[19:58] <beuno> this is a one time thing you have to do
[19:58] <beuno> to use   lp:location   URLs
[19:59] <beuno> having your username set, it uses ssh instead of http, so it can perform write operations
[20:00] <lakshmanan> beuno, ok .. actually what went wrong in my steps... what did/might have do/done wrong in my previous attempts...if any... what should i do from now on
[20:01] <beuno> lakshmanan, from now on, just use:  bzr push location
[20:01] <lakshmanan> beuno, ok... but everytime.. i restart... should i set this username thing
[20:02] <beuno> you didn't have launchpad-login specified, and you had already tried to push via http, which creates an empty dir (it's a bug in Launchpad), so you have to specify the --use-existing-dir flag
[20:02] <beuno> lakshmanan, you will have to specify that again if you reinstall, or use it from a different user on the system
[20:02] <lakshmanan> ok
[20:03] <lakshmanan> brb.. thanks
[20:03] <beuno> welcome'
[20:06] <Kinnison> lifeless: that compression stuff looks very interesting
[20:19] <lifeless> Kinnison: :)
[20:19] <lifeless> Kinnison: play!
[20:22] <Peng> Is it just me, or is the lp branch "pybloom", not "bzr-pybloom"?
[20:23] <Kinnison> lifeless: tempting, but I'm busy writing READMEs and tests for my templating library
[20:23] <dash> what's the current state of bzr-svn? anybody know if bzr-svn 0.4.10 has problems with svn 1.5?
[20:25] <dash> looks like current bzr-svn requires current bzr as well
[20:26] <Peng> Uh, there's an svn 1.5 compatibility branch.
[20:26] <Peng> I don't know much else though.
[20:26] <Peng> And yes, bzr-svn's 0.4 branch requires bzr.dev.
[20:27] <Verterok> dash: are you usign bzr-svn from source?
[20:28] <dash> Verterok: was trying to :)
[20:28] <Verterok> in that case I think you need install the subversion-dev package from your distro
[20:28] <dash> yep, got that
[20:28] <dash> getting an error from libsvn though
[20:28] <Verterok> dash: bzr-svn now provide it's own python bindings to subversion
[20:29] <Verterok> so you need to compile them against your installed subversion
[20:30] <dash> Verterok: even 0.4.10?
[20:30] <Verterok> dash: I don't know, let me check
[20:30] <dash> because i'm not seeing any C files in there
[20:31] <dash> specifically, attempting to branch from an svn url gets me this:
[20:31] <dash> python: /build/buildd/subversion-1.5.0dfsg1/subversion/libsvn_ra/ra_loader.c:973: svn_ra_get_log: `Assertion *path != '/'' failed.
[20:32] <Verterok> dash: I encountered a similar error while trying to build it for Mac OS X
[20:33] <Verterok> dash: are  you building subversion-1.5 from sources?
[20:33] <dash> no
[20:34] <dash> using the package in intrepid
[20:34] <Verterok> dash: I think that error is caused by a minor version number in the subverison build
[20:35] <dash> yeah apparently the api changed in 1.5
[20:35] <dash> guess i'll downgrade
[20:36] <Verterok> dash: bzr-svn branch (0.4) contains the c files
[20:36] <Verterok> dash: https://code.launchpad.net/~jelmer/bzr-svn/0.4
[20:37] <dash> yeah I just tried that
[20:37] <dash> it doesn't work with bzr 1.5 though :)
[20:42] <Verterok> dash: time to fill a bug them :)
[20:43] <dash> Verterok: why's that? Peng just said it depends on bzr.dev
[20:45] <Verterok> oh, sorry I missed that
[20:46] <Verterok> dash: I assumed svn-1.5 :P
[20:46] <Peng> Well, I mean, I don't know if it's intentional, but it's the case at the moment.
[20:48] <dash> bzr 1.6 will be along soon enough
[20:48] <dash> I can deal with bzr-svn 0.4.10 until then. :)
[21:19] <dash> hm. so bzr has the idea of a branch attribute called the 'submit branch'. for a workflow that creates branches for specific features/issues, do I understand it correctly to be "the branch this one should be merged into, once it's done"?
[21:35] <pickscrape> Hi, are there any good instructions out there for building debian/ubuntu packages for bzr plugins?
[22:03] <pygi> so folks, welome cheezeburger :)
[22:04] <pygi> a bzr repositories serving tool :)
[22:05]  * pickscrape pricks his ears up
[22:05] <pickscrape> Read-only serving or read/write?
[22:05] <matkor> Does making bzr checkout <remote_branch> downloads full diff history ?
[22:06] <dash> matkor: yes. "bzr checkout --lightweight" does not.
[22:08] <matkor> ok.. is it possible to "cut down" given branch history ? Let's I am only interested to have hisory since given revision (make given revision first one) ?
[22:08] <dash> matkor: 1.6 is going to allow something like that, I believe
[22:08] <dash> 'stacked branches'
[22:14] <pygi> pickscrape, read-write
[22:14] <pygi> pickscrape, it allows easily setting up bzr repositories and access management to them
[22:14] <pickscrape> pygi: does it use the smart server?
[22:14] <pygi> probably yes, still gotta see =)
[22:15] <pygi> it's just an idea I got today, and registered a project
[22:15] <pickscrape> pygi: Then it sounds very interesting indeed.
[22:16] <pickscrape> pygi: I'll watch your project with great interest :)
[22:16] <pygi> :)
[22:18] <pickscrape> Sorry to ask again, but can someone point me at some docs on packaging bzr plugins for debian/ubuntu?
[22:18] <pygi> hmmm
[22:19] <pygi> here's an idea
[22:19] <pygi> apt-get source bla-package
[22:19] <pygi> where bla-package is some bzr plugin, and you can see how it's done
[22:19] <pygi> then if you have any questions, I can probably help
[22:19] <asabil> pygi: where is the code for cheeseburger ?
[22:19] <asabil> :D
[22:20] <pygi> asabil, cheezeburger* :)
[22:20] <pygi> asabil, in my head, does that work for you? xD
[22:20] <asabil> lol
[22:20] <pickscrape> I'm looking in bzr-svn's checkout now, but don't see anything to do with packaging (I'm not at all familiar with debian packages so I really don't know what I'm looking for)
[22:20] <asabil> sorry, cheezeburger
[22:20] <pygi> pickscrape, debian directory
[22:20] <dash> pickscrape: it wouldn't be in the checkout, i bet
[22:20] <chx> heya. here is a challenge. i would like to put my daily database dumps into some RCS. the file is like 10G. Also, I wonder whether there is a way to throw away old revisions after some time
[22:21] <pickscrape> Yeah, there isn't a debian directory here
[22:21] <asabil> pygi: looking forward to see the real thing
[22:21] <dash> pickscrape: that stuff is usually kept as a patch
[22:21] <pygi> asabil, :)
[22:21] <dash> pickscrape: apt-get source will fetch it
[22:21] <pickscrape> dash: thanks, I'll try that out
[22:21] <dash> chx: if you're just versioning a single blob, maybe xdelta or git would serve you better
[22:21] <pygi> chx, ehm, that's not so nice, but ...
[22:21] <chx> not a blob. text file.
[22:21] <chx> i have a LOT of data.
[22:22] <chx> and then some.
[22:22] <pygi> a blob actually is any file :P
[22:22] <chx> okay, okay
[22:22] <dash> chx: question is, what operations do you want to perform
[22:22] <chx> in databases blob is a binary large object ;)
[22:22] <chx> dash: commit
[22:22] <dash> chx: is that all? :)
[22:22] <chx> dash: when the database server dies under every other blue moon , checkout.
[22:22] <pickscrape> dash: thanks, that has revealed it :)
[22:22] <dash> chx: i'd just keep a list of diffs
[22:22] <pygi> asabil, do you have a use case? :)
[22:22] <chx> dash: yes. that's all. and, sometimes it'd be great to throw out old stuff.
[22:23] <dash> chx: yep. you want a backup system, not an RCS :)
[22:23] <chx> well, no
[22:23] <asabil> pygi: it's about hosting/managing/serving bzr branches right ?
[22:23] <chx> An RCS sounds to me like the ideal stuff for this
[22:23] <pygi> asabil, yup
[22:23] <chx> after all
[22:23] <chx> i have a file that grows.
[22:23] <chx> and, if we have the dump in an RCS who knows what useful things we can do?
[22:23] <chx> tag it before a big rollout?
[22:23] <dash> chx: RCSes have to support a lot more operations
[22:23] <chx> why not.
[22:24] <dash> chx: like, not forgetting history :)
[22:24] <chx> dash: I ... know.
[22:24] <asabil> pygi: something like launchpad's bzr support would be just awesome
[22:24] <chx> dash: i know.
[22:24] <chx> dash: i was wondering whether graft would be useable here.. just wondering.
[22:24] <pygi> asabil, it's not any kind of UI, rather just a server side tool
[22:24] <pygi> you got that part, right? :)
[22:25] <asabil> pygi: I would want both :p
[22:25] <pickscrape> pygi: so in a very loose sense, it's like a bzr equivalent of svnserve?
[22:25] <pygi> asabil, I agree, but for UI stuff I need help :P
[22:25] <pygi> pickscrape, ehm, it's something similar to gitosis if you're familiar with it?
[22:25] <asabil> =_=
[22:26] <pickscrape> pygi: I'm not actually. Gave up on git when my head started to melt, came here and haven't really looked back
[22:26] <pickscrape> I'll read up on it though
[22:26] <pygi> pickscrape, lemme get a link for you
[22:26] <pygi> http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
[22:26] <chx> dash: xdelta...?
[22:27] <pygi> asabil, if you wanna help tho ... :)
[22:28] <asabil> pygi: just design it so that a UI can be added on top
[22:28] <asabil> pygi: I am afraid am really not skilled with UIs
[22:28] <dash> chx: never mind, thought it was a binary
[22:28] <chx> no, no
[22:28] <chx> just a "small" textfiel
[22:29] <chx> that gives me a ton of headaches
[22:29] <pygi> asabil, ofcourse, didn't thought of doing it any other way :)
[22:34]  * pygi goes back to writing some git stuff
[22:44] <tca> I'm running bzr selftest after I added a small patch for a ghost revision problem. How should I know if any of the test breakages are caused by my patch? Run selftest before and after and compare broken tests?
[22:45] <mwhudson> well, 'the tests always pass on trunk'
[22:46] <mwhudson> so if you're seeing failing tests, it's very very likely you introduced them
[22:46] <mwhudson> but i guess running in a pristine bzr.dev branch first would be good to confirm this
[22:46]  * luks would change that to 'the tests usually pass on ubuntu/linux machines'
[22:47] <luks> (with en_* locale)
[22:49] <mwhudson> well, yes
[22:56] <Odd_Bloke> pygi: What do you envisage cheezeburger doing?  And shouldn't it be 'cheezburger'?
[22:58] <colbrac> anybody an idea how to set an icon on a gtk.Window so that it shows up as a big icon in the app switcher (alt-tab)
[22:59] <colbrac> or is this something missing in pygtk?
[23:01] <luks> colbrac: http://www.pygtk.org/docs/pygtk/class-gtkwindow.html#method-gtkwindow--set-icon-list ?
[23:03] <pygi> Odd_Bloke, possible, yes, I messed it up :P
[23:04] <jam> luks: and --no-plugins
[23:04] <colbrac> luks: thanks, I've been looking all over that page but this seems worth a try
[23:05] <pygi> Odd_Bloke, well, keeping ssh keys for people who have commit access to some repo, managing access to repos, coordinating with some web interface for bzr repos, and stuff
[23:08] <colbrac> woohoo! That worked :) Olive now has an icon in the switcher :D
[23:10] <Odd_Bloke> pygi: Do you mean repos or branches?
[23:11] <pygi> Odd_Bloke, ehm, well, branches
[23:14] <f0ghorn> anyone have thoughts on https://bugs.launchpad.net/bzr-svn/+bug/248289 ?
[23:15] <Odd_Bloke> jelmer: ^
[23:52] <igc> igc
[23:52] <igc> morning