[00:12] <lifeless> meep
[00:12] <lifeless> Raw size 3461880213
[00:12] <lifeless> Compressed size 141152371
[00:12] <lifeless> Compressed size 508555
[00:13] <lifeless> thats the inventories from my main bzr repo
[00:13] <davidstrauss> Merging with no common ancestor is not working properly for me.
[00:13] <lifeless> Jc2k: ^ guess what the bottom compressed size is from
[00:13] <lifeless> davidstrauss: what it is doing
[00:14] <davidstrauss> lifeless: http://fourkitchens.com/blog/2009/01/17/distributed-version-control-provides-streamlined-alternative-vendor-branches
[00:14] <davidstrauss> lifeless: I'm trying the commented operation, but with "bzr merge --revision=1..-1 bzr://vcs.fourkitchens.com/drupal/6" as the merge
[00:14] <davidstrauss> lifeless: And I get TONS of conflicts
[00:15] <lifeless> if you run bzr init and add in a new tree,then the files have new identity
[00:16] <lifeless> so when you merge, and they have the same path, its a file name conflict
[00:16] <davidstrauss> lifeless: how can i force a common ancestor
[00:16] <lifeless> start from trunk rather than by doing 'bzr init'
[00:16] <davidstrauss> lifeless: that's impossible. the whole point of this procedure is that you've started your own project on its own
[00:16] <lifeless> I'm sorry if I'm not being really helpful - I'm trying to understand what your blog post is about
[00:17] <davidstrauss> lifeless: i want people who have drupal projects in bazaar branches to be able to migrate to using our drupal bazaar branch for upgrades
[00:18] <lifeless> davidstrauss: ah
[00:18] <davidstrauss> lifeless: despite having no established common ancestor
[00:18] <lifeless> so the -r x..y syntax will force an ancestor of x
[00:18] <davidstrauss> lifeless: yes, but we get tons of conflicts
[00:18] <lifeless> but the /content/ of the trees is unrelated, I would expect tons of conflicts
[00:18] <lifeless> do you know much about bzr internals?
[00:19] <davidstrauss> lifeless: not for content IDs
[00:19] <lifeless> ok, very quick primer so my answers will make sense to you
[00:19] <m4v> hi, quick question, does bzr track file permissions?
[00:19] <lifeless> m4v: execute bit only
[00:19] <bob2> only execute
[00:19] <davidstrauss> lifeless: is there a way to force bazaar to understand that file name match = content match?
[00:19] <lifeless> m4v: see etckeeper for tracking full permissions, which supports bzr
[00:20] <lifeless> davidstrauss: each object that bzr is managing has a path and a fileid. The fileid is the globally unique ID for the object
[00:20] <davidstrauss> lifeless: I can see that now, but that doesn't really make it possible to efficiently merge without common ancestry
[00:21] <davidstrauss> lifeless: I mean, there *has* to be a way to merge efficiently without common ancestry
[00:21] <lifeless> davidstrauss: this is a 1:1 relationship in any tree - 1 path, 1 id.
[00:21] <lifeless> davidstrauss: over time you can get many different paths having the same id - when things are renamed and so on
[00:21] <lifeless> davidstrauss: so, to do a merge with an unrelated tree
[00:22] <lifeless> davidstrauss: such that future merges can be no-brainers
[00:22] <lifeless> davidstrauss: you have to replace the fileid of *every* file that is in the source tree and in the target tree, with the fileid from the sourcetree
[00:22] <davidstrauss> lifeless: is there a way to do that automatically?
[00:23] <lifeless> then you have to do a merge across the two file ids using the specified base, or else the old fileids local changes wil be lost
[00:23] <davidstrauss> lifeless: Is there a way to do that branch-wide?
[00:23] <lifeless> you need to identify the common revision in both branches as well
[00:24] <m4v> lifeless: alright
[00:24] <lifeless> davidstrauss: so - thats what needs to happen. The bad news is that noone (to the best of my knowledge) has written this code up
[00:24] <davidstrauss> lifeless: identifying the common revision in both branches is already part of my procedure
[00:24] <lifeless> davidstrauss: yes, but there is no way to tell bzr at the moment, you only manage to tell it 3 of the 4 coordinates needed
[00:25] <davidstrauss> lifeless: so is there an efficient way to resolve the conflicts?
[00:25] <garyvdm> vila: I managed to get qbzr to use CLIUIFactory rather than TextUIFactory.
[00:26] <lifeless> davidstrauss: it is scriptable in python
[00:26] <davidstrauss> lifeless: has it been scripted?
[00:26] <lifeless> davidstrauss: in fact, writing a custom conflict resolver could do it during the merge to make it seamless
[00:26] <lifeless> 11:21 < lifeless> davidstrauss: so - thats what needs to happen. The bad news is that noone (to the best of my knowledge) has written this code up
[00:27] <davidstrauss> lifeless: what would the custom conflict resolver look like?
[00:28] <davidstrauss> lifeless: would it be in python or a shell command?
[00:31] <lifeless> davidstrauss: I think it would be a subclass of bzrlib.merge.Merge3Merger, though I haven't written a custom one myself
[00:32] <lifeless> http://paste.ubuntu.com/106710/ <- knit vs gc compression
[00:33] <lifeless> short story, 141MB to 0.5MB, but 10 times slower at extraction, at the moment
[00:36] <davidstrauss> lifeless: what is gc compression?
[00:39] <lifeless> davidstrauss: its a new delta compression I'm evaluation for bzr
[00:44] <davidstrauss> lifeless: is there a way to specify an external merge tool that runs in the shell?
[00:44] <lifeless> I think the extmerge plugin does this
[00:44] <lifeless> note though that I don't think it will handle the file id changing that you need
[00:44] <davidstrauss> ok
[00:44] <lifeless> fundamentally this needs code written to support it
[00:47] <davidstrauss> lifeless: I think this is one area git's architecture shines.
[00:47] <davidstrauss> apparently
[00:47] <lifeless> well its certainly simpler there, for git or hg
[00:48] <lifeless> its the inode abstraction that makes it complex to handle parallel imports
[00:48] <lifeless> I encourage you to file a bug, this is something we should put a canned answer to in the core
[00:48] <davidstrauss> ok
[00:49] <lifeless> for now, people that want to move onto your branch would be best served by:
[00:49] <lifeless>  - pull your branch
[00:49] <davidstrauss> lifeless: would that handle the file ID mismatches?
[00:49] <lifeless>  - apply their local changes as a plain patch (bzr diff -r x..y | bzr patch)
[00:49] <davidstrauss> ok
[00:49] <lifeless> commit that patch
[00:50] <lifeless> then they are descendants of your branches
[00:50] <davidstrauss> lifeless: so, basically, start fresh
[00:50] <lifeless> yes
[00:50] <davidstrauss> lifeless: this seems similar to when you bzr bind after divergence
[00:52] <lifeless> gc is faster at compression, sweet
[00:55] <jelmer> we have a gc?
[00:57] <davidstrauss> lifeless: https://bugs.launchpad.net/bzr/+bug/318620
[00:58] <lifeless> jelmer: groupcompress
[00:58] <lifeless> davidstrauss: thank you
[01:07] <garyvdm> What do you guys think about merging a number of revisions that are currently the tip of your mainline, with an older revision, just for the sake of grouping them together?
[01:08] <garyvdm> I think I better pastebin a dag to explain this..
[01:10] <lifeless> garyvdm: you can do it if you want
[01:10] <lifeless> it just makes it look like a merge of a branch
[01:12] <garyvdm> Here is my dag just to make sure we are on the same wave length: http://pastebin.com/d23836559
[01:14] <jelmer> lifeless, ah, that makes more sense (-:
[01:18] <spiv> jelmer: bzr-svn is working well for me these days, btw.
[01:18] <jelmer> spiv, cool
[01:18] <spiv> jelmer: the current 0.5 tip seems to be quite reliable at pulling from python's and twisted's repos.
[01:19] <spiv> jelmer: I have some hackery to submit to make it import faster, though :)
[01:19] <spiv> (e.g. don't import subertpy all the time, etc)
[01:19] <spiv> jelmer: it even does find_tags at a bearable speed now :)
[01:20] <jelmer> spiv, patches for import improvements are more than welcome
[01:50] <thumper> hi ho
[01:50] <thumper> I just went bzr init, and bzr stat
[01:50] <thumper> and got a traceback
[01:50] <thumper> is this a known bug?
[01:50] <thumper> bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument 'verbose'
[01:51] <jelmer> thumper, do you have loom installed?
[01:51] <jelmer> thumper, I think you need a newer version of loom
[01:51] <thumper> plugin installed, yes
[01:51] <thumper> using it, no
[01:51] <jelmer> it wraps bzr status but doesn't cope with a new argument that has been added to status
[01:51] <jelmer> even if you're not using it
[01:52] <thumper> :(
[01:53] <jelmer> the last revision of the loom trunk fixes it
[01:53] <thumper> WTF?
[01:53] <thumper> :-(
[01:54] <thumper> bzr log --line -r-10..-1 now gives be non-mainline messages
[01:54] <thumper> this is very new
[01:55] <thumper> and I can't go --line --short, as that doesn't work
[01:55] <jelmer> yeah, I can confirm that has changed since 1.11
[01:56] <thumper> can we change it back?
[01:56] <thumper> it is really annoying
[01:57] <jelmer> I'm not sure it's intentional or a regression that is a side-effect of the recent work on log
[01:57] <thumper> I don't think it is intentional
[01:57] <jelmer> probably worth filing a bug about
[01:58] <thumper> igc: my log --line now shows non-mainline revisions
[02:02] <lifeless> jam: are you around by chance?
[02:15] <igc> thumper: I thought jam has sent a quick fix to pqm for that but it looks like he hasn't
[02:15] <igc> I'll do it now
[02:28] <thumper> igc: that'd be grand
[02:29] <igc> thumper: in the pqm queue now
[02:29]  * igc lunch
[02:29] <thumper> igc: fantastic
[03:08] <igc> thumper: try bzr.dev now and let me know if it's still broken
[03:08] <thumper> igc: ok
[03:08] <mwhudson> oops, 700 unread emails on the bzr list
[03:30] <S11001001> hello all
[03:30] <S11001001> I am maintaining a Trac with some modifications (my.desktopdoctorsinc.com) using a Bazaar branch.  I'm in the process of rebuilding it with upstreamable changes (~30% of the code) separated out.  I've built a bzr-loom with 7 patches so far, mostly non-interdependent, and can probably get a few more into upstreamable state.  I tend to merge upstream at new releases, the changes are typically larger than the total of all changes in my
[03:30] <S11001001> branch, and there are usually 2-3 conflicts.  Question is, would I be better off sticking with loom, or keeping separate ordinary branches for these changes?
[03:35] <lifeless> either is fine
[03:52] <thumper> igc: lp:bzr is a few revs behind by the look of it
[03:54] <spiv> thumper: it's 3 hours behind, on average ;)
[03:55] <thumper> spiv: funny man
[03:55] <thumper> so when is bzr going to host trunk on LP?
[03:58] <lifeless> http://bazaar.launchpad.net/~lifeless/+junk/bzr-compressbench
[04:52] <pygi> goooood morning
[05:32] <poolie> hello pygi
[05:47] <pygi> poolie, :)
[05:47] <pygi> chapter 1 coming to your address this week :)
[06:23] <davidstrauss> lifeless: http://fourkitchens.com/blog/2009/01/19/creating-common-branch-ancestry-hard-problem
[07:35] <vila> hi all
[08:03] <igc> hi vila
[08:36] <davidstrauss> What is the status of nested trees?
[08:37] <Lo-lan-do> They're full of birds?
[08:39] <jml> davidstrauss: they aren't there yet. interest is being renewed though.
[08:39] <davidstrauss> jml: The Drupal project is very interested in getting this support stable.
[08:39] <davidstrauss> jml: So we can effectively consider Bazaar for module development on Drupal.org
[08:39] <sdboyer> jml: like, very interested :)
[08:41]  * fullermd frowns.
[08:42] <fullermd> NEWS is looking a little odd.
[08:42] <jml> sdboyer, davidstrauss: I *think* abentley intends to work on it very soon.
[08:42] <jml> but I couldn't say for sure.
[08:43] <fullermd> poolie: It looks like r3940 spuriously added a whole separate section on top of NEWS
[08:46] <sdboyer> jml: well, our timeframe for making a vcs switch is anything but clear, but nested trees would be a _huge_ deal for us, so if part of the hold-up is having a really rigorous use case to put the code through, that's something we can provide
[08:46] <jml> sdboyer: cool :)
[08:49] <luks> can't https://launchpad.net/bzr-scmproj be used as an alternative?
[08:50] <jml> maybe!
[08:50]  * jml doesn't know anything about it.
[09:02]  * igc dinner
[09:03] <davidstrauss> bzr-scmproj looks kind of clunky
[09:29] <poolie> davidstrauss: it's trying to do it in a kind of minimal but useful way
[09:31] <vila> luks: Looks like gary merged a conflict in qbzr trunk, just deleting it seems enough though
[10:10] <poolie> hello vila
[10:10] <vila> hey !
[10:19] <fullermd> poolie: Did you catch my above?
[10:28] <poolie> about news, or about nested trees?
[10:28] <poolie> i saw both
[10:28] <poolie> i'm making 1.11final tonight, and then will merge back and fix the news
[10:28]  * fullermd nods.
[10:28] <fullermd> Just making sure IRC didn't eat it   :)
[10:29]  * davidstrauss smiles in anticipation of 1.11
[10:30] <fullermd> Shucks, that means I have to update the port...
[10:43] <LarstiQ> sdboyer, davidstrauss: yeah, that would help
[10:43] <davidstrauss> :-0
[10:43] <davidstrauss> :-)
[10:43]  * LarstiQ thinks he may need to rethink the current approach
[10:46] <sdboyer> LarstiQ: great, we should definitely talk, then. cept probably not at 5am my time :)
[10:46] <LarstiQ> sdboyer: k, I'm in utc+1/+#
[10:46] <LarstiQ> 3
[10:46] <davidstrauss> sdboyer: It's the same time here
[10:46] <LarstiQ> sdboyer: currently in .nl
[10:47] <LarstiQ> and some of my time in .fi
[10:47] <fullermd> Heck, it'll be that time here in about 15 minutes   ;p
[10:47] <davidstrauss> I think Drupal could survive without nested branch support by simply having checkouts for each module. It's just not as elegant.
[10:48]  * LarstiQ nods
[10:48] <sdboyer> sure. my interest in having nested branches really working prior to us beginning our coding work is that i'd rather do it all in one fell swoop
[10:49]  * sdboyer is wary that delaying a piece like that until later could very well mean that by the time nested branches are ready, our coders have found other itches to scratch :)
[10:50] <sdboyer> not essential for implementation, but probably wise.
[10:50] <sdboyer> however, unlike davidstrauss, who has been talking about needing to go to bed for two hours, i actually AM going to bed :P
[10:50] <fullermd> A lot of things are easier to setup than to re-setup..
[10:51]  * sdboyer agrees with fullermd wholeheartedly
[10:51]  * sdboyer waves g'night
[11:06] <LarstiQ> poolie: the only other moves on nested trees has been scmproj, right?
[11:10] <poolie> i think so
[11:16] <LarstiQ> hmkay
[11:17] <LarstiQ> poolie: and/but there is still interest in getting it done?
[11:17] <LarstiQ> (well, I know I'd _like_ to have it, but progress has been meh)
[11:18] <Peng_> Oh god. Now that bzr-svn can finally handle a certain pair of branches, bzr-search can't!
[11:18] <Peng_> lifeless: ping
[11:39] <poolie> LarstiQ: interested in working on it?
[11:39] <poolie> i heard you had a branch that fixed some subtrees bugs?
[11:43] <LarstiQ> poolie: I have a couple of small fixes. From time to time I try to merge bzr.dev, but with the 100k diffs, it's not the easiest thing to do and not very motivating
[11:43]  * LarstiQ needs to put more regular time into it to move it forward
[11:44] <LarstiQ> poolie: I'd very much like to get this moving somehow, yes.
[11:44] <poolie> hm
[11:44] <poolie> well, send them up and hopefully we can gradually reduce the problems
[11:44] <poolie> do they fix failures when a subtree format is the default?
[11:45] <LarstiQ> they fix failures on subtree formats, I don't know about specifically that being the default, but with bugs in the usage of subtrees, it's not ready for that yet anyhow
[11:48] <poolie> i'm just wondering what tests you added to get failures
[11:48] <poolie> or what you changed
[11:48] <poolie> since the trunk test suite does not fail, it's presumably not testing everything
[11:49] <LarstiQ> poolie: right, lp:~larstiq/bzr/nested-trees is a continuation from Aaron's branch
[11:50] <LarstiQ> poolie: which is, afaik, the only place where work on by-reference trees is
[11:53] <LarstiQ> poolie: and by reference is I think where the brunt of the usecases are
[11:57] <Jc2k> lifeless: omg is that groupcompress!?!?!
[11:58] <james_w> pretty amazing :-)
[12:03]  * LarstiQ goes to lunch
[12:06] <poolie> hello jc2k, james_w
[12:06] <james_w> hi poolie
[12:06] <Jc2k> hi poolie
[12:08] <Peng_> Whee
[12:17] <Lo-lan-do> I can't seem to find a description of this "groupcompress" thingy that everyone seems to happy about.  Any pointer?
[12:18] <james_w> Lo-lan-do: I don't think so. It's a new compression strategy for storage of texts inside packs (or anything else really)
[12:19] <james_w> it's a different way of doing deltas than what is currently used, which gives a large compression win, but has trade-offs in other areas
[12:19] <Lo-lan-do> Okay.  So smaller repository sizes, I guess?
[12:19] <james_w> currently decompression time, and I imagine annotation time, but that may not change as packs already damaged that
[12:20] <james_w> yes, *massively* smaller in the current implementation
[12:20] <Lo-lan-do> A new storage format too, I suppose.  Will it be compatible with the current ones?
[12:21] <james_w> but that is at a cost of a 200% increase in decompression time, which is unacceptable in my opinion
[12:21] <Lo-lan-do> Um, yeah, sounds not-very-nice indeed.
[12:21] <james_w> yeah, it's just a change in the internal compression, so it will be a new format, but not a watershed one or anything.
[12:21] <Peng_> Can throwing more Pyrex/C at the problem improve decompression time?
[12:21] <Peng_> (I guess not if it's all in zlib.)
[12:21] <james_w> perhaps
[12:22] <james_w> first thing will be to try limiting the delta chains. That will lose some of the win in terms of compression, but may still lead to a better overall format
[12:22] <poolie> it's currently only for inventory data
[12:23] <poolie> so the point is to speed up commit and extraction
[12:23] <james_w> ah, I thought it was texts too
[12:23] <poolie> the decompression time is something that still needs to be solved before we go ahead with ti
[12:23] <poolie> it could be applicable
[12:23] <james_w> yeah
[12:23] <james_w> is there any plan to move away from XML inventories?
[12:23] <poolie> to file texts too
[12:24] <poolie> however, for reasons i don't want to go into right now, it has some troubles with big files
[12:24] <poolie> ie it'll store too many full texts
[12:24] <poolie> (well, arguably too many)
[12:24] <poolie> Lo-lan-do: it'll be backward/forward compatible
[12:25] <poolie> in the usual way
[12:28] <Lo-lan-do> Thanks
[13:26] <yml> hello
[13:28] <yml> I thought it was possible to do a partial checkout of a bzr branch. I would like to create a branch with only a subfolder ot the complete bzr repository.
[13:28] <yml> Is it possible ?
[13:29] <luks> it isn't
[13:33] <yml> Thank you for the confirmation
[13:33] <beuno> yml, you should, however, be able to export a directory
[13:35] <yml> beuno: how would you do this ?
[13:35] <yml> I mean my branch is hosted on launchpad
[13:37] <beuno> yml, ah. I guess you can only do that with local branches
[13:49] <igc> night all
[13:55] <yml> beuno: I see. Thank you for your help
[13:56] <beuno> g'night igc
[13:56] <yml> I will create a symbolic link to put the folder in my pythonpath
[13:57] <edreamleo> Help!  Bzr is, all of a sudden, acting bizarrely.  It started reporting changed files, but bzr diff gives nothing and bzr commit said "useless commit"  I tried installing bzr 1.11 and 1.10 with no improvement.
[13:58] <edreamleo> I just tried bzr branch bzr/1.10 from c:\ (I'm using XP) and bzr appeared to install, but now I see no installed folder.
[14:00] <edreamleo> BTW, "changed" files happen just after a fresh bzr branch.  Is there a cache that should be cleared?
[14:01] <Jc2k> you dont do bzr branch bzr/1.10 to install a new version..
[14:03] <edreamleo> Jc2k.  True, I installed bzr 1.10 from a downloaded zip file.  But I wanted to use bzr to grab bzr sources, and that appeared to work.
[14:03] <Jc2k> does the output of bzr status say "unknown:" and then a list of file?
[14:04] <edreamleo> No.  bzr status says modified.  The actual file appears random, but compares binary equal to the file in other branches.
[14:05] <Jc2k> how odd
[14:05] <edreamleo> By "appears random" I mean the actual file that is reported varies from time to time, or rather, from branch to branch.
[14:05] <edreamleo> Yes!  Odd indeed.
[14:06] <Jc2k> i had some weirdness moving branches between linux, flash drive and windows but this was over a year ago
[14:07] <edreamleo> At first I suspected bad memory.  But the oddness happens on all branches.  Maybe a bit got flipped in a central .bzr folder?
[14:08] <Jc2k> not really sure, im not a dev and what bits of the code i know are related to the workingtree stuff
[14:08] <Jc2k> *arent
[14:10] <edreamleo> I wonder.  Does a fresh install change C:\Documents and Settings\HP_Administrator\.bzr ?  I suspect not.  Any reason not to trash this?
[14:14] <edreamleo> Is there a trouble-shooting guide or FAQ?
[14:34] <superm1> Hi guys.  I'm wondering how to push my tags to the main branch in LP without doing another revision.
[14:35] <superm1> i can't appear to push because pushing requires a new revision
[14:48] <Peng_> superm1: Push will push tags even if there are no new revisions.
[14:48] <superm1> Peng_, is that only with newer versions of bzr?  I'm on hardy, so 1.3.1-1ubuntu0.1
[14:49] <james_w> superm1: I'm not sure, how did you verify that the tags hadn't been pushed?
[14:50] <Peng_> superm1: I don't think it's a new feature.
[14:50] <superm1> james_w, i pulled from another computer that's regularly been pulling from that same branch
[14:50] <james_w> ah, ok
[14:50] <james_w> it's probably just broken then, I don't remember it changing
[14:52] <superm1> okay, well surely i'll be doing another revision at some point from this branch then. the tags will get pushed up at that time at least
[14:52] <Peng_> WFM in bzr.dev.
[14:52] <Peng_> superm1: Does the LP branch support tags?
[14:52] <Peng_> superm1: Does it have any tags currently?
[14:53] <superm1> Peng_, oh you know what, i just tried to pull again and i *did* get the tag this time. it must have committed but there was just a delay before it was available
[14:53] <Peng_> Oh.
[14:53] <superm1> sorry for the chatter james_w and Peng_ but thanks for helping indicate that it should be working :)
[14:54] <Peng_> superm1: If you're pulling from http://bazaar.launchpad.net/, there might be a (short) delay, yeah. There isn't one for bzr+ssh or sftp.
[14:54] <superm1> Peng_, yeah i was pulling from http on the other computer, so that would explain it
[14:54] <james_w> glad to know it works :-)
[14:55] <james_w> there's a bug open about it not telling you what it's done
[14:55] <james_w> "No revisions to push" should be extended to mention that it pushed some tags
[14:55] <superm1> yeah that would be useful
[15:03] <jelmer> james_w: Hi
[15:03] <jelmer> james_w: Are you aware of any guides about using bzr-loom as alternative to quilt/dpatch for Debian packaging?
[15:04] <james_w> jelmer: I'm not
[15:10] <LarstiQ> beuno, mwhudson: similar to https://bugs.edge.launchpad.net/loggerhead/+bug/260547 when I try to run serve-branches proxied by an ssl apache site, links to ../changes or ../annotate drop back to http
[15:11] <bvk> hi, is there any quick way to branch lp:bzr instead of std bzr branch lp:bzr ?
[15:11] <LarstiQ> beuno, mwhudson: should I make a new bug, comment on that one, fix it if it is easy to do?
[15:11] <bvk> it never gets finished for me :(
[15:11] <LarstiQ> bvk: your two alternatives are the same?
[15:11] <beuno> LarstiQ, fix it is always the first option  :)
[15:11] <beuno> if not, I think a comment on the bug is useful
[15:11] <LarstiQ> beuno: it is an area I'm rather unfamiliar with
[15:11] <LarstiQ> but I'll have a go
[15:12] <LarstiQ> beuno: any hints on where to start looking?
[15:12] <jelmer> bvk, if you mean an alternative URL, try http://bazaar-vcs.org/bzr/bzr.dev
[15:13] <bvk> LarstiQ, jelmer: no, i am looking for any tarbal with repository. is such a thing available anywhere?
[15:13] <LarstiQ> bvk: specifically to get one copy of bzr.dev? I could generate a tarball for you
[15:13] <jelmer> I'm curious though as to why branching lp:bzr doesn't work for you
[15:13] <bvk> LarstiQ, jelmer: no, i tried both urls, lp:bzr and http://.../bzr.dev :-( but both timeout from my computer always :(
[15:13] <LarstiQ> bvk: or do you mean, for a given launchpad branch, does it support downloading a snapshot tarball?
[15:14] <bvk> LarstiQ: yes, that would be of great; thanks
[15:15] <bvk> LarstiQ: no, my problem is 'bzr branch lp:bzr' always timesout and doesn't get finish. its too slow
[15:15] <LarstiQ> bvk: ok, it would be good to solve that if possible, but a tarball is coming up for you
[15:17] <bvk> LarstiQ: thanks LarstiQ
[15:17] <LarstiQ> bvk: http://richtlijn.be/~larstiq/bzr.dev-20090119.tar.gz
[15:17] <LarstiQ> bvk: that is my ~/src/bzr/bzr.dev as of now
[15:17] <LarstiQ> bvk: the file is ~5M, if that is too big, I can make a tarball of it after a `remove-tree`
[15:18] <LarstiQ> you would then have to `bzr co .` after unpacking and cding
[15:19] <bvk> LarstiQ: 5MB is fine, i can easily download that.
[15:22] <bvk> LarstiQ: Is the branch with full history is of only 5MB? Then why was bzr took more than half hour and still didn't complete :(
[15:23] <Peng_> I think LarstiQ left out the repo.
[15:23] <LarstiQ> hmm, good point, I recall it being 40~ ish
[15:24] <bvk> well, i was looking for a branch with full history :(
[15:24] <LarstiQ> bvk: it does seem to be so
[15:25] <bvk> btw, is there any way to make a branch with partial history? say, like 50 days history?
[15:25] <LarstiQ> meh, still not looking at the right place
[15:25] <Peng_> bvk: No, there's not.
[15:25] <LarstiQ> bvk: --stacked might help you
[15:25] <LarstiQ> though it does not do it like that
[15:25]  * Peng_ watches bzip2.
[15:27] <Peng_> bvk: http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar -- it's almost 100 MB, and you'll have to run "bzr co .".
[15:28] <Peng_> Ehh, http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar.bz2 saves about 10 MB.
[15:28] <LarstiQ> hth do I end up with a working standalonish branch but it's .bzr/repository is empty
[15:29] <Peng_> .bzr/repository exists but is empty?
[15:29] <Peng_> Maybe it's a stacked branch?
[15:29] <LarstiQ> yeah, it is...
[15:30] <LarstiQ> bvk: well. That explains why it is so small.
[15:30] <LarstiQ> and why logging all took longer than expected
[15:30] <Peng_> http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar.gz saves almost as much as the bzip2 version, and I'm going to stop now.
[15:31] <Peng_> Thank goodness I don't have p7zip, lrzip and lzma on that machine. ;)
[15:31] <LarstiQ> :)
[15:31] <LarstiQ> nullzip? ;)
[15:32] <Peng_> "bzr branch"'s new progress bars are neat. Reminds me a bit of all the info git gives, only prettier. ;)
[15:32] <LarstiQ> bvk: if you do continue downloading my tarball, you should end up with a stacked bzr.devc
[15:32] <bvk> okay, i just found out that i was using bazaar 1.5, where as latest one is at 1.11
[15:32] <Peng_> bvk: Ok, but 1.5 should work fine.
[15:33] <Peng_> Well, it'll probably be slower and use more RAM than 1.11, but it'll *work*.
[15:35] <bvk> i just did 'bzr co .' in LarstiQ's 5MB tree and i got 'Bazaar Branch Format 7 (needs bzr 1.6)\n' :-(
[15:35] <bvk> i will upgrade my bzr and will try 'bzr branch lp:bzr' again
[15:36] <Peng_> Well, 1.5 can branch from lp:bzr fine.
[15:36] <Peng_> Or http://bazaar-vcs.org/bzr/bzr.dev/
[15:37] <bvk> Peng_: my problem is that it takes too much time. I waited for half an hour and it didn't finish
[15:37] <Peng_> Cool, lzma saves close to 20 MB, and that wasn't with the best compression.
[15:38] <Peng_> bvk: You can't wait half an hour? What kind of Internet connection and computer do you have? Not some Pentium II on dial-up, right?
[15:38] <Peng_> Ohnoes, bzr.dev has a new revision. Now my tarballs are out-of-date. :P
[15:39] <bvk> Peng_: mine is macbook with 256Kbps internet
[15:39] <Peng_> bvk: 256 Kbps? Yeah, that could do it...
[15:41] <Peng_> ...It'd take you a long time to download 100 MB, wouldn't it?
[15:42] <LarstiQ> bvk: my tarball should give you a workingtree of bzr.dev at a recent revision, plus .bzr/ bits to act as a stacked bzr branch
[15:42] <bvk> Peng_: true...but its UI always made me think it hung and i would endup either killing it in the middle (impatient :D)
[15:43] <LarstiQ> bvk: so if you extrac that, you can run the bzr _in there_ to branch with
[15:43] <LarstiQ> just run path/to/extracted/bzr.dev/bzr branch ...
[15:43] <Lo-lan-do> I usually try a "watch du -hs .bzr" when I wonder if it's stuck.
[15:43] <Peng_> bvk: Well, it probably wasn't hung. And the next version (not today's 1.11) should have much a much more active progress bar when branching.
[15:43] <LarstiQ> Lo-lan-do: did you see the progress indication that's not in 1.11?
[15:44] <LarstiQ> Lo-lan-do: it succeeds in subjectively making me feel it's waaaay faster
[15:44] <LarstiQ> Lo-lan-do: achieved by actually giving information :)
[15:44] <Lo-lan-do> LarstiQ: I've grown used to just switching to another virtual desktop for a while :-)
[15:45] <Peng_> Hmm, it's kind of creepy that the server lets me monitor how far along bvk's download is, and how fast it's going.
[15:45] <Peng_> Lo-lan-do: You should try it. It's very nice. It gives a running count of the revisions downloaded.
[15:46] <LarstiQ> Lo-lan-do: I picked up that skill when I was on cable. 8kbs up/down combined. Cable modem attached via serial to the pc. Best idea EVAR
[15:48] <Lo-lan-do> Peng: I'm switching back and forth between 1.5 and 1.11rc1 these days, actually.
[15:48] <Peng_> Lo-lan-do: 1.11 final is out. :D
[15:49] <Lo-lan-do> 1.11rc1 seems nice, but the corresponding bzr-svn version takes half an hour for every operation I do on a branch bound to a remote SVN repo, so I often downgrade back to a version that "only" takes four minutes.
[15:49] <Lo-lan-do> Not in Debian yet => it doesn't exist :-)
[15:50] <Lo-lan-do> (I keep pestering jelmer about it, but I also try not to burn him out)
[15:53] <jelmer> Lo-lan-do: :-)
[15:53] <jelmer> Lo-lan-do, I'm trying to get 0.5rc2 out today, hopefully I can have another look at your performance regression after that
[15:54] <Lo-lan-do> jelmer: I'm trying to single out a bug in svn-import, too :-)
[15:54] <jelmer> Lo-lan-do, argh, and I just got the bug count in bzr-svn back to < 30 :-)
[15:56] <LarstiQ> beuno: it looks to me like it may be a bit more complicated than trying to replicate the patch *somewhere*
[15:56] <Lo-lan-do> jelmer: Okay.  Just ping me when it's < 29 then :-D
[15:56] <beuno> LarstiQ, a comment on the bug about the https is fine then  :)
[15:57] <beuno> you did install python-pastedeploy, right?
[15:57] <LarstiQ> beuno: yup
[15:58] <LarstiQ> beuno: and it's working fine for my http vhost
[16:11] <LarstiQ> beuno: added a comment
[16:18] <LarstiQ> lifeless: is bicyclerepair completely bitrotted?
[16:19] <jelmer> any versionedfile API experts around?
[16:19]  * LarstiQ hides
[16:23] <jelmer> LarstiQ, nevermind, already found the problem
[16:23] <jelmer> KnitCorruption caused by a text revision that has the same parent twice
[16:24] <jelmer> Lo-lan-do, never mind me, it's actually at 27 already :-)
[16:25] <Lo-lan-do> jelmer: Does 0.5rc2 change anything related to deleted files by any chance?
[16:26] <jelmer> Lo-lan-do: some things - what's the error you're seeing?
[16:26] <Lo-lan-do> bzr: ERROR: Unable to find file id for child 'editreleases.php' in 'gforge/www/project/admin' in <RevisionMetadata for revision 999, path branches/Branch_gforge in repository 'c3c08832-fc22-4c88-9867-b2b84583e700'>.
[16:27] <jelmer> ah, good chance that's fixed in rc2
[16:27] <Lo-lan-do> At first I suspected that there was a problem with repacking (since I seem to remember it happens on or near revisions 10^n), but that's apparently a different problem.
[16:28] <Lo-lan-do> I'll try using http://people.samba.org/bzr/jelmer/bzr-svn/0.5 then, see if it helps.
[16:38] <jinRooma> so if i push to an ftp server, does it upload every file, or just the modified and new ones?
[16:40] <Peng_> jinRooma: It uploads the new revision data.
[16:41] <jinRooma> Peng_, when you say revision data, do you mean the actual files from the project
[16:41] <Peng_> jinRooma: No, I mean the data in .bzr.
[16:42] <Peng_> jinRooma: Push doesn't deal with working tree files; it deals with revisions.
[16:42] <jinRooma> ok i see. THe way i want to use it is, i work offline on my project, and i then synch it with the server on a daily basis
[16:42] <Peng_> jinRooma: In answer to your question, it only uploads the new data.
[16:42] <Peng_> (Well, it will sometimes download some of the old data, combine it into fewer files, and upload it again, but that shouldn't be a big deal.)
[16:44] <jinRooma> I see, so bzr does do some analysis / comparison of local & remote, and make decisions based on this. its not just a dumb upload
[16:46] <Peng_> jinRooma: Right.
[16:46] <Peng_> Now, bzr isn't the fastest vcs ever, but you have to give it *some* credit. :P
[16:47] <jinRooma> its the only vcs i have used, for some reason could not get my around sub version and cvs
[16:47] <jinRooma> but im using it mainly for back up than versioning
[16:48] <jinRooma> ... which is primitive but better than nothing
[16:48] <jelmer> LarstiQ, any idea what could cause a versionedfile revision to end up with the same parent twice?
[16:49] <jelmer> get_parent_map() seems to filter out the duplicate parent unfortunately, but add_lines() complains
[16:52] <jinRooma> i should probably use rsync or some such for my needs
[16:55] <LarstiQ> jelmer: I don't know, but yesterday I got my bzr.dev in a state where I can't revert because I have two parents or some such
[17:45] <Peng_> Does anyone else care about my bzr.dev tarballs, or can I delete them now? bvk?
[17:47] <bvk> Peng_: you can delete it now; thanks a lot
[17:47] <bvk> :)
[17:48] <Peng_> bvk: Alright.
[18:11] <Lo-lan-do> jelmer: Back to 28, I'm afraid :-/
[18:12] <Lo-lan-do> (Report sent, off for dinner, back later if you have any insights)
[18:19] <jelmer> Lo-lan-do, :-(*
[18:19] <jelmer> rocky, hi
[18:19] <jelmer> rocky, I've worked around the bug you were seeing, but I think it's a bug in bzr.
[18:19] <rocky> jelmer: heyo
[18:19] <jelmer> (not committed to 0.5, as it degrades performance, especially on large trees)
[18:20] <jelmer> http://samba.org/~jelmer/tmp/test-text-existance.diff
[18:20] <rocky> hm
[18:21] <jelmer> hopefully one of the australians can shed some light on the actual problem when they wake up
[18:23] <rocky> hehe
[18:24] <jelmer> alternatively, there's a one-line fix to bzr that will work around it without any performance regressions
[18:24] <jelmer> Lo-lan-do, ENOBUGREPORT
[18:26] <bvk> hi, is there any bzr plugin that would allow me to maintain bugs (and messages) within the code repository?
[18:30] <jelmer> bvk, You mean something like be (BugsEverywhere)?
[18:31] <jelmer> see bugseverywhere.org
[18:31] <bvk> jelmer: well, i don't know about bugseverywhere; let me check it out
[18:33] <jelmer> rocky, alternative test http://samba.org/~jelmer/tmp/fix-add-records-dupe-test.diff
[18:39] <bvk> jelmer: yes, it is what i was looking for. thanks
[18:47] <mwhudson> LarstiQ: i'd actually just noticed something similar the other day
[18:47] <mwhudson> LarstiQ: file a bug, i guess
[19:20] <Lo-lan-do> jelmer: http://bugs.debian.org/512325
[19:20] <jelmer> Lo-lan-do, thanks, just found it
[19:21] <jelmer> I'm trying an import now, at r6132 atm
[19:21] <Lo-lan-do> I was puzzled by the fact that it copies something like 11k revisions even though there are less than 7k in the SVN repo.
[19:22] <jelmer> Lo-lan-do, Some svn revisions probably cause multiple bzr revisions
[19:23] <Lo-lan-do> I supposed that much.  Like, maybe some commits touched files in several branches at once.
[19:23] <Lo-lan-do> Not very important anyway.
[19:25] <flacoste> i've got a problem with bzr-svn repository
[19:25] <jelmer> hi flacoste
[19:25] <flacoste> hi jelmer!
[19:25] <flacoste> I have a bzr-svn branch tracking Windmill repository
[19:25] <flacoste> they moved to a failover server
[19:25] <flacoste> and now I get the following error when I do bzr pull
[19:26] <flacoste> http://svn.getwindmill.com/trunk is permanently redirected to http://svn.getwindmill.com/trunk/
[19:26] <flacoste> bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ("Chemin '/windmill/!svn/vcc/default' non trouv\xc3\xa9", 175007)
[19:26] <flacoste> i can load the URL in the browser fine
[19:27] <flacoste> In English, the message reads "Path '...' not found"
[19:27] <jelmer> flacoste, This fails for me as well:
[19:27] <jelmer> svn ls http://svn.getwindmill.com/trunk/
[19:27] <flacoste> hmm, yeah, they just found that out :-)
[19:28] <flacoste> ok, it's probably an error on their end then
[19:28] <flacoste> sorry for the noise
[19:29] <jelmer> np
[19:52] <jelmer> Lo-lan-do, did you remove the svn-cache as well as the bzr repository prior to trying the import?
[19:53] <Lo-lan-do> Ah, damn.  No, I didn't.  Should I do that?
[19:54]  * Lo-lan-do tries
[19:54] <lifeless> -> LCA
[19:54] <lifeless> jelmer: compressbench may interest you, for your xdelta apply/create code
[19:55] <lifeless> Jc2k: did you see my gc stats?
[19:55] <jelmer> lifeless, 'morning
[19:55] <jelmer> Lo-lan-do, oh, never mind
[19:55] <jelmer> Lo-lan-do, just reproduced it
[19:55] <jelmer> lifeless, cool, I'll have a look
[19:55] <jelmer> lifeless, still there?
[19:55] <Jc2k> lifeless: yes
[19:55] <jelmer> lifeless, quick question about knits
[19:55] <Jc2k> lifeless: my reply was something like "omg thats groupcompress?!?"
[19:56] <lifeless> Jc2k: :)
[19:56] <jelmer> lifeless: what are the contents of node_refs ? The first part of the tuple are the parents of the text, what is the second?
[19:56] <lifeless> jelmer: node refs in indices is a list of lists of keys
[19:56] <lifeless> jelmer: for knit mapped packs
[19:57] <lifeless> jelmer: if the knit is defined with parents=True, delta=True, then the node refs length is 2, the first element is parents, the second is the compression tree
[19:57] <lifeless> jelmer: in all bzr repositories, the second must be either empty, or the first parent.
[19:57] <Peng_> lifeless: "-> LCA"?
[19:57] <lifeless> but its intended to be arbitrary
[19:57] <lifeless> Peng_: linux.conf.au
[19:57] <Peng_> Oh.
[19:57] <lifeless> jelmer: just not implemented yet
[19:58] <lifeless> jelmer: if delta=False, parents=True, the node refs length is 1, parents only
[19:58] <lifeless> jelmer: and False False is length 0
[19:58] <jelmer> lifeless, I'm seeing weird errors where add_record() crashes because the existing node_refs[1] contains the first parent and we're trying to add node_refs[1] that is an empty tuple
[19:58] <lifeless> jelmer: finally, delta=True, parents=False, is unimplemented in knits today
[19:59] <lifeless> jelmer: thats when one repository has a text compressed, and the other has a full text. The cross check is overly strict - that is a bug
[19:59] <flacoste> jelmer: they fixed it, but now when I bzr pull, it's refetching everything
[19:59] <Peng_> lifeless: I wanted to bug you about something: One of my bzr-svn branches makes "bzr index" die, with "Did not find ids set([some file IDs])".
[19:59] <lifeless> Peng_: please file a bug
[19:59] <Peng_> lifeless: Alright.
[20:00] <lifeless> Peng_: I'll ask you to run some custom code based on the details in the bug report, but I have a plane to catch now, so can't do it interactively
[20:00] <jelmer> lifeless, Ah, thanks!
[20:00] <jelmer> flacoste, did the repository change in some way ? Did you upgrade bzr-svn?
[20:01] <flacoste> jelmer: you mean the SVN repository, i don't think so, and I haven't update bzr-svn in a while
[20:02] <flacoste> jelmer: actually, i don't know if it will create new BZR revisions
[20:02] <flacoste> the message is
[20:02] <flacoste> Initialising Subversion metadata cache in /home/francis/.bazaar/svn-cache/7915dd7d-006c-436d-aff2-976aa4ca8641
[20:02] <flacoste> and then fetching all revisions
[20:02] <flacoste> but if that metadata is keyed by hostname, then i guess it would be normal
[20:02] <flacoste> to refetch everything
[20:03] <lifeless> flacoste: thats the svn repo uuid
[20:03] <flacoste> the question is, will this create new bzr revisions
[20:03] <lifeless> flacoste: its stored in the repository
[20:03] <lifeless> flacoste: and yes
[20:03] <flacoste> ok, so copying the repository files should preserve the UUID?
[20:03] <lifeless> flacoste: I'm not sure exactly where it is stored, so can't answer that
[20:03] <flacoste> "It's a scripted mirror of the original repo, so it should be the same."
[20:04] <lifeless> god, that could mean anything
[20:05] <flacoste> they are using svnsync
[20:06] <Jc2k> flacoste: by default svnsync would have a different UUID, but i have a hack on bzr-mirror to preserve the UUID
[20:06] <flacoste> Jc2k: can this help me?
[20:07] <flacoste> i mean can I use this to trick bzr-svn in considering the two UUIDs as identical
[20:08] <Peng_> Wow, "bzr check" sure spams .bzr.log.
[20:10] <Jc2k> flacoste: i dont know enough about what you are encountering
[20:10] <Kittens> hm...
[20:11] <flacoste> Jc2k: i have a bzr-svn branch of Windmil and the main server became unavailable, they had to switch to a failover mirror
[20:11] <flacoste> Jc2k: now when I do a bzr pull, it refetches every revision although there should only be about 4 or 5 that I don't have
[20:12] <Jc2k> ah.
[20:12] <flacoste> and I get:
[20:12] <flacoste> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[20:12] <flacoste> but that's not accurate
[20:12] <Jc2k> their failover mirror will have a different UUID; do you know if you can svnsync from their mirror?
[20:13] <flacoste> i don't know, i could check
[20:13] <flacoste> how would that help?
[20:13] <jelmer> flacoste: Do you have any local changes? If not, you can just "bzr pull --overwrite"
[20:14] <jelmer> flacoste, if you had a svn checkout I think you would get errors as well since the UUID of the repository changed
[20:14] <flacoste> i don't, ok, i'll do this
[20:16] <Lo-lan-do> Does svnsync preserve the uuid?
[20:16] <jelmer> Lo-lan-do, not by default I think
[20:17] <flacoste> jelmer: but will this break merging?
[20:17] <Peng_> jelmer: With the fix for bug 308353, will bzr-svn create any particularly convoluted history?
[20:17] <jelmer> flacoste, merging from where?
[20:18] <Peng_> jelmer: Because that's what breaks bzr-search. :)
[20:18] <flacoste> jelmer: for example, if I merge the new branch into one made from the previous repository
[20:18] <Peng_> lifeless: Filed bug 318935.
[20:18] <jelmer> flacoste, that will break, since they are fundamentally different repositories
[20:19] <flacoste> damn
[20:19] <flacoste> anyway to hack it?
[20:20] <jelmer> flacoste: Fix the upstream repository
[20:20] <flacoste> and is there an easy way to do this?
[20:20] <Lo-lan-do> jelmer: You're right.  But one can hack the mirror's UUID by hand, according to http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt
[20:20] <flacoste> using svnsync?
[20:20] <flacoste> aha
[20:21] <jelmer> flacoste, svnadmin setuuid can do that for you
[20:23] <jelmer> Peng_, Not that I'm aware of
[20:24] <guilhembi> vila: still there?
[20:25] <flacoste> jelmer: setuuid is only a 1.5 command and they are running 1.4 :-(
[20:26] <Lo-lan-do> flacoste: What about "vi db/uuid"?
[20:26] <flacoste> Lo-lan-do: is that safe?
[20:26] <Lo-lan-do> It may not be safe at all, I have no idea.
[20:26] <flacoste> lol
[20:26] <Lo-lan-do> It's just that the uuid seems to be stored there.
[20:26] <Lo-lan-do> If it's *only* stored there, then my guess is that it's safe, but...
[20:28] <LarstiQ> Lo-lan-do: seems like it's time for some experimenting! ;)
[20:28] <Lo-lan-do> Yeah, I'm currently "experimenting" with grep -r :-)
[20:28] <Lo-lan-do> Only one result.  db/uuid.
[20:29] <Lo-lan-do> Maybe it is safe after all.
[20:29] <LarstiQ> what about the svnadmin setuuid source?
[20:30] <wgrant> Lo-lan-do: I edited db/uuid in a fresh repository recently, and it worked fine.
[20:30] <Lo-lan-do> I'll read that too, although I don't really care for it (I was only asking about uuids out of curiosity).
[20:30] <flacoste> http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html
[20:30]  * Lo-lan-do deflects stuff to flacoste 
[20:30] <flacoste> there is a solution ^^^
[20:33] <Lo-lan-do> LarstiQ: The source code has so many layers of indirection I gave up.
[20:33] <wgrant> I think one of my branches has suffered from bug #302698. Shall I just push my local copy, overwriting the remote branch?
[21:25] <alevine> anybody have experience with bzreclipse? When I import a project by branching it, it seems to freeze
[21:38] <guilhembi> vila: sent a mail. Bonne nuit!
[21:47] <Necoro> hey - is it possible to get the branch status w/o invoking bzr? - or at least to implement such things in C f.ex.
[21:47] <Necoro> because I want to display whether a bzr branch has been changed in my shell prompt
[21:48] <Necoro> and invoking bzr for this is way too slow
[21:48] <jelmer> Necoro, no you really need bzr for that
[21:48] <jelmer> you may be able to use the bzr service stuff though
[21:48] <Necoro> (I already managed to get rid of the "bzr nick" and "bzr revno" calls)
[21:48] <jelmer> (keeps bzr running in the background and makes incremental calls faster)
[21:49] <Necoro> "bzr service stuff" <-- sounds interesting ...
[21:49] <Necoro> documentation somewhere?
[21:49] <jelmer> launchpad.net/bzr-service I think
[21:53] <Jc2k> jelmer: wow, someone already made the crack i was daydreaming about!!
[21:54] <jelmer> Jc2k, the ssh stuff you mean?
[21:55] <Jc2k> jelmer: no, bzr-service!
[21:55] <jelmer> ahh
[21:55] <jelmer> where someone is jam I think
[21:55] <Necoro> hmm - bzr-service seems to be outdated though
[21:56] <Jc2k> yes :(
[21:59] <Jc2k> hmm, didnt take much to make it work again tho
[22:00] <Necoro> I needed to deal a bit with imports ... but as I don't know the bzrlib API, this can only be counted as workaround
[22:00] <Necoro> it's fast however
[22:01] <Necoro> instead of using TCP/Unix Sockets/FIFOs one could also implement this using DBus
[22:02] <Necoro> (at least for unix)
[22:02] <mwhudson> bzr-service needs more unix crack related to pty's and pipes
[22:02] <Necoro> which would also allow to omit explicitly starting the service ;)
[22:02] <Jc2k> i just added an import bzrlib and killed the call trace.something and it worked
[22:14] <sevenseeker> I have been making changes to various files and just noticed I accidentally deleted an entire directory
[22:14] <sevenseeker> how do I restore it and keep my changes?
[22:15] <mwhudson> does bzr revert directory-you-deleted work?
[22:15] <beuno> mwhudson, I think that if the directory isn't there, bzr will barf
[22:15] <beuno> maybe not barf, but not do what you'd expect  :)
[22:16] <sevenseeker> aha, yes... I don't know what I fat fingered earlier but it works great
[22:16]  * sevenseeker is embarrased
[22:16] <sevenseeker> thanks
[22:17] <Necoro> hmm ... my shell prompt now works ;)
[22:17] <Necoro> though there are still some rough edges with bzr-service
[22:28] <alevine> how can I import an authenticated svn repo into bzr? when I try I get a 401 error and when I add username@ I get a traceback
[22:29] <Necoro> and I guess, I'll take the bzr-service client instead of bzr whenever possible ;)
[22:29] <Necoro> should be much faster
[22:32] <jelmer> alevine, prefix the URL with "svn+"
[22:33] <alevine> jelmer, thanks so much. did i miss something in documentation?
[22:33] <alevine> it says its deprecated
[22:34] <alevine> or is it just the fact that it cant figure out that it's subversion because it is authenticated
[22:35] <jelmer> alevine, yeah, it's deprecated - it's a workaround around a bug in bzr itself
[22:37] <Necoro> perhaps bzr-service should get polished and directly integrated into bzr ... this will probably be sufficient to reduce the "bzr is sooo slow" voices a bit
[22:37] <alevine> jelmer, good to know i really appreciate you being here to tell me that
[22:37] <jelmer> alevine, np
[22:38] <jelmer> Necoro, bzr-service has several issues, I think they're mentioned on the main page
[22:39] <Necoro> jelmer: only "unsecure" and "works only on windows" ... if you accept the last one as "who cares", the first one should be easy to fix
[22:40] <Necoro> s/only/not/
[22:40] <jelmer> Necoro: bzr service will run under a different terminal
[22:40] <jelmer> that causes several problems for e.g. the GUI tools
[22:41] <jelmer> and I doubt it supports overriding environment variables right now
[22:42] <Necoro> hmm ok
[22:55] <alevine> jelmer, do you happen to know if branching an svn repo will download every file for every revision regardless of it has changed or not
[22:56] <jelmer> alevine, It will not download files when they have not changed
[22:58] <alevine> hm, ok. thanks
[23:25] <thumper> igc: I've confirmed with bzr.dev that log --line doesn't show non-mainline revs for me now
[23:41] <_raz_> does anyone know why the .bzr dir and files have a wrong mode in 1.10?
[23:42] <_raz_> I cannot do a brnch or pull on the remote directory via ftp
[23:43] <_raz_> as it seems, the files have no rights at all, directories only u+rwx
[23:43] <_raz_> according to the launchpad tracker that was already fixed