[00:00] <luke-jr> mwhudson: I mean when I 'rm a', 'bzr status' lists it as deleted and 'bzr commit' removes it from the repository
[00:00] <luke-jr> I don't want that.
[00:00] <luke-jr> rather, I want bzr to leave it alone like svn does
[00:03] <lifeless> luke-jr: there isn't a global option for this at the moment. I wanted to make it be like svn but got shot down on the mailing list
[00:03] <luke-jr> wtf ☹
[00:03] <luke-jr> is there a not-so-global option?
[00:03] <lifeless> luke-jr: you can supply --strict to commit, and it will cause missing files to be considered an error
[00:04] <luke-jr> no way to automatically use --strict?
[00:04] <luke-jr> wait, an error? ☹
[00:04] <luke-jr> why can't it just ignore it⁇
[00:04] <ScottK> Is there a bzr command that just pushes back where the code was pulled from?
[00:04] <lifeless> ScottK: bzr push :parent
[00:04] <ScottK> lifeless: Thanks.
[00:06] <lifeless> luke-jr: well its code, anything is possible. I'm just describing what the current code does, and that I wanted to make new files and missing files be treated symmetrically, but didn't manage to get consensus on the list for this
[00:06] <lifeless> luke-jr: you're welcome to dig up that thread and post referring to it. Support from users would be good :P
[00:08] <fullermd> You could automatically use strict by just setting up an alias.
[00:09] <luke-jr> fullermd: an error blocks commits, I presume-
[00:09] <luke-jr> I just want the files not present in my WC
[00:09] <luke-jr> yet not delete them from the repo
[00:09] <luke-jr> and still be able to commit changes
[00:10] <mwhudson> oh well, that's less likely to win favour
[00:10] <mwhudson> the idea of commit is that it records what's on disk
[00:11] <luke-jr> it doesn't go trying to add my temp note files]
[00:11] <luke-jr> -.-
[00:11] <mwhudson> true, that's why i have commit --strict on by default...
[00:11] <luke-jr> …
[00:12] <luke-jr> so how do I get that?
[00:12] <luke-jr> better an error than remove I suppose
[00:14] <lifeless> luke-jr: there is a plan, for 'views' which will be a WT setting that says what files to have present on disk; when that is implemented you could use it to get rid of some files from disk without having commit remove them from the branch
[00:14] <lifeless> luke-jr: its not implemented yet, I'm just letting you know that its planned
[00:46] <delaney> is there anyway to make local commits the default with TortoiseBzr?
[01:07] <lifeless> http://paste.ubuntu.com/108059/ - currnet knit vs gc with 1G corpus
[01:09] <mwhudson> seems a bit better :)
[01:09] <mwhudson> is the "how do we make gc stream" question addressed yet?
[01:10] <NfNitLoop> are there known issues with bzr blame?
[01:10] <NfNitLoop> I ran blame on a repo that I've branched from svn.
[01:10] <NfNitLoop> bzr blame says a line was last changed in r1
[01:10] <NfNitLoop> but when I svn blame the repo, I find otherwise.
[01:11] <NfNitLoop> (yes, I know svn rev#s are different from bzr rev#s)
[01:12] <NfNitLoop> What I seen in svn is that the line has been changed since it was created.   bzr blame leads me to believe that it has been the same since its initial revision.
[01:12] <spiv> NfNitLoop: no issues like that.
[01:13] <spiv> NfNitLoop: but bzr-svn will have recalculated all the diffs between revisions.
[01:13] <lifeless> mwhudson: well, just compress on the fly
[01:13] <spiv> NfNitLoop: and so it's possible that it's calculated a different (but equivalent) diff to svn for the same change to a file
[01:13] <lifeless> mwhudson: (as one possible answer)
[01:14] <NfNitLoop> OOOoooh.
[01:14] <NfNitLoop> Yes, I see, spiv.  Thanks.
[01:14] <NfNitLoop> The file was copied in svn.
[01:15] <spiv> NfNitLoop: e.g. consider four lines "aabb" becoming "bbaa"
[01:15] <NfNitLoop> and svn keeps the history through copies.
[01:15] <NfNitLoop> and, IIRC, bzr doesn't?
[01:15] <spiv> NfNitLoop: did "aa" get deleted and re-added, or did the "bb" lines get deleted and re-added :)
[01:15] <spiv> NfNitLoop: oh, yes, that too.
[01:15] <NfNitLoop> yeah, that's it.
[01:17] <NfNitLoop> the diff is pretty simple.   one line's boolean is getting switched between "true" and "false".
[01:17] <NfNitLoop> with no justification in comments or commit messages.
[01:18] <NfNitLoop> Anyway, thanks for the help!
[01:35] <luke-jr> does 'bzr mv' work with bzr-svn right, or does it just add?
[02:17] <enkrates794> I filed a bug about a week ago and got a response asking for more info. I provided the info, but I'm not sure if I should do something else in launchpad to get a further response. Could someone take a look at the bug and let me know if I've missed something? https://bugs.launchpad.net/bzr/+bug/316196
[02:19] <alevine> what's the easiest way to make a personal bzr repo that can be shared (preferably over http)?
[02:19] <alevine> with subversion I used the apache module
[02:22] <tecan> i have problems with bzr
[02:23] <nDuff> alevine, just push your repository to somewhere some web server is sharing
[02:23] <nDuff> alevine, no special web server module needed.
[02:23] <nDuff> alevine, (though if you want more performance, a "smart server" is available).
[02:23] <tecan> suse came with bzr 1.8 but i installed 1.6 and now everything is more complicated
[02:23] <alevine> nDuff, push it over...ssh?
[02:24] <tecan> its probably python 2.6 issues
[02:24] <alevine> thats very cool
[02:24] <nDuff> alevine, ...it's fairly common to use SFTP for uploads (yes, pushes or bound commits) and let third parties use HTTP to download.
[02:24] <asabil> alevine: you must know that http is way way slower than the smart protocols
[02:25] <nDuff> tecan, could you be more specific about the issues you're seeing? "everything is more complicated" isn't very actionable. :)
[02:25] <mwhudson> tecan: new bzr's work with 2.6, but 1.6 isn't very new
[02:25] <alevine> nDuff, asabil: thanks, performance is not an issue, mostly just for myself and for sharing code every once in a while
[02:28] <tecan> there is no where to download the latest tarballs ?
[02:28] <tecan> 1.6 is the latest i can get the source to
[02:31] <luke-jr> …
[02:32] <nDuff> tecan, http://bazaar-vcs.org/
[02:32] <nDuff> erk
[02:35] <luke-jr> so what's the deal with file copies anyhow?
[02:35] <luke-jr> such a simple feature has no progress for years?
[02:37] <nDuff> luke-jr, merge semantics become *much* complicated when one supports copies -- such that one pretty much *has* to do unintuitive things some of the time.
[02:37] <nDuff> luke-jr, there's a pretty good argument to be made that supporting features that require you to do unintuitive things is bad.
[02:37] <nDuff> s/features/"features"/
[02:42]  * igc lunch
[02:42] <nDuff> luke-jr, ...I can see supporting copies inasmuch as "create a new file which looks at this old one for purposes of blame and log operations", and that's probably a pretty reasonable feature request...
[02:43] <thumper> where can I find the default ignore list?
[02:43] <thumper> as in the files that are ignored by default
[02:43] <nDuff> luke-jr, ...but having merges not change the new version under any circumstances probably isn't end-user-intuitive behavior either.
[02:46] <nDuff> thumper, ~/.bazaar/ignore
[02:50] <thumper> nDuff: ta
[02:56] <thumper> anyone know where the bzr svg icon lives?
[02:56] <thumper> I want it for a presentation
[02:59] <jam> http://bazaar-vcs.org/Icons I think
[02:59] <jam> thumper: http://bazaar-vcs.org/LogoOptions
[02:59] <thumper> jam: fantastic, ta
[03:01] <thumper> jam: is there an svg without the text?
[03:01] <jam> thumper along the bottom
[03:01] <jam> bazaar192.svg?
[03:02] <jam> or you can look here: http://bazaar-vcs.org/LogoOptions?action=AttachFile
[03:02] <jam> there seem to be quite a few .svg files
[03:30] <luke-jr> nDuff: screw merge stuff, that's secondary to actually recording a copy
[03:33] <nDuff> luke-jr, ...if you tell users you'll record a copy but don't then give them the behavior they expect when merging between a branch where a copy happened and a branch where the file was changed (whatever that "behavior they expect" may be), that's just asking for surprised/unhappy users. Heck, there'd be likely folks who'd expect copy+rm to behave the same way as a mv -- lots of other SCMs do it that way, after all.
[03:34] <nDuff> ...but anyhow, it's been discussed on list; see the thread [RFC] Tracking file copies
[03:34] <luke-jr> cp+rm = mv
[03:36] <nDuff> ...so are changes in the original going to impact copies on merge or not? (And, more to the point, will changes in the *copies* impact the *original* on cherrypick? If so, which copy?) "Only if the original has since been deleted" means you've got a new set of corner cases.
[03:38] <nDuff> converting cp+rm to mv *only if the original was deleted within the same commit* is a reasonable behavior, but it's not quite the same thing as the generalization cp+rm=mv.
[03:38] <luke-jr> changes to both copies could be merged
[03:39] <luke-jr> creating conflicts if necessary
[03:39] <nDuff> whether that's appropriate depends on why you did the copy. If you're copying a template out to create a new file you're going to modify, merging changes from the new versions back to the template is absolutely wrong behavior.
[03:40] <luke-jr> yes, ok
[03:40] <luke-jr> so cp+rm might not always be = mv
[03:40] <luke-jr> so keep cp+rm separate from mv
[03:40] <nDuff> anyhow, see the mailing list thread
[03:41] <luke-jr> how about just having changes to a copied file depend on the copy changeset?
[03:43] <luke-jr> IMO, cherry picking is a less needed feature than copying
[03:50] <nDuff> luke-jr, well, you might ask jelmer how the spec is coming along sometime.
[03:52] <thumper> is there a nice page explaining how to get bzr working with eclipse?
[03:52] <thumper> I have some pug people asking
[03:52] <thumper> and I don't use eclipse
[03:55] <luke-jr> thumper: open a terminal and Alt-Tab
[03:55] <luke-jr> (why anyone would use eclipse is beyond me, it sucks)
[03:55]  * thumper looks strangly at luke-jr
[03:55] <nDuff> there's a bzr plugin for Eclipse
[03:55] <thumper> nDuff: yes there is
[03:56] <thumper> nDuff: is it packaged for ubuntu?
[03:56] <nDuff> ...though I haven't used it recently; last time I tried, it didn't support linked resources. (They've fixed that since, but not early enough for my purposes)
[03:56] <thumper> is bzr-xmloutput?
[03:58]  * thumper wishes for bzr-eclipse and bzr-xmloutput to live in the ~bzr PPA
[07:12] <vila> hi all
[07:38] <tecan>  ERROR: The user tecan has not registered any SSH keys with Launchpad.
[07:38] <tecan> how do i fix this ?
[07:40] <bob2> login via the web interface and add an ssh key
[07:41] <tecan> where
[07:41] <tecan> i dont see ssh anywhere
[07:43] <tecan> oh o found it
[07:48] <kiko-zzz> morning
[07:52] <tecan> morneng
[08:34] <awilkins> Where is the keyserver where Launchpad keeps it's PPA signing keys? The latest bzr packages are signed with keys I can't find and apt is refusing to associate with them :-)
[08:38] <igc> ping vila
[08:38] <vila> igc: pong
[08:38] <igc> vila: any thoughts on jam's comments re log --include-merges option naming?
[08:39] <igc> he voted tweak but I think we should get the name right first
[08:39] <igc> in particular, how useful would depth control be?
[08:39] <igc> e.g. ..
[08:39] <igc> log -n1 => flat
[08:39] <vila> which thread ? I'm a bit out of loop on log for the last few days :-/
[08:40] <igc> log -n0 => fully nested
[08:40]  * igc looks
[08:40] <vila> I read that I think, I'd prefer --merge_depth to be: 0: flat, -1 fully nested or something like that
[08:40] <fullermd> You mean depth like how many levels deep to show merges?
[08:41] <vila> i.e. matching our internal merge_depth so that it can be used more broadly
[08:41] <vila> fullermd: yes
[08:41] <fullermd> That strikes me as way too fiddly.  It seems like you'd need really contrived cases for a user to actually know what to do with it other than "none" or "all".
[08:42] <vila> I encounter the use case yesterday in a loom where I wanted mainline but at depth 1
[08:42] <igc> vila:https://lists.ubuntu.com/archives/bazaar/2009q1/051802.html
[08:43] <igc> fullermd: it a shame we don't have optional parameter values to options
[08:43] <igc> then log --nested could mean all
[08:43] <vila> and depending on the workflow you use I'm sure there are other such use cases *other* than mainline of full
[08:43] <vila> s/mainline of full/mainline or full/
[08:43] <fullermd> Well, you could add a --nest-level to supplement it.  That's not a major objection.
[08:44] <igc> and log --nested=2 could mean show just 2 levels (total or beyond the mainline depending on one's thought pattern)
[08:44] <fullermd> Yah, but it seems like it would have to be a very specific workflow, AND you'd have to know that it was universally followed.
[08:45] <vila> igc: Ha ! That thread ! Exactly the one I wanted to comment in priority
[08:45] <igc> fullermd: with PQM not showing the real author, I think was suggesting looking down just one level would be nice
[08:45] <fullermd> IMO, by the time you have the need and environment to be able to do that level of control, you're in a position to also want much more control over the rest of the output too.
[08:45] <vila> So, first of all, I still think we should refactor log to be able to pass parameters to log formatters *before* adding generic parameters to log
[08:46] <vila> i.e. not all parameters all relevant for all log formatters
[08:47] <igc> vila: I'm still not sure about that
[08:47] <vila> Second: I think there are more ways to select and present the revisions than just mainline and full, in the broader perspective, any sub-graph may be interesting
[08:47] <igc> vila: I think it ought to be simple for a plugin to define a new LogFormatter like "email" or "xml"
[08:47] <vila> oops, forget Second for a moment then, let's discuss first first
[08:48] <igc> and making every log-formatter see most parameters seems to be introducing complexity to the "create a new LogFormatter" process
[08:48] <vila> IMHO LogFormatter deals mainly with formatting *one* revision and everybody tends to think about them only in that context
[08:49] <vila> That's no the entire truth
[08:49] <igc> vila: also, I think the immediate priorities need to be:
[08:49] <vila> LogFormatter also deals wiht the graph of revisions they are presenting
[08:49] <igc> * make it fast so people can use it on large projects
[08:49] <igc> * provide the blatantly missing functionality (like log DIR)
[08:50] <vila> igc: I understand your priorities, that's one reason I stepped back on refactoring log (the other main one being that I had an already full plate with other issues and my changes to log can stay private for the time being)
[08:51] <vila> Regarding your priorities, "fast" can be done without refactoring, "DIR" I don't think so
[08:51] <igc> vila: I'm not rejecting your idea, I just don't want to hold up improvements than are arguably orthogonal
[08:52] <vila> igc: full agreement
[08:52] <igc> vila: so returning to my UI question, I think fullermd's suggestion has merit: namely ...
[08:52] <vila> but I think *some* of them are not that orthogonal :)
[08:53] <igc> leave the option called --include-merges (and add --nest_level later)
[08:53] <jelmer> luke-jr, That's a known bug in that rc, should be fixed in the 0.5 branch
[08:54] <vila> My main concern is that IMHO we're introducing options that we may deprecate later or force some log formatters to handle things they don't want to care about
[08:54] <igc> vila: but perhaps the LogFormatter constructor should take a nest_level now.
[08:54] <igc> understood
[08:55] <igc> but it's pretty damn easy given depth is a field in every record passed to a LOgFormatter to format
[08:55] <vila> igc: nest_level to constructor sounds good to me
[08:56] <igc> checking if n <= m isn't more complex than if prefer_merge_revisions IMO
[08:56] <fullermd> Can't the formatters just eat whatever args you give them and only bother looking at the ones they care about?
[08:57] <fullermd> It seems insane to have to explicitly add each possible arg, even if they'll never care about it...
[08:57] <vila> if it's under log formatter control I'm happy enough, it means they can decide to handle the option or not, or even reject the option
[08:57] <igc> but it implies lots of common filtering code repeated in each log formatter
[08:58] <vila> fullermd: we are not there yet, but the idea is to pass unprocessed option to log formatter which in turn can pass back unprocessed option for error handling
[08:58] <igc> rather than a log formatter having a clear responsibility, i.e. "format this record"
[08:58] <vila> igc: that's why we want a base class with all the utilities !
[08:59] <vila> You're back to reducing log formatter to "format this record" that's not their only responsibility IMHO
[08:59] <igc> it is currently
[08:59] <igc> they don't really so a graph ...
[08:59] <vila> no it isn't : look at begin_log end_log
[08:59] <igc> just a sequence of tuples (including a depth field)
[09:00] <igc> begin_log and end_log are hooks as I understand them for opening/closing headers/footers, yes?
[09:00] <vila> of course the LogRevision are called in sequence but that's also a part that could/should go under the lf responsability
[09:00] <igc> and/or opening/closing resources perhaps
[09:01] <vila> That's why I say the lf responsability is currently unclear, parts of it being implemented by the log module, I think that's wrong and blurry things
[09:02] <vila> igc: Have a look at the xnloutput Log Formatter for example
[09:03]  * igc looks
[09:04] <vila> It's a lf that consider itself responsible for the whole log display, not only each individual revision display, because it must balance the xml flags for each level
[09:04] <vila> so it must understand the whole graph (or tree if you prefer)
[09:05] <vila> You can argue that it could just use depth as an attribute and just format the whole as just a sequence...
[09:06] <vila> ...but that's not the point I'm trying to make :-)
[09:06] <igc> right
[09:06] <igc> so begin_log & end_log put out the <log> and </log> markers
[09:06] <igc> the rest looks like the usual HTML formatting dance :-)
[09:07] <igc> i.e. balancing of tags while outputting nested lists
[09:08] <vila> i.e. taking care of the whole formatting not only of the "format this record"
[09:08] <vila> that's my point
[09:10] <vila> end-log do a bit more than just putting out the </logs>  (not <log>) marker, there is a stack to purge to
[09:10] <igc> it's format-this-record-in-the-context-of-what-I've-seen-already and ...
[09:10] <igc> unwind levels as we step outwards
[09:10] <vila> you can stop there, you said context
[09:11] <igc> vila: I guess I'm asking ...
[09:11] <igc> why would passing more to the log formatter help it?
[09:11] <igc> we don't pass through end-of-merge for example
[09:12] <igc> vila: would that make things easier say?
[09:12] <vila> what is end-of-merge ?
[09:13] <igc> a True/False field generated by tsort.merge_sort (along with rev-id, depth & revno)
[09:13] <igc> I suspect having it would help much
[09:13] <igc> it's not until you see the *next* depth that xmlformat will know the amount of levels to unwind
[09:14] <igc> s/would/wouldn't/
[09:14] <vila> I think that giving more responbilities to lf, will make it easier them to access the data they need instead of relying on the log module to format them in a generic way
[09:16] <vila> Being able to decide at the lf level what 'revision' parameter is valid or not sounds like a solution to several problems you tried to address recently
[09:17] <vila> igc: Won't you be happier with get_view_revisions being specific to a log formatter ?
[09:18] <igc> I'll be happier when get_view_revision goes!
[09:18] <igc> it's a crap API!
[09:18] <vila> I think that will make the include_merges parameter useless for example
[09:18] <vila> igc: great, delegate to lf will make it less crap
[09:19] <igc> true, but so will fixing it :-)
[09:20] <igc> the mainline rev, revnos and include_merge parameters are all unnecessary IMO
[09:20] <igc> Branch.iter_merge_revisions is the way forward I feel
[09:21] <vila> except for the fact you need them to be reasonably fast, I entirely agree :)
[09:21] <vila> i.e. they are implementation details
[09:22] <vila> Branch.iter_merge_revisions ? IS there where you use a reverse parameter ?
[09:22] <igc> jam wanted a reverse parameter to it and I've submitted a patch along those lines but ...
[09:22] <igc> I'm not sold yet on reverse being meaningful at that level
[09:22] <vila> Can we please, please, stop using 'reverse', 'forward' and 'backward' have a meaning by themselves 'reverse'... always makes me wonders
[09:23] <igc> true
[09:23] <igc> so currently, reverse in log & missing calls sort_by_depth
[09:24] <vila> hmm, more than just that I think
[09:24] <igc> That feels a bit too fancy for Branch.iter_merge_revisions where forward/backwards makes a lot more sense
[09:25] <vila> off-topic forward without 's' and backwards with 's' always /
[09:25] <vila> s!/!?!
[09:25] <vila> lol, perl is noise :)
[09:25] <igc> no, I meant forward/backward
[09:26] <vila> ooh, you mean 'reverse' as used at UI level, I was meaning internally also
[09:26] <igc> vlia: anyhow, I need to have dinner now
[09:26] <igc> vila:^^
[09:26] <vila> Enjoy your dinner :)
[09:27] <igc> so you're ok with --include-merges at the UI level & preferred_depth at the LogFormatter API level?
[09:27] <igc> vila:^
[09:28] <vila> why preferred  instead of just depth ?
[09:28] <vila> I'm ok for --include-merges
[09:28] <igc> you're right, just depth is good
[09:29] <igc> or levels
[09:29] <vila> Overall: I'm globally ok with your modifications anyway, it's just that I think some of them may be simpler *after* refactoring and some of them may make refactoring *harder*
[09:29] <vila> But since you'r the one spending the time on it, you get to choose :)
[09:29] <igc> :-)
[09:30] <vila> igc: And I'm perfectly fine that
[09:30] <vila> igc: And I'm perfectly fine with that
[09:30] <igc> cool - time to go. Thanks for the chat
[09:30] <vila> You're welcome
[09:45] <vila> jam: Ha ! Look who is blocking pqm now ! Welcome to the club :-)
[09:51] <NET||abuse> hi guys.. basic usage question, i've a little project on my laptop, i'm concerned for the hardware, how do i clone up to my server for backup? can i just sftp copy the whole versioned directory(working copy i guess) straight up to the server?
[09:51] <NET||abuse> or do i need to use a bzr instruction to do so?
[09:52] <pygi> NET||abuse, either bzr branch whateva on server works, or you can sftp things
[09:52] <pygi> or bzr push from local to server
[09:52] <NET||abuse> hmm, ok
[09:52] <NET||abuse> i'll have a look at it.
[09:59] <NET||abuse> hmm, missing page in the bzr docs,, http://bazaar-vcs.org/Scenarios/NewProject
[09:59] <pygi> NET||abuse, that Scenarios page is new :)
[09:59] <pygi> we're yet to work on it ;)
[10:02] <NET||abuse> so i can push to my server where it has no bzr repo setup, initi'd yet
[10:06] <vila> herb: It looks like you're the only losa around, can you have a look at PQM please ?
[10:06] <vila> herb: I meant when you come online...
[10:08] <NET||abuse> hmm, ok so branch from my local to remote doesn't work,, i did bzr branch ./ svn+ssh://me@host/path/to/new/bzr/dir    and it throws error "bzr: ERROR: No repository present:"
[10:10] <NET||abuse> What i'm looking to do is move my current standalone branch on my local laptop, up to a dir on my webserver, and then have that act as the main branch for my work, i will be opening it up to someone else next week, so need it up there, and also worried my laptop is about to croak
[10:11] <NET||abuse> it's gotta a discreet nvidia NVS135M card in it, they're known to have issues, this is my 1st replacement from dell, the first one died and 5 engineer visits didn't fix it, so they just gave me whole new model, now last night during 10,000 bc :) the screen glitched like the last one had started to before it died...
[10:11] <NET||abuse> not good.
[10:18] <fullermd> I don't think you can branch into SVN...
[10:20] <fullermd> I don't even know if branch CAN target somewhere remote.  Used to definitely not; can't remember if that was changed or not.
[10:20] <fullermd> Generally you just push anyway.
[10:28] <NET||abuse> umm, you see this is why i need to ask,, yeh, svn+ssh,, oops,, i'm not looking to push to svn, was looking to make a new bzr repo... so i just tried bzr ./ bzr+ssh://me@host/path/to/repo/to/create   and it didn't like it,, error unkown command 'server' connection closed: please check connectivity and permissions
[10:29] <NET||abuse> unknown command wasn't 'server' just 'serve'   still the error stands...
[10:30] <NET||abuse> so last effort,, i just tar.gz up the bzr repo directory,, then upload it.
[10:30] <NET||abuse> extract it on the remote server then try to point my local to it.
[10:30] <NET||abuse> or will they conflict? would i have to re clone/branch from the server back down to my local machine?
[10:34] <fullermd> Unknown command serve?  That sounds like a *REALLY* old bzr on the far side...
[10:35] <fullermd> Taring it up should work just fine for backing it up.
[10:39] <NET||abuse> fullermd: yeh, the far side is the old LTS ubuntu, dapper i think?
[10:39] <spm> vila: what seems to be the problem? One of your submissions appears to have succeeded about 20 minutes ago?
[10:40] <vila> spm: thanks for looking in to it, it looked like last *jam* submission was blocking the pqm, mine was just waiting
[10:40] <vila> spm: things seems fine now
[10:40] <vila> spm: did you do anything ?
[10:41] <spm> vila: cool. apart from looking? no. :-) Easiest fix I've done in ages :-)
[10:41] <vila> spm: pqm is just afraid by you then :)
[10:41] <spm> heh
[10:42] <vila> Or may be *I* just misread or read too soon...
[10:43] <spm> shrug - is no matter. when it gets stuck it's pretty easy to unstick - better to keep things flowing
[10:48] <dr_barnowl> fullermd: You can branch into SVN
[10:49] <dr_barnowl> fullermd: I had to "svn-versionize" a list of dated archive folders recently, which I did by committing them to bzr branches and pushing them to svn
[10:54] <fullermd> Well, I know you can push them in.  I mean I don't think you can use _branch_ to do it.
[10:54] <fullermd> (actually, I thought you couldn't use push either, and there was some other command to create one ab ovo)
[10:57] <wgrant> You have to use bzr svn-push to create a new branch.
[11:00] <clemente> In latest bzr.dev:  File "/home/w/bzr/oficial/bzrlib/ui/__init__.py", line 237, in make_ui_for_terminal:  UnboundLocalError: local variable 'cls' referenced before assignment
[11:19] <vila> clemente: thanks, fix is on its way
[11:37] <nua> hi I'm having real trouble starting the bzr server, it breaks and I get a traceback: http://pastebin.com/m66382410
[11:37] <nua> I'm using the standard install for ubuntu 8.10
[11:38] <nua> which reports to be bzr 1.6.1
[11:42] <lifeless> thats a bug in bzr-dbus which has been fixed since that release
[11:42] <lifeless> either uninstall bzr-dbus, or upgrade it, or have dbus running
[11:48] <ScottK> Sounds like a good SRU candidate then.
[11:52] <nua> hmm, now I'm just getting address already in use, I think that other attempt is still using it
[12:02] <frk2> hello all
[12:02] <frk2> had a question regarding the use of hooks in bazaar
[12:06] <frk2> Im using a shared repository arch
[12:06] <frk2> so basically everyone commits to a singular server
[12:07] <frk2> to send commit notifications out do i have to configure bzr-email on every single desktop?
[12:07] <frk2> configuring on the remote repo in .bzr/branch/branch.conf does not seem to work, configuring locally does
[12:13] <lifeless> bzr-email on te server, and push via bzr+ssh should work just fine
[12:13] <lifeless> gnight all
[12:13] <frk2> but a bound commit does not
[12:14] <frk2> lifeless,  i can try to push and see if that works. But I have the branch bound to the server- a commit does not help
[12:14] <frk2> guess you have gone off to bed :) gnite
[12:22] <Jc2k> frk2: you could try bzr-hookless-email as a workaround in the mean time
[12:22] <frk2> Jc2k, whats that?
[12:23] <Jc2k> frk2: it uses inotify (or just run it very frequently in cron) and looks at what changed and generates emails
[12:24] <frk2> is it part of bzr tools now?
[12:24] <Jc2k> no
[12:24] <frk2> so get it from lp directly?
[12:25] <Jc2k> bzr branch lp:bzr-hookless-email
[12:25] <Jc2k> its not a plugin, so no need to put it in .bazaar/plugins or anything
[12:25] <Jc2k> i've not used it myself, but i think debian are using it for their commit emails
[12:31] <frk2> Jc2k, got it running- am guessing it uses sendmail or something to actually send the email
[12:32] <Jc2k> frk2: its based on bzr-email, so imagine its the same kind of thing as that
[12:33] <mtaylor> lifeless: coupla quick things about stacked branches... --stacked-on=lp:~mordred/wafflegrid/5.1-upstream doesn't work - doesn't recognize lp: syntax ... and also, that fails, so the push aborts, but not before it creates _something_ on launchpad
[12:55] <nua> I add the bzr PPA and got the latest version, all working fine now
[12:56] <nua> I was wondering how I require log-in to access the repositories if I'm using bzr serve? it seems like anyone can checkout the code
[12:58] <frk2> nua, you do not, i think
[12:58] <frk2> thats why its read obly
[12:58] <frk2> only
[12:58] <frk2> unless explicitly enabled
[12:58] <frk2> i use bzr+ssh
[12:59] <nua> ok, so I basically have to use bzr+ssh if I want authentication?
[12:59] <nua> that's ok, but it means I get really ugly urls
[13:00] <frk2> AFAIK, yes
[13:00] <nua> would I create an ssh account for each collaborator (I'd rather not) or could I force them to use a single bzr user and authenticate on their ssh keys?
[13:07] <nua> frk2: what about https?
[13:12] <awilkins> nua: You can use http and your http server will take care of auth for you if you configure it
[13:13] <nua> awilkins: ok thanks, I think I'll give that a go
[13:13] <awilkins> nua: ssh also works with a single ssh user as long as you put each users public key on your authorized_keys file
[13:14] <nua> awilkins: I think http sounds like the most sensible route
[13:15] <awilkins> nua: It's very easy for read-only access
[13:15] <awilkins> nua: It'll work out of a dumb http server ; write-access takes a little more work
[13:15] <nua> awilkins: I can run a smart http server by using bzr+http:// right?
[13:16] <awilkins> nua: You can _access_ a smart server by specifying bzr+http://
[13:16] <awilkins> nua: To run one you need to configure the server to pass requests to bazaar through WSGI
[13:17] <nua> awilkins: ok, but I can write to the sever over http/https?
[13:17] <awilkins> nua: Yes, as long as the smart server is configured
[13:18] <awilkins> Which web server are you using?
[13:18] <nua> awilkins: I usually use apache or lighttpd... just looking at which to set up now
[13:19] <nua> awilkins: do you know of any guides on how to set up bzr smart server and http?
[13:19] <awilkins> I wrote the page at http://bazaar-vcs.org/ServerGuide/IIS
[13:19] <awilkins> I think there are hints for apache in the docus somewhere
[13:20] <awilkins> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id80
[13:20] <nua> awilkins: yeah, just found that :)
[13:21] <awilkins> I had to fix the code to make it work with IIS :-)
[13:21] <awilkins> Half IIS's fault though
[13:26] <vila> haaa, just finish talking with igc, saw lifeless less than an hour ago, now poolie is joining... Did I enter the TZ ? (Twilight Zone :)
[13:26] <vila> Hi poolie :-)
[13:29] <poolie1> hello vila
[13:33] <igc> hi poolie
[13:33] <igc> jam: thanks for the review re the dotted_revno_to_revision_id patch. Much appreciated
[13:33] <poolie> hello igc, you're up late
[13:33] <poolie> i think
[13:34] <igc> poolie: my hours are all the place right now
[13:34] <igc> 7am start yesterday, 6am finish, hospital visit in between
[13:35] <igc> I sleep when I tired currently
[13:36] <igc> jam: I'd also love a review of the iter_merge_sorted_revision patch if you have time/interest
[14:09] <igc> poolie: re log --include-merges, I think I'd prefer log --levels N to control how many levels are displayed
[14:10] <igc> N=0 would be "all of them"; N=1 would be a flat list
[14:10] <igc> together with a shorthand of -n, I think it would work well ...
[14:11] <igc> e.g. log -n1 seems better than log --no-include-merges
[14:11] <igc> likewise log --short -n0 is easier than log --short --include-merges
[14:12] <igc> also, when logging from a merge revision, it's the number of levels down that matters, not mainline vs merge revision display
[14:12] <igc> poolie, jam: thoughts?
[14:13] <igc> fullermd suggested having both --include-merges and nest_levels
[14:13] <igc> once we have the latter though, the former seem redundant
[14:13] <aquarius> I had a conflict in my branch when I merged another branch into it, on a file foo/bar/baz. I've done "bzr rm foo" (it doesn't need to be there any more), but bzr still says the conflict is present
[14:14] <aquarius> how do I unconfuse it (and me)?
[14:14] <poolie> poolie: that sounds nice, um
[14:14] <poolie> i would have thought -n0 means "no" :-)
[14:14] <poolie> actually seriously 0 means "none"
[14:15] <poolie> also, being indented one level does not precisely correspond to "one step away" in the actions the user took
[14:15] <poolie> though arguably it does when you pull the dag around a bit
[14:15] <poolie> shorter options == better
[14:19] <poolie> does that help at all?
[14:28] <igc> poolie: I think 0 meaning all is ok; asking for zero levels isn't very useful :-)
[14:28] <poolie> ah
[14:28] <poolie> if you're counting from kind of column zero on the screen
[14:28] <poolie> then yes
[14:28] <igc> well, for log at least!
[14:29] <igc> so I guess we can have n mean either total number of levels or number of nested levels
[14:29] <igc> do you have a preference?
[14:30] <igc> if # of nested levels, then -n0 means flat & we need a # or symbol for all
[14:31] <igc> log -n all is actually ok btw
[14:31] <igc> we don't have int options, just strings we parse into ints it turns out
[14:31] <igc> poolie: ^^
[14:32] <igc> n fact, -n all would work regardless of what exact semantics we gave the numbers
[14:33] <poolie> igc, that makes sense, i think -n0 is nice and short to type to mean everything
[14:33] <igc> me too
[14:33] <poolie> so -n0 would be the default?
[14:33] <igc> it's format specific
[14:34] <igc> the -n just overrides the default
[14:34] <igc> that way we keep c ompatibility for existing users
[14:35] <poolie> ok
[14:35] <poolie> sounds good
[14:35] <igc> internally, -1 will mean "let the format decide" and it will be the default
[14:41] <luke-jr> jelmer: which bug?
[14:42] <bakunin> I'm trying out bzr on my Windows box towards our Subversion repository, but I haven't been able to find out how you specify username and password towards the subversion repository. Any pointers to documentation about this?
[14:46] <luke-jr> jelmer: isn't the difference between "Fix Committed" and "Fix Released" that the latter is actually in a release?
[14:50] <luke-jr> jelmer: BTW, any chance we can get a 'bzr svn-cp' or such that pushes a 'svn cp' upstream? >_<
[14:51] <luke-jr> maybe represent it in bzr through a 'copied from' property or such
[14:51] <luke-jr> (until it has proper copy support)
[15:04] <vila> igc: catching up ! +1 +1 +1 for -n !! Including 0 for all
[15:04] <igc> vila: thanks. I think it will work well
[15:04] <vila> I also prefer that to having several options
[15:08] <vila> igc: "internally, -1 will mean "let the format decide" and it will be the default" :-)
[15:08] <vila> Let the format decide ftw ! :-)
[15:08] <igc> and for backwards compatibility :-)
[15:09] <vila> same boat ! More room to improve other lfs :-)
[16:26] <nua> does this mean I need to edit the bzrlib source?? http://pastebin.com/m533f12af
[16:36] <tro> bakunin: use the HTTP method of specifying username/password. ie: svn://username:password@svn.repo.com/path/to/repo/trunk
[16:40] <awilkins> nua: I think the WSGI handler that is posted is a bit out of date
[16:40] <awilkins> nua: When I upgraded on Windows I had to change the logging parameters
[16:43] <bakunin> @tro Will the same work for a http URL?
[17:09] <tro> bakunin: yes
[17:13] <pickscrape> Given a revision ID, what is the quickest way in bzrlib to determine the number of parents that the revision has? (i.e. whether or not it is a merge)
[17:22] <garyvdm> pickscrape: http://pastebin.com/d2ec223ca
[17:23] <pickscrape> garyvdm: thanks for that
[17:46] <poolie> vila: hello
[18:00] <bakunin> tro: Thanks a lot. It worked. I guess this is how basic authentication is handled
[18:23] <luke-jr> how do I get teh 'svn revno' with bzr?
[18:26] <james_w> luke-jr: recent bzr-svn will put it in the output of "bzr log"
[18:27] <luke-jr> james_w: programmically
[18:28] <james_w> luke-jr: dunno
[18:28] <james_w> luke-jr: take a look at bzr-svn's source for how it implements that
[18:29] <luke-jr> :/
[18:29] <james_w> show_foreign_revid perhaps
[18:30] <luke-jr> s/programmically/from a shell script/
[18:45]  * garyvdm wishes he could use python 3.0's nonlocal statement...
[18:58] <lorph> is tortoisebzr usable yet
[19:03] <garyvdm> lorph - I use it.
[19:04] <garyvdm> Heh - He left allready :-(
[19:24] <mrooney> I am using bzr-svn to attempt to branch a rather large svn repository, but it doesn't seem robust enough to ever make it the whole way through. Is there a way to continue/resume this process?
[19:25] <mrooney> It seems to get a few thousand revisions in and then die and I have to start all over.
[19:25] <james_w> hey mrooney
[19:25] <mrooney> james_w: hey!
[19:25] <james_w> you can "bzr branch -r 1000"
[19:25] <james_w> then "bzr pull" 1000 revisions at a time
[19:26] <mrooney> james_w: ahh that sounds perfect, so if I branch 1000 and then the next pull fails, what state is it left in, the original before that pull? or is it still broken?
[19:26] <james_w> it should be left as it was before the pull
[19:26] <james_w> bzr pull -r 2000
[19:26] <james_w> bzr pull -r 3000
[19:26] <james_w> etc.
[19:27] <james_w> should stop it doing too much in one go
[19:30] <mrooney> james_w: thanks so much, this seems good
[19:30] <james_w> cool
[19:30] <mrooney> I figured an easy way to back up our SVN repositories incrementally was just to branch once from another machine via bzr-svn, and then pull every night
[19:30] <mrooney> james_w: does that sound sane?
[19:30] <james_w> seems reasonable
[19:31] <mrooney> excellent
[19:31] <mrooney> It would also probably help if I wasn't doing this over wifi :)
[20:00] <asabil> btw, does bzr have a way to see the diff/log of changes that where retrieved using a pull ?
[20:03] <garyvdm> asabil: There is before you pull. You can use missing to see what revisions, and diff pull_branch for diff
[20:04] <garyvdm> asabil: bzr does not remember what the tip revid was before the pull
[20:05] <asabil> it would be really very useful if it did
[20:28] <amanica_> asabil: you can tag it before you pull
[20:28] <amanica_> or maybe we can do an implicit tag before pulling
[20:29] <amanica_> eg BEFORE_LAST_PULL
[20:29] <amanica_> maybe this would be possible to do with a plugin...
[20:35] <lifeless> mtaylor: file a bug on the stacking-on failure please
[20:36] <garyvdm> Is there a way to specify the bound branch?
[20:37] <garyvdm> e.g. bzry push -d --bound_branch--
[20:37] <lifeless> garyvdm: bzr bind <url>
[20:37] <lifeless> garyvdm: oh; :master I think
[20:38] <garyvdm> lifeless: re:bind Then I would need to bind every time I switch - which is often
[20:38] <garyvdm> I'll check out :master
[20:39] <garyvdm> :bound works - thats very cool
[20:45] <knittl> hi! is there a way to stash commits like in git?
[20:45] <bob2> shelve
[20:46] <knittl> bzr shelve? i can't find it in the manpage
[20:47] <knittl> and it doesn't work … (binary files)
[20:51] <lifeless> knittl: in used to be in a plugin, it recently got moved to core and fixed for binary files
[20:52] <LarstiQ> knittl: which shelve is this with btw, shelf1 or `shelve` from 1.10 and up?
[20:52] <lifeless> knittl: what bzr version do you have?
[20:52] <LarstiQ> knittl: hi, btw :)
[20:52] <knittl> hi LarstiQ :)
[20:52] <knittl> 1.6.1 i got on my machine
[20:52] <knittl> LarstiQ: i checked out blender (took hours)
[20:53] <LarstiQ> knittl: got everything though?
[20:53] <knittl> yup, i'm not missing a thing (till yet)
[20:54] <knittl> -yet +now … sounds better xD
[20:54] <knittl> ok, i just bzr rm --keep the files, committed my changes and pulled
[20:55] <knittl> weirdly enough it told me there was nothing to pull/merge, but before committing it told me there was a pending merge
[20:58] <lifeless> knittl: that means you had done a merge
[20:58] <knittl> lifeless: well, i didn't tell it to do a merge. but nevermind … i'm only doing a little branch for a sideproject xD
[20:59] <lifeless> knittl: check your bash history, I can pretty much guaranteed that 'bzr merge' is in there somewhere :)
[20:59] <knittl> yes, but it aborted and told it couldn't merge because of uncommitted changes
[21:00] <lifeless> knittl: it would do that after you'd made changes; such changes could have included an earlier attempt to merge
[21:00] <knittl> ok, i see :)
[21:00] <lifeless> one of the most obvious differences to git is that 'bzr merge' always waits for the user to commit the result - we don't autocommit
[21:02] <lifeless> -> breakfast
[21:29] <lifeless> Peng: btw, you should find bzr search lower on memory but not too much slower on indexing
[21:30] <Peng_> lifeless: The new group_size stuff? Cool, how much lower?
[21:31]  * Peng_ fires up "bzr -Dmemory index".
[21:31] <lifeless> a lot lower for mysql trees :P
[21:32] <lifeless> also loggerhead suggestions should be faster in format 2 search indices
[21:32] <Peng_> Oh, cool.
[21:32] <Peng_> Should suggestions in general be faster, or is it specific to LH?
[21:33] <lifeless> faster in general
[21:35] <Peng_> Bah, the progress bar is already off the side of the screen.
[21:35] <lifeless> ugh
[21:41] <Peng_> 9 minutes 14 seconds for bzr.dev. "VmPeak:   121356 kB"
[21:41] <Peng_> That's awesome memory usage. It used to take decreasing the group_size to ~80 to do that.
[21:45] <jelmer> luke-jr, you can get the svn revno with "bzr log -r -1"
[21:45] <jelmer> luke-jr, "Fix released" means it's part of the main branch in the bzr world
[21:46] <jelmer> luke-jr, wrt svn-cp, there is no way to make that work while bzr can't represent that internally
[21:49] <Peng_> Nice, "bzr search aye" returns an excerpt from doc/en/user-guide/images/workflows_pqm.png. At least it didn't confuse my shell.
[21:51] <jelmer> hi Peng_
[21:51] <jelmer> Peng_, Did you get anywhere further with that bzr-svn+bzr-search issue you were seeing?
[21:52] <Peng_> jelmer: I didn't try to.
[21:54] <luke-jr> jelmer: bzr doesn't have arbitrary metadata?
[21:54] <Peng_> Haha, "bzr search branch" on bzr.dev sure has a lot of results. :)
[21:54] <luke-jr> jelmer: I'd rather not have to grep/sed on log -r -1
[21:55] <jelmer> luke-jr: only revision properties, but they are set at commit time
[21:56] <jelmer> luke-jr, and the amount of work to work around the fact that bzr doesn't have copies makes me think we should really just implement copy support in bzr first
[21:57] <jelmer> luke-jr, sorry :-/
[21:58] <Peng_> "bzr search branch" had 5311 results. FYI. :P
[21:59]  * jelmer notices bzr-search is Peng_'s latest toy
[22:03] <Peng_> jelmer: Well, I go through a lot of toys. :P
[22:28] <luke-jr> jelmer: so implement copy support already :/
[22:28] <luke-jr> jelmer: honestly, I'd benefit greatly from moving a number of my projects to bzr, but without copy support I can't :/
[22:28] <knittl> is there a bzr move?
[22:28] <luke-jr> yes
[22:28] <jelmer> knittl, yes
[22:28] <knittl> it's not bzr mv … what is it?
[22:29] <luke-jr> knittl: it is
[22:29] <knittl> oh … i must've mistyped it then …
[22:30] <luke-jr> jelmer: supposedly the problem w/ copying is cherry-picking, but IMO copying is more important than cherry picking, so that problem should be deferred :/
[22:31] <jelmer> luke-jr, fwiw, I agree with that (some copy is better than no copy)
[22:31] <jelmer> and just having the history stored now means we can use it later when there is proper merge support (if ever, as that's a very hard problem to solve)
[22:32] <knittl> can somebody help me with a concrete repo? (+branch)
[22:33] <knittl> i'm still more used to git … after all i'm a programmer and like it complicated xD
[22:33] <jelmer> knittl, what's the problem?
[22:33] <knittl> i can't get two directories pulled into b
[22:33] <knittl> * -b +my branch
[22:34] <Peng_> jelmer: Hg supports merging across copies.
[22:35] <jelmer> Peng_: So what do they do when you copy a file and then merge in another branch that changes that file?
[22:35] <jelmer> Do you merge it into both copies ? Or just into one?
[22:35] <jelmer> If you base one source file on the other, you don't necessarily want the changes
[22:35] <Peng_> jelmer: The other branch changed the original or the copy?
[22:35] <jelmer> The other branch changed the original
[22:36] <Peng_> jelmer: The changes are merged into both.
[22:36] <Peng_> Cue Peng_ being proved wrong.
[22:40] <lifeless> Peng_: 9 minutes is slower than usual to index though?
[22:42] <Peng_> lifeless: I dunno. The group_size is 2000, and I'm not sure if I have numbers for that (and if I did, it would be for format 1).
[22:42] <Peng_> lifeless: For group_size = 1000 from a couple months ago, it was 9m56s, so it's faster.
[22:42] <Peng_> lifeless: So, I figure that if it is slower, it's not significant.
[22:45] <knittl> hm, how do i get those folders into my branch? :-/
[22:46]  * Peng_ /aways
[22:46] <lifeless> Peng_: thanks,c ool
[22:48] <jelmer> knittl, I'm not I understand completely what you're trying to do
[22:49] <jelmer> knittl, if you're trying to import folders, just "bzr add" followed by "bzr commit" should be sufficinet
[22:49] <knittl> jelmer: the folders already exist in the master branch
[22:49] <knittl> but they are 'unknown' in my branch
[22:49] <jelmer> knittl, so you want to do a cherry pick merge of those folders?
[22:50] <knittl> i just want to have them in my branch :D
[22:50] <lifeless> knittl: normaly you would just 'bzr merge master && bzr commit' to get something into your branch
[22:51] <knittl> i only tried bzr merge till now
[22:51] <knittl> it tells me there's »nothing to do«
[22:53] <lifeless> knittl: what is the *exact* command line you are running
[22:53] <ivazquez|laptop> Given a bzrlib.branch.BzrBranch6, how do I get the revision of a file within?
[22:53] <knittl> lifeless: bzr merge (master)
[22:54] <knittl> master or not, the output is the same
[22:54] <lifeless> ivazquez|laptop: you need a revision tree - so tree = branch.repository.revision_tree(branch.last_revision()); tree[tree.path2id('path')].revision
[22:55] <ivazquez|laptop> Excellent, thanks.
[22:55] <lifeless> knittl: the literal word master, or the URL ?
[22:56] <knittl> lifeless: ok, i tried "master" after your advice. but i tried the url before and it doesn't change anything
[22:56] <lifeless> knittl: does 'bzr missing URL' report anything?
[22:58] <knittl> »you have 4 extra revisions« + the logs
[22:58] <lifeless> knittl: ok, you have everything from that branch already; so either the folders you are talking about aren't versioned, or you've deleted them locally :)
[22:58] <lifeless> knittl: are you able to give us some more data? Is it an open source project that we could go peek at the url ?
[22:58] <knittl> i don't think i deleted them …
[22:59] <knittl> sure … lp:dnd or lp:~knittl/+junk/dnd
[23:01] <lifeless> I'm on a terrible wifi network at the moment, one second while I wait for my packets to get through :)
[23:01] <knittl> no problem … i'm glad you help me understand bzr a little
[23:01] <lifeless> https://code.edge.launchpad.net/~knittl/+junk/mtd ?
[23:02] <lifeless> I can't see a dnd branch of yours
[23:02] <ivazquez|laptop> Hrm. I'm getting "TypeError: unsubscriptable object" from tree[...].
[23:02] <lifeless> ivazquez|laptop: oh sorry, tree.inventory[...
[23:02] <ivazquez|laptop> Ah, thanks.
[23:02] <knittl> lifeless: yes
[23:03] <lifeless> knittl: so is this your branch without the folders, or the branch with the folders that you want to get into your current copy?
[23:03] <knittl> it's my branch without the folders from dnd
[23:03] <knittl> they got added in r12, my r12 differs …
[23:04] <lifeless> ok
[23:04] <lifeless> and where is the dnd branch?
[23:04] <knittl> the dnd branch is just lp:dnd
[23:04] <knittl> or what do you mean?
[23:07] <lifeless> ok, got it. Now what are the folders you want?
[23:08] <knittl> Data/{Models,Sounds}
[23:09] <knittl> and i didn't remove them … i looked at my history
[23:10] <lifeless> your rev 15 merged his rev 12 that added the files, but your merge backed out his changes
[23:10] <lifeless> I imagine you did something like 'bzr revert .' and then committed something
[23:10] <lifeless> which will have kept the merge record but reverted all the code changes
[23:11] <lifeless> this is easy to fix
[23:11] <lifeless> are you still on rev 15?
[23:11] <knittl> iirc i did bzr rm --keep because they were changed (oh damnit …)
[23:11] <knittl> yup, i'm still on 15
[23:11] <lifeless> ok, do  a 'bzr st' and make sure there are no pending changes - no pending merges or changed files
[23:11] <knittl> no output—good  :)
[23:12] <lifeless> now, 'bzr uncommit' and say yes when prompted.
[23:12] <lifeless> then do 'bzr shelve --all'
[23:13] <lifeless> you should now be on rev 14
[23:13] <lifeless> do 'bzr st' again - is there any output
[23:14] <Peng_> lifeless: Should "bzr search" use more memory when it finds tons of results?
[23:14] <knittl> ok, output after uncommit is added [my files] and 1 pending merge
[23:14] <knittl> bzr shelve --all
[23:14] <Peng_> (Well, "more" = 88 MB, and "tons" = "5300")
[23:14] <luke-jr> jelmer: when multiple possibilities are valid, Conflict
[23:15] <lifeless> Peng_: probably, though that does seem excessive
[23:15] <lifeless> knittl: 'bzr st' output after doing the shelve ?
[23:15] <knittl> wops, that bzr shelve shoulda go into my shell xD
[23:15] <knittl> shelve won't complete
[23:15] <knittl> $ bzr shelve --all
[23:15] <knittl> bzr: ERROR: Changes involve binary files.
[23:15] <lifeless> odd
[23:15] <lifeless> what bzr version do you have?
[23:16] <knittl> 1.6.something
[23:16] <knittl> 1.6.1
[23:16] <lifeless> ok, when you get a chance upgrade, cause that is fixed
[23:16] <knittl> that's the latest bazaar i get from the ubuntu repos
[23:16] <lifeless> for now though, just take a copy of your new files somewhere
[23:16] <Peng_> https://launchpad.net/~bzr/+archive
[23:17] <knittl> okay
[23:17] <lifeless> knittl: when you've taken that copy, run 'bzr revert'
[23:18] <lifeless> knittl: and then 'bzr merge lp:dnd', if it merges without conflicts then do 'bzr commit'
[23:18] <knittl> ok, i'll try
[23:18] <knittl> ok, did that, worked fine :)
[23:19] <lifeless> put your files back, run 'bzr add' then 'bzr commit'
[23:19] <knittl> my files are still there … now just the regular bzr add?
[23:19] <knittl> great :)
[23:19] <knittl> why is this so complicated? :p
[23:20] <lifeless> well, its not normall :)
[23:20] <lifeless> knittl: also, you may like to know that you can push to lp:~knittl/dnd/mtd
[23:20] <knittl> :)
[23:20] <knittl> lifeless: yes, i know that …?
[23:21] <lifeless> cool (I just found it odd your branch was in +junk)
[23:21] <knittl> oh yes, i just wanted to test … maybe i'll move it to ~knittl/dnd later on
[23:22] <lifeless> you can do that in the web ui I think
[23:22] <lifeless> anyhow, http://bazaar-vcs.org/Download/ has newer versions of bzr for Ubuntu - just follow the link to the ppa
[23:22] <knittl> yes, but that's not important atm. is long as i can pull/push and have all data xD
[23:24] <knittl> $ bzr push
[23:24] <knittl> Using saved location: bzr+ssh://knittl@bazaar.launchpad.net/~knittl/%2Bjunk/mtd/
[23:24] <knittl> bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
[23:24] <knittl> :-$
[23:25] <lifeless> add --overwrite
[23:26] <lifeless> that error is just a protection against mmistakes, but we redid that commit deliberately
[23:26] <knittl> ok, i really need to get a newer version
[23:26] <knittl> but that will hopefully be available in jaunty
[23:27] <knittl> lifeless: got it all back to normal. thanks!
[23:27] <knittl> i can always count on irc :)
[23:30] <Peng_> "bzr search a" on bzr.dev takes 84 seconds (user time; realtime fluctuated), VmPeaks at 96 MB, and returns 12,429 results. :D
[23:37] <wgrant> jelmer: Is that add_records() fix in bzr.dev the one to stop it complaining about knit corruption?
[23:38] <jelmer> wgrant, it will stop a complaint if you run "bzr merge"
[23:38] <jelmer> wgrant, it won't affects "bzr check"
[23:38] <wgrant> jelmer: Right. Thanks for handling the bug quickly.
[23:39] <enigma1> Hm...I just got an assert error with bzr-svn 0.5
[23:39] <enigma1> I was pushing a tag back up to SVN.
[23:39] <wgrant> jelmer: Is 0.5 stable now?
[23:39] <wgrant> I thought it was still unreleased.
[23:40] <enigma1> AssertionError: Unable to find direct lhs parent for <RevisionMetadata for revision 9707, path cpp-common/tags/0.11 in repository 'daff2dd8-1c3d-0410-9cd2-f6297dd8f964'>
[23:40] <jelmer> wgrant: Yeah, it's not yet released (there's one rc out, another to follow soon)
[23:40] <enigma1> No...this is off 0.5-trunk
[23:40] <jelmer> enigma42, Any chance you can try after removing the local cache?
[23:40] <jelmer> s/try/try again/
[23:40] <jelmer> there was a bug similar to this fixed some days ago
[23:41] <enigma42> jelmer: I'm a little nervous to clear the cache.
[23:41] <jelmer> enigma42: Why?
[23:41] <enigma42> Last time I cleared the cache, my svn branches got out of sync with the SVN server.
[23:41] <enigma42> So, the latest revisions in bzr were in svn, but they weren't correlated.
[23:41] <jelmer> enigma42: alternatively, you could just move it out of the way for now
[23:42] <enigma42> True.
[23:42] <jelmer> just to see if it helps
[23:42] <enigma42> OK...let me try.
[23:42] <enigma42> Um...I think my 0.5-trunk my be a little of of date, do you know when the bug was fixed?
[23:42] <wgrant> jelmer: Is 0.5 in a PPA somewhere yet?
[23:43] <jelmer> wgrant, there's a month old package in debian experimental
[23:43] <jelmer> enigma42, I think about a week
[23:43]  * wgrant shall update that and PPA it.
[23:43] <jelmer> enigma42, if removing your cache causes issues, that would be a sign there's a lot more wrong..
[23:44] <enigma42> jelmer: OK. So you think I should update to the latest 0.5-trunk, remove the cache, and try again?
[23:44] <jelmer> enigma42: Please do - that should tell us if those problems are still there, and allow us to fix them
[23:45] <enigma42> OK. Let me give that a go.
[23:47] <enigma42> Oh...on a different note, why is the bzrtools in the PPA *way* out of date?
[23:48] <enigma42> Is that hard to build?
[23:48] <enigma42> Is that something I could build and email to someone?
[23:49] <lifeless> Peng_: yes, thats not that useful :P - searching for multiple terms might be more useful :P
[23:52] <lifeless> jelmer: where is bzr-git up to?
[23:52] <lifeless> jelmer: [should the help be improved, is there meant to be a git:// urlspec?]
[23:53] <jelmer> lifeless: I'm making sure dulwich is ready for a release
[23:54] <jelmer> I blessed the current mapping as stable yesterday and renamed it appriopriately
[23:54] <jelmer> The idea is to release a simple bzr-git in a couple of days
[23:54] <jelmer> meanwhile I'm still working on optimization
[23:55] <enigma42> jelmer: The most recent revision I'm seeing for the 0.5 tree is from Saturday, Dec 27. Does that sound right to you?
[23:55] <jelmer> lifeless, I was hoping to receive comments about my local branches spec, that's the main thing important about URLs
[23:55] <enigma42> jelmer: I'm pulling from: http://people.samba.org/bzr/jelmer/bzr-svn/0.5/
[23:55] <jelmer> enigma42, no, the most recent one is from a couple of hours ago
[23:55] <enigma42> Ack...nevermind.
[23:56] <spiv> "[###################/] determining changes:analyzing repository layout:determining changes:copying revision:determining revisions to fetch:discovering revisions -2349/68866
[23:56] <enigma42> Looked at the wrong end of the log. :-P
[23:56] <lifeless> jelmer: I glanced at it
[23:56] <spiv> "
[23:56] <spiv> jelmer: that's an amusing progress line :)
[23:56] <jelmer> spiv: bug in the new progress code :-(
[23:57] <jelmer> spiv, btw, did you see my comments to your import patch?
[23:57] <spiv> jelmer: yeah, I did.
[23:58] <ivazquez|laptop> Taking a look at https://fedorahosted.org/packagedb/browser/0.3.x , how do I get 182 from the InventoryFile for AUTHORS?
[23:59] <jelmer> hmm, ohloh seems to've released the sourcecode related to their vcs analysis
[23:59] <lifeless> ivazquez|laptop: you map the revision back via the branch
[23:59] <jelmer> and added hg support
[23:59] <jelmer> unfortunately it's all ruby :-(