[00:08] <bob2> do any dvcses aside from darcs have superfly cherrypicking?
[00:08] <fullermd> I think arch did OK.
[00:09] <fullermd> Probably not as good as darcs though, since it's fundamentally first-class in darcs.
[00:13] <ronny> fullermd: last time i checked arch was rather broken
[00:14] <ronny> and i dont think it got any better
[00:19] <beuno> mwhudson_, any ideas why tests now always fail for me in LH (on all branches, so it's not the broken tests)?
[00:19] <beuno> http://paste.ubuntu.com/187005/
[00:19] <beuno> jelmer, hi
[00:19] <jelmer> beuno, hello
[00:20] <beuno> jelmer, quick question
[00:20] <fullermd> Well, AFAIK it's not moving anywhere.  But it still sorta cherrypicked OK   :p
[00:20] <beuno> jelmer, when was bzrlib.foreign introduced in bzr?
[00:22] <lifeless> 1.13/1.14
[00:22] <beuno> jelmer, just to figure out if I have to bump the min bzrlib version
[00:22] <beuno> ok, I do then
[00:22] <beuno> thanks lifeless
[00:22] <jelmer> beuno, good question, I think it was 1.11
[00:22] <jelmer> lifeless, that late?
[00:25] <igc> morning
[00:25] <beuno> hi igc
[00:25] <igc> hi beuno
[00:27] <beuno> jelmer, I'm not sure what to expose on the UI for this
[00:27] <beuno> as in
[00:27] <beuno> I have no idea what this is: (('203ae883-c723-44c9-aabd-cb56e4f81c9a', 'trunk', 230), BzrSvnMappingv3(TrunkBranchingScheme(0)))
[00:27] <jelmer> beuno, So in that particular case the interesting bit would be "trunk" and 230
[00:28] <beuno> jelmer, so it's not key value pairings, just values with no explanation to them?
[00:28] <jelmer> beuno: You can call use the second part of the tuple to get a key/value representation
[00:28] <jelmer> What is returned is a tuple with foreign_revid and mapping
[00:29] <jelmer> foreign_revid is specific to the foreign vcs
[00:29] <beuno> jelmer, could we refactor this so it gives us the key:value entries directly?
[00:29] <beuno> that way it's very clear what should be exposed  :)
[00:30] <jelmer> beuno, mapping.vcs.show_foreign_revid(foreign_revid) will return a dictionary with key/value pairs (all strings)
[00:30] <jelmer> that's what's used for "bzr log"
[00:30] <jelmer> you might also be interested in mapping.vcs though, e.g. for displaying a git/svn/hg/etc icon
[00:32] <jml> hey, bzr people.
[00:32] <beuno_> grr
[00:33] <jelmer> moin jml
[00:33] <jelmer> wb beuno
[00:33] <jelmer> beuno, did you see those last few lines?
[00:34] <beuno_> jelmer, saw: 20:30 < jelmer> you might also be interested in mapping.vcs though, e.g. for displaying a git/svn/hg/etc icon
[00:34] <beuno_> las
[00:34] <beuno_> last
[00:34] <jelmer> beuno_, yeah, that's right
[00:35] <beuno_> jelmer, it's starting to get more complex than exposing it on the UI
[00:36] <jelmer> beuno: Perhaps we should focus on just the foreign rev info first, and other fancy stuff like icons later
[00:41] <beuno> jelmer, sounds good
[00:41] <beuno> can you update the branch to ad that
[00:44] <lifeless> jelmer: I was sure it was in by then, and a later than actual answer is still useful :)
[00:45] <lifeless> jelmer: $ rmadison subunit
[00:45] <lifeless>    subunit | 0.0.2~bzr66-1 | karmic/universe | source, all
[00:46] <jelmer> lifeless, \o/
[00:46] <jelmer> beuno, will do
[00:48] <FurnaceBoy2> abentley, thanks for your suggestion earlier, but I am still stuck: http://pastebin.ca/1445563
[00:48] <FurnaceBoy2> abentley, thanks for your suggestion earlier, but I am still stuck: http://pastebin.ca/1445563  ; I have committed my changes before this
[00:50] <lifeless> FurnaceBoy2: if you want your local branch to overwrite the solaris10-port, add --overwrite to your push command, just once.
[00:51] <FurnaceBoy2> hm, ok. i think i have succeeded by doing that in the past, I wonder why it didn't occur to me this time.
[00:51]  * FurnaceBoy2 goes to try
[00:52] <FurnaceBoy2> ok that certainly pushed.
[00:52] <FurnaceBoy2> thanks
[00:53] <jelmer> beuno, sorry, phone call. I'm working on the foreign revid stuff now
[00:58] <jelmer> beuno, lp:~jelmer/loggerhead/foreign
[01:05] <lifeless> igc: ping
[01:05] <beuno> jelmer, thanks, dinner, but will look at it later
[01:05] <lifeless> igc: I'd like to try and convince you to change the core iter_changes and put excludes into it too :)
[01:05] <beuno> lifeless, your evil plan worked
[01:05] <lifeless> beuno: which one was that?
[01:05] <jelmer> lifeless: +1
[01:06] <igc> lifeless: I've come to the same conclusion
[01:06] <lifeless> \o/
[01:06] <igc> lifeless: trying to do it as a decorator is too fragile w.r.t. locking
[01:06] <igc> and consistency
[01:07] <lifeless> igc: it will also tend to trigger full inventory scans from dirstate, I suspect
[01:07] <igc> its just more work, but hey, that's ife
[01:07] <jml> how much memory can I expect bzr 1.14 to use when cloning a 1.2 GB branch stacked on a 450MB branch?
[01:07] <lifeless> jml: a few hundred MB probably
[01:07] <jml> limited on-production experimentation suggests 4.5GB+
[01:07] <lifeless> jml: bugger a file
[01:07] <jml> lifeless: cool.
[01:08] <beuno> lifellif"get slightly involved and then get sucked in/obbssessed"
[01:08] <jml> lifeless: will do that, but would like to experiment locally first.
[01:08] <lifeless> beuno: :) with loggerhead?
[01:09] <lifeless> I think it was loggerhead I tried to do that with
[01:48] <cody-somerville> jelmer, ping
[01:48] <jelmer> cody-somerville, hi
[01:48] <cody-somerville> jelmer, using the latest bzr-git, 0.3.2, locally I get a different error
[01:48] <cody-somerville> http://pastebin.ubuntu.com/187048/
[01:49] <jelmer> cody-somerville, what git repository was this again?
[01:50] <cody-somerville> git://git.debian.net/git/debian-live/live-helper.git
[01:53] <jelmer> cody-somerville: Hmm, that looks different indeed. Any chance you can file a bug report?
[01:54] <cody-somerville> jelmer, sure. bzr-git on launchpad?
[01:55] <jelmer> cody-somerville, yep
[01:55] <jam> igc: ping
[01:55] <igc> hi jam
[01:57] <cody-somerville> jelmer, filed as lp #382993
[01:58] <jam> igc: I was hoping you would get a chance to run some Usertest stuff on Jelmer's most recent bencode serializer code
[01:58] <jam> We really need to come up with a disk format for 2.0 rather soonish
[01:58] <igc> jam: that's on my list for today
[01:58] <lifeless> I'm still on check FWIW
[01:58] <lifeless> spiv: are you copacetic on network deltas?
[01:59] <igc> jam: the main thing I need is a patch/branch with all the proposed bits including a placeholder format, e.g. development8-rr
[01:59] <igc> jam: jelmer did exactly that fro me to benchmark the rio stuff
[02:00] <igc> jam: to test on OOo, I also need 36 hours to generate a repo in the proposed new format
[02:00] <jam> igc: I'm pretty sure he had a --dev7-rr format
[02:00] <jam> also, I would expect converting from --dev6 => --dev7 would be much faster
[02:00] <jam> and it could be mysql, it wouldn't have to be OOo
[02:01] <igc> jam: great. I'll take a look at his latest patches
[02:01] <igc> yes, mysql would be faster. I don't have it converted to development6 yet though.
[02:01] <igc> jam: can you upload a converted repo for me?
[02:07] <lifeless> jelmer: I don't see the index problem
[02:07] <lifeless> jelmer: care to fix?
[02:08] <jelmer> lifeless, I tried, but couldn't easily find out where the unicode objects were being introducecd
[02:09] <lifeless> what was their value?
[02:09] <kizzo> Is there a way to specify the ssh port to use when pushing something to your private branch?
[02:09] <lifeless> bzr+ssh://host:port/...
[02:10] <jelmer> lifeless, checking
[02:11] <kizzo> So instead of "bzr push lp:~kizzobot/blah/blah", the location would be "bzr+ssh://launchpad.net:22/..."?
[02:11] <kizzo> I'll try it out now.
[02:11] <lifeless> kizzo: uhm
[02:12] <lifeless> kizzo: the default port for lp/bzr+ssh is 22, so it should Just Work
[02:12] <lifeless> kizzo: what are you seeing happen?
[02:12] <lifeless> (and it would be bzr+ssh://bazaar.launchpad.net:22/~kizzobot/blah/blah)
[02:12] <kizzo> My /etc/ssh/ssh_client specifies a default port of NOT 2222.
[02:12] <lifeless> interesting
[02:12] <lifeless> ok
[02:12] <kizzo> Oh wait .. s/NOT//
[02:13] <lifeless> so the above should work
[02:13] <kizzo> Yeah.
[02:13] <lifeless> and please file a bug that lp: isn't forcing the port
[02:13] <jelmer> cody-somerville, looks like a symlink target that's been changed to include an extra /
[02:13] <kizzo> Yeah I would think so too.
[02:13] <kizzo> I think it is actually..
[02:13] <kizzo> kizzo@crashtest:~/work/new-bindings$ bzr push bzr+ssh://code.launchpad.net:22/~kizzobot/+junk/python-bindings
[02:13] <lifeless> in fact, bzr+ssh should possibly force the port
[02:13] <kizzo> ssh: connect to host bazaar.launchpad.net port 2222: Connection timed out
[02:14] <kizzo> hmm
[02:14] <lifeless> not code.launchpad.net - bazaar.launchpad.net
[02:14] <jelmer> lifeless, a bit related, it also looks like "bzr index" doesn't like ghosts
[02:14] <lifeless> redirectors in the middle will give you grief
[02:14] <lifeless> kizzo: another thing you could do, in ~/.ssh/config
[02:14] <lifeless> Host bazaar.launchpad.net
[02:14] <lifeless>   port 22
[02:14] <SamB> lifeless: why should it force the port ?
[02:15] <cody-somerville> jelmer, does that mean an easy fix?
[02:15] <jelmer> lifeless, node is (<bzrlib.btree_index.BTreeBuilder object at 0xa8c528c>, ('1545',), u'p  mapping.py')
[02:15] <lifeless> SamB: because there is a well known port
[02:15] <jelmer> cody-somerville, not sure yet
[02:15] <kizzo> lifeless: Oh ok that works - thanks.
[02:15] <kizzo> And specifying the port in the URL successfully works.
[02:15] <SamB> lifeless: wouldn't that be a major abuse of the URL syntax ?
[02:15] <lifeless> SamB: no
[02:15] <SamB> it's not necessarily the case that ALL ssh servers run on that port ...
[02:15] <lifeless> SamB: naturally
[02:15] <SamB> there may be situations where a SINGLE machine has MORE THAN ONE
[02:16] <lifeless> SamB: I think you have misinterpreted what I said
[02:16] <SamB> lifeless: what did you mean ?
[02:16] <lifeless> SamB: If a user tells bzr 'bzr+ssh://host/' bzr should be attempting to connect to port 22
[02:16] <SamB> oh, sure!
[02:16] <SamB> that's not forcing, that's defaulting!
[02:17] <lifeless> SamB: so it should be forcing the port when it invokes ssh
[02:17] <SamB> oh
[02:17] <SamB> you mean it should pass the default port on to SSH
[02:17] <lifeless> no, I mean it should tell ssh the port to use, always.
[02:17] <SamB> instead of just assuming that SSH has the default default?
[02:17] <lifeless> right
[02:18] <kizzo> SamB: I think lifeless is saying that it would be bad if the bzr tool itself was always forcing the port to be 22, and not letting the user specify another port.
[02:18] <lifeless> jelmer: is that a path in your tree?
[02:18] <SamB> kizzo: I'm pretty sure that's what I was trying to say to lifeless ...
[02:18] <jelmer> lifeless, mapping.py is, not the "p  " bit
[02:18] <kizzo> Oh nvm haha.
[02:18] <lifeless> jelmer: p is path
[02:18] <lifeless> jelmer: its the entry type
[02:18] <jelmer> lifeless, ah, right
[02:19] <lifeless> so
[02:19] <lifeless> search should be ghost friendly, as long as the ghosts aren't required to calculate deltas - which they must not be
[02:20] <spiv> lifeless: copacetic on network deltas?  I only just woke up, so I'm hardly copacetic on anything right atm ;)
[02:26] <lifeless> jelmer: what are you indexing?
[02:26] <jelmer> lifeless: anything
[02:28] <lifeless> jelmer: line 978 of index.py
[02:28] <lifeless> can you insert
[02:28] <jelmer> lifeless, it's looking very similar to the reconcile text ghost handling bug
[02:29] <lifeless> [02:29] <lifeless> --- index.py    2009-01-21 07:59:57 +0000
[02:29] <lifeless> +++ index.py    2009-06-03 01:29:17 +0000
[02:29] <lifeless> @@ -975,6 +975,9 @@
[02:29] <lifeless>          if document_key in self._document_ids:
[02:29] <lifeless>              return self._document_ids[document_key]
[02:29] <lifeless>          next_id = str(self.document_index.key_count())
[02:29] <lifeless> +        value = "%s %s %s" % document_key
[02:29] <lifeless> +        if type(value) is unicode:
[02:29] <lifeless> +            import pdb;pdb.set_trace()
[02:34] <jelmer> lifeless, (Pdb) print document_key
[02:34] <jelmer> ('p', '', u'mapping.py')
[02:35] <kizzo> When you do something like "bzr branch lp:whatever", what is the expanded version of "lp"?
[02:35] <moldy> hi
[02:35] <moldy> dumb question: how do i restore a deleted file?
[02:36] <jelmer> lifeless, unrelated question, could it be that bzr is fixing the formatting of InventoryEntry.symlink_target
[02:37] <lifeless> jelmer: peng filed this as a dev6 specific bug
[02:37] <jelmer> lifeless, the bzr-search thing you mean?
[02:37] <lifeless> jelmer: can you give me the backtrace for that?
[02:37] <lifeless> kizzo: its the result of an xmlrpc call
[02:38] <moldy> i have committed the deletion and done other changes since then
[02:38] <lifeless> moldy: bzr revert -r <rev that had the file> FILENAME
[02:38] <jelmer> lifeless, http://pastebin.ubuntu.com/187068/
[02:39] <moldy> lifeless: thanks! is there any better way to find <rev> than to read through the logs?
[02:39] <lifeless> moldy: bzr log -v | less , /FILENAME  :)
[02:40] <lifeless> moldy: (for now)
[02:41] <moldy> lifeless: ok, i see. thank you!
[02:41] <lifeless> jelmer: pull trunk
[02:42] <jelmer> lifeless, I can confirm that works, thanks!
[02:43] <jam> igc: lp:///~jameinel/bzr/bencode_serializer
[02:43] <jam> That should be the latest version of the serializer, with all the bits sewn together
[02:44] <jam> well, once it finishes uploading :)
[02:45] <jam> I think the machine with my mysql conversion is offline right now, I'll see what I can do
[02:47] <kizzo> Hmm why is "bzr branch lp:~kizzobot/+junk/python-bindings" talking SSH?  (I have a packet sniffer running and seeing the traffic).
[02:47] <kizzo> I'm under the impression that I'm branching FROM launchpad - why would SSH be involved?
[02:47] <Peng_> kizzo: Why shouldn't it?
[02:48] <Peng_> kizzo: If you've run "bzr launchpad-login", lp: expands to bzr+ssh://bazaar.launchpad.net/
[02:48] <kizzo> Peng_: It's a public branch.  Like, anyone should be able to get it.
[02:48] <kizzo> hmm
[02:48] <lifeless> jelmer: cool
[02:48] <Peng_> kizzo: Anyone can get it. If they haven't logged in, it'll use http.
[02:49] <Peng_> Who what works?
[02:49] <igc> jam: thanks
[02:49] <jam> igc: just make sure you run 'make' :)
[02:49] <igc> jam: and thanks for the reivews as well
[02:49] <igc> jam :-) will do
[02:49] <igc> the numbers tend to stand out if do forget :-)
[02:50] <igc> s/if/if I/
[02:53] <xnevermore> I'm trying to use bzr-svn to create a subversion repo on a remote server and push my bzr branch to it. I tried using "bzr svn-push svn+ssh://server.com/home/username/svnrepos/project", but got "bzr: ERROR: No repository present"
[02:54] <jelmer> xnevermore, a repository ahs to alreday exist
[02:54] <jelmer> and I need to fix my spelling
[02:54] <xnevermore> jelmer: do you know what the svn command for that is?
[02:55] <jelmer> xnevermore, on the remote server: svnadmin create /path
[02:55] <lifeless> jelmer: bzr init --svn svn+ssh://server.com/home/username/svnrepos/project would be cute :)
[02:56] <lifeless> jelmer: and the api definitely supports it:)
[02:56] <jelmer> lifeless, the remote one doesn't unfortunately
[02:56] <SamB> lifeless: well enough ?
[02:56] <lifeless> SamB: EPARSE
[02:56] <jelmer> lifeless, locally "bzr init-repo --subversion" already works
[02:56] <SamB> the API may believe it supports a thing, but it might not actually be possible to make it work in a real situation ...
[02:57] <lifeless> SamB: I don't see why it wouldn't
[02:57] <lifeless> SamB: or I wouldn't have said that the api supports it ;)
[02:57] <SamB> lifeless: that's usually on account of not having tried and failed ;-)
[02:58] <lifeless> SamB: are you arguing hypothetically, or from experience with this particular api ?
[02:58] <xnevermore> jelmer: ok, i issued that command, then issued the svn-push command, but got "bzr: ERROR: These branches have diverged. Use the merge command to reconcile them."
[02:58] <lifeless> jelmer: how does it fall down for you?
[02:58] <SamB> lifeless: hypothetically, I guess
[02:58] <SamB> I haven't tried and failed either
[02:58] <jelmer> xnevermore, you need to push to somewhere inside of the repository, e.g. URL/trunk
[02:58] <lifeless> SamB: 'nuff said
[02:58] <SamB> but the way jelmer keeps doing it I wouldn't have been surprised either way
[02:59] <jelmer> lifeless, the API for creating a repository requires you to specify a local path
[02:59] <lifeless> jelmer: whose api
[02:59] <jelmer> lifeless, The SVN one
[02:59] <SamB> oooh
[02:59] <lifeless> jelmer: I was meaning 'ssh host svnadmin ...'
[02:59] <jelmer> lifeless, The only API that works with svn+ssh://, svn:// and http:// doesn't allow creating repositories
[02:59] <SamB> for once it's not bzrlib's fault
[03:00] <jelmer> lifeless, ahh
[03:00] <lifeless> jelmer: which you have enough data to do
[03:00] <jelmer> lifeless, Yeah, I guess we could do that
[03:00] <SamB> jelmer: certainly it could try
[03:00] <SamB> what does svn+ssh need from a remote anyway ?
[03:02] <xnevermore> jelmer: cool, thanks. that worked fine
[03:03] <lifeless> SamB: it uses libsvn locally with a remote url
[03:03] <lifeless> SamB: as opposed to the bzr rpc server
[03:03] <SamB> lifeless: I meant, what does libsvn need from the remote ...
[03:03] <jelmer> SamB, it needs svnserve present on the remote server
[03:06] <lifeless> just like bzr really, except our serve is a subcommand
[03:10] <jelmer> svnserve should be an alias for "bzr serve --svn"
[03:18] <lifeless> that would be cool in a strange sort of way
[03:50] <thumper> jelmer: http://launchpadlibrarian.net/27418534/ubuntu-tweak-master-log.txt
[03:50] <thumper> jelmer: still awake?
[04:06] <Peng_> So, um, how do bzr serve --git and --svn work? Do they serve native git/svn branches over the git/svn protocols? Bzr branches?
[04:07] <Peng_> How do you check if a transport is read-only?
[04:07] <spiv> Peng_: there's .is_readonly() on the transport object
[04:08] <Peng_> spiv: Oh, that's simple and obvious. Thanks.
[04:08] <spiv> Peng_: of course, a transport may think its read-write and then get PermissionDenied from all write ops ;)
[04:08] <lifeless> .readonly is a misfeature
[04:08] <lifeless> I advise against using it
[04:08] <lifeless> it really just reflects that a particular transport will deny *all* write operations, not that *any given* operation will succeed
[04:08] <spiv> Peng_: so the reliable way is to actually try writing and be prepared to catch errors :)
[04:09] <Peng_> I'm interested in making sure the transport is read-only, not making sure it's not. :)
[04:10] <lifeless> Peng_: context?
[04:12] <Peng_> lifeless: Loggerhead, both in general, and specifically for serving .bzr/smart.
[04:17] <lifeless> Peng_: I'm not sure why you would care there?
[04:17] <lifeless> is there any reason loggerhead shouldn't be able to write when its serving, just as bzr:// can  ?
[04:18] <Peng_> That's a good point. Still, it doesn't allow configuring that (yet), and it should default to read-only.
[04:18] <lifeless> sure
[04:19] <lifeless> I'd make sure bzr serve's facility for configuring this is reused directly
[04:20] <Peng_> Thanks to how "bzr serve" works, it already is.
[04:20] <Peng_> "bzr serve" passes a transport to Loggerhead; if --allow-writes was not passed, it's read-only.
[04:20] <Peng_> But start-loggerhead and serve-branches are still around, and the latter takes arbitrary URLs.
[04:34] <lifeless> jam: ping
[04:39] <Peng_> Making Loggerhead writable is spooky and totally cool.
[04:46]  * igc lunch
[04:49] <lifeless> Peng_: for sex, have clients at the trunkof the branch get updates pushed via ajax when someone commits via loggerhead
[05:01] <Peng_> It's totally cool that pushing from a bzr client -> bzr+http server -> bzr server works, right?
[05:01] <lifeless> Peng_: yes
[05:01] <Peng_> :)
[05:16] <kizzo> lifeless: Thanks.
[05:42] <Peng_> Do you think it's worth running a bzr+http server?
[05:42] <Peng_> Especially since that entails running an old version of bzr that actually works?
[05:43] <jml> lifeless: so, regarding the memory thing I mentioned earlier
[05:43] <Peng_> I'm not sure what percentage of that was a serious question and what was whining.
[05:43] <jml> lifeless: http://paste.ubuntu.com/187123/ has a traceback I got from doing C-\ while the memory was climbing
[05:43] <jml> lifeless: can you please help me file a good bug for this, now that I can reproduce the error locally?
[05:44] <lifeless> sure
[05:44] <lifeless> let me look
[05:44] <spiv> Peng_: yeah, sorry about that, that bug is on my todo list...
[05:44] <lifeless> so that particular point is in index processing
[05:44] <lifeless> and you don't have the C extensions built
[05:45] <lifeless> first thing, see if they make a difference.
[05:46] <lifeless> jml: secondly, grab jam's memory profiler tool
[05:46] <lifeless> and use it when you break in
[05:47] <jml> I wonder why they aren't built. I'm running from the nightly ppa
[05:49] <lifeless> jml: I may be wrong
[05:49] <lifeless> import bzrlib._btree_serializer_c
[05:49] <jml> it's not there.
[05:50] <jml> 1.15+4368+109 should be recent enough, right?
[05:51] <lifeless> bug in the ppa builds
[05:51] <lifeless> I'll file it
[05:52] <jml> thanks.
[05:53] <Peng_> spiv: <3
[05:53] <jml> hah, I don't even have pyrex installed.
[05:54] <Peng_> Actually, I wasn't just whining. Branching bzr.dev's entire history over bzr+http would probably make my server catch fire.
[05:54] <pygi> Peng_: with what format ?:)
[05:57] <Peng_> pygi: 1.9.
[05:57] <pygi> Peng_: try with brisbane? :)
[05:58] <Peng_> pygi: Not possible. If I upgrade my bzr+http server to a version that supports bbc, it'll also suffer from bug 348308.
[05:58] <Peng_> Obviously I could set up two servers, but that'd be a pain.
[05:59] <Peng_> And anyway, trying it means risking an OOM.
[06:04] <jml> hmm. rate of climbing seems slower, but it's still over 1g.
[06:05] <lifeless> time for the memory profiler
[06:06] <jml> hurh, it's not using the c module
[06:06]  * jml bangs the box a couple of times.
[06:24] <jml> hmmmmm.
[06:24] <jml> now that I'm using C extensions, seems to be capped at ~721MB
[06:25] <lifeless> thats still high
[06:25] <lifeless> if you could build and use jams profiler that would be good
[06:25] <jml> lifeless: sure thing. where does it live?
[06:27] <lifeless> lol http://mac.wareseeker.com/free-john-arbash-meinel/
[06:28] <lifeless> (spam search hit in google)
[06:29] <lifeless> https://lists.ubuntu.com/archives/bazaar/2009q2/056433.html
[06:29] <lifeless> ^ jml:
[06:29] <jml> ta
[06:30] <jml> lifeless: interested at all in the pure python data?
[06:31] <lifeless> jml: not really.
[06:31] <lifeless> choosing battles etc
[07:18] <vila> hi all
[07:55] <spiv> Gar, why does PQM not want to send me failure mail...
[08:04] <lifeless> No handlers could be found for logger "bzr"
[08:04] <lifeless> Permission denied (publickey).
[08:04] <lifeless> bzrlib.errors.ConnectionReset: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[08:12] <spiv> Ah, right.  Ok.
[08:13] <spiv> I guess the PQM user isn't properly set up to cope with lp: URLs :/
[08:46] <lifeless> spiv: rt it?
[08:53] <ronny> jelmer: im kinda missing how i should store objects i created in a dulwich repo, any hints on what im missing?
[08:55] <ronny> ah, found my issue
[08:55] <ronny> searched the wrong file for that
[10:09] <jml> lifeless: did you go to jkakar's commandant talk?
[10:59] <balor> How do I throw out all the changes in my current working directory?  i.e. rebase on current HEAD.
[11:00] <Peng_> balor: ..."bzr revert"?
[11:01] <balor> Peng_: thanks
[11:01] <Peng_> Oh, good.
[12:20] <johnf> I've written an init script for bzr server. Should I submit a patch to bzr or should I just put it in the debian package?
[13:24] <vadi2> I
[13:25] <vadi2> *I'm trying to setup bzr over svn with bzr-svn, and thought the process was to make a new folder and use bzr-svn import --trees into the new location. But I accidentally did "bzr init" not in the new folder, but in the current svn one.
[13:25] <vadi2> the svn repository is huge and it's doing "something" - is that something wrong and should I cancel?
[13:32] <jelmer> vadi2, hi
[13:32] <jelmer> vadi2, init in the svn one?
[13:32] <jelmer> vadi2, doesn't sound like what you'd want
[13:32] <vadi2> yeah, after a long while it gave "bzr: ERROR: Already a branch: "."."
[13:33] <vadi2> But I'm having a problem getting it to import into my proper folder now though
[13:33] <vadi2> http://paste.pocoo.org/show/120769/
[13:34] <jelmer> vadi2, You're importing from a svn repo into a svn repo?
[13:34] <vadi2> why's that
[13:35] <vadi2> I did "bzr init" in yorba3 folder
[13:35] <jelmer> vadi2: That creates a branch, not a repository
[13:35] <jelmer> vadi2: A svn repository contains multiple branches
[13:35] <jelmer> you don't need to run "bzr init" before svn-import
[13:36] <vadi2> What would be the proper way?
[13:36] <jelmer> vadi2, don't running anything at all
[13:36] <jelmer> just "bzr svn-import yorba yorba3"
[13:37] <jelmer> or "bzr svn-import --trees yorba yorba3" if you want working trees
[13:37] <vadi2> Sorry. What folder to run that in?
[13:38] <vadi2> http://paste.pocoo.org/show/120770/
[13:38] <jelmer> vadi2, I think you may have a incomplete .bzr directory in Programs/ ?
[13:38] <jelmer> It should be run in Programs, ideally yorba3 should not exist yet
[13:39] <vadi2> no, don't have a .bzr in Program
[13:39] <vadi2> *s
[13:39] <vadi2> going to try deleting yorba3
[13:40] <vadi2> "No repository present: "file:///home/vadi/Programs/"" :/
[13:40] <vadi2> I'm using the stock jaunty version of bzr-svn though, not the ppa one because bzr-gtk breaks
[13:41] <jelmer> maybe try in a different directory
[13:41] <jelmer> e.g. bzr svn-import /path/to/yorba /tmp/yorba3
[13:42] <vadi2> $ bzr svn-import --trees /home/vadi/Programs/yorba /tmp/yorba3
[13:42] <vadi2> bzr: ERROR: No repository present: "file:///home/vadi/Programs/"
[13:42] <vadi2> there is no repository in 'Programs', that is correct. Not sure why it's not looking at the "yorba" folder
[13:43] <jelmer> vadi2, Does yorba actually contain a subversion repository?
[13:44] <jelmer> vadi2, is there no .bzr directory in yorba?
[13:45] <vadi2> there is a repository (svn log works) and there is no .bzr
[13:47] <vadi2> maybe I have a broken bzr-svn? getting the proper version installed without upgrading bzr was tricky.
[13:48] <jelmer> vadi2, don't know
[13:48] <awilkins> vadi2: Perhaps try bzr svn-import svn+file://home/vadi/Programs/yorba yorba3  ?
[13:50] <vadi2> http://paste.pocoo.org/show/120773/
[13:52] <jelmer> vadi2, that suggests there really isn't a svn repo in yorba
[13:53] <vadi2> But I have .svn in it and "svn log", "svn status" work okay
[13:53] <jelmer> vadi2: That suggests there's a subversion working tree there, not a repository
[13:53] <jelmer> vadi2: I think you want either 'bzr branch yorba yorba3' or 'bzr svn-import url-to-svn-repos yorba3'
[13:54] <vadi2> I'll try the first. It's very big to download again
[13:54] <vadi2> Thanks for your help, I'll try it in a bit.
[13:54] <jelmer> vadi2, it won't retain much of the data that 'svn co' downloaded
[13:54] <vadi2> o
[13:54] <vadi2> alright.
[13:55] <jelmer> vadi2, bzr downloads all of the history of what you're branching, svn only keeps the last revision
[13:56] <vadi2> right
[14:13] <beuno> jelmer, hi!  just took another stab at your foreign branch
[14:13] <beuno> but it tracebacks
[14:13] <beuno> added the tb to the merge proposal
[14:20] <beuno> james_w, hi
[14:22] <jam> spiv, lifeless: I missed this last night, but PQM fails with both lp: urls and bzr+ssh://bazaar.canonical.com/ ones
[14:22] <jam> I think they changed the firewall rules
[14:24] <jam> But #is never really came up with an answer
[14:25] <jelmer> beuno, that's odd, I can't see how we could get there without setting foreign_revid somehow
[14:25] <jam> i just switched to http://bazaar.launchpad.net
[14:25] <vila> jam: using http:// urls is the answer
[14:25] <vila> jam: and hi :)
[14:25] <beuno> jelmer, yeah, I tried to fiddle with the code, but didn't figure it out either
[14:26] <jam> hey vila
[14:26] <jam> It is *an* answer
[14:26] <jam> I don't think it should be *the* answer
[14:26] <jam> Perhaps the LOSAs feel differently
[14:26] <vila> jam: I agree with you, but it's the only answer that works :)
[14:26] <jam> I wonder if they didn't change PQM so that it actually thinks it has a launchpad user account
[14:26] <jam> and now it is trying to log in
[14:26] <vila> do you mean you used to be able to use lp: URLS ?
[14:27] <jam> whereas before lp:/// urls were resolving to http
[14:27] <jam> vila: I configured it and had it working for at least 2-3 months
[14:27] <vila> jam: that's so unfair ! So I was really the only one hanging pqm while using them :-)
[14:30] <jam> vila: I think you hung pqm, then they "fixed" it, so I could use it
[14:30] <jam> then they broke it again :)
[14:30] <vila> jam: I thought "they" fixed it twice, so I'm more cautious now about that :)
[14:43] <moldy> hi
[14:43] <moldy> why does bzr st only show directories with status unknown, but not the files inside those directories?
[14:59] <stani> how can I retrieve the revision number from python from a bazaar repository
[14:59] <stani> ?
[15:00] <beuno> stani, you have the revision id?
[15:00] <beuno> stani, take a look at: http://bazaar-vcs.org/Integrating_with_Bazaar
[15:01] <jelmer> beuno, argh, I'm so stupid
[15:01] <stani> I have a path and I want to get the revision number so I can construct a temporary version number for my package: package-0.2.bzr192
[15:01] <jelmer> beuno, fix pushed
[15:02] <beuno> jelmer, thanks
[15:02] <stani> bueno: thanks, I'll try that
[15:02] <beuno> stani, so you need the tip?
[15:02] <beuno> it should be explained there
[15:06] <stani> bueno: hmmm doesn't seem to work
[15:06] <stani> bueno: http://www.pasteall.org/5894/python
[15:08] <stani> bueno: I thought afterwards I could do b.revno()
[15:08] <beuno> stani, you need to open the branch
[15:09] <beuno> Branch.open('....
[15:09] <jam> moldy: we don't recurse into unknown directories because often that would be foolish
[15:09] <jam> consider a "build" directory with hundreds of unwanted files
[15:09] <stani> bueno: thanks, stupid mistake of me
[15:10] <moldy> jam: i would like to see that there are hundreds of unwanted files
[15:11] <moldy> jam: without having to run ls on every directory with status unknown :) there is no option to request recursion?
[15:11] <jam> moldy: it was an explicit design decision, if you can present a use case for changing it, then please describe it to su
[15:11] <jam> moldy: bzr ls --recurse
[15:11] <jam> sorry "bzr ls --recursive"
[15:12] <moldy> "bzr st --recursive" would save me that additional command
[15:13] <moldy> i might want to add the directory, but not its contents
[15:21] <stani> beuno: what is the python equivalent to 'bzr export', it doesn't seem to be mentioned on that page
[15:35] <jam> stani: you can generally look in bzrlib/builtins.py to see what a command does, and how to translate that into direct python calls
[15:45] <timour> Guys, I need help with BZR 1.15.
[15:46] <timour> I have Kubuntu 9.04, fresh install.
[15:46] <timour> When I run any BZR command I get:
[15:46] <timour> "No handlers could be found for logger "bzr"
[15:46] <jelmer> timour, is your ~/.bzr.log writable?
[15:46] <timour> jelmer, checking ...
[15:48] <timour> jelmer, weird, no, it is:
[15:48] <timour> -rw-r--r-- 1 root root 18K 2009-06-03 17:22 .bzr.log
[15:49] <timour> jelmer, should I chown it and make it writeable?
[15:49] <jelmer> timour, yeah
[15:50] <visik7> does bzr serve implement a wsgi interface ?
[15:51] <timour> jelmer, great, it worked, thanks a lot!
[15:51] <jelmer> visik7: bzr serve --http uses wsgi internally
[15:52] <visik7> but can I attach bzr serve to mod_wsgi ?
[15:54] <jelmer> visik7: You can attach loggerhead to mod_wsgi I *think*
[16:02] <visik7> if setup loggerhead do the server automatically checkout latest revision ?
[16:03] <visik7> or also without loggerhead
[16:03] <visik7> I mean does a non-dumb server provide autocheckout ?
[16:04] <jelmer> visik7, not sure I'm following
[16:05] <visik7> I'm referring to http://doc.bazaar-vcs.org/bzr.0.18/server.htm
[16:05] <visik7> if I push using a dumb server the branch is not checked out
[16:05] <visik7> I was asking if with a non dumb server the checkout is performed
[16:05] <jelmer> visik7, ah
[16:05] <jelmer> visik7, no, that's not the case yet
[16:05] <visik7> :(
[16:06] <visik7> I need a way to auto checkout on push
[16:06] <visik7> and the push-and-update plugin is not a viable solution
[16:06] <jelmer> there's a plugin that can do that over ssh
[16:06] <jelmer> ah
[16:07] <jelmer> visik7, I don't think there's anything that can do that atm
[16:07] <jelmer> visik7, Somebody needs to add that feature to the smart server
[16:07] <visik7> smart server ?
[16:07] <jelmer> visik7, yeah, what bzr+ssh:// and bzr+http:// use under the covers
[16:08] <visik7> oh the non dumb
[16:08] <visik7> :)
[16:08] <visik7> ok and bzr serve is hookable ? with a custom plugin to get this thing ?
[16:09] <jelmer> I don't know
[16:09] <visik7> ok thanks anyway
[16:11] <jelmer> lifeless, ping
[16:13] <awilkins> I've been trying to get lifeless for days, is he alive?
[16:13] <awilkins> (hmm, that was a humourless pun on his name...)
[16:13] <beuno> awilkins, he was around yesterday, yes
[16:15] <andrew> What do I need to have in order to be able to tab-complete bzr commands? (Ubuntu 9.04)
[16:16] <awilkins> andrew: Seems to just work here, I'd never thought about it
[16:16] <beuno> andrew, it works by default
[16:17] <andrew> For example, if I type in: bzr st[tab], it starts giving me file names
[16:17] <beuno> andrew, that's odd. It shouldn't happen
[16:19] <andrew> But since it does happen, what can I do to fix it?
[16:27] <awilkins> Remove and reinstall the bzr package?
[16:27]  * awilkins is embarassed to propose this windows-onian method
[16:27] <andrew> awilkins: tried that, no luck
[16:28] <andrew> awilkins: ha, don't be embarassed, I tried that already as it was suggested by somebody else
[16:31] <visik7> how can I run the following command from a python script: bzr update
[16:31] <visik7> =
[16:31] <visik7> ?
[16:32] <LarstiQ> andrew: is completion enabled in the shell you're using?
[16:33] <LarstiQ> andrew: bash on Debian for instance, has it disabled by default
[16:34]  * LarstiQ heads to the dojo
[16:40] <andrew> got it fixed thanks to evand. Apprently I didn't have a ~/.bashrc ...
[16:50]  * andrew blames likewise-open for that messup
[17:18] <ddaa> Here's an idea for promoting bzr.
[17:19] <ddaa> It's the dvcs for test-driven development and continuous integration.
[17:19] <ddaa> Write test, write implementation, commit, merge parent, repeat.
[17:19] <dash> ddaa: I would like to believe that
[17:19] <dash> Hmm.
[17:19] <dash> how's that different from the competition
[17:20] <ddaa> Other dvcs, with their anemic log functionality discourage frequent commits on feature branches and frequent merges.
[17:20] <dash> well, that matches my experience
[17:20] <ddaa> Because that creates a lot of very small commits that end up making the mainline log unusable.
[17:21] <dash> i specifically picked bzr over hg because of the ability to get a clean trunk log
[17:21] <bob2> eh
[17:21] <dash> like i was used to in svn
[17:21] <bob2> bzr and git now have the same log output
[17:21] <SamB> bob2: eh?
[17:21] <ddaa> bob2: meh?
[17:21] <dash> bob2: interesting.
[17:21] <ddaa> bob2: you mean hg changed its log output to highlight the mainline?
[17:21] <SamB> maybe if you use --first-parent or whatever ...
[17:22] <bob2> no idea what hg does
[17:22] <ddaa> Ah, I mean git.
[17:22] <ddaa> You mean git log now only shows the mainline?
[17:22] <ddaa> and has an option to show a hierarchical log?
[17:23] <bob2> --graph, iirc
[17:23] <ddaa> I dunno git, but I know that with hg's "fast forward pull on no divergence", you cannot get a clean mainline even if you want to.
[17:24] <ddaa> I know jelmer reported that samba folks asked him to stop frequently merging trunk into his branch because it polluted the log.
[17:24] <stani> What is the equivalent of 'bzr export DEST' in python? Is this done with a WorkingTree or a Branch?
[17:24] <dash> ddaa: right, that's the key missing feature in hg as far as I can tell
[17:25] <dash> I did have an hg user tell me it was possible once
[17:25] <dash> but it's not the normal mode of operation
[17:25] <ddaa> I'm pretty sure that's not going to change now.
[17:25] <dash> sure.
[17:25] <luks> can't you just always fetch+merge?
[17:25] <ddaa> Their community is too used to the way it works now to change at this point.
[17:25] <dash> luks: not if there's no divergence.
[17:25] <luks> hm, interesting
[17:25] <SamB> huh, git at least has an option for it!
[17:26] <jelmer> SamB, defaults matter unfortunately
[17:26] <SamB> jelmer: yes, they do
[17:26] <dash> especially unfortunate defaults
[17:26] <SamB> but at least with git you CAN do it if you get asked to
[17:26] <luks> well, I think git people see the history differently than bzr people
[17:26] <ddaa> Anyway, I think that can be a useful sales script.
[17:26] <luks> in git it's a set of patches, basically
[17:26] <SamB> you know ?
[17:27] <ddaa> luks: and they are sooo wrong.
[17:27] <luks> but they seem to like it
[17:27] <ddaa> but I have yet figured the right arguments to explain it clearly.
[17:27] <luks> flat log / rebase / etc.
[17:27] <SamB> luks: er, well, it's not a set of patches
[17:27] <SamB> but sometimes they use it to store a pile of patches
[17:27] <luks> SamB: not technically, but they treat it that way
[17:27] <SamB> which it isn't at all good for
[17:27] <SamB> really
[17:27] <ddaa> luks: I believe git folks like it because either 1. they have hugre trees and require git performance or 2. they do not know any better.
[17:28] <SamB> I honestly wish there was some kind of git/darcs hybrid where you could keep that "set of patches" in a darcs-managed area on top of a git-managed history ...
[17:29] <Isaiah> ddaa: Or they use github ;)
[17:29] <luks> I can see that maintaining a mainline in the kernel wouldn't be easy
[17:29] <luks> but I think it would work better for most other projects
[17:29] <ddaa> SamB: the mental model of a tool's community is important. It dictactes a lot of the detail choices that form the day to day experience with the tool.
[17:31] <ddaa> luks: I believe the kernel has a strong culture of "lines of development", it's just that there are basically two kinds of people: those have the conceptualization skills required to see past git's quirks, and those that don't care.
[17:31] <ddaa> Less polarized projects may have more people in the middle area, where they build a workflow and mental model informed by the quirks of git's ui.
[17:33] <ddaa> I'm also a bit irked by how hg's documentation confused "changeset" and "revision".
[17:33] <SamB> anyway, it isn't always bad if things that were in feature branches end up in the mainline ...
[17:33] <ddaa> SamB: explain what you mean.
[17:34] <SamB> well, it depends on how noisy they were, mostly ...
[17:34] <ddaa> That's my point.
[17:34] <ddaa> The DVCS for TDD must support extremely chatty branches.
[17:34] <SamB> oh.
[17:35]  * SamB wishes the kernel used more TDD
[17:35] <SamB> well, in the sense that tests would be nice
[17:35] <SamB> not in the sense that I think anyone should stop trying to think about the correctness of their code ...
[17:35] <ddaa> SamB: it's not clear it's at all possible for kernel development. Most of the problems are with hardware quirks.
[17:35] <SamB> ddaa: hmm.
[17:35] <luks> I imagine testing hardward interaction must be fun
[17:36] <SamB> well, it'd still be nice if there were more tests for the things that can be tested, you know?
[17:37] <SamB> the kernel isn't ALL drivers
[17:37] <SamB> and some of the drivers aren't for devices, even
[17:37] <luks> yeah, but that's usually the patch that is broken
[17:37] <luks> and should be properly tested
[17:37] <luks> er, s/patch/part
[17:39] <SamB> it'd be handy to have a provided test harness even without the tests, actually ...
[17:40] <ddaa> You need test, otherwise how do you know that your test harness works? :)
[17:41] <mthaddon> abentley: so the verdict on nested trees is that it's not in the immediate future - do you know if it'll be in bzr 2.0 and what the timeline for that is?
[17:42] <ddaa> For crissakes, can we very much please have it for bzr 2.0?
[17:42] <abentley> mthaddon: I don't know whether it'll be in 2.0.
[17:42] <SamB> ddaa: well, okay, I meant without many tests
[17:42] <abentley> mthaddon: I'm not sure what timeline you mean.
[17:42] <ddaa> It's a major differentiating feature, IMO it's worth delaying 2.0 until it's done and stabilized.
[17:43] <mthaddon> abentley: I was meaning when 2.0 is expected to be released, but if you're saying it might not be in 2.0, then I guess it's a moot point
[17:43] <mthaddon> but fwiw I'd agree with ddaa
[17:43] <abentley> ddaa: It's currently in the design stage.
[17:44] <abentley> mthaddon: There will be a 1.6 release.  2.0 could be the next release after that.
[17:45] <mthaddon> ok, thx
[17:45] <abentley> sorry, 1.16, not 1.6
[17:47] <ddaa> abentley: That's good to know, but it does not contradict my position: it's a major differentiating feature, and it's worth delaying 2.0 for it, so it will have the exposure it deserves.
[17:47] <ddaa> There's only one shot at 2.0, so you must make it count.
[17:48] <abentley> ddaa: All other DVCSes have it, so it can only be a differentiating feature by being awesome.
[17:48] <ddaa> if you are referring to hg forests
[17:48] <ddaa> (or git equivalent)
[17:48] <ddaa> it's about as advanced as config-manager
[17:48] <SamB> abentley: what the heck do you mean that all other DVCs have it?
[17:48] <ddaa> meaning that IMHO it sucks major balls
[17:48] <SamB> and I don't think it's that great in any of them at the moment ...
[17:49] <ddaa> the only thing that's close is svn externals, and AFAIK no dvcs is even close to this level of seamlessness.
[17:49] <abentley> SamB: Mercurial has the forests extension, Git has submodules.  (I shouldn't have said they "all" have it.)
[17:49] <SamB> and who uses them ?
[17:49] <SamB> especially who uses submodules ?
[17:49] <ddaa> But that's a good point.
[17:50] <ddaa> "All other dvcs claim to have it, although they have only some half-assed implementation, so the promotion impact of having it in bzr is consideradly lessened".
[17:50] <SamB> I remeber once someone actually had a problem while using them and asked a question about it in #git
[17:51] <SamB> but I don't remember if the problem was actually related to them or not
[17:51] <ddaa> SamB: I'd bet submodules suck, but we're talking perceptions here.
[17:52] <ddaa> abentley: OTOH, that means that NOT having nested trees for 2.0 can be a perceived weak point for bzr.
[17:53] <SamB> ddaa: perhaps only by someone who hasn't actually heard anything about how git's work ...
[17:53] <ddaa> According to this line of though, 2.0 should implement some minimal support for nested trees.
[17:53] <bialix> ddaa: do you aware of scmproj?
[17:53] <ddaa> SamB: which is the case of essentially anyone who's choosing a new DVCS.
[17:53] <ddaa> bialix: nope
[17:53] <SamB> ddaa: eh?
[17:54] <bialix> this is plugin emulated nested trees
[17:54] <ddaa> SamB: most people who are switching their project to a DVCS have only the vaguest ideas of the specifics of each tool. That why they usually end up just picking the fastest, because that's a difference they can measure.
[17:54] <bialix> I'd like to reuse some abentley work
[17:55] <abentley> ddaa: And *that*'s what 2.0 will address.
[17:55] <ddaa> bialix: is it usable in production
[17:55] <ddaa> abentley: I know that's the *main* goal of 2.0.
[17:55] <bialix> ddaa: nested trees is better
[17:56] <ddaa> bialix: abentley just said that nested-trees are "in the design stage"
[17:56] <bialix> yes
[17:56] <bialix> and this makes nested trees better
[17:56] <bialix> scmproj is poor emulation. it works but have some problems
[17:57] <ddaa> abentley: but I also think that the 2.0 release should pack the maximum punch possible.
[17:57] <ddaa> bialix: I hardly see how "something that's in the design stage" (implicitly, not something that's usable) can be better than something that works today.
[17:59] <bialix> git submodules is also work today, altough you guys very hardly on it
[18:00] <ddaa> Two different discussions.
[18:00] <ddaa> One hand: what's the right way to do it.
[18:01] <ddaa> Other hand: perception of potential adopters or switchers.
[18:01] <ddaa> As past experience has shown, they have very little overlap.
[18:01] <ddaa> Since the perception is that git and hg have a form of nested trees.
[18:02] <ddaa> The question is whether scmproj can be used to convincingly argue that bzr has feature parity.
[18:02] <bialix> I've designed scmproj based on forest/submodules and past nested trees spec.
[18:03] <bialix> but it need more love
[18:03] <bialix> I'd say it could be used to check different variants for implememting real nested trees
[18:04] <bialix> but I'm not aware someebody is using it aside me and AmanicA
[18:04] <bialix> so there is too little user feedback
[18:04] <bialix> is it usable? more or less. Could ut be better -- definitely
[18:05] <bialix> but all people waiting for real nested trees, so I'm doubt scmproj is vital alternative
[18:07] <ddaa> So we're still stuck without a viable conterparts for forests/submodules.
[18:07] <cdecarlo> I need to use a non-standard port to connect to my comuper over ssh, how do I use bzr+ssh:// to connect to a different port?
[18:07] <ddaa> Which I think should not be the case in 2.0.
[18:08] <cdecarlo> *computer
[18:08] <bialix> ddaa: we also still don't have versioned properties
[18:10] <ddaa> You mean file properties?
[18:10] <bialix> today they called rulkes
[18:10] <bialix> rules
[18:11] <ddaa> I do not know what you are talking about.
[18:11] <ddaa> And I like to think I know a thing or two about version control...
[18:11] <bialix> abently: does lp:bzr/1.15 is valid submit branch for BB?
[18:12] <bialix> ddaa: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#rules
[18:15] <ddaa> bialix: so you say this should be supported by metadata (not unlike revision properties) that have versioned text (like source files).
[18:15] <bialix> no, I don't say anything
[18:16] <bialix> this is not file properties
[18:16] <ddaa> I say, let's just stick that in a source file and be done with it.
[18:16] <bialix> the problem is these rules currently is not propagated
[18:16] <ddaa> It's not ideal, but there's a precedent with .bzrignore
[18:17] <bialix> many devs think it's wrong approach
[18:17] <ddaa> and the alternative are all pretty bad
[18:17] <bialix> and I understand why
[18:17] <ddaa> Well, I guess they have thought of an alternative I haven't thought of.
[18:17] <bialix> but.. at the end of the day there is still nothing in bzr
[18:18] <ddaa> Right. The bzr dev are sometimes too focused on doing the Right Thing, to the point of sometimes not doing anything.
[18:18] <bialix> :-/
[18:18] <ddaa> See what happened with tags.
[18:18] <bialix> tags are bad
[18:19] <ddaa> They are certainly inelegant.
[18:19] <bialix> they definitely better than .hgtags
[18:19] <ddaa> Do they solve their target use case?
[18:19] <ddaa> I think so.
[18:19] <dash> huh. why are tags bad?
[18:19] <bialix> until you start change tags and merging them
[18:20] <ddaa> bialix: the point is that when you start to think about merging tags, you go mad.
[18:20] <bialix> today it's nightmare
[18:20] <bialix> I wonder how git does tags merge
[18:20] <jam> bialix: git has conflicts on tags pretty much the same as us
[18:20] <dash> merging tags sounds like a thing that shouldn't work at all
[18:20] <jam> dash: it is more the idea that both people have tag "foo" but they disagree on the value
[18:20] <jam> how do you resolve that?
[18:20] <bialix> jam: in git tags are objects
[18:20] <jam> bialix: they are just refs
[18:21] <jam> not versioned objects
[18:21] <jam> refs/tags/XXX IIRC
[18:21] <ddaa> I had the chance to participate in many a restaurant discussions about tags merging with lifeless and the folks, and once you started to think about merging and conflicts it became horrendously tricky in terms of user interface.
[18:21] <dash> jam: it would not hurt my feelings if that just failed outright
[18:21] <jam> ddaa: of course, then someone wants to delete a tag and have it propagate
[18:21] <bialix> ddaa: you know today bzr simply stops
[18:22] <bialix> there is absolutely no UI to merge tags
[18:22] <jam> I believe the current state for bzr is that you can do "bzr pull" which will keep your local tags and "bzr pull --overwrite" which will use the remote tags
[18:22] <jam> but merge doesn't have the same options, etc.
[18:22] <ddaa> that's fine
[18:22] <ddaa> at least the tags are there, and people no longer obsess about "bzr is missing tags"
[18:23] <ddaa> and since nobody has solved the problem any better, it's not net drag on adoption
[18:23] <bialix> jam: git's tags has additional metadata: who create tag and when. why bzr don't have it?
[18:25] <bialix> ddaa: so, using your classification, bzr has nested tree support today: from scmproj plugin.
[18:25] <bialix> it's almost equally ugly as in hg/git and it kinda works
[18:26] <ddaa> does it kinda work equally to hg/git?
[18:26] <jam> bialix: Because it wasn't part of the requirements that Martin put together when he created basic tag support
[18:26] <bialix> ddaa: you can get, update, commit, push easily entire nested construct. and perform more complex actions like in git
[18:27] <ddaa> if it's not any worse than hg/git solutions, then I say let's have 2.0 and big partay!
[18:27] <bialix> ddaa: other actions require more work
[18:27] <jam> bialix: also, git tags don't *always* contain that info
[18:27] <jam> I just tested it
[18:27] <jam> and I create .git/refs/tags/test-tag which just has a sha1 in it
[18:27] <ddaa> BTW, can we have 2.0 partay for DVCS geeks in Paris?
[18:28] <ddaa> Or alternately, can I have an invitation?
[18:28] <ddaa> I miss having beer with you folks.
[18:28] <bialix> jam: I was under impression git tags should have additional metadata. maybe I'm wrong
[18:29] <bialix> from some presentation about git. There is 4 basic objects in git: blob, tree, commit and tag
[18:30]  * bialix has to go
[18:30]  * bialix waves
[18:30] <cdecarlo> I needed bzr+ssh to use a non-standard port so I created a ~/.bazaar/authenication.conf file and configured the proper settings but I'm not sure if it's reading the file? is there a way to be sure
[18:30] <jam> too late, I guess. but git *also* has "signed tags" which *do* have extra meta info
[18:35]  * ddaa goes back to his "getting rich by startup founding" business
[18:36] <dash> are you secretly paul graham?
[18:36] <ddaa> I wish.
[18:36] <ddaa> But if I were I would alread have solved the getting rich part.
[18:37] <ddaa> I would probably be working on some unlikely project such as "getting famous by changing how the world does rich text editing".
[18:37] <dash> yes please
[18:40] <ddaa> dash: for a couple millions euros, I'll happily abandon my current project and start working full time on this.
[18:40] <ddaa> one-time expense!
[18:47] <cdecarlo> my authentication.conf file isn't being accessed, is there some secret I don't know about?
[18:55] <Clint> why am i getting this, and how do i make it better?
[18:55] <Clint> bzr: ERROR: The method _generate_inventory is not supported on objects of type KnitPackRepository.
[18:56]  * ddaa watches helpless has texmacs is switch to git after the Savannah disaster.
[18:56]  * ddaa watches helpless as texmacs is switching to git after the Savannah disaster.
[18:57] <ddaa> No discussion, request for input, or consideration of alternatives.
[18:58] <ddaa> Clint: presumably because you are using some plugin that does not work with your version of bzr.
[18:59] <mattl> ddaa: we're moving to bzr after the Savannah problems, so any help you can give Clint on this would be very helpful.
[18:59] <Clint> ddaa: i will elaborate then. i did a bzr svn-import, got three "branches" from that, cloned them into subdirs of a --rich-root repo, and tried to join --reference them
[18:59] <Clint> the first worked, the second two give me that error
[19:00] <ddaa> Please paste the end of your .bzr.log in a pastebin
[19:01] <ddaa> I won't be able to solve it for you, but somebody else might.
[19:01] <ddaa> But I am questioning the usefulness of your doing join in this case. I doubt this will achieve the result you wish.
[19:01] <Clint> ddaa: http://paste.debian.net/37963/
[19:01] <Clint> okay, what am i misunderstanding?
[19:02] <ddaa> What do you want to achieve by joining the branches imported from svn?
[19:03] <Clint> ddaa: mattl wants to be able to clone the rootdir and get all three
[19:04] <ddaa> You should write a small script using the "bzr branches" command.
[19:04] <ddaa> from bzrtools
[19:05] <mattl> Clint: is this turning into a nightmare?
[19:05] <ddaa> Also, I bet the error you have comes from using 'join --reference', nested trees do not really work.
[19:06] <mattl> okay.
[19:06] <ddaa> They are very experimental stuff.
[19:06] <mattl> Clint: let's just have a stable tree, experimental tree and trunk tree.
[19:06] <mattl> 3 seperate ones
[19:07] <ddaa> They are the equivalent of svn externals. You could use the scmproj plugin for this functionality.
[19:07] <mattl> would everyone need that plugin to check out?
[19:07] <ddaa> only to checkout the combination
[19:08] <ddaa> you do not need it to use branches individually.
[19:09] <mattl> yeah, that's too much for people to have to do
[19:09] <mattl> individual branches then
[19:10] <Clint> done
[19:10] <ddaa> sorry about the inconvenience, but you cannot really do partial checkouts or whole repo checkouts (as you do with svn) with any DVCS
[19:11] <mattl> yeah, just getting my head around it all.
[19:11] <mattl> been in CVS/SVN for about a decade, and used bzr for er.. 48 hours
[19:12] <ddaa> hope you'll like it
[19:13] <mattl> lots of people telling us to use git and hg
[19:13] <mattl> but like bzr, our project is soon going to be a GNU project
[19:42] <beuno> mwhudson_, I'd like to unblock my LH reviews today if possible
[19:44] <jelmer> beuno: hi
[19:44] <beuno> jelmer, hi again
[19:48] <jelmer> beuno, if there's anything else I can do to unblock the foreign revid stuff, please let me know
[19:49] <beuno> jelmer, I think it's enough for me to tweak and land
[19:49] <beuno> will get to it at the end of my day
[19:49] <jelmer> beuno: sweet
[19:53] <Clint> is the rich-root format mature enough for sanity?
[19:55] <jelmer> Clint: Yeah, the 1.9-rich-root format is stable and mature
[19:55] <jelmer> Clint, the 2.0 format will be rich root only
[19:56] <Clint> jelmer: i seem to have trouble reading it with bzr 1.5
[19:56] <jelmer> Clint, well, yeah, bzr 1.5 doesn't support 1.9-rich-root
[19:56] <jelmer> Clint, it should support --rich-root-pack though, which was introduced in bzr 1.0
[19:57] <Clint> jelmer: okay
[19:58] <jelmer> Clint, why do you need rich roots though?
[19:59] <Clint> jelmer: bzr svn-import; am i able to discard the svn stuff after that to release the rich-root requirement?
[19:59] <jelmer> Clint, no, unfortunately not
[19:59]  * Clint sighs.
[19:59] <jelmer> Clint: The multiple formats thing is a mess :-( I would recommend using rich-root-pack if you're stuck with 1.5
[20:00] <jelmer> This'll all go away with 2.0, where we'll have a single format
[20:00] <jelmer> not that that helps you now
[20:00]  * Clint nods.
[20:01]  * SamB wonders how you can be stuck with 1.5 ... then remembers that it doesn't help if *you* have the latest release but none of the people who want to pull from you do ...
[20:01] <Clint> having different trouble with 1.13 instead of 1.5 as well
[20:03] <jelmer> SamB, lenny has 1.6
[20:03] <jelmer> s/1.6/1.5
[20:06] <Clint> (and 1.13 in backports.org)
[20:15] <SamB> jelmer: oh. you mean people actually run stable?
[20:15] <SamB> ... I suppose that might be the case :-(
[20:29] <abentley> jelmer: Please stop sending bzr-gtk merge directives with revision serializer format 9.
[20:31] <jelmer> abentley, Am I still doing that?
[20:32] <jelmer> I'm using the same version of bzr to send bzr-gtk merge requests as I use to send bzr.dev merge requests
[20:32] <abentley> jelmer: Yes, you're still doing that.
[20:32] <abentley> Your message re: "Use Revision.get_apparent_authors rather than deprecated
[20:32] <abentley>         Revision.get_apparent_author." does that.
[20:33] <abentley> jelmer: Are you storing your bzr-gtk stuff in the same repository as your bzr.dev stuff?
[20:34] <jelmer> abentley: Ah, no
[20:34] <jelmer> abentley, the bzr-gtk one is a development6 repository
[20:34] <jelmer> So I guess I should downgrade that to 1.9-rich-root
[20:34] <jelmer> abentley, thanks
[20:35] <abentley> jelmer: A real development6?  Or your new dev6 with RIO?
[20:35] <jelmer> abentley, no, a real development6 repository, at least that's what "bzr info" says
[20:35] <jelmer> ("Shared repository with trees (format: development6-rich-root)")
[20:36] <jelmer> hmm
[20:37] <jelmer> downgrading to 1.9-rich-root fails though, with an error about subtrees
[20:40] <abentley> jelmer: http://paste.ubuntu.com/187614/
[20:40] <abentley> jelmer: It's definitely in some wacky format.
[20:41] <jelmer> abentley: Hmm
[20:41] <jelmer> I haven't done anything special in this repository though, except for upgrading to --development6
[20:41] <jelmer> so I wonder how I ended up with the version 9 revision serializer
[20:42] <lamont> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototy
[20:42] <lamont> pes -g -O2 -g -Wall -O2 -fPIC -I/usr/include/python2.6 -c bzrlib/_patiencediff_c
[20:42] <lamont> .c -o /build/buildd/bzr-1.15/./build/temp.linux-armv5tel-2.6/bzrlib/_patiencedif
[20:42] <lamont> f_c.o
[20:42] <lamont> bzrlib/_patiencediff_c.c:28:20: error: Python.h: No such file or directory
[20:42] <lamont> interesting
[20:42] <lamont> bzr 1.15-1 on armel
[20:46] <jam> abentley, jelmer: bzrlib.chk_serializer.CHKSerializer.format_num == '9'
[20:46] <jam> At least, that is my guess
[20:46] <lamont> hrm.. probably something to do with build-depending on 2.4 and 2.5, while building with 2.6?
[20:46] <jelmer> jam: ah, yeah
[20:47] <jelmer> lamont, we depend on python-all-dev IIRC
[20:48] <lamont> Build-Depends: debhelper, cdbs, quilt, python, python2.5-dev, python2.4-dev, python-central, python-docutils, graphviz, zlib1g-dev
[20:49] <lamont> that's 1.15-1~bazaar1~hardy1 (speaking of which, what an ugly versio nmmber)
[20:50] <abentley> jam: It looks like it's not registered in serializer.format_registry.
[20:55] <cody-somerville> jelmer, any luck with that bzr-git bug? :)
[20:55] <jelmer> cody-somerville: It turned out to be less trivial than I had expected, not sure what's causing it exactly yet
[21:13] <jszakmeister> So, I think I found an interesting bug (or at least that's the way it appears).
[21:14] <jszakmeister> SvnRepository derives from ForeignRepository which derives from Repository
[21:14] <jszakmeister> SvnRepository inherits Repository's iter_inventories() method.
[21:14] <ddaa> Hey. Got a showstopper problem with trac-bzr.
[21:15] <jszakmeister> However, in Repository.iter_inventories() it's calling self._iter_inventories(), which is supposed to call SvnRepository._iter_inventories(), but appears to be calling Repository._iter_inventories() instead.
[21:16] <ddaa> Not sure what's going on, but trac crashes when trying to compare a offset-naive datetime with an offset-aware datetime.
[21:16] <ddaa> When trying to build the list of change dates.
[21:17] <ddaa> Using bzr 1.15, Trac 0.11.4, and trac-bzr tip from launchpad.
[21:17] <jszakmeister> It's like the method lookup is failing to find SvnRepositories _iter_inventories method.
[21:18] <jszakmeister> It's very weird.
[21:19] <ddaa> jszakmeister: usually, when I get this impression with python code, I find that I made myself confused. I suggest you look at it again tomorrow with a fresh mind.
[21:20] <jszakmeister> Oh, no I'm not confused.  I dumped information from the code object... it's calling the wrong method.
[21:20] <ddaa> Python does not do weird mysterious thing, and bzr and bzr-svn do not do inscrutable voodoo hack. It's almost certainly doing the obvious thing.
[21:20] <jelmer> jszakmeister, that bugs already been fixed
[21:20] <jszakmeister> jelmer: the one I filed or a different one?
[21:21] <jelmer> jszakmeister, the one you filed
[21:21] <jelmer> its fixed in the main bzr-svn branch
[21:21] <jszakmeister> I saw that.  I pulled your branch, and now I get a failure elsewhere.
[21:23] <jszakmeister> I'm getting this now: 'NoneType' object has no attribute 'get_record_stream'
[21:24] <jszakmeister> And it appears it's not entering the right _iter_inventories() method. :-(
[21:26] <jelmer> jszakmeister, can you pastebin the traceback?
[21:26] <jszakmeister> Sure can.
[21:26] <jelmer> jszakmeister, qbrowse works fine for me with the change fwiw
[21:28] <jszakmeister> http://pastebin.com/m4d9df712
[21:28] <jszakmeister> jelmer: are you running from a branch?  I've been trying to get it to work against a remote repository.
[21:28] <jelmer> jszakmeister, against a remote repository
[21:29] <jszakmeister> Weird.  I wonder what's up with my setup then?
[21:29] <jelmer> bzr-svn 3030?
[21:29] <jam> abentley: ping
[21:30] <jam> Something is a bit funny with the codereview preview
[21:30] <jam> namely: https://code.edge.launchpad.net/~jameinel/bzr/1.16-simple-win32/+merge/6984
[21:30] <abentley> jam: pong
[21:30] <jam> It is including vincent's changes
[21:30] <jam> (Perhaps bzr trunk was not up to date when it generated the diff?)
[21:30] <jam> I don't see a way to tell code-review to regenerate the diff
[21:31] <jelmer> jszakmeister, ^
[21:31] <jszakmeister> jelmer: 3029
[21:31] <jszakmeister> lemme pull again
[21:31] <abentley> jam: Code Review is branch-oriented.  If your branch is based on Vincent's, it thinks you're trying to merge the whole thing.
[21:31] <jelmer> jszakmeister, 3029 should also include the fix
[21:31] <jam> abentley: there is a single revision from my branch that isn't in trunk
[21:32] <jam> it was only based on vincent's in that I branched from bzr.dev
[21:32] <jelmer> jszakmeister, it looks like you're running an old version somehow
[21:32] <jam> it even gets that right in the 'list of revisions' to be merged
[21:32] <jam> My guess is that I submitted the request
[21:32] <jam> inbetween the time that the mirroring script updated lp:bzr from http://bazaar-vcs.org/bzr/bzr.dev
[21:32] <jam> and the time vincent landed his patch
[21:33] <jszakmeister> jelmer: I don't believe so... I can see my debug lines in the output
[21:33] <jszakmeister> I'll check and see if something else is being picked up though.
[21:33] <abentley> jam: I assume you're talking about the review diff, not the preview diff.
[21:34] <jam> abentley: sure 'Review diff'
[21:34] <abentley> jam: Did you use bzr send? Code Review will take your review diff out of your merge directive verbatim.
[21:34] <jam> I don't know what the difference is, specifically
[21:34] <jam> abentley: no, I used the web
[21:34] <jam> "propose for merge"
[21:35] <jszakmeister> jelmer: I think you're right.  I have my soft link set up wrong.
[21:35] <abentley> jam: A review diff is a diff against the LCA of the tip and the submit branch trunk, as generated by "bzr send"
[21:35] <abentley> jam: it's shown at the bottom of the merge proposal.
[21:36] <abentley> jam: a preview diff is a diff of the submit branch tip against a submit branch tip with the source branch tip merged into it.
[21:36] <jszakmeister> You rock jelmer!
[21:37] <abentley> jam: It is generated by MAD and is accessible from the "Diff against target" link.
[21:37] <jszakmeister> I though I had another debug statement in bzr-svn, but it was in bzrlib.  The one I had in there *wasn't* being printed.
[21:37] <jszakmeister> Thank you sir!
[21:37] <jelmer> jszakmeister, np
[21:37] <abentley> jam: I suspect what happened here is that your review diff was generated before lp's mirror of bzr.dev was updated.
[21:38] <jam> abentley: my assumption as well
[21:38] <jam> I filed bug #383346 about it
[21:39] <abentley> jam: You didn't file a bug about it being wrong?
[21:39] <jszakmeister> No off to figure out how to teach qbzr not to look at the local repository for revision info, if you happen to be trying to browse an unrelated remote repo.
[21:39] <jam> abentley: well that bug mentions that it is wrong, and probably due to the race condition
[21:39] <jam> you can change the subject to whatever fits best in your mind
[21:40] <abentley> jam: I think it's more important to get it right than to be able to regenerate it.
[21:40] <jam> abentley: I don't think you can avoid the race condition
[21:40] <jam> Though also in the bug I mentioned the possiblity of detecting it after the fact
[21:40] <jam> (revs that were requested for review show up in the merge target)
[21:40] <abentley> jam: We can at least perform a mirror immediately before generating the diff.
[21:41] <ddaa> FFS, how can the datetime handling in trac-bzr even work with trace 0.11?
[21:41] <jam> abentley: that would be possible, but still leaves open the issues with landing pieces of a multi-phase patch
[21:41] <ddaa> It's out and out braindead. I cannot imagine how it could have passed even superficial testing.
[21:42]  * ddaa blames jelmer
[21:42] <ddaa> actually, bzr blames jelmer
[21:43] <abentley> jam: Until there's proper support for base revisions or dependent branches, you can use bzr send for that.
[21:43] <jam> abentley: or you could just detect that the set of revisions for review changed...
[21:44] <jam> or have something easier than "Resubmit" to regenerate the diff
[21:44] <abentley> jam: No, we should not.  People who are reviewing something should be reviewing the same thing.  Regenerating the diff breaks that, and makes people review the integration, not the change.
[21:45] <ddaa> jelmer: dude, revision 60 http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/revision/60#tracbzr/backend.py
[21:45] <ddaa> by default, timestamps are offset-naive, not utc!
[21:46] <ddaa> jelmer: what were you trying to fix when you made this change?
[21:46] <jelmer> ddaa: argh, not sure how that got in
[21:46] <ddaa> I'll try reverting that in my trac, see if that makes it happier.
[21:53] <ddaa> jelmer: that fixes it for me.
[21:53] <ddaa> bzr merge -r60..59
[21:53] <ddaa> jelmer: will you patch mainline for me?
[21:55] <dash> oh man =/
[21:55] <dash> i am getting an exciting error message with bzr 1.15
[21:55] <dash> http://paste2.org/p/243728
[21:56] <abentley> dash: It's the loom plugin being out of date.
[21:56] <dash> aah.
[21:57] <ddaa> abentley: darn, I was hoping it was bzr-svn so I could blame jelmer again ;)
[21:57] <abentley> ddaa: We could blame jelmer because bzr-svn doesn't auto-update bzr-loom >:)
[21:58] <ddaa> abentley: Deal!
[21:58] <ddaa> And next, we'll blame jelmer for war in Palestine.
[22:06] <dash> so i guess i get to try to fix it :)
[22:07] <fullermd> Oh look, a big long thread of ranting on pgsql-hackers about git's lacking co [--lightweight]...
[22:09] <jelmer> ddaa: You're welcome to do that yourself, we need more trac-bzr hackers :-)
[22:09] <jelmer> ddaa: Otherwise, I'm happy to do it
[22:12] <ddaa> jelmer: okay, sent my team application, approve it and I'll fix your mainline.
[22:13] <jelmer> ddaa, welcome
[22:17] <fullermd> I really hate launchpad sometimes.
[22:19] <ddaa> jelmer: ur maine-coon r a fixed.
[22:19] <ddaa> I mean mainline, not maine-coon sorry. I blame my inner lolcat.
[22:20] <jelmer> ddaa, kthx!
[22:20] <jam> thumper: ping
[22:20] <thumper> jam: just on a call right now
[22:21] <jam> thumper: np, just though I'd mention that my patches for gc stacking are up for review
[22:22] <thumper> jam: excellent, thanks
[22:22] <jelmer> jam: I'm wondering if maybe some of my later changes to bencode had an impact on performance
[22:22] <jam> jelmer: I should have been using the very lastest version of your code for my testing
[22:22] <jelmer> jam: I mean negative impact
[22:23] <jam> which changes?
[22:23] <jam> stuff like strtol?
[22:23] <jam> instead of PyLong_FromString?
[22:23] <jelmer> jam: The ones after I put up the patch for review
[22:23] <jelmer> jam, yeah, that sort of thing
[22:24] <jelmer> well, I would be surprised if strtol would be slower than PyLong_FromString
[22:24] <jelmer> but I'm a bit surprised with the current performance given what I saw earlier
[22:33] <jml> so, how does one actually _use_ py_memory_dump?
[22:34] <LarstiQ> good question, a colleague of mine used it, I should look at how he did that
[22:35]  * LarstiQ goes to sleep
[22:35] <ddaa> jelmer: do you know why all the revision names are urlencoded?
[22:35] <jam> jml: from memory_dump import scanner; scanner.dump_gc_objects('filename.txt')
[22:35] <jam> from memory_dump import loader
[22:35] <jam> m = loader.load('filename.txt')
[22:36] <jam> etc
[22:36] <ddaa> it's very annoying, because it encodes 1. the colon in special revision names 2. the slash name of branches in subdirs.
[22:36] <jml> jam: thanks.
[22:36] <ddaa> jelmer: I'd hack it away, but I'm afraid of breaking older trac releases.
[22:36] <jam> jml: you can do the load in a separate process, in case you are already at, you know, 4.5GB of resident memory :)
[22:36] <jam> though that dump will be a bit painful regardless
[22:36] <jelmer> ddaa: It's a dvcs, use a separate branch :-)
[22:37] <jelmer> the only other release we worry about is 0.10, and the main difference in that is the datetime stuff
[22:48] <jelmer> abentley, is bundlebuggy running bzr.dev ? if so, any chance you can update it? The serializer 9 registration patch has landed
[22:54] <abentley> jelmer: No, it's not.
[22:54] <jelmer> abentley, is there some way I can force the format of the serializer
[22:54] <jelmer> used in merge directives?
[22:55] <abentley> jelmer: The only way to force the format of the serializer is to change the repository format.  Bundle format 4 copies this data verbatim.
[22:56] <jelmer> abentley: okay, I'll fall back to manual patches for now then. Thanks
[22:56] <abentley> jelmer: I'll upgrade BB to 1.16 when it comes out.
[22:57] <salgado> hi there.  is it possible to recover from a corrupted .bzr/checkout/dirstate ?
[22:57] <Peng_> salgado: You could just nuke .bzr/checkout and run "bzr checkout".
[22:57] <salgado> all of a sudden one of my branches is giving me this whenever I do 'bzr <anything>': bzr: ERROR: The dirstate file (DirState(u'/home/salgado/devel/launchpad/mainline/.bzr/checkout/dirstate')) appears to be corrupt: trailing garbage: 'AAATMUexj0JHsY9'
[22:57] <jelmer> abentley: Cool. I can survive with plain patches for a month or so.
[22:57] <Peng_> salgado: (Um, that's assuming you're using a regular branch, not a checkout or something.)
[22:58] <salgado> Peng, yes, this is supposed to be a regular branch.  will try that, thanks
[23:06] <ddaa> jelmer: I savagely removed all the urllib.quote/unquote functionality, and it does not appear to break anything for me
[23:06] <ddaa> while at the same time fixing my problems
[23:06] <jelmer> ddaa, Yeah, the code badly needs a cleanup
[23:06] <jelmer> ddaa, I've mostly been trying to keep it running for bitlbee/ctrlproxy
[23:06] <ddaa> the ctrlproxy one is borked
[23:07] <jelmer> yeah, I haven't had time for trac-bzr recently
[23:07] <ddaa> I don't have time either really.
[23:07] <jelmer> unfortunately there aren't a lot of alternatives to trac
[23:07] <jelmer> redmine is nice but it's ruby
[23:07] <jelmer> and I don't know ruby
[23:08] <ddaa> I dunno either trac or redmine
[23:08] <jfroy> jelmer: I'm having a weird problem with rebase
[23:08] <ddaa> I'll upload my patch in a branch, and I'll let the crowd decide.
[23:09] <jelmer> ddaa: did you try running the testsuite?
[23:09] <ddaa> nope
[23:09] <jelmer> jfroy, ?
[23:09] <jfroy> I try to pull from a branch (remote svn branch), get a notice that the branches have diverged.
[23:09] <jfroy> I try to rebase on to that same URL, and that does nothing
[23:09] <jfroy> unless I forgot how to rebase...
[23:09] <ddaa> jelmer: what's the magic command to run the test suite?
[23:09] <jelmer> jfroy, are the urls for pull and rebase the same?
[23:10] <jfroy> yes
[23:10] <jelmer> ddaa: "trial tracbzr" / "nosetests tracbzr"
[23:11] <ddaa> jelmer: it fails horribly
[23:12] <ddaa> but I cannot be bothered to fix it right now
[23:12] <jelmer> ddaa: did you verify that % and : in revision ids still work after removing the urllib.quote/unquote sutff?
[23:12] <jelmer> vila, ping
[23:12] <ddaa> jelmer: lol
[23:12] <ddaa> I'd bet they don't
[23:13] <ddaa> but I specifically want "current:" and friends not to be escaped
[23:13] <ddaa> and I do not have any such revision handy
[23:14] <jfroy> it prints "Started 2 unique searchers for 8 unique revisions" in the trace then exits with 0
[23:15] <jfroy> however bzr missing says I'm missing 3 revisions
[23:15] <jfroy> I could try rebase against a fresh local branch of the remote branch
[23:15] <jelmer> jfroy, and missing also says that you've got extra revisions?
[23:16] <jfroy> correct, 1 extra
[23:16] <jfroy> which is actually a merge revision
[23:17] <jfroy> yeah, rebase against a local copy of the remote branch yields the same result
[23:17] <jfroy> urg, seems I'm hosed :/
[23:18] <jelmer> jfroy, rebase skips merges
[23:18] <jelmer> jfroy, known bug
[23:18] <jfroy> but shouldn't I pick the 3 revisions I am missing from the remote branch, then rebase the merge on top of that new history?
[23:18] <jfroy> *shouldn't it
[23:18] <jelmer> jfroy, it's a known bug, it should handle the merge
[23:18] <jfroy> I see
[23:18] <jfroy> gotcha
[23:18] <jfroy> mmm
[23:19] <jfroy> I guess I can uncommit
[23:19] <jfroy> the merge was clean, easy to re-do
[23:19] <jfroy> pretty serious bug though :/
[23:20] <jfroy> mmm
[23:20] <jelmer> jfroy, even when it will support merges, they'd be quite prone to conflicts
[23:20] <jfroy> uncommit actually puts merges back to pending?
[23:21] <jfroy> yeah I guess it would....
[23:21] <jelmer> yeah, it only changes the branch
[23:21] <jfroy> need to revert it out
[23:21] <jfroy> and then revert --forget-merges (why can't you do both at the same time...)
[23:23] <mwhudson_> i think i want to refactor how loggerhead serves branch content
[23:23] <jfroy> and well, would it be that prone to conflicts if the merged branch was orthogonal?
[23:24] <jfroy> mmmm
[23:24] <jfroy> bzr merge -r foo.. doesn't seem to be doing what I want
[23:25] <jfroy> I thought this would mean "cherrypick from revisions foo to tip of branch being merged"
[23:25] <jelmer> jfroy, bzr revert with no arguments does both
[23:25] <jfroy> but it seems to be picking a lot more revisions than that
[23:25] <Peng_> mwhudson_: Eh?
[23:25] <jelmer> mwhudson_, ?
[23:25] <jfroy> jelmer: oh?
[23:25] <jelmer> mwhudson_, into a separate loggerhead.app thing?
[23:25] <jfroy> that's not clear
[23:26] <mwhudson_> Peng_: basically, i think we should always traverse to the branch, then see if the request is for .bzr
[23:26] <mwhudson_> though i guess that doesn't work for repositories
[23:26] <mwhudson_> '/.bzr/' in PATH_INFO is a bit gross
[23:29] <jfroy> nevermind, bzr was sane, I was not :/
[23:41] <ddaa> jelmer: here you have my shameless hack.
[23:41] <ddaa> https://code.launchpad.net/~ddaa/trac-bzr/trac-bzr.ddaa
[23:42] <ddaa> Mh... crap committer name... I'll fix that.
[23:56] <dash> bloarg
[23:56] <dash> so today my task is to merge some code into an svn repo that was copied out of it a month ago, into a separate svn repo
[23:56] <dash> and hacked upon
[23:57] <dash> i've got bzr branches of both now via bzr-svn
[23:57] <dash> i wonder if it makes sense to try to replay any of the history