[00:26] <SamB> is BZR_PROGRESS_BAR=none working for anyone else ?
[00:26] <SamB> it isn't working for me ...
[00:56] <jml> SamB: I've never tried it.
[00:58] <SamB> well, progress bars look really unsightly in emacs buffers :-(
[01:29]  * SamB wonders if he reported https://bugs.launchpad.net/launchpad-bazaar/+bug/339380 against the correct thing ...
[01:29] <ubottu> Ubuntu bug 339380 in launchpad-bazaar "push doesn't work when default stacking branch is a mirror that has failed to update ?" [Undecided,New]
[01:30] <SamB> um, that's not an ubuntu bug is it ?
[01:30] <SamB> it wasn't supposed to be ...
[01:32] <SamB> where did everybody go?
[01:32] <SamB> to bed ?
[01:32] <SamB> (because of the DST change?)
[01:33] <jelmer> still here
[01:33] <jelmer> SamB, #launchpad is more appropriate for launchpad bugs though
[01:33] <SamB> well, I can't really tell where the bug is ;-)
[01:44] <jelmer> lifeless, ping
[02:03]  * SamB wonders if he should report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517770 on launchpad, Debian isn't responding and he has no reason to believe this is a Debian problem ...
[02:03] <ubottu> Debian bug 517770 in bzr "bzr: BZR_PROGRESS_BAR is ignored" [Normal,Open]
[02:03] <SamB> huh, that thing is neat
[02:12] <LaserJock> SamB: it nows eeeeverything :-)
[02:14] <Peng_> mwhudson: If I break the build, you have only yourself to blame. :P
[02:17] <jelmer> SamB, I'm pretty sure it's not debian specific
[02:17] <jelmer> SamB, just haven't had time to forward it to lp yet
[02:18] <SamB> oh, okay, I guess I'll do it then
[02:20] <james_w> SamB: I've just done it
[02:20] <james_w> bug 339385
[02:20] <ubottu> Launchpad bug 339385 in bzr "bzr: BZR_PROGRESS_BAR is ignored" [Undecided,New] https://launchpad.net/bugs/339385
[02:21] <SamB> ah, okay, subscribed myself to that
[02:25] <SamB> would it be innapropriate to flag this bug as affecting an emacs-lisp package that runs bzr and expects it to honor that environment variable ?
[02:26] <SamB> the launchpad documentation doesn't seem to be very clear on the intended meaning of "also affects" ...
[02:26] <LaserJock> SamB: it would be I think if something had to be fixed in the emacs package in order for it to work
[02:27] <SamB> oh, no
[02:27] <LaserJock> so I would think in this case it wouldn't be appropriate
[02:29] <SamB> but if the package had users, wouldn't it be nice to be able to somehow indicate that this bug would affect that package, so that they wouldn't file a bug against it?
[02:29] <SamB> but I guess that's more of a launchpad question ...
[02:29] <LaserJock> well, it might yes, but it would sort of depend on if that's likely
[02:30] <LaserJock> like take a bug in grep. you're not going to add an "Also affects" to every program that uses grep
[02:30] <SamB> well, no ;-)
[02:31] <SamB> but it's very likely that this particular bug will affect anyone using this emacs package on its own code ...
[02:32]  * SamB wonders when the bug occured
[02:34] <SamB> (that's how I found it; I initially reported it against the elisp package only to discover that it *was* setting the env var but that wasn't working)
[02:36] <LaserJock> then what you'd normally do is mark the elisp package task as "Invalid" and do "Also affects" for bzr
[02:36]  * SamB decides to update http://bazaar-vcs.org/GitStyleBranches with how it's working for him
[02:37] <SamB> that wasn't necessary because the elisp package wasn't yet using a bug tracker
[02:39]  * SamB wonders why in the world MoinMoin has markup for <h1> ...
[02:40] <ronny> hu?
[02:40] <ronny> its a wiki
[02:40] <SamB> yes, but the H1 should come from the page title
[02:41] <ronny> hmm
[02:42] <ronny> im sure there is some obscure use case that is/was necessary
[03:33] <SamB> I've tried to explain the procedure in detail: http://bazaar-vcs.org/GitStyleBranches -- criticism welcome
[08:22] <lifeless> jelmer: pong
[10:37] <Spaz> does bzr have a way to copy files?
[10:46] <luks> hm, bzr+ssh (push) is doing something stupid. progress bar is on "Transferring:Walking content. 900/995" and it's doing tons of tiny append requests (~300 bytes on average)
[10:46] <luks> Spaz: it doesn't
[10:46] <Spaz> :(
[10:55] <LarstiQ> luks: -Dhpss?
[10:55] <LarstiQ> luks: this sounds a bit familiar, just a sec
[10:55] <luks> LarstiQ: how do you know I knew about the append requests? :)
[10:55] <luks> s/know/think/
[10:56] <luks> and sftp fails with PathError: Generic path error: '51i9iwdq4q7i7h37s2ub.fetch': Failure: unable to rename to '../packs/1735d9ebad85f138adac0df322fbfaf0.pack')
[10:56] <LarstiQ> luks: so that is how you knew ;)
[10:56] <luks> so it's not possible to push this branch to a remote server
[10:56] <LarstiQ> luks: bug 331823?
[10:56] <ubottu> Launchpad bug 331823 in bzr "Pushing an update of a stacked branch to Launchpad sometimes takes nearly an hour" [Critical,Fix released] https://launchpad.net/bugs/331823
[10:56] <luks> there is no stacking involved
[10:57] <LarstiQ> luks: the title might not be describing the actual problem correctly
[10:57] <luks> well, unless recent bzr is doing something automagically
[10:57] <LarstiQ> luks: the bug in question is not in 1.12, but was in bzr.dev
[10:57] <LarstiQ> fwiw
[10:58] <LarstiQ> if that doesn't work, it is unfortunately something else
[10:58] <luks> frankly, that sftp fails worries me a little more
[10:58] <luks> I never had good luck with bzr+ssh
[10:59] <luks> the pack code still hides the actual error, so without hacking bzr I can't even know why it's failing
[11:00] <MarcWeber> Which is the bzr command to find a diff adding or removing a string?
[11:01] <luks> bzr doesn't have such a command built-in
[11:01] <MarcWeber> luks ? I'd like to know wether there has been a test case containing "stop on never"
[11:02] <MarcWeber> So can't I just export a long list of diffs or such?
[11:03] <luks> there is bzr log -p, but that's probably not released yet
[11:07] <MarcWeber> I don't mind installing an experimental bazaar version..
[11:07] <MarcWeber> Thank you!
[11:09] <LarstiQ> MarcWeber: you can also use the bzr-bisect plugin
[11:09] <LarstiQ> MarcWeber: which is a bit more general than what you asked, but can get it done.
[11:10] <MarcWeber> :-) bzr -> git would do as well.
[11:10] <luks> LarstiQ: I wonder how, you need to check manually whether the string is there or not
[11:11] <LarstiQ> luks: as the test for yes/no you run 'grep string'
[11:11] <luks> LarstiQ: that's O(log N) vs O(1) operation :)
[11:11] <luks> (for human work)
[11:18] <LarstiQ> luks: oh, I use the 'automatic' branch of bisect, where you write the test once
[11:19] <LarstiQ> Odd_Bloke: merge it allready ;P (I don't suppose you have since recalled what the problem was?)
[11:21] <harobed> in bazaar online document, at 5.2.2   Starting a central branch, are there one error in "Here is an example of the second way:" ?
[11:21] <harobed> I think last line bzr push sftp://centralhost/srv/bzr/project/trunk isn't useful because second example use checkout
[11:21] <luks> link?
[11:21] <harobed> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#publishing-a-branch
[11:22] <harobed> at  5.2.2
[11:22] <luks> yep, that's wrong
[11:23] <luks> commit will automatically push in this case
[11:23] <harobed> Ì happy, I well understand :)
[11:23] <harobed> luks: can you fix it ?
[11:24] <luks> maybe, it's been some time since I last sent a bzr patch :)
[11:24] <luks> I think the example should use branch, not checkout
[11:24] <luks> because checkouts are explained later
[11:25] <luks> hm, or not
[11:25] <luks> "Note that committing inside a working tree created using the checkout command implicitly commits the content to the central location as well as locally."
[11:25] <harobed> yes
[11:25] <harobed> I think we must delete push line
[11:25] <luks> yep
[11:29] <harobed> luks: you send the patch ?
[11:29] <harobed> or I do ?
[11:30] <luks> already sending it
[11:30] <harobed> great ;)
[11:30] <luks> or do you want to? :)
[11:39] <harobed> no, I'm continuing Bazaar user guide reading...
[11:39] <lifeless> right, BB mail-bombed:)
=== montywi|weekend is now known as montywi
[12:42] <Odd_Bloke> LarstiQ: I haven't, and I don't really have time to check whether it's a major issue or not.
=== radix` is now known as radix
[16:46] <awilkins> jelmer: Ping?
[16:47] <jelmer> awilkins, pong
[16:47] <awilkins> jelmer: Are you interested in public SVN repos that cause tracebacks in bzr-svn?
[16:47] <jelmer> awilkins, yes, very much so
[16:48] <awilkins> jelmer: The MythTV SVN causes an AssertionError on both a branch and the trunk
[16:48] <jelmer> awilkins, URL ? :-)
[16:48] <awilkins> jelmer: I can pack up the repo I have for you to save you some time if you want
[16:48] <awilkins> http://svn.mythtv.org/svn/branches/release-0-21-fixes
[16:48] <awilkins> It's a /trunk , /tags , /branches  layout
[16:50] <awilkins> Traceback at  http://pastebin.ubuntu.com/128387/
[16:51] <awilkins> ls
[16:52] <jelmer> awilkins, when does it break exactly?
[16:52] <jelmer> during the copying phase?
[16:53] <awilkins> Copying revisions
[16:53] <awilkins> Hmm, don't need "obsolete packs" do we
[16:54] <jelmer> awilkins, around which revision?
[16:54] <jelmer> I'm at 800 now
[16:55] <awilkins> Around 15000
[16:55] <awilkins> I was bandwidth bound here, but I don't know which end
[16:55] <awilkins> I suspect mine though, only 2mbit
[16:56] <awilkins> Using 1.9-rich-root
[16:59] <awilkins> As I recall it identifies about 20,000 revisions to copy, and when you try again after it breaks, it has about 4,000 left
[17:00] <awilkins> Uploading my repo (178MB in an archive) would probably take longer than you downloading at your end :-)
[17:02] <jelmer> awilkins, I don't get impressive results here either, it seems mainly restricted by the CPU in the server and the latency
[17:02] <jelmer> hi weigon
[17:03] <weigon> hi
[17:03] <rocky> heyo jelmer
[17:03] <jelmer> hey rocky
[17:04] <rocky> jelmer: don't suppose you've had a chance to try out my branch? (no idea if you intend on eventually upgrading your tracbzr instnaces)
[17:04] <jelmer> awilkins, I think I get ~75k
[17:04] <jelmer> rocky, I don't actually have any tracbzr instances running
[17:04] <jelmer> rocky, we have one at bugs.bitlbee.org, but I don't have any access to the admin side of things
[17:04] <rocky> ahhh, gotcha
[17:05] <jelmer> rocky, If it fixes any actual bugs (the _get_weave one, right?) and you're confident it works well I'd be happy to review it though
[17:07] <rocky> jelmer: well before my changes i couldn't actually browse the repo, got several problems... not sure what you mean regarding _get_weave tho
[17:07] <rocky> this is with bzr 1.12
[17:08] <rocky> jelmer: i wouldn't care about officially branching off to have a branch to release from that only cares about trac 0.11 and bzr > 1.12 support
[17:08] <rocky> could probably get rid of some gunk that way
[17:11] <rocky> jelmer: btw, is there anyway to delete a branch from launchpad? i'd like to get rid of my sandbox branch
[17:12] <jelmer> rocky, Hmm, what in particular broke with 1.12 ?
[17:13] <jelmer> rocky, I think it's possible to remove a branch from lp, not sure how exactly
[17:13] <rocky> jelmer: let me switch my branch back to find the original problems
[17:15] <gnomefreak> in Hardy i'm getting an error when running bzr bd --merge --dont-purge --builder=...... its telling me Unable to load plugin 'builddeb' is there a way around this?
[17:16] <rocky> jelmer: the _get_weave bug you described... that's because of bzr 1.12
[17:16] <gnomefreak> bzr: ERROR: unknown command "bd" is also there
[17:16] <rocky> jelmer: which means viewing the revision log for a file broke
[17:17] <jelmer> rocky, right
[17:17] <jelmer> rocky, Please request a merge of your branch into trunk
[17:18] <rocky> jelmer: hm... looks like that bug was reported back with bzr 1.6 ... bug #263300
[17:18] <ubottu> Launchpad bug 263300 in trac-bzr "Does not work with bzr 1.6" [Undecided,New] https://launchpad.net/bugs/263300
[17:19] <jelmer> yeah, it's pretty old
[17:19] <rocky> wow, which is a duplicate of a bug referencing bzr 1.5
[17:20] <rocky> jelmer: i think i'll do some more research and such before i request a merge
[17:21] <jelmer> rocky, more research why ? Because you're not confident your code is right?
[17:22] <rocky> because i just found out some more info on the bug regarding what the code was just trying to accomlish, it's possible i missed something
[17:22] <rocky> plus, my branch does more than just fix that
[17:22] <rocky> it fixes 1 other thing as i recall and cleans up backend.py for pep8
[17:30] <jelmer> rocky, generally, please keep separate bug fixes in separate branches
[17:30] <jelmer> so they can be merged independently
[17:40] <rocky> well, the branch started out as "sandbox" because i didn't know what i was fixing :)
[19:05] <mwhudson> Peng: hi
[19:05] <mwhudson> Peng: "However, if I truncate builtins.py, it can't figure it out." -- if you disable the filename guessing, right?
[19:08] <Peng_> mwhudson: Right.
[19:09] <Peng_> mwhudson: I'm not sure if I tested it with filename guessing enabled.
[19:11] <Peng_> mwhudson: Yeah, with filename guessing, it works.
[19:18] <stefanlsd> How would i revert some changes I did in revision 2.  I am now on rev 13, but just want to drop the rev 2 changes?
[19:18] <LarstiQ> stefanlsd: obliterate? (harder) or apply a reverse diff? (easy)
[19:19] <LarstiQ> stefanlsd: bzr merge . -r 2..1
[19:19] <LarstiQ> for the latter
[19:23] <mwhudson> Peng_: ok
[19:24] <mwhudson> Peng_: land it :)
[19:25] <Peng_> mwhudson: Alright. Thanks. :)
[19:25] <mwhudson> thanks for the fix
[19:27] <Peng_> :)
[19:27] <stefanlsd> LarstiQ: thanks. the reverse diff worked great.
[19:30] <Peng_> Done.
[19:32] <lifeless> mwhudson: moin
[19:33] <mwhudson> lifeless: hi
=== montywi is now known as montywi|evening
[20:05] <thumper> morning
[20:11] <jelmer> 'morning lifeless, mwhudson, thumper
[20:22] <lifeless> jelmer: what tz are *you* in :P
[20:27] <lifeless> jml: https://edge.launchpad.net/testscenarios
[20:36] <lifeless> jelmer: you might like current subunit - all the merge requests that were outstanding have been landed :)
[20:38] <awilkins> jelmer: Did your branch from the SVN at mythtv.org reproduce that AssertionError
[20:39] <lifeless> radix: http://bazaar.launchpad.net/~radix/subunit/report-errors-better/revision/50 ?
[20:39] <lifeless> radix: no test for it ? :P
=== arjenAU2 is now known as arjenAU
[21:02] <jfroy> jelmer: ping
[21:08] <LarstiQ> lifeless: I have vague notion in my head that you've done something with testing and resources, is that correct?
[21:08] <lifeless> LarstiQ: :P
[21:08]  * LarstiQ wonders how to interpret that :P
[21:10] <LarstiQ> lifeless: the problem I have is that some tests need different/largish datasets, I'd like the loading of them work irregardless of where you run the test from
[21:10] <lifeless> LarstiQ: lp:testresources may match your needs
[21:10] <LarstiQ> lifeless: kiitos
[21:11] <lifeless> LarstiQ: its specifically designed though, for resources that multiple tests need
[21:11] <lifeless> LarstiQ: e.g. 'a mysql db' or 'a configured django server' etc
[21:11] <LarstiQ> lifeless: not too far from what I'm going through
[21:11] <lifeless> LarstiQ: there is another project, 'testscenarios' which is closer to regular dependency injection, which is 'run this one test in N different scenarios'
[21:12] <lifeless> LarstiQ: high up my TODO list is making these two projects play really well together
[21:12] <LarstiQ> lifeless: also useful, but not what I'm looking for right now
[21:12]  * LarstiQ had briefly looked at some things on pypi
[21:12] <lifeless> LarstiQ: just ping me for any info you want on testresources
[21:13] <lifeless> the api needs a little love at the moment
[21:13] <LarstiQ> lifeless: will do
=== arjenAU is now known as arjenAU2
=== arjenAU2 is now known as arjenAU
[21:57] <mwhudson>   File "/home/mwh/canonical/repos/bzr/brisbane-core/bzrlib/plugins/groupcompress/groupcompress.py", line 753, in get_record_stream
[21:57] <mwhudson>     yield FulltextContentFactory(key, parents, sha1, bytes)
[21:57] <mwhudson> UnboundLocalError: local variable 'bytes' referenced before assignment
[21:57] <mwhudson> um, guys?
[21:58] <lifeless> mwhudson: that wouldn't seem to work :P
[21:59] <mwhudson> this was bzr pull ../bzr.dev into an empty --gc-chk255 branch
[22:01] <lifeless> mwhudson: intent that line 4
[22:01] <lifeless> and at the end of the if at line 742 yield a chunked one appropriately
[22:01] <lifeless> indent
=== montywi|evening is now known as montywi|zzz
[22:03] <mwhudson> lifeless: i have no idea what "yield a chunked one appropriately" means
[22:04] <lifeless> yield ChunkedContentFactory(key, parents, sha1, bytes)
[22:04] <lifeless> erm
[22:04] <lifeless> s/bytes/chunks
[22:04] <lifeless> mwhudson: probably want to drop into pdb once, and check the type of chunks
[22:04] <lifeless> if it is a bytestring, just change the variable names
[22:05] <mwhudson> lifeless: seems to be progressing now
[22:05] <lifeless> if it is a list, ^^ chunked factory type
[22:07] <mwhudson> well, to a point, then i got
[22:07] <mwhudson> bzr: ERROR: Revision {('selftest-20050621060616-bb8b5b36e3c950c8', 'robertc@robertcollins.net-20050919060519-f582f62146b0b458')} not present in "<bzrlib.plugins.groupcompress.groupcompress.GroupCompressVersionedFiles object at 0x21d9b50>".
[22:15] <lifeless> mwhudson: I suspect you have a very old bzr.dev repo
[22:15] <lifeless> that looks like the issues I was repairing in mine
[22:15] <mwhudson> there's something about bzr.dev -r 1512 that confuses it
[22:15] <mwhudson> it's fairly old i guess
[22:15] <mwhudson> reconcile time?
[22:15] <lifeless> grab a copy from http://bazaar-vcs.org to /tmp
[22:15] <lifeless> reconcile isn't a big enough hammer
[22:15] <mwhudson> or that
[22:16] <mwhudson> ok
[22:20] <lifeless> brekfasty things
[22:23]  * mwhudson stabs his isp
[22:24] <mwhudson> lifeless: (when you get back) is lp:bzr repaired sufficiently?
[22:30] <Kobaz> aww
[22:31] <Kobaz> bzr diff doesn't take multiple files for arguments
[22:40] <thrope> hi - I'm having some trouble, runninng 1.12 and bzr-svn 0.5.2 - dont use it much, bt just tried to check the log of NEWS in loggerhead branch, got an error about subvertpy
[22:40] <thrope> so I installed subvertpy with easy_install
[22:40] <thrope> and now I just get a segmentation
[22:41] <thrope> I was hoping bazaar would be getting more stable with the frequent releases after all the trouble i had when starting out with it
[22:41] <thrope> but it seems not!
[22:41] <thrope> what can I do to debug a segmentation fault
[22:41] <thrope> when i try to do log on a file
[22:50] <bob2> Kobaz: eh, yes it does
[22:51] <thrope> removing bzr-svn seemed to fix it - strange that it completely breaks bzr, even on plain bzr branches that having nothing to do with svn
[22:52] <lifeless> mwhudson: lp:bzr - dunno
[22:52] <lifeless> mwhudson: I'd hope so cause the format change recently was done after repair
[22:53] <lifeless> thrope: so bzr-svn sefaulting - please do file a bug on bzr-svn
[22:53] <mwhudson> should be then
[22:54] <lifeless> thrope: as for it affecting to many bzr commands, I've filed a bug on that just recently :), and the next version is somewhat better. It does hook in at a very basic level though which means that early-faults inbzr-svn will show up
[22:55] <thrope> lifeless: i will reinsall and see if I can reproduce it, but I reading a bit I think it doesn't support python 2.4 which I am on, so perhaps it was that
[22:56] <mwhudson> lifeless: same result with lp:bzr :(
[22:59] <lifeless> mwhudson: hmm
[23:00] <lifeless> mwhudson: as a hack, set the format._fetch_order = 'topological' in groupcompress
[23:00] <lifeless> mwhudson: see if that helps
[23:01] <mwhudson> lifeless: i need more clues than that
[23:01] <mwhudson> ah, repofmt.py
[23:05] <mwhudson> lifeless: no difference
[23:05] <lifeless> testing myself
[23:06] <lifeless> mwhudson: wherein does it fail?
[23:06] <lifeless> like, revno ?
[23:07] <mwhudson> lifeless: https://pastebin.canonical.com/14704/
[23:08] <mwhudson> it's r1512 that seems to be the problem
[23:08] <mwhudson> i can pull -r 1511
[23:08] <lifeless> Pull phase:Transferring revisions 2200/22421
[23:08] <mwhudson> and then pull -r 1512 fails
[23:08] <mwhudson> lifeless: it fails soon for me then :)
[23:08] <lifeless> ok
[23:09] <mwhudson> repository has 2600 revisions
[23:12] <lifeless> mwhudson: so, ('selftest-20050621060616-bb8b5b36e3c950c8', 'robertc@robertcollins.net-20050919060519-f582f62146b0b458') is in the source
[23:12] <lifeless> mwhudson: and not in the target
[23:13] <lifeless> ('selftest-20050621060616-bb8b5b36e3c950c8', 'john@arbash-meinel.com-20051123154424-a02f8bf990a1fed5')
[23:13] <lifeless> is the text to insert
[23:13] <lifeless> I suspect I'll end up hacking deeply on this today :(
[23:15] <lifeless> mwhudson: ah
[23:15] <lifeless> (Pdb) self.source.has_revision('robertc@robertcollins.net-20050919060519-f582f62146b0b458')
[23:15] <lifeless> True
[23:15] <lifeless> (Pdb) self.target.has_revision('robertc@robertcollins.net-20050919060519-f582f62146b0b458')
[23:15] <lifeless> True
[23:15] <lifeless> I remember this
[23:16] <lifeless> mwhudson: for now, use what you've got to play with :)
[23:16] <jml> lifeless: thanks.
[23:24] <mwhudson> lifeless: yeah, makes senss i guess
[23:25] <lifeless> mwhudson: I've pushed the groupcompress initial bugfix
[23:27] <lifeless> mwhudson: wipe out your chk repo
[23:27] <lifeless> mwhudson: and apply this:
[23:28] <lifeless> --- bzrlib/repository.py        2009-03-07 06:42:07 +0000
[23:28] <lifeless> +++ bzrlib/repository.py        2009-03-08 23:28:00 +0000
[23:28] <lifeless> @@ -3381,10 +3381,7 @@
[23:28] <lifeless>                          # We don't copy the text for the root node unless the
[23:28] <lifeless>                          # target supports_rich_root.
[23:28] <lifeless>                          continue
[23:28] <lifeless> -                    # TODO: Do we need:
[23:28] <lifeless> -                    #       "if entry.revision == current_revision_id" ?
[23:28] <lifeless> -                    if entry.revision == current_revision_id:
[23:28] <lifeless> -                        text_keys.add((file_id, entry.revision))
[23:28] <lifeless> +                    text_keys.add((file_id, entry.revision))
[23:28] <lifeless>              revision = self.source.get_revision(current_revision_id)
[23:28] <lifeless>              pending_deltas.append((basis_id, delta,
[23:28] <lifeless>                  current_revision_id, revision.parent_ids))
[23:29]  * mwhudson tries that
[23:31] <mwhudson> lifeless: it's getting further, at least
[23:33] <lifeless> mwhudson: we still have a root bug, I'm not landing that patch as it will potentially make fetches a lot longer, but it will work :)
[23:38] <mwhudson> lifeless: i then got
[23:38] <mwhudson> bzr: ERROR: Revision {('NEWS-20050323055033-4e00b5db738777ff', 'john@arbash-meinel.com-20060920223617-ee51f416037ec263')} not present in "<bzrlib.plugins.groupcompress.groupcompress.GroupCompressVersionedFiles object at 0x1c2dc90>".
[23:39] <mwhudson> 7600 revs in :(
[23:41] <lifeless> mwhudson: grah, I'll run with the change I had you made; but again - use what you have :P
[23:46] <Kobaz> bob2: no it doesn't
[23:48] <Kobaz> budder {~/projects/basePBX/postgres/t} kobaz$ bzr diff *
[23:48] <Kobaz> bzr: ERROR: Path(s) are not versioned: postgres/t/v_cos_includes.pl postgres/t/v_extensions.pl postgres/t/v_trunks.pl postgres/t/v_cos.pl postgres/t/generatePolycomConfig.pl postgres/t/l4p_tests.conf "postgres/t/#v_cos.pl#" postgres/t/v_trunk_groups.pl "postgres/t/#v_extensions.pl#"
[23:48] <Kobaz> those files are in the repo... and if i do bzr diff v_cos_includes.pl, it works fine
[23:48] <Kobaz> and even the help says it takes one file
[23:49] <Kobaz> Usage:   bzr diff [FILE...]
[23:49] <Kobaz> hmm
[23:49] <bob2> Kobaz: because you used *, which your SHELL expands to every random file in that dir
[23:50] <lifeless> Kobaz: what are you trying to accomplish?
[23:50] <bob2> Kobaz: if you did bzr diff onefileinthebranch.pl twofileinthebranch.pl etc it would work
[23:50] <Kobaz> actually, if i do bzr diff file1 file2, that actually works
[23:50] <Kobaz> lifeless: do a diff of all the files in the dir
[23:50] <Kobaz> okay, so it does take multiple files... but it doesn't handle wildcards properly
[23:50] <lifeless> Kobaz: 'bzr diff .'
[23:50] <Kobaz> ah, that works
[23:51] <bob2> Kobaz: your shell handles the wildcards
[23:51] <SamB> heh
[23:51] <Kobaz> well
[23:51] <bob2> "'bzr diff legitfile.pl somefilethatisn'tinthebranch.pl" should file, imo
[23:51] <Kobaz> apparently there's some difference between bzr diff *, and bzr diff everyfileinthedirectory
[23:52] <mwhudson> lifeless: bzr.dev 2238 seems to be the problem this time
[23:52] <Kobaz> because if i take all the files... and make a list, and send it to bzr diff.. it works fine
[23:52] <bob2> Kobaz: you missed a file
[23:52] <bob2> Kobaz: e.g. the # backup files
[23:52] <Kobaz> but bzr diff * (which in theory is the same thing)... doesn't work
[23:52] <Kobaz> that doesn't throw an error
[23:53] <Kobaz> bzr diff #v_cos.pl#  #v_extensions.pl#  generatePolycomConfig.pl  l4p_tests.conf  v_cos.pl  v_cos_includes.pl  v_extensions.pl  v_trunk_groups.pl  v_trunks.pl
[23:53] <Kobaz> that works fine
[23:53] <Kobaz> $ echo *                                                                                                                                                   #v_cos.pl# #v_extensions.pl# generatePolycomConfig.pl l4p_tests.conf v_cos.pl v_cos_includes.pl v_extensions.pl v_trunk_groups.pl v_trunks.pl
[23:54] <Kobaz> that's the shell expansion
[23:54] <Kobaz> so... something wiggity is going on
[23:58] <Kobaz> ooooooh
[23:58] <Kobaz> i see what's going on
[23:58] <Kobaz> the error message is wrong
[23:58] <Kobaz> bzr diff \#v_cos.pl# generatePolycomConfig.pl
[23:58] <Kobaz> bzr: ERROR: Path(s) are not versioned: postgres/t/generatePolycomConfig.pl "postgres/t/#v_cos.pl#"
[23:58] <Kobaz> it should say : bzr: ERROR: Path(s) are not versioned: "postgres/t/#v_cos.pl#"
[23:59] <Kobaz> because the perl script is versioned
[23:59] <mwhudson> lifeless: so using the gc-chk255 format, loggerhead works but is ~twice as slow on most pages