[00:01] <poolie> spiv, hope you get well soon
[00:01] <kgoetz> win 2
[00:01] <abentley> poolie: Sure.
[00:27] <kees> how long should doing a "bzr upgrade" on a bzr+ssh URL take?
[00:27] <lifeless> time to pull fully, time to push fully, roughly
[00:28] <lifeless> faster if there is an optimised case for it
[00:28] <kees> lifeless: ah, so it pulls, does the work locally, then pushes?
[00:30] <kees> okay, strace shows that now... the upstream bandwidth was so low I wasn't seeing it my monitors.  :P
[00:30] <kees> the progress bar isn't very helpful.  :)
[00:55] <nDuff> AttributeError: 'SvnWorkingTree' object has no attribute '_transport' (in bzrlib.workingtree.WorkingTree.read_basis_inventory) trying to branch from a svn repo into a bzr one.
[00:55] <nDuff> bzr 1.6, bzr-svn 0.4.12
[00:56] <nDuff> (ubuntu packages, with http://ppa.launchpad.net/bzr/ubuntu)
[00:58] <nDuff> ...hrm; looks like the branch operation succeeded; no working tree generated, but "bzr update" in the target location fixes that...
[00:59] <nDuff> ...and "bzr check" claims everything's in good shape.
[01:04] <lifeless> nDuff: please file a bug
[01:04] <lifeless> nDuff: I suspect you did branch <svntree> NEWPATH
[01:04] <lifeless> and its probably not tested by bzr-svn's test suite
[01:04] <nDuff> where NEWPATH was under a preexisting shared repository
[01:04] <nDuff> ...but yes.
[01:04] <markh> we need an appeals process for reviews! ;)
[01:06] <lifeless> markh: we have one; Reply.
[01:07] <jml> or more reviewers :)
[01:08] <markh> yeah, but if the complaint is about stylistic issues, hitting reply will just start a huge debate about stylistic issues...
[01:09] <lifeless> markh: a review is a dialog, no more no less
[01:09] <markh> I guess I mean the vote then
[01:09] <lifeless> if a particular reviewer feels that some stylistic issue is sufficiently important to make it a requirement to land...
[01:10] <lifeless> then either a) they are right, or b) they are wrong - and either way we should discuss it
[01:10] <lifeless> an 'appeals process' sounds like a formalised huge debate IMO :)
[01:10] <markh> or I should just stop complining, submit to the request and re-re-submit
[01:10] <markh> and sigh :)
[01:10] <lifeless> I'm happy to give my opinion if you tell me the thread
[01:25] <nDuff> ...filed as bug 264548
[01:27] <lifeless> nDuff: thanks
[01:33] <jml> jam: still around?
[01:36] <poolie> hello jml
[01:36] <poolie> do you still have teeth? are you back in sydney?
[01:38] <jml> poolie: some. no.
[01:38] <jml> poolie: back late tomorrow
[01:39] <poolie> robert and andrew were going to work here on friday and then maybe go to the pub, you're welcome to come if you want (to either part)
[01:39] <jml> poolie: I'll be landing at about 10:30pm
[01:39] <jml> but thanks for the invite :)
[01:39] <poolie> maybe next time
[01:55] <jml> internet!
[02:04] <RAOF> Is yours?
[02:16] <strk> know a trick to check history of a single file ?
[02:16] <strk> with 'viz' preferably
[02:16] <strk> to easily check actual diffs between revs
[02:25] <lifeless> abentley: does bb match the /exact/ sender field, or only the email portion ?
[02:25] <abentley> lifeless: The exact sender field.
[02:25] <lifeless> strk: well, log -v FILE is probably close to what you want
[02:26] <lifeless> strk: I don't think viz has a per-file mode at the moment
[02:26] <lifeless> abentley: oh. can you tweak an email address in bb for me then? user adri
[02:26] <lifeless> strk: folk generally use annotate though, to look at a file
[02:27] <abentley> lifeless: Sure.
[02:27] <lifeless> abentley: Adrian Chadd <adrian@squid-cache.org>
[02:27] <lifeless> I had just put in the email component
[02:27] <poolie> strk, with gannotate you can doubleclick lines to see the diff iirc
[02:27] <poolie> it would be nice to get viz too
[02:28] <strk> wow, annotate got to my conclusion in a shot
[02:33] <poolie> great
[02:35] <abentley> lifeless: Done.  Note that it is an exact match, so I used "Adrian Chadd" <adrian@squid-cache.org>
[02:36] <lifeless> thanks
[03:57] <lifeless> back soon, shopping run
[05:29] <lifeless> poolie: hi, I've reviewed the locks hook patch john said resubmit: to; I'm also asking for resubmit.
[05:55] <poolie> lifeless: my patch?
[05:57] <lifeless> I wrote a patch to hook locks
[05:57] <lifeless> you updated it
[05:57] <lifeless> I needed it today, and realised it was still unmerged
[05:57] <poolie> now you want me to update it again and resubmit it?
[05:58] <lifeless> I'm happy to do the update
[05:58] <lifeless> we need to agree on how it should look though
[05:59] <poolie> ok, i'm just preparing to send something then will look at it
[06:00] <poolie> so
[06:01] <poolie> my patch makes these hooks inconsistent with the other ones
[06:01] <poolie> i agree the inconsistency is bad, and um
[06:01] <poolie> to some extent the lack of testing is bad, though iirc the way it was done in the old code was not tested either
[06:02] <poolie> i think the existing interface is both a bit unsafe and longwinded, but
[06:02] <lifeless> the old code doesn't try 'restore to pristine' or clone a hooks object
[06:02] <lifeless> uhm, anyhow
[06:02] <poolie> yeah, anyhow
[06:02] <poolie> let's not block this on changing that
[06:03] <poolie> so, i think at least having specific names for that behaviour lets you think about changing it
[06:03] <poolie> s/changing/testing
[06:28] <poolie> lifeless: mini review sought of http://pastebin.ubuntu.com/43261/
[06:31] <lifeless> poolie: looks good
[06:31] <poolie> great
[06:32] <poolie> anything missing?
[06:32] <poolie> well, before you start
[06:32] <poolie> anything missing that people are likely to misunderstand
[06:34] <lifeless> nothing comes to mind
[06:34] <lifeless> bbiab
[06:34] <poolie> kthx
[06:37] <j00bar> howdy! I'm a total bzr n00b and really just want to accomplish one thing. i'd like to checkout only a subdirectory of the trunk. this is easy with other vcs' like svn -- can it be done with bzr?
[06:37] <Spaz> j00bar, you can't do that yet
[06:37] <Spaz> j00bar, it will be possible in a few versions or so
[06:37] <Spaz> sorry
[06:38] <Spaz> j00bar, if the subdirectory is a branch, however
[06:38] <Spaz> then you can
[06:38] <j00bar> bugger.
[06:38] <j00bar> it's a python project where the subdir has the actual code and the branch root has INSTALL, README, etc that i don't really want -- with SVN or other systems, i just check out the subdir and update as needed...
[06:38] <Spaz> j00bar, most DVCS's you'll find don't support partial checkouts yet
[06:39] <j00bar> but if it can't be done, it can't be done -- no worries -- thanks!!!
[06:39] <Spaz> np
[06:56] <vila> Goood morning Bazaar
[07:50] <lifeless> hi visik7
[07:50] <lifeless> meh
[07:50] <lifeless> hi vila
[07:51] <vila> hi :)
[07:51] <visik7> :P
[07:53] <lifeless> brane is flied
[07:53]  * lifeless halts()
[10:59] <jdahlin> I'm having a problem with bzr-svn 0.4 and bzr 1.5 shipped with fedora
[10:59] <jdahlin> This is written to my .bzr.log: AttributeError: 'module' object has no attribute 'properties_handler_registry'
[11:08] <james_w> jdahlin: you have a mismatch between bzr-svn and bzr versions
[11:08] <james_w> I think your bzr-svn is too new
[11:08] <jdahlin> yeah, I reverted a few commits and it appears to work now
[11:33] <awilkins> Hmm, strk has gone
[11:33] <awilkins> qlog has a per-file mode
[11:50] <awilkins> markh: Hi there, are you building the bzr-svn extensions for windows?
[11:51] <awilkins> markh: I've got a build error, did you run into this - error LNK2019: unresolved external symbol _svn_auth_get_windows_ssl_server_trust_provider referenced in function _get_windows_ssl_server_trust_provider
[11:59] <awilkins> Never mind, looks like it's a "no longer supports svn 1.4 libraries" thing
[13:00] <AnMaster> I have two questions: 1) what is "subtree support" 2) what is "rich root". Both are mentioned in bzr help formats, but I have been unable to find anything more detailed, like what it actually means
[13:00] <AnMaster> and yes I have tried google
[13:13] <sabdfl> AnMaster: they are related, iirc
[13:13] <sabdfl> subtrees are when you have a branch, which in turn incorporates another branch
[13:14] <sabdfl> subtrees let you manage that better
[13:14] <AnMaster> um you mean like svn:external?
[13:14] <AnMaster> or something else?
[13:14] <sabdfl> i think so, yes
[13:14] <AnMaster> ah ok
[13:14] <sabdfl> rich roots are where there is a unique ID associated with the branch root, iirc
[13:14] <sabdfl> it's a watershed - once you move the branch to a rich root format, you can't go back
[13:15] <sabdfl> and generally, it should only be done once across a community, iirc
[13:15] <sabdfl> so we haven't yet made it the default
[13:15] <sabdfl> abentley would know more
[13:16] <AnMaster> hm ok
[13:19] <abentley> sabdfl, AnMaster: The relationship is that rich roots are a prerequisite for subtrees support.  But it turns out they're also useful for bzr-svn, which is why we provide formats supporting them.
[13:19] <AnMaster> hm ok
[13:20] <AnMaster> abentley, so subtree is basically same as svn:externals?
[13:20] <abentley> AnMaster: Yes, but that feature isn't finished yet.
[13:20] <AnMaster> right
[13:22] <AnMaster> anyway that is not a feature I need, features I need/want are: 1) cherrypicking like darcs 2) faster push/pull for huge repos (close to git's speed preferred, but with the usability of bzr) 2) something like svn:eol-style
[13:23] <AnMaster> err make the last one 3) heh
[13:26] <abentley> AnMaster: We want to improve cherrypicking support, but we don't want to implement it the way Darcs does.  Their approach to patch handling leads to performance and integrity problems.
[13:26] <AnMaster> hm ok
[13:26] <pickscrape> I'm having a problem with the trac-bzr source browser, and I'd like a little help in debugging it.
[13:26] <abentley> The other two are currently in development.
[13:28] <pickscrape> My trac install consists of a plain directory containing a number of shared repositories with branches beneath them.
[13:28] <pickscrape> When browsing the root of one of the branches, I get an error like this: NoSuchRevision: KnitPackRepository('file:///path_to_shared_repo/.bzr/repository/') has no revision (revision)
[13:29] <pickscrape> Is there any way I can find out why the browser thinks it needs that revision? The repository and branch seem to be working fine in general use.
[13:29] <AnMaster> abentley, basically I need to merge bugfixes back to a stable branch from trunk (and sometimes the other way too), bzr can't handle keeping track of what revisions have been merged and what ones haven't.
[13:29] <AnMaster> not when you skip some non-bugfix revisions in the merging
[13:30] <abentley> Right.  We do want to add that, though no one is currently working on it.
[13:31] <AnMaster> well I would if I was a python programmer
[13:32]  * awilkins wasn't a Python programmer before he started scratching his own issues on Bazaar, but appreciates not everyone has the time to take out on solving problems in other projects
[13:34] <awilkins> For me the choice was - use SVN and implement my own merge tracking or - use Bazaar and resolve any other issues you might confront
[13:34] <awilkins> So far I'm _very_ glad I chose Bazaar
[13:34] <AnMaster> awilkins, at least I don't have time before next summer holidays
[13:35] <awilkins> AnMaster: What you are wanting is the tracking of cherry-picks
[13:36] <awilkins> AnMaster: Have you tried a different merge algorithm? You may get more joy with something like --weave
[13:37] <radix> AnMaster: if you make the bug fixes in the stable branch first, you can continuously merge the stable to the trunk
[13:37]  * awilkins was just about to say that too
[13:37] <radix> there's a page about this somewhere
[13:37] <radix> I can't remember what it's called
[13:38] <radix> anmaster: here it is: http://www.venge.net/mtn-wiki/DaggyFixes
[13:41] <awilkins> So a combination of "bisect" to test for the bug presence, a branch, and a forward-merge (to both the stable bugfixing branch and the trunk) might work more cleanly (but is obviously slightly more of a PITA)
[13:44] <AnMaster> hm will try that
[13:46] <awilkins> Thanks for asking, I like learning new ways of doing things :-)
[13:51] <pickscrape> Is there a command to check for the presence of a revision ID is a shared repository (or something I can use to achieve the same)?
[13:52] <awilkins> bzr revision-info -r revid:<myrevid>   ?
[13:52] <awilkins> Hmm, not sure about the shared repo bit
[13:53] <pickscrape> Yeah, it complains about it not being a branch
[13:54] <fullermd> You could stat -c it.  revision-info will blow up if that rev isn't in the current branch.
[13:55] <fullermd> (other similar things like diff or testament would work too)
[13:55] <pickscrape> Thing is, I don't know which branch the revision was been created against :)
[13:55] <pickscrape> was been?
[13:55] <abentley> pickscrape: it doesn't matter.
[13:56] <fullermd> (of course, revision-info should be a little more polite about failing, but that's neither here nor there)
[13:57] <awilkins> If stat and diff work with revid: (regardless of branch) then so should revision-info IMHO
[13:57] <pickscrape> Oh, so it will search the entire shared repo regardless of whether the revision in question is a part of the branch's history or not?
[13:57] <abentley> pickscrape: Yes.
[13:57] <pickscrape> Sweet, thanks.
[13:57] <fullermd> awilkins: Well, but revision-info wants to show the revid.
[13:58] <fullermd> awilkins: Er, I mean 'revno'.
[13:58] <fullermd> That fares poorly when the revision isn't in the branch...
[13:59] <awilkins> Ugh, yes
[14:00] <pickscrape> Thanks all, that's confirmed my theory. The revision that trac-bzr is complaining about exists in one of the other shared repositories.
[14:00] <pickscrape> So the next question would be, why would it be picking up that revision in the first place...
[14:03] <EarthLion> how can you commit with sub revision numbers e.g. revision no 7.3
[14:03] <EarthLion> if i do bzr commit -m "blah" it always gives me a whole number
[14:04] <EarthLion> the help doesn't have any info on this
[14:04] <awilkins> EarthLion: Sub numbers are always nested revisions of merges
[14:04] <awilkins> EarthLion: Revisions committed on the branch you are on are always single integers
[14:05] <EarthLion> awilkins:  "Sub numbers are always nested revisions of merges" can you explain what that means
[14:06] <awilkins> EarthLion: revisions numbers with more than one component are used to identify the revisions that are part of merges from other branches
[14:06] <awilkins> You cannot commit revisions with more than one number in the branch you are working on
[14:06] <EarthLion> ah ok i see thanks for explaining
[14:43] <jelmer> awilkins, ping
[14:48] <ericvw> I am still a bit confused between bzr init and bzr init-repo for an initial project; can someone give me why I would use bzr init-repo to start a project vs bzr init?
[14:48] <fullermd> Oh, well, that's easy.  You wouldn't   :)
[14:48] <ericvw> haha
[14:49] <fullermd> init creates a branch, that you have files in and work in.  init-repo creates a repository, that a set of branches can use to share common history.
[14:49] <uws> ericvw: init-repo only makes sense if you plan to have multiple branches and want to use shared storage for them
[14:49] <uws> ericvw: but you can always convert later (trivial)
[14:49] <uws> ericvw: (just branch your branch into a repository and you're done)
[14:50] <fullermd> uws: Or use reconfigure   :)
[14:50] <ericvw> uws: So if I had a branch with bzr init, and I decided to create a repository and wanted to add that solo branch to the repository what command should I look into?
[14:51] <ericvw> But for individual or small peer use, I could probably get away with a init-rep
[14:51] <ericvw> init-repo*
[14:51] <fullermd> ericvw: You'd need to init-repo in a parent dir of your branch (or alternately, init-repo somewhere and move that branch into a subdir of it), then use reconfigure --use-shared.
[14:52] <ericvw> fullermd: ok, I will experiment with this, thanks!
[14:52] <fullermd> ericvw: init-repo doesn't give you somewhere to work; it's not an alternative to init.  It's a potential enhancement for some use-cases.
[14:52] <ericvw> so in contrast to svn, the definition of repo is something different, right?
[14:53] <fullermd> If you only ever have one branch, it doesn't gain you anything.  If a project is tiny, you probably wouldn't be able to notice what it gains.
[14:53] <fullermd> Well...   yes, and no, and totally, and kinda.
[14:53] <ericvw> yeah, that is what threw me for a loop at first
[14:54] <fullermd> init-repo doesn't [shouldn't] change anything about how any commands work.
[14:54] <fullermd> There's no semantic difference between doing $SOMETHING among two branches that are in the same shared repo, doing $SOMETHING among two branches in different shared repos, doing $SOMETHING among two branches neither of which is in a shared repo, etc.
[14:55] <ericvw> ok, i think i am getting the concept now,  I will have to re-read the guide again to get a better understanding
[14:55] <fullermd> For the purposes of initial experimentation, you can forget init-repo even exists.
[14:55] <fullermd> You can switch to using it (or away from using it) on a given project at the drop of a hat.
[14:56] <ericvw> fullermd: thanks for the explanations and help!
[14:56] <ericvw> uws: you too as well :D
[15:03] <ericvw> I am a little confused in doc-guide section 4.2.2 It talks about creating a repo and then grabbing a branch from someone else...; so in a 2 person environment, you may each have your own repo with a branch within it?
[15:06] <abentley> ericvw: It is possible to do that, but the whole point of a shared repo is to put branches in it.
[15:07] <ericvw> abentley: ok, thanks
[15:09] <jelmer> when did bzr branch including tree generation get so freakingly fast?
[15:11] <zbrown> jelmer: I think in 1.5 or 1.6
[15:11] <abentley> jelmer: That was a bit of a team effort with ianc.
[15:11] <abentley> We're currently hamstrung by poor index performance, though.
[15:12] <abentley> I would *like* to be competitive with cp, at least in a shared repo.
[15:12] <zbrown> I was quite impressed
[15:12] <zbrown> and still am ;)
[15:13] <zbrown> I still shudder to think what managing wine's repo in bzr would be like though
[15:21] <jelmer> abentley, Thanks, it's now at least quick enough to "feel" instantaneous on non-huge trees
[15:29] <gour> any idea why attempt to push from laptop to desktop machine fails - see log http://rafb.net/p/okZ1bY72.html
[15:30] <gour> zbrown: don't know about wine's repo, but from today my machines are m$ free - i was finally able to make some proprietary folio infobase running under wine - no need for Virtualbox & similar emulators any longer :-D
[15:32] <abentley> gour: could you try bzr push nosmart+bzr+ssh://gour@gaura-nitai.no-ip.org/home/gour/repos/bzr/cfgfiles/.bzr/repository/
[15:32] <abentley> Sorry, skip the end.
[15:33] <abentley> bzr push nosmart+bzr+ssh://gour@gaura-nitai.no-ip.org/home/gour/repos/bzr/cfgfiles/
[15:40] <gour> abentley: same - http://rafb.net/p/pwZZw175.html
[15:40] <gour> let me check if i push to the right dir
[15:42] <abentley> gour: cfgfiles looks like it already has a repository.  Is that intentional?
[15:42] <gour> hmm, the gour@gaura-nitai.no-ip.org/home/gour/repos/bzr/cfgfiles/ has the following format - gour@gaura-nitai.no-ip.org/home/gour/repos/bzr/cfgfiles/
[15:43] <gour> oops, http://rafb.net/p/3c0gT377.html
[15:43] <gour> and bzr upgrade says: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
[15:44]  * gour thinks that having less supported formats would be better
[15:44] <abentley> gour: Right.  Rich-roots are not a default format.
[15:44] <abentley> gour: Talk to Jelmer.
[15:46] <gour> abentley: ok. explicit upgrade to --rich-root-pack solved it
[15:49] <gour> anyone responsible for bzr-gtk here?
[15:53] <gour> ohh, it seems we solved it...
[16:04] <zbrown> gour: haha, well I'm glad to hear it :). We (the wine contributors) are pleased with how far wine has come in the last few months
[16:09] <gour> zbrown: i was dreaming several years to become 100% free. used win4lin, vmware, vbox...all bloatware
[16:12] <abentley> zbrown: Do you know offhand how well Wine supports Adobe Premiere?
[16:17] <zbrown> abentley: can't say I do know
[16:18] <zbrown> abentley: reports seem to indicate its not that great though
[16:18] <zbrown> gour: Eh I hardly find vmware to be bloatware
[16:19] <zbrown> gour: at least on my laptopt, its very responsive, not quite "real system" but its still better than most
[16:19] <abentley> zbrown: Too bad.  I have a friend who wants to use Ubuntu, but must use Premiere.
[16:21] <zbrown> abentley: its getting there, its just not all the way there yet
[16:22] <zbrown> hard to hit a moving target like Microsoft :)
[16:27] <gour> zbrown: bloatware in the sense that i required the whole OS to run single apps for which there is no native-linux replacement
[16:27] <abentley> zbrown: But most applications are backwards-compatible with XP or 2000, no?
[16:29] <Toksyuryel`> microsoft is a moving target? if anything they're moving backwards and making things constantly easier for us
[16:36] <zbrown> Toksyuryel`: not when you're trying to emulate (sometimes broken) behaviors of the OS that applications depend on
[16:37] <zbrown> abentley: What are you particularly referring to? As of right now, emulation in wine is targeted for NT 5 series
[16:37] <zbrown> so 2000, XP and 2003 are the main goals
[16:37] <zbrown> granted XP is the focus
[16:37] <abentley> zbrown: So those targets haven't moved for 5 years.
[16:38] <zbrown> abentley: API's change with service packs and security releases ;)
[16:38] <zbrown> abentley: not to mention the api is just way huge
[16:38] <Toksyuryel`> zbrown: oh, I get what you're saying now
[16:39] <abentley> zbrown: That I can certainly agree with.
[16:39] <zbrown> Its only hard because there's maybe 20-30 regular contributors, probably <20
[16:39] <zbrown> and MS has thousands of people changing things on us ;)
[17:11] <ericvw> Odd question, it doesn't make sense to have a repo with checkouts within it does it on a local development environment?
[17:12] <ericvw> I understand the using shared storage for 2+ branches in a shared-repo in a development environment.
[17:37] <jelmer> abentley, speaking of which..
[17:38] <jelmer> abentley, What's the latest status in your discussion with Robert about rich-root-pack as default?
[17:38] <abentley> jelmer: We haven't talked about it in months.
[17:39] <jelmer> oh, ok. I thought I saw something about it recently
[18:01] <jelmer> awilkins, ping
[18:07] <ericvw> Did anyone happen to answer my question when I left temporarily?
[18:09] <vila> jelmer: ping, did you see my mail about 'Re: transport implementation test scenarios and rabbit-holing' ?
[18:10] <vila> jelmer: there are two questions for you (search for jelmer in the body :)
[18:17] <jelmer> I only see the email from mwh
[18:30] <LarstiQ> jmm, ericvw quit just a bit too early
[18:36] <vila> jelmer: strange, I replied and added you in CC your email @samba.org is still valid ?
[18:36] <LarstiQ> jelmer: maybe it's not in the bzr folder
[18:46] <jelmer> vila, LarstiQ: nope
[18:53] <ericvw> What is the primary difference between checkouts and branches?
[18:56] <vila> jelmer: here is a digest just for you http://paste.ubuntu.com/43429/  :D
[18:57] <jelmer> vila, which python-kerberos did you install?
[18:58] <jelmer> you'll need at least 1.0+svn2455-1
[19:00] <jelmer> vila, you have a kerberos environment?
[19:06] <jjesse> good afternoon, i'm working on setting up a bzr branch of a subversion checkout, how do i go about ignoring all the .svn directories under the different folders?
[19:07] <jjesse> i think i need to edit a .bzrignore file but not quite sure i need to do
[19:08] <jam> jjesse: "bzr ignore .svn" should be sufficient
[19:09] <Spaz> yeah
[19:09] <jjesse> jam thanks
[19:09] <ericvw> when doing a checkout, does the .bzr have the same characteristics as branch since i can bind/unbind?
[19:21] <ericvw> In the 1.1 project/trunk layout design, are those 'container' directories branches or just folders?
[19:45] <jelmer> vila, hi
[19:45] <jelmer> vila, ?
[19:57] <jam> just a reminder to beuno, jelmer, vila, et al. Today is bug day
[19:58] <jam> please triage, fix, and otherwise do interesting stuff to the bug tracker
[19:58] <jam> (I know Jelmer did work last weekend, but *today* is the official bug day)
[19:58] <beuno> jam, cool!  bug day finally happened!  I like you as release manager  :)
[20:09] <jam> oddly enough, I'll actually have released 3 versions in a row
[20:09] <jam> I released 1.5
[20:09] <jam> and then accidentally inherited 1.6
[20:09] <jam> and now I'll be doing 1.7
[20:09] <jam> :)
[20:10] <beuno> jam, and doing a great job at it, really
[20:10] <jam> I'll say I'm more comfortable with it now that I've done 7-ish actual releases :)
[20:10] <jam> Peng: so if you count 1.6.1rc2 + 1.6rc5 you could claim rc7 :)
[20:11] <LarstiQ> oh there is a bug day?
[20:12] <LarstiQ> gah, why does ericvw keep disappearing!
[20:38] <theuiguy> I'm doing some code cleanup in a source tree and I'm trying to understand the subtleties of bzr rm versus just rm.
[20:38] <theuiguy> I want the code to still be available using bzr log / bzr diff / etc.
[20:39] <theuiguy> Is there a difference between the two: bzr rm vs. rm?
[20:40] <theuiguy> bzr status shows files as removed using either command.
[20:41] <LarstiQ> theuiguy: you could bzr rm --keep and still have the actual file, but removed from a version control point of view.
[20:41] <LarstiQ> theuiguy: bzr rm is explicit, just rm is implicit.
[20:42] <theuiguy> LarstiQ: I think I want the opposite -- I want the file removed from my tree, but still have it in version control if I ever need to go back to it.
[20:42] <LarstiQ> theuiguy: well, you still need to commit.
[20:43] <theuiguy> It seems like just rm is what I should use.
[20:43] <LarstiQ> theuiguy: with any (rm, bzr rm, bzr rm --keep), after you commit that file won't show up anymore, but still be present in historical revisions.
[20:44] <theuiguy> LarstiQ: Are you sure? That's not what I'm seeing at the moment, admittedly before I commit
[20:44] <theuiguy> If I do rm, I can still do bzr log FILENAME and see FILENAME's history
[20:44] <LarstiQ> theuiguy: I'm very sure, but I could be more precise about "won't show up"
[20:45] <theuiguy> but with bzr rm, it doesn't show the history anymore
[20:46] <theuiguy> LarstiQ: Please do be more precise... I want to understand this
[20:48] <LarstiQ> theuiguy: right, so the difference between bzr rm and rm *before commit* is that because the plain rm is implicit, the file will only not be in the inventory after you committed. Whilst bzr rm has a bit more info and can already do that.
[20:48] <LarstiQ> theuiguy: they'll be exactly the same after you commit.
[20:49] <Snaury__> jelmer: see my patch in https://bugs.launchpad.net/bzr-svn/+bug/263570
[20:49] <LarstiQ> theuiguy: all revisions henceforward will not have that file in their inventory. It might still be in your tree if you did bzr rm --keep, but status will say it is an unkown file.
[20:49] <LarstiQ> theuiguy: if you do a fresh checkout, or remove the file and then revert to a revision, the file will not be recreated.
[20:49] <theuiguy> LarstiQ: So after commit, how would I be able to look at the history of the file? I'd have to revert?
[20:49] <LarstiQ> theuiguy: however, if you revert to a revision before it was removed, the file _will_ be created in your working tree.
[20:50] <LarstiQ> theuiguy: hmm, it seems there might be a regression there.
[20:50] <LarstiQ> theuiguy: you should be able to provide a file path that doesn't match the current state, but a historical one.
[20:50] <LarstiQ> theuiguy: you could always revert, yes
[20:50] <theuiguy> LarstiQ: It's probably just our older version of bzr
[20:51] <LarstiQ> theuiguy: or say, use bzr cat -r rev to see how that file looked in a certain revision.
[20:51] <LarstiQ> theuiguy: what part of the history of that file are you interested in seeing?
[20:52] <theuiguy> LarstiQ: Well, I'm doing some code cleanup in our tree... files that I don't think we'll ever need again
[20:52] <theuiguy> but I want to be sure I can get back to them if we ever need them
[20:53] <theuiguy> bzr rm scared me because the behavior before commit makes it look like the files are completely gone.
[20:53] <theuiguy> including all knowledge of what went on in prior revisions
[20:53] <LarstiQ> theuiguy: I can see that, but I can reassure you that is not the case.
[20:54] <LarstiQ> theuiguy: so I think that is a ui bug that needs to fixed to be less scary.
[20:55] <theuiguy> Is it a recent addition that you should be able to provide a historic path to see history?
[20:55] <theuiguy> as in bzr log -r OLDFILE
[20:55] <theuiguy> with some revision information of course
[20:56] <theuiguy> Or does that not currently work?
[20:56] <LarstiQ> theuiguy: it doesn't do that on my recent copies. So either it used to be possible, or I misremeber wrong.
[20:56] <LarstiQ> theuiguy: but it works for cat
[20:58] <LarstiQ> theuiguy: I think I was confused with cat.
[20:58] <theuiguy> hmm... so it does work for cat?
[20:58] <LarstiQ> theuiguy: but I still think it might be a nice feature. Although I acknowledge it can be tricky to infer what the user means.
[20:58] <LarstiQ> theuiguy: yes
[20:58] <LarstiQ> theuiguy: bzr cat -r <rev with file> path/to/file
[20:59] <LarstiQ> theuiguy: should work even with path/to/file not existing in the current revision.
[20:59] <theuiguy> ah... it'd be nice if log could do something like it ending with "deleted in revsion X"
[21:00] <LarstiQ> theuiguy: well, removed is relatively simple
[21:00] <LarstiQ> theuiguy: but consider files that are moved around.
[21:00] <LarstiQ> theuiguy: especially if you swap files a and b
[21:01] <LarstiQ> theuiguy: what does 'bzr log -r rev a' mean?
[21:01] <theuiguy> LarstiQ: So let me see if I understand: bzr rm or rm both say remove this file as soon as I commit this and don't track it any more
[21:01] <theuiguy> but ...
[21:01] <LarstiQ> theuiguy: give me the information for the file that is currently at path a, or the one that was at a in that revision?
[21:01] <theuiguy> they are still in revision history for previous versions
[21:01] <LarstiQ> theuiguy: exactly.
[21:02] <LarstiQ> theuiguy: bzr very rarely destroys history
[21:03] <theuiguy> LarstiQ: that's very reassuring. Thanks!
[21:03] <LarstiQ> theuiguy: and if it does, always on explicit user request (bzr rebase for instance)
[21:03] <theuiguy> LarstiQ: It doesn't seem like bzr handles the simple case where there's nothing there in the current revision
[21:04] <theuiguy> Is rebase built in now? Or still a plugin?
[21:04] <LarstiQ> theuiguy: you mean, bzr log foo when foo isn't present?
[21:04] <LarstiQ> theuiguy: plugin
[21:04] <theuiguy> LarstiQ: yes
[21:06] <LarstiQ> theuiguy: right, it's relatively straightforward in the case where there only ever was one file with that name.
[21:06] <LarstiQ> theuiguy: in the other case, maybe log should be more interactive, and present you with a list of different files that had that name, and ask which one you want.
[21:06] <theuiguy> It could be helpful to know
[21:06] <theuiguy> especially if there are file renames in there
[21:07] <theuiguy> Or perhaps just show renames in and out of that filename...
[21:07] <theuiguy> with the log only showing what was there at various revisions
[21:08] <LarstiQ> renames would be the common case of that problem, it's also possible to just do serial adds and removes.
[21:10] <theuiguy> LarstiQ: So the difference in behavior before commit between bzr rm and rm is accidental, right?
[21:11] <LarstiQ> theuiguy: I don't know for sure, but the difference sounds logical to me. It's not of much significance though.
[21:13] <chadmiller> Hi all.  On the server where my canonical trees are, I wish to have some code that marks bugs as updated when branches are pushed-to with revisions that mention those bugs.  My current idea involves cron, but I'm having trouble.
[21:14] <LarstiQ> chadmiller: you're not using --fixes?
[21:14] <chadmiller> It looks (I think) like merges can rearrange my trees so that merely keeping track of the last-seen revision-id and constucting a list from that to the end is not sufficient to know what to update.
[21:15] <chadmiller> LarstiQ: No.  I perhaps could, but I don't think that solves my problem.
[21:15] <LarstiQ> chadmiller: it doesn't, but makes the detecting of fixed bugs less iffy.
[21:15] <LarstiQ> so, on to the actual problem.
[21:15] <chadmiller> I don't have a problem with that.
[21:16] <LarstiQ> chadmiller: you'll probably want to know if the last seen revision-id is in the ancestry of the tip, instead of in the revision-history of the branch.
[21:16] <chadmiller> We're really good about the format.  [Bb]ug\s*#\s*\d+
[21:16] <LarstiQ> chadmiller: and no one mentions them unless they're actually fixed?
[21:16] <LarstiQ> chadmiller: are you averse to using bzrlib for this?
[21:16] <chadmiller> LarstiQ: (yes.  The format is no problem.)
[21:17] <chadmiller> LarstiQ: I'm not averse, but I am daunted.
[21:18] <LarstiQ> chadmiller: I'm not sure how I'd do it otherwise. But I could be warped by knowing bzrlib ;)
[21:18] <chadmiller> LarstiQ: So, to be clear.  When cron fires off some program every minute, I only need an updated tree and a revision id of the last-seen revision-id?
[21:19] <LarstiQ> chadmiller: yes, I think that would be enough information to figure out the rest from.
[21:19] <chadmiller> I don't need the structure of the last tree, or a list of previous revisions ever seen?
[21:19] <chadmiller> Hmm, okay.
[21:19] <LarstiQ> chadmiller: well.
[21:20] <LarstiQ> chadmiller: unless people uncommit or push --overwrite.
[21:20] <LarstiQ> chadmiller: but if they use merge, that would be ok.
[21:20] <chadmiller> Eh, hm.  We can trust that no one will commit, push, uncommit, push.
[21:20] <LarstiQ> good :)
[21:20] <chadmiller> Or use --overwrite.
[21:52] <vila> jelmer: sorry, I was away afk far longer than I thought, I just have 1.0-1 (hardy) so I think you answered my question
[21:57] <LarstiQ> chadmiller: sorry, I've been dragged to do other things.
[22:00] <chadmiller> LarstiQ: It's okay.  I'm still wrapping my head around the problem.  Of the solution, you suggest a new program that imports bzrlib.  It takes a parameter, the revision id, and inspects a branch.  It somehow (!?) emits the log messages of all revisions that were not present before the time when the given revision id was at the tip.  Right?
[22:01] <LarstiQ> chadmiller: yes
[22:01] <chadmiller> Wow.  I have to come up with a test case first.  Then I'll start on the Hard Party.
[22:01] <chadmiller> Wow.  I have to come up with a test case first.  Then I'll start on the Hard Part.
[22:04] <LarstiQ> chadmiller: it may not be enough, but you could try something like
[22:06] <LarstiQ> chadmiller: well, basically bzrlib.log.show_changed_revisions as seen in cmd_pull
[22:06]  * chadmiller looks.
[22:07] <hgr3> I am having problems applying a patch with "bzr patch", I just keep getting bzr: ERROR: Error invoking patch: No such file or directory. What am I doing wrong? (I am on windows)
[22:08] <Odd_Bloke> hgr3: How are you invoking it?
[22:09] <hgr3> Odd_Bloke: bzr patch mypatch.patch
[22:09] <LarstiQ> chadmiller: another builtin to look at is cmd_missing
[22:11] <hgr3> Odd_Bloke: I have never done this before, is it something I am missing?
[22:11] <LarstiQ> chadmiller: specifically bzrlib.missing.{iter_log_revisions,find_unmerged}
[22:14] <hgr3> If I use bzr diff myfile.c > mypatch.patch, should I not be able to do bzr patch mypatch.patch in the same go? But if I try, I get Error, No such file or dir
[22:16] <jam> hgr3: to run "bzr patch" you have to have the patch executable (from diffutils, etc) I don't think it is available on windows
[22:17] <jam> well, it *is* available
[22:17] <jam> just not by default
[22:17] <jam> I could be wrong on that, though.
[22:17] <hgr3> jam: ahh... I see :) where can I read more about this?
[22:17] <jam> hgr3: 'bzr patch' is provided by bzrtools, which brings in other dependencies
[22:17] <jam> I don't know for sure why it doesn't use some of the internal mechanics.
[22:17] <chadmiller> LarstiQ:  bzrlib.missing.find_unmerged takes two branches as parameters.  I only have the one branch (unless I change my program to keep another branch to compare against; ugh).
[22:18] <jam> hgr3: if you want something you can apply easily, I would suggest looking at "bzr send" though that doesn't do per-file.
[22:18] <jam> chadmiller: 'bzrlib.missing._find_unmerged' is probably what you would really care about.
[22:18] <jam> But regardless, those are both focused on mainline stuff
[22:18] <hgr3> jam: I have a patch I desperately would like to apply to a file, but I don't find out how to do it... what do you suggest?
[22:19] <jam> what you probably want is
[22:19] <jam> b = branch.Branch.open('mybranch')
[22:19] <jam> g = b.repository.get_graph()
[22:19] <zbrown> hgr3: patch -p0 ?
[22:19] <LarstiQ> hgr3: another problem might be relative paths in the branch.
[22:19] <jam> g.find_unique_ancestors(b.last_revision(), [old_last_revision])
[22:19] <jam> chadmiller: ^^
[22:19] <LarstiQ> hgr3: what are the values of `pwd` and `bzr root` ?
[22:20] <chadmiller> Ooo.
[22:20] <LarstiQ> chadmiller: and jam saves the day again :)
[22:20] <jam> hgr3: http://gnuwin32.sourceforge.net/packages/patch.htm
[22:20] <jam> zbrown: He's on windows and doesn't have patch installed yet
[22:20] <LarstiQ> jam: I knew there was a graph function like that, but I didn't find it yet :/
[22:20] <jam> chadmiller: you probably want some "lock_read()" in there, too
[22:21] <zbrown> jam: oooh ok, my mistae
[22:21] <LarstiQ> jam: oh, but _find_unmerged does that
[22:21] <jam> LarstiQ: yeah. _find_unmerged is where the real work is done
[22:21] <hgr3> thank you!
[22:24] <LarstiQ> hgr3: installing patch helped?
[22:25] <jam> he probably needs to put it somewhere on his path, etc
[22:25] <jam> but as he wants to apply a diff, patch is the go-to command :)
[22:26] <LarstiQ> right :)
[22:27]  * LarstiQ just would like confirmation it is not #30159
[22:46]  * mwhudson wants bzr push --no-tree
[22:46] <LarstiQ> mwhudson: for locla fs pushes?
[22:47] <mwhudson> LarstiQ: yes
[22:47] <LarstiQ> mwhudson: makes sense.
[23:08] <jam> bug #30159
[23:10] <jam> LarstiQ: for what hgr3 needed, that was certainly the case. "bzr patch" uses bzrtools, which uses the patch executable
[23:10] <jam> which is a bit of a shame, because we *do* have native ability to parse patch files
[23:10] <jam> (bzrlib.patches)
[23:10] <LarstiQ> jam: right, but if he didn't have patch, we wouldn't even get to 30159
[23:48] <poolie> hello all
[23:49] <jelmer> 'morning poolie
[23:52] <igc> morning
[23:53] <mwhudson> hi igc, poolie
[23:57] <spiv> Good morning.