[01:07] <Gilgad> does anyone know about the current status of nested tree's is?  Last references on the wiki point to the 0.15 version, saying support is incomplete
[01:09] <Rolly> Gilgad: last I checked that feature hadn't been worked on in a year
[01:10] <Gilgad> ouch
[01:10] <Gilgad> i guess thats why i can't find anything more recient than 0.15
[01:11] <Rolly> It sure would be nice to have :)
[01:13] <Gilgad> agreed, i was thinking of doing something like this: http://toykeeper.net/tutorials/svnhome using bzr, but it depends heavily on svn:externals (which as far as i can tell is nested trees) for organization
[01:14] <Rolly> yep, svn:externals == nested trees
[01:14] <ToyKeeper> You could do something similar, sort of, by doing a lot of one-way merges.
[01:14] <Rolly> What is a one-way merge?
[01:15] <ToyKeeper> Put the config modules in different branches, then merge each into host branches.  It's not the greatest approach, but it can work.
[01:16] <Gilgad> but when happens when i want to commit a change
[01:16] <Gilgad> as in, isn't the merge a one time thing
[01:16] <ToyKeeper> Basically, commit on the module branch, then re-merg.
[01:16] <ToyKeeper> merge, even.  :)
[01:16] <Gilgad> hmm
[01:16] <ToyKeeper> I really haven't found a good way to use bzr for $HOME.
[01:17] <Gilgad> what do you use? or nothing?
[01:17] <ToyKeeper> At least, if I want to share parts of a config across multiple hosts and have localized changes on each.
[01:17] <ToyKeeper> I'm using svn.
[01:17] <Gilgad> yea
[01:17] <Gilgad> mm, aparently svn would work, but i don't have a place to set up a server
[01:17] <Gilgad> i mean, i guess there are free services
[01:18] <Gilgad> but i like that i can have my repo be just files on another system
[01:18] <Gilgad> i just use my universities unix access to store it on my space there
[01:19] <ToyKeeper> Any host you have ssh access to should work.
[01:20] <Gilgad> for svn?
[01:20] <Rolly> svnserve daemon would also work, no?
[01:20] <Gilgad> note my above admission that i know little about vcs in general
[01:23] <ToyKeeper> Heh, I just perked up because someone said my name.  :)
[01:32] <pygi> jml, around or busy?
[01:48] <jml> pygi: just having lunch
[01:50] <pygi> jml, when you come around, please poke ;) thx
[01:50] <pygi> hopefully I wont be sleeping
[01:51] <jml> pygi: ok if I poke you tomorrow morning my time?
[01:51] <pygi> jml, probably, but we should finish it then :)
[01:51] <jml> yes
[01:51] <pygi> because Douglas needs to work on contracts
[01:51] <jml> *nod*
[01:51] <pygi> anyway, have fun :)
[02:45] <AfC> If I've come across an svn:// URL that Subversion can check out but Bazaar can't, would Jelmer et al want a bug report about it?
[02:46] <pygi> AfC, why not? :)
[02:46] <pygi> HI abentley
[02:46] <AfC> Hm. Or it could just be that their "server" is insanely slow and underpowered.
[02:47] <pygi> url? Perhaps I can try?
[02:47] <pygi> probably wont help tho :D
[02:48] <AfC> pygi: svn://svn.xmlroff.org/trunk/xmlroff
[02:48] <pygi> ups, no bzr svn here :/
[02:48]  * pygi looks into it
[02:49]  * AfC has to run, but if works ok for you then I'll try again from a different uplink
[02:49] <pygi> kk
[02:54] <abentley> pygi: hi
[06:39] <GPH-Laptop> Is there a way to get a print out of the directory structure in a repository?
[06:46] <fullermd> ls?   8-}
[06:47] <fullermd> (which is to say, you're probably asking either too little or too much; what's the goal?)
[06:48] <awmcclain> Do I need to set up an ssh umask to be able to share the branches that I push? Every new bracnh that I push has teh wrong group perms. :(
[06:50] <spiv> awmcclain: https://lists.ubuntu.com/archives/bazaar/2007q3/027560.html ?
[06:51] <awmcclain> I already set the repo branch to 2770
[06:51] <awmcclain> repo dir
[06:51] <awmcclain> :-\
[06:51] <awmcclain> ohhhh
[06:51] <awmcclain> let me try doing it one level down
[06:52] <GPH-Laptop> fullermd: Oh, you're back. Yay!
[06:53] <GPH-Laptop> fullermd: Is there a command that I can use to just list the whole directory structure of the repository? (Similar to ls, I guess, but recursive, maybe?)
[06:53] <GPH-Laptop> Or am I asking too much
[06:53] <GPH-Laptop> ?
[06:54] <GPH-Laptop> Also, what's with the delay in packaging 1.10?
[06:54] <jml> GPH-Laptop: possibly UDS?
[06:55] <awmcclain> spiv: drwxrwsr-x 14 clownfish dev 4096 Dec  8 16:22 andrew
[06:55] <GPH-Laptop> jml: Sorry, UDS?
[06:55] <jml> GPH-Laptop: the Ubuntu Developer Summit that's going on right now.
[06:55] <GPH-Laptop> ah
[06:55] <GPH-Laptop> wasn't aware of that
[06:56] <jml> GPH-Laptop: I haven't been tracking the 1.10 release closely, so it might not be the case
[06:56] <AfC> fwiw, Gentoo Linux has got bzr 1.10 packaged. Great to see them so on top of things.
[06:56] <GPH-Laptop> jml: Doesn't look to be much more than source and Mac OS X 10.5
[06:56] <GPH-Laptop> unfortunately, I'm on 10.4 ;)
[06:57] <fullermd> GPH-Laptop: Do you actually mean the structure of a [shared] _repository_?  Or do you mean of a branch?
[06:58] <fullermd> For a branch, there's always `bzr ls` and its various options.
[06:58] <GPH-Laptop> fullermd: Um... probably a shared repository, but either should do.
[06:58] <GPH-Laptop> Yup, that does it.
[06:58] <GPH-Laptop> Thanks
[06:59] <fullermd> There's nothing in bzr to list _repositories_ as such (at least, not at the UI level), since they're not treated as semantic units.
[07:03] <GPH-Laptop> Alright... but an up-to-date branch serves just as well.
[07:04] <GPH-Laptop> fullermd: Any reason why directories don't have a trailing slash?
[07:05] <fullermd> Well, the flip answer is "because that's how it was written"   :)
[07:05] <fullermd> I don't know if there was an intentional choice to not have them, or whether it "just happened" to be so done.
[07:06] <jml> GPH-Laptop: any reason why they should?
[07:08] <fullermd> Well, there's "because it's conventional".
[07:08] <jml> fullermd: only in some conventions :)
[07:08] <fullermd> Well, in the ones that are Right And Proper, of course.  ;)
[07:09] <GPH-Laptop> jml: There's no other way to differentiate between files and directories (ignoring file extensions, of course)
[07:10] <jml> GPH-Laptop: not visually, no. but why is that useful?
[07:12] <GPH-Laptop> jml: Well, it prints out a list of everything in the branch... Wouldn't you want to be able to know which are files and which are directories, without having to look to see if there are files within that directory? (What if it's empty?)
[07:12] <GPH-Laptop> I would, particularly if I'm copying the list to paste it somewhere else.
[07:13] <GPH-Laptop> regular ls at least has a mode for that, if not the default action
[07:14] <jml> GPH-Laptop: 'bzr ls -v' prints trailing slashes.
[07:14]  * fullermd could really get to hate '-v' sometimes...
[07:14] <GPH-Laptop> but it also prints "V" in front of every line... what does that even mean, anyway?
[07:15] <fullermd> It's listed on every command, even those where it doesn't actually do anything.  There's never any indication of what it _does_.  And most of the things it does aren't what I considered "verbove" anyway.  Blah.
[07:15] <fullermd> GPH-Laptop: "Versioned" presumably.
[07:15] <jml> GPH-Laptop: whether the file is versioned or not.
[07:15] <jml> I still haven't come across a circumstance where I *care* whether a thing is a file or not.
[07:16] <GPH-Laptop> jml: But I didn't ask it that question. I just wanted a list of files and directories.
[07:16] <jml> GPH-Laptop: which question?
[07:16] <fullermd> (which _will_ be the only option when ls is run on a branch without an [accessible] working tree)
[07:16] <GPH-Laptop> whether the file is versioned
[07:16] <jml> GPH-Laptop: are you using a Unix?
[07:16] <GPH-Laptop> jml: Mac OS X
[07:16] <spiv> Yes.  Other possiblities are 'I' for ignored, and '?' for unknown.
[07:18] <jml> GPH-Laptop:  bzr ls -v -V | cut -c 10-
[07:18] <jml> GPH-Laptop: I *think* cut on OS X is close enough for GNU cut to work
[07:19] <GPH-Laptop> wow... that was way too complicated
[07:19] <GPH-Laptop> but yes, it did work
[07:19] <spiv> GPH-Laptop: feel free to file a bug report or post to the mailing list to ask for this behaviour
[07:19] <GPH-Laptop> not that I needed it... my file structure is currently small enough that I could just add the slashes myself (thanks, though)
[07:19] <spiv> GPH-Laptop: I don't think anyone has wanted it before, so the current behaviour is just that way because that's all that was needed so far.
[07:20] <GPH-Laptop> spiv: OK. I just might do that.
[07:20] <spiv> GPH-Laptop: it doesn't sound unreasonable, although it does sound like something that will inspire some bike-shedding...
[07:20] <AfC> bike shedding, hooray!
[07:21] <GPH-Laptop> spiv: I didn't mean to start any arguments. I'm just saying what _I'm_ looking for. ;)
[07:21] <spiv> GPH-Laptop: sure.  I'm glad you're letting us know what you want :)
[07:22] <GPH-Laptop> spiv: I'm glad you're willing to listen. :)
[07:29] <GPH-Laptop> jml, fullermd, spiv: https://bugs.launchpad.net/bzr/+bug/306424
[07:29] <GPH-Laptop> oh
[07:29] <GPH-Laptop> heh
[07:32] <GPH-Laptop> OK, another question
[07:33] <GPH-Laptop> If I branch the bzr development branch, can I run the bzr script from that branch
[07:33] <GPH-Laptop> that is, the modified one?
[07:35] <jml> GPH-Laptop: yes.
[07:35] <jml> GPH-Laptop: /path/to/that/bzr should just work
[07:35] <GPH-Laptop> jml: OK, thanks
[07:35] <jml> GPH-Laptop: that's how bzr developers run unit tests and the like
[07:36] <GPH-Laptop> Is all the code just in that one bzr file?
[07:36] <jml> hell no
[07:36] <GPH-Laptop> I didn't think so
[07:36] <jml> bzrlib/ has all of the code in it.
[07:36] <GPH-Laptop> I guess I'm just looking at Launchpad wrong
[07:38] <drew_> sorry if this may sound elementary, but i stumbled across bazaar in looking for revision control, i just have a simple(hopefully) question.  Does Bazaar track revision numbers on a per file/per branch basis?
[07:39] <GPH-Laptop> drew_: Per branch, I believe
[07:39] <GPH-Laptop> but I'm nowhere near an expert yet ;)
[07:40] <GPH-Laptop> Is Launchpad acting up for anybody else?
[07:41] <jml> GPH-Laptop: not for me.
[07:41] <jml> GPH-Laptop: are you looking at the branch browser or at launchpad proper?
[07:41] <GPH-Laptop> " Sorry, there was a problem connecting to the Launchpad server. "
[07:41] <GPH-Laptop> for example, http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/3883
[07:42] <jml> right, the code browser
[07:42] <GPH-Laptop> yeah
[07:44] <drew_> GPH-Laptop: ty, guess it's time to actually figure out this whole version control thing :)
[07:45] <GPH-Laptop> drew_: Yeah. fullermd patiently helped me when I first got started with bzr... not to put any pressure on him, though ;)
[07:46] <fullermd> It's part of my clever scheme to build up a mass army of people indebted to me, for when I decide to remake the world in my own image.
[07:47] <drew_> :) nah i'll fight my way through(ofcourse i'm stil adjusting to linux in general here) but a peer of mine suggested i look into revision control at home and the only experiance i have is with PDMWorks
[07:47] <Rolly> Hm, never heard of THAT one
[07:47] <drew_> solidworks revision and workflow control
[07:47] <GPH-Laptop> fullermd: I suppose you can count me in on that one. ;)
[07:47] <Rolly> Aha
[07:48] <GPH-Laptop> Now I have to learn Python, too... :P
[07:48] <drew_> ty again, guess it's time to get a scotch and see what i can break :)
[07:49]  * fullermd rubs his hands together and cackles.
[07:49] <GPH-Laptop> lol
[07:49] <jml> drew_: excellent idea
[07:49] <GPH-Laptop> OK... first I have to figure out where the ls code is located...
[07:49]  * jml goes off to consort with enemy languages.
[07:49] <GPH-Laptop> THEN, I can learn Python :P
[07:49] <jml> GPH-Laptop: you trying to fix that bug you just filed?
[07:49] <GPH-Laptop> jml: I was gonna look into it, yeah
[07:49]  * fullermd keeps on working on some perl   :p
[07:49]  * GPH-Laptop does PHP
[07:50] <fullermd> That's what I get paid for most of the time.
[07:51] <jml> GPH-Laptop: feel free to ask me any questions
[07:51] <GPH-Laptop> jml: I kinda just did. ;)
 OK... first I have to figure out where the ls code is located...
[07:52] <GPH-Laptop> ;)
[07:52] <jml> GPH-Laptop: oh right.
[07:52] <jml> GPH-Laptop: so, bzrlib/builtins.py has all of the built in commands
[07:52] <GPH-Laptop> ah
[07:52] <jml> GPH-Laptop: like 'ls'
[07:52] <GPH-Laptop> OK
[07:53] <fullermd> Search in it for cmd_{whatever_command}
[07:53] <jml> GPH-Laptop: there'll be a class called cmd_ls or something like that.
[07:53] <GPH-Laptop> ugh... Launchpad is being naughty again
[07:53]  * fullermd accidentally glances at the 'ls' code.
[07:54] <fullermd>                     if non_recursive and '/' in fp:
[07:54] <fullermd> That's efficient   :p
[07:54] <GPH-Laptop> jml: Loggerhead is being stubborn again.
[07:55] <jml> GPH-Laptop: I'll pass it onto the OSAs.
[07:55] <GPH-Laptop> jml: K, thanks.
[07:55] <jml> GPH-Laptop: url please?
[07:57] <GPH-Laptop> jml: http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/3883?file_id=builtins.py-20050830033751-fc01482b9ca23183
[07:57] <GPH-Laptop> It's on a URL-specific basis?
[07:57] <jml> GPH-Laptop: well, it's working for me.
[07:57] <mwhudson> annotating files with complicated history takes ages :/
[07:58] <mwhudson> this one is a bazaar problem not a launchpad problem, really
[07:58] <jml> yeah.
[07:58] <GPH-Laptop> is there a way to view it non-annotated?
[07:58] <mwhudson> you can download it
[07:59] <jml> GPH-Laptop: if you want to get a local copy of the whole branch, 'bzr branch lp:bzr'
[07:59] <GPH-Laptop> ...without having to download it? ;)
[07:59] <GPH-Laptop> jml: Alright, I might do that
[07:59] <mwhudson> that said
[07:59] <jml> GPH-Laptop: 'bzr cat http://bazaar.launchpad.net/~bzr/bzr/trunk/bzrlib/builtins.py' might get you the file though.
[07:59] <mwhudson> annotating builtins.py locally takes a few seconds
[07:59] <GPH-Laptop> but it would be useful to have the features of ViewVC
[07:59] <mwhudson> so something funny is going on
[07:59]  * GPH-Laptop <3 ViewVC
[08:00] <GPH-Laptop> jml: Nah, that's fine. I'll just do the whole branch.
[08:00] <jml> GPH-Laptop: well, you can get all of those features with the bzr client
[08:00] <jml> GPH-Laptop: although the colors are less pretty :)
[08:00] <GPH-Laptop> heh
[08:01] <GPH-Laptop> jml: Hmm... slow...
[08:01] <GPH-Laptop> should I have run an init or something first?
[08:01] <jml> GPH-Laptop: it's got a biggish history.
[08:01] <jml> GPH-Laptop: no, not really.
[08:01] <GPH-Laptop> OK
[08:02] <GPH-Laptop> I have a feeling it's going to take a long while before I get the hang of this :P
[08:02] <GPH-Laptop> So get used to me ;)
[08:02] <jml> GPH-Laptop: once it's downloaded, you might want to do something like 'bzr init-repo bzr-branches'; 'bzr branch bzr bzr-branches/trunk'
[08:02] <jml> GPH-Laptop: no worries.
[08:03] <GPH-Laptop> bzr-branches being my current directory, or what?
[08:03] <jml> GPH-Laptop: bzr-branches being a new directory that will be a shared repository of all your branches of bzr itself
[08:04] <jml> GPH-Laptop: you can call it susan if you really want.
[08:04] <GPH-Laptop> how is that related to the directory I just did `bzr branch lp:bzr`? Should I issue them in the same directory?
[08:04] <GPH-Laptop> Heh
[08:04] <jml> GPH-Laptop: so, the directory that you're in now isn't special (unless you've already done init-repo)
[08:05] <GPH-Laptop> I may have a bit upstream... I don't recall
[08:05] <GPH-Laptop> would that matter?
[08:05] <jml> GPH-Laptop: what does 'bzr info' say?
[08:05] <GPH-Laptop> not a branch
[08:06] <jml> GPH-Laptop: ok. so it's just a boring old directory.
[08:06] <jml> GPH-Laptop: you want to make a directory like ~/Projects/bzr or whatever you prefer
[08:06] <jml> GPH-Laptop: that will hold all of the branches that you make of bzr itself
[08:06] <jml> GPH-Laptop: but you make that directory using 'bzr init-repo'
[08:06] <GPH-Laptop> ~/Development/bzr/bzr/
[08:06] <GPH-Laptop> is where it is
[08:07] <GPH-Laptop> And, of course, it just created another bzr
[08:07] <jml> GPH-Laptop: so that the branches share their revision data.
[08:07] <GPH-Laptop> so ~/Development/bzr/bzr/bzr/
[08:07] <fullermd> OK, so you can make ~/Development/bzr/ the shared repo, and use reconfig to shuffle the branch you're making into it after it's done.
[08:07] <jml> GPH-Laptop: heh. is that 'bzr branch' command finished?
[08:07] <GPH-Laptop> yeah
[08:07] <fullermd> So, something like
[08:08] <fullermd> cd ~/Development/bzr ; bzr init-repo . ; mv bzr/bzr bzr.dev ; bzr reconfigure --use-shared bzr.dev
[08:08] <fullermd> (or call it 'trunk' instead if you prefer)
[08:08] <jml> right. what fullermd said.
[08:08] <fullermd> (and then that extraneous 'bzr' dir can be tossed too)
[08:09] <jml> and then, to work on your bug fix, go 'bzr branch bzr.dev trailing-slash-bug-306424' (or whatever)
[08:09] <GPH-Laptop> well... the first bzr directory hold more than just Bazaar stuff... it's actually a directory of code that uses bzr... so should I do that in bzr/bzr?
[08:09] <fullermd> Ah, in that case, yah.
[08:10] <GPH-Laptop> so I should have ~/Development/bzr/bzr/bzr.dev/?
[08:10]  * fullermd nods.
[08:10] <GPH-Laptop> OK
[08:11] <fullermd> That'll be your local branch of the bzr trunk, using the shared repo in ~/Development/bzr/bzr/.  Then other branches like ~/Development/bzr/bzr/add-trailing-slash/ can share the repo.
[08:11] <spiv> "bzr/bzr/bzr" sounds a bit swedish chef-like!
[08:11]  * fullermd swats at the fly.
[08:11] <GPH-Laptop> lol
[08:11] <GPH-Laptop> ok
[08:12] <jml> spiv: make a dvcs called "Shantih!" and make us all happy
[08:14] <fullermd> Or maybe "Beetlejuice"   :p
[08:15] <GPH-Laptop> And then I can run ~/Development/bzr/bzr/bug-306424-ls-trailing-slash/bzr to test?
[08:15] <jml> GPH-Laptop: yep
[08:15] <GPH-Laptop> cool
[08:15] <jml> GPH-Laptop: another thing you may be interested in...
[08:15] <GPH-Laptop> yeah?
[08:16] <jml> GPH-Laptop: bzrlib has a lot of unit tests
[08:16] <GPH-Laptop> Will I need to change them?
[08:16] <jml> GPH-Laptop: you might want to add one or two.
[08:16] <GPH-Laptop> Oh, OK
[08:17] <GPH-Laptop> one step at a time, though ;)
[08:17] <jml> GPH-Laptop: "./bzr selftest" will run all of them.
[08:17] <GPH-Laptop> alright, I'll keep that in mind
[08:17] <jml> GPH-Laptop: and './bzr selftest test_ls' should run the ls ones
[08:17] <GPH-Laptop> cool
[08:17] <jml> (which live in bzrlib/tests/blackbox/test_ls.py)
[08:17] <GPH-Laptop> k, got it
[08:18] <fullermd> Running all of them will take some time   :p
[08:20] <GPH-Laptop> Is there a good place for python docs (commands) like there is at php.net?
[08:21]  * fullermd shrugs.
[08:21] <GPH-Laptop> heh
[08:22] <fullermd> Start from python.org and follow likely links.  There are some within a click or two.
[08:22] <GPH-Laptop> ok
[08:23] <GPH-Laptop> What is PyQt4?
[08:25] <jml> GPH-Laptop: it's Python bindings to Qt version 4. Qt is a graphical widget toolkit, used by KDE and others.
[08:25] <GPH-Laptop> the unit test failed because I don't have it
[08:26] <jml> GPH-Laptop: I'm sceptical.
[08:26] <jml> GPH-Laptop: can you paste the command you ran and the output to paste.ubuntu.com (or the pastebin of your choice)
[08:28] <GPH-Laptop> jml: http://gphemsley.pastebin.com/d6a1a95dd
[08:29] <jml> GPH-Laptop: ./bzr --no-plugins selftest test_ls
[08:29] <igc> night all
[08:29] <jml> igc: g'night :)
[08:30] <jml> igc: good to see you back :)
[08:30] <igc> thanks jml
[08:30] <GPH-Laptop> jml: Yup, that did it. Thanks.
[08:30] <GPH-Laptop> igc: Good night stranger. :P
[08:30] <jml> GPH-Laptop: one of your installed plugins requires PyQT
[08:31] <GPH-Laptop> interesting... how come I didn't know that before?
[08:31] <fullermd> Alien mind control rays.
[08:31] <GPH-Laptop> and how come I don't have it?
[08:31] <jml> GPH-Laptop: dunno.
[08:31] <jml> GPH-Laptop: 'bzr plugins' will list the plugins that bzr can find that work
[08:32] <GPH-Laptop> hmm... you think it's qbzr? :P
[08:32] <vila> GPH-Laptop: ./bzr selftest -s bb.test_ls will be far quicker than ./bzr selftest test_ls (give it a try) and it may even works around your plugin problem
[08:33] <GPH-Laptop> vila: Indeed.
[08:34] <vila> GPH-Laptop: the quicker part, the plugin part or both ?
[08:35] <GPH-Laptop> both
[08:35] <spiv> Adding --no-plugins will also work around the plugin problem.  (But I know vila gets sad when people do that...)
[08:35] <vila> spiv: :-)
[08:35] <GPH-Laptop> heh
[08:36] <vila> spiv: try writing a plugin that you want to use to run selftest and you'll quickly get sad too :-)
[08:36] <jml> I'm sad about being hungry.
[08:36] <fullermd> Dangit, you had to mention hungry...
[08:37] <vila> spiv: like, for example, plugging a real hpss server in the test framework :-P
[08:37] <vila> or even an instrumented one :)
[08:37] <spiv> vila: I don't follow that example, currently there's both real and instrumented hpss servers in the test suite...
[08:38] <vila> spiv: by the way, any idea about how to fix FAIL: branch_implementations.test_sprout.TestSprout.test_sprout_preserves_kind(BzrBranchLoomFormat6)
[08:38] <vila>     BzrBranch6('file:///tmp/testbzr-MSlMuJ.tmp/bzrlib.tests.branch_implementations.test_sprout.TestSprout.test_sprout_preserves_kind%28BzrBranchLoomFormat6%29/work/branch2/') is an instance of <class 'bzrlib.branch.BzrBranch6'> rather than <class 'bzrlib.plugins.loom.branch.LoomBranch6'>
[08:38] <vila> spiv: say you want to test an older hpss server then
[08:38] <spiv> (too many real, really; most of the tests that start a TCP server and a thread don't really need to...)
[08:39] <vila> spiv: right, that was just *one* example
[08:40] <vila> but plugging *real* servers into the test framework is still the best way I know of to check bzr compatibility
[08:41] <vila> (even if I understand that you're referring to writing simpler tests)
[08:41] <vila> s/simpler/more focused/
[08:41] <spiv> vila: possibly by deleting the clone method from loom.branch.LoomSupport ?
[08:43] <GPH-Laptop> jml: Oh... bzr files indent with spaces...
[08:43] <spiv> vila: does that test even exist in current bzr.dev?
[08:43] <jml> GPH-Laptop: these days, almost all Python does
[08:43] <GPH-Laptop> jml: Oh, really?
[08:43] <jml> GPH-Laptop: well, all sane Python :)
[08:43] <vila> spiv: isn't it the one you hack with jam ?
[08:44] <spiv> $ grep test_sprout_preserves_kind bzrlib/tests/branch_implementations/test_sprout.py | wc -l
[08:44] <spiv> 0
[08:45] <jml> GPH-Laptop: indent with four spaces. there's a hacking guide in doc/developers/HACKING.txt
[08:45] <jml> GPH-Laptop: (and lots of other juicy docs in the same dir)
[08:45] <GPH-Laptop> jml: Oh. Probably should have looked for that first.
[08:45] <spiv> vila: there's not test_sprout_uses_bzrdir_branch_format
[08:45] <spiv> s/not/now/
[08:45] <vila> 8-)
[08:46] <jml> GPH-Laptop: docs are for looking at second :)
[08:46] <GPH-Laptop> What do you think I should do... add the trailing slash by default or add another option?
[08:46] <GPH-Laptop> heh
[08:46] <spiv> vila: and it passes
[08:46] <fullermd> I'd be in favor of it just being there always.
[08:46] <jml> GPH-Laptop: add it by default.
[08:47] <spiv> vila: (I'm still suspicious of LoomSupport.clone, though...)
[08:47] <vila> spiv: great ! Looks like I should update the bottom thread in my loom !
[08:47] <vila> The comment talks about updating the nick too
[08:47] <fullermd> For even extra fun and bikeshedding, add a * on executable files too   :p
[08:47] <jml> (why doesn't ubuntu ship with wireshark by default?)
[08:47] <jml> fullermd: !
[08:47] <fullermd> (the lack of something like that has made me very cranky in the past)
[08:47] <jml> fullermd: definitely would want that in an option
[08:47] <vila> fullermd, GPH-Laptop : Don't forget the '@' for symlinks !
[08:48] <jml> fullermd: not in default behaviour
[08:48] <fullermd> See?  Instant argument; just add fullermd!
[08:48] <vila> --decorated --color... definetly bikeshedding when color becomes an option :)
[08:48] <spiv> jml: possibly because default installing software with a history of exploits that allow executing arbitrary code makes people nervous
[08:49] <GPH-Laptop> heh
[08:49] <GPH-Laptop> jml: so... anything besides slash in default?
[08:49] <spiv> "I want my bikeshed to be suffixed with the @ character!"
[08:50] <fullermd> Adding the / is probably a safe thing to have on it.  I can't offhand think of anything it would hurt...
[08:50] <fullermd> spiv: Don't be such a rogue   :p
[08:50] <jml> GPH-Laptop: no.
[08:50] <jml> GPH-Laptop: just '/'.
[08:50] <spiv> Adding @ at least has some consistency with adding /; they are both signifiers of the inventory entry type.  * doesn't have that distinction.
[08:51] <vila> The only case I know of where *not* having the final '/' hurts is Apache
[08:51] <spiv> At some point the answer is "if you want a custom tree formatter, there's an API you can use..." :)
[08:51] <fullermd> True.  OTOH, (1) the '/' doesn't harm anything I can think of offhand ('cd', 'ls', etc) you'd paste it to, where '@' would.
[08:52] <fullermd> And (2) there's no case [on POSIX] where a trailing '/' could validly appear, so you could always sed it away if you wanted, whereas a trailing @ could be significant.
[08:52] <fullermd> [in the filename I means]
[08:52] <jml> I'm using wireshark to track some machine-local traffic, how do I filter so I only capture one direction?
[08:53] <spiv> jml: filter on src port?
[08:53] <fullermd> Specify src/dest port.
[08:53] <spiv> (or dst port)
[08:53] <jml> how do I do that?
[08:53] <spiv> That's how the TCP stack distinguishes them, after all.
[08:53] <spiv> With much clicky-clicky.
[08:53] <jml> spiv: yeah, there's a sense in which you just restated my question :)
[08:54] <fullermd> "and src 123"
[08:54] <jml> hmm... I think I want a *capture* filter, not a display filter
[08:54] <jml> (they have different syntax, yay!)
[08:54] <fullermd> Oh.  Display filter would work too...
[08:54] <spiv> "tcp.srcport == 1234" looks likely.
[08:55] <spiv> (I clicky-clicked on the "+ Expression..." button, expanded the "TCP" filters, etc etc...
[08:55] <spiv> )
[08:56] <spiv> (I'm sure you'd have been as distressed as me if I hadn't closed that paren)
[08:57] <jml> spiv: good grief! I wonder what the alternative UI design was :)
[09:01] <GPH-Laptop> jml: Is there any special protocol for commit messages in my local branch/
[09:01] <GPH-Laptop> ?
[09:01] <vila> spiv: ./bzr selftest -s bt.branch_implementations.test_sprout -v not failing anymore ! Hurrah ! :-)
[09:03] <jml> GPH-Laptop: not at all.
[09:03] <jml> GPH-Laptop: generally, you just want to make them helpful.
[09:04] <jml> GPH-Laptop: also, if you haven't used a dvcs before, you want to commit way more often than you are used to :)
[09:07] <GPH-Laptop> jml: I think I'm pretty much done
[09:07] <GPH-Laptop> it was pretty simple
[09:07] <GPH-Laptop> but how come it seems like the unit tests aren't all being run?
[09:07] <GPH-Laptop> that is,
[09:07] <GPH-Laptop> some of the test lines don't give errors when I forgot to fix them
[09:07] <jml> GPH-Laptop: 'bzr di -r submit:' should generate you a diff, I think. If you pastebin it I can take a look.
[09:11] <GPH-Laptop> jml: http://gphemsley.pastebin.com/d1454f2dd
[09:12] <GPH-Laptop> oh wait
[09:12] <GPH-Laptop> I think I have a little optimization to do
[09:12] <GPH-Laptop> hang on
[09:14] <jml> GPH-Laptop: looks fine to me. If you do 'bzr send' once you're done, that will prepare a merge directive (a patch on steroids) and attach it to a message, you can then send it to the mailing list.
[09:14] <jml> GPH-Laptop: the HACKING guide has some more info about that.
[09:15] <GPH-Laptop> jml: http://gphemsley.pastebin.com/d2ef5b771
[09:17] <fullermd> I dunno if I'd reuse outstring like that...   but that's stylistic quibbling.
[09:19] <GPH-Laptop> fullermd: Well, it is the outstring... isn't it?
[09:19] <fullermd> No, it's a filename.  It doesn't replace outstring, it replaces fp, so I'd call it 'fnstr' or something like that, and replace the requests for fp with it.
[09:20] <jml> send it to the mailing list!
[09:20] <jml> that way, stylistic quibbling will get the patch landed :)
[09:20] <GPH-Laptop> heh
[09:20] <GPH-Laptop> ok
[09:20] <fullermd> Hey!  We have to run the gauntlet of the IRC bikeshed before we can run the ML bikeshed!
[09:21] <GPH-Laptop> I edited the NEWS file... anything else I have to do before sending it?
[09:22] <mwhudson> is there some way to force bzr to use paramiko over openssh?
[09:22] <luks> BZR_SSH=paramiko ?
[09:23] <GPH-Laptop> jml: Does the merge directive include my commit messages?
[09:23] <jml> GPH-Laptop: yes, it does.
[09:25] <mwhudson> luks: you are my hero
[09:27] <GPH-Laptop> jml: OK, so now I just e-mail it?
[09:27] <GPH-Laptop> Or should I attach it to the bug?
[09:27] <jml> GPH-Laptop: yeah. put [MERGE] at the start of the subject, and include text that human beings will read
[09:28] <jml> GPH-Laptop: (assuming you are using bzr send)
[09:28] <jml> GPH-Laptop: and send it to the mailing list. Include a link to the bug as well.
[09:28] <GPH-Laptop> I did send -o
[09:28] <GPH-Laptop> is that OK?
[09:28] <jml> GPH-Laptop: sure. just attach the output to your email
[09:28] <GPH-Laptop> and do I attach it to the bug?
[09:29] <jml> GPH-Laptop: no
[09:29] <GPH-Laptop> OK
[09:29] <jml> GPH-Laptop: if you want, push your branch to Launchpad (bzr push lp:<yourusername>/bzr/<branch-name>)
[09:29] <jml> GPH-Laptop: and then link that branch to the bug.
[09:36] <GPH-Laptop> jml: It says invalid branch name
[09:36] <spiv> GPH-Laptop: use a valid one, then *wink*
[09:37] <spiv> What name did you try?
[09:38] <luks> GPH-Laptop: it's easier to just mail it :)
[09:38] <GPH-Laptop> spiv: bzr push lp:gphemsley/bzr/bug-306424-ls-trailing-slash
[09:39] <luks> missing ~
[09:39] <spiv> GPH-Laptop: your username needs to be prefixed with a ~
[09:39] <GPH-Laptop> oh
[09:39] <spiv> so bzr push lp:~gphemsley/bzr/bug-306424-ls-trailing-slash
[09:39]  * GPH-Laptop nudges jml 
[09:39] <spiv> jml: tsk tsk :P
[09:39]  * spiv wanders off
[09:39] <luks> but really, isn't pushing the whole bzr just for one patch an overkill?
[09:40]  * GPH-Laptop shrugs
[09:40] <spiv> Sometime soon we should update the branch format of bzr trunk so that pushing bzr branches to launchpad will use stacking.
[09:40] <GPH-Laptop> may as well learn the process
[09:40] <strk> how do I switch to a specific revno ?
[09:41] <spiv> strk: bzr pull --overwrite -r REVNO, usually
[09:41] <jml> sorrry
[09:41]  * spiv really wanders off
[09:47] <GPH-Laptop> jml: OK, posted to the mailing list, but awaiting moderation
[09:49] <GPH-Laptop> Branch available @ https://code.launchpad.net/~gphemsley/bzr/bug-306424-ls-trailing-slash
[09:50] <strk> spiv: thanks!
[09:53] <jml> GPH-Laptop: thanks
[09:53] <strk> chefan: is
[09:53] <jml> GPH-Laptop: I don't have moderation privileges, but I'll ping poolie or someone similar tomorrow.
[09:54] <GPH-Laptop> jml: OK
[09:54] <GPH-Laptop> then I'll head off to bed
[09:54] <jml> GPH-Laptop: ok. g'night.
[09:55] <GPH-Laptop> jml: g'night
[11:54] <spiv> GPH-Laptop: moderated
[14:49] <lamont> can I safely remove .bzr/repository/obsolete_packs? or is there a command to prune the cruft from the repo?
[14:50]  * lamont checks to see what bzr pack buys him
[14:51] <Peng_> lamont: You can empty the directory, but I don't think you can delete it.
[14:52] <Peng_> lamont: Anyway, there's no real reason to. It'll be cleaned out (and filled with new packs) the next time the repo is auto-packed or you run "bzr pack".
[14:52] <lamont> neat.  bzr pack brought me from 808MB clear down to 1150MB
[14:53] <Peng_> lamont: Right. When a pack is no longer needed, it's moved to obsolete_packs instead of being deleted outright, in case something goes wrong.
[14:53] <luks> if will be cleaned up and new obsolete packs will be added
[14:53] <lamont> otoh, .bzr/repository/packs went from 574920->574904 (woo!!) while obsolete_packs went from 233MB->574MB
[14:53] <luks> *it
[14:54] <Peng_> lamont: When it auto-packs, some packs will be compressed down into one, and the old ones will be moved to obsolete_packs. When you run "bzr pack", *everything* will be compressed down to one pack, so obsolete_packs will have a copy of the entire repo.
[14:54] <lamont> right
[14:55] <lamont> is there a way to tell bzr that I actually do backups of the machine and to quit saving me from myself by bloating said backups with extra copies of everyting?
[14:56] <Peng_> Heh.
[14:56] <Peng_> Can your backup software exclude obsolete_packs?
[14:56] <lamont> it could
[14:56] <Peng_> (I mean, exclude the contents of it. The directory itself needs to exist.)
[15:13] <lifeless> lamont: sounds like you'd just hit a extreeme autopack anyhow; obsolete_packs' contents are automatically pruned
[15:13] <lamont> lifeless: I manually did 'bzr pack' to see if it would help.
[15:13] <lamont> which, uh, not so much
[15:13] <lifeless> lamont: yes, I saw
[15:14] <lifeless> for obsolete_packs to have been at 250MB it must ave already just packed 50% of your archive
[15:16] <lamont> well... total of 11 files in the archive
[15:16] <lamont> 42MB, 1.1MB, 1.1MB, and < 10k
[15:17] <lamont> so 575 MB of .bzr, and another 50MB total in the tree.
[15:17] <lifeless> you're versioning a 422MMMB file?
[15:17] <lamont> sure.  iz histyory
[15:17] <lamont> ot
[15:18] <lamont> it's also not very compressable, since it's already,uh, bit-indexed data
[15:18] <lamont> I stand corrected.  bzip2 takes it down from 42.2MB to 28.0 MB
[15:19] <lamont> the tree has a whopping 36 commits, and no branches
[15:20] <lifeless> ok
[15:20] <lifeless> so at the 30th commit it autopacked
[15:20] <lifeless> that gave you te 250mb thing
[15:20] <lifeless> then 6 more commits that didn't autopack
[15:21] <lifeless> the 40th would have trimmed wiped obsolsete_packs and then moved the 10 most recent files into there when autopacking again.
[15:21] <lamont> ok
[15:21] <lamont> every 10 or so then?
[15:37] <lifeless> lamont: it allows no more than 10 packs with a given revision count, rounded up to the next base10 digit
[15:38] <lifeless> lamont: e.g. 10 of 1, 10 of 10, 10 of 100 etc
[15:38] <lifeless> lamont: so log backoff
[15:38] <lamont> ah, ok
[15:38] <lamont> hrm.. why no bzrtools 1.10-1 backport for dapper?
[15:39] <lifeless> because you haven't done one yet?
[15:39] <lamont> s/you/poolie et al/
[15:40] <lamont> or will bzrtools 1.9.1-1~dapper1 "just work" with bzr 1.10-1?
[15:40] <lifeless> dunno, where did the dapper binary comefrom
[15:48] <lamont> lifeless: jam did the upload it would appear
[15:48] <lamont> besides, I don't have write privs to the ppa :-p
[15:49] <lifeless> lamont: file a bug, surely you should be able to :)
[15:49] <lamont> heh
[15:49] <lamont> ah.  iz funnier when read that I should surely be able to file a bug.
[15:53] <jam> lamont, lifeless: I haven't been packaging dapper because it needs different settings from all of the other packages
[15:53] <jam> most of them are just "dch && bzr commit && bzr builddeb"
[15:54] <lamont> jam: we still need/want dapper... and pushing it back to y'all is specifically because it requires a merge instead of a smack...
[15:54] <lamont> wc -l /home/lamont/bin/build-package
[15:54] <lamont> 300 /home/lamont/bin/build-package
[15:54] <lamont> ^ I already have a bitchslap script
[15:58] <jam> lamont: so why no concern over bzr-svn? Which has never been packaged for dapper
[15:58] <lamont> because that machine is running hardy.
[16:03] <awilkins> Ok, https://bugs.launchpad.net/bzr/+bug/304023
[16:03] <awilkins> I've traced a fail and a success, and it looks like the success should be failing :-)
[16:04] <lamont> jam: and bzr should require more than just smackery for dapper, too.  py-support vs py-central
[16:04] <jam> lamont: that is already handled by someone else
[16:04] <jam> "has been handled"
[16:04] <jam> and yes it does
[16:05] <lamont> right
[16:05] <jam> building the "bzr" package is automated
[16:05] <jam> building bzr and bzr-svn still requires me to do a lot of manual steps
[16:05] <jam> because they aren't built in the same way
[16:05] <jam> bzrtools and bzr-svn are generally built from the debian package
[16:05] <lamont> yeah - bzr-svn just needs hardy, bzrtools needs dapper/hardy
[16:06]  * awilkins has a roughly automated build script for either, maybe it could be done for both
[16:06] <jam> and the debian package doesn't support dapper
[16:06] <awilkins> My script is Powershell though, and rather specific to my environment at present
[16:06] <jam> because of py-central versus py-support
[16:06] <awilkins> (on win32 at any rate)
[16:06] <lamont> yep
[16:07] <jam> also, we run into weird problems with multiple-targets and "bzr builddeb" if you build from a bzr tree rather than from a tarball
[16:07] <jam> because it rebuilds the tarball
[16:07] <jam> which causes the md5sum to change
[16:07] <jam> which causes it to fail to upload
[16:07] <jam> etc
[16:07] <jam> which is partially why I do it manually
[16:08] <jam> as I build a tarball for the first time, and then re-use that tarball for all the others
[16:08] <jam> anyway, *right now* I'm on win32, which is a real pain for building packages :)
[16:09] <jam> If you are stressing that getting bzrtools-1.10~dapper1  is very important for you I can do something about it
[16:09] <jam> lamont: What is your specific need/urgency/etc ?
[16:27] <GPH-Laptop> jml, fullermd: Are you around?
[17:49] <Peng_> lifeless: brisbane-core uses more disk space right now, right? But that's because compression hasn't been optimized yet, and it will become significantly better than the current stuff, right?
[17:59] <lifeless> Peng_: yes, its more  disk space for the inventories
[18:00] <Peng_> Thanks for the confirmation.
[18:00] <lifeless> Peng_: massively less uncompressed
[18:00] <Peng_> What?
[18:00] <Peng_> That it's much smaller when not compressed?
[18:01] <lifeless> Peng_: the inventories inv development4 are about one 20th the size of the inventories in --1.9 *before compression*
[18:01] <lifeless> Peng_: but --development4 doesn't delta compress the inventories, just gzips, at the moment
[18:02] <Peng_> How good should they be when they're delta compressed?
[18:02] <lifeless> better than 1.9, but more than that I can't say
[18:03] <lifeless> we have a feedback loop to do to tune them - the inventories may change to be more compressable, for instance
[18:03] <pygi> poolie, hey, could I poke for a sec? :)
[18:03] <Peng_> The inventories are much smaller when uncompressed, but what does that buy me as a user? On disk, they're always compressed.
[18:04] <lifeless> Peng_: bzr spends less time comparing the inventories between two revisions, so fetch, log -v, and other such commands have less work to do
[18:04] <Peng_> lifeless: Ah, that sounds good.
[18:04] <poolie> hello pygi
[18:04] <Peng_> Would memory usage be improved too?
[18:04] <lifeless> Peng_: yes
[18:04] <seb_kuzminsky> ongoing svn->bzr switch saga...
[18:05] <lifeless> Peng_: e.g. mysql-server has a 1.7MB inventory, on average (in 1.9). So diff requires assembling 3.4MB of text, parsing it, then doing a full dict comparison between the objects
[18:05] <seb_kuzminsky> i've read the Bazaar User Reference, and i can see how to add a client-side post-commit email hook, but i'd prefer to do the email-sending via a single server-side post-commit hook i think
[18:06] <seb_kuzminsky> the developers all have login accounts on the server, and we use bzr+ssh to commit/push
[18:06] <lifeless> Peng_: in split-inv, we read a tree on demand, so we may only read 30 or 40 k of data - total.
[18:06] <seb_kuzminsky> is that possible somehow?  if so where's it documented?  ;-)
[18:07] <lifeless> seb_kuzminsky: it is possible; s piv made it so, I'm not 100% sure what-all is needed :)
[18:08] <seb_kuzminsky> hm
[18:08] <seb_kuzminsky> also a post-commit hook to poke the buildbot would be nice
[18:09] <lifeless> seb_kuzminsky: spiv will be online in about 4 hours
[18:09] <seb_kuzminsky> ok thanks lifeless
[18:09] <lifeless> seb_kuzminsky: but generally, try just insalling bzr-email on the server and see what happens :)
[18:10] <seb_kuzminsky> i tried that, now when i "bzr up" in my checkout (bound branch) i get this warning message:
[18:10] <Peng_> Errm, BTW, sorry about not getting around to the bzr search index thingy yet. I have been busier than usual, but mostly I'm just goofing off and being lazy. :\
[18:10] <seb_kuzminsky> /usr/lib/python2.5/site-packages/bzrlib/plugins/email/__init__.py:57: DeprecationWarning: bzrlib.branch.BranchHooks.install_hook was deprecated in version 1.5.
[18:10] <seb_kuzminsky>   Branch.hooks.install_hook('post_commit', branch_commit_hook)
[18:10] <lifeless> Peng_: no worries
[18:10] <seb_kuzminsky> bzr 1.10rc1
[18:10] <lifeless> seb_kuzminsky: did you install  bzr-email via package?
[18:11] <seb_kuzminsky> bzr-email 0.0.1~bzr5 (Debian Sid's standard .deb)
[18:11] <seb_kuzminsky> maybe i should bypass debian and grab bzr & friends from lp
[18:11] <seb_kuzminsky> oops, typo, that' bzr-email 0.0.1~bzr25-1.1
[18:11] <seb_kuzminsky> whatever that means ;-)
[18:12] <seb_kuzminsky> "bzr plugins" doesnt show a version number for email
[18:14] <lifeless> right the debian package is old
[18:14] <lifeless> file a bug there asking for a new version to be packaged :P
[18:15] <seb_kuzminsky> ok will do
[18:16] <lifeless> now, for yourserver, you can probably just ap-tget source bzr-email
[18:16] <lifeless> grab the bzr-email upstream (bzr branch lp:bzr-email)
[18:16] <lifeless> drop the newer source on top of the debian source package, and rebuild it
[18:17] <seb_kuzminsky> sorry, i had the "testing" version installed, there's a newer one in sid
[18:17] <seb_kuzminsky> the sid one is "bzr34"
[18:17] <seb_kuzminsky> from august sometime
[18:18] <seb_kuzminsky> i'll try that
[18:21] <seb_kuzminsky> looks like it's pretty close to top-of-tree bzr-email, it's just missing some test suite fixes
[18:24] <seb_kuzminsky> with bzr-email r34 (from Sid) it no longer gives an error when committing :-)
[18:27] <seb_kuzminsky> hm, the "bzr help email" only talks about configuring client-side post-commit email-sending hooks
[18:44] <seb_kuzminsky> ok i think i'm thinking about this wrong
[18:44] <seb_kuzminsky> we've been using subversion, but we're switching to bzr
[18:44] <seb_kuzminsky> i'm basically trying to replicate our existing svn infrastructure using bzr
[18:45] <seb_kuzminsky> the sticking points are server-side post-commit hooks
[18:45] <seb_kuzminsky> one for sending email on commit, and another for prodding the buildbot
[18:45] <seb_kuzminsky> this seems to be not well supported in bzr currently
[18:45] <seb_kuzminsky> so bzr admins must be using some other mechanism to accomplish something similar
[18:46] <seb_kuzminsky> in terms of workflow, we're using something like one of the "Centralized" flows, or "decentralized with shared mainline"
[18:46] <seb_kuzminsky> how do others do this?
[19:12] <lifeless> seb_kuzminsky: how did you go?
[19:13] <lifeless> seb_kuzminsky: re: bzr-email docs, when the server runs the mail hook the *server* acts as the client
[19:13] <seb_kuzminsky> lifeless: i'm not there yet, but still trying :-)
[19:14] <seb_kuzminsky> the bzr-email hook runs in the server's copy of the branch, i get that
[19:14] <seb_kuzminsky> but where does it get its configuration from?  from the user who's running bzr, right?
[19:14] <lifeless> you can configure it in branch.conf
[19:15] <seb_kuzminsky> hm
[19:15]  * seb_kuzminsky is rereading the docs
[19:18] <GPH-Laptop> jml, fullermd: Are you around?
[19:18] <seb_kuzminsky> so it's ok to edit .bzr/branch/branch.conf?  the .bzr/README told me not to
[19:18] <GPH-Laptop> jam: What about you? You around?
[19:19] <jam> GPH-Laptop: absolutely not :)
[19:19] <GPH-Laptop> heh
[19:19] <GPH-Laptop> jam: Just wondering if you saw my response to your e-mail?
[19:20] <jam> I did
[19:20] <GPH-Laptop> I wasn't sure what poolie's response meant
[19:20] <jam> I would probably still be more in favor of writing out the plain fp if --null is given
[19:20] <jam> I don't think he fully understood
[19:20] <jam> I know I was wrong in thinking that it would give @, etc
[19:20] <lifeless> seb_kuzminsky: we're a little unclear about things; yes its ok to edit .bzr/branch/branch.conf
[19:21] <seb_kuzminsky> okay then :-)
[19:21]  * seb_kuzminsky edits
[19:21] <jam> I'll go ahead and respond to the email so it is documented :)
[19:22] <GPH-Laptop> ok, thanks :)
[19:24] <GPH-Laptop> jam: Also, any idea why I got an e-mail about not having voting rights?
[19:24] <GPH-Laptop> from Bundle Buggy
[19:25] <jam> I believe when you replied to me, it didn't properly "quote" my BB:resubmit vote.
[19:25] <jam> I'm not 100% sure ,though
[19:26] <jam> It *looks* like your mail client is indenting the response, but not prefixing it with ">"
[19:26] <GPH-Laptop> Ah
[19:26] <GPH-Laptop> Alright, I'll change to unformatted
[19:26] <GPH-Laptop> you can thank Gmail for that ;)
[19:26] <seb_kuzminsky> lifeless: now the server's .bzr/branch/branch.conf says this:
[19:27] <seb_kuzminsky> post_commit_to = seb@highlab.com
[19:27] <GPH-Laptop> jam: So, am I to make a change and resubmit?
[19:27] <seb_kuzminsky> and "bzr hooks" shows post_commit as bzr-email
[19:27] <jam> We need 1 other person to approve it.
[19:27] <lifeless> seb_kuzminsky: that sounds good
[19:27] <jam> The change is small enough that someone can do it for you
[19:27] <seb_kuzminsky> i'm not setting post_commit_mailer, so it should default to /usr/bin/mail
[19:27] <jam> but if you do it, it is easier on us :)
[19:27] <lifeless> seb_kuzminsky: yes
[19:27] <seb_kuzminsky> i can send myself email that way
[19:27] <seb_kuzminsky> but when i commit, i get nothing
[19:28] <GPH-Laptop> jam: Alright. Same way? bzr send -o?
[19:28] <jam> should be fine
[19:28] <GPH-Laptop> jam: Can I just reply to that e-mail?
[19:28] <jam> as long as you attach a patch you can just reply
[19:28] <GPH-Laptop> okey doke
[19:29] <jam> BB should notice and mark the patch as superseding the previous one
[19:29] <seb_kuzminsky> lifeless: my commits are happening (i can pull them)
[19:30] <seb_kuzminsky> but the mailserver logs on the bzr server machine show nothing going out, and the mailserver logs on the receiving side (highlab.com) see nothing coming in
[19:30] <lifeless> seb_kuzminsky: what bzr client and server versions do you have ?
[19:30] <seb_kuzminsky> the server is 1.6.1, with bzr-email r34
[19:31] <seb_kuzminsky> er, the server is 1.10rc1, with bzr-email r34
[19:31] <seb_kuzminsky> sorry
[19:31] <seb_kuzminsky> the client is 1.6.1
[19:31] <lifeless> I think you need a newer client
[19:31] <lifeless> let me check
[19:33] <seb_kuzminsky> lifeless: why should the client version matter?  isnt it the bzr on the server doing this work (the client commits on a bound branch)
[19:36] <lifeless> seb_kuzminsky: older clients do more things via the VFS than via RPC calls
[19:36] <poolie> hell jam
[19:36] <jam> i'm sorry poolie, I didn't mean to upset you :)
[19:36] <seb_kuzminsky> lifeless: gotcha
[19:37] <lifeless> seb_kuzminsky: so 1.6 looks like it should be ok
[19:37] <lifeless> seb_kuzminsky: I'm not sure whats wrong, digging
[19:38] <mwhudson> so i have a bazaar install which is doing annotates (at least) REALLY slowly
[19:38] <poolie> hella jam dude
[19:38] <mwhudson> all the c extensions are built now, though it's possible they're not being used for some stupid reason
[19:38] <mwhudson> how can i debug this?
[19:39] <seb_kuzminsky> lifeless: i committed in a bound branch on the server, and it sent out the email
[19:39] <jam> mwhudson: how slow is slow? And what version of bzr?
[19:39] <jam> We had a fix recently
[19:39] <poolie> mwhudson: press C-\ in the middle of the annotate and look at where it is
[19:39] <poolie> and what he said
[19:39] <jam> bzr 1.9
[19:39] <lifeless> seb_kuzminsky: ah!
[19:39] <mwhudson> jam: ah, maybe it's just relative age, indeed
[19:39] <mwhudson> the slow one is tiocsctty
[19:39] <mwhudson> no
[19:39] <mwhudson> 1.7.1rc1
[19:39] <mwhudson> (fricking x clipboards)
[19:39] <jam> mwhudson: so bzr 1.6 introduced a regression
[19:40] <jam> where we weren't using the stored values
[19:40] <jam> we fixed that in bzr 1.9
[19:40] <mwhudson> jam: ok, that went easily then
[19:40] <mwhudson> (glad i asked!)
[19:42] <seb_kuzminsky> is there a preferred way to install a newer bzr on Intrepid?  backports doesnt have anything.  a PPA maybe?
[19:42] <mwhudson> yes, the "bzr" ppa
[19:42] <seb_kuzminsky> thanks mwhudson
[19:43] <lifeless> seb_kuzminsky: ok, its because bzr-email uses the post_commit hook
[19:43] <poolie> jam, i started on a namedtuple-like object
[19:43] <poolie> and am trying to get it to pass tests in dirstate.py
[19:43] <poolie> currently just written in python
[19:43] <poolie> it certainly looks better
[19:43] <lifeless> seb_kuzminsky: could you please file a bug, that it should support [optionally] using post_change_branch_tip as well, with an option to enable that
[19:43] <seb_kuzminsky> lifeless: instead of the post-tip-change hook
[19:43] <seb_kuzminsky> lifeless: ok will do
[19:43] <poolie> we'll have to see if it's possible to make a C version comparably fast to Py_Tuple
[19:44] <lifeless> seb_kuzminsky: it can't just swithc over, because 'pull' locally shouldn't usually email :)
[19:44] <jam> sounds interesting
[19:45] <GPH-Laptop> jam, poolie: Any idea why all packages aren't available for 1.10 yet?
[19:45] <jam> GPH-Laptop: what packages are you looking for?
[19:46] <jam> poolie: I would imagine you could get close, with the exception of anything that is folded into the interpreter directly
[19:46] <jam> poolie: the other question would be what the overhead of using the named arguments instead of the offset
[19:46] <seb_kuzminsky> lifeless: is it similar to this: https://bugs.launchpad.net/bzr-email/+bug/250934
[19:47] <lifeless> seb_kuzminsky: oh, identical - thats fine
[19:47] <GPH-Laptop> jam: Mac OS X 10.4
[19:47] <seb_kuzminsky> domo arigato mr ubottu  ;-)
[19:47] <poolie> heh
[19:47] <poolie> jam, good question
[19:48] <GPH-Laptop> jam: Hey, by the way, looks like I made a boo-boo on my last commit message.
[19:48] <jam> Since i believe it will be implemented as "name => offset => get" there will obviously be *some* overhead
[19:48] <poolie> i might leave this angle of getting the python impl to pass and instead write up the C version and do some microbenchmarks
[19:48] <jam> GPH-Laptop: the Mac installers are built by the community, so someone just has to wake up and do it.
[19:48] <GPH-Laptop> jam: It kinda expanded my "`bzr ls`" to be the contents of the current directory.
[19:48] <GPH-Laptop> jam: Ah, OK
[19:49] <poolie> jam, what do you mean by "name => offset => get"
[19:49]  * Peng_ points out that there are already namedtuple implementations out there.
[19:49] <GPH-Laptop> Is there a command to change the commit message?
[19:49] <Peng_> GPH-Laptop: No.
[19:49] <jam> GPH-Laptop: bzr uncommit; bzr commit -m "new message"
[19:49] <Peng_> I -- yeah, what he said.
[19:49] <GPH-Laptop> alright
[19:49] <GPH-Laptop> should I resubmit again?
[19:50] <jam> you can't really change one after-the-fact
[19:50] <jam> but you can regenerate the commit
[19:50] <jam> if it is important to you, you can email it to me
[19:50] <Peng_> If it's just a typo, it's not worth fixing (you should look at bzr.dev's history...)
[19:51] <GPH-Laptop> Peng_: It kinda contains the contents of the directory instead of just the name of the command ;)
[19:51] <poolie> Peng_: in C?
[19:53] <GPH-Laptop> Alright, I'll be back later.
[19:53] <Peng_> GPH-Laptop: Heh, nice.
[19:54] <poolie> Peng_, there is http://svn.python.org/projects/python/trunk/Objects/structseq.c but it's not exposed in python
[19:54] <GPH-Laptop> jam: Alright, new patch sent.
[19:54] <GPH-Laptop> adieu
[19:55] <Peng_> poolie: Ah... Never mind, then, I gues.s
[19:55] <poolie> it would be nice if there were
[19:55] <poolie> i thought that 2.6 namedtuples
[19:55] <jam> Peng_: IIRC 2.6 does have a namedtuple class
[19:55] <jam> but it is *really* crummy
[19:55] <poolie> would do this directly, but in 2.6.0 they're slower than objects
[19:56] <jam> it is a pure-python class
[19:56] <jam> and does things *really* weird
[19:56] <jam> like using "eval()"
[19:56] <poolie> after thinking about this a bit more, i'm not convinced they should be tuple subclasses
[19:56] <poolie> or more precisely, "should provide the tuple protocol"
[19:56] <Peng_> jam: Yeah, it's pure Python, and uses exec.
[19:57] <jam> the reason we *use* tuples is because they are very fast to create
[19:57] <poolie> but we could use Py_StructSeq, unless we can do something faster
[19:57] <jam> so named tuple breaks that
[19:58] <poolie> so being able to index things by ints, or iterate them, or take the length, when they're not conceptually sequences, is a bit of a bug source
[20:00] <seb_kuzminsky> lifeless: i installed bzr 1.10 on my client & still no email when i commit, is that expected from the bzr-email hook hooking in the wrong place?
[20:01] <lifeless> seb_kuzminsky: do you mean commit or push?
[20:06] <lifeless> jelmer: ping
[20:10] <lifeless> seb_kuzminsky: I've uploaded draft code to mail on push/pull for you, to http://bazaar.launchpad.net/~/bzr/bzr-email/trunk
[20:12] <pygi> poolie, ups, sorry, I was out to eat :)
[20:26] <poolie> np
[20:33] <seb_kuzminsky> lifeless: wow, thanks for the draft code!!
[20:33] <seb_kuzminsky> lifeless: the client has a heavy checkout (a bound branch), and i did commit in there, and it didnt email me
[20:33] <seb_kuzminsky> i'll try again with your new code, thanks!
[20:43] <seb_kuzminsky> lifeless: aww yeah!!
[20:43] <seb_kuzminsky> thank you
[20:56] <lifeless> seb_kuzminsky: my pleasure
[21:34] <Oli``> I'm currently using one big bzr repo for all my website projects. I'm a few days down the road now and 3 sites in and it's already pretty slow to work out commits. Is it possible to split these 3 directories into their own repos (keeping, if possible, ignore settings and revision info from the existing repo)
[21:35] <luks> is it a big repo or a big branch?
[21:35] <Peng_> I doubt the repo is making a significant difference.
[21:35] <Peng_> Well, some, but..
[21:36] <Oli``> yeah I'm probably using the wrong terminology... I typed bzr init. made 3 directories inside with all the site files in each of those and that's where I am =)
[21:36] <Peng_> Oh, one big branch.
[21:38] <Oli``> Peng_: does that make a difference to what you said?
[21:42] <Peng_> Oli``: Yes. Committing requires the entire working tree to be scanned for changes, so obviously the size of the branch matters.
[21:42] <Peng_> But that probably doesn't happen if you run "bzr commit some_file", and you might be experiencing slowness for other reasons too.
[21:42] <Peng_> Oli``: What version of bzr?
[21:43] <Oli``> 1.10
[21:43] <Oli``> Ubuntu PPA, I believe
[21:43] <Peng_> Oh.
[21:43] <Peng_> I was hoping it was some really old version, so upgrading would make everything much faster. :P
[21:43] <lifeless> Oli``: generally, we'd say one branch per project :)
[21:44] <Oli``> lifeless: yeah I was being lazy to see if I wanted to stick with bzr
[21:44] <lifeless> Oli``: if they are all one website, one branch is fine, but if they are for different VHosts it reallu doesn't make sense to use one branch
[21:44] <lifeless> Oli``: bzr commits should not slow down noticably under about 5000 files
[21:44] <Oli``> hmm.. they're each only about 30 files each =\
[21:45] <Peng_> Oli``: Would any of the files happen to be gigantic?
[21:45] <lifeless> Oli``: are you committing .iso files or similar ? :)
[21:45] <Oli``> nope. python source files, jpeg images (small, sub-200k)
[21:45] <Oli``> css, javascript, nothing scary
[21:45] <lifeless> Oli``: can you do 'time bzr st'
[21:47] <LarstiQ> Oli``: are you using a checkout against a remote machine, or a local branch?
[21:47] <lifeless> Oli``: oh, also 'bzr inventory | wc -l'
[22:01] <Oli``> LarstiQ: both but --local seems pretty slow too
[22:01] <Oli``> sorry I had a phone call
[22:01] <Oli``> 0.844s was the real result for time bzr st
[22:02] <Oli``> bzr inventory | wc -l = 152
[22:04] <Oli``> Perhaps I'm imagining things (or expecting things to run at light-speed) but for the sake of correctness, I probably aught to split things up while I'm only dealing with 3 projects...
[22:04] <Oli``> Is it going to be more hassle than its worth trying to keep the current history? Should I just juggle things around and create three new branches?
[22:07] <Peng_> Oli``: Well, you might be able to use "bzr split" to spin off each directory into its own branch, though they'll all contain the full history up until this point.
[22:07] <Peng_> I think.
[22:08]  * jml beats combine-thread repeatedly
[22:18] <lifeless> Oli``:
[22:18] <lifeless> Oli``: 'time bzr commit -m 'unchanged' --allow-unchanged'
[22:19] <Oli``> no such option --allow-unchanged
[22:19] <Oli``> but --unchanged exists
[22:19] <Oli``> 1.1s
[22:20] <lifeless> Oli``: that is a bit slow. How did you install bzr?
[22:20] <Oli``> from the ubuntu repo.. then upgraded to the PPA version
[22:25] <lifeless> Oli``: 'python -c "import bzrlib._dirstate_helpers_c"
[22:33] <mark1> igc: woohoo - welcome back :)
[22:34] <mwhudson> revision-info should take a -d argument
[22:58] <pygi> jml, in 10 minutes?
[22:58] <jml> pygi: sure.
[23:09] <seb_kuzminsky> i'm trying to use bzr 1.10rc1 to provide read-only anonymous access to my repo
[23:09] <seb_kuzminsky> i'm starting it from inetd like this:
[23:09] <seb_kuzminsky> bzr stream tcp nowait nobody /usr/bin/bzr bzr serve --directory=/data/bzr --inet
[23:09] <lifeless> seb_kuzminsky: the easiest way is just to put the repo up on http ;)
[23:10] <seb_kuzminsky> lifeless: i had a feeling you'd say that :-)
[23:10] <lifeless> seb_kuzminsky: easier for folk beind firewalls and so on
[23:10] <seb_kuzminsky> it's an internal server
[23:10] <seb_kuzminsky> the only user will be our buildbot
[23:11] <seb_kuzminsky> all the devs access it via bzr+ssh
[23:11] <seb_kuzminsky> so the firewall is not an issue for us
[23:12] <seb_kuzminsky> when i telnet to the bzr port on the server, inetd starts bzr like i tell it to, but then the bzr server says:
[23:12] <seb_kuzminsky> No handlers could be found for logger "bzr"
[23:12] <Peng_> That's just a warning..
[23:12] <seb_kuzminsky> if i say "bzr ls bzr://server", it says:
[23:12] <seb_kuzminsky> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
[23:12] <seb_kuzminsky> Server does not understand Bazaar network protocol 2, reconnecting.  (Upgrade the server to avoid this.)
[23:12] <seb_kuzminsky> bzr: ERROR: Generic bzr smart protocol error: Server is not a Bazaar server: Received bad protocol version marker: 'No handlers could be found for logger "bzr"\n'
[23:12] <Peng_> Heh.
[23:12] <seb_kuzminsky> both client and server are 1.10rc1
[23:12] <Peng_> Oh. I guess the warning gets in teh way.
[23:13] <Peng_> bzr likes to log to ~/.bzr.log. If it's being run as some user that can't, I guess it will emit the warning.
[23:13] <seb_kuzminsky> oh i see
[23:13] <seb_kuzminsky> i'm running it as nobody
[23:13] <seb_kuzminsky> i'll try running it as me, hold on
[23:13] <Peng_> Can you set the environment variable BZR_LOG (to a writable file, or /dev/null to suppress logging)?
[23:14] <Peng_> IMO, that's a bug that the logging warning breaks the smart server..
[23:14] <seb_kuzminsky> sounds like a bug to me ;-)
[23:14] <seb_kuzminsky> if i run it as me it works fine
[23:14] <seb_kuzminsky> i'll see if i can convince inetd to do like you suggest
[23:14] <seb_kuzminsky> do you want me to open a bugreport?
[23:15] <Peng_> I think so (if there isn't already one!)
[23:15] <seb_kuzminsky> even "bzr serve -q" gives that error
[23:17] <seb_kuzminsky> Peng: i think there's no way to tell inetd to doctor the environment of the programs it runs
[23:17] <seb_kuzminsky> i could write a wrapper...
[23:18] <Peng_> Ah. I don't know what you should do, then. It would be a really trivial wrapper.
[23:18] <seb_kuzminsky> https://bugs.launchpad.net/bzr/+bug/129030
[23:19] <Peng_> Oh, nice.
[23:19] <Peng_> Less than 1.5 years old! :P
[23:20] <seb_kuzminsky> https://bugs.launchpad.net/bzr/+bug/106117
[23:23] <seb_kuzminsky> those two look related to this problem, i dont see any other bugs that seem related
[23:24] <jam> lifeless: you may be interested to know that I've been able to tweak the old Inventory deserialization to the point that fetching 1.9 => chk for mysql  seems to be spending 78% of its time in CHKInventory.create_by_apply_delta
[23:26] <jam> also, your page cache helps a *lot*
[23:26] <lifeless> jam: thats cool
[23:26] <lifeless> jam: how fast is it?
[23:26] <jam> if only apply_inventory_delta re-opens the base tree each time
[23:26] <jam> lifeless: I got to 34k revisions after 15k seconds
[23:27] <lifeless> 2/sec?
[23:27] <jam> approximately
[23:27] <jam> I just stopped it because I wanted to do an lsprof now that we are further along
[23:27] <lifeless> so, we need to make create_by_apply_delta faster :>
[23:27] <lifeless> jam: pick three reviews you need and link em here please
[23:27] <jam> I'm also seeing "52.009MB => 13.017MB"
[23:28] <jam> my update to your commit builder patch: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493C0839.10808%40arbash-meinel.com%3E
[23:28] <jam> The follow-on interdiffering serializer patch: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493C0958.9010704%40arbash-meinel.com%3E
[23:29] <jam> The rest of what I've been playing with is not in a mergeable state. But if you get those, then I have a patch which merges the new code from bzr.dev back into the chk branch.
[23:29] <jam> Which resolves some conflicts, etc.
[23:30] <jam> Since you approved the FIFO code, I can go ahead and offer a bzr.dev patch using that for XML deserialization
[23:30] <jam> that is at least worth reviewing for conceptual merit
[23:31] <jam> lifeless: Anyway... I'm thinking that flattening the trie will actually help the create_by_apply_delta a lot.
[23:31] <jam> I don't have much better answers, as the time is partially spent in "serialize"
[23:31] <lifeless> jam: k
[23:31] <jam> and I've already worked out that merge revisions are pretty much always going to get collisions
[23:32] <lifeless> jam: so, parameterised key-transforms ++
[23:32] <lifeless> I think that that is a good thing to do
[23:32] <lifeless> I think we should consider/do a C serializeer and parser very soon
[23:33] <seb_kuzminsky> Peng: works fine with the little wrapper we talked about, with BZR_LOG=/dev/null
[23:33] <Peng_> seb_kuzminsky: :)
[23:33] <seb_kuzminsky> i also added a comment to one of those bug reports, and suggested merging them
[23:34] <jam> lifeless: well, as significant amount of time is in the Index code
[23:34] <jam> 100s / 300s for converting 100 revs
[23:34] <jam> (though from scratch, so nothing is paged in already)
[23:34] <jam> (under lsprof)
[23:34] <lifeless> jam: ok, index tuning to do too then
[23:34] <lifeless> :)
[23:35] <jam> 279k calls to _KnitGraphIndex._get_entries
[23:35] <jam> which seems like a bit much versus only 100 revisions
[23:36] <lifeless> I'd add a tracer for that
[23:36] <jam> 25k calls to get_parent_map => 194k calls to _get_entries
[23:37] <lifeless> meep
[23:37] <jam> 17k calls to get_build_details => 54k calls to _get_entries
[23:37] <jam> get_entries is an iterator, so that is how many records we are *reading* not the actual number of calls
[23:38] <jam> but even 25k calls to get_parent_map is 250 calls per revision
[23:39] <jam> I suppose some of that may be the "_walk_to_common_revisions" code
[23:39] <jam> which has to go pretty far back
[23:39] <seb_kuzminsky> aaahhhhh: https://launchpad.net/bzrbuildbot  :-)
[23:39] <jam> but there *are* 16.5k calls to "add_records" which hints that we are adding 165 pages per revision
[23:40] <lifeless> jam: what project?
[23:41] <jam> mysql
[23:41] <jam> And I'm guessing 50-75% of those are collisions
[23:41] <seb_kuzminsky> hm, but they have no code or anything  :-(
[23:42] <jam> lifeless: oh and one more. http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493EF306.6000906%40arbash-meinel.com%3E
[23:42] <jam> It is a trivial update to the earlier LRUCache update
[23:46] <Gwaihir> is there a bzr 1.10 package for lpia architecture?
[23:47] <lifeless> Gwaihir: I'm not sure, it will depend if the ppa builds lpia automatically I suspect
[23:47] <jam> Gwaihir: should be
[23:47] <jam> it usually builds i386, amd64, lpia
[23:48] <lifeless> jam: all reviewed
[23:48] <jam> lifeless: thanks
[23:53] <Gwaihir> looks like the package is present, but if I add the sources.list entry it complains that it's not possible to find the lpia architecture
[23:53] <jam> lifeless: quick question... if we are walking in topological order. will a merge revision actually usually follow the right-hand parent?
[23:53] <Gwaihir> anyway... thx, found the package
[23:54] <lifeless> jam: rephrease/more detail please
[23:54] <jam> putting together a paste, just a sec
[23:55] <jam> http://paste.ubuntu.com/83214/
[23:55] <jam> If you have the simple merge graph
[23:55] <jam> and you topo_sort
[23:55] <jam> lifeless: the idea is that mysql is merging the 5.1 branch into 6.0
[23:55] <seb_kuzminsky> thanks again lifeless and Peng_, see you later
[23:56] <jam> but the InterDifferingSerializer code will see the 5.1 as the "basis" versus 6.0
[23:56] <jam> which causes us to create a delta of all of 5.1 versus 6.0
[23:56] <lifeless> jam: topo_sort has no preferennce between B and C
[23:56] <lifeless> DCBA and DBCA are both valid IIRC
[23:57] <jam> lifeless: what about: http://paste.ubuntu.com/83217/
[23:57] <jam> I'm also more concerned with the output of "tsort.topo_sort" than the definition of "topologically sorted" :)
[23:58] <jam> Anyway, my point is that C=>E and E=>G may be small changes, but B has lots of changes
[23:58] <jam> and if we use all of C, E, G as the base
[23:58] <jam> then each delta includes the changes from B
[23:58] <jam> which is why we are getting so much redundancy in the conversion
[23:59] <jam> arg..... python2.4's collections.deque doesn't have a ".remove()" attribute