[00:17] <lifeless> abentley: pon
[00:18] <abentley> So I started hacking on per-file base selection yesterday, and I found a locality-of-reference problem.
[00:18] <lifeless> ok
[00:18] <abentley> The file content is stored in the versionedfile.  The file type is stored in the inventory.
[00:19] <abentley> So to do it absolutely correctly, I'd have to retrieve all the trees for the selected revisions.
[00:20] <abentley> Because the selected revision may not be a file-- it may be a directory, symlink or tree reference.
[00:21] <lifeless> ok
[00:21] <lifeless> I see
[00:21] <lifeless> now, if the kind is the same on both tips
[00:21] <lifeless> does that make it easier ?
[00:21] <abentley> In fact, we're already assuming it's a file on both tips.  Otherwise, we wouldn't need a base at all.
[00:22] <lifeless> so if its the same on both tips
[00:22] <lifeless> 3-way merge says that if the base is a different kind
[00:22] <lifeless>  -> we'd treat is as empty of the same kind ?
[00:23] <abentley> Not quite.  We'd still emit foo.BASE in the correct kind.  But wrt the file merge, yes.
[00:24] <lifeless> now symlinks and dirs have an existing empty text for their revisions
[00:25] <abentley> AFAIK, correct.
[00:25] <abentley> So we can shortcut the kind check 99% of the time.
[00:25] <lifeless> so; and I realise this is hacky;
[00:26] <lifeless> if doing a 3-way custom base on two currently-file-texts, w.get_lines(custom_base) will give us [] when the kind has changed.
[00:27] <abentley> I hate to have it shortcutted 99% of the time, though.  It makes me fear the full path won't get adequately tested.
[00:27] <lifeless> are you doing custom bases for symlinks and dirs too?
[00:28] <abentley> No.  Those will get handled by the standard merger, which also handles inventory issues such as renames and executability.
[00:29] <abentley> I don't think those things change enough to require the same care as text files.
[00:30] <lifeless> so I guess I'm saying; if we're only doing custom base on (text, text) pairs; and get_lines(custom_base) will always return a suitable set of lines, ([] when the common base has a different kind), then its not a shutcut situation
[00:31] <abentley> By shortcut, I mean that we're avoiding retrieving the file kind from the relevant inventory.
[00:31] <abentley> But in the case where it's [], we will have to do so.
[00:32] <lifeless> I don't see that we ever need the file kind for the base if the parents are both texts; other than to write foo.BASE.
[00:32] <abentley> Right.  But we will have to write foo.BASE.
[00:32] <lifeless> ok
[00:32] <lifeless> so lets look at that
[00:32] <lifeless> we write foo.BASE when we ended up doing a merge right
[00:33] <abentley> Right.
[00:33] <lifeless> now, will we avoid doing 'merges' sometimes with custom file bases ?
[00:34] <abentley> No, but if the BASE is not a file, we will do a two-way merge between THIS and OTHER.
[00:34] <lifeless> which is where [] is useful because it's just a clean degradde.
[00:35] <abentley> A clean what?
[00:35] <lifeless> degrade
[00:35] <lifeless> it's what 3-way degrades too
[00:35] <abentley> Okay.
[00:35] <lifeless> hmm, one sec local interrupt
[00:39] <lifeless> back
[00:40] <lifeless> wondering if we will ever get base == left or base == right with custom merge bases
[00:40] <lifeless> I think we can
[00:40] <lifeless> consider this
[00:41] <lifeless> at the graph level we have two lca's
[00:41] <lifeless> so we recurse
[00:41] <lifeless> its easy then for at the file level for one side to be purely an extension of the other for a single file
[00:41] <lifeless> so when we are considering that single file we'll not need to merge at all
[00:42] <lifeless> I'm going to think out lout now
[00:42] <lifeless> and enumerate what I think the possible cases are
[00:43] <lifeless> * Base is one side (common I suspect in criss-cross merges; many files won't be actually unmerges)
[00:43] <lifeless> * Base is the revision the graph level base had
[00:44] <lifeless> * Base is another inventory
[00:44] <lifeless> s/another inventory/from &/
[00:44] <lifeless> done
[00:54] <lifeless> abentley: ^
[01:03] <josep17> buenas noches
[01:03] <josep17> desde venezuela
[02:24] <abentley> lifeless: I would expect base==left or base==right to be rare.  But I would imagine we can get it.  I'm not sure why it matters.
[02:25] <abentley> We need a general solution.
[02:27] <abentley> Sure, I can hack up something gross to do per-file bases, but I think you ought to consider how an upcoming repo format could give us cheap access to file kind, symlink target, and maybe execute bit.
[02:27] <abentley> Right now, I'm re-implementing annotate merge, and it's going swimmingly.
[02:50] <jelmer> dato: resubmitting bzr-svn fixed it
[02:50] <jelmer> dato: your upload of 0.4.4-2 hadn't been processed yet, apparently
[03:19] <abentley> jelmer: Have you noticed that the bzr-gtk test suite is completely borked if run as part of the bazaar test suite?
[03:25] <lifeless> abentley: I'm pretty sure I hit it all the time.
[03:25] <lifeless> abentley: anyhow, our current format can give use kind/target/execute quite cheaply
[03:25] <lifeless> abentley: just use the same parse-a-delta-fragment logic.
[03:27] <abentley> Oy.  Can't we do up a format where that works by design instead of being a tremendous hack?
[03:28] <lifeless> abentley: yes, both the ones poolie and I have been fiddling/mailing about will work by design
[03:29] <abentley> Awesome.
[03:29] <lifeless> abentley: but they largely formalise useful properties we have been able to leverage from the current format.
[03:30] <lifeless> abentley: I have been thinking that content object information should be pushed down to the per file graph anyhow; as metadata on the node
[03:32] <abentley> Well, I know the new format will do comparisons much faster, but that sounds like it would slow them down.
[03:42] <lifeless> abentley: I'm thinking some duplication actually
[03:42] <lifeless> abentley: but also there is locality of data possibilities.
[03:42] <lifeless> abentley: this would be a 2nd or 3rd iteration out.
[03:42] <lifeless> abentley: one possibility is:
[03:42] <abentley> Oh, by "pushing down", I thought you'd be taking it out of the inventory.
[03:43] <lifeless> kind + exec + content in the 'knit'
[03:47] <lifeless> inventory has parent + name + pointer to the knit version
[03:47] <lifeless> 'knit' index can pull kind + exec into it.
[03:48] <lifeless> abentley: the open things in my mind about whether this makes sense are what datum we actually need at the same time
[03:50] <abentley> For our tree-manipulation functions, we generally use inventory and file texts simultaneously.
[03:51] <abentley> When building a tree, to create a file, we need file_id, name, parent, kind, execute bit, and content basically simultaneously.
[03:52] <abentley> That's not a hard requirement.  TreeTransform could work efficiently if you learned names, parents and file-ids in one pass, and everything else in a second pass.
[03:58] <lifeless> abentley: so its the case of status/diff when the last-mod is different and the value is the same that would be hurt
[03:58] <lifeless> abentley: -> how common is that
[03:58] <lifeless> (assuming we don't want false positives for st
[03:59] <lifeless> another possibility here though is to decouple the metadata graph from the content graph
[03:59] <abentley> This is assuming we're not diffing against a DirstateRevisionTree?
[03:59] <lifeless> right
[03:59] <abentley> So we wouldn't have the md5sum in the inventory?
[04:00] <lifeless> so you'd have (fileid, parentid, name, content-pointer[revid, validator]) as a graph
[04:00] <lifeless> and (kind, exec, content) as a graph
[04:00] <abentley> I'm not sure at all how common that is.  Merges can produce it, though.
[04:00] <lifeless> you'd have a sha1, but not of the lines, of the lines & kind and exec bit
[04:01] <lifeless> this would for instance, allow us to start only storing one copy of 'COPYING' etc, depending on how we want to take it.
[04:01] <lifeless> this is all still wildly speculative
[04:01] <abentley> I don't think kind is a big concern.  If it changes, we definitely need to get all the data.
[04:03] <abentley> I dunno, though.  I think having all the data in the inventory might well be a win.
[04:04] <lifeless> I'd like to be in a position to experiment
[04:04] <abentley> Just because there are many operations that just want to know which files changed.
[04:04] <lifeless> write some arbitrary benchmarks outside bzr that simulate access patterns and the like
[04:06] <lifeless> maybe this is something we can reason about in march
[04:17] <abentley> Also, some stats on real trees might help us answer these questions about what's common better.
[04:27] <lifeless> abentley: indeed. So having an analyser that can report what a transformed tree would look like would be good
[04:28] <abentley> I'm not sure what you have in mind.  The PreviewTree thing?
[04:28] <lifeless> nah
[04:28] <lifeless> just a script to take a branch
[04:29] <lifeless> and break it out into the things I'm talking about, without doing disk transformations, just in-memory, and report
[04:30] <abentley> Oh, to simulate a changed repo format?
[04:30] <lifeless> right
[04:50] <jelmer> lifeless: what breaks about it?
[04:50] <jelmer> s/lifeless/abentley/
[04:51] <jelmer> ah, I see
[05:16] <lifeless> meh
[05:16] <lifeless> sorry about disappearing; what did I not respond to
[05:16] <Odd_Bloke> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[05:16] <Odd_Bloke> 05:03:21 -!- lifeless [n=robertc@ppp245-86.static.internode.on.net] has quit [Read error: 113 (No route to host)]
[05:16] <Odd_Bloke> 05:15:45 -!- lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr
[05:16] <Odd_Bloke> Oops, got the trackbar.
[05:17] <Odd_Bloke> But yeah, nothing. :p
[05:17] <lifeless> thanks
[08:07] <alecwh> hello, I'm considering using bazaar for a project of mine... we're using subversion right now, because subversion is offered on Google Code, and Gna! (http://gna.org). Are there any free repository hosts that our GPL program can use (using bazaar)?
[08:08] <beuno> alecwh, sure, https://launchpad.net/
[08:08] <beuno> it also works as a bug tracker
[08:09] <beuno> (and a bunch of other stuff)
[08:09] <alecwh> no way... it hosts a free bazaar repository? that's awesome.
[08:10] <alecwh> how do I set it up?
[08:10] <alecwh> https://code.launchpad.net/phpns/
[08:10] <alecwh> This is our project
[08:10] <alecwh> Register branch?
[08:17] <beuno> alecwh, let me fetch you a how-to real quick
[08:17] <Peng> Hmm. I just started using LP a bit. I should look into the launchpad plugin.
[08:18] <beuno> alecwh, https://help.launchpad.net/FeatureHighlights/BazaarHosting might help a bit
[08:19] <beuno> but you basically just push to the right address with bzr
[08:19] <beuno> and the branch gets created
[08:19] <beuno> the folks at #launchpad might be able to give you more details though
[08:20] <beuno> it's a bit over 5am here, so I'm going to bed
[08:20] <beuno> good luck  :D
[08:21] <alecwh> ok, thanks a lot bueno. ;_
[08:21] <alecwh> ;)
[08:23] <Peng> Might be even simpler using lp: URIs.
[09:19] <Peng> New Pyrex release.
[09:32] <alecwh> How do I import a subversion repository into a bazaar repository?
[09:33] <Peng> alecwh: You could use bzr-svn.
[09:34] <alecwh> what does that do?
[09:34] <Peng> alecwh: bzr-svn can even allow pushing from bzr to svn. It's pretty neat.
[09:34] <Peng> alecwh: Well, for one thing, it imports svn repos into bzr repos.
[09:34] <alecwh> yeah, that's what I'm looking for. =D
[09:34] <alecwh> how does that look like?
[09:34] <alecwh> the bash command.
[09:35] <Peng> Not sure.
[09:35] <Peng> "bzr branch" might do it.
[09:35] <Peng> Read the docs.
[09:35] <alecwh> ok, thanks Peng. =)
[09:47] <lifeless> alecwh: www.bazaar-vcs.org/svn IIRC
[09:47] <alecwh> This page does not exist yet. You can create a new empty page, or use one of the page templates.
[09:47] <alecwh> lifeless: I got that error.
[09:48] <lifeless> alecwh: there is a link on it
[09:48] <lifeless> alecwh: to BzrSvn :)
[09:48] <alecwh> ok, thanks lifeless. I'll read over it.
[09:50] <JordanC> Hey there
[09:50] <JordanC> Tried to get things working with olive, but no dice/
[09:50] <alecwh> hey JordanC. =D
[09:52] <Odd_Bloke> JordanC: Define 'no dice'. :p
[09:53] <alecwh> Odd_Bloke: It didn't work.
[09:53] <Odd_Bloke> Yeah, I got that much. :p  I was hoping for something a little for specific. :D
[09:53] <Odd_Bloke> s/for/more/
[09:55] <JordanC> I came in here a while back, and yeah
[09:55] <Odd_Bloke> JordanC: Are you using Olive or bzr-gtk?
[09:55] <JordanC> I spoke to some developers, and they said that because of the SSH factor, I can't connect to launchpad using olive
[09:55] <Odd_Bloke> Ah, OK.
[09:55] <Odd_Bloke> Have you looked at QBzr?
[09:56] <JordanC> Hmm, lesee
[09:56] <JordanC> KDE Bazaar proggy?
[09:57] <Odd_Bloke> JordanC: http://bazaar-vcs.org/QBzr
[09:57] <luks> no, in two ways
[09:57] <Odd_Bloke> Qt, not KDE.
[09:57] <luks> not a program, not kde
[09:57] <JordanC> Damnit
[13:01] <ronny> yo
[13:01] <ronny> is there a way to get more easy to parse output from bzr ?
[13:02] <ronny> (im parsing the status output for an ide, an its really tricky to get it together atm)
[13:22] <Odd_Bloke> ronny: There's an xmloutput plugin, I believe.
[13:22] <Odd_Bloke> ronny: https://edge.launchpad.net/bzr-xmloutput
[13:22] <Odd_Bloke> ronny: Which IDE were you thinking of?
[13:22] <abentley> luks: I'm looking at your patch more carefully now.
[13:23] <luks> thanks :)
[13:23] <abentley> I think a nicer way to extract the name would be to have a pattern that only matches if there's "name <email>", and if it fails to match, just return the original string.
[13:24] <ronny> Odd_Bloke: pida
[13:24] <luks> well, I think returning "email" from short_author is better than "<email>"
[13:25] <luks> unless you want to match "(name )?<email>", which is exactly what the patch does
[13:25] <abentley> I think that's highly unlikely.
[13:25] <ronny> Odd_Bloke: right now we parse the command output, cause the subsystem for python-api based vcs tools is basically nonexistant
[13:26] <luks> abentley, "<email>" is the use case from the bug report
[13:27] <ronny> the bad thig is - we get wrong data sometimes, but cant figure the exact source, cause the bzr output aint nice to parse (so the parser is tricky)
[13:27] <abentley> Also, I don't know if lazy_regex was meant to be used in new code.
[13:27] <abentley> I thought it was just to make existing code faster.
[13:28] <abentley> And I really doubt there's a performance win by using it.
[13:29] <luks> but what's the point of compiling a regular expession you are not going to use
[13:29] <luks> sure, it's not a big win, but there is a lot of small things like this
[13:29] <abentley> There's no win, there's loss in compiling a regular expresion.  I was talking about not compiling at all.
[13:30] <luks> hm? you mean parsing the string manually?
[13:31] <abentley> no, just using re.match
[13:31] <luks> that compiles it every time you use it
[13:31] <abentley> Right.
[13:31] <luks> so about 3k times for log on bzr
[13:32] <ronny> actually its cached
[13:32] <abentley> luks: I really doubt that performance difference is observable.
[13:33] <ronny> the more often a re is used, the more sense it makes just to compile it
[13:34] <ronny> but the difference is only small, cause all re's u use are cached in re._cache
[13:37] <luks> abentley, I mean, bzrlib already has code to delay regex compilation, pre-compiled regex is faster than re.match, there is a patch that use it -- why make is slower? even if the difference is small
[13:37] <abentley> Because it's clearer to just write re.match
[13:38] <abentley> Takes fewer lines.  Doesn't require people to grok lazy_regex.
[13:38] <ronny> hmm - how does lazy_regex work ?
[13:39] <luks> compiles the regex when it's first used
[13:40] <luks> *first time
[13:40] <ronny> im more intrested how the store works
[13:40] <ronny> cause i doubt it has any notable gain compared to re.match
[13:42] <abentley> ronny: It allows the "lazy_compiled" patterns to be substituted for really compiled patterns-- that's what it's for.
[13:42] <abentley> So you can fix import slowness without rewriting the module.
[13:43] <ronny> "import slowness" ?
[13:43] <abentley> regexes that compile at import time reduce cause latency problems for programs like Bazaar.
[13:44] <abentley> You run bzr, it imports a whole bunch of modules, they compile a whole bunch of regexes, and then, finally, it starts doing what you asked.
[13:45] <ronny> hmm - why do you guys need so many regexes ?
[13:45] <abentley> The libraries we import need them.
[13:47] <abentley> (well, they *have* them.  *need* is debatable)
[13:47] <ronny> btw - any timeframe when bzr will be as fast as hg ?
[13:47] <abentley> For example ConfigObj has regexes that produce a noticeable compile delay.
[13:48] <abentley> ronny: It depends what you're talking about.  With the packs format, commit speed is pretty similar.  With the smart server, pull time is similar.
[13:49] <abentley> status has been comparable for some time now.
[13:50] <ronny> ah - so its mostly cause bzr has tonns of other operation modes ?
[13:50] <abentley> Well, it depends what operation you want to speed up.
[13:51] <ronny> all i care for is fast sync and fast commit
[13:51] <abentley> I think 1.0 will give you that.
[13:52] <ronny> hmm - i didnt exactly use bzr for quite some time
[13:53] <ronny> does it still try hide the existence of multiple heads (for example by allways enforcing merges)
[13:53] <abentley> I think we've got the pieces in place to support good performance for most commands.
[13:53] <abentley> I don't know what you mean by hiding the existence of multiple heads.
[13:54] <abentley> But in some cases, the commands must be updated to take advantage of them.
[13:54] <ronny> last time i used it it dodnt allowme to hae multiple heads in my repo
[13:55] <abentley> Repositories typically have many heads due to people uncommitting revisions.
[13:55] <abentley> But we don't have multiple heads for a single branch.  Instead we allow multiple branches per repository.
[13:56] <ronny> hmmk - thats a problem for me
[13:56] <abentley> Why?
[13:58] <ronny> enforces me to split one semantical branch into multiple branches if more than one person is working on that
[13:58] <abentley> No, they can use heavyweight checkouts.
[13:58] <Odd_Bloke> ronny: That's what you're doing with multiple heads anyways...
[13:58] <abentley> That lets them commit locally.
[13:59] <abentley> And then sync up with the main branch when they're ready.
[13:59] <ronny> damn - how many modes of operation does bzr have ????
[14:00] <abentley> We support a range from svn-like to fully distributed.
[14:00] <ronny> hmm - having too many choices tends to be confusing
[14:04] <abentley> Well, we have three: a "tree" has a branch and working copy at the same location.  A "heavyweight checkout" has a branch in one location and the working copy is at different location, but has a local copy of the branch to act as cache.  A lightweight checkout is like a heavyweight checkout with no local cache.
[19:28] <alecwh> I just created a bazaar branch at launchpad (https://code.launchpad.net/~alecwh/phpns/devel), and now I want to upload my project (which is in /var/www/devel) to the repository. In the terminal, my working directory is /var/www/devel, and I gave the command:  bzr push bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel , but it doesn't seem to be working. I get the error: bzr: ERROR: Not a branch: /var/www/devel/ , can anyone help me upload
[19:29] <luks> cd /var/www/devel; bzr init; bzr add; (check if it added only files you want); bzr commit
[19:30] <luks> and then you can use bzr push
[19:30] <luks> http://doc.bazaar-vcs.org/bzr.0.92/en/mini-tutorial/index.html#putting-files-under-version-control
[19:31] <alecwh> ok, I'll try that. will 'bzr add' add every single directory and file inside /var/www/devel?
[19:31] <lifeless> moin
[19:31] <alecwh> moin?
[19:35] <lifeless> alecwh: yes, add adds recursively, obeying your ignore rules
[19:36] <alecwh> thanks lifeless. I've got one more question: when I was using svn, every 'commit' you made actually uploaded your changes to the online repository. Is this not the case with bazaar?
[19:37] <lifeless> alecwh: if you have a checkout it acts like svn
[19:38] <alecwh> a checkout?
[19:38] <lifeless> alecwh: that is, if you do 'bzr checkout bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel local-dir-name'
[19:38] <lifeless> then you can cd local-dir-name, and do
[19:38] <alecwh> that will download the project, right?
[19:38] <lifeless> 'bzr commit', which will commit back to bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel, just like svn
[19:38] <alecwh> oh.
[19:39] <beuno> alecwh, or, when you want to send all your commits, just use "bzr push"
[19:39] <lifeless> alecwh: if you have a separate 'branch' though, then your commits are performed just on your machine
[19:39] <alecwh> ok, that makes sense.
[19:39] <alecwh> https://code.launchpad.net/~alecwh/phpns/devel
[19:39] <beuno> (when using branches instead of checkouts)
[19:39] <alecwh> I just finished uploading everything...
[19:39] <lifeless> alecwh: and then when you want them to be in bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel, you do 'bzr push bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel' (bzr will remember the push location the first time, so you don't need to type it every time0
[19:40] <alecwh> how do I make it so every time I 'commit' it will update this repository?
[19:40] <lifeless> alecwh: bzr bind bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel
[19:40] <alecwh> ok lifeless, that worked. =D
[19:41] <alecwh> I was using 'cia.vc', which puts a bot inside your channel on freenode, and then it will post a message inside the channel whenever a commit/change is made. Is there something like this for bazaar?
[19:42] <lifeless> alecwh: there is a plugin for bzr to announce to cia
[19:42] <lifeless> alecwh: you can also subscribe to the branches on launchpad
[19:42] <lifeless> alecwh: or install bzr-email to send emails to arbitrary email address's on commits
[19:43] <alecwh> ok, cool. Do you know what the plugin was called? I'm just looking for it...
[19:44] <lifeless> http://www.google.com/search?q=bzr+cia&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:official&client=firefox-a
[19:44] <lifeless> 3rd and 4th hits look relevant to me
[19:46] <alecwh> https://launchpad.net/bzr-cia
[19:50] <alecwh> lifeless, uhm, how do I get the plugin? =P
[19:51] <beuno> alecwh, with bzr, of course  :D
[19:52] <alecwh> https://code.launchpad.net/~jelmer/bzr-cia/main
[19:52] <alecwh> is this the one I'm looking for?
[19:52] <beuno> alecwh, yeap
[19:52] <alecwh> bzr branch http://bazaar.launchpad.net/~jelmer/bzr-cia/main?
[19:52] <alecwh> use that command?
[19:53] <beuno> alecwh, yeah, you download it with that command
[19:53] <alecwh> ok, done. =D
[19:53] <alecwh> I think I got it now
[19:53] <beuno> now, follow the instructions in: https://launchpad.net/bzr-cia
[22:17] <lifeless> success; we have a 1.0 build on dapper-amd64
[22:17] <lifeless> i386 testing now
[22:17] <lifeless> brb foodstuff time
[22:34] <dato> jelmer: very well
[22:35] <dato> jelmer: btw, I guess there is no way to convert from svn a trunk and a branch, if I somehow say which revisions from the trunk are merges from the branch, right?
[22:40] <jelmer> dato: only if you can go back in history and set some magic svn properties
[22:40] <dato> jelmer: can I a dump of the repository, load it locally, set the properties there, and redump? that ought to work?
[22:42] <jelmer> dato: yes, but you would want to change the uuid
[22:42] <dato> ok. is there a document explaining what properties I should set?
[22:43] <jelmer> and pulling from the original in the future may be problematic
[22:43] <jelmer> http://bazaar-vcs.org/BzrForeignBranches/Subversion/mapping
[22:46] <jelmer> basically, you'd want to set the bzr:ancestry:vX-SCHEME property
[22:47] <lifeless> dato: is it really worth doing? why not just do a merge after the conversion?
[22:47] <dato> jelmer: it's a one-time conversion
[22:48] <dato> lifeless: I seem to find a strange pleasure fiddling with the tools.
[22:49] <lifeless> dato: :)
[22:53] <dato> jelmer: ok, thanks for the link. I'll try to do it. also, I svn-import trunk didn't work for me yesterday, but the packaged version worked fine. I'll try again tomorrow. finally ;), changing the UUID is just a matter of editing the dumpfile by hand, or?
[23:08] <jelmer> dato: the trunk branch for bzr-svn is highly experimental
[23:08] <jelmer> dato: 0.4 is the branch that is packaged
[23:09] <jelmer> dato: yep, editing the dumpfile should be all that's needed to change the uuid
[23:09] <abentley> lifeless: What do you consider a good way to decide if something should be a separate module or not?
[23:11] <abentley> I was expecting plan_merge to be bigger than it is, which is why I originally did it.
[23:11] <lifeless> abentley: I don't have a good rule; sometimes I get there and combine; sometimes I start in the same module and split.
[23:13] <vila> wtf ? test_revision.TestIsAncestor.test_is_ancestor is failing just under the comment:
[23:13] <vila>         # NB: if you see an assertion error here, its probably access against
[23:13] <vila>         # an unlocked repo. Naughty.
[23:13] <abentley> I guess by analogy, I'd think if merge3 has its own module, then annotate merge can have one, too.
[23:14] <vila> the problem is I'm working on http response parsing rewrite and I can't find any link >-/
[23:15] <vila> Worse, the same test on bzr.dev@3059 fails too, midnight bug ?
[23:16] <vila> and on top of that, I see (when doing bzr missing in my bzr.dev branch) revno: 3061, deprecate bzrlib.revision.is_ancestor
[23:18] <vila> Ran 9939 tests in 437.020s
[23:18] <vila> FAILED (failures=1, known_failure_count=5)
[23:19] <vila> bah, time to sleep anyway, a bit frustrating though
[23:21] <vila> not failing anymore in bzr.dev@3065... at least....
[23:27] <lifeless> jelmer: where is bzr-gtk for 1.0 ?
[23:30] <lifeless> abentley: oh it can have one if you think it should; I was asking the question.
[23:31] <abentley> Sure, and I've actually decided to move them into versionedfile and merge.
[23:31] <abentley> Just because there's so much related stuff in those modules.
[23:49] <jelmer> lifeless: phanatic is doing release management these days, I'll ping him by email