[00:00] <awilkins> lifeless: CAn you BAN announcer? Pretty please?
[00:04] <announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
[00:05] <announcer> Rev 3274: (Neil Martinsen-Burrell) Explain version-info --custom in the User ian.clatworthy@canonical.com
[00:05] <lifeless> its saying channel not synced
[00:05] <lifeless> when I try to ban
[00:05]  * awilkins is not familiar enough with IRC to know what this means
[00:05] <lifeless> neither am I
[00:05] <lifeless> I am hoping someone else where will be ;)
[00:06] <elmo> lifeless: op me
[00:06] <frsk> It's because there's a netsplit going on, I think
[00:06]  * awilkins has a cunning plan.... /ignore announcer
[00:08] <lifeless> elmo: what was the issue ?
[00:08] <elmo> lifeless: no idea; it was a WAG that it'd work for me
[00:08] <elmo> I'm spethial ;-)
[00:08] <lifeless> heh. thanks
[00:09] <announcer> Rev 3273: (jam) Fix moving directories to root nodes. john@arbash
[00:10] <announcer> Rev 3274: (Neil Martinsen-Burrell) Explain version-info --custom in the User ian.clatworthy@canonical.com
[00:10] <lifeless> elmo: it would be nice if it had worked for you :)
[00:12] <mwhudson> i knew the ban syntax was funky, but that's really strange
[00:13] <jelmer> awilkins: I don't see anything there about allowing c variables as arguments to extension type constructors
[00:13] <awilkins> jelmer: The bit that caught my eye was "So you can use extension types to wrap arbitrary C data structures and provide a Python-like interface to them."
[00:14] <awilkins> I was thinking that meant you could pass a c-struct to a parameter that demanded an extension type based on that c-struct ?
[00:15] <jelmer> awilkins: probably, but I'm trying to work out how :-)
[00:15] <awilkins> What are the types?
[00:15] <jelmer> not really relevant, but svn_ra_reporter2_t, apr_pool_t, void *
[00:16] <awilkins> void *? One of the dreaded "batons"?
[00:16] <jelmer> yup
[00:16] <jelmer> that's not really relevant here though
[00:16] <jelmer> I just need to pass pointers, no need for interpretation
[00:16] <jelmer> by pyrex
[00:17] <lifeless> anyone know who is running announcer?
[00:17] <awilkins> Well, a pointer is a platform-sized integer
[00:18] <lifeless> jelmer: you can't allow C ariables directly because extension types are constructable by python
[00:18] <lifeless> jelmer: the constructor has to follow python ABI, which means getting python objects and unpacking appropriately
[00:19] <jelmer> lifeless: statik is running announcer apparently
[00:19] <awilkins> jelmer: Is this relevant? http://www.obviousobscurity.org/?page_id=13
[00:19] <jelmer> lifeless: Ah, crap
[00:19] <lifeless> statik: ping
[00:19] <awilkins> Just under "Example 1" "wherever you can pass a void * you can pass a python object"
[00:19] <lifeless> jelmer: care to give me a quick snapshot on your problem
[00:19] <jelmer> lifeless: It's possible in SWIG, it just makes the class impossible to construct from python itself
[00:20] <lifeless> jelmer: that means it has no constructor :)
[00:20] <jelmer> it has a constructor, but no python users can ever construct the arguments to call that constructor properly :-)
[00:20] <lifeless> jelmer: one way you could meaningfully do this is to have a no-args constructor, then a C initialisation interface
[00:21] <lifeless> jelmer: swig has issues though ;)
[00:21] <jelmer> lifeless: Basically, I have a pyrex function which calls out to a C function that returns 2 pointers
[00:21] <jelmer> I would like to return a Python object from my pyrex function that uses those two pointers
[00:22] <lifeless> lol searching for 'pyrex wrap' on google is not sfw
[00:23]  * awilkins isn't at work *click*
[00:23] <jelmer> :-)
[00:24] <jelmer> lifeless: yeah, pyrex owns swig big time if you only need Python bindings
[00:24] <jelmer> The next release of bzr-svn will likely no longer use python-subversion but its own pyrex code
[00:25] <lifeless> jelmer: you can define __new__ with C args I think
[00:26] <lifeless> http://ldots.org/pyrex-guide/5-python-wrapper.html#class
[00:26] <lifeless> e.g. def __new__(self, reporter, pool)
[00:27] <lifeless> oh hmm
[00:27] <lifeless> no
[00:27] <lifeless> jelmer: the easiest and cleanest way
[00:27] <jelmer> it'll complain that it's not possible to use cdef for special methods
[00:27] <lifeless> would be a trivial type wrap (e.g. an incomplete type definition)
[00:27] <jelmer> and without cdef it's not possible to have c type arguments
[00:27] <lifeless> what are the types of the two pointers
[00:28] <jelmer> one is a typedeffed struct and the other is a void pointer
[00:28] <lifeless> so
[00:28] <lifeless> ctypedef typedeffedstruct
[00:29] <lifeless> ctypedef ctypedef baton void *
[00:29] <lifeless> cdef class foo:
[00:30] <lifeless>     def __init__(self, struct, baton):
[00:30] <lifeless>         self.struct = struct
[00:30] <lifeless>         self.baton = baton
[00:30] <lifeless>     cdef typedeffedstruct struct
[00:31] <lifeless>     cdef baton baton
[00:31] <lifeless> obviously reorder but roughly that should work I think
[00:31] <jelmer> that breaks
[00:32] <lifeless> pastebin it?
[00:32] <jelmer> because it complains in the __init__ that struct is being converted from a Python object to a ctypedeffedstruct
[00:32] <lifeless> thunk it
[00:32] <lifeless> def __init__..
[00:33] <jelmer> thunk it?
[00:33] <lifeless>     cdef typedeffedstruct c_struct
[00:33] <lifeless>     self.struct = c_struct
[00:33] <lifeless> emr
[00:33] <lifeless>         c_struct = passed_in_struct
[00:34] <lifeless> totally unclear I know. 3 lines; a typed variable, assignment to that
[00:34] <lifeless> then local assignment
[00:34] <lifeless> if that doesn't work, give me a second
[00:35]  * awilkins thinks 00:21 < jelmer> lifeless: Basically, I have a pyrex function which calls out to a C function that returns 2 pointers
[00:35] <awilkins> 00:21 < jelmer> I would like to return a Python object from my pyrex function that uses those two pointers
[00:35] <awilkins> oops
[00:35] <awilkins> sorry
[00:38] <jelmer> lifeless: nope, I don't seem to be able to fool it that way either :-(
[00:38] <jml> jelmer: hi
[00:38] <jelmer> jml: Hey
[00:39] <awilkins> Did you look at http://www.obviousobscurity.org/?page_id=13 , because I thought that looked promising
[00:39] <jml> jelmer: I was looking at your subunit patches: https://bugs.edge.launchpad.net/subunit/+bug/178362 and https://bugs.edge.launchpad.net/subunit/+bug/178361
[00:39] <ubotu> Launchpad bug 178361 in subunit "[MERGE] Split by newline rather than by any whitespace character." [Low,Fix committed]
[00:39] <jml> jelmer: but I couldn't find the actual patches.
[00:41] <jelmer> I think I originally sent them to robert and later forwarded them to launchpad before it had support for attachments
[00:41] <jelmer> I'll see if I still have them somewhere
[00:43] <lifeless> jelmer: can you pastebin your experiment ?
[00:44] <awilkins> Or just post a branch of it :-)
[00:44] <lifeless> well
[00:44] <lifeless> right now, fastest to pastebin ;)
[00:45] <awilkins> I presume it's svn_ra_do_diff ?
[00:46] <jml> jelmer: anyway, if you post them on LP, I'll try to review them
[00:47] <awilkins> Poor jelmer, being pulled three ways
[00:48] <jelmer> lifeless: The branch is at http://people.samba.org/bzr/jelmer/bzr-svn/pyrex
[00:48] <lifeless> meh
[00:48] <lifeless> ok
[00:48] <jelmer> I'll see if I can trim it down to something that's easier to test and play with
[00:49] <jelmer> jml: sure, I'll have a look
[00:50] <jelmer> jml: Hmm, it's not possible yet to create a branch in launchpad yet using "bzr push lp:..." ?
[00:51] <jelmer> ah, only if I specify a homedir explicitly
[00:52] <awilkins> Yup, no squiggless
[00:52] <jml> jelmer: huh what?
[00:53] <jelmer> "bzr push lp:subunit/cparent" complains about "invalid series"
[00:53] <jelmer> but "bzr push lp:~jelmer/subunit/cparent" works ok
[00:53] <jml> oh
[00:53] <jml> what would you rather it do?
[00:54] <jelmer> Tell me new branches can only be created if I specify an explicit owner, perhaps
[00:54] <jelmer> it's a minor thing though
[00:54] <jelmer> I tend to only use launchpad for mirrorring my branches rather than hosting them
[00:55] <milian> hey is it somehow possible to ignore a file which is under version control? let me explain why I need this:
[00:55] <jml> jelmer: error messages are pretty important
[00:55] <milian> whe have a website in bzr, a forum - its in its untouched status so everybody can install it
[00:56] <milian> but the changes that occur by installing it dont neccessarily need to be submitted
[00:56] <milian> thus I'd like to ignore some of those files - is this possible?
[00:56] <lifeless> jelmer: please file a bug
[00:57] <lifeless> jelmer: also, bzr register-branch --product subunit, now uses the public location so just-works
[00:57] <jelmer> lifeless: yes, but this is really a minor thing compared to "bzr register-branch" which gives a traceback for pretty much everything
[00:58] <jelmer> (branch already registered, invalid product, authentication, ..)
[00:58] <awilkins> milian: bzr help ignore
[00:58] <lifeless> jelmer: file bugs on all of those :)
[00:58] <lifeless> jelmer: feedback -> improvements
[00:58] <lifeless> awilkins: I don't htink that will do what milian wants
[00:58] <lifeless> milian: you basically want a file which noone can edit
[00:59] <awilkins> lifeless: I'm not sure what milian wants
[00:59] <lifeless> milian: I don't see how you could edit it yourself subsequent to doing this
[00:59] <lifeless> milian: what I suggest you do, is have the file called something like 'filename.example'
[00:59] <jelmer> lifeless: I know :-) I've already filed bugs on some of them earlier
[00:59] <lifeless> milian: then folk can copy it to filename, to get an unversioned local copy
[00:59] <awilkins> milian: How about template files which you copy to "install" the thing?
[01:00] <awilkins> milian: You could even write a small script that does the copying
[01:00] <awilkins> Darn, lifeless got there first
[01:00] <milian> hmmm complicated
[01:00] <milian> but well, lets see what I can come up with
[01:00] <milian> thank you guys
[01:02] <lifeless> milian: or you could just 'bzr revert filename' after merging from someone to ignore any changes they made
[01:03] <awilkins> The template idea coupled with an ignore list for the real config files has the advantage of not requiring constant vigilance
[01:06] <milian> ah blast it - now I've accidently commited some files I dont want - how do I revert that commit without losing my changes? backing up my files and reverting?
[01:06] <milian> I haven't pushed yet - so the commit should be local
[01:07] <milian> or is bzr revert --forget-merges what I want?
[01:07] <lifeless> bzr uncommit
[01:07] <awilkins> bzr uncommit
[01:07] <milian> oh darn - so simple :D great
[01:07] <milian> thank you again
[01:08] <poolie> hello again
[01:09] <lifeless> poolie: hi
[01:09] <lifeless> poolie: did you see leslies 'register now urgent urgent' mail ?
[01:10] <lifeless> just checking my gmail now so just saw it
[01:13] <lifeless> statik: ping, announcer banned, it wouldn't shutup
[01:17] <poolie> lifeless: not yet, will look
[01:17] <poolie> lifeless: i just saw that hardy went into beta freeze
[01:17] <poolie> i would really like to get the baz rename done before it's too late
[01:17] <poolie> was it beuno looking after it?
[01:18] <lifeless> yes, was getting the patch up
[01:18] <lifeless> some serious headache though
[01:18] <lifeless> baz fails to build
[01:18] <lifeless> api changes in libneon
[01:18] <lifeless> poolie: oh, so unless you applied for bzr to be an organisation, we've missed soc.
[01:18] <lifeless> I didn't put us in.
[01:19] <poolie> i have not
[01:19] <lifeless> right, that makes deciding on soc projects easy
[01:19] <poolie> right
[01:19] <poolie> tbh i don't think it gives a good return on the amount of time it requires, compared to helping people in the project directly
[01:20] <poolie> we can sponsor people directly if they'd like to do similar things
[01:20] <lifeless> I don't htink there is much soc specific overhead myself
[01:20] <beuno> poolie, baz doesn't build in either lenny or feisty >
[01:20] <lifeless> the questionaires etc are pretty quick to do
[01:20] <beuno> so the work is done for the transition
[01:20] <beuno> but since we can't get it to build, we can't upload
[01:22] <poolie> beuno: so the old binary can stay in the archive? how is that allowed?
[01:23] <poolie> lifeless: there's time in applying, dealing with student applications, reporting to them
[01:23] <poolie> it's non-trivial
[01:23] <beuno> poolie, it won't in Debian, and, in Ubuntu, it's been passed on in binary. I have _no_ idea how/why
[01:23] <jelmer> jml: Still there?
[01:24] <jml> jelmer: always
[01:24] <beuno> it will get removed from Debian if it's not fixed, as it's a release critical bug
[01:24] <jelmer> jml: The changes for those bugs are in the branches I just registed on launchpad
[01:24] <jml> jelmer: ok.
[01:24] <jelmer> jml: My trunk branch contains the SubunitTestRunner change
[01:24] <jelmer> and the "jelmer" branch contains a bunch of other changes
[01:24] <lifeless> poolie: there is, I'm comparing that time to the time to get contributions directly; we still have to decide whats good, work with folk contributing code, assess how they are going if we are doing a bounty
[01:24] <lifeless> poolie: I don't think the /incremental/ overhead is significant
[01:25] <lifeless> poolie: anyhow, its all moot
[01:25] <poolie> it is moot
[01:25] <poolie> approximately zero of the students last year committed long-term improvements
[01:26] <poolie> that doesn't mean there's no prospect of doing better
[01:27] <poolie> the main advantage i think is if it brings people in who would not previously have thought of working on it, and who do actually get right into it
[01:27] <poolie> the potential is there...
[01:28] <jelmer> phanatic got into bazaar through the SoC
[01:28] <jelmer> Samba got one committer because of the SoC
[01:29] <jelmer> I know wine has similar results
[01:29] <jelmer> all 1 in 6 students actually staying around
[01:29] <lifeless> poolie: I think we should do bounties for the folk that were interested from the sprint
[01:29] <lifeless> poolie: if we can get funding for that
[01:30] <poolie> that's true
[01:30] <poolie> we can
[01:30] <beuno> poolie, and you already have the topics to choose from organized in: http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms   :)
[01:30] <poolie> so we can fund jelmer, phanatik, guillermo,
[01:33] <lifeless> cool
[01:35] <beuno> so, poolie, lifeless, what do you want to do about baz?
[01:36] <poolie> excuse my ignorance, but if it ftbfs how can it go into a new distribution release?
[01:36] <beuno> well, I don't know how Ubuntu is doing it. They seem to just pass on the binary
[01:36] <poolie> beuno: you're still in london?+
[01:37] <beuno> Debian will remove it before relase
[01:37] <beuno> poolie, no, Madrid. My flight was cheaper if I returned the 20th, so I'm waiting here until then
[01:37] <poolie> beuno: i want to not have hardy release with 'install bazaar' not giving you baz
[01:37] <poolie> i mean, bzr
[01:38] <beuno> poolie, even at the expense of removing baz?
[01:38] <beuno> neither me or james_w could get it to build in debian or ubuntu, so we can't upload the changed binary name for transitioning
[01:41] <jelmer> is there any reasoning as to what options are retrieved using their own function on BranchConfig or using get_user_option() ?
[01:41] <lifeless> http://weblog.latte.ca/blake/tech/bzr/Looms - nice :)
[01:42] <lifeless> jelmer: get_user_option has a basic lookup
[01:42] <lifeless> jelmer: custom methods are used for things that don't fit into that
[01:42] <james_w> lifeless: nice.
[01:43] <james_w> lifeless: also http://thread.gmane.org/gmane.comp.package-management.vcs-pkg/11
[01:44] <jelmer> lifeless: thanks
[01:44] <lifeless> james_w: great post'
[01:44] <lifeless> james_w: now how about a patch to make merge actually merge the looms :)
[01:45] <james_w> lifeless: erm, yeah...
[01:45] <james_w> I might do some looms tomorrow.
[01:46] <james_w> I've got my own little bzr sprint going on.
[01:46] <james_w> Going to work is for people who never want to get anything done :)
[01:49] <lifeless> james_w: :>
[01:50]  * beuno points to http://blog.orebokech.com/2008/03/emacs-in-bzr-initial-impressions.html
[01:58] <poolie> hello yacc
[02:00] <yacc> poolie: hi.
[02:10] <poolie> beuno: so it really looks like log in the main problem atm; mwh has a patch to speed it up for very long history
[02:10] <mwhudson> (when he's not busy killing x)
[02:11] <beuno> poolie, ah, cool. We should really make an effort to make sure "bzr is painfully slow" doesn't get stuck in people's heads
[02:15] <poolie> indeed
[02:17] <poolie> jml: could you followup about that, if you haven't done so already?
[02:17]  * beuno is off to bed
[02:21] <james_w> anyone know how to stop vim from forcing you to the first column when you type # to start a comment?
[02:22] <poolie> james_w: hm, yes, somehow
[02:22] <jelmer> poolie/lifeless: Any chance one of you could set "child_submit_to = bazaar@lists.canonical.com" in bzr.dev's .bzr/branch/branch.conf ?
[02:22]  * poolie looks
[02:22] <poolie> jelmer: i think only lifeless can write there
[02:24] <poolie> james_w: i remember hitting that myself
[02:24] <poolie> maybe 'filetype indent on' ?
[02:25] <piedoggie> I screwed up a merge.  commit from one machine is the mainline is at rev 40.  changes from second are recorded as rev 38.1.1.  how do I merge rev 40 and 38.1.1 into a new revsion?
[02:25] <poolie> or set nosmartindent nocindent, probably in an autocmd for python files
[02:26] <poolie> piedoggie: are those numbers from the same branch?
[02:26] <piedoggie> y
[02:26] <poolie> hm
[02:26] <poolie> actually, can you explain more? it sounds like you've already merged them
[02:26] <poolie> you don't like the way you merged it?
[02:27] <piedoggie> all the changes (38.1.1)  have not made it to head.
[02:27] <poolie> because they conflicted and you rejected them?
[02:27] <piedoggie> it is like I created a branch
[02:28] <piedoggie> the changes should have been in conflict but I never got the merge message
[02:28] <james_w> poolie: it seems like :set cindent might be it.
[02:28] <poolie> rather nocin
[02:28] <piedoggie> er.. conflict message
[02:29] <poolie> piedoggie:
[02:29] <lifeless> poolie: hmm, permissions
[02:29] <poolie> possibly easiest is to do 'merge -c 38.1.1', which will redo all those changes, then you can pick what you want
[02:29] <poolie> lifeless: ?
[02:29] <poolie> on that branch
[02:29] <piedoggie> k let me try that
[02:30] <piedoggie> -c not -r?
[02:30] <poolie> yes
[02:30] <lifeless> poolie: rsync/bzr/bzr.dev$ chmod g+w .bzr/branch/*
[02:30] <lifeless> poolie: you should be able to edit
[02:30] <lifeless> poolie: sorry about wrong permissions
[02:30] <poolie> if the changes you want are not in that particular revision, but rather something it merged, then you might need to pick out the particular one and use -c on that
[02:30] <james_w> poolie: thanks for the pointers.
[02:31] <poolie> you're welcome
[02:31] <lifeless> *yawn*
[02:31] <lifeless> 5am is the wrong time to wake
[02:31] <piedoggie> how can I show all the diffs?  diff -c 38.1.1??
[02:32] <poolie> yes
[02:33] <lifeless> bbiab
[02:33] <piedoggie> this may not be a good thing :-) but bzr works in a way that feels natural to my mind
[02:33] <poolie> :)
[02:44]  * yacc wonders if bzr is not a better client for svn repos than svn even now, ...
[02:45]  * RAOF has found it to be so.
[02:46] <RAOF> But that's because I don't use svn properly (ie: I try to do branch-merge, which is almost exactly half supported by svn :P)
[03:54] <Potato-[CE]> i have a question: can i use bzr for multiple projects which are in multiple directories (not all under one obvious parent directory)?
[03:55] <gotgenes> Potato-[CE]: Sure, you could but you have to examine whether there's advantage in keeping each project under the same repository.
[03:56] <gotgenes> As long as you house all projects within some central directory, though, then yes, you can keep all of them in a single repository.
[03:57] <Potato-[CE]> well, i think i need to start over with my directory layout. I have one project just started, i don't mind erasing the data...what's the best way to change the repository directory?
[03:58] <Potato-[CE]> just delete .bzr?
[04:00] <gotgenes> Potato-[CE]: That would do it.
[04:02] <Potato-[CE]> okay, i see that here too "If you accidently put the wrong tree under version control, simply delete the .bzr directory."
[04:02] <Potato-[CE]> thanks for the information, i appreciate it. :-)
[04:11] <NfNitLoop> So I'm trying to check out a svn repo with bzr-svn, and I can't tell if it's in a loop or not.
[04:11] <NfNitLoop> I've got the message:
[04:11] <NfNitLoop> using experimental bzr-svn mappings; output may change between revisions
[04:12] <jml> So, I think I've mentioned this before, but did you know that the ssh process started by Bazaar hangs around doing things if the Bazaar process is SIGINTed?
[04:12] <NfNitLoop> and a progress bar keeps filling up.
[04:13] <NfNitLoop> oops, nevermind, there it goes.
[04:13] <NfNitLoop> I guess it just had tons of branches to check out.
[04:13] <NfNitLoop> *heart* bzr-svn.
[05:03] <jml> jam; ping
[05:30] <ubotu> New bug: #202063 in bzr-gtk "gannotate display of uncommitted lines is unobvious" [Undecided,New] https://launchpad.net/bugs/202063
[05:49] <jml> does Bazaar use Twisted Conch as its ssh client in Windows?
[06:41] <lifeless> jml: not as far as I Know
[06:43] <jml> lifeless: it's just that there's some things that say "Twisted" on the Bazaar / Launchpad showmedo video
[06:50] <lifeless> interesting
[07:06] <poolie> lifeless: hi, want a brief call?
[08:07] <Peng> ubotu: ping?
[08:07] <ubotu> Sorry, I don't know anything about ping? - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[08:07] <Peng> Well, that's a good enough response.
[08:20] <ubotu> New bug: #202079 in trac-bzr ""Invalid url supplied to transport" in sub directories" [Undecided,New] https://launchpad.net/bugs/202079
[08:31] <RAOF> I've got some strange behaviour with Hardy's bzr:  I'm branching Do (with lp:do, so bzr+ssh), and when I do this into a directory which *isn't* a shared repository, "bzr info" in the branch directory gives Standalone tree (format: dirstate).
[08:32] <RAOF> When I branch it into a directory under a default-format (pack-0.92) repository, and then run bzr info in the branch directory I get: Repository tree (format: unnamed)
[08:33] <Peng_> Yeah.
[08:33] <Peng_> The name like "pack-0.92" refers to the repository type, branch type, and working tree type.
[08:33] <RAOF> When I branch it into a repository with rich-root format, the branch errors out with: http://www.paste2.org/p/15882
[08:34] <Peng_> When you branch it into the repo, it's using pack-0.92's repo type but dirstate's branch type, so bzr doesn't know what to call it.
[08:34] <RAOF> Right.  So that should probably be handled by printing both repo & branch type.
[08:34] <Peng_> Indeed.
[08:35] <Peng_> info -v will show all of them.
[08:35] <RAOF> Ah, right.
[08:36] <RAOF> Is there already a bug for this?
[08:37] <Peng_> Shrug.
[08:37] <Peng_> Wait, a bug about what?
[08:38] <Peng_> That information or the error you pasted?
[08:38] <RAOF> That information.
[08:38] <Peng_> Oh.
[08:38] <Peng_> Shrug.
[08:38] <RAOF> Heh.  It's a small problem, but it'd be nice if it displayed both :)
[08:38] <RAOF> Any ideas about the error?+
[08:39] <RAOF> Eh
[08:39] <Peng> I dunno.
[08:39] <RAOF> Heh
[08:39] <Peng> But, rich-roots and non-rich-roots don't really go together.
[08:39] <Peng> Huh.
[08:39] <Peng> I'm surprised you didn't get a compatibility error. Maybe bzr's smarter than that.
[08:47] <awilkins> jml: plink appears to be the best choice for bzr+ssh:// on windows
[08:47] <Peng> What's wrong with paramiko?
[08:47] <awilkins> Had a chap in here a couple of days ago that couldn't get it to work, but plink worked fine for him
[08:48] <awilkins> I suppose I could upload a key to LP and try both
[08:48] <Peng> What problem was he having?
[08:48] <Peng> Password prompt?
[08:48] <awilkins> I thin it was dropping the stream in the middle of establishment
[08:49] <awilkins> He was using an agent
[08:51]  * awilkins uploads a key
[08:51] <Peng> Oh, huh.
[08:54] <awilkins> DId you buy your network card from the same guy that sold jelmer his :-)
[08:55] <Peng_> Hahaha.
[08:55] <Peng_> Actually, the Ethernet port on my 2-year-old motherboard failed, so I'm using my 5-year-old NIC...
[08:55] <Peng_> But I'm tinkering with a new IRC client.
[08:56] <awilkins> I'm quite happy with irssi running on my router atm.
[08:56] <Peng_> Goodbye Konversation.
[08:56] <fullermd> I'm due for another bout of screwing with irssi to try and resolve annoyances...
[08:57] <Peng_> Heh.
[08:57] <Peng_> I've used irssi a little, but I'll stick with my GUI clients..
[08:57] <fullermd> The part where it (sometimes) eats part of wrapped lines is especially bothersome.
[08:58] <awilkins> Running irssi on the router has the advantage that my office IT services can't block it.
[08:58] <asabil> Peng_: weechat
[08:58] <fullermd> The big problem with GUI clients is that they don't work well inside screen   :p
[08:58] <Peng_> asabil: ?
[08:58] <asabil> weechat is a quite nice client
[08:58] <Peng_> Ah.
[08:59] <Peng> Oh, non-GUI.
[08:59] <asabil> still very usable
[08:59] <Peng_> Connection reset by peer? What the hell? I hit the quit button!
[08:59] <awilkins> Well that's a pile of crap then
[09:01] <ubotu> New bug: #202083 in bzr "bzr info confusing when branch format does not match repository format" [Undecided,New] https://launchpad.net/bugs/202083
[09:43] <awilkins> So once you upload an SSH key to launchpad, is there a way to test it's working without creating branches?
[09:44] <Peng> If you have to create one, there's staging and junk.
[09:44] <awilkins> Meh?
[09:45] <Peng> Branches pushed to lp://staging/ or something are deleted daily. You can also register random branches to the +junk project.
[09:45] <awilkins> Aha
[09:45] <Peng> Wait, if you're using bzr+ssh, any operation would require a password or SSH key.. You could just "bzr info" something.
[09:46] <awilkins> Mmkay
[09:46] <awilkins> So, just replace the http with bzr+ssh ?
[09:46] <Peng> Yeah.
[09:46] <Peng> And add your username
[09:47] <Peng> After running bzr launchpad-login, lp: URLs will automatically use bzr+ssh too.
[09:48] <awilkins> so my username would be adrian-wilkins (that's what it says in my key edit window after the "~")
[09:52] <awilkins> Ooh, doesn't work well from powershell
[09:53] <awilkins> Ok, does the same thing from cmd.exe tooo
[09:53] <awilkins> THe SSH stuff works with plink though.. now for paramiko
[09:55] <awilkins> bzr: ERROR: Unrecognised value for BZR_SSH environment variable: paramiko
[10:06] <awilkins> Dumb-ass question : do you need to install pycrypto and paramiko for python 2.5 on windows?
[10:06]  * awilkins is finding it hard to locate a pycrypto binary for py2.5 on win32
[10:06] <Peng> They're both still necessary with 2.5, but they're likely provided with the bzr installer.
[10:07] <awilkins> THe standalone one or the python one?
[10:07]  * awilkins is using the python one
[10:07] <awilkins> Aha
[10:08]  * awilkins intalls the damn dependencies
[10:08] <Peng> http://bazaar-vcs.org/BzrWin32Installer#bzr-dependencies ?
[10:08] <awilkins> Yeees
[10:08] <Peng> That might not be the Python-based installer.
[10:08] <Peng> I have no idea how it all works.
[10:08] <awilkins> I've always used putty/plink
[10:09] <awilkins> THe Python flavoured one has none of the extra deps in it
[10:09] <Peng> Ah.
[10:12] <awilkins> Paramiko seems to work better than plink
[10:13] <awilkins> Plink gives you this "unable to read from standard input" error after it finishes
[10:14] <awilkins> It's happy enough using Pageant for keys though (puttys ssh-agent)
[10:14] <awilkins> Yay
[10:42] <fullermd> Man, progress bars have gotten unprogressive with packs   :|
[10:53] <awilkins> I always just _love_ seeing progress bars that clearly have no idea of how long things take :-|
[10:53] <LeoNerd> Even better are the ones that go backwards
[10:53] <awilkins> I'd much rather see a spinner, or an "estimate bar"
[10:53] <awilkins> Maybe make the progress bar out of "?" instead of "="
[10:53] <awilkins> Or "~"
[10:53] <awilkins> "Approximate progress bar"
[10:57] <fullermd> Don't even much see the spinner spinning; it spends so much time blocking in downloads that it's halfway done before it starts spinning.
[11:32] <Odd_Bloke> Morning.
[11:32] <Odd_Bloke> (And it actually is!)
[12:24] <awilkins> Odd_Bloke: Afternoon
[13:09] <awilkins> Gah, MinGW can't find files on other drives.... nice one, that should be at the top of the sodding install page for it
[13:09] <awilkins> "Oh by the way, windows path support is fundamentally broken in"
[13:10]  * awilkins rubs sore patch from beating head on wall
[13:14] <luris> If you've uncommited and reverted, are the changes lost, or is there a trick to it?
[13:14] <luris> :)
[13:15] <awilkins> luris: revert will backup changes to ~1~ files
[13:15] <Peng> luris: Also, the revision is still in the repo. You can find it if you wrote down the revid or with the "bzr heads" plugin.
[13:15]  * awilkins didn't know that
[13:16] <Peng> Not sure how you'd get it back into the branch though.. Maybe pull would do it?
[13:17] <fullermd> It will.
[13:17] <luris> Peng: pull like how?
[13:17] <fullermd> pull -rwhatever .
[13:17] <luris> bzr pull -r 1423?
[13:17] <awilkins> bzr pull . -r revid:mytrashedrevid  ?
[13:18] <luris> thanks :)
[13:50] <statik> lifeless: sorry about that
[13:52] <statik> everyone, sorry about the announcer malfunction yesterday
[13:52] <statik> won't happen again
[13:53] <fullermd> "Those responsible have been sacked."
[13:53] <Peng> Announcer malfunction?
[13:54] <fullermd> It wasn't a _malfunction_ per se...   it was just sorta "enthusiastic"...
[13:55] <xif> does bzr have anything similar to SVN:externals?
[13:55] <lamont> so... if I have a branch, and I want to make it an orphan (by forgetting all about it's parent), is it sufficient to just thwack .bzr/branch/branch.conf?
[13:57] <fullermd> lamont: I guess so...   depends on what you're trying to accomplish by "orphaning" it.
[13:57] <Peng> lamont: branch.conf includes the push location and other things too. I'd say edit it, don't just blindly delete it.
[13:57] <lamont> fullermd: I'm trying to make the branch of the cvsps-import-created bzr tree forget that it had a former life as a cvs tree.
[13:58] <lamont> Only in .bzr: checkout
[13:58] <lamont> Only in .bzr: repository
[13:58] <lamont> is the only diff other than the parent_location in branch.conf
[13:58] <fullermd> Oh, you're out of luck on that.  Once you've been in CVS, you NEVER forget.
[13:59] <lamont> ROTFL
[13:59] <fullermd> It's like Vietnam for source code.
[13:59] <lamont> Peng: this the new root-of-all-branches for the item in question
[13:59] <lamont> fullermd: and RCS is what?  WW I?
[14:00] <fullermd> I was thinking "Battle of Carthage".
[14:00] <lamont> or the Korean Conflict, since that wasn't even worthy to be called a war
[14:03] <lamont> so for the stupid question of the day (just to make sure I'm not a total idiot)... if I have a branch that I created with bzr branch $SOURCE, I bring it current with 'bzr up'?
[14:03] <lamont> as in bzr preserves that bit of cvs insanity?
[14:04] <Peng> lamont: Use "bzr pull". up is for checkouts.
[14:04] <Peng> lamont: (pull automatically updates the working tree too.)
[14:05] <lamont> ah.  which means I really want that to be a checkout - it's not a branch
[14:07] <Peng> Meh.
[14:07] <Peng> I always use branches even when I could really just use a checkout.
[14:07] <Peng> That way I don't have to learn how checkouts work.
[14:07] <lamont> (this is the "gimme a copy of _that_ branch so I can work on it locally and compile it" automatic processing thing)
[14:08] <lamont> where "work on it locally" == "compile it"
[14:12] <james_w> lamont: a lightweight checkout may be sufficient for you then, if all you want is the working tree.
[14:14] <lamont> james_w: that is all I want.
[14:14] <lamont> so yeah.
[14:14] <lamont> thanks
[14:33] <fullermd> Yeah, y'know, I was just thinking, "Gee, it's neat that some project is trying out bzr.  We should totally take that opportunity to rererehash a bunch of bzr-vs-git emails."
[14:37] <Odd_Bloke> james_w: GJ on the Emacs thread BTW. :)
[14:38] <james_w> Odd_Bloke: thanks.
[14:38] <james_w> fullermd: me too. :)
[15:05] <awilkins> Oh *spit*
[15:06] <awilkins> Anyone know how to get "ld" to look in other folders on MinGW ?
[15:06] <awilkins> (anyone who says "Add -L arguments" will be shot)
[15:07] <LeoNerd> Is -R in that category also?
[15:07] <fullermd> Hack the code?   :>
[15:07] <awilkins> I'm trying to build things in Pyre
[15:07] <awilkins> x
[15:15] <awilkins> Nnnnnyuurg, this is horrible
[15:35] <Odd_Bloke> Is there a test convenience function to create a branch that uses a shared repository if it finds one?  make_branch creates its own repo.
[15:42] <chadmiller> Hi abentley.  I submitted a patch to the list under the wrong address, and then followed it with the same thing from the correct address.  The correct address' patch got one level of approval.  Then the list moderator approved the second posting, which 1) clobbered the prev status and 2) has the wrong address on it.  Can you roll the latest one back, or should I spam the list again?
[15:43] <abentley> I think I can fix it.
[15:43] <chadmiller> 'Kay.
[15:47] <abentley> chadmiller: don
[15:47] <abentley> done
[15:47] <chadmiller> Thank you, sir.
[15:47] <abentley> You're welcome.
[15:50]  * awilkins is suffering PAIN
[15:51] <awilkins> Getting the build kit for Python is a real pain unless you have an MSDN sub
[15:55] <james_w> heh, I like the way gmane doesn't have emacs.devel under gmane.comp.editors, it's just gmane.emacs.devel
[15:56] <awilkins> The group was probably founded before there were any other editors except vi
[15:57] <awilkins> Or poking-the-motherboard-with-a-paperclip-wired-to-ground
[15:57] <fullermd> I'm pretty sure emacs pre-dates vi...
[15:57] <fullermd> (dunno if GNU-emacs does, but...)
[15:57] <awilkins> emacs is clearly OUTMODED compared to vi :-P
[15:58]  * awilkins raises shields
[15:58] <fullermd> Well, vi is certainly enmoded, so...
[16:40] <blueyed> Is there a shortcut to "bzr diff -r ancestor:FULLURL" (leaving FULLURL out and using the parent branch instead)?
[17:23] <awilkins> blueyed: Since your branch contains all the revisions from the parnet branch, just determine the tip revision of the parent branch and diff against that
[17:24] <awilkins> blueyed: Of course, to get the revno of the parent branch you need it's url :-(
[17:25] <fullermd> ancestor: doesn't use the tip, it uses the ancestor...
[17:26] <james_w> blueyed: does -r ancestor:submit: do it?
[17:28] <blueyed> james_w: -r submit:..ancestor: does it. Thanks. didn't know about "submit:" yet.
[17:29] <james_w> blueyed: I think it's quite new.
[17:29] <james_w> blueyed: I don't really understand it yet, but it was worth a shot.
[17:29] <blueyed> james_w: at least for my use case "-r submit:" is enough even.
[17:30]  * awilkins requires tea
[17:35] <ubotu> New bug: #202222 in bzr-loom "up-thread interacts poorly with remerge" [Undecided,New] https://launchpad.net/bugs/202222
[18:39] <mxpxpod> is bzr-svn able to get subversion tags?
[18:39] <jelmer> mxpxpod: it can fetch subversion tags as branches in bzr; it won't set bzr tags yet
[18:39] <LeoNerd> There's no "easy" way to tell a subversion tag as a tag
[18:40] <LeoNerd> In bzr, a tag is really a tag... it's a symbolic name for "just some point in history"...
[18:40] <LeoNerd> (same as CVS)
[18:40] <mxpxpod> I'm trying to check out openwrt's kamikaze 7.09 and I'm getting this:
[18:40] <LeoNerd> Whereas svn doesn't really have such a concept. All it has is a cheap copy, that happens to live in a directory called "tags"
[18:40] <mxpxpod> bzr branch https://svn.openwrt.org/openwrt/tags/kamikaze_7.09/ openwrt
[18:40] <mxpxpod> bzr: ERROR: Not a branch: "https://svn.openwrt.org/openwrt/tags/kamikaze_7.09/".
[18:42] <jelmer> mxpxpod: Do you have a subversion library that has been built with https support?
[18:42] <jelmer> mxpxpod: Try "svn ls https://svn.openwrt.org/openwrt/tags/kamikaze_7.09"
[18:42] <mxpxpod> jelmer: works fine
[18:43] <mxpxpod> ah, I see
[18:43] <mxpxpod> once I did that and accepted the certificate permanently, I'm able to branch
[18:45] <Odd_Bloke> Could someone reject http://bundlebuggy.aaronbentley.com/request/%3C20080226155240.1f2f0145@lapbert.oxbridgetech%3E for me?  It's been superseded, but by a divergent branch.
[18:47] <beuno> james_w, your post about bzr revno's rocks!  I suspect it's going to be widely pointed at  :)
[18:49] <trondn_> hi... I am probably doing something seriously wrong.. I downloaded and installed the development tree of bazaar on my test system, and tried just a simple command such as bzr log -v on the source tree.. it used 13 _minutes_ to complete and used 94% of the cpu.. This is on Solaris with python 2.5... any ideas what I should do differently?
[18:49] <asabil> jelmer: is there a way to handle google code svn with bzr-svn and launchpad ?
[18:50] <jelmer> asabil: Not sure what you mean - it is certainly possible to pull code fomr google code svn and upload it to launchpad
[18:50] <Peng> trondn_: Does your repo perhaps include the entire history of the universe?
[18:50] <asabil> jelmer: last time I tried It was broken, and launchpad fails to import google code sometimes
[18:51] <Peng> trondn_: You should install Pyrex and run "make". Bzr has some optional C bits to speed things up.
[18:52] <trondn_> Peng: I used the command listed on the "installation" web-page to branch the repository...
[18:52] <trondn_> Peng: I will try :)
[18:52] <jelmer> asabil: bzr-svn and launchpad imports are a completely different thing
[18:53] <asabil> yes I know, anyway I will wait for a new bzr-svn to test (one that is 1.2 compatible)
[18:55] <jelmer> asabil: what exactly was broken then ?
[18:56] <asabil> not able to find some special/inexistant files/properties containing a !
[18:56] <asabil> I am not really sure about the exact problem
[18:57] <asabil> I am unable to use bzr-svn (using bzr 1.2), but basically http://waf.googlecode.com/svn/trunk/ fails
[18:57] <asabil> last time I tried
[18:59] <james_w> beuno: thanks :)
[19:00] <james_w> trondn_: that is far too long. I've not heard of anyone running on solaris before, maybe there is something that bzr is doing wrong on that platform.
[19:01] <trondn_> james_w: i don't think there is anything wrong with the python-intepreter, because I did a quick test with mercurial, and that used just 2 secs to dump the history.. I will install the pyrex-library as suggested and retry the operation :)
[19:05] <asabil> trondn_: truss  -a  -e  -f  -rall  -wall bzr log ?
[19:05] <fullermd> Well, it's "too long", but I dunno if it's really unexpectedly long...
[19:05] <asabil> (never used solaris, but truss seems to be the equivalent of strace)
[19:06] <asabil> because 13 minutes is really very long
[19:07] <Peng> Huh. I just got 14 seconds on Linux. I didn't expect it would be that fast.
[19:07] <trondn_> asabil: it is using 98% CPU and all in user-space....
[19:07] <fullermd> Yes, but log -v is slower than a dead snail tied to a 3 meter cube of depleted uranium.
[19:07] <fullermd> I'm over 6 minutes of CPU time on running it here so far.
[19:07]  * Peng wanders off.
[19:07] <Peng> Wait, that's right.
[19:07] <Peng> I can't read time.
[19:07] <Peng> 14 *minutes*.
[19:07] <Peng> So Slowlaris is faster!
[19:07] <asabil> lol
[19:08]  * Peng wanders off.
[19:08] <asabil> fullermd: running it on the bzr sources itself ?
[19:09] <fullermd> Yeah.
[19:09] <fullermd> Over 8 minutes now...
[19:09] <asabil> :/ maybe bzr log really needs some love
[19:09] <fullermd> Well, yeah.  log -v and log $FILE have needed love since, like, ever.
[19:10] <james_w> ah, I missed the -v
[19:10] <trondn_> but why on earth is it so slow?
[19:11] <fullermd> log isn't bad.  But as soon as it gets within whiffing distance of the inventory, it might as well be running on an 8086.
[19:13] <trondn_> so there is nothing I can do to make it faster?
[19:13] <trondn_> (without hacking the source...)
[19:13] <fullermd> Heck, that's half the base complaint in the emacs thread; log $FILE.  That's not "slow with packs", that's always been *SLOW*.
[19:13] <fullermd> Crud.  I'm over 12 minutes.  Hurry up and finish!  My ego couldn't take being behind Solaris...   :(
[19:14] <fullermd> Well, either "hack the source", or "don't use log -v".
[19:15] <beuno> fullermd, just pop in 3 more CPUs, and 4 gigs of ram
[19:15] <beuno> that should put solaris in it's place
[19:15] <LarstiQ> heh
[19:15] <beuno> maybe a 15.000 rpm disk
[19:15]  * LarstiQ is actually get a Sun machine RSN
[19:15] <beuno> but that maybe abuse
[19:15] <fullermd> Well, I certainly needs new disks.  And they will be 15k'ers.  But that's a few months off.
[19:15] <trondn_> beuno: I also got a T5220 with 32 cores and 32GB ram I could try ;)
[19:15] <Odd_Bloke> Because bzrlib and CPython are clearly able to use several cores. ;)
[19:16] <beuno> trondn_, ah crap. Canonical will have to put sown some hard cash to beat that  :p
[19:16] <beuno> we should finally open a bug for "bzr is too slow, send ram and CPUs to users on request"
[19:16] <Odd_Bloke> +
[19:16] <Odd_Bloke> Ack, +1
[19:17] <Peng> Sign me up!
[19:17]  * LarstiQ sends Peng a spare 6510
[19:18] <Peng> Back in my day, a 2-core, 2 GHz CPU with 2 GB of RAM was good...
[19:18] <fullermd> New drives will probably speed bzr up more on common ops for me than CPU upgrade...
[19:18] <Peng> Well, the CPU is nice, but I keep chewing all my RAM with Firefox and whatnot.
[19:18] <fullermd> My drives have done real nice by me, but they're getting a little long in the tooth.
[19:19] <trondn_> fullermd: so what was the result of your command?
[19:19] <fullermd> Dunno.  It's over 18 minutes now.
[19:19] <trondn_> :O
[19:20] <fullermd> Sad.  It took less than 9 to branch the whole history down across the network, more than twice that (and still running) to look at the logs.
[19:20] <LarstiQ> fullermd: what branch would that be?
[19:20] <fullermd> bzr.dev
[19:20] <beuno> I suppose some noise should be made in bug 172975
[19:20] <ubotu> Launchpad bug 172975 in bzr "bzr log slower with packs" [Medium,Triaged] https://launchpad.net/bugs/172975
[19:21] <fullermd> I doubt that bug has much relation to this issue.
[19:22] <trondn_> there must be something seriously wrong with the algorithm, because 98% of the time is spent in the userspace, and when I try to use truss to look at the the process it use extremely few system calls.....
[19:22] <beuno> than a new one should be opened
[19:22] <trondn_> (none in 30 secs..)
[19:22] <fullermd> What's wrong with it is "building inventories is motherfarking expensive".
[19:23] <beuno> fullermd, sounds like a good bug title
[19:24] <AfC> I like it
[19:25] <LarstiQ> on a plane?
[19:26] <fullermd> Well, there's nothing particularly newsworthy about it.  It's been a known issue since...  I dunno.  0.6.2 at least.
[19:28] <scode> What is the intended method of applying a merge directive with a minimum of fuss?
[19:29] <scode> (one generated with bzr send)
[19:29] <fullermd> Ah!  It finished.
[19:29] <fullermd> scode: `bzr merge $FILE`
[19:29] <fullermd> % time dbzr log -v >> /dev/null
[19:29] <fullermd> 1592.597u 4.563s 27:09.30 98.0% 106+137k 912+0io 0pf+0w
[19:29] <scode> fullermd: Thanks!
[19:30] <fullermd> Less than a half hour at least.
[19:30] <scode> Am I blind or should I submit a patch to have this documented? I don't see it mentioned in the merge cmd help, nor mentioned in the send help.
[19:30] <LarstiQ> $HOME/bin/bzr log > alog  16.79s user 1.14s system 69% cpu 25.974 total
[19:31] <Peng> 13 minutes 43 seconds! My computer rox!
[19:31] <LarstiQ> fullermd: and mine is a puny laptop
[19:31] <fullermd> I thought it was mentioned in an article in the main docs somewhere, but I'm not sure.  IF it's not, it certainly should be.
[19:31] <fullermd> LarstiQ: Now try it with -v   :P
[19:31] <Peng> LarstiQ: Not only log, but log -v.
[19:31] <LarstiQ> oh oh :)
[19:32] <Odd_Bloke> real	11m55.461s
[19:32]  * LarstiQ started it and goes out for a bit
[19:32] <fullermd> % time dbzr log >> /dev/null
[19:32] <fullermd> 18.459u 0.321s 0:19.03 98.6%    103+133k 0+0io 0pf+0w
[19:32] <Peng> Odd_Bloke: Damn.
[19:32] <fullermd> And it didn't even break 130 meg of core that time.
[19:32] <Odd_Bloke> Mine's a laptop too. :)
[19:32] <Odd_Bloke> Anyhow, party tiem! :)
[19:32] <Peng> Odd_Bloke: Running log isn't a party?!
[19:32] <spiv> Heh, I'm in a talk  at PyCon that mentions bloom filters.
[19:33] <fullermd> log -v is more like the hangover...
[19:33] <trondn_> well, I started a bzr log -v on a pretty big repository earlier today, and guess for how long its been running ;)
[19:33] <trondn_> 8:21:00 ;)
[19:33] <trondn_> and still not done ;)
[19:35] <LarstiQ> spiv: hihi
[19:36] <spiv> LarstiQ: hello
[19:36] <spiv> LarstiQ: if I go quiet, it's probably because the network here hates me.
[19:40] <LarstiQ> spiv: I know that feeling. I got my wifi card yesterday, tried to use it in the office, and then realized it doesn't support WPA.
[19:41] <spiv> LarstiQ: ouch.
[19:41] <spiv> LarstiQ: the problem here isn't so much my hardware as the other 900 people trying to use the network at the same time.
[19:43] <LarstiQ> spiv: ah yes
[19:43] <LarstiQ> spiv: how is PyCon going so far?
[19:47] <spiv> Good.  Busy!
[19:57] <LarstiQ> spiv: have you met Mark Hammond yet?
[19:57] <spiv> I have!
[20:00] <LarstiQ> yay!
[20:10] <Stavros> how can i see a list of the versioned files?
[20:11] <spiv> Stavros: bzr inventory
[20:11] <fullermd> Stavros: Check 'bzr ls' and its options.
[20:12] <Stavros> oh right, thanks
[20:51] <salgado> hey guys, why should I "bzr record" in a loomified branch? and what happens if I don't?
[20:53] <salgado> lifeless, you awake already? (^)
[20:54] <spiv> salgado: it records teh state of the lom
[20:54] <spiv> er, loom
[20:54] <spiv> salgado: as in, what the current revision of each thread is.
[20:55] <spiv> salgado: so if you want someone else to be able to branch your loom and have all the current revisions and see all the threads you've added and what your current thread is, you should use "bzr record"
[20:55] <fullermd> From skimming the docs, I think of it as sorta a 'meta-tag'.
[20:56] <salgado> spiv, right, that's what I imagined, but nobody can see the threads of my loomified branches once I push them to devpad. is that expected?
[20:58] <salgado> (I did record them)
[21:02] <fullermd> I think that's a different problem, that push doesn't push looms right...
[21:03] <salgado> could be
[21:03] <spiv> salgado: https://bugs.edge.launchpad.net/bzr-loom/+bug/201613 and https://bugs.edge.launchpad.net/bzr-loom/+bug/201409 might be affecting you
[21:03] <ubotu> Launchpad bug 201409 in bzr-loom "pulling a loom resets to last-recorded state" [Undecided,New]
[21:05] <salgado> a ha. /me subscribes
[21:05] <salgado> thanks spiv!
[21:13] <awilkins> jelmer: Any luck with those pyrex bindings?
[21:14] <awilkins> jelmer: I'm having _lots_ of fun trying to get them to build on win32
[21:52] <scode> I know I read somewhere about a setting that would allow me to have a branch of an upstream repo, which I in turn branch (down to my workstation for making actual modifications), yet have 'bzr send' and such use the original upstream as the target branch rather than the intermediare staging branch. Rings a bell?
[21:53] <blueyed> scode: rebase?
[21:53] <beuno> scode, you can just do bzr push parent_repo_location
[21:53] <beuno> don't need to jump through the branched branch
[21:54] <fullermd> Er.  Send, not push.
[21:54] <fullermd> And you can specify the target branch on the 'send' commandline.
[21:54] <beuno> send?
[21:55] <fullermd> And use --remember to mark it permanently.
[21:56] <scode> beuno: I am branching the bzr.dev upstream repo to which I have no access.
[21:56] <scode> beuno: This branc I keep on my central server. But then I want to branch *that* to work on.
[21:57] <scode> But I want "bzr send" to generate bundles as if I had had the bzr.dev as the direct upstream.
[21:57] <beuno> aaah, right
[21:57] <beuno> well, I have that exact workflow
[21:57] <LarstiQ> fullermd: $HOME/bin/bzr log -v > vlog  988.73s user 36.39s system 90% cpu 18:52.94 total
[21:58] <beuno> and send works fine when specifying upstream (and add --remember, as fullermd said)
[21:58] <scode> Yeah, just looking into that. Thanks!
[21:59] <fullermd> LarstiQ: Pfft.  You losers and your up-to-date systems   :p
[21:59] <beuno> scode, welcome
[22:01] <LarstiQ> fullermd: well, sort of :)
[22:02] <fullermd> I've got a spare drive somewhere I could toss in the PPro, and see how long that runs...    I remember those 45 minute 2-rev 'bzr pull's...
[22:15] <ubotu> New bug: #202331 in bzr "log should be able to show diffs as well" [Undecided,New] https://launchpad.net/bugs/202331
[22:56] <benzo> hi
[23:13] <jelmer> awilkins: Hi
[23:14] <jelmer> awilkins, still there?
[23:16] <benzo> yes - again
[23:16] <benzo> you too?
[23:17] <Odd_Bloke> Evening.
[23:17] <benzo> i've some basic questions
[23:17] <Odd_Bloke> benzo: Don't ask to ask. :)
[23:17] <benzo> always
[23:18] <benzo> as far I understand is bazaar a distr. scm
[23:18] <benzo> but there are also centralized scenarios
[23:18] <Odd_Bloke> benzo: Yep.
[23:18] <benzo> so you have basically:
[23:19] <benzo> - a server and - a client
[23:19] <benzo> could someone explain me how to start in such a scenario?
[23:20] <Odd_Bloke> benzo: You don't need a client/server in a distributed SCM.
[23:21] <Odd_Bloke> benzo: You _can_ do it that way, but it's not the only way. :)
[23:21] <fullermd> I think terminologically "server" and "client" are misleading in this connection...
[23:22] <benzo> there is a term "lock-step"
[23:22] <fullermd> It's really best viewed as a continuum.
[23:23] <benzo> yeah but I like to stick with client/server model for a moment - ok?
[23:23]  * fullermd shrugs.
[23:23] <fullermd> I don't think it's helpful.  Distributed work is all client-server too.
[23:23] <fullermd> The distinguishing feature is branch relations, not "client" or "server".
[23:24] <LarstiQ> benzo: often, the 'server' is just another client you decide to think differently of.
[23:24] <huslu> is there something that can track owndership and permission info of files in bzr?
[23:24] <benzo> ok here is what I mean: server=mainline
[23:24] <LarstiQ> huslu: unix permissions? Not in the core
[23:25] <LarstiQ> benzo: ok
[23:25] <huslu> LarstiQ: anywhere else? i'm trying to track /etc
[23:25]  * fullermd should write something up someday.
[23:25] <benzo> how do I have to setup that?
[23:26] <benzo> how do I start?
[23:27] <benzo> I'd like to have the following scenario for starters:
[23:28] <LarstiQ> huslu: a quick look at BzrPlugins doesn't show any, but I know people use bzr for /etc. You might also want to look at the tool 'etckeeper'
[23:28] <benzo> 1. a central repository on a webserver
[23:28] <LarstiQ> benzo: well, you could just push/pull to one machine
[23:28] <benzo> 2. a client who can checkout/commit
[23:29] <benzo> 3. the possibility the read the sources via web browser
[23:30] <benzo> on the server, i went through the 5-min tut: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
[23:31] <benzo> to the step: Viewing the revision log
[23:31] <benzo> but know I'm not sure if I startet the wrong way
[23:32] <LarstiQ> benzo: http://bazaar-vcs.org/Workflows may be of help
[23:32] <benzo> do I have to start on the 'client' and then push the branch to the server?
[23:33] <LarstiQ> benzo: no, you can make available what you did and go from there
[23:33] <benzo> yes I know these - thanks
[23:34] <benzo> but again - do I have to start on the 'client' and then push the branch to the server?
[23:34] <benzo> in a centralized scenario?
[23:34] <LarstiQ> benzo: no, the server is nothing special, it's a client too
[23:35] <LarstiQ> benzo: so there's nothing really wrong with what you did
[23:35] <benzo> is it ok then when I started on the server (sorry ...)
[23:35] <LarstiQ> benzo: yes, it is.
[23:35] <LarstiQ> no worries :)
[23:36] <benzo> and how can this no requested per url?
[23:36] <benzo> for viewing it in a web browser
[23:36] <LarstiQ> benzo: multiple different ways. For write access you'd either have bzr+ssh:// or sftp:// or possibly bzr:// if you run bzr serve
[23:37] <LarstiQ> benzo: ah, that's a different question
[23:37] <LarstiQ> benzo: do you want the raw content, or something like loggerhead?
[23:38] <benzo> i think i start with raw content
[23:38] <benzo> its easier i guess
[23:38] <LarstiQ> http://bazaar.launchpad.net/~bzr/bzr/trunk/files is an example of loggerhead btw
[23:39] <benzo> nice! but step-by-step
[23:39] <LarstiQ> benzo: well, then you'd need to have a webserver running, and somewhere under it's docroot you'de have a checkout of the branch you want to browse
[23:39] <benzo> ah ok - thats the mistake ive done
[23:40] <benzo> what if i'm not on the server
[23:40] <LarstiQ> what do you mean?
[23:41] <LarstiQ> Surely you're not physically sitting on it :)
[23:41] <benzo> can the checkout be done remotely
[23:41] <benzo> :-)
[23:42] <LarstiQ> benzo: making a checkout on the server needs to have access to it somehow
[23:42] <benzo> otherwise the content on the web is not updated
[23:42] <benzo> do you know svn
[23:42] <benzo> ?
[23:42] <LarstiQ> I do.
[23:43] <benzo> you can setup apache that he reads the repository
[23:44] <LarstiQ> benzo: yeah, so as an equivalent to that I'd probably suggest running loggerhead.
[23:45] <benzo> but loggerhead is 'just' the webfrontend no
[23:45] <benzo> ?
[23:45] <benzo> sorry i alway miss the ?
[23:45] <LarstiQ> 'a' webfrontend, yes
[23:46] <benzo> but consider the following workflow
[23:47] <benzo> a.) I work on my machine and commit to the central repo
[23:47] <benzo> b.) then I have to make a checkout on the server, so that I can view the changes on the web?
[23:50] <LarstiQ> that doesn't seem like a workflow?
[23:50] <LarstiQ> benzo: what are you trying to accomplish with viewing it on the web?
[23:50] <benzo> viewing the sources
[23:51] <LarstiQ> you can do that by other means of course, but then why not use loggerhead for that purpose?
[23:52] <benzo> c) an other person would checkout then
[23:52] <LarstiQ> making a checkout is no different for them than for you?
[23:52] <benzo> its an example
[23:53] <benzo> and why do I have to checkout?
[23:53] <LarstiQ> maybe it's because it's almost 01:00
[23:53] <LarstiQ> but I don't understand what your problems are
[23:55] <benzo> a picture says more then thousand words: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/images/workflows_centralized.png
[23:55] <LarstiQ> benzo: if you had just a basic httpd, and wanted to show the file contents, you would make use of it's filesystem backed method of showing files. In order to get the files you want to view from a branch, you make a checkout.
[23:55] <LarstiQ> benzo: I understand the picture, I don't see how it explains your questions.
[23:56] <LarstiQ> maybe an example helps
[23:57] <benzo> but you had it almost: "benzo: yeah, so as an equivalent to that I'd probably suggest running loggerhead."
[23:57] <LarstiQ> 'client'> cd work; bzr push sftp://server/srv/bzr/work; ssh server bzr co /srv/bzr/work /var/www/viewable-work ; links http://server/viewable-work
[23:57] <LarstiQ> and then you'd see the files in your browser
[23:58] <LarstiQ> benzo: if you use loggerhead, you wouldn't create a checkout on your server
[23:58] <LarstiQ> benzo: since in that case you have a webapp doing the work for you, instead of using a dumb http that is only showing files it has on disk.
[23:58] <LarstiQ> httpd even
[23:59] <benzo> client'> cd wo.... THIS IS WHAT I WANTED TO KNOW
[23:59] <LarstiQ> note in my command line exaple above, you would only do the 'bzr co /srv..' once
[23:59] <benzo> ;-)
[23:59] <LarstiQ> benzo: you didn't make that clear to me
[23:59] <LarstiQ> and now I'm going to bed
[23:59] <LarstiQ> ciao