[12:11] <luks> asabil, NfNitLoop: http://rafb.net/p/6eZRXW13.html :)
[12:15] <james_w> luks: nice work.
[12:32] <igc> morning all
[12:50] <asabil> hmm, luks nice but maybe having it per branch can be more handy ?
[12:52] <luks> well, I was just playing, it's nothing serious. per-branch bookmarks wouldn't be so easy as these global ones
[12:53] <luks> http://rafb.net/p/H4YUxG13.html if you want more complete version
[12:56] <asabil> that;s awesome already :)
[12:58] <asabil> I was also wondering if there any way to attach some kind of metadata to a branch
[12:58] <asabil> I was hacking on loggerhead a bit
[12:59] <asabil> and what I did was to add a branch-info file inside each branch
[12:59] <asabil> and that file contains variables like description = "branch descriptio"
[12:59] <asabil> this is particularely useful for auto discovered branches
[01:00] <asabil> is there any clean way to implement this feature ?
[01:02] <abentley> asabil: I have implemented a VCS frontend that used per-branch aliases, and I found it had poor usability.
[01:03] <abentley> Because you were never sure what aliases were set where.
[01:03] <asabil> hmmm
[01:03] <abentley> And which ones were global, versus local.
[01:03] <asabil> I don't think that global aliases are useful
[01:03] <Odd_Bloke> I think it would only work if they were either all global or all local...
[01:03] <abentley> They're very useful.
[01:04] <asabil> I agree Odd_Bloke
[01:04] <asabil> then maybe the ablity to specify shorthands for servers ?
[01:04] <abentley> Most of my work is done against two or three branches.  Having shorthands would be quite nice.
[01:05] <asabil> then maybe the ability to say
[01:05] <asabil> myserv/bzr/branch.x
[01:05] <abentley> Well, just set it up so that you can append to the alias.
[01:05] <asabil> where myserv is a shorthand
[01:06] <abentley> So you can alias example.com/bzr to myserv, and just specify "myserv/branch.x"
[01:06] <Odd_Bloke> I know that git have some sort of aliasing because I was reading a blog post about it.  No doubt that'll have disappeared into the depths of reddit by now.
[01:07] <abentley> As for per-branch descriptions, I think it would be reasonable to stick them in branch.conf.  The branch nick is already there.
[01:07] <Odd_Bloke> The example they used would have me specifying, for example, 'abentley' to point to your branch so if I want to pull your changes I literally type 'git pull abentley'.
[01:07] <asabil> abentley: where is branch.conf ?
[01:07] <abentley> Ow!
[01:07] <abentley> asabil: in .bzr/branch/
[01:07] <Odd_Bloke> I think that then pulls the changes to a local cache which you can then treat as a branch.
[01:07] <asabil> ok thanks abentley :)
[01:08] <Odd_Bloke> So I was thinking, if there were a smart-server or something running at the other end, it generates a merge-directive and sends you that.
[01:08] <Odd_Bloke> But that was just an idea that flitted through my mind at some point.
[01:10] <Odd_Bloke> Quite hard to form exactly what the use case for that would be, because I don't do any development that's distributed to that extent.
[01:11] <abentley> The smart server can take a more direct approach than a merge directive.
[01:11] <asabil> hmmm, I think it can be a very nice feature
[01:13] <poolie__> hello
[01:18] <lifeless> poolie: should I do debs of the rc2
[01:18] <poolie> yes, please
[01:20] <poolie> lifeless, so can we expect 0.90final to go into gutsy? how about rc2?
[01:20] <lifeless> I need to do the request as per discussion with mdz
[01:20] <lifeless> that I cc'd you on
[01:21] <poolie> k
[01:21] <lifeless> bzr-svn is now in debian
[01:21] <lifeless> so I should have the request put up today
[01:40] <lifeless> abentley: I presume bzrtools 0.91 is imminent ?
[01:41] <lifeless> jelmer: bzr-gtk 0.91 coming soon
[01:42] <abentley> Yeah, I'll get that out soon.
[01:43] <lifeless> abentley: with nested trees, does the parent entry file id need to match the subtree root id ?
[01:43] <abentley> Yes, that's the current design.
[01:45] <lifeless> interestingly that isn't enforced by commit
[01:52] <lifeless> ok, bug fixed in fetch for subtrees.
[01:54] <lifeless> poolie: bzr.dev still has all the 0.91 changes in its in development section
[01:55] <lifeless> poolie: this seems wrong ?
[01:55] <poolie> i
[01:55] <poolie> i haven't committed a change to bump the version
[01:55] <poolie> should do that now
[01:55] <poolie> lifeless, i see gutsy claims to have 0.90 already
[01:56] <poolie> or at least '0.90-1'
[01:56] <lifeless> I thought the version bump commit was in the release process?
[01:57] <lifeless> yes, 0.90 has reached gutsy
[01:57] <poolie> it is, i haven't finished the process though
[01:57] <lifeless> I think mdz has got someone to do the sync I asked for anyhow
[01:58] <poolie> my point is, that seems to be the wrong version number, should it not be 0.90rc1?
[01:58] <lifeless> no
[01:58] <lifeless> 0.90 got released remember
[01:58] <lifeless> you're working on 0.91
[01:59] <poolie> oh right
[01:59] <poolie> just coincidental
[02:00] <lifeless> if you count a missing digit :)
[02:01] <jelmer> lifeless: Will do so by the end of the week
[02:01] <lifeless> jelmer: I can't really upload debs of the 0.91 rc's without fixed plugins
[02:01] <jelmer> lifeless: I'm considering stopping doing synchronized releases
[02:02] <jelmer> lifeless: I'm a bit busy at the moment, can't really put the effort into testing bzr-gtk at the moment
[02:02] <lifeless> jelmer: perhaps you could share the responsibility
[02:02] <jelmer> lifeless: I've been trying to get Szilvester to do a release for the last couple of releases :-)
[02:03] <jelmer> lifeless: If you feel like doing it, you're more than welcome
[02:03] <jelmer> lifeless: btw, thanks for uploading 0.4.2
[02:03] <lifeless> well
[02:03] <lifeless> is there any reason not to just say 'its released' ?
[02:04] <jelmer> The only two things in it I've used since I did the previous release are viz and gcommit
[02:04] <jelmer> but there has been a lot going on, merged by other people
[02:05] <jelmer> so I don't really feel comfortable releasing it without testing, especially since there are so little unit tests.
[02:07] <jelmer> another option would be to simply upload a copy of bzr-gtk 0.90 but mark it as being compatible with 0.91
[02:08] <jelmer> because none of the important API's have changed
[02:10] <abentley> jelmer: You're not concerned about Branch.last_revision / WorkingTree.last_revision?
[02:11] <jelmer> abentley: ah, I wasn't aware of that..
[02:12] <lifeless> abentley: whats happened to those apis ?
[02:13] <abentley> They now return NULL_REVISION instead of None
[02:13] <lifeless> ah right
[02:14] <lifeless> poolie: that bug I found last night? I've done a regression test for it and mailed to the list right now
[02:14] <lifeless> I think this is critical enough for 0.91
[02:14] <poolie> thx
[02:17] <lifeless> jelmer: I think you should ask for help on the list
[02:17] <lifeless> jelmer: you maintain two plugins that are version locked that I know of
[02:18] <jelmer> lifeless: bzr-svn isn't version locked - it contains a list of versions it knows it is compatible with and will warn if it sees an unknown version but will still work
[02:18] <lifeless> jelmer: and its bad for bzr to have mismatches during release; there is a week of freeze for plugin authors to know there are no changes incoming that will bust api's
[02:19] <lifeless> jelmer: warning confuses and infuriates users
[02:19] <jelmer> lifeless: there have been too many api changes to not have those warnings in
[02:20] <jelmer> lifeless: for bzr-gtk I can see a point in not having the warnings - that's why I was suggesting desynchronizing the releases
[02:20] <lifeless> jelmer: well, the warnings are not useful when a user is using the plugin and no newer release has happened
[02:20] <lifeless> I'd argue that they *are* useful when a user experiences a bug
[02:21] <lifeless> and reporting plugin versions in bzr's error output supercedes that warning IMO, because you, the author, will be able to tell
[02:21] <jelmer> lifeless: so far, bzr has broken bzr-svn every release
[02:22] <lifeless> ok
[02:22] <lifeless> well, its your domain
[02:22] <jelmer> I'm also confident enough to do a bzr-svn release, as I'm the sole maintainer of the main branch and it's very well tested
[02:24] <jelmer> bzr-gtk has almost no tests, several different people committing to mainline, no review, out-of-date NEWS...
[02:24] <jelmer> so doing a release for it is more work
[02:25] <lifeless> can you change your process
[02:25] <lifeless> for instance, set policy like bzr does for NEWS
[02:25] <lifeless> require review like bzr does - perhaps ask Aaron to setup a prefix like [bzr-gtk/MERGE]  for a different bundle buggy instance?
[02:26] <abentley> lifeless: I'd agree with Jelmer; before plugin authors will remove the warnings, they need to trust Bazaar not to break the API.
[02:26] <igc> lifeless: review sent to the list on 'knit text add reductions'
[02:28] <igc> lifeless: I'll send through some more feedback on http://bundlebuggy.aaronbentley.com/request/%3C1189034650.27751.10.camel@lifeless-64%3E as well - I'd really like to see this one land soon
[02:28] <lifeless> which is that
[02:29] <igc> the 'move stuff into CommitBuilder' one
[02:29] <igc> (0.92 targetted)
[02:29] <lifeless> right
[02:29] <lifeless> that needs an update
[02:29] <lifeless> massive bugs that I fixed last night
[02:29] <igc> :-)
[02:30] <igc> I saw the changes in your commit branch
[02:30] <jelmer> lifeless: we did talk about bundle buggy at some point, but never got around to it. I agree it would be a good idea to use it for bzr-gtk.
[02:31] <igc> lifeless: with path_content_summary, why did you not make file-id a parameter?
[02:31] <lifeless> igc: because it has no use for one
[02:31] <abentley> jelmer: I'd be happy to chat about BB at some point.
[02:31] <lifeless> its unneeded overhead to pass one in
[02:32] <igc> won't same trees benefit from it??
[02:32] <igc> s/same/some/
[02:32] <lifeless> 'some' trees?
[02:32] <lifeless> if you are doing a commit from a tree that has no path orientated data structure - e.g. committing from something like a revision tree.
[02:32] <lifeless> but yagni
[02:33] <lifeless> working trees have disk
[02:33] <jroes> hey guys, anyone else think the sftp example at http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html is a bit misleading?  on a default setup, you need to specify the absolute path to the dir you want to push your revisions to (I doubt most user accounts have write access to /)
[02:33] <lifeless> memory trees have a transport with path data
[02:33] <jelmer> abentley: Szilveszter and have been talking about setting up a separate copy of it somewhere, but if it's possible to have one up on the main site, that'd be awesome
[02:33] <jdub> yo folks
[02:34] <jelmer> hi jdub
[02:34] <igc> I was thinking about workingtree4 where lookup by id would save a path -> id conversion from the little I know of that code
[02:34] <jdub> lovely to see bzr so versionly close to 1.0 8)
[02:34] <lifeless> igc: the api does not use id at all
[02:34] <lifeless> igc: so why would it do a path->id conversion at all ?
[02:35] <abentley> Jelmer: in theory, I'd be happy to.  But I'm a bit worried about performance on that machine.
[02:35] <jdub> have an svn-upgrade issue to ask about...
[02:35] <jdub> $ bzr svn-upgrade
[02:35] <jdub> Using saved location: http://svn.automattic.com/wordpress-mu/trunk
[02:35] <jdub> bzr: ERROR: Unable to import bzr-rebase (required for svn-upgrade support): No module named rebase.rebase
[02:35] <jdub> 
[02:37] <igc> lifeless: path_content_summary() in workingtree_4.py has an implementation for DirStateRevisionTree but not WorkingTree4. Just thinking out loud about a potential implementation ...
[02:37] <lifeless> igc: I really don't understand what you are thinking about
[02:37] <jelmer> abentley: ah, ok
[02:37] <lifeless> igc: what fileid keyed data are you thinking it would want?
[02:38] <jelmer> jdub: Do you have trunk of bzr-rebase installed as ~/.bazaar/plugins/rebase ?
[02:38] <igc> sha1. I really need to know that code better. I plan to look at it today so I can ask more intelligent questions.
[02:38] <lifeless> igc: sha1 is keyed by path
[02:38] <jdub> jelmer: no plugins installed -- bummer
[02:38] <igc> ok - that's good to know
[02:39] <lifeless> igc: if there are multiple fileids at a given path, only one of them will be present in tree 0 - the working tree
[02:39] <lifeless> so thats the one to use
[02:39] <jelmer> jdub: trunk of bzr-rebase is at http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/
[02:39] <jelmer> though if you have no local changes, it's probably faster to just 'bzr branch' from scratch rather than svn-upgrade
[02:39] <lifeless> jelmer: aptitude install bzr-rebase
[02:39] <jdub> jelmer: so the new bzr-svn breaks svn but bzr doesn't include the bits to fix it yet? :-)
[02:39] <lifeless> jdub: its in a separate plugin, which bzr-svn recommends
[02:40] <jdub> lifeless: hrm, not available to me yet
[02:41] <lifeless> hmm, whoever synced bzr-svn missed the new recommends
[02:41] <lifeless> jelmer: *why* doesn't it depend on bzr-rebase?
[02:41] <elmo> in 10 minutes escudero.canonical.com, the machine hosting www.bazaar-vcs.org, will be shut down for some necessary maintenance, ETD is 5 minutes
[02:42] <jelmer> lifeless: it's only needed for svn-upgrade
[02:42] <lifeless> thanks elmo
[02:42] <lifeless> jelmer: all the same
[02:42] <lifeless> :)
[02:42] <pygi> lifeless, sync pickups entire package, so nobody *missed* it, the debian maintainer did it
[02:42] <pygi> or am I missing something? :)
[02:42] <jdub> i guess if you don't forsee svn-upgrade being used regularly, you'd only need bzr-rebase on these odd occasions
[02:43] <jelmer> lifeless: svn-upgrade is only necessary for those upgrading from bzr-svn 0.3
[02:43] <lifeless> pygi: I think you are missing several emails, irc discussion and the debian maintainer has done nothing wrong
[02:43] <lifeless> jelmer: I see this as a purity vs do-the-right-thing situation
[02:44] <igc> lifeless: more feedback on the 'knit text' stuff - 32 unit tests are failing because of parameter count mismatches. Do you want a pastebin or email?
[02:44] <jdub> but with the break in this upgrade, having all the tools available would make users less surprised
[02:44] <lifeless> igc: its all fixed here
[02:44] <lifeless> igc: like I said, massive fixes needed
[02:44] <igc> cool
[02:44] <lifeless> jdub: I'm with you
[02:45] <jdub> btw, the message i get from bzr merge wouldn't hint me towards svn-upgrade
[02:45] <igc> lifeless: just to be clear, I'm talking about the patch I reviewed this morning (random_id etc.), not the other one
[02:46] <lifeless> revno: 2810
[02:46] <lifeless> committer: Robert Collins <robertc@robertcollins.net>
[02:46] <lifeless> branch nick: knits
[02:46] <lifeless> timestamp: Tue 2007-09-11 14:05:11 +1000
[02:46] <lifeless> message:
[02:46] <lifeless>   Unbreak weaves.
[02:48] <lifeless> poolie: you know you could have just changed the product rather than marking invalid and filing a new task
[02:48] <lifeless> FWIW
[02:49] <abentley> lifeless: That's a humdinger of a bug you found with fileids_altered_by
[02:49] <lifeless> abentley: yah
[02:50] <lifeless> abentley: totally by accident too
[02:51] <abentley> Such an ugly hack, that code.  I'm surprised we haven't found more bugs.
[02:52] <elmo> (escudero / www.bazaar-vcs.org is back)
[02:52] <lifeless> abentley: well its reasonably well tested; the glitch here was no direct testing of nested tree fetching
[02:55] <poolie> lifeless, i din't realize it was possible to change the product of a task
[02:55] <lifeless> oh
[02:55] <jelmer> lifeless: well, it's a bit more hackish than that... bzr-rebase 0.2 isn't out yet.
[02:55] <lifeless> so click on the thing to expand it
[02:56] <poolie> ah, i think i saw the greyed out text as "you can't change this"
[02:56] <lifeless> and there is a field
[02:56] <lifeless> you can edit it
[02:56] <jdub> lifeless: whoa, that crazy stuff still afflicts launchpad?
[02:56] <jelmer> lifeless: which I admit is ugly
[02:56] <lifeless> jelmer: seems difficult for users:)
[02:58] <jelmer> lifeless: trunk works fine for bzr-svn, but has two bugs that block it from being uploaded as an official bzr-rebase release.
[03:01] <abentley> poolie: someone mailed me saying they want to put bzrlib/patches.py into the standard library.  I wrote all but 14 lines, but Canonical has joint copyright.  Are you in favour of relicensing it in principle?
[03:03] <jdub> elmo: what's the appropriate way to request ubuntu.com alias changes?
[03:03] <lifeless> jelmer: still difficult for users to have to choose between 'working bzr-rebase' and 'working bzr svn-upgrade'
[03:03] <jamesh> jelmer: ran into a crasher bug with bzr-svn.  I've filed a bug with all the information I have, but I'd be happy to provide more on request
[03:03] <jamesh> "svn_path_basename: Assertion `is_canonical(path, len)' failed." then a segfault
[03:03] <elmo> jdub: outside of the LP-automagic ones?  rt@ubuntu.com
[03:04] <elmo> jdub: (as in, send a mail to that address)
[03:04] <jdub> yeah
[03:04] <jelmer> jamesh: where did you file it? The latest bug report from you I have here is from 25 october last year
[03:04] <jamesh> jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/139020
[03:04] <Ubotu> Launchpad bug 139020 in bzr-svn "assertion error segfault when branching from svn+http://svn.effbot.python-hosting.com" [Undecided,New] 
[03:05] <jdub> elmo: i think my jeff.waugh is not LP-automagic (how do they work?)
[03:05] <elmo> jdub: -> privmsg
[03:05] <jamesh> jelmer: the email will probably go out in 5 minutes (LP waits a little to batch changes)
[03:05] <jdub> sorry :0
[03:05] <jdub> :)
[03:05] <jelmer> jamesh: ah, 3 minutes ago.. that explains it :-)
[03:05] <elmo> it's okay, we're just off topic
[03:06] <poolie> abentley, i don't see any problem with that
[03:06] <jamesh> jelmer: I managed to pull out a Python stack trace from the segfault if that helps ...
[03:07] <jelmer> jamesh: seems I can reproduce it here
[03:08] <jamesh> might just be a weird SVN server
[03:08] <abentley> poolie:Okay, I'll mail you something more formal if/when we get there.
[03:08] <jamesh> although (assertion errors seem unexpected)
[03:09] <jelmer> lifeless: yes, that's true
[03:09] <jelmer> jamesh: the subversion library asserts on invalid paths
[03:09] <abentley> jdub: Oh, hi Jeff.
[03:12] <jdub> hey abentley
[03:12] <abentley> Next time you're in Toronto, give a shout.
[03:12] <jdub> !
[03:12] <jdub> i'm in toronto atm!
[03:13] <abentley> Dude!
[03:13] <jdub> <- asshat.
[03:13] <jdub> i am in sydney
[03:13] <jdub> which looks a little bit like toronto
[03:13] <jdub> it is very sprawly
[03:13] <jamesh> concrete fences around the CBD?
[03:13] <abentley> PyGTA showed me pics of your visit.
[03:13] <jdub> but our security is VERY NICE! HIGH FIVE!
[03:13] <lifeless> jelmer: bzr-rebase isn't in debian even is it ?
[03:13] <jdub> jamesh: bah!
[03:14] <jdub> pygta?
[03:14] <lifeless> I think the concrete fence was entirely appropriate; it is an island of convicts after all
[03:14] <abentley> Yeah, Sydney wasn't to hard to get my head around.
[03:15] <lifeless> igc: new patch version, want to confirm you're happy with what I did?
[03:15] <jelmer> lifeless: 0.1 is in debian
[03:15] <lifeless> jelmer: hmm, madison isn't showing it. whats the source package name?
[03:15] <jamesh> you don't want all the world leaders escaping and overstaying their visas too
[03:15] <jelmer> lifeless: bzr-rebase
[03:15] <jamesh> better to keep them locked up
[03:15] <abentley> http://linuxcaffe.ca/node?page=3
[03:15] <lifeless> hmm, madison crackness
[03:15] <jelmer> lifeless: it's both in sid and lenny
[03:16] <igc> lifeless: sure, I'll look now
[03:16] <igc> thanks for the fast turnaround
[03:16] <abentley> jdub: PyGTA meet at linuxcaffe.
[03:17] <jdub> oh, that was ages ago, after i spoke in toronto on the badgerbadgerbadger tour
[03:17] <jdub> it was just random
[03:17] <abentley> Hehe.
[03:20] <lifeless> poolie: is there anything in bzr.dev yet that shouldn't be in 0.91 ?
[03:20] <poolie> i have not merged anything like that yet
[03:20] <poolie> no, there is nothing that can't merge to 0.91
[03:21] <lifeless> ok
[03:21] <lifeless> I'll merge my branch trivially then
[03:21] <poolie> i was going to merge the version bump, but will hold off
[03:21] <poolie> ok
[03:21] <jelmer> jamesh: fixed in trunk.
[03:21] <jelmer> thanks for the bugreport :-)
[03:23] <lifeless> igc: I think 'saving data locally' might be better as 'Finalizing commit' or something
[03:23] <igc> lifeless: sounds better to me
[03:24] <jamesh> jelmer: thanks.
[03:29] <poolie> lifeless, let me know when you're done and i'll open things for 0.92
[03:29] <lifeless> they are both in pqm now
[03:30] <lifeless> back shortly
[03:31] <lifeless> poolie: lol you and your committed pdb lines :)
[03:32] <jelmer> lifeless: so, what should we do with bzr-gtk 0.91 ? when are you going to upload the .debs?
[03:32] <poolie> :)
[03:32] <poolie> i need a precommit hook maybe
[03:32] <poolie> specifically what happened though is that  i started from an unclean tree and should have checked that
[03:33] <jelmer> lifeless: s/going to/would you like to/ :-)
[03:37] <poolie> they should be in as an experimental format
[03:38] <NfNitLoop> Mmmm.
[03:39] <beuno> great, I'll be experimenting with them then
[03:39] <lifeless> jelmer: if poolie is going to do an rc3 I'll wait for that, otherwise I'll start on them in a couple hours
[03:39] <beuno> I keep hearing good things about it
[03:40] <poolie> i'm going to just use the break command rather than set_trace() for a while :)
[03:40] <poolie> lifeless, wait for rc3 to make debs?
[03:40] <poolie> when should we do rc3? today? tomorrow?
[03:43] <jelmer> lifeless: it's ok to wait until the weekend with bzr-gtk 0.91 though?
[03:43] <jelmer> lifeless: otherwise, feel free to take a snapshot and call that 0.91~rc1 or something..
[03:43] <lifeless> jelmer: well as soon as I upload debs to bazaar-vcs.org, the other plugins will break
[03:43] <lifeless> thats my concern
[03:43] <lifeless> bzrtools is good now, as abentley has done a release
[03:44] <lifeless> poolie: so, my fetch fix - do you want to do an rc3 with that immediately, or wait a bit., If you are waiting I'll do debs of rc2, otherwise I'll do the debs after you do rc3
[03:45] <jelmer> lifeless: I'll do bzr-svn 0.4.3 tomorrow, release is already tagged just not packed and uploaded yet
[03:45] <jelmer> have fun
[03:45] <jelmer> g'night
[04:10] <Vantage13> anyone have any tips/guides on importing in a large cvs repo into bzr?
[04:24] <poolie> Vantage13, is it an open source tree?
[04:24] <Vantage13> poolie:  nope...
[04:25] <poolie> Vantage13, http://bazaar-vcs.org/BzrMigration?highlight=%28import%29#head-4b8472ce65e228eb1e87383ff908129305df9dee
[04:25] <poolie> cvsps-import is probably a good way to go
[04:26] <Vantage13> poolie: thanks.  I'll give it a shot
[04:26] <poolie> please let us know if you have any problems/questions, or if it works well
[04:29] <lifeless> poolie: my patch causes an error in a different test
[04:31] <lifeless> just debugging now
[04:32] <poolie> k
[04:34] <jroes> anyone ever accidentally try bzr pushing to sftp://blah.net/blah/blah without a username@?  bzr (or maybe it's the paramiko dependency) crashes pretty hard on win32
[04:35] <lifeless> I don't use win32, but we do that all the time without a username
[04:35] <lifeless> by crash do you mean you get a backtrace
[04:35] <jroes> yup
[04:35] <jroes> I get a python bt that is
[04:35] <lifeless> could you file a bug then?
[04:36] <jroes> sure, looking for the bug tracker now
[04:38] <lifeless> launchpad.net/bzr
[04:40] <jroes> doesn't look like an already existing one, surprisingly
[04:40] <jroes> I hope it's repro-able
[04:41] <lifeless> poolie: the test fails cause of another bug AFAICT
[04:41] <lifeless> abentle1: are you still up ?
[04:42] <abentle1> lifeless: yeah
[04:42] <lifeless> with nested trees
[04:42] <lifeless> should we have a knit TREE_ROOT ?
[04:43] <abentle1> A knit *for* TREE_ROOT?
[04:43] <lifeless> yes
[04:43] <lifeless> fileids_altered_by_revisions()
[04:43] <abentle1> We do have one
[04:43] <lifeless> returns {'TREE_ROOT':['ghost'] }
[04:43] <lifeless> in the test test_fetch_all_fixes_up_ghost
[04:44] <lifeless> when the source and target repo's are both KnitRepository3
[04:44] <lifeless> but there is no such source weave in the test case
[04:44] <lifeless> I'm not sure if the test is invalid
[04:44] <abentle1> That's strange.
[04:45] <lifeless> if you apply my patch to fix the regex, then run ./bzr selftest test_fetch_all_fixes_up_ghost
[04:45] <lifeless> you'll see the failure
[04:45] <abentle1> The only case would be if there were no revisions to store.
[04:46] <abentle1> I'm sorry, but I'm not feeling so hot tonight.
[04:46] <lifeless> :(. Get well soon
[04:46] <abentle1> Tx.
[04:47] <abentle1> It's toothache.  Very distracting.
[04:47] <lifeless> its a test that sets up a manual repo
[04:47] <lifeless> rather than using commit builder
[04:47] <abentle1> Ooooh.
[04:48] <abentle1> Then it sounds quite likely it's setting up an invalid knit3 repo.
[04:49] <lifeless> yes
[04:49] <lifeless> thats my conclusion, I'm upgrading it to commit builder
[04:51] <jroes> oh, now launchpad is cool.  I was able to say "this also applies to paramiko" :)
[04:51] <poolie> lifeless, btw is configmanager in launchpad?
[04:51] <poolie> i couldn't find it the other week
[04:51] <lifeless> uhm don't think so
[04:52] <poolie> k
[04:52] <NamNguyen> hi, the http smart server guide says "this feature is EXPERIMENTAL and is NOT SECURE. It will allow access to arbitrary files on your server." i wonder how is that done?
[04:55] <nxsryan> hello
[04:55] <lifeless> NamNguyen: I think that is outdated, spiv can comment more
[04:55] <lifeless> nxsryan: hi
[04:55] <nxsryan> i installed the plugin to send emails on commit -- i want this to happen anytime anyone commits. but where do i put the conf variables, then?
[04:55] <NamNguyen> nxsryan: in ~/.bzr/locations.conf
[04:55] <lifeless> nxsryan: bzr help email has documentation about this
[04:56] <nxsryan> lifeless: i looked at that
[04:56] <lifeless> nxsryan: you can put them in ~/.bazaar/bazaar.conf
[04:56] <lifeless> or ~/.bazaar/locations.conf
[04:56] <nxsryan> lifeless: i know that, i'm trying to figure out how to configure it so it happens for every user
[04:56] <nxsryan> lifeless: system-wide
[04:56] <lifeless> the configuring-bazaar document has more details on the configuration system
[04:56] <poolie> i just pinged spiv, he should be on in a bit
[04:56] <lifeless> nxsryan: bzr does not have a system wide configuration system at the moment, only per-branch, per user and per-user-location
[04:57] <nxsryan> hm :/
[04:57] <poolie> it'd be reasonable to read something like /etc/bazaar/bazaar.conf i guess
[04:57] <NamNguyen> hello spiv, is the http smart server still prone to security problems?
[04:57] <poolie> there does seem some potential for unwanted disclosure if email is turned on globally
[04:58] <lifeless> poolie: one can always disable it per user
[04:58] <poolie> if people are also keeping personal files say
[04:58] <nxsryan> poolie: definitely it'd be better to have the option and decide not to use it!
[04:58] <spiv> NamNguyen: I don't think so, but I haven't thought closely about it recently.  I think with the ChrootTransport it should be fairly trustworthy.
[04:58] <fullermd> Well, that calls for /etc/bazaar/locations.conf (rather, /usr/local/etc/bazaar/ for some of us) too...
[04:59] <NamNguyen> spiv: the docs @ http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/http_smart_server.html says abitrary files might be read, i wonder how it is done? at the HTTP layer or at the bzr layer?
[04:59] <spiv> NamNguyen: I should re-read the documentation and update it.
[05:00] <nxsryan> blah. this plugin uses a weird switch to mail -> "mail: illegal option -- a"
[05:01] <NamNguyen> it could have used smtplib
[05:01] <Ubotu> New bug: #139031 in paramiko "bzr push via sftp without username crashes on win32" [Undecided,New]  https://launchpad.net/bugs/139031
[05:01] <abentle1> NamNguyen: We actually have some nicer stuff on top of smtplib also.
[05:02] <NamNguyen> abentle1: does it support utf-8 on SMTP headers and message body?
[05:02] <NamNguyen> i noticed your BB does support utf-8 in the message body
[05:02] <nxsryan> so. does anyone know a different plug-in to mail about commits?
[05:02] <nxsryan> this one doesnt work on freebsd
[05:04] <lifeless> NamNguyen: smtplib requies *much* more configuration
[05:04] <lifeless> NamNguyen: 'mail' is a fine interface for fire and forget mailing
[05:04] <lifeless> nxsryan: it can be configured to work on bsd
[05:04] <NamNguyen> lifeless: agree
[05:05] <lifeless> nxsryan: How emails are sent is determined by the value of the configuration option
[05:05] <lifeless> 'post_commit_mailer':
[05:05] <lifeless> nxsryan: look for that in bzr help email, and read down
[05:05] <lifeless> nxsryan: you can either use a wrapper to your real mail, or smtplib as per the documentation
[05:05] <nxsryan> lifeless: ok, thanks
[05:16] <lifeless> poolie: submitting with a fairly trivial fix ok  ?
[05:16] <abentle1> NamNguyen: the higher-level code supports utf-8.  See email_message.py
[05:19] <abentle1> lifeless: I do wonder whether we should support calling mail/sendmail from bzrlib.smtp_connection or similar.
[05:20] <lifeless> possibly; I haven't looked at that code et
[05:20] <lifeless> *yet*
[05:23] <lifeless> food time
[05:23] <poolie> lifeless, i guess
[06:03] <lifeless> poolie: it was only test code that was problematic
[06:22] <lifeless> igc: ok, take #45 -> list now
[06:23] <igc> lifeless: what's #45?
[06:24] <igc> latest patch?
[06:24] <igc> got it
[06:29] <lifeless> poolie: ok, bzr.dev has my fix now, so you can do the 0.92 openening shuffle
[06:31] <lifeless> igc: I've pushed the latest commit branch code, which was passing all tests for me
[06:32] <igc> great! I'll grab it now
[06:32] <lifeless> I'm also pushing the repository branch
[06:34] <igc> please - that's the one I want ( http://people.ubuntu.com/~robertc/baz2.0/repository/)
[06:34] <lifeless> its pushed
[06:35] <lifeless> hmm, dunno if thats entirely fixed yet.
[06:35] <lifeless> probably just a merge awawy
[06:35] <igc> 2759 is the last revno I have on that branch and it claims nothing to pull
[06:35] <lifeless> thats probably why it was so quick to push
[06:36] <igc> :-)
[06:38] <lifeless> pushing 2760 now
[06:38] <lifeless> haven't tested, but it should be good
[06:38] <igc> np - I'll test :-)
[06:40] <lifeless> puthed
[06:42] <beuno> Verterok, :D
[06:42] <Verterok> hiya
[06:43] <beuno> Verterok, I'm going real quick to walk the dog, but I solved the problem yesterday and pushed it to my branch
[06:43] <beuno> the missing function should be completely implemented
[06:43] <Verterok> beuno: great!
[06:44] <Verterok> beuno: so, can be merge it in trunk?
[06:44] <beuno> Verterok, take a look and see if it's in shape to merge with the trunk, and I'll move on to the next feature
[06:44] <beuno> :D
[06:44] <beuno> that would be your call
[06:45] <beuno> brb
[06:45] <Verterok> :D ok I 'll take look to it
[06:46] <igc> lifeless: +1 with those changes - voted on BB accordingly. Thanks
[06:53] <beuno> back
[07:00] <Verterok> beuno: hi there!
[07:01] <beuno> Verterok, so?  the code could be cleaner, but for a first try, I'm pretty happy with it
[07:01] <lifeless> yay
[07:01] <lifeless> another 2 seconds off
[07:02] <Verterok> yes, it works as advertised :)
[07:02] <Verterok> beuno: I'm getting <log> </logs> tags at the end of the xml (maybe a copy&paste bug?)
[07:03] <beuno> Verterok, even when no logs are present?  (it probably is a copypasta error)
[07:05] <Verterok> beuno: should I expect <logs> and <log> tags in the xml?
[07:06] <beuno> Verterok, only if it shows you revisions
[07:07] <beuno> Verterok, could you copy and paste the output somewhere?
[07:07] <Verterok> sure
[07:09] <Verterok> beuno: http://rafb.net/p/cUlESQ51.html
[07:09] <beuno> Verterok, that would be wrong
[07:09] <beuno> let me fix that real quick
[07:11] <Verterok> beuno: maybe you can alse merge your branch with the last changes in trunk ?
[07:11] <beuno> Verterok, sure, seems reasonable
[07:21] <beuno> Verterok, the problem comes from the "workaround", why does it print out the closing tags, but no the opening one right above it?
[07:22] <Verterok> beuno: ups? :D
[07:23] <beuno> Verterok, I'm sure it's as much my fault as it's yours
[07:23] <Verterok> beuno: ahh, you have the previous version of __init__.py (in the current the workaround, actually "work around" it )
[07:23] <beuno> I'm just trying to understand *why* it doesn't print out the opening tag when it's specified right above the other ones
[07:23] <beuno> Verterok, aaaah, so I should merge first, then complain  :D
[07:24] <Verterok> the openeing tags are printed from inside XMLLogFomatter
[07:25] <beuno> let me merge and take a look
[07:25] <lifeless> igc: I see 7 seconds in 'saving data locally'
[07:26] <lifeless> 3% in index serialisation
[07:26] <lifeless> 85% in _update_builder_with_changes
[07:26] <igc> yup
[07:26] <igc> I'm seeing 3% in set_parent_trees
[07:26] <igc> 3.6% in add_inventory of which 2.8% is serialise_inventory
[07:27] <igc> (those figures from yesterday's branch of yours and today's total time is the same)
[07:28] <lifeless> I would expect that
[07:28] <Verterok> beuno: I known it's ugly, but is the only way I can close the </logs> tag, and the last </log>, because when XmlLogFomatter do log_revision(...) it doesn't know if is the last one (or how much left to print, XmlLogFomatter recieves one revision at a time)
[07:28] <lifeless> if yo uapply my most recent commit branch patch from the commits list you should see a further 1% drop
[07:29] <beuno> Verterok, yeap, the newer version makes it easier, applying the new format now, should be fixed in a sec  :D
[07:30] <Verterok> cool
[07:38] <beuno> Verterok, merged, fixed and pushing as we speak
[07:43] <Verterok> beuno: it's a worksforme(tm), merging..and pushing to trunk
[07:44] <beuno> Verterok, yay!  one thing less to implement  :D
[07:47] <Verterok> beuno: I wonder what you do think about enclosing all missing xml output in a root tag, I'm not an xml expert.
[07:48] <beuno> Verterok, I was hoping you where, I wasn't sure what approach to take either
[07:48] <Verterok> jeje
[07:48] <beuno> either seems fine to me, parsing it is almost the same, I just don't know what the cleanest method would be
[07:49] <Verterok> I presume (need to check it) that a well-formed xml should have a root tag, but I'm not 100% sure
[07:49] <Verterok> yes, the parsing don't change
[07:50] <beuno> Verterok, so you want me to enclose all the information as childs of a missing-specific tag?
[07:51] <Verterok> I'm not sure, let me check with the XML spec
[07:54] <Verterok> beuno: any problem to add a root element? :P look (2) in: http://www.w3.org/TR/REC-xml/#sec-well-formed
[07:55] <beuno> Verterok, none at all, I'll add'n'push
[07:55] <Verterok> beuno: great, thanks!
[07:59] <Verterok> beuno: I'm tempted to write a DTD/XSD, do you think is  usefull in any way to you/others that use the plugin?
[07:59] <beuno> Verterok, I'm sure having a DTD would be useful on many cases, just not mine specifically
[08:00] <Verterok> ok
[08:00] <beuno> but it does seem like a must-have at some point
[08:00] <beuno> so go with what you feel like doing  :D
[08:03] <Verterok> I'll try to write it when I have some spare time or if a user need/request it :D
[08:03] <beuno> that's the spirit, hehehe
[08:06] <beuno> Verterok, where you looking for something like this?   http://rafb.net/p/Q2kh9R50.html
[08:07] <Verterok> beuno: yes, the root tag, if you want it to be <missing> o something else, that's your call :)
[08:08] <beuno> Verterok, then it's done, let me just fix a bug I introduced and I'll push again
[08:08] <Verterok> ok
[08:08] <beuno> I might change the tag's name to <beuno> (?)
[08:08] <Verterok> sure :D
[08:09] <beuno> heheh, not yet, I'm saving that one for when it's part of bzr directly  :p
[08:09] <Verterok> jaja
[08:11] <beuno> argh, the missing code is terribly hard to work with, I'll try and refactor it later on if some bzr dev has the time to help me a bit
[08:13] <Verterok> I encounter similar problems working with the other comands (as is shown in my copy&paste form bzrlib :P )
[08:14] <mkanat> bzr co bzr://bzr.everythingsolved.com/vci/trunk
[08:14] <mkanat> bzr: ERROR: Tags not supported by BzrBranch5('file:///home/mkanat/unzip/trunk/'); you may be able to use bzr upgrade --dirstate-tags
[08:14] <mkanat> And both server and client are 0.18.
[08:14] <mkanat> Is that fixed in 0.90?
[08:14] <mkanat> It works fine over SFTP, but not over bzr:// or bzr+ssh://
[08:15] <fullermd> Not fixed on 0.90.  Not _fixed_ in 0.91 either, just sorta OBE.
[08:15] <poolie_> mkanat, it should be ok in 0.91rc
[08:16] <mkanat> poolie_, fullermd: Okay. :-)
[08:17] <mkanat> fullermd: OBE?
[08:18] <fullermd> Overtaken By Events.  0.91 still doesn't properly inherit the format of the parent branch, but the default is now dirstate-tags, so...
[08:19] <mkanat> fullermd: Ah, okay.
[08:19] <beuno> Verterok, pushed
[08:20] <mkanat> Is bzr log -v ever going to be fast, or should I just rely on it never being fast?
[08:20] <Verterok> beuno: ok, merging & pushing. then directly to bed
[08:20] <mkanat> It's a matter of an architecture decision for the VCI driver for Bzr.
[08:21] <mkanat> Because "bzr log" is super-fast.
[08:21] <beuno> Verterok, sounds like a plan, I would love to follow as soon as I finish moving this 6gb mess-of-a-website from one server to the other
[08:22] <Verterok> uh, good luck with that!
[08:22] <Verterok> seeya!
[08:22] <beuno> Verterok, thanks, sleep well
[08:23] <Verterok> thanks
[08:23] <Verterok> bye
[08:29] <lifeless> beuno: you were?
[08:29] <lifeless>  whats your lp name?
[08:29] <beuno> lifeless, beuno
[08:29] <beuno> I hadn't noticed until now
[08:29] <beuno> not that it's important, just curious  :D
[08:32] <lifeless> real    1m41.819s
[08:32] <lifeless> user    1m33.066s
[08:32] <lifeless> sys     0m4.940s
[08:32] <fullermd> They found out you were writing XML stuff.  The stigma will follow you forever.
[08:32] <lifeless> another 4 seconds nuked
[08:32] <fullermd> So you're just killing time?   :p
[08:33] <beuno> fullermd, hahaha, I knew I shouldn't of gone down that path...   it's just so tempting to write xml...   :/
[08:34] <lifeless> fullermd: bleh
[08:40] <lifeless> igc: another 4 second improvement pushed to my repository branch
[08:40] <lifeless> and I'm done for the day.
[08:41] <igc> great ...
[08:41] <igc> just fyi ...
[08:41] <igc> my reporting changes are a slight win still for your stuff
[08:41] <igc> but the iter_changes stuff is not
[08:42] <igc> I'll grab your stuff now
[08:43] <igc> lifeless: does the latest stuff fix selftest or just performance improvements?
[08:43] <igc> that's just in a nice way :-)
[08:44] <lifeless> its just faster
[08:48] <jdub> poolie_: around?
[08:51] <poolie_> jdub, hi
[08:51] <jdub> poolie: got a moment for a phone call?
[08:51] <jdub> poolie: bzr related, but not support ;-)
[01:40] <jolex> hi. is it possible to replace an earlier commit if this is not the last in the branch and I would like to preserve newer commits?
[01:41] <Peng> No.
[01:44] <johnf> Can anyone point out anything that would be missing from my patch in https://bugs.launchpad.net/bzr/+bug/128456 that would help me get someone to apply it :) Its a trvial patch to enable bzr+https
[01:44] <Ubotu> Launchpad bug 128456 in bzr "bzr+https is not a supported protocol" [Low,Triaged] 
[01:52] <jolex> peng: what about cherry picking with commit history?
[02:14] <jolex> i'm planning to use bazaar in the following working model: two parallell branches (production and working). production contains only public releases (common source code base for projectmembers). working is my "private" branch where I keep track of all my changes. my changes in working is applied to the common source code. when all the project members changes has been added and the common source is released I can again commit this to my production branch. and I w
[02:14] <jolex> ant to merge this (my own changes plus other members' changes) into my working branch. Is there anyone with experience from a similar usage of bazaar?
[02:19] <dato> jelmer: do you know why doing bzr pull with 0.92.dev would raise a 'Version mismatch' exception coming from bzr-svn in some branches, and not in some others?
[02:24] <jelmer> dato: bzr-svn only warns when it's invoked
[02:24] <dato> I wonder why it's being invoked for a branch of bzrtools, then.
[02:24] <jelmer> bzr first tries to find a .bzr directory, if that isn't found it will try other formats
[02:26] <dato> so I can't understand what's happening with this bzrtools branch.
[02:29] <dato> ah
[02:29] <dato> updating bzr-svn seems to help
[02:29] <dato> well
[02:29] <dato> obviously, d'oh
[02:31] <jdong> schplee! I just tried pushing th LP over bzr+ssh for fun, and to my surprise it worked.
[02:32] <jdong> when has this been the case?
[02:39] <Peng> Ack.
[02:39] <Peng> I was just thinking of responding to jolex.
[02:43] <dato> jelmer: ok, seems like for all branches in shared repos the svn format will be tried on them, dunno if that's a bug or not
[03:07] <jelmer> dato: doing what exactly?
[03:36] <Ubotu> New bug: #139109 in bzr "No API to create a branch reference without opening it" [Undecided,New]  https://launchpad.net/bugs/139109
[03:36] <dato> jelmer: bzr pull
[04:08] <Lo-lan-do> Hi all
[04:08] <Lo-lan-do> (Uh-oh, says jelmer)
[04:09] <Lo-lan-do> Thanks for bzr-svn 0.4.2 in Sid, but...
[04:09] <Lo-lan-do> http://paste.debian.net/36917
[04:11] <brmassa> guys, using olive (bzr-gtk) on Kubuntu, everytime i push my branch to launchpad it breaks (i think its because ssh). Does it happen on Ubuntu?
[06:00] <luisbg> how do I revert to an old version? I'm in 96 and want to go back to 90
[06:00] <luisbg> I meant revision not version
[06:01] <dato> luisbg: bzr revert -r 90
[06:01] <luisbg> dato, thanks a lot =)
[06:01] <luisbg> couldn't find it in the bzr man
[07:16] <james_w> Lo-lan-do: is that the first commit in the branch?
[07:47] <Lo-lan-do> james_w: No.
[07:47] <Lo-lan-do> (Sorry, was away for dinner)
[07:50] <corporate_cookie> is there a rpm version of BZR for RHEL4 ?
[07:50] <Lo-lan-do> I tried re-pushing, but then I get another assertion error: http://paste.debian.net/36935
[09:27] <jelmer> re
[09:30] <jelmer> Lo-lan-do: is the gforge svn repository publicly accessible?
[09:30] <Lo-lan-do> jelmer: Not anonymously :-(
[09:31] <Lo-lan-do> But if you care to register on gforge.org, you should at least get read access.
[09:31] <Lo-lan-do> (Unless Tim Perdue is growing more and more paranoid)
[09:32] <jelmer> ok, just registered
[09:45] <lifeless> hi
[09:46] <Ubotu> New bug: #139202 in bzr ""Could not acquire lock" error doesn't tell you how to fix it" [Undecided,New]  https://launchpad.net/bugs/139202
[09:46] <jelmer> 'morning lifeless
[09:56] <lifeless> so, how many seconds can I save today.
[09:58] <jelmer> Lo-lan-do: ok, trying to pull now..
[09:58] <Lo-lan-do> jelmer: The initial "bzr get" takes me about three hours on my DSL link.
[09:59] <jelmer> the repository doesn't seem to be very fast, indeed :-(
[09:59] <Lo-lan-do> If you need an initial branch, I have a mirror on alioth
[10:00] <Lo-lan-do> (Looking for the public URL)
[10:00] <Lo-lan-do> http://alioth.debian.org/~lolando/bzr/gforge/upstream-svn/trunk/
[10:01] <jelmer> lifeless: I'm looking forward to the packs stuff landing!
[10:01] <jelmer> Lo-lan-do: thanks
[10:01] <Lo-lan-do> It's not quite up-to-date (since I'm not eager to publish stuff there that's not really in SVN), but you'll only miss a handful of versions.
[10:03] <Lo-lan-do> What I'm trying to push to SVN is basically a merge into that branch of http://alioth.debian.org/~lolando/bzr/gforge/debian/sid/
[10:08] <lifeless> jelmer: dogfoodink yet ?
[10:14] <NfNitLoop> so, what are packs?   Just a way to compress your repository?
[10:14] <NfNitLoop> Didn't see anything about it on the wiki, but I suppose that's because it's still being implemented. :)
[10:15] <jelmer> lifeless: not yet, though I plan on trying it out on my Samba branches
[10:15] <jelmer> lifeless: I'll migrate bzr-svn as soon as packs enters bzr.dev
[10:15] <jelmer> as it has to have the latest bzr anyway
[10:18] <lifeless> well
[10:18] <lifeless> entering bzr.dev won't freeze the format immediately
[10:19] <lifeless> so I'd encourage you to dogfood irrespective of bzr.dev merging
[10:20] <jelmer> Lo-lan-do: I'm unable to pull as the alioth apache server appears to be executing .php.knit files
[10:21] <jelmer> http://alioth.debian.org/%7Elolando/bzr/gforge/.bzr/repository/knits/82/184%406d150e1c-e21c-0410-8b89-9ee68aed362b%253atrunk%253agforge%25252%2546www%25252%2546account%25252%2546register.php.knit
[10:22] <Lo-lan-do> I thought I had fixed that...  I'll have a look.
[10:23] <Lo-lan-do> Damn, I must have lost the .htaccess when I erased and reinstalled the branch.
[10:24] <Lo-lan-do> And I obviously forgot what it contained :-(
[10:24] <Lo-lan-do> Oh hey, I copied it on my blog :-)
[10:24] <Lo-lan-do> Try again?
[10:25] <jelmer> Lo-lan-do: ok, thanks
[10:33] <james_w> lifeless: there was a discussion recently on the git list about packing. It started when it was realised that users can't be expected to ever pack their repos. Am I right that you have implemented automatic repacking?
[10:35] <lifeless> abentley: ping
[10:35] <lifeless> james_w: yes we pack automatically
[10:36] <lifeless> james_w: every 10 commits we pack 10 revs, every 100 we pack 100 etc
[10:36] <lifeless> james_w: so we have sum(digits) packs as an upper limit at any point in time.
[10:37] <Lo-lan-do> Nice.  Will that work with remote branches/repositories too?
[10:42] <lifeless> Lo-lan-do: yes it operates an all mutating transactions
[10:43] <Lo-lan-do> Lovely.
[10:43] <lifeless> using bzr+ssh is better cause it won't have to repack over the wire, but it will work :)
[10:43] <Lo-lan-do> I guess that'll mean fewer round-trips to branch HTTP branches?
[10:43] <james_w> lifeless: that sounds pretty good to me.
[10:44] <lifeless> Lo-lan-do: yes, we auto pack to provide an upper bound on latency overhead that scales (O(log10)) with repository commits
[10:44] <lifeless> if we didn't you'd slowly degrade
[10:45] <Lo-lan-do> That's great news :-)
[10:49] <jelmer> Lo-lan-do: what version of bzr-svn are you using, 0.4.1?
[10:49] <Lo-lan-do> 0.4.2 now
[10:50] <Lo-lan-do> 0.4.1 didn't let me push.  0.4.2 did, with the aforesaid results.
[10:58] <Lo-lan-do> jelmer: Maybe some more information would help, I guess.
[10:58] <Lo-lan-do> I had several versions waiting to be pushed when 0.4.2 came out.
[10:58] <jelmer> Lo-lan-do: I think I've figured out what the problem is
[10:58] <Lo-lan-do> So I tried a push, got the first assertion error (assert self._new_revision_id is None or self._new_revision_id == revid)
[10:58] <lifeless> looks like thats another 3 seconds
[10:59] <Lo-lan-do> But one SVN commit still happened.
[10:59] <lifeless> meh, actually no change
[11:00] <Lo-lan-do> It contained the contents of the first revision I wanted to push.
[11:00] <jelmer> Lo-lan-do: it looks like it truncated the svn-revid property
[11:01] <Lo-lan-do> http://lists.gforge.org/pipermail/gforge-commits/2007-September/000548.html
[11:01] <jelmer> Lo-lan-do: which triggered that after-commit assertion
[11:01] <jelmer>    - 4865 lolando at debian.org-20070903205903-1g307x3ja2b9o0zw
[11:01] <jelmer> that line shouldn't have been remvoed
[11:03] <Lo-lan-do> Should it be a multiline property?
[11:03] <jelmer> yep
[11:04] <Lo-lan-do> Hm.  I guess I can fix it by hand, but won't another push truncate it again?
[11:05] <jelmer> I'm trying to figure out what is causing the truncation
[11:06] <Lo-lan-do> (You really must come visit southern France one of these days, my beer debt towards you is growing daily)
[11:07] <jelmer> (-:
[11:09] <hsn_> bzr 0.91 works with Trac?
[11:10] <jelmer> not sure
[11:10] <hsn_> 0.90 does
[11:11] <jelmer> it doesn't use any exotic API's so I think it should work ok
[11:14] <hsn_> cvs2bzr is still recommened method for moving away from CVS or better tools gets coded lately?
[11:16] <lifeless> cvsps
[11:16] <lifeless> there is a plugin on the bazaar plugins page
[11:16] <Lo-lan-do> jelmer: I'm off to bed, for now.  Thanks for your help, feel free to leave the problem aside for now, or to email me (lolando@d.o) for extra information.  I'll probably come back tomorrow anyway :-)
[11:17] <Lo-lan-do> 'night all
[11:21] <jelmer> 'night Lo-lan-do
[11:36] <hsn_> bzr: ERROR: cvsps-import can only operate on a local copy of the cvs repository. But i dont have shell access to CVS server..
[11:46] <radix> if I've merged a branch, committed some other stuff, and then decide the branch merge needs to be reverted
[11:46] <radix> how can I revert the merge, while still being able to bring back those changes later?
[11:47] <hsn_> bzr shelve?
[11:48] <radix> in SVN I revert the revision that merged the branch, and then just remerge again, and it works, because SVn doesn't track merged revisions. But bzr will go "oh, you already have those revisions!"
[11:48] <radix> hsn_: that's for working tree changes...
[11:50] <hsn_> you have branch - merge - changes and want to make branch - changes? make bzr diff for changes, then bzr uncommit and aply diff
[11:51] <radix> That was kind of incomprehensible, but I'll pick out some things: I can't uncommit because I've already made some unrelated commits.
[11:51] <radix> (and the branch already got distributed to other developers, etc)