[00:20] <piyo> hello. how can i "resume" an network-interrupted "bzr checkout"? I am checking out the official emacs repository
[00:20] <piyo> no sorry, i mean "bzr branch"
[00:20] <piyo> not "bzr checkout"
[00:21] <gutworth> you can't really
[00:21] <piyo> can i do something like, bzr branch sameurl different-local-dir?
[00:21] <Peng> piyo: Certainly. But the data was lost when bzr exited.
[00:21] <Peng> piyo: Probably. Most of it.
[00:22] <piyo> because these newbie instructions are preping a "shared repository"
[00:27] <piyo> so if i successfully complete the "bzr branch" with "different-local-dir", is it sufficient to just rename "different-local-dir" to "desired-local-dir" (e.g. trunk2-try -> trunk)
[00:27] <bob2> should be ok
[00:27] <bob2> there's a tarball you can download, I think
[00:27] <bob2> which should be more easily resumable ;)
[00:28] <piyo> :)
[00:28] <piyo> :(
[00:28] <piyo> ok ill give the tarball a looksee as well
[00:31] <piyo> huh, the tarball seems to be delisted from that official newbie guide page
[00:32] <piyo> http://www.emacswiki.org/emacs-se/BzrForEmacsDevs (but view in Google Cache)
[00:32] <bob2> if it was hosted at notamigos, it's probably not useful
[00:33] <piyo> it was http://bzr.notengoamigos.org/emacs-merges.tar.gz
[00:36] <piyo> bob2: can you point to the tarball that you are referring to? or is it this undated page? http://bzr.notengoamigos.org/
[00:37] <bob2> no idea, sorry
[00:37] <piyo> ok thanks
[00:38] <piyo>  >bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk/ trunk2
[00:38] <piyo>  [#########-          ]  45123KB   129KB/s | Fetching revisions:Inserting stream
[00:38] <piyo> :)
[00:42] <Peng> piyo: For future reference, you can do it in chunks to limit the damage if your connection goes out, and to save RAM. "bzr branch -r 1000 ...; cd ...; bzr pull -r 2000; ..."
[00:42] <piyo> oh yeah this is what im looking for
[00:43] <piyo> thanks
[00:44] <Peng> You could even script it.
[00:44] <piyo> bzr pull has sane retvals?
[00:44] <Peng> piyo: No idea.
[00:45] <piyo> ok
[00:45] <piyo> sorry, "sane" is vague. i mean 0 == ok, 1 == no-more-to-retrieve, etc
[00:51] <Peng> Nonetheless, no idea.
[00:51] <Peng> Oogh, I just sneezed incorrectly.
[00:52] <piyo> ok
[00:52] <piyo> when you say script it, do you mean in python, but not using process return values?
[00:53] <Peng> Nah, I just meant a little loop in sh.
[00:53] <piyo> ok thanks
[00:54] <piyo> i think the -r requires an absolute value, amirite
[00:54] <Peng> piyo: Yeah.
[00:54] <piyo> :)
[00:58]  * piyo idles
[01:30] <Kamping_Kaiser> I've run 'bzr send', and its only showing me the first line of my commit message as the subject. is the rest of it hidden somewhere (in the bundle?) or is it ignored?
[02:53] <ardian> Hi
[05:01] <Supertanker> Hi; this has been bugging me for awhile: exactly where does Bazaar store its files? You know how SVN has those lovely .svn folders inside each working directory? What's Bazaar's equivilent? How does it keep track?
[05:02] <Supertanker> I'm uncomfortable trusting my project when I don't know what is going on with my VCS.
[05:02] <Supertanker> trusting my project to a VCS*
[05:02] <Kamping_Kaiser> in a .bzr directory ...
[05:04] <Supertanker> Are you serious?
[05:04] <bob2> yes
[05:04]  * Supertanker headdesks
[05:04] <Supertanker> I cannot believe I forgot to look for hidden files
[05:04] <Supertanker> Foot in mouth time
[05:04] <bob2> however there's only one, in the root of the checkout/branch/repository
[05:04] <Supertanker> Thank you so much :>
[05:04] <Supertanker> Oooh, I like that.
[05:05] <Supertanker> Much more convenient than in every subdirectory.
[05:06]  * Kamping_Kaiser applies a trout to Supertanker 
[05:07]  * Supertanker accepts being trouted before installing bzr on one of his development servers
[05:31] <mlh> OTish, but I think svn is moving to a single .svn in the root, too
[05:41] <Supertanker> Huh
[05:41] <Supertanker> It'd be a great idea.
[06:01] <Supertanker> Hmm, does bzr have any functionality similar to svn's 'svnadmin dump > backup' and 'svnadmin load < backup'?
[06:02]  * Supertanker is considering using bazaar to keep track of the fifty billion drafts for his novel
[06:02] <bob2> cp -a .bzr
[06:02] <Supertanker> Hmmm, simple. I like it!
[06:02] <Supertanker> Oh god, I'm tired. I just thought of using bazaar to keep track of bazaar updates
[06:02] <Supertanker> backups*
[06:03] <Peng> Then take backups of your backups . . . . ..
[06:03] <Supertanker> And back them up too, just to be safe?
[06:04] <Supertanker> And print them all out as ASCII too, just to have hard copy!
[06:05] <Supertanker> Okay, last question for the night: what is the difference between init and init-repo? From what I see, each 'branch' is like an svn repository, and a 'repo' is...a collection of branches. right?
[06:07] <Peng> Supertanker: A shared repository (created by init-repo) is a storage optimization. If you have two branches, it's a waste of disk space for both of them to have a copy of the entire history, right? So you put them in a shared repo, then there's only one copy.
[06:08] <Peng> Supertanker: In bzr, on-disk, all a repository is is a big bag of revisions. They don't even have to be from the same project.
[06:08] <Peng> Supertanker: A shared repository is just a repository that will be used by multiple branches below it in the directory tree.
[06:08] <Supertanker> Ah, okay, that makes sense.
[06:09] <Supertanker> So if I was using the feature branches setup, I'd have 'trunk' and 'myshinyfeature'. When I wanted to add code, I'd branch trunk as myshinyfeature, work on it, and then merge it back into trunk; both of them share a repository so bzr doesn't have to keep track of two seperate histories.
[06:09] <Supertanker> Right?
[06:10] <Peng> Supertanker: Two separate copies of what is largely the same history, yes.
[06:10] <Peng> Supertanker: It's faster, too, since you aren't always copying a bunch of data around.
[06:11] <Supertanker> Okay, that makes perfect sense
[06:11] <Supertanker> Thanks!
[06:14] <Peng> :D
[06:16] <Supertanker> Ah, I tihnk I see
[06:16] <Supertanker> I was wondering how to make 'container' directories, or if there was anything special to it like the way the manual suggests, but I apparently forgot about just plain 'mkdir'. :P
[08:13] <luks> ok, this is embarrassing, but for some reason I can't push to launchpad and I can't figure out what's wrong
[08:13] <luks> $ bzr push lp:bzr-pager
[08:13] <luks> bzr: ERROR: Cannot lock LockDir(lp-64802192:///~luks/bzr-pager/pager/.bzr/branchlock): Transport operation not possible: readonly transport
[08:13] <luks> $ bzr push bzr+ssh://bazaar.launchpad.net/~luks/bzr-pager/pager
[08:13] <luks> bzr: ERROR: Cannot lock LockDir(lp-64802192:///~luks/bzr-pager/pager/.bzr/branchlock): Transport operation not possible: readonly transport
[08:13] <luks> any ideas?
[08:14] <Peng> That's an interesting one. I've got no idea. Tried --no-plugins?
[08:14] <spiv> luks: is ~luks your lp username?
[08:14] <luks> yes
[08:14] <luks> well, luks is my lp username
[08:14] <spiv> Right, yes.
[08:14] <spiv> That's what I meant :)
[08:14] <Peng> luks: Try bzr+ssh://luks@bazaar...
[08:15] <luks> no, bzr+ssh://luks@... doesn't work either
[08:16] <Peng> luks: You have angered the Launchpad gods. Sacrifice a goat.
[08:16] <spiv> luks: add -Dhpss to the command line, and pastebin the resulting ~/.bzr.log ?
[08:16] <spiv> I suppose it's possible that LP is having issues.
[08:18] <luks> http://paste.pocoo.org/show/160547/
[08:19] <Peng> Not any more informative.
[08:19] <spiv> Well, it's clear that the server doesn't think you can write to that dir.  Which is very odd!
[08:20] <Peng> I can't either. So it's an LP issue.
[08:20] <Peng> I get the same error on one of my branches.
[08:21] <spiv> But almost certainly an LP issue rather than bzr itself.  So ask in #launchpad, or file a question at https://answers.launchpad.net/launchpad-code
[08:22] <Peng> spiv: Could you try it too?
[08:22] <spiv> Peng: I could, but frankly I don't expect a different result, and I ought to be enjoying my holiday :P
[08:22] <Peng> spiv: :D
[08:23] <spiv> luks: (I've asked in #launchpad)
[08:39] <spiv> Peng: fwiw, I *can* push a new bzr branch successfully.
[08:44] <Peng> Huh.
[08:44] <Peng> Argh.
[08:44] <Peng> I screwed up. I tested locking a mirrored branch. Of course I can't do *that*.
[08:45] <spiv> Oh.
[08:45] <Peng> I just tried locking a normal branch, and it succeeded.
[08:46] <spiv> Peng: ok, cool
[08:46] <Peng> luks: Your branch is a mirrored branch too.
[08:47] <spiv> Peng: oh, urgh.
[08:47] <Peng> luks: You need to push to the bzr+ssh version of http://bzr.oxygene.sk/bzr-plugins/pager
[08:47] <spiv> Peng: that's a horribly unclear error for bzr + lp to give in that case!
[08:47] <Peng> :D
[08:47] <spiv> luks: sorry about the unclear error, please do file a bug about that one, I'm sure we can do better.
[08:52] <luks> ouch
[08:52] <luks> I so totally didn't realize that
[08:54] <luks> thanks Peng and spiv
[08:54] <spiv> luks: neither did I
[08:54] <Peng> :)
[08:55] <luks> spiv: well, it's my branch, I should have known this :)
[08:55] <spiv> luks: so much so that I was digging up the escalation policy for lp outages before I realised.
[08:55] <Peng> At least the on-call losas should be awake at this hour. :P
[08:56] <mindlace> or those of us in other countries
[08:56] <spiv> Peng: happily I didn't get so far as ringing the relevant phone number and finding out...
[08:57]  * spiv -> afk
[08:57] <Peng> spiv: See you later. :)
[10:30] <finno> Newbie question: Is there an easy way to rename my trunk branch? If I just rename the directory and update the nickname, is that enough?
[10:34] <luks> unless you have set the nickname manually, you don't even need to do that
[10:34] <luks> just renaming the directory should be enough
[10:39] <finno> looks good thanks! I was expecting it to have updated the log entries but in hindsight that was a big misunderstanding.
[10:45] <Kamping_Kaiser> whoever you were, impatient sydneysider, you do need magic if you pushed it somewhere
[13:48] <juffo-wup> Hi people of bzr
[13:48] <rubbs> hello
[13:49] <juffo-wup> I'm trying to checkout from a ftp server (FileZilla) on Windows on another Windows box
[13:49] <juffo-wup> But all I get is 'Operation timed out'
[13:50] <juffo-wup> What could be wrong?
[14:01] <juffo-wup> Sorry, connection problems.
[14:02] <juffo-wup> Does anybody have any ideas?
[14:02] <juffo-wup> It worked using HTTP.
[14:02] <juffo-wup> But that won't do it, as it can't create directories on the server.
[14:07] <rubbs> juffo-wup: are you able to copy down the directory from the FTP server with just plain FTP?
[14:07] <rubbs> I'm wondering if it's some sort of connection or authentication issue
[14:10] <juffo-wup> Yes, I can.
[14:12] <juffo-wup> After I log on through bzr, FileZilla reports this:
[14:12] <juffo-wup> '(000018) 30-12-2009 10:43:37 - nombre (146.83.216.214)> 227 Entering Passive Mode (146,83,216,159,5,181)'
[14:12] <juffo-wup> (nombre is the user name)
[14:12] <rubbs> well, we've reached the end of my usefulness (already, I know it sucks), but maybe someone like Peng or Jam can help.
[14:13] <rubbs> if they're around
[14:13] <rubbs> lot of people are on vacation right now
[14:13] <juffo-wup> Ok, thanks rubbs.
[14:14] <moldy> hi
[14:15] <moldy> is there any useable zsh completion for bzr by now?
[14:16] <juffo-wup> Bye.
[19:46] <NfNitLoop> I should never read Slashdot comments. :p
[19:47] <NfNitLoop> I read the Slashdot story about Emacs switching to bzr.
[19:47] <NfNitLoop> and it's full of comments along the lines of "omg, git is better".   But they've all got outdated or incorrect info.
[19:47] <NfNitLoop> which, is really par for the course for Slashdot comments anyway.
[19:48] <NfNitLoop> but I feel obligated to test these cases that people claim are better in git. :p
[19:50] <rubbs> I stopped reading /. a while ago. I didn't really get anything from it. People are just dumb and will fight you for no reason. You get a few nutjobs in there and the whole thing goes to pot really quick
[20:00] <Peng> I stopped reading it because I hate the look of the new comment system.
[20:08] <NfNitLoop> Oh, I actually like the look of the new comment system.  It's just the comments themselves I don't care for. :p
[20:08] <Peng> :P
[20:08] <NfNitLoop> One guy's complaint was that bzr didn't track cherrypicking.  But... as far as I can tell, neither does git.
[20:08] <rubbs> everything always devolves into a fight there. It's not productive and a waste of my time.
[20:09] <NfNitLoop> (which he weas proposing as an alternative)
[20:10] <NfNitLoop> The only thing better about git's cherrypicking is that it copied the cherrypick'd revision's commit message.
[20:11] <NfNitLoop> which is nice.  but... woo.
[20:16] <NfNitLoop> so, I've got a possibly stupid question.    I've got my own branch of bzr (~2.0.4dev-something) with local modifications.
[20:16] <NfNitLoop> I want to make a .deb out of it so I can install it into my ubuntu system and then use it with all of the other goodies that depend on it.
[20:17] <NfNitLoop> I'm trying to run tools/build-packages.sh  but that seems to be downloading a pristine source .tgz from somewhere.
[20:17] <NfNitLoop> which is not quite what I want. :p
[20:17] <NfNitLoop> how do I just build my version as a .deb for my platform?
[20:18] <Peng> bzr-builddeb, maybe?
[20:18]  * Peng doesn't know
[20:18]  * NfNitLoop reads up on builddeb.
[20:32] <NfNitLoop> huh.  Reading builddeb's manual is making my eyes glaaze over.  I was hoping for 1 or two commands to turn this source tree into a .deb, I don't need to create source&diff debs and all that.
[20:33]  * rubbs  has no idea how to build debs. He wishes he had time to figure it out.
[20:33] <zsquareplusc> rubbs: "quickly create ubuntu-application; quickly package" ;-)
[20:34] <zsquareplusc> NfNitLoop: well, bzr already has packages, so all the control files should be around. in that case builddeb should work with them
[20:37] <NfNitLoop> aha, if I just run it by hand and don't pass the -S flag it doesn't try to build source debs.
[20:42] <Pilky> any chance I could get some opinions on this? http://dropbox.mcubedsw.com/skitchpics/BazaarX%20Log.png
[20:44] <james_w> wow
[20:44] <Pilky> especially from any Mac users
[20:44] <rubbs> Pilky: I think it looks good. is there any reason why the newist revisions are to the left? Most time lines run from left to right rather than from right to left
[20:44] <NfNitLoop> looks cool.
[20:45] <Pilky> rubbs: well, scroll areas usually default to the top left of the area and I figure you're more likely to want to see the most recent parts of the time line
[20:46] <rubbs> that works enough for me. I think it looks great.
[20:47] <Pilky> cool
[20:47] <Pilky> of course the fun bit will come when I actually implement it
[20:47] <Pilky> it's all good mocking it up, but I don't see this being an easy coding job :p
[20:47] <rubbs> haha... true
[20:50] <Pilky> and even harder than getting it to work is getting it to be efficient.
[20:51] <NfNitLoop> Hrmm. no, builddeb fails because it wants to sign a deb.  >.<
[21:16] <NfNitLoop> oh, yay, there is a simple way to build.  grab the debian/ dir from somewhere, plop it in place and call dpkg-buildpackage. :)
[22:04] <phinze> is 'bzr up' the cheapest way to find out if there is new data available for a bound branch?
[22:05] <phinze> i'm talking with a co-worker about keeping like 8 bound branches up to date, and we're trying to figure out how to make it a bit less clunky
[22:06] <phinze> i suppose bzr up gets cheaper when there aren't changes to merge, but i was just wondering if there is an even cheaper check we can do first and make it a bit lighter
[22:13] <phinze> basically something that would be able to avoid the N network loops for N branches, which seems to be where the bulk of the cycles are going
[22:21] <phinze> ...i'll do a bit more digging, and perhaps do a mailing list post
[23:23] <NfNitLoop> Hrmm.  'bzr svn-import' is a bit slower than 'bzr branch <svn-branch>'. :p
[23:28] <NfNitLoop> Got a lot of "inconsistent details in skipped record" messages.  Kindof curious what that means.
[23:28] <NfNitLoop> I found bug 418257, where spiv said it's not a bug.
[23:29] <NfNitLoop> I guess I don't know what "one repository has been reconciled and the other has not" means.
[23:48] <spiv> NfNitLoop: actually, I never commented on that bug
[23:48] <spiv> NfNitLoop: abentley replied before I looked at it
[23:49] <spiv> NfNitLoop: "been reconciled" would mean "has had 'bzr reconcile' run on it"
[23:50] <spiv> NfNitLoop: but if this is during a new import from bzr-svn, then abentley's comment wouldn't apply
[23:50] <spiv> NfNitLoop: but... it would also most likely be a bzr-svn bug, not bzr itself.
[23:51] <spiv> NfNitLoop: (although 'bzr reconcile' would have a fairly good chance of correcting it)