#bzr 2008-07-21
<poolie> spiv, igc, i'm having some skype issues...
<poolie> are you here?
<rick_h__> lifeless: ping
<MatthewWilkes> Right 4 hours is enough. I may try again tomorrow
<gdoubleu> Is there anything special you need to do when pushing a loomified branch?  I pushed a loomified branch to launchpad from my laptop and then branched that onto another machine, but it didn't seem to have the threads.
<gdoubleu> I have the bzr-loom plugin on both machines
<Odd_Bloke> gdoubleu: Did you 'bzr record' first?
<gdoubleu> i did not
<Odd_Bloke> I think you need to.
<Odd_Bloke> Though I don't really use looms, so am not sure.
<gdoubleu> I'll try that and attempt to push again
<mwhudson> how do i make a branch7 branch?
<mwhudson> poolie, spiv?
<mwhudson> oh, done
<igc> hi all
<igc> fyi, I'll be working on porting/testing fastimport to use the new Repository API today
<igc> but I'll be offline for a few hours first - lunch & my daily hospital visit first
<mwhudson> hey, can bzrlib.repofmt.pack_repo.RepositoryFormatPackDevelopment1 get a new name in bzr.dev really fast?
<Odd_Bloke> mwhudson: Why?
<mwhudson> well, because it's a terrible name
<Odd_Bloke> What would you suggest instead?
<thumper> SuperDuperFormat?
<thumper> RockinFormat
<mwhudson> not sure what the conventions are
<Odd_Bloke> It'll be renamed to SuperDuperFormat or somesuch once it's actually that.
<Odd_Bloke> But, ATM, it's a development format.
<spiv> Something without "Development" would be nice, once it's no longer in Development.
<mwhudson> well, i'm kinda hoping 1.6 is actually going to get released soon
<Odd_Bloke> mwhudson: I think this format will be in development during the 1.6 cycle.
<Odd_Bloke> s/1.6/1.7/
<Odd_Bloke> So will be renamed before 1.7 is released.
<Odd_Bloke> So before then, users will only see it if they've opted-in to the use of a development format.
<mwhudson> speaking as a launchpad developer, i really hope not :)
<mwhudson> there's a difference between a development format and a non-default format, surely
<Odd_Bloke> In what sense?
<mwhudson> well, in the 'option name' sense
<spiv> rich-root-pack is a non-default format that isn't a development format, for example.
<Odd_Bloke> Well, it'll be hidden, I think.
<Odd_Bloke> It certainly should be hidden...
<spiv> i.e. the option for it is relatively non-scary, it isn't hidden, etc.  Whereas I think the --stacked option on a branch isn't going to be hidden?
<spiv> ISTR some discussion about it on the list.
<poolie> mwhudson: i have a patch that makes it a stable format
<mwhudson> poolie: excellent
<mwhudson> how can i see things that are note()d or mutter()ed when prodding bzrlib interactively?
 * mwhudson has vague memories of trace.enable_default_loggin()...
<poolie> like from a python interpreter
<poolie> yes that should do it
<gdoubleu> Odd_Bloke: about the pushing looms, it looks like it's not possible yet: https://bugs.launchpad.net/bzr-loom/+bug/201613
<ubottu> Launchpad bug 201613 in bzr-loom "pushing looms does not work properly" [Critical,Triaged]
<mwhudson> i think that bug is actually mostly fixed
<mwhudson> apart from the 'when do i need to record' confusion
 * mwhudson wanders off
<stub> How do I turn off the bzr prompt thing that seems to have installed itself into /etc/bash_completion.d ?
<tacone> boys, my bzr got locked, what to do ? --> Unable to obtain lock lp-147252812:///~rapache-devel/rapache/rapache-stage0/.bzr/branch/lock
<tacone> break-lock doesn't seem to work
<tacone> bzr: ERROR: Unsupported protocol for url "lp-147252812:///~rapache-devel/rapache/rapache-stage0/.bzr/branch/lock"
<stub> Is it a bug that bzr has installed /etc/bash_completion.d/bzrbashprompt.sh (breaking my prompt), or is there some way I need to turn it off?
<AfC> tacone: is that long number supposed to be there in the protocol?
<AfC> ï»¿/msg tacone Oh, just FYI, there are women here, too.
<bob2> stub: just have to rm it for now
<tacone> girls, my bzr got locked :(. http://pastebin.com/m4a069b45 what to do ?
<AfC> :)
<spiv> stub: there is a bug report about that
<AfC> tacone: maybe try `bzr break-lock bzr+ssh://tacone@bazaar.launchpad.net/~rapache-devel/rapache/rapache-stage0/`
 * tacone is about to switch in scared-newbie-mode-on
<spiv> tacone: "bzr break-lock bzr+ssh://tacone@bazaar.launchpad.net/~rapache-devel/rapache/rapache-stage0/"
<spiv> AfC: beat me :)
<tacone> lol
<AfC> spiv: Hooray!
<stub> And then file a bug about the message that tells you to do different
<spiv> stub: I'm just doing exactly that
<tacone> worked
<AfC> Terrific
<tacone> I'll file a bug for that, thanks.
<spiv> tacone: I just filed one
<spiv> tacone: https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/250451
<ubottu> Launchpad bug 250451 in launchpad-bazaar "bzr suggests wrong URL for break-lock with a LP hosted bra" [Undecided,New]
<kiorky> why does bzr-svn not want to store my creds :S
<tacone> spiv: oh god. I was about to click submit :-)
<tacone> ok, trashed :-D
<tacone> thanks you all. goodbye
<jelmer> kiorky, it's not bzr-svn that doesn't store them
<jelmer> kiorky, it's bzr itself
<jelmer> kiorky, any chance you can file a bug about this?
<lifeless> Jc2k: is the conduit guy around at the moment ?
<Jc2k> lifeless: he is
<lifeless> Jc2k: I have a few minutes before leaving for the train
<lifeless> rick_h__: hi
<Jc2k> lifeless: *tries to lure him on to gnome-bzr*
<jelmer> 'morning lifeless
<lifeless> ohi jelmer
<kiorky> jelmer: yep, but i am at work, but sue i can when i l have time
<kiorky> jelmer: maybe around 12:30, so 11:30 for u
<jelmer> Thanks
<kiorky> jelmer: describe me what u want as backtrace or tests and etc
<jelmer> kiorky, just the fact that passwords aren't saved should be sufficient
<blaudden> Hi, I'm running the "merge3-per-file" version of bzr and it just pops into "pdb" all the time. Can't see that it has any breakpoint set ot anything. Typing "cont" will run for a while and then stop at the same line again. Any advice?
<jelmer> blaudden, Is that John Meinel's branch?
<jelmer> You'd probably want to talk to him - he's around here as "jam" but it's probably too early for him right now
<blaudden> yes, it looks like that from "bzr log"
<blaudden> ok, i'll hang around. Thanks!
<spiv> blaudden: presumably there's a "pdb.set_trace()" either in your branch of bzr, or perhaps in a plugin
<spiv> blaudden: I'd try grepping for pdb in your branch of bzr and also in ~/.bazaar/plugins
<spiv> If you do "bt" at the (pdb) prompt it should give an indication of where the pdb.set_trace() line is
<blaudden> spiv: i'll try that.
<blaudden> 850  	            import pdb; pdb.set_trace();
<blaudden> thanks!
<spiv> blaudden: ta-da :)
<poolie> hello
<jelmer> spiv,poolie: Hallo!
<rick_h__> lifeless: still around?
<lifeless> rick_h__: yes, going v soon though to start travelling home
<rick_h__> lifeless: cool, have a good trip then
<rick_h__> just wanted to try to get this repo/branch thing right in my head
<lifeless> ok
<rick_h__> check that "commiting to the repo" "add files to the repo" were good
<rick_h__> and that creating a branch, and serving out the branch were right
<rick_h__> the docs with the shared repository for multiple branches seemed to make some sense
<rick_h__> I've just never set it up that way so repo == branch for appearance
<lifeless> yeah
<lifeless> branch is the user abstraction people work with
<lifeless> there is always a repository for  abranch, its implicitly created if no explicit one was made by the user
<rick_h__> so should I also commit your changes to the branch then?
<rick_h__> and the only time really refer to the repository is if setting up a shared one?
<lifeless> yup
<spiv> jelmer: hey
<rick_h__> ok, sounds like a plan then
<lifeless> the tip of a branch is the latest revision
<lifeless> a branch has a tip, tags, and configuration details
<rick_h__> yea, that comment in that article threw me a bit, but I found some of the docs that seemed to clear it up more
<spiv> jelmer: how soon will bzr-svn be faster (the "find_tags is slow" bug)? :)
<rick_h__> well have a nice trip lifeless and hopefully this article will be life in Oct and then I can bug you on some more advanced stuff :)
<lifeless> sure thing
<jelmer> spiv: couple of days hopefully
<Peng_> With one slow and large svn repository, bzr-svn spends a massive amount of time crawling the whole thing for tags even when I do a no-op "pull", and even though the branch I actually have checked out is quite tiny.
<jelmer> Peng, there's an open bug about this
<Peng_> Okay. Well, if you want an example branch, http://software.inl.fr/svn/mirror/tools/ipy/trunk (but I didn't try to reproduce it; I don't feel good about abusing random svn servers to test things).
<jelmer> Peng_, Thanks for reporting this. It'll hopefully be fixed in a couple of days
<jelmer> (see also spivs comments a couple of lines back)
<Peng_> Yeah, since the subject had been brought up, I just wanted to mention it.
<kiorky> jelmer: uhm i have another problem, i have a bzr+qsvn branch, then i rebranch locally, but it trys to acces the foreign repo. Why ?
<kiorky> jelmer: the work connection is pretty bad, soi like to work offline :)
<trepca> hey
<jelmer> kiorky, hi
<jelmer> kiorky, I suspect you don't have an actual local branch but just a local working tree
<jelmer> kiorky: E.g. "svn co" will not create a local branch
<kiorky> jelmer: i used bzr branch svn+http://svncred:pass@foo
<kiorky> jelmer: then bzr branch ../path
<jelmer> kiorky: Where ../path was created with "bzr branch" ?
<kiorky> the first yes : "bzr branch svn+http://svncred:pass@foo"
<jelmer> not "bzr co" ?
<kiorky> nope
<jelmer> if that created "foo" then "bzr branch foo bla" should not access the network
<kiorky> i can redo it to double check
<kiorky> let me a minute
<kiorky> jelmer: ~>bzr branch foo bar
<kiorky> <https://subversion.makina-corpus.net:443> Login LDAP Makina Corpus mpa password:
<kiorky> jelmer: :)
<kiorky> which a fresh bzr branch svn+...
<kiorky> (in foo)
<nevans> bug in bzr-svn relating to checkouts: https://bugs.launchpad.net/bugs/248289
<ubottu> Launchpad bug 248289 in bzr-svn "concurrent access problems" [Undecided,New]
<nevans> It seems that bzr will try to lock the checked-out branch during a bound branch's commit...
<nevans> but it can't lock an svn "branch", so it winds up rewinding history on the svn repo.  :-(
<nevans> I didn't even notice this had happened until recently... apparently I've done it four times in the last six months...
<nevans> s/done it/triggered this bug/
<pickscrape> Is there something in bzrlib that I can use to list files in a remote directory? I'm specifically talking about a non-branch directory (e.g. a directory that might contain branches)
 * pickscrape looks at bzrlib.transport
<james_w> pickscrape: there is listdir(), but it doesn't work over http
<pickscrape> james_w: I've got transport's list_dir working very nicely over bzr+ssh, thanks!
<bpeterson> Bazaar can use a variety of different libraries for http, correct?
<luks> where 'variety' == two
<bpeterson> urllib and pycurl?
<luks> but I think plain urllib2 is now the prefered one
<luks> yes
<bpeterson> is one faster than the other?
<luks> faster in what way?
<luks> even if one is faster than the other, it won't be noticable
<luks> network will be limiting them, not CPU
<bpeterson> it's just that bzr over http seems quite slow to me
<luks> bzr is slow over http
<luks> or generally, bzr is slow :)
<bpeterson> especially with networking
<james_w> bpeterson: slower than what?
<bpeterson> hg
<bpeterson> I still use Bazaar because st, diffing, and committing are pretty snappy, but not networking...
<luks> what format are you using?
<luks> (bzr info)
<bpeterson> rich-root-pack
<luks> ah, not much you can do, I'm afraid
<bpeterson> is rich-root-pack a comprise for space over something else?
<radix> bpeterson: I think what he means is that the pack-based formats are the most efficient formats right now, so there's nothing better for you to upgrade to for better performance over HTTP
<james_w> bpeterson: static-http for hg?
<bpeterson> yep
<nevans> how does sftp compare to http for performance?
<nevans> still the same bottleneck?
<bpeterson> actually I'm more concerned with performance over bzr+ssh
<fullermd> No, I think sftp has all different bottlenecks   :)
<fullermd> I'm pretty sure sftp eats more round trips, so it's probably a bit more latency sensitive.
<bpeterson> it's over ssh, so shouldn't have state?
<fullermd> Well, bzr+ssh is a totally different beast from either, so...
<bpeterson> mm
<nevans> I think it must depend a lot on various factors (e.g. size of your repo).  I just did some tests on a very small branch of mine... and bzr+ssh actually went slower than http.
<nevans> probably because it has additional overhead of ssh connection and starting up bzr on the remote end
<bpeterson> I'm working with the Python core bzr repo; ~200 MB
<LeoNerd> 'bzr st' still claims a pending merge, even though I've shelved it away for now... How might I clear that?
<LeoNerd> In actual fact I probably want to just revert it, but I'm keeping it shelved for now
<bpeterson> LeoNerd: bzr resolve
<luks> bzr revert --forget-merges
<LeoNerd> Ah yes; the latter did it
<LeoNerd> bpeterson: isn't that for conflicts?
<bpeterson> yes, never mind
<bialix> luks: hi
<luks> hey
<bialix> good evening
<bialix> luks, Garyvdm was very helpful in fixing regressions
<bialix> I think we are ready to release 0.9.2
<luks> I haven't followed the latest fixes
<bialix> I'm planing to prepare some screenshots with new features
<luks> but the current state is usable for me
<bialix> me and Gary have fixed all known (for me) regressions so far
<pickscrape> Does anyone know what happened to the bzr gentoo overlay?
<bialix> luks: so I'm about to starting release process tonight or tomorrow
<luks> cool, thanks a lot
<luks> I've uploaded translations to launchpad, still waiting for review :(
<bialix> I saw.
<bialix> I'm confused because I could cange status of some translations
<bialix> I'm confused because I could change status of some translations
<bialix> I won't wait for translations and don't want to delay release
<bialix> but if you wanna to update sk.po I'll wait
<bialix> pickscrape: what's up with Gentoo?
<pickscrape> Well, I added the overlay a while back to layman, which set it up as a bzr branch that it would pull
<pickscrape> But lately it seems that the branch it pointed at has gone away.
<pickscrape> Wondering if it has died or just been moved somewhere else.
<bialix> luks, I can't create deb for linux. But it will be nice to have it for 0.9.2. This release will be a bomb
<luks> bialix: umm, I might do it
<luks> but I actually wanted to get rid of the PPA
<luks> it's easy to install it on linux
<bialix> well, I'm fine either way
<bialix> if you will close PPA, then I'll just need to update our wiki page properly
<luks> I did :)
<luks> or do you mean more than removing it from there?
<pickscrape> Is bzr-gtk no longer going to be in the bzr PPA then?
<luks> this is about qbzr
<pickscrape> oic
<bialix> pickscrape: I'm actually using Windows, but I saw this: https://launchpad.net/bzr-gentoo-overlay May be it helps you
<pickscrape> bialix: thanks, I just found that myself. I think they might have moved it, so I'm setting it up again to find out...
<bialix> luks: I mean this: https://launchpad.net/~luks/+archive
<bialix> I don't know PPA well, so maybe presence of 0.9.0 confused me a bit
<luks> let me see if I can remove 0.9.0 from there
<bialix> ok. I'm just wanted to check this with you
<luks> I'll probably build 0.9.2 after the release
<luks> but in a ~qbzr-dev PPA
<bialix> ah, ok. make sense
<chadmiller> Hi.  I work in a project that makes a lot of tags.  |wc -l  says "320".  This brings into relief that tagging in bzr is kind of weird.
<LeoNerd> A tag is just a human-readable "friendly" name for a revision... same as a hostname is just a friendly name for an IP address
<jam> chadmiller: How are you using tags, and how is it a bit weird in bzr?
<jam> (eg, care to elaborate?)
<jam> You might be using branches for tags, which is an older way that is certainly clumsier
<chadmiller> Consider this morning:  Tim noticed that some tag was on the wrong revision.  He used "bzr tag --delete", "bzr tag", "bzr push" to change it.  Paul comes along and, on pull, gets "Conflicting tags:\n\tblah-blah".  This concerns Paul.  He's questions whether his tree is valid, completed "pull" correctly, et c.
<jam> chadmiller: well, tim could have used "bzr tag --force" but sure
<chadmiller> He can't tell very much with "missing" or "log".
<jam> The problem is that tags aren't versioned
<jam> so when they disagree
<jam> we don't know which one is "more correct"
<chadmiller> Right.
<jam> we've had some long discussions about it
<jam> it is hard to do better without introducing a whole lot of "meta" overhead
<jam> chadmiller: is there some ui polish we could apply to make it a bit more understandable?
<chadmiller> I think my biggest problem with it is informational.  Maybe the "Conflicting tags" message should also have "Don't Panic" in warm, friendly letters.
<jam> Conflicting tags: <3 <3
<jam> Something like that?
<Jc2k> now it sounds like bzr is enjoying your suffering
<bpeterson> perhaps provide a bzr tag --rename command?
<bpeterson> or document that you should use bzr tag --force if you want to rename
<bpeterson> here, I'll send you a bundle
<jam> bpeterson: "bzr help tag"
<jam> --force               Replace existing tags.
<jam> But if it is missing in other documentation, feel free :)
<jam> also, '--rename' sounds like it would change the name of the tag (but point to the same revision)
<jam> which isn't the same as pointing the same name to a different revision
<chadmiller> :)  "Your $(verb)s completed, but upstream disagrees about which revisions these tags should appear on.  Your tags were not updated.  Conflicts:\n"
<bpeterson> isnt' that what chadmiller wanted?
<chadmiller> "%", not "$", grr.
<jam> chadmiller: well, probably 'not all tags were updated"
<jam> but I understand
<chadmiller> Something in the "tag{,s} --help" about resolving those would be good too.
<chadmiller> And "bzr pull --clobber-local-tags" ?
<bpeterson> so if you want to rename a tag (change the name, but keep it on the same revision), you should bzr tag --delete name and bzr tag --force name
<bpeterson> ?
<pickscrape> We actually encountered exactly this this mornin g
<jam> bpeterson: I would do "bzr tag new-name -r tag:oldname"
<jam> and then "bzr tag --delete oldname" if you prefer
<pickscrape> A colleague changed a tag, and when I tried to pull I got the 'conflicting' message
<jam> but deleting tags doesn't propagate at the moment..
<pickscrape> The solution was for me to redefine the tag at my end, after that pull worked.
<pickscrape> The problem is, I didn't know (other than talking to him myself) what revision he had changed it to
<jam> pickscrape: I *think* you can also "pull --overwrite" but I'm not 100% sure.
<jam> pickscrape: bzr log -r tag:NAME path/to/his/branch
<pickscrape> jam: I was worried about --overwrite clobbering my local changes
<jam> or 'bzr tags -d /path/to/his/branch"
<pickscrape> It would have been good if the message had told me which revision the tag was defined as upstream
<bpeterson> uhh. that new launchpad ui sure gets me
<trepca> is there anyway to save my password for HTTP auth
<trepca> it's a pain typing it every time
<trepca> even worse ... it asks me several time
<chadmiller> Uhm, is the ppa "bzr-beta-ppa" a likely candidate for the real release?
<chadmiller> There's some serious evil in there.
<jam> Care to list specific evil?
<jam> I know poolie plans a couple changes before an rc1
<chadmiller> etc/bash_completion.d/bzrbashprompt.sh .   1) clobbering $PS1.  2a) running a python interpreter twice for every shell prompt.  2b) running /bzr/ twice for every shell prompt.
<jam> chadmiller: ah, that is planned to be fixed
<jam> we weren't meant to install that file
<jam> it is a packaging issue
<chadmiller> Whew!  Okay, good.
<jam> in the short term you can just rm that one
<radix> that reminds me of when I installed git-core and it installed a bash completion file which ran git twice
<radix> unfortunately, there's another program I have installed in ~/bin called "git", which is an interactive fiction interpreter for Glulx games
<radix> so every time I started a new terminal two GUI windows would pop up and give an error message
<jam> radix: at least it wasn't on every \t :)
<radix> heh, yeah
<pickscrape> I'm writing a plugin for internal use that provides a main command with subcommands (shelf-style)
<pickscrape> it's been going well, but I'm now having a problem adding options to the subcommands
<pickscrape> It seems that bzrlib is trying to parse them as part of the main command, and complaining that it doesn't have the option
<pickscrape> I suppose this is because subcommands are a bit of a hack, bit I'm wondering if anyone knows of a workaround
<LarstiQ> pickscrape: ah, you're overloading short options that already exist in bzr?
<LarstiQ> pickscrape: oh no, I see now.
<LarstiQ> pickscrape: well, as a hacky workaround, combine the main command's options from the subcommand options?
<pickscrape> LarstiQ: I was just going to try that. It might work, the only problem being the options would show up againt the main command in the help output. I will give it a try though
<LarstiQ> pickscrape: yeah
<james_w> pickscrape: you may be able to write a subclass of Command that works better with subcommands
<pickscrape> james_w: I thought I'd find that when I originally looked at the shelf code, but didn't. Now that I've hit this obstacle I think I might revisit that idea again :)
<james_w> it would be a useful thing to have in the core for other plugins to make use of, e.g. shelve
<pickscrape> Yes, I was thinking that too. If I get one working I'll see about making it available to bzr. Thing is, nothing in bzrlib would actually need it right now.
<LarstiQ> pickscrape: but because it isn't there, no one feels invited to use it :)
<pickscrape> chicken/egg :)
<pickscrape> My concern is more related to testing/bitrot: if it gets added but not used etc...
<LarstiQ> pickscrape: right, I see.
<pickscrape> I suppose shelf could keep it happy though if it was migrated to use it.
<LarstiQ> pickscrape: if there are two plugins using it though, I think the use part is reasonably covered. For it to be accepted into core it needs to be fully covered with tests anyhow.
 * LarstiQ nods
<pickscrape> Hmm, on that idea, perhaps it would be better added to bzrtools initially, and then to core once stable etc?
<Gilgad13> if i want to move an entire directory that is versioned, how would i do so?  i've tried "bzr mv oldDir path\to\newDir" but i get an error that newDir is not versioned.  Do I have to create and add newDir first?  Is it possible to move whole directories?
<Gilgad13> i'm using windows, if it matters
<pickscrape> Is newdir inside the same branch as the directory you're moving?
<Gilgad13> yes, its executed exactly like that, ie. both paths are relative
<LarstiQ> Gilgad13: is path\to\ versioned?
<pickscrape> Does path\to already exist and versioned?
<Gilgad13> no, should it be?
<pickscrape> Gilgad13: yes
<LarstiQ> Gilgad13: I'd think so.
<Gilgad13> hang on...
<james_w> is there a typo in oldDir
<james_w> I think if that is the case it complains about the wrong thing
<Gilgad13> no, versioning path\to worked
<Gilgad13> and an obvious next question.  can I undo a specific move, without reverting to last commit?
<Gilgad13> no handy undo-last?
<pickscrape> bzr uncommit will undo your last commit, but it will cause problems if the commit has been published elsewhere
<Gilgad13> i'm talking about operations between commits, like complex reorg's with multiple moves.  Right now i either bzr revert or move the moved file
<pickscrape> Oh. I think revert should do what you need it to
<Gilgad13> but it would be nice to have the safety net
<Gilgad13> well, if i'm like 4 move's in, it would suck to redo them because of a typo
<LarstiQ> Gilgad13: if it's really complex there is no silver bullet.
<pickscrape> revert won't undo only the last move I don't think
<Gilgad13> damn, i like silver bullets
<pickscrape> AFAIK it just looks at the WC picture as a whole.
<Gilgad13> pickscrape: exactly
<Gilgad13> so i'd have to start over
<LarstiQ> starting over doesn't seem like the way to go?
<pickscrape> Could you just bzr mv the file back again?
<LarstiQ> Gilgad13: but I don't have a clear enough picture of your situation to really give advice.
<Gilgad13> pickscrape: its what i've been doing
<james_w> you can "bzr mv" back, and "revert path" would probably do it, but obviously would do the wrong thing if the files were modified as well
<Gilgad13> LarstiQ: its mostly hypethetical, so no worries
<LarstiQ> Gilgad13: are you looking for a revert that only undoes treeshape changes, not content changes?
<Gilgad13> LarstiQ: yes, and if possible lets me select specific changes
<LarstiQ> problem with that being creating a tree state that never existed in history, but yes.
<LarstiQ> Gilgad13: what do you mean exactly? 'bzr revert -r a..b path/' wouldn't be enough?
<Gilgad13> having experimented more, i think its a mental problem with how i thought bzr recorded moves
<Gilgad13> as in, i thought the recorded a log of actions, but i now see that only the beginning (ie, last commit) and end(now) state matter, not how many moves were applied inbetween
<Gilgad13> s/the/bzr in first line
<LarstiQ> Gilgad13: ah, indeed.
<pickscrape> LarstiQ: I may be jumping the gun a bit here, but it looks like the only change needed to get subcommands working properly is to call parser.disable_interspersed_args() in _parse_args after retrieving it
<pickscrape> Sorry, parse_args
<pickscrape> (I moved it into a local subclass and called it _parse_args.)
<pickscrape> So if that was moved into the Command class itself, a simple switch could potentially allow subcommands with options to function.
<pickscrape> Hopefully I didn't make any other changes that I forgot to take into account here...
<pickscrape> In fact, simply adding that right into bzrlib appears to make everything work, and doesn't appear to break anything else.
 * pickscrape goes off to run the bzr unit tests for the first time ever :)
<pickscrape> Yeah, it does break some things. :) This is what tests are for.,..
<lifeless> Gilgad13: you can 'bzr revert FILENAME'
<Gilgad13> aye, but what would that do with regards to moves?  unmove them?
<Gilgad13> revert content changes?
<meatballhat> are transparent checkouts from svn supposed to 'just work'?
<lifeless> Gilgad13: it would put the path back and revert content changes; I think there i sroom for a --path-only flag or something
<lifeless> meatballhat: yes, though you can't pull or merge into a an actual svn tree
<lifeless> meatballhat: ((ecause svn can't add revisions without doing a commit to a branch)
<meatballhat> lifeless: so there is nothing akin to the 'git-svn' interface, or do I misunderstand? :)
<lifeless> meatballhat: you misunderstand
<lifeless> meatballhat: 'svn co svn://... foo && cd foo && bzr merge bzr://...' -> FAIL (the .svn directory is not capable of representing a pending merge)
<lifeless> meatballhat: 'bzr branch svn://... foo && cd foo && bzr merge bzr://... && bzr commit && bzr push svn://...' -> WIN
<meatballhat> lifeless: so I use bzr <command> with 'svn://' urls? or are you only explaining the workflow?
<meatballhat> rather, is the use case documented for "I'm at work and my company uses Subversion, but I'd like to interface with it using Bzr" ?  :)
<lifeless> meatballhat: I think its documented on the FAQ
<lifeless> meatballhat: and yes, you use svn urls with bzr
<meatballhat> lifeless: thanks much!
<wingo--tp> what's robert collins' nick? any idea why he hasn't definitively commented on https://bugs.launchpad.net/bzr/+bug/239499 ?
<ubottu> Launchpad bug 239499 in bzr "corrupt knit index on an old arch-imported bzr repo" [Medium,Confirmed]
<lifeless> wingo--tp: that would be me
<wingo--tp> ah hello good sir!
<lifeless> wingo--tp: I've been travelling for the last two weeks; kind of fragments things
<wingo--tp> ah ok
<wingo--tp> i'll wait then :)
 * wingo--tp just got back to a normal rhythm, post-guadec
<lifeless> yah, I had a distro sprint post guadec, then LRL
<lifeless> currently in an airport
<wingo--tp> yowsers
<thumper> lifeless: what is LRL?
<lifeless> thumper: lug radio live
<thumper> ah
<jam> lifeless: I thought it might be something like "Living Real Life", but I was pretty sure you don't do that :)
 * lifeless gestures
<lifeless> jam: what do you think of the marks rfc?
<jam> lifeless: I think it could be really neat, as long as it doesn't get too complex for the user
<jam> the hunk-level support is interesting
<jam> I'm not sure how we would layer it in for stuff like 'commit', though I'm sure it is possible
<jam> I guess it could just be a MarksTree(WorkingTree)
<jam> lifeless: I was just looking over your testresources code, aren't you being naughty and iterating over a dictionary you are mutating?
<jam> Or is that strictly allowed with your priorityDictionary
<poolie> jam, hello
<jam> hi poolie, ready for a call?
<poolie> yes, does skype suit you
<lifeless> jam: I don't recall; its nearly entirely paged out
<jam> lifeless: no problem, looking closer it seems to be the way it is designed
<jam> poolie: skype is fine
<jam> lifeless: sorry to hear about your flight being delayed, are you on your way back to AU?
<lifeless> yes
<lifeless> jam: I think marks should be core
<lifeless> poolie has said hes concerned by that :)
<lifeless> I just think its likely to need to be pretty fundamental to work well and consistently
<jam> lifeless: I think marks is hooking into a lot of places, so it would end up decorating a lot of commands
<jam> status/diff at a minimum
<lifeless> jam: yah
<jam> commit
<poolie> i was imagining a decorator type object too
<jam> I'm not sure about update
<lifeless> so I'm thinking a WT5 tree; with methods to get a flavour view
<jam> poolie: yeah, even if it was "WT.get_view('xxx') which returned ViewTree(self)
<poolie> i don't really necessarily mind it being in the core as long
<lifeless> or even just change the view on the main object
<poolie> something about that mail worried me on first reading
<poolie> i would hope that we can work out a way to eg make a ViewTree rather than patching things all over the place
<lifeless> lets not use the term view here
<lifeless> views are Ian's partial-files-on-disk project
<lifeless> which has some overlap but is different
<jam> lifeless: well, MarksTree is a bit clumsy, but something like that
<jam> sure
<lifeless> (I realise I used the term view above; naughty robert :))
<poolie> it would also be nice to support
<poolie> commit --interactive
<poolie> which would ask which files or hunks to commit
<lifeless> jam: one way is to decorate a WT; another is to alter the behaviour of the WT itself
<lifeless> poolie: yes, bzr-interactive does this already
<poolie> and this might want to create a transient in-memory view just for that one command
<poolie> oh, nice
<lifeless> poolie: and I think I proposed a way to do that in the thread using marks
<jam> lifeless: sure, though I think doing it with a decorator is a bit better separation of concern
<jam> but as long as it is tasteful, either way is fine
<lifeless> merge needs to preserve marks for instance
<lifeless> indeed tree transform needs to know
<lifeless> though perhaps a lookaside structure will work
<bud3030_> Hi Bzr I have a 2nd pc with hardy on it I wen to change passwd under preference  now the new and old want auth.
<bud3030_> If there is not a fix that mean a clean install
<lifeless> what protocol are you using with bzr?
<jam> lifeless: do we have any way of creating branching/merging history without creating a real tree on disk?
<jam> BranchBuilder and MemoryTree don't really seem to offer that functionality
<lifeless> jam: they both do, but at quite a low level, not by calling merge()
<jam> lifeless: how do you create the second branch?
<jam> BranchBuilder only has 'build_commit'
<jam> and never exposes its tree
<lifeless> oh hmm; remember tired :) I'm sure MemoryTree supports set_parent_ids
<lifeless> BranchBBuilder though I dunno
<jam> ah, I guess
<jam> I guess I could do the 1 MemoryTree and use uncommit, etc to move it around
<jam> I'll try it
<jam> Though I guess I also need to create files in the tree
<jam> which is difficult with MemoryTree ... :(
<jam> oh, I guess you have put_file_bytes...
<lifeless> right
<lifeless> its why it exists :P
<jam> but it requires a file_id
<jam> which is a bit odd for creating a new file
<lifeless> yes, which add gives you
<lifeless> add([foo], [fooid], [file])
<jam> so you just "add(['foo']" even though foo doesn't actual exist?
<lifeless> put_file_bytes(fooid, content)
<jam> _add you mean?
<lifeless> public add
<jam> ah, and by passing the kinds it shortcuts '_gather_kinds'
<jam> ok
<lifeless> could you eyeball https://bugs.launchpad.net/bugs/250514 please
<ubottu> Launchpad bug 250514 in bzr-email "bzr-email fails to send via a gmail tls smtp connection (needs ehlo cmd)" [Undecided,New]
<jam> lifeless: I thought we already had a proper patch for that a while ago
<jam> maybe it just didn't make it into trunk?
<lifeless> ><
<jam> jamesh: ^^ Didn't you work up a proper "resend ehlo after starting tls" ?
<jam> lifeless: ah, it is the one in bzrlib which is fixed
<jam> And for some reason the 'email' plugin doesn't use the one in bzrlib
<lifeless> I thought it had been patched to do so :(
<jam> lifeless: well, it is parameterized
<jam> so it looks easy to do so
<jam> but for some reason, I don't see a "from bzrlib import XXX"
<lifeless> weird
<jam> lifeless: I uploaded a simple patch on it
<lifeless> jam: thanks
#bzr 2008-07-22
<mwhudson> hm
<mwhudson> why are the only calls to bzrdir.clone() with preserve_stacking=True in the branch_implementations tests?
<mwhudson> hm
<mwhudson> i guess a branch is certainly involved if there is stacking going on
<lifeless> mwhudson: push --stacked uses clone, no ?
<mwhudson> lifeless: i guess i should have inserted the word 'direct' into my sentence somewhere
<spiv> "Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)" :)
<mwhudson> spiv: and the format is actually development1 ?
<spiv> mwhudson: no, it actually is one of those
<mwhudson> ok
<mwhudson> spiv: https://bugs.edge.launchpad.net/bzr/+bug/250422
<ubottu> Launchpad bug 250422 in bzr "pushing over hpss ignores stacking policy" [Undecided,New]
<mwhudson> spiv: instant thoughts?
<spiv> mwhudson: "that sounds like a bug"
<mwhudson> spiv: i'm glad you think so
<spiv> mwhudson: A -Dhpss trace might be interesting.
<spiv> mwhudson: a wild guess is that RemoteRepository doesn't look at the stacking policy?
<lifeless> I din't want to invent ftp
<lifeless> so the client is meant to resolve $shit
<mwhudson> spiv: the problem is that i don't know which piece is _supposed_ to look at the stacking policy
<mwhudson> i guess i should read through cmd_push
<lifeless> so I'm thinking for marks
<spiv> mwhudson: me either :)
<mwhudson> hmmmm
<mwhudson> spiv: the problem seems like it might be RemoteBzrDir.get_config not doing the right thing
<spiv> mwhudson: I can certainly believe that.
<mwhudson> spiv: i commented on the report
<spiv> mwhudson: if you implement a "def get_config(self): self._ensure_real(); return self._real_bzrdir.get_config()" does that fix it?
<mwhudson> spiv: let's find out
<mwhudson> spiv: no
<mwhudson> though, um
<mwhudson> spiv: if you add it to the right class, yes, that seems to help
<mwhudson> :)
<spiv> mwhudson: that's good to know.  Send a patch to the list :)
<mwhudson> spiv: where should a test go?
<mwhudson> er
<mwhudson>         config = my_dir.get_config()
<mwhudson>         if config is None:
<mwhudson>             self.assertFalse(isinstance(my_dir, bzrdir.BzrDirMeta1))
<mwhudson>             raise TestNotApplicable(
<mwhudson>                 'This BzrDir format does not support configs.')
 * mwhudson objects, furiously
<lifeless> IsNotInstance ?
<lifeless> hmm, I want a composer
<spiv> lifeless: I suggest Bach
<lifeless> EDEAD
<lifeless> in this regard, I'm a vitalist
<mwhudson> so what are BzrDirFormat5 and BzrDirFormat6 ?
<lifeless> bzr 0.5 and 0.6
<lifeless> they are all-in-one formats
<mwhudson> so caring about them is not at all encouraged?
<lifeless> we upgrade from them
<lifeless> but clearly they cannot support stacks because their repository is not modular - you can't change the repository logic without stopping it being a bzrdirformat5 or whatever
<mwhudson> ok cool
<lifeless> that test wants a whitelist not a blacklist because of e.g. bzr-svn etc
<lifeless> its an /interface/ test not an implementation test.
<ppires> hi :-)
<mwhudson> lifeless: whitelist as in "these formats are allowed to not do get_config" ?
<lifeless> 09:56 < mwhudson>             self.assertFalse(isinstance(my_dir, bzrdir.BzrDirMeta1))
<lifeless> thats a whitelist
<lifeless> these formats are required to do it
<mwhudson> oh, ok
<lifeless> ppires: hi
<lifeless> mwhudson: installing bzr-svn won't magically change a static list like that, and it doesn't have a full plain text format
<mwhudson> lifeless: right, fair enough
<ppires> do i need bzr installed in order to use something like bzr-eclipse plug-in?
<lifeless> ppires: yes
<lifeless> ppires: there is a faq for installing bzr-eclipse
<ppires> yes there is lifeless, but as i'm having some issues with the plug-in itself just wanted to double check. thanks
<lifeless> Verterok: ^
<lifeless> Verterok is the author
<mwhudson> lifeless: it wasn'
<mwhudson> t immediately clear to me that bzr-svn's bzrdir should return None from get_config as opposed to a config that had no values set
<lifeless> mwhudson: I don't actually know what it does offhand :P
<mwhudson> though i guess set_default_stacked_on is part of the config interface...
<jelmer> lifeless: it returns an object that converts some svn file properties to bzr settings
<bob2> is it a known bug that merging a bundle based on a revision you don't have causes a traceback (couldn't find it on lp but want to double check).
<jelmer> in particular the mergeWithUpstream property used by svn-buildpackage, which is convert to the equivalent for bzr-builddeb
<mwhudson> hmm
 * mwhudson appears to be unable to drive send
<jelmer> mwhudson: why does that matter?
<mwhudson> bzr send -o- produces something reasonable
<mwhudson> but 'bzr send' doesn't attach anything to the mail
<Verterok> lifeless: thanks
<mwhudson> jelmer: because of the way the test for bzrdir.get_config() is written
<Verterok> ppires: if you have any issues with the plugin, maybe I can help
<lifeless> Verterok: I demoed bzr-eclipse at lugradio live too FWIW
<Verterok> ppires: also I'm going to release a new build in the next few days (hope I can get it for tomorrow)
<Verterok> lifeless: yay! :)
<ppires> hi Verterok i'm here looking how to install plug-ins. http://bazaar-vcs.org/UsingPlugins is not very clear about it
<ppires> i mean, they talk about folders, but not how to install them. should they be compiled somehow?
<Verterok> ppires: which OS?
<ppires> http://bazaar-vcs.org/XMLOutput only offers the source-code.
<ppires> Linux, Ubuntu 8.04 to be more precise
<Verterok> ppires: bzr branch lp:bzr-xmloutput/0.4 $HOME/.bazaar/plugins/xmloutput
<Verterok> ppires: that should do the trick :)
<mwhudson> is there a convention for including bug numbers in merge requests?
<Verterok> ppires: or you could do a checkout:  bzr co lp:bzr-xmloutput/0.4 $HOME/.bazaar/plugins/xmloutput
<ppires> lp is a shortcut to launchpad?
<spiv> Yep.
<ppires> cool!
<lifeless> bye guys
<ppires> Verterok: i'm using eclipse ganymede (3.4) and bzreclipse leaves some "unable to staisfy dependency" in the Error log
<igc> morning
<Verterok> ppires: I'm not sure if it works with 3.4, let me check (I'm still with 3.3)
<Verterok> mornin' igc
<igc> hi Verterok
<ppires> i cannot reach "Console" and "Decorators" tabs. eclipse complains about invalid values
<ppires> bye lifeless and thanks
<ppires> morning igc
<Verterok> ppires: you must configure the location of the bzr executable
<Verterok> ppires: in the "Bazaar" pref. page
 * Verterok launching Eclipse 3.4
<mwhudson> spiv: sent to the list
<Verterok> ppires: I can't even start 3.4 :( (I think I should download the final release :P )
<ppires> you were right Verterok
<Verterok> ppires: it's working? if not, could you pastebin the error?
<ppires> eheh, i'm running the latest stable release
<ppires> Verterok: this is a lamme question, but are Decorators the ability to mark graphically resources like files?
<ppires> and folders..
<spiv> mwhudson: thanks
<Verterok> ppires: yes, to show the status of the file/folder/project
<ppires> ok, i answered this one and i was in doubt. https://bugs.launchpad.net/bzr-eclipse/+bug/160907
<ubottu> Launchpad bug 160907 in bzr-eclipse "When creating new classes in Eclipse it would be nice if they were automatically added to bazaar" [Undecided,Incomplete]
<ppires> wow cool bot!
<Verterok> ppires: right, the files/folders are flagged with the db-like orange icon (like in the CVS plugin)
<ppires> never used cvs. anyway, Verterok does this plug-in support bzr+ssh?
<Verterok> ppires: it should, because it uses bzr to execute the commands
<ppires> i'm not used to bzr that's why this may sound a bit confusing to me.
<Verterok> ppires: be carefull with the authentication, check Bug #121936
<ubottu> Launchpad bug 121936 in bzr-eclipse "Eclipse hangs in bazaar operations that require user input" [High,Triaged] https://launchpad.net/bugs/121936
<ppires> ic, tks!
<Verterok> ppires: for workaround until I fix it, look the Authentication section in http://bazaar-vcs.org/BzrEclipse/Installation
<ppires> now i'm going for bed. work tomorrow. tks a lot Verterok! i'll keep in touch ;-)
<Verterok> ppires: np, sleep well, see y'later
 * Verterok running out of battery, be back in while
 * mwhudson lunches
 * beuno dinners
<cody-somerville> +
 * emgent thinking to sleep.
<mwhudson> this is a little surprising: http://pastebin.ubuntu.com/29167/
 * mwhudson digs
 * spiv -> lunch
 * mwhudson is probably done pelting the bazaar list with merge requests now
<mwhudson> huh how bizaare
<mwhudson> beuno: still here?
<beuno> mwhudson, yeap
<beuno> despite my ISPs attempt to make me got to sleep
<mwhudson> i have this pair of branches where merging a into b gives 'nothing to do' and merging b into a gives conflicts
<mwhudson> wtf??
<mwhudson> what now?? http://pastebin.ubuntu.com/29210/
<mwhudson> what now?? http://pastebin.ubuntu.com/29210/
<spiv> mwhudson: that's an unexpected traceback.
<mwhudson> yeah
<spiv> It makes about as little sense to me as it does you :
<spiv> :)
<mwhudson> it happens with the installed 1.6b3, not bzr.dev
<mwhudson> i guess it's a circular import
<mwhudson> and one of my plugins happens to import branch earlier or something
<mwhudson> spiv: does it happen for you?
<mwhudson> it's very quick, obviously, before even the check that '.' is a branch
<spiv> mwhudson: nope, but I only have bzr.dev
<mwhudson> fair enough
 * mwhudson corrects the mail he's about to send from going to Martin Pool to going to Martin Albisetti 
<mwhudson> one of you guys has to change his name, i think
<spm> mwhudson: put forward the request in #canonical-sa's?
<mwhudson> spm: maybe
<kiorky> jelmer_: https://bugs.launchpad.net/bzr-svn/+bug/250706
<ubottu> Launchpad bug 250706 in bzr-svn "branching locally tries to reach forward svn server" [Undecided,New]
<jml> I want a programming language / refactoring tool / editor / vcs that understands itself.
<jml> and a pony.
<spiv> A self-aware pony?
<jml> maybe.
<jml> It's hard to say. I so rarely use ponies to make changes to things.
<mwhudson> jml: i'm sure you can still get a LispM from somewhere
<jml> mwhudson: do you reckon they'd integrate with my freerunner?
<mwhudson> jml: they would probably destroy it quite thoroughly if they fell on it
<jml> haha
<jml> freedom prevails.
<mwhudson> my word, you can still buy genera
<mwhudson> or pirate it, apparently: http://www.advogato.org/person/johnw/diary/12.html
 * mwhudson wallows in computing nostalgia
<jml> mwhudson: heh
<mwhudson> on http://en.wikipedia.org/wiki/HyperCard now
<jml> mwhudson: so, the thing that provoked this outburst of mine was thinking that I was saying "extract method foo from bar" twice: once in emacs and once in my bzr log
<mwhudson> jml: someone has been talking about this sort of thing on the rope-dev mailing list recently i think
<jml> mwhudson: glyph mentions this sort of thing from time to time.
<jml> oh wow. rope isn't brm.
<mwhudson> but he's not been being very clear and i haven't put the effort in to really understand what he's on about
<jml> *nod*
<mwhudson> yeah, rope looks a little interesting
<mwhudson> but, sigh, time
<bob2> wonder what "Mercurial, GIT and SVN (pysvn library) support in refactorings" means
<mwhudson> also i entirely failed to get ropemacs to work at all last time i used it
<kiorky> jelmer_: for the auth problem, somehow some branch.conf werent wearing the good url, fixing it fixes auth cache.
<kiorky> jelmer_: can we use svn urls and rely on svn cache, without having to put url with creds inside ?
<kiorky> jelmer_: i mean urls in the branch.conf
<poolie> night
<Peng_> Good night.
<colbrac> Changing an unlocked branch through bzrlib doesn't set a lock right? (for example branch.set_push_location(location)). I wonder how bzr-gtk should behave regarding setting and releasing locks on branches. I assume you only read_lock when it takes a little while to read out all the stuff you need and want a consistent set and set a write_lock if you want change stuff that takes a little while, while changing small bits like the mentioned set_defa
<colbrac> ult_location() don't need a lock?
<colbrac> * the mentioned set_push_location()
<Peng_> Bazaar takes out a write lock for a moment when it renames a modified pack-names into place. It's the right thing to do.
<colbrac> but fully handled by bzrlib.. I guess bzr-gtk has to be checked that in all cases a lock is set it is released asap.
 * Peng_ shrugs.
<Peng_> I think many operations take out locks themselves and some require you to do it, but I don't know.
<Pieter> Does Bazaar have something like Git's merge diff view?
<Jc2k> what is special about gits merge diff view o_O
<Jc2k> i've never seen it
<Pieter> it shouws two columns of ++'s
<Pieter> as with http://ss.frim.nl/==814 for example
<Jc2k> no idea personally
<Jc2k> is that a gitk feature, or a git feature?
<Jc2k> (can i do it in a shell)
<Pieter> git feature
<Pieter> gitk just adds some colors
<james_w> is that the same as "git diff --cc" ?
<Pieter> more like -c, I think
<Pieter> but it's the same as "git show <merge>"
<james_w> I don't think we have that, would you care to file a bug?
<james_w> I think it would be good to have for those that want it.
<Pieter> sure
<james_w> and if you can explain the use case, rather than just saying that we should clone the git feature that would be appreciated.
<Pieter> igc: your merge seems fine, and git-bzr still works as first :)
<igc> Pieter: ok, thanks for the test
<mwhudson> there is merge --preview, is that anything like the git feature?
<Pieter> I don't know.. can I use it on an existing merge?
<james_w> mwhudson: I don't think so.
<mwhudson> ok
<james_w> I think the git feature allows you to attribute changes to each side of the merge.
<igc> night all
<james_w> night igc
<Pieter> james_w: #250783
<james_w> thanks
<mark1> is anyone familiar enough with http://research.operationaldynamics.com/blogs/andrew/software/version-control/bzr-orthogonal-patches.html to answer a couple of questions related to it?
<Odd_Bloke> Moin.
<Odd_Bloke> markh: Possibly.  What are the questions? :)
<markh> the article mentioned keeping the revision history for the underlying changes as a motivation - but once you get to the end of his article (ie, after the final commit), a "bzr log --long" only shows a single revision for the merge - not the smaller revisions that you merged from the initial tree.
<markh> so the question is "what am I missing?" :)
<markh> so the "bundle" and everything else described works as advertised - but the point about the revision history isn't mentioned after the introduction
<markh> actually, I think I know...
<markh> I did "bzr merge ..\orig_branch\filename.py"
<markh> I imagine I needed to do lots of individual "merge -r ..." commands to get what I was after
<markh> manually extract them from the log I guess...
<Odd_Bloke> So I'm not really familiar enough with the article to help after all.  But you probably do want several 'merge -r's rather than a 'merge <filename>'.
<jelmer> kiorky: bzr-svn already uses the svn cache but it doesn't write to it
<markh> actually, it appears I'm missing the point :)  The conclusion says "Contributors meanwhile can create all the private revisions they ever wanted, and donât have to forecast which are going to be publicly visible and which arenât. So they can leave off worrying about a proper commit messages, etc, until they actually go to create and submit an orthogonal patch."
<markh> ok, I see where I got confused now :)  The person putting the patch together makes the commits, then sends them upstream - but its still only those explicitly committed in the patch creation process that are included, not all the original checkins that went towards it.
<Peng_> (Off-topic) This is odd. markh's second-to-last line wraps to three lines, and on the second one, a bit of the blank space just shows whatever was last on the screen. Another blank spot doesn't.
<jamesh> I generally try to keep my branches focused so I don't have to try and reverse engineer a single branch into feature branches
<jamesh> if they are orthogonal, then I can usually work on them independently.  If they are not orthogonal, then the loom plugin can help.
<LarstiQ> oh hey, loom, I forgot that as a solution.
<markh> yeah, but often working towards one feature means editing 4 files - which logically break down as 2 patches for review
<markh> then you have 1 tree, with 4 files with mixed up checkins.  Its seems very hard to create a bundle from just 2 of those files for review
<jamesh> if you do have a single branch and the changes you want to separate are related the loom plugin can still be useful
<markh> a patch is obviously fine, but a bundle seems hard
<markh> yeah - I'm not familiar with loom yet :(
<jamesh> start with two threads: the upstream trunk and your combined branch
<jamesh> create a thread in between them for the first change, moving the relevant work down from the top thread
<jamesh> then merge up again (which should be a null merge due to the changes already being present)
<jamesh> repeat until you're finished and discard the top thread
<markh> thanks for the tip!  I'll have a read up on it...
<Odd_Bloke> markh: Shelve from bzrtools would also allow you to do something like this (shelve one reviewable set of changes, commit, unshelve, commit).
<markh> Odd_Bloke: thanks, but I think that might be slightly different - each of the files had already been locally committed many times.  loom sounds like it might be closer (not that I've looked yet...)
<markh> shelve is closer to mercurials "queues" iirc?
<Odd_Bloke> I'm not sure, but it does sound like looms would work better for you. :)
<LarstiQ> markh: from my understanding, you would do one merge -r range for each range you want to include in the logical patch
<Peng_> Shelves aren't the same thing as mq.
<markh> LarstiQ: hi!  and commit each one?
<markh> bugger :)
<Peng_> Shelve is just for letting you temporarily remove changes from the working tree, and then put them back.
<LarstiQ> markh: you could do that if you wanted that granularity, or just commit one thing if that is ok to you
<Peng_> You could probably use it as a really poor man's mq, but not very well.
<Peng_> (Since you can have multiple different shelves.)
<bob2> what are queues more like then?  looms? branches?
<markh> when I initially read the article, I thought it would bring across each of the initial commits, with their original message.  I now (think I!) understand it only brings across the explicit commits you make in that "cherry-pick" branch.
<LarstiQ> markh: say you want to create a bundle to just review a cog change, and have relevant changes in revisions 1, 2, 4, 6 and 7.
<LarstiQ> markh: correct.
<LarstiQ> markh: well, content changes even, it doesn't bring across revisions.
<markh> I guess I meant "and commit messages" :)
<LarstiQ> markh: untill someone makes it so that cherry picks get recorded fully.
<markh> I was talking with you about this exact issue at eurocon.  So IIUC, loom is the only reasonable way to magically create a bundle that did include both changes and checkin messages?
<LarstiQ> markh: (continueing my example) you would then 'bzr merge -r 1..2; bzr merge --force -r4; bzr merge --force -r6..7; bzr commit' Assuming I'm not off by one, and you want to create one revision. (Depends on how big the changes are I guess)
<LarstiQ> markh: ah, if you want to recreate the revisions more or less exactly, I would do 'foreach rev: do bzr merge -rrev; bzr ci -m `bzr log -rrev path/to/orig`; done'
<LarstiQ> in my current knowledge, for that workflow
<LarstiQ> looms might be better
<LarstiQ> markh: not sure if the foreach plugin would help there
<markh> would that include the original author of the patch?
<LarstiQ> markh: no, it would take as committer whatever is set for the one doing the new commits.
<LarstiQ> could be done too of course
<markh> I see a good use case for the bzr-orthogonal-patches.html, but just checking loom is probably the only good solution if I want the "full history"?
<LarstiQ> but I have to get back to my exercises with ambigous notation :/
<markh> no probs - thanks!
<LarstiQ> markh: the "real" solution is making cherry picks record the fact.
<markh> (in my case, for my recent patch, bzr-orthogonal-patches.html is actually a better answer - I'm just curious)
<LarstiQ> imo.
<markh> LarstiQ: right - just making sure I understand things as they are now - its all getting clearer each day :)
<LarstiQ> markh: I'm not well versed enough in looms to answer that unfortunately.
<LarstiQ> markh: The for loop with the ci -m `bzr log -r` trick is what I practically do right now if I find myself in that situation.
<LarstiQ> markh: did I tell you I had gotten python-nautilus running?
<LarstiQ> pygi: you were still going to tell me about Novell's plans on nautilus integration btw.
<markh> no!  I also found myself cringing at some windows specifics I forgot about when taling to you :(
<markh> but I've a really nice tbzr build, with the very nice qt4 based qbzr, and largely working!  But I must go and re-acquaint myself why my girlfriend for a while...
<LarstiQ> markh: I really really have to kick myself back to studying now or I'll avoid studying all day long, but I will check back on tortoise status later today, and try to publish something that works with nautilus.
<LarstiQ> markh: oooh
<LarstiQ> markh: have fun, and I look forward to checking out the qbzr stuff :)
<pygi> LarstiQ, you must be joking :)
<Pilky> Looking at qbzr has really made me want to start working on BazaarX again
<Pilky> I just need to find the time from somewhere
<rjek> Hi.
<rjek> Is it a bug or an unwarrented expectation of mine that using setup.py to install bzr into ~/opt/bzr-1.5/ yeilds something that won't work because it can't find bzrlib?
<rjek> (well, it does find bzrlib, just the ancient one that's installed system-wide)
<rjek> Additionally, is it the case that the current stable bzr-svn requires a non-stable release of bzr to run?
<rjek> I ask this question due to receiving this error: bzr: ERROR: Installed bzr version 1.5 is too old to be used with bzr-svn, at least 1.6 required
<rjek> (I did a lightweight checkout of http://people.samba.org/bzr/jelmer/bzr-svn/stable/ and bzr was obtained from the release tarball)
<Odd_Bloke> rjek: Try prefixing the bzr command with 'PYTHONPATH=~/opt/bzr-1.5/lib/python:$PYTHONPATH'
<rjek> Odd_Bloke: Sure, I've been informed about that solution.  But as a non-Pyton user who just wants to use bzr (with no regard of what it's written in) I was a bit surprised that it didn't "just work".
<Odd_Bloke> rjek: Well, if you installed anything in a non-standard location, expecting it to 'just work' is optimistic.
<rjek> Not when there's an install script!
<rjek> If all it was doing is just copying files to a directory, what's wrong with the common makefile with an install target?
<jelmer> rjek: you need a released version of bzr-svn for bzr 1.5
<rjek> I was kinda expecting a tool called "setup" to set it up for use, rather than just copying it somewhere.
<Odd_Bloke> rjek: But you don't want a tool called 'setup' to monkey around with your shell environment, because it will almost certainly do something wrong.
<rjek> Odd_Bloke: Quite.  However, rewriting a bit of the (trivial) bzr launcher script it puts in bin/ seems like an ideal approach.
<rjek> If the setup tool isn't actually going to set it up then, perhaps changing its name to something that doesn't suggest that it will would be wise, to avoid confusion for people like me who have no interest in Python?
<radix> rjek: wouldn't you expect a command that involved the word "install" (instead of, say, "copy") to actually make it usable in the installed environment?
<rjek> jelmer: Where can I obtain this from?  The plugins page on bazaar-vcs.org doesn't mention anything other than the stable branch.
<radix> (i.e., make install)
<rjek> Yes.  And in general, they do.
<jelmer> rjek: It's on the bzr-svn wiki page, http://bazaar-vcs.org/bzr-svn
<radix> not if you specify a prefix like ~/opt/bzr-1.5
<rjek> jelmer: That page doesn't exist.
<rjek> radix: `./configure --prefix=~/opt/foo && make install` almost always works.
<radix> rjek: maybe you use a different version of 'make' than I do, but it certainly won't set up my PATH and LD_LIBRARY_PATH on my system
<jelmer> rjek: sorry, http://bazaar-vcs.org/BzrSvn
<rjek> I don't understand why "./setup.py install --home ~/opt/foo" should be any different.
<rjek> radix: I've not suggested that it should.
<rjek> jelmer: Thanks,
<radix> It's _not_ any different from that. you're complaining that it doesn't do _more_ than the usual 'configure; make' dance because it's named differently.
<radix> at least that's my understanding of what you've been saying.
<rjek> Erm.
<rjek> I'm saying `./configure --prefix=~/opt/foo && make install` yeilds something that just works, and `./setup.py install --home ~/opt/foo` does not.
<radix> ok, I don't get it. how does that work?
<LarstiQ> radix: rjek's point is rewriting the bzr script at install time.
<radix> LarstiQ: yes, I understand that feature request
<radix> but "./configure; make install" never made that just work for software I've installed
<jelmer> rjek: "./configure --prefix=~/opt/foo && make install" doesn't work either in a lot of cases
<Kinnison> For pure apps it would.
<Kinnison> for apps which contains libraries, it may not
<radix> heh, "pure". yes, right
<Kinnison> depending on what the app does wrt. building hard paths into its link
<rjek> I can't think of an application I've installed that way that didn't work.
<radix> so yes, if it's only a binary, and you absolutely specify the binary, it'll run the app
<radix> rjek: any app which exposes most of its functionality through a library which the main binary links with
<radix> I've dealt with some recently, actually
<rjek> I don't give a toss if it exposes a library - I'm wanting to install bzr to use bzr :)
 * Odd_Bloke notes that "echo PYTHONPATH=$HOME/opt/foo/lib/python:$PYTHONPATH >> ~/.bashrc" would have been much quicker than this conversation. :)
<radix> rjek: yes, I understand that, and bzr should be wonderfully awesome and easy to use
<Kinnison> Odd_Bloke: Not for someone who didn't know how.
<rjek> radix: Your sarcasm suggests that it's not important for bzr to be easy to use.
 * Kinnison thinks that having the setup.py somehow modify the incoming bzr driver script to stuff the right pythonpath on the front wouldn't be *too* hard
<radix> I also don't give a toss when I'm using an application that has 'configure; make' and it doesn't work, which actually happens
 * rjek sighs.
<radix> :(
 * Kinnison looks on, distinctly unimpressed
<Kinnison> never mind, eh?
<LarstiQ> Well, we could have handled that better.
<radix> yeah, sorry.
<radix> I'm trying to make amends.
<LarstiQ> radix: thanks.
<Kinnison> Interestingly we already put this effort in for Windows
<Kinnison> we create a customised bzr.bat
<radix> ok, I think I've proven to him that I'm way more of an ass than anyone else here
<Kinnison> :-)
<radix> and, now I'm filing a bug about the problem
<Odd_Bloke> < ubottu> Launchpad bug 250789 in bzr "radix is an ass" [Undecided, New]
<Odd_Bloke> ^_^
<ubottu> Launchpad bug 250789 in bbs2ch "æ§ä»æ§ã®å®æ°å¤ãåç§ãã¦ãã" [Undecided,New] https://launchpad.net/bugs/250789
<radix> that's "radix is an ass" in Japanese
<radix> "radikusu issu an assu"
<radix> bug #250826 (or does the bot automatically find new bugs?)
<ubottu> Launchpad bug 250826 in bzr "setup.py should rewrite bin script when installed to a non-standard location so it can be run without specifying PYTHONPATH" [Undecided,New] https://launchpad.net/bugs/250826
<Peng_> Yay, I restarted Loggerhead with only 0.994 seconds of downtime. :)
<Stavros_> hello
<Stavros_> i tried to install bzr in freebsd from sources but the command bzr is not found
<Stavros_> any idea what might be wrong?
<Peng_> The 'bzr' script isn't in your PATH?
<Stavros_> this is possible
<Stavros_> wouldn't the installer do that?
<Peng_> You did a "setup.py install"? Its output should say where it went.
<Stavros_> ah
<Stavros_> hmm, it shows site-packages
<Peng_> Well, it went in the same directory as "python" is in, unless you told it not to.
<Stavros_> ah
<Peng_> Stavros_: That's bzrlib, not the "bzr" script.
<Stavros_> indeed, i'm looking for the script
<Stavros_> it turns out that it works in bash
<Stavros_> thanks
 * Kinnison attaches a possible fix bundle to https://bugs.launchpad.net/bzr/+bug/250826
<ubottu> Launchpad bug 250826 in bzr "setup.py should rewrite bin script when installed to a non-standard location so it can be run without specifying PYTHONPATH" [Undecided,New]
 * Kinnison goes back to work now
<jam> mwhudson: ping
<jam> rjek, radix, Odd_Bloke: Of course, even easier is to just do
<jam> py setup.py build_ext -i
<jam> ln -s ~/bin/bzr $PWD/bzr
<jam> I think I have the order backwards there
<jam> but you get my idea
<jam> :)
<radix> ah, because it does the magic when it knows its in a development environment?
<jam> radix: no because python always imports from the local directory of the script
<jam> arguably, *python* does the magic
<radix> yeah, but the bzr script isn't in the same place that bzrlib is, right?
<radix> or maybe it is
<radix> I thought it was in a 'bin' or 'scripts' directory or something
<radix> oh, there it is
<Kinnison> jam: But that's not the instructions we specify in INSTALL
 * Kinnison has punted a patch to the bug
<Kinnison> it's not ideal (lacks NEWS etc) but it does the job I think
<jam> radix: no, some of the other canonical projects (like PQM) use a 'bin', but bzr does not
<jam> Kinnison: yeah, I commented on it already
<radix> Kinnison: thanks
<Kinnison> jam: I wonder where the mail from LP is then :-(
 * Kinnison pokes dejectedly at his maildir
<jam> Kinnison: lp delays emails for a few minutes
<Kinnison> oh
<jam> because sometimes you make multiple changes
<jam> and it wants to batch them together
<Kinnison> fair enough
 * Kinnison has responded to your comment anyway
<slangasek> supposing I have created a bzr repo using bzr cvsps-import
<slangasek> and I now want to push the lot to a public server
<slangasek> what's the best way to do that?
<slangasek> (noting also that this is a live CVS repo, so I don't intend this to be a one-time import; so I need to stow it in such a way that I don't lose any other branches that I add over time)
<LarstiQ> slangasek: does cvsps-import create multiple branches?
<slangasek> yes
 * pickscrape is migrating his IT department from svk to bzr *tonight*
 * pickscrape stresses
<kiorky> uhm, is that possible to pull changes from smoewhere but without updating the working copy yet, like with hg pull
<LarstiQ> slangasek: the repo-push plugin?
<slangasek> LarstiQ: well, I think my larger concern is not "how do I push it?", but "how should I lay things out so that the cvsps imported branches co-exist with my bzr-only branches?"
<Pilky> do people know that the bzr website seems to be messed up?
<jam> kiorky: generally no, though if you have a shared repository you can
<jam> cd ..
<jam> bzr branch OTHER_PERSONS_STUFF
<jam> and then you'll have it locally but not merged
<Pilky> as it seems to be showing a bunch of directories for users rather than the site itself
<jam> Pilky: yeah, the wiki seems to be down
<jam> I'll ask
<LarstiQ> Pilky: hmm, non frontpage still seems to work
<pickscrape> Down for me
<Pilky> ah, back up now
<pickscrape> Yep
<jam> yeah, back up now
<LarstiQ> slangasek: I have no cvsps experience, how would they not co-exist?
<dash> hi. anybody know of a guide for getting started with bzrlib? i'm looking at the api docs now, just wondering if there's some description of good starting points for common tasks
<pickscrape> dash: this has become my bible: http://bazaar-vcs.org/Integrating_with_Bazaar
<dash> thanks!
<dash> that looks exactly like what I want. :)
<pickscrape> dash: along with this: http://starship.python.net/crew/mwh/bzrlibapi/moduleIndex.html
<pygi> pickscrape, aha, I found a bug on the page!
 * pygi hides
<pickscrape> :)
<pickscrape> I think I was told it was a bit out of date when I was first pointed at it
<pickscrape> What bug did you find?
<pickscrape> I wish it explained more (i.e. something) about locking.
<slangasek> LarstiQ: cvsps-import creates a "Bazaar-NG meta directory, format 1".  If I add my own branches inside of that tree, will future cvsps-import runs clobber them?  And if I don't, will I have inferior performance?
<slangasek> if nothing else, I can take the cvsps-imports and stick them in an "upstream" tree on my server, and build a "debian" tree next to it
<LarstiQ> pickscrape: individual functions will try to take out a lock when they need to, but there are cases where it is better to take out a lock yourself.
<is_null> hello everybody, is it possible to track a remote subversion repository in a subfolder, and branch it? I'd like to track the framework used in an application and be able to maintain a branch of it
<pygi> pickscrape, a missing ")" :P
<LarstiQ> slangasek: the meta directory doesn't tell me much, but assuming it is a repository you can add your own branches under that, I'm fairly confident to say cvsps-import will not clobber even if I don't know it.
<slangasek> LarstiQ: ok, guess I'll test :)
<LarstiQ> slangasek: but you could add your own branches under repo/vorlon for example, I doubt it will touch that :)
<LarstiQ> is_null: part of what you want to do sounds like bzr-svn
<pickscrape> LarstiQ: yes, I was aware of commands taking the lock themselves. However, I'm not sure sure about what when it is better to do the locking yourself.
<slangasek> LarstiQ: ok, confirmed that it doesn't clobber it, thanks
<is_null> LarstiQ, i've read this: http://bazaar-vcs.org/BzrForeignBranches/Subversion but it doesn't say about tracking *in* a subfolder of the bzr repo
<slangasek> LarstiQ: now, the question is whether that's the layout I /want/, since everything imported by cvsps-import has rather ugly names, and I'm thinking it might be nice to have that off in its own namespace :)
<is_null> now i've read the faq as well ;)
<LarstiQ> slangasek: right, that might be done by cvsps, no clue :/
<slangasek> ?
<LarstiQ> is_null: well, you would convert the svn branch into a bzr one first, and then track a bzr branch normally (if that worked, sigh)
<LarstiQ> slangasek: bzr cvsps-import --layout-as-i-want
<slangasek> LarstiQ: er, heh
<LarstiQ> slangasek: you have by far more cvsps knowledge than I by now though, so :)
<slangasek> LarstiQ: I'm pretty much stuck with the CVS tag and branch names if I want to be able to use it, so I would argue that the ugliness is inherent :)
<is_null> LarstiQ, i mean, can bzr track the svn branch in a sub-directory of the bzr repo?
<is_null> like git-submodule (which does not support svn)
<slangasek> is_null: 'bzr join'
<slangasek> is_null: I think that's what you're after
<slangasek> it's good and evil :)
<LarstiQ> is_null: in bzr terms, a repository and a branch are different things.
<LarstiQ> is_null: I don't know what git-submodule does.
<LarstiQ> is_null: but tracking a svn branch by having a bzr branch in a bzr repo is no problem at all, I just think you are using different terminology.
<is_null> LarstiQ, bzr repo: /myapp, svn repo: svn://foo, i'd like to track svn://foo in /myapp/framework
<LarstiQ> is_null: is /myapp something you created with 'bzr init-repo'?
<is_null> LarstiQ, yes
<LarstiQ> is_null: ok, no problem then.
<is_null> nice, thanks
<LarstiQ> well, at least for the 'tracking in a subdir' part.
<LarstiQ> is_null: it could be svn://foo does really funky stuff and bzr-svn will be need to taught that
<LarstiQ> is_null: but give bzr-svn a try with svn://foo and let us know how it went
<is_null> what package is bzr-svn part of?
<LarstiQ> is_null: bzr-svn
<LarstiQ> is_null: http://bazaar-vcs.org/BzrForeignBranches/Subversion
<is_null> thanks again!
<bartt5> When using bzr shelve in shell inside Emacs, the carriage-return isn't automatically added when pressing y, n. q, etc
<bartt5> Does anyone now how to instruct Emacs to add a carriage-return in this case?
<is_null> bzr-svn is not up to date with installed bzr version 1.6b3.
<is_null> There should be a newer version of bzr-svn available.
<is_null> bzr: ERROR: exceptions.ImportError: cannot import name make_file_knit
<is_null> with bzr and bzr-svn from the gentoo overlay
<LarstiQ> is_null: I think I saw someone mention before that there was something wrong with the gentoo overlay
<LarstiQ> is_null: gentoo aside, I'd either match up bzr 1.5 and bzr-svn 0.4.10 (from memory, the page lists which version match), or go with bzr.dev and lp:bzr-svn/0.4
<Peng_> LarstiQ: You're correct.
<Peng_> (with those versions)
<is_null> ok! thanks
<is_null> same problem when trying to run tests: http://nopaste.com/p/a8I2lKBYG
<is_null> with versions dev-util/bzr-1.5, dev-util/bzr-svn-0.4.10, dev-util/bzr-rebase-0.2
<beuno> hrm, anyone know why I would be getting this: http://paste.ubuntu.com/29354/
<LarstiQ> is_null: with bzr 1.5 and bzr-svn 0.4.10 you get a message complaining something doesn't match with _1.6b3_ ?
<is_null> LarstiQ: http://nopaste.com/p/aghDKt9Mg
<beuno> I moved around branches inside my shared repo, but I don't see why that would make it explode
<LarstiQ> is_null: that is very weird. bzr-svn 0.4.10 has cache.py with CacheTable right there
<LarstiQ> is_null: can you confirm /usr/lib64/python2.5/site-packages/bzrlib/plugins/svn/cache.py exists?
<is_null> 07bd547b639ef507eb603dc85a342a04  /usr/lib64/python2.5/site-packages/bzrlib/plugins/svn/cache.py
<LarstiQ> is_null: that is correct.
<is_null> anything else i can do?
<LarstiQ> is_null: you could run that with BZR_PDB=1 set, only helpful if you know python/pdb
<LarstiQ> is_null: ah, hmm
<LarstiQ> is_null: please do do that, and then type in 'import cache' 'p cache.__path__'
<LarstiQ> is_null: I think I know what the problem is, namely there being a 'cache' module/package on sys.path that bzr-svn isn't expecting there. To be more precise, it is only expecting to be run from a bzr source tree I think.
<is_null> LarstiQ, true
<is_null> /usr/lib64/portage/pym/cache
<LarstiQ> is_null: right
<is_null> seems like a minor bug
<LarstiQ> is_null: is this something that the gentoo packaging runs automatically?
<is_null> LarstiQ, "this"?
<LarstiQ> is_null: bzr-1.5 selftest svn
<LarstiQ> is_null: or did you run it seperately yourself?
<is_null> i do it, but the ebuild can do it as well, i'm not re-installing it each time
<is_null> change from cache to: from bzrlib.plugins.svn.cache import CacheTable now a new problem: http://nopaste.com/p/aaUuwowFob
<is_null> the same problem
<LarstiQ> right, I expect more problems of the same sort
<LarstiQ> is_null: so, two things.
<LarstiQ> is_null: if you are interested in the results of running the tests, I suggest for that to cd to the bzr 1.5 sourcedir, and run ./bzr selftest svn
<LarstiQ> is_null: for the larger problem, I think a bug filed against bzr-svn saying that its importing style is fragile in the face of same named modules on the path is fair.
<LarstiQ> is_null: if you want to attach a patch to that bug, I don't think jelmer will have a problem with that ;)
 * LarstiQ is called to dinner.
<LarstiQ> is_null: I'll see how far you are when I get back.
<is_null> LarstiQ, thanks a lot for you support!
<is_null> now i have https://bugs.launchpad.net/bugs/246683 :)
<ubottu> Launchpad bug 246683 in bzr-svn "Assertion `*path != '/'' failed" [Undecided,Fix committed]
<slangasek> hum, anyone here know bzr-email?
<slangasek> more to the point, does it actually work for anyone?
<jelmer> is_null: you need a newer version of bzr-svn
<jelmer> slangasek: yep
<jelmer> slangasek: what's not working?
<slangasek>   File "/usr/lib/python2.5/site-packages/bzrlib/plugins/email/smtp_connection.py", line 213, in send_text_and_attachment_email
<slangasek> jelmer: that
<jelmer> LarstiQ: the imports have already been fixed in bzr-svn's branch
<slangasek>     assert isinstance(attachment_text, str)
<slangasek> AssertionError
<jelmer> slangasek: can't remember seeing that before; any chance you can file a bug?
<slangasek> yep
<james_w> slangasek: running under BZR_PDB=1 and getting type(attachment_text) would be useful
<james_w> my guess is unicode
<LarstiQ> jelmer: hmm, but there is no bzr-svn with those fixes compatible with bzr 1.5 is there?
<slangasek> jelmer, james_w: bug #250901 filed; I'll try with BZR_PDB=1 on my next commit
<ubottu> Launchpad bug 250901 in bzr-email "traceback on all commits" [Undecided,New] https://launchpad.net/bugs/250901
<jelmer> LarstiQ: only the one in Debian has them
<jelmer> slangasek: thanks
<slangasek> (Pdb) type(attachment_text)
<slangasek> <type 'NoneType'>
<slangasek> james_w: ^^
<slangasek> anything else I should check before dropping out of the debugger?
<is_null> jelmer, you ad
<is_null> jelmer, you advice to use which version of svn, bzr and bzr-svn please?
<jam> beuno: check your plugins for bug #250514
<ubottu> Launchpad bug 250514 in bzr-email "bzr-email fails to send via a gmail tls smtp connection (needs ehlo cmd)" [Undecided,New] https://launchpad.net/bugs/250514
<jam> beuno: sorry, bug #250893
<jam> :)
<ubottu> Launchpad bug 250893 in bzr "Traceback when moving branches in a shared repo" [High,Incomplete] https://launchpad.net/bugs/250893
<jelmer> is_null: in general, I would recommend bzr 1.5 and bzr-svn 0.4.10
<jam> beuno: at least, auditing the code here, everything looks like it should be fine
<beuno> jam, I'll try with --no-plugins
<jelmer> is_null: however since you're hitting those two bugs I would recommend bzr.dev and bzr-svn from the 0.4 branch in your case
<beuno> jam, same with --no-plugins
<is_null> jelmer, with svn 1.5.0?
<jam> beuno: can you look at your /...pythonpath/site-packages/bzrlib/bundle/__init__.py file
<jam> and see if read_mergeable_from_url takes possible_transports?
<jam> It certainly does in bzr.dev
<jelmer> slangasek: looks like this is a bug if no diff should be sent
<jelmer> e.g. if difflimit = 0
<slangasek> jelmer: well, I /want/ a diff to be sent; I thought difflimit = 0 meant unlimited
<slangasek> :)
<jam> beuno: my best guess after plugins is that the install packaging isn't properly overriding the bzrlib/bundle/ sub-package
<jam> beuno: another thing to check is the timestamps on the __init__.py file and the __init__.pyc files
<jam> if the .pyc is newer, it won't get rebuilt
<slangasek> jelmer: btw, does anyone have a post-commit hook that will tag bugs 'pending' in the Debian BTS? :-)
<beuno> jam,
<beuno> lrwxrwxrwx 1 root root    45 2008-07-22 02:17 __init__.py -> /usr/share/pyshared/bzrlib/bundle/__init__.py
<beuno> -rw-r--r-- 1 root root  2872 2008-07-22 02:17 __init__.pyc
<jam> beuno: can you check: /usr/share/pyshared/bzrlib/bundle/__init__.py
<jelmer> slangasek: not yet afaik, but I agree it would be nice to have such a thing :-)
<jam> beuno: though it certainly looks like it is *today* :)
<slangasek> damn, I just volunteered myself, didn't I
<jam> beuno: and the contents of __init__.py ? does it have possible_transports?
<beuno> jam, hm, no
<jam> beuno: .... :(
<jam> beuno: so, do you want to try uninstalling and re-installing?
<beuno> and, surprise surprise, it has an older timestamp
<jam> obviously something weird
<beuno> I just did: setup.py install   in bzr.dev
<jam> beuno: also, how do you have bzr 1.6b4 ?
<jelmer> slangasek: :-)
<beuno> shouldn't that overwrite everything?
<jam> ah, but did you uninstal the system package first?
<jam> beuno: I can't say how smart the python installer is
<slangasek> jelmer: do you think this should be a feature of bzr-email, or a new post-commit hook?
<jam> as debs verses setup.py install
<beuno> jam, ah, I didn't
<slangasek> (I guess I could just wrap the 'bts' command...)
<jam> beuno: kind of like the old case of "./configure; make; make install' versus "apt-get install"
<jam> they don't *talk* to eachother
<jam> beuno: we can certainly update the bug to say that "setup.py install" doesn't overwrite the existing install cleanly.
<beuno> jam, right, I can't remove the package because it will remove:
<beuno> launchpad-dependencies
<beuno> launchpad-developer-dependencies
<jam> though 'bzr' may punt and point fingers at disutils
<beuno> which I sort of need
<jam> beuno: isn't there a remove-force but don't remove dependencies?
<jelmer> slangasek: I would say it should be a feature of a new post-commit hook, perhaps part of bzr-builddeb (though James is perhaps a better person to decide that)
<jam> I don't know apt very well
<Odd_Bloke> jam: 1.6b4 is what bzr.dev is currently marked as.
<slangasek> james_w: your thoughts?
<jam> Odd_Bloke: no, I know that, I thought beuno installed from a package, and we've never released a b4 package
<beuno> jam, I can't seem to get it to go away on it's own. It insists on taking others with it
<Odd_Bloke> jam: Ah, OK.  I only glanced over the scrollback. :)
<jam> beuno: well, I'm at the limit of my understanding of apt-get without a command line (currently logged into win32)
<jam> LarstiQ, jelmer: ^^ do you have an idea how to apt-get remove without taking all dependencies with it?
<jam> Odd_Bloke: ^^
 * Odd_Bloke doesn't know.
<jelmer> jam: aptitude unmarkauto <package> I think
<beuno> jam, that doesn't seem to do anything for me
<beuno> uhm, jelmer
<jelmer> beuno: if you run that on the dependencies and then deinstall the package itself
<jelmer> it shouldn't take the dependencies with it
<beuno> jelmer, ah, thanks
<james_w> slangasek: I agree that it appears to be a difflimit = 0 bug. I also think that there should be a special value for no limit, perhaps 0 or -1
<james_w> slangasek: or did you mean on tagging things pending?
<slangasek> james_w: ah, I'd moved on, I was asking about tagging things pending :)
<james_w> I think something separate to bzr-email would be better. Using bts or tagpending will probably reduce the work.
<slangasek> right
<is_null> i don't understand this error when trying to checkout bzr-svn: http://nopaste.com/p/aFhoMZdbP
<LarstiQ> is_null: svn co?
<is_null> yes
<LarstiQ> is_null: on a bzr branch? :)
<is_null> my bad ... i got a little confused
<Odd_Bloke> doko: o/
<allee> email plugins problem:  with bzr push sftp://foo@bar/path/to/repo  and  a ~foo/.bazaar/locations.conf on host bar, neither the settings in [/path/to/repo] nor [sftp://foo@bar/path/to/rep/] are used here :(    Is it my fault?  Or are plugins on the repo server ignored?
<jelmer> allee: the email plugin only triggers on commit, not on push
<slangasek> doh, I think that was about to be my next question
<slangasek> jelmer: is this a limitation of the post-commit hook logic?
<jelmer> slangasek: it's an implementation choice in the email plugin
<jelmer> slangasek: it only triggers on commit because if you also trigger on push that means you could be sending the notification email more than once (once on commit, once on every push)
<jelmer> It would be nice to allow the user to decide when to trigger the notification email though
<slangasek> jelmer: but in theory, there might be different audiences who would be interested in receiving mail about it at different points...
<allee> jelmer: uhm, not good. I prefer not to use a leight-weight checkout, but only stuff that pushed to the 'authoritive central' repo matter.   IMHO push IS A commit-in-one-go ;)    Is there already a tool that handles push e-mail too?
<slangasek> i.e., I really want to generate email when I've pushed to a repo on alioth, not just when I've committed locally
<jelmer> slangasek: yeah, I agree it would be nice to support email on push as well
<slangasek> wishlist against bzr-email?
<jelmer> slangasek: yeah
<allee> ah clarification from my side:  I don't need a push configured locally, but once on the repo server so everyone push/commit to the central repo triggers it.
<allee> slangasek: can you post the bug/with id here?   I would like to subscribe
<slangasek> allee: well, the latter relies on your server side having some smarts, because the only way to configure this right now is via ~/.bazaar
<slangasek> allee: yes, I'll post the bug # here
<allee> oh, I naively assume bzr sftp:// does it like rsync: start a remote bzr and talk to it
<Odd_Bloke> allee: bzr+ssh:// does do that.
<allee>  Odd_Bloke: bzr+ssh (e-mail) triggers also (e-mail) plugins this way?
 * allee tries ...
 * allee failed
<ppires> hi there :-)
<Odd_Bloke> allee: Sorry, I meant bzr+ssh starts a remote bzr, not that it does any of the email stuff.
<allee> Odd_Bloke: no problem.  It was worth a quick try ;)  Thx.
<ppires> allee: shouldn't that plug-in be installed in the remote bzr?
<ppires> i'm totally newb at this, but that's my logic. if you call remote bzr, then commits are made in the remote bzr instance, and so triggering any plug-ins there and not on your machine. perhaps i'm wrong
<Odd_Bloke> ppires: The issue here is that the email message is wanted on push to branches on that machine, not on commits to branches on that machine.
<allee> ppires: yes, I did.  but e-mail plugin is only called on a) commit and b) on the host bzr does run
<allee> .. not the remote repo server
<Odd_Bloke> allee: If you were bound to a remote branch using bzr+ssh, I would expect commits to trigger on the remote host.
<allee> Odd_Bloke: mhmm, I've to leave now.   I'll try your workaround tomorrow.  Thx again
<Odd_Bloke> allee: That would still be individual commits and not pushes though.
<ppires> Odd_Bloke: ic
<slangasek> allee: bug #250934
<ubottu> Launchpad bug 250934 in bzr-email "bzr-email should support email on push" [Undecided,New] https://launchpad.net/bugs/250934
<mwhudson> jam: hi
<allee> slangasek: thx
<jam> mwhudson: hi, just wondering if you had PQM rights to merge your earlier patch
<mwhudson> jam: no
<cjwatson> hi, I'm trying to sort out problems with lp:~ubuntu-core-dev/casper/trunk
<cjwatson> also mentioned in https://answers.launchpad.net/launchpad-bazaar/+question/39693
<cjwatson> trying to branch this locally says:
<cjwatson> $ bzr get casper test
<cjwatson> bzr: ERROR: Revision {Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--base-0} not present in "x_Matt_Zimmerman_<matt.zimmerman@canonical.com>_Sun_Mar_13_00:51:19_2005_1366.3".
<cjwatson> bzr reconcile crashes:
<cjwatson> Reconciling repository file:///home/cjwatson/src/ubuntu/casper/bzr/casper/
<cjwatson> bzr: ERROR: exceptions.KeyError: 'Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21'
<jam> mwhudson: I forgot to check, but isn't there an associated bug for that fix?
<jam> or was this a drive-by fix?
<cjwatson> lifeless tried to help me at the distro sprint, but we only really succeeded in making things worse
<cjwatson> so I'd appreciate expert help :)
<cjwatson> (not that lifeless isn't. er. I'll shut up now)
<mwhudson> jam: it was drive-by in fixing some other bug
<mwhudson> bug 250418 in fact
<ubottu> Launchpad bug 250418 in bzr "bzr_dir_for_branch_stacked_on_relative_url.clone('...', preserve_stacking=True) miscalculates stacked-on URL" [Undecided,New] https://launchpad.net/bugs/250418
<mwhudson> there's a fix for that one to review too :)
<jam> cjwatson: 'reconcile' complaining is a known issue, I would have thought "bzr branch" was already fixed in the last beta release
 * mwhudson goes to have breakfast
<cjwatson> jam: the branch has been a bit buggered for a long time, though
<cjwatson> it's worked fine for those of us who already have copies of it ...
<jam> cjwatson: well, when I look at it, I see nothing in the repository there
<jam> and the last revision shows up as "NULL"
<jam> http://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk/.bzr/branch/last-revision
<jam> cjwatson: is it supposed to be a hosted branch, or a mirrored branch?
<jam> cjwatson: ah, it looks like it might be a hosted branch, and the branch mirror script is borking on the missing mainline revision?
<jam> mwhudson, jml: Can you shed more light on what is going on?
<jam> cjwatson: so are you branching from "lp:casper" which actually means you are using bzr+ssh most of the time?
<cjwatson> jam: I branched from it approximately a zillion years ago
<cjwatson> I think at the time it was hosted on rookery
<cjwatson> right now, bzr info says: checkout of branch: bzr+ssh://bazaar.launchpad.net/%7Eubuntu-core-dev/casper/trunk/
<jam> cjwatson: well, my current comment is that it is the bazaar-launchpad guys and their custom mirroring stuff
<cjwatson> jam: mwhudson asked me to come here ...
<jam> I would guess that the bzr+ssh side is working okay
<jam> though "bzr reconcile" would still bork
<cjwatson> it should be a hosted branch, yes
<jam> and the mirror script is broken for fetching branches that have ghosts in their mainline
<jam> They might then chose to kick it back to us, because of some fetch api they are using that breaks for them.
<jam> but I'll let them debug that side of it.
<cjwatson> jam: 'bzr push' fails on the same branch, FWIW
<cjwatson> sftp://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk/ seems to work, at least for log
<cjwatson> ah, but branch still fails, meh
<cjwatson> I've put the branch at http://people.ubuntu.com/~cjwatson/tmp/casper/trunk/.bzr/ in case it's useful
<mwhudson> jam: ghosts on mainline sounds like a recently fixed bzr bug
<mwhudson> at least there was some problem with them recent
<mwhudson> ly
<mwhudson> maybe this will go away when we update bzr on the codehosting systems?
<jam> mwhudson: if wishes were fishes, we'd all eat a lot of fish
<jam> but yeah, maybe
<jam> reconcile still has a problem
<jam> and check probably does too
<muffinresearch> I writing something where I need to get the last rev for a specific file through the bzrlib api. Looking at the API I can see two ways to do it. Either subclass log.LogFormatter and stash revision.revno or to use log.find_touching_revisions. Am I missing a more direct approach?
<mwhudson> muffinresearch: yes
<mwhudson> though i forget what the best way is
<mwhudson> one way is to load an inventory and look at the InventoryFile for the file
<jam> muffinresearch: try this
<jam> First ,do you have a Branch or WorkingTree ?
<jam> but something like:
<muffinresearch> Can get either
<jam> wt, relpath = bzrib.workingtree.WorkingTree.open_contaning(path)
<jam> wt.lock_read()
<jam> file_id = wt.path2id(relpath)
<jam> ie = wt.inventory[file_id]
<jam> sorry scratch that
<jam> basis_tree = wt.basis_tree()
<jam> basis_tree.lock_read()
<jam> ie = basis_tree.inventory[file_id]
<jam> last_modified_revision = ie.revision
<jam> basis_tree.unlock()
<jam> wt.unlock()
<muffinresearch> yep that seems much more direct
<muffinresearch> thanks!
<jam> if you only have a branch, you would do something more like
<jam> rev_tree = branch.repository.revision_tree(branch.last_revision())
<jam> ie = rev_tree.inventory
<jam> etc
<jam> ie = rev_tree.inventory[file_id]
<muffinresearch> @jam: cheers for your help
<pickscrape> Are bzrlib's progress bars generically usable from within plugins?
<jam> pickscrape: "generically" I suppose
<jam> using
<jam> pb = bzrlib.ui.ui_factory.get_nested_progress_bar()
<jam> ...
<jam> pb.finished()
<pickscrape> jam: thanks, I'll look into it :)
<colbrac> jelmer: Which command can I use to test the tick addition?
<beuno> mwhudson, just finished fixing everything in your review, and replied to your email with comments
<mwhudson> beuno: excellent
<beuno> now, I've been poking at my evil fill_div function
<beuno> I've started and abandoned a few approaches
<Peng_> Ooh, what's going on now?
<beuno> do you have something specific in mind?
<beuno> Peng_, shhhh, it's secret    :)
<beuno> and it's like 7k diff, that's all I'm saying about it
<Peng_> Adding Mercurial support?!
 * Peng_ runs away.
<beuno> :p
<pickscrape> They're making a merge algorithm that *never* results in any conflicts
<jelmer> colbrac: I was using some experimental bzr-svn stuff, not sure what else uses it
<Peng_> pickscrape: It uploads your merge to MTurk?
<beuno> mwhudson, ^  on the fill_div bit
<mwhudson> beuno: it was just that the code in the function was a bit nonsensical
<mwhudson> beuno: on the phone now
<beuno> mwhudson, right. I kept running into problems with types, so it ended up looking like that.  I'm obviously missing something very simple.  No hurry though, waiting on the phone is always more annoying then waiting on irc  :p
<igc> morning
<Jc2k> evening
<beuno> afternoon
<emgent> night.
<pickscrape> evening
<Peng_> That about covers it.
 * fullermd has a nice diurnal anamoly.
<pickscrape> That sounds painful. You should get it seen to
<poolie> hi
<jelmer> colbrac, I'm upgrading the format of the trunk bzr-gtk branch atm, please don't push anything; it may be discarded
<jelmer> 'morning poolie
<colbrac> ok
<colbrac> Actually I'm puzzled atm why the 'Merged!' mails from BB show the wrong previous status
<jelmer> which ones in particular?
<colbrac> Fix lp115...bla and Remove olive.glade -take2 have semi-approved
<colbrac> while Fix lp115.. is approved, and Remove.. conditionally approved
#bzr 2008-07-23
<jelmer> hmm, that doesn't make sense to me either
<jelmer> abentley, ^
<jelmer> abentley: http://bundlebuggy.aaronbentley.com/request/%3C48859468.40605%40xs4all.nl%3E says conditionally approved
<jelmer> http://article.gmane.org/gmane.comp.version-control.bazaar-ng.gtk/1294 says semi-approved
<jelmer> poolie: at the risk of repeating myself.. what's the status on 1.6 ? :-)
<jelmer> poolie, will you do a rc or something or are there other things you'd like to get fixed first?
<AfC> jelmer: (fwiw, there have been some emails about that)
<AfC> jelmer: (but it's a busy list, so easy to miss things)
<Traveler9> How do I fix this: Unable to import paramiko (required for sftp support): No module named paramiko
<Peng_> Traveler9: You install paramiko.
<Traveler9> How do I do that?
<bob2> depends on your OS
<Peng_> Note that paramiko depends on PyCrypto.
<Traveler9> Windows XP
<bob2> hm, I thought the bzr windows installer thing included paramiko
<Traveler9> I found a site that says
<Traveler9> pycrypto compiled for Win32 can be downloaded from the HashTar homepage: http://nitace.bsd.uchicago.edu:8080/hashtar
<Traveler9> But the link is dead.
<bob2> the links on http://bazaar-vcs.org/WindowsInstall are dead?
<Traveler9> I got the Paramiko binaries from there, but I get the same error.
<nekohayo> seriously. http://ecchi.ca:8000/1.png
<nekohayo> how can I be prevented from removing my own branch? any solution for this?
<mwhudson> you have to get the subscriber to unsubscribe
<Odd_Bloke> mwhudson: As a workaround, or is that intended behaviour?
<mwhudson> more intended than not i think
<Odd_Bloke> O.o
<nekohayo> mwhudson: wtf? :)
<nekohayo> branch watchers can hold branch makers hostages nowadays?
<Traveler9> I installed paramiko on WinXP and I'm getting: Unable to import paramiko (required for sftp support): No module named paramiko
<mwhudson> nekohayo: the only thing that has changed recently is that you can delete branches at all :)
<nekohayo> makes me want to reconsider launchpad as a hosting service :) perhaps I should just dump branches on my apache server
<nekohayo> anyway I guess I'll just change its name and status for now
<mwhudson> well, i doubt SF let's you entirely blow away the history of a project's svn repo
<mwhudson> which is what deleting a branch is like
<markh> Traveler9: you have Python installed, and running bzr from that?
<Traveler9> Yes and yes
<markh> does 'python -c "import paramiko"' work?
<Traveler9> Hm I did that and it said nothing
<Traveler9> But I get the same error on a bzr push
<thumper> nekohayo: the intent was to allow the watchers to have time to branch if they are interested before you delete it
<thumper> nekohayo: I am beginning to think that it isn't such a good reason
<nekohayo> thumper: hm. perhaps there should be a "it will be deleted in 72 hours" then?
<thumper> nekohayo: yeah, that sounds sensible
<Odd_Bloke> Perhaps making the choice to abandon a branch more obvious too.
<markh> Traveler9: so if you execute 'bzr version', does the location of the "Python standard library" match what you expect (ie, is it your Python's lib directory where paramiko is?)
<Traveler9>  Python standard library: C:\Program Files\Bazaar\lib\library.zip
<Traveler9> Not sure where paramiko was installed to.
<markh> Traveler9: right - you are running a binary version, not the Python version
<markh> the simplest answer is probably to update your binary version of bzr - can you remember what version of bzr you installed?
<Traveler9> Bazaar (bzr) 1.6b3
<is_null> i finnaly got bzr+bzr-svn, but tests don't pass: http://nopaste.com/p/aPc7fi5uh any tip please? is it a local issue?
<markh> I'm surprised that comes without paramiko
<markh> I'm putting up a 1.6b4 binary right now that should work :)  It will be a few minutes though, and its about 16MB as it has a full copy of Qt4 included (I tried but failed to trim some of that - later!)
<markh> Traveler9: actually, b4 isn't quite ready :)  starship.python.net/crew/mhammond/bzr-setup-1.6b3.exe is a slightly different binary version than what you are using - it contains a rudimentary Tortoise and also works fine with Paramiko, if you want to give it a go.  b4 will have a much better tortoise, but I'm sure you can survive a few days :)
<Traveler9> Should I uninstall bzr first?
<markh> it shouldn't hurt not too, but it sure can't hurt to uninstall :)
<bpeterson> can bzr log and diff be optimized for huge projects?
<Traveler9> Okay that version gives me: 0.235  failed to instantiate transport <bzrlib.registry._LazyObjectGetter object at e710a8, module='bzrlib.transport.sftp' attribute='SFTPTransport'> for 'sftp://fortw@67.222.133.33/~/': ParamikoNotPresent()
<is_null> what does that mean please? "bzr: ERROR: Repository KnitPackRepository('file:///home/jpic/testbzr/.bzr/repository/') is not compatible with repository SvnRepository('file:///home/jpic/testsvn')"
<mwhudson> beuno: replied to your mail
<bpeterson> is_null: it means you have to make different repo when you do init-repo
<markh> bugger.
<jelmer> is_null, which bzr-svn branch are you using (wrt http://nopaste.com/p/aPc7fi5uh) ?
<is_null> bpeterson, i see, i'm trying to track/branch a framework svn repo inside the bazaar repo
<is_null> jelmer, 0.4
<jelmer> hmm, perhaps I forgot to push some changes
<jelmer> is_null: the error is caused by your local bzr repository not being a rich-root-pack repository
<jelmer> see the bzr-svn FAQ
<is_null> for testing, i made the bzr repo in ~/testbzr, an svn repo in ~/testsvn (svn wc: ~/testsvn2), i'm trying to get ~/testsvn tracked and branched into ~/testbzr
<is_null> jelmer, i just saw the faq, sorry
<is_null> the problem is now "AttributeError: 'SvnWorkingTree' object has no attribute '_transport': http://nopaste.com/p/ayvGv2tIb
 * mwhudson lunches
<markh> Traveler9: I'm stumbling around a little in the dark now, but I'm guessing it might be specifically related to sftp.  what does "bzr selftest test_sftp" do for you?  I get 18 tests run, 1 failure and 3 skips
<Traveler9> 18 tests, 3 skipped, tests failed
<Traveler9> [18/18 in 4s, 1 fail] test_sftp_transport.TestSocketDelay.test_delay
<jelmer> is_null, I'll have a look, probably broken by some recent change in bzr.dev
<is_null> jelmer, what revision are you using?
<jelmer> bzr.dev 3565
<jelmer> bzr-svn 1489
<is_null> thanks!
<markh> same result - strange.  i'm fairly sure paramiko us being used in those builds for bzr+ssh pushes. but I haven't tried sftp
<poolie> <jam> /train :-) :-)
<poolie> hi markh
<markh> hi poolie
<fullermd> Are these bzr-gtk BB confirmations leaking onto the bzr list?
<Odd_Bloke> They seem to be.
<Odd_Bloke> abentley: ^
<jelmer> BB uses the branch location to find the project but it doesn't know about all of the aliases for bzr-gtk on launchpad
<jelmer> if it can't find the submit branch location, it'll default to bzr
<lifeless> hi
<lifeless> cjwatson: its in progress on my laptop; haven't finished investigating
<jelmer> 'morning lifeless
<lifeless> jelmer: hi, any progress on that bug?
<jelmer> lifeless, hi
<jelmer> lifeless, I've merged your rebase branch
<jelmer> lifeless, Which bug?
<lifeless> cool
<mwhudson> hi lifeless
<lifeless> bzr-svn critical thingy
<lifeless> hi mwhudson
<lifeless> jelmer: the one discussed in $gnome-bzr
<Traveler9> shoop da woop
<lifeless> I've literally just got home from the plane, I'll be a bit spotty today
<lifeless> Bug 250480
<ubottu> Launchpad bug 250480 in bzr-svn "Missing texts, ghosts and inconsistent parents" [Critical,New] https://launchpad.net/bugs/250480
<Traveler9> Is cElementTree needed?
<markh> Traveler9: how you going - i seem to be able to push to sftp fine with those binaries
<markh> Traveler9: its not in those binaries, so I hope not :)
<jelmer> lifeless, I've been travelling until late yesterday evening so haven't had much time to look at it yet
<lifeless> jelmer: ok
<lifeless> me too :)
<markh> Traveler9: is it possibly something in your environment?  Is it possible you tried to install paramiko into the "\program files\bazaar" directory?
<Traveler9> It was installed to the default, I didn't change anything.
<markh> your python install should not be used at all when using the binaries.  Theoretically they couldn't possibly conflict, but theory and practice...
<Traveler9> I'm getting this now: bzr: ERROR: exceptions.NameError: global name 'win32ui' is not defined
<is_null> why isn't bin/bzr compiled?
<bob2> to what?  it is python code.
<bob2> bytecompiled?
<markh> Traveler9: ack, that is in paramiko.  You getting that running "python bzr", or bzr.exe?
<Traveler9> cmd.exe /K start_bzr.bat
<is_null> bob2, yes
<jelmer> is_null, how did you get the _transport error?
<bob2> is_null: it is like 80 lines of code :)
<is_null> jelmer, sorry, i did not make the investigation log
<jelmer> is_null, I've just pushed some fixes to the 0.4 branch
<jelmer> any chance you can try again?
<is_null> bob2, i'd like to set different pax flags on bzr, i tryed to bytecompile it by running `python -O bzr` as in section 6.1.3 of http://docs.python.org/tut/node8.html but it did not create the bytecompiled file and i'm a newbie with python ... any tip please?
<is_null> jelmer, sure
<is_null> (note that i was probably mis-using bzr-svn)
<jelmer> is_null, that's alright, it shouldn't yell at you if you do that
<markh> Traveler9: I'm not sure how that happened-  I might need to check the paramiko binary - but it looks like you will need to edit paramiko\win_pageant.py :(
<bob2> is_null: I don't think that will help, 'python' will still be the executable
<markh> the paramiko trunk doesn't have that error
<is_null> jelmer, can't reproduce, sorry
<Traveler9> I'm not sure how to go about doing that.
<is_null> bob2, true ... i was confused
<markh> The problem isn't simply "paramiko is missing" - if it is, the error looks more along the lines of "bzr: ERROR: Unsupported protocol for url "sftp:... No module named paramiko"
<Traveler9> Do you want the entire backtrace?
<markh> not of the NameError - I'm more interested in your original error from the binary "failed to instantiate transport <bzrlib.registry._LazyObjectGetter object at e710a8, module='bzrlib.transport.sftp' attribute='SFTPTransport'> for 'sftp://fortw@67.222.133.33/~/': ParamikoNotPresent()" and why that is failing to find paramiko
<Traveler9> Well right now it's giving me the NameError
<markh> oh - you mean start_bzr.bat from the "\program files\bazaar" directory?  Yeah, please include the 2 lines above the one you show
<Traveler9> 2 lines above "global name 'win32ui' is not defined"?
<markh> yeah
<Traveler9> >bzr push --create-prefix sftp://fortw@68.222.133.33/
<Traveler9> Connected (version 2.0, client OpenSSH_4.3)
<Traveler9> bzr: ERROR: exceptions.NameError: global name 'win32ui' is not defined
<jelmer> lifeless, just posted a comment; I can't reproduce it
<markh> that is looking very much like an error I made making those binaries :(  I'll try and have a fixed one in an hour - hopefully less.
<is_null> jelmer, i've got a segfault with bzr-svn: http://nopaste.com/p/aRwQLnxlk what bzr-dev revision for the current head of bzr-svn please?
<jelmer> the latest bzr.dev should work with the latest of bzr-svn
<is_null> still segfaulting ...
<jelmer> is_null, that sequence of commands works fine here
<jelmer> what version of python are you using?
<jelmer> and what hardware platform?
<is_null> jelmer, amd64, python 2.5.2
<jelmer> is_null: The bzr-svn testsuite doesn't segfault?
<lifeless> spiv: http://svn.gnome.org/tmp/common-pre-commit
<lifeless> spiv: gnome common hook sources
<lifeless> jam: ping
<is_null> jelmer, http://nopaste.com/p/a2J5Ni7Jm
<lifeless> jam: is there a canned way to disable lazy imports?
<jelmer> is_null, can you try "make check-one" ?
<jelmer> (or bzr selftest svn --one)
<lifeless> jelmer: debugging the segfault I get ? ::)
<spiv> lifeless: thanks, but I already have a copy of that.
<lifeless> spiv: cool
<lifeless> spiv: I was closing browser windows
<spiv> Ah, right.
<jelmer> lifeless, I think it's a different one - he's getting unexplainable errors in the testsuite as well
<is_null> jelmer, http://nopaste.com/p/adjtVmRUI
<lifeless> jelmer: the test suite that segfaults for me ? :)
<lifeless> jelmer: python 2.5.2 amd64
<jelmer> lifeless: Do you get testsuite errors before the segfault?
<jelmer> is_null, what version of subversion are you using?
<is_null> jelmer, 1.5.0
<lifeless> jelmer: svn, version 1.4.6 (r28521)
<lifeless> jelmer: running make check
<lifeless> jelmer: fail - doesn't honour PYTHONPATH
<is_null> it seems to do so here: http://nopaste.com/p/aaI6uBvZQ
<jelmer> lifeless, I'm pretty sure it does - you may need to set $BZR though
<lifeless> which bzr gets the right bzr
<libwilliam> I was wondering if there was a place somewhere that listed the strings you couldn't pass into the --message option of bzr log
<lifeless> jelmer: no errors just hte segfault
<libwilliam> currently I know of bzr log --message=* --message=? --message=+
<markh> Traveler9: http://starship.python.net/crew/mhammond/bzr-setup-1.6b4-mh1.exe will hopefully work better for you.
<bob2> libwilliam: surely that is a limitation of your shell, rather than bzr
<lifeless> libwilliam: it wants a regex
<lifeless> libwilliam: so "bzr log -m='.*'" will work fine
<lifeless> (for instance)
<bob2> libwilliam: eep, sorry, read 'commit' rather than 'log'
<libwilliam> lifeless, well I am doing the Anjuta plugin, and I have an entry where someone types in a regex and I update on the go... I just don't want it crashing if the first char they type is *
<libwilliam> currently I can handle ignoring a first char of * + or ? but I wasn't sure if that was all of them.
<lifeless> libwilliam: if you're doing that sort of search, I would suggest using bzr-search instead
<lifeless> libwilliam: but separately - nothing should cause bzr log -m to actually crash; if you see crashes please file a bug
<libwilliam> ok
<libwilliam> ill make sure and submit a bug
<lifeless> it just won't find anything useful if its not a valid regex
<lifeless> (bzr-search will be stupidly faster than log -m for long lived projects)
<Traveler9> Okay
<libwilliam> k, stupidly fast sounds good :)
<lifeless> it doesn't suport regexes or stemming or anything yet
<jelmer> is_null, checking what could cause this..
<lifeless> just simply boolean AND with literal matches
<is_null> jelmer, wait, something is actually eating all my RAM and i can't figure the process
<libwilliam> unfortunately I need xml output, I am using the xml plugin... but I think something like that is in the works
<lifeless> there is xml plugin support for search
<Traveler9> bzr: ERROR: exceptions.NameError: global name 'win32ui' is not defined
<libwilliam> bzr-xmloutput has search support?
<lifeless> libwilliam: Verterok: knows the details, but there is a bzr-eclipse that has search support
<lifeless> and it uses the xml stuff too
<jelmer> is_null, any chance you can try again with the latest revision in the 0.4 branch?
<Odd_Bloke> libwilliam: Surely you can validate whether a string is a regex before passing it through to bzr?
<spiv> Or just re.escape the search string.
<lifeless> spiv: kindof prevents them using a re ;)
<libwilliam> Ya Vertorok mentioned he was working on doing something with search in his plugin
<spiv> lifeless: well, depends on what they want :)
<libwilliam> For the mean time I will check if it is a regex beforehand... and I'll submit a bug on the bzr crash with an invalid regex
<lifeless> libwilliam: the search is in the xmlrpc plugin I think.
<lifeless> libwilliam: or the rpc branch of xmloutput
<lifeless> I dunno the details :)
<lifeless> all I know is I have eclipse here that does bzr-search integration
<libwilliam> thats the one I have checked out :) so i'll browse the code and see how to use it
<is_null> jelmer, http://nopaste.com/p/aTshZ4A9y btw, see at the end that there is >2G of free RAM, and it still exits "out of memory"
<libwilliam> thanks!
<Verterok> libwilliam: hi
<libwilliam> Verterok: hey
<Verterok> lifeless: the xmlrpc service in xmloutput now support bzr-search ;)
<jelmer> is_null, I suspect this is some 64-bit-related issue
<libwilliam> Nice :)
<jam> lifeless: I don't have a canned way to do so, but in the 'bzr' script you could do override the lazy_import function. You could even just use the same ImportProcessor with a different lazy_import_class that just automatically imported them into scope.
<jam> That said, I know that bzrlib won't import anymore because of cyclical dependencies
<Verterok> libwilliam: the support is only for the xmlrpc bit, it uses xmlrpc de/serialization to send the results to the client (a simple dict)
<lifeless> jam: damn
<libwilliam> Alright, the xmlrpc thing I am going to look into after I get most of the stuff working by itself, which is close.
<libwilliam> When you explained it it didn't seem so tricky
<lifeless> mwhudson: how did you make pyflakes/pydocktor work with lazy import?
<mwhudson> lifeless: i only did pyflakesw
<Verterok> libwilliam: but I think that writting a xmlsearch command should be quite easy :)
<lifeless> mwhudson: ... and how?
<Verterok> libwilliam: be aware that I don't have a clue about how to write a xmlrpc client in C :)
<mwhudson> lifeless: https://code.edge.launchpad.net/~mwhudson/pyflakes/support-lazy-imports
<mwhudson> lifeless: by compiling the string that gets passed into lazy_import into an ast and processing that just like the rest of the ast
<libwilliam> Verterok: you just avoided a question in a couple weeks ;)
<lifeless> blergh
<Verterok> heh :)
<is_null> jelmer, well thanks for your help anyway, i know that you can't do anything about it... too bad i couldn't get my stuff done after all that hours trying (hopefully i'm a newbie and used to it)
<lifeless> jam: I want to try our freeze
<lifeless> its been on my list for $too_long
<jam> freeze?
<lifeless> jam: do you think the cyclical imports are easy to resolve?
<jam> lifeless: It would just be delaying them to some later time
<lifeless> jam: py2exe for linux. ish.
<jelmer> is_null, Things should hopefully be a bit easier to deal with once the new versions of bzr and bzr-svn are out
<is_null> jelmer, what do you mean?
<Leefmc> Question: What is the proper command for uploading a branch to the launchpad? I'm rather confused as if i "register a branch" (Trunk for example), the resulting branch is "located at ~myname/hcrf/trunk", which seems odd to me to tie a project branch to my name
<jelmer> is_null, well, since you can't use the current release because of some bugs that have since been fixed
<jelmer> I assume your distro packages bzr and bzr-svn?
<Leefmc> I'm coming from Git, but this is obviously foreign heh
<lifeless> Leefmc: well, if you want a project branch that many people can upload to, create a team
<lifeless> Leefmc: branches in launchpad are in a namespace - owner/project/name
<jam> lifeless: the other 'quick hack' to do it is to just comment out the "lazy_import(globals(), """ line
<Leefmc> lifeless: I have to create a team "first"? At the moment i dont have a team, nor do i want one, but later it will be desired.
<lifeless> Leefmc: this lets anyone call their branch anything they want
<Leefmc> lifeless: Ah, ok
<jam> I intentionally made the syntax == regular import
<lifeless> Leefmc: you can create a team later and hand the branch over to the team
<Leefmc> lifeless: I just found it odd since my project is launchpad.net/myproj
<is_null> jelmer, i'm using bzr.dev and the 0.4 branch of bzr-svn ...
<jam> so I think you could do:
<jelmer> is_null, yeah, but the 0.4 branch is rather unpolished
<jam> lazy_import = lambda scope,text: eval text in scope
<jam> or something to that effect
<jelmer> is_null, in particular, this 64-bit issue exists at the moment but that should be fixed before the release
<jelmer> It doesn't exist in 0.4.10
<lifeless> jelmer: do you have access to a 64 bit cpu?
<lifeless> is_null: you could run under gdb
<is_null> lifeless, can't (aslr)
<jelmer> lifeless, no, but I'm installing debian on a 64-bit qemu image atm
<lifeless> jelmer: let me know if you can't reproduce
<ToyKeeper> No matter how many times I hear that, it still doesn't sound right.
<jelmer> ToyKeeper, ?
<pickscrape> hehe
<pickscrape> I think he was referring to "let me know if you can't reproduce"
<jelmer> lol
<pickscrape> Which might be something you'd get referred to a fertility specialist for.
<Leefmc> Question: Does launchpad code give you the ability to view source code? (Ie, web based source, with highlighting, etc?)
<jelmer> I had never thought of interpreting it that way
<pickscrape> Takes a strange mind...
<lifeless> Leefmc: http://bazaar.launchpad.net/USER/PROJECT/BRANCH
 * ToyKeeper spent much of the past 2 years trying not to laugh during QA meetings because of that particular language quirk
<spiv> Leefmc: you can browse source, he's an example of a file in a branch: http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/head:/README
<lifeless> Leefmc: e.g. http://bazaar.launchpad.net/~lifeless/+junk/bzr-index2
<Leefmc> ah k ty. I was wondering because it seems i have uploaded my project, but i have yet to find where i can browse the source, etc.
<spiv> Leefmc: it doesn't do syntax highlighting of files yet, though.
<Leefmc> no biggie
<spiv> There's a "Browse code" link on the branch page.
<spiv> (Assuming that the branch has revisions in it, anyway)
<Leefmc> yea
<Leefmc> So what is the proper pushing command then? The tutorial shows bzr push bzr+ssh, but the launchpad pages show bzr push lp:
<Leefmc> Though i've gotten errors everytime with lp
<ToyKeeper> Leefmc: Did you 'bzr launchpad-login myname' first?
<Leefmc> No, i get an error with that
<spiv> Either is fine, the "lp:" one is just a shortcut.  If you get errors with it, it's likely because you haven't run "bzr launchpad-login YOURNAME" first.
<ToyKeeper> You need to give it your username, and set up ssh keys, before you can push to launchpad.
<Leefmc> Note that the tutorial never talked about the lp one, nor launchpad-login
<Leefmc> ToyKeeper: Yea but i can't do that heh,it just gives errors :/
<Leefmc> 1 sec, i'll get the error
<Leefmc> This is part of it: ....  is permanently redirected to https://launchpad.net/~...
<Leefmc> Full: bzr: ERROR: https://launchpad.net/%7ELeefmc/%2Bsshkeys is permanently redirected to https://launchpad.net/~leefmc/+sshkeys
<bob2> enter that URL in your web browser to paste your id_rsa.pub in
<pickscrape> How can I retrospectively add --no-trees to a shared repository?
<spiv> Leefmc: https://launchpad.net/~leefmc/+sshkeys is not a URL for a bzr branch
<lifeless> pickscrape: touch .bzr/repository/no-working-trees
<lifeless> pickscrape: (sorry)
<pickscrape> lifeless: excellent, thanks
<pickscrape> Worked like a charm :)
<jamesh> sounds like something "bzr reconfigure" should let you do
<lifeless> indeed
<spiv> Leefmc: also, there doesn't appear to be a 'leefmc' user in Launchpad, although I do see a 'leefmc+0layvar'.
<lifeless> mwhudson: pyflakes uses the python parser?
<mwhudson> lifeless: it uses the compiler package
<mwhudson> (which uses the parser module, which uses the python parser)
<Leefmc> spiv: About the url, i dont know about that. All i know is i type "bzr launchpad-login Leefmc" and it gives me that error. Also, i assumed it wanted my display name because it roughly accepts "Leefmc", but if i type "leefmc" it returns a "no leefmc user" error
<Leefmc> I'll try my full name
<spiv> It wants your launchpad user ID.
<lifeless> holy cow
<Leefmc> spiv: So which command should i use for pushes then? As i mentioned the tutorial gives one example, the project pages give another
<spiv> Leefmc: that error is pretty bad, it seems to be a bug in the launchpad-login command.
<Leefmc> spiv: Gotcha, i changed my "name" to leefmc anyways, and now it worked :)
<spiv> Leefmc: either is fine, but "lp:" requires that you've done a successful "bzr launchpad-login ..." first.
<spiv> Leefmc: the lp: essentially just redirects to the bzr+ssh:// location
<Leefmc> spiv: Either is fine, but one isn't optimal over the other?
<Leefmc> Ah ok, gotcha :)
<spiv> But is obviously much shorter to type.
<jam> lifeless: if you are just looking to use something like py2exe, our setup.py code already has something to hack in understanding of lazy_import for py2exe
<jam> you might just grab that
<lifeless> jam: freeze generates C modules
<jam> ah
<jam> interesting
<lifeless> /usr/share/doc/python2.5/examples/Tools/freeze
<lifeless> with the bytecode in an array.
<lifeless> fugly stuff :)
 * ToyKeeper wonders why bzr remembers the expanded URL instead of the one the user entered
<jamesh> do people still use freeze?
<lifeless> jamesh: I want to see what it does to startup time
<jamesh> lifeless: I'd have thought that zip imports would give similar performance
<lifeless> jamesh: depends where the slowdown really is
 * igc lunch
<Leefmc> There doesn't seem to be a link section for a project dev blog, am i correct? (Ie, to tell users of the project dev blogs location)
<lifeless> markh: does py2exe work on linux?
<lifeless> Leefmc: don't think there is no; #launchpad is the IRC channel for launchpad specific questions BTW
<Leefmc> lifeless: Thanks for the heads up
<markh> lifeless: not afaik
<lifeless> (though we'll try to answer here, the actual lp devs are better represented on #launchpad)
<markh> I believe it can run on linux, but not create executables that target linux
<markh> there is py2app for macosx - and pyinstaller is a revival of a dead project, and it says it works on linux - http://pyinstaller.python-hosting.com/ - but I'm not sure how active that is
<Leefmc> How do you save a location to bazaar?
<Leefmc> Mine has an invalid location saved (for pushing)
<bob2> "bzr push --remember kajshdfklajsh" will overwrite the existing value
<lifeless> Leefmc: --remember
<Leefmc> thanks
<lifeless> markh: yah, I want a monolithic binary, not an installer.
<lifeless> need sleep, back in a few
<lifeless> hours that is
<Leefmc> Question: So, just to get my bearings, in Git i would often try out code ideas by creating a separate branch and toying with code. And ofcourse at anytime you can switch pop back and forth between the two branches. How is this done in bzr?
<Leefmc> bzr branch seems to talk about separate directories and junk
<Leefmc> so i assume that is not what i want
<lifeless> what you probably want is:
<lifeless> bzr init-repo --no-trees REPO
<lifeless> bzr init REPO/trunk
<lifeless> bzr checkout --lightweight REPO/trunk WORKING
<lifeless> cd WORKING
 * Leefmc is confused :)
<Leefmc> So wait
<lifeless> cp -r /source_I_want
<lifeless> bzr add
<lifeless> bzr commit -m 'imported'
<Leefmc> your cd'ing, so is the git workflow not possible in bzr?
<lifeless> bzr branch $REPO/trunk $REPO/branch
<lifeless> bzr switch branch
<lifeless> bzr switch trunk
<lifeless> etc
<lifeless> Leefmc: its totally possible, we have separate concepts for 'source you edit', 'branch', and 'history storage'
<lifeless> it just looks a tiny bit different than in git
<Leefmc> Well i mean, your cding.. so your storing your branches as copies, correct?
<Leefmc> Thats not exactly what i was looking for
<lifeless> what my commands above setup is one tree to edit your source, N branches, and one repository to store your history
<lifeless> Leefmc: I don't know what you mean by 'as copies'. Each branch is a few KB of data
<markh> those tools all try to get as close to a monolithic installer as possible iiuc
<Leefmc> lifeless: Copies as in, say all your code is in "/src", are you storing "/src" and "/test-branch" ?
<markh> pyinstaller's history is that it was proving better than py2exe, but then the maintainer vanished, so most people jumped back to py2exe - then it was revived as pyinstaller.
<lifeless> Leefmc: I don't follow the question
<Leefmc> lifeless: Ie, in git (and this is the main point im driving at) all your code is stored under "/src" and git modifies your source depending on the branch your in
<Leefmc> lifeless: So you can have ten branches, but you only have one directory for your source
<Leefmc> lifeless: And switching between those branches does nothing but change the contents of "/src"
<Leefmc> lifeless: But git manages that, not me. No cding, etc
<lifeless> Leefmc: so there are two separate things here: having N directories, and 'switch does nothing but change the contents of "/src"'
<lifeless> Leefmc: in bzr (without plugins) a branch is always a directory, so that you can use normal tools to manage it
<Leefmc> lifeless: Gotcha
<lifeless> Leefmc: but your *source code* is able to be decoupled from the *branch*
<lifeless> Leefmc: and that gives you 'switch does nothing but change the contents of "/src"'
<lifeless> Leefmc: e.g. if you have two branches of mysql with only a couple of files different, 'bzr switch' will only write to those two files, and the metadata files during the update
<Leefmc> lifeless: Gotcha
<lifeless> Leefmc: give the commands I put up above a poke, and peek around inside .bzr of each thing
<Leefmc> k
<lifeless> I'm going away for a few hours (jetlagged), but there are other folk here can probably help you understand what bzr can offer
<Leefmc> thanks
<Leefmc> night ;)
<lifeless> k, really going. but a quick result from freeze: stat system time : 0m0.048s vs 0.072s (wall clock not dramatically different on hot-cache)
<lifeless> on cold cache, the frozen bzr is 2 seconds faster
<lifeless> (with --no-plugins given)
<markh> that's significant
 * markh the master of understatement ;)
<pickscrape> Anyone know the current state of trac-bzr development?
<pygi> pickscrape, I don't really think it's being developed, tho you probably shouldn't listen to me :p
<pickscrape> That's a shame
<pygi> oh well
<jelmer> pickscrape, devleopment is still happening
<jelmer> pickscrape, it's not at a very high pace, but there is the occasional patch every now and then
<pickscrape> jelmer: yes, I'm just trying to decide which branch to install
<pickscrape> trac0.11 is the obvious choice
<pickscrape> But then ~menesis/trac-bzr/menesis-dev adds a couple of additional commits on top of that
<jelmer> pickscrape, I would recommend just lp:trac-bzr
<pickscrape> Does that suppose 0.11 though?
<jelmer> yeah, I think it does
<Odd_Bloke> What's the status of Cart?
<thumper> Odd_Bloke: :) dormant?
<thumper> Odd_Bloke: are you doing the weird nocturnal lifestyle thing?
<AfC> ï»¿Don't be awake when everyone else in your timezone is. Fight the establishment!
<alecw1> What is the best name for a development branch? I've heard dev, devel, head, trunk... which is recommended?
<thumper> alecw1: I normally use a feature name
<thumper> alecw1: eg. revision-feed or karma-for-commits
<alecw1> I'm talking about the repository that we merge all tested features into; it's like, the main game branch.
<thumper> trunk
<thumper> that's what I call it
<thumper> but often it is devel
 * thumper shrugs
<thumper> bzr has bzr.dev
<thumper> I don't think there is a recommended name
<thumper> just as long as there is a concensus
 * thumper looks at the word thinking he has spelled it wrong
<alecw1> consensus
<alecw1> okay, I think I'll stick with trunk
<alecw1> that just sounds to-the-point, easy to say, etc
<AfC> alecw1: we use 'mainline'
<alecw1> AfC: but that's not very conventional. =P
<jamesh> "trunk" is familiar to people who are coming from subversion
<AfC> alecw1: it is the "mainline" of development.
<jamesh> and isn't a particularly bad choice
<pickscrape> For our new repo we're using 'live' because that's what it represents in our case
<pickscrape> development happens on branches
<pickscrape> (it's a website)
<AfC> jamesh: being palatable to people who refused to move on from Subversion wasn't a high priority for us at the time.
<jamesh> AfC: that is not what I said
<alecw1> "trunk" doesn't imply that 'development happens here' though.
<jamesh> AfC: what I mean is that if there are a number of equally valid choices, why choose to be different?
<alecw1> jamesh: agreed, it just seems easier, familiar, and not incorrect.
<jamesh> and I am not suggesting that blindly copying subversion on everything is a good idea either
<AfC> jamesh: I can't remember who suggested it at the time, but I was well familiar with the term from both the corporate world and older open source communities. If anything, we found 'trunk' ambiguous. Whatever
<jamesh> just save your inconsistencies for things that matter.
<jamesh> AfC: sure.  If anything, Subversion picking "trunk" was inconsistent with CVS
<jamesh> or maybe not.  The CVS docs seem to use "main" about as much as "trunk", and often talk of the "main trunk"
<AfC> Our use of DVCS predates Subversion. I really don't attach a high priority to their terminology for things. Admittedly, I'm not in the business of convincing people who use it to switch. And certainly, far be it from me to tell others what to pick. People can do what they want with their own projects.
<pickscrape> jelmer: JFYI, ~vslavik/trac-bzr/trac0.11 does a better job with trac0.11 than lp:trac-bzr does
<pickscrape> trac-bzr won't even let me view a changeset.
<rusty> Hi all... someone else committed to my repo, but I see the change or pull it.  The only clue is that on the server that commit has "branch nick: commit_repo" whereas all mine are "branch nick: ccan"
<rusty> s/but I see/but I cannot see/
<sohail> hey guys, how would I convert a git repository to bzr?
<mwhudson> sohail: "fast-export"
<sohail> mwhudson, and then importing to bzr?
<mwhudson> sohail: right, there is a bzr-fastimport plugin
<spiv> rusty: where are you seeing "branch nick: commit_repo"?  I'm a bit confused, you say both that you can see the nick in a commit, but also that you can't see the commit?
<AfC> If rusty has pulled, then `bzr update` won't help, will it?
<sohail> mwhudson, thanks
<mwhudson> sohail: note that i've never done this, i'm just parroting what i've seen other people say :)
<rusty> spiv: server ozlabs.org sees commit in the logs.  I pull, it says "No revisions to pull."
<sohail> mwhudson, thats ok.. I probably wouldn't lose any data :-)
<mwhudson> sohail: :)
<spiv> rusty: does "bzr log --show-ids -r -1" on both locations show the same thing?
<AfC> rusty: when you say "logs" do you mean `bzr log` on the serer in that branch there shows the revisions, or something to the effect of "I saw it in the Apache log" (sic)
<rusty> spiv: no.  I have 51. It has 52.
<rusty> AfC: `bzr log` in server repo dir vs. `bzr log` on my machine.
<AfC> rusty: got it
<AfC> rusty: that's a weird behaviour. Something is wedged, I should think
<rusty> AfC: it's possible that my GSoC student created a branch somehow.
<spiv> rusty: Hmm, then "bzr pull URL" should pull that new revision.
<rusty> spiv: yeah, you'd think so!
 * spiv thinks
<spiv> Is this a checkout or a brancH?
<spiv> (i.e. does "bzr info" include the word "checkout" somewhere in the output?)
<spiv> If it's a checkout of the remote branch, then the problem might be that you need to run "bzr update" to update the checkout.
<rusty> spiv: neither end does:
<rusty> server: Standalone branch (format: pack-0.92)
<rusty> my end: Standalone tree (format: dirstate)
<rusty> spiv: Hmm, server is 1.5, I am 1.3.1
<spiv> Those versions should be ok.
<spiv> Hmm.  Your side is in an old format though.
<spiv> I guess it's possible that you have hit a bug that causes the revision-history file in an old format branch to be a bit inconsistent, though that seems pretty unlikely.
<rusty> spiv: repo is published at http://ccan.ozlabs.org/repo/ via a CGI I got from somewhere...
 * spiv looks
<rusty> spiv: looks like an hgweb ripoff :)
<spiv> Ah, good ol' bzr-webserve :)
<rusty> And that doesn't show rev 52 either :(
<spiv> Ah, no, it's branch format 6, so it's not a revision-history file problem.
<rusty> spiv: want ssh access to the box?  Or a tarball of the whole repo?  It's pretty small.
<spiv> rusty: is there a public URL for the branch with revno 52?
<spiv> rusty: yeah, a tarball's fine.  andrew at canonical.com.
<rusty> spiv: I don't even know if it is a branch... how do I tell?
<spiv> If you can do things like "bzr log" in it, it's a branch :)
<spiv> More precisely, if it has .bzr/branch/*
<rusty> spiv: http://ozlabs.org/~rusty/repo.tar.bz2
<rusty> spiv: 700k.
<spiv> rusty: ta
<pygi> aha, now I can send a patch against a patch because I just found a bug :p
 * pygi hides
<spiv> rusty: hmm, so if I untar that to /tmp, and do "bzr branch http://ccan.ozlabs.org/repo/; bzr pull /tmp/repo", it pulls revision 52
<AfC> rusty: to elaborate on something spiv said, you can have an "empty" directory that has a branch in it if there's a .bzr/branch/ there; the directory will be populated with the project when there is a Working Tree present, but one doesn't always have to have the full tree sitting there checked out to have a branch location;
<AfC> rusty: Repository in Bazaar parlance is the .bzr/repository/ directory, which might be at ., might be at .., might be at ../.., etc
<spiv> rusty: so at this point I guess we should double-check that the location that "bzr pull" is using is what we think it is
<AfC> rusty: [when at .. or higher it is a "shared repository"]
<rusty> spiv: trying that cmd here.
<spiv> Hmm, "bzr branch http://ccan.ozlabs.org/repo/ foo; cd foo; bzr pull /tmp/repo" actually
<rusty> spiv: yep... will take a while, satellite :)
<spiv> rusty: ah, ouch :)
<spiv> I should get back to cutting down round-trips then ;)
<rusty> spiv: Branched 51 revision(s).... +N etc..  Now on revision 52.
<rusty> spiv: OK, so that worked.  But why didn't pull just go straight to 52?
<rusty> spiv: (I used branch -v BTW)
<spiv> Well, what URL did "bzr pull" say it was using before?
<spiv> (I'm assuming you were just doing plain "bzr pull" with no explicit URL)
<rusty> http://ccan.ozlabs.org/repo/  I also tried explicitly pulling from bzr+ssh://...
<rusty> (which should be same repo as cgi points at)
<spiv> Ah, but http://ccan.ozlabs.org/repo/ only has revision 51.
<spiv> $ bzr revno http://ccan.ozlabs.org/repo/
<spiv> 51
<rusty> spiv: yes, but why?
<rusty> spiv: bzr log on that dir says it has 52.
<rusty> spiv: and using bzr+ssh://  didn't see 52 either, so I can't blame some cgi weirdness.
<spiv> What exactly do you mean by "on that dir?"
<spiv> I see only 51 with "bzr log $ bzr revno http://ccan.ozlabs.org/repo/
<spiv> 51
<spiv> d'oh
<spiv> I see only 51 with "bzr log http://ccan.ozlabs.org/repo/ -r -1"
<rusty> spiv: I ssh into server, do "bzr log" in /home/ccan/repo...
<spiv> And bzr+ssh://server/home/ccan/repo didn't show 52?
<rusty> spiv: hold on, I'm using a wrapper for ssh access in the ccan account's .authorized keys... bzr-ssh
<spiv> Ah, hmm.
<rusty> spiv: maybe I screwed something there.... one sec, will try circumventing it.
<rusty> spiv: ah, oops.
<spiv> rusty: :)
<rusty> spiv: yeah... so I don't quite know how, but this seems to mess things up:
<rusty> orig_cmd = os.getenv('SSH_ORIGINAL_COMMAND', '?')
<rusty> if orig_cmd == 'bzr serve --inet --directory=/ --allow-writes':
<rusty>     os.execlp('bzr', 'bzr', 'serve', '--inet', '--directory=' + sys.argv[1], '--allow-writes')
<rusty> (I use the authorized_keys file to redirect them to run the script, based on hg-ssh)
<spiv> Hmm.
<rusty> spiv: sys.argv[1] is "/home/ccan".  It's annoying that bzr serve wants to serve the entire world, but this at least restricts it to writing in the ccan home dir.
<rusty> spiv: I *really* don't want to grant full ssh access just so people can commit to repo :(
<sohail> hmm... After importing my git repo to bzr, the packed bzr is twice as large as the gc'ed git
<sohail> how can I find out what's wrong?
<spiv> What's argv[1]? -- ah, I look away for a second and you've already told me :)
<luks> sohail: you have probably lots of junk under .bzr/repository/obsolete-packs
<sohail> luks, what is that?
<sohail> luks, indeed, half of the whole repo is contained here..
<luks> packs that were used before you ran `bzr pack`
<AfC> sohail: or, bzr may be storing more {meta,indexing,etc} data, so it's possible that "nothing" is wrong. However, the Bazaar hackers have been working away quite heavily on some neat things that dramatically reduce the size taken by revision data on disk, which is pretty cool.
<luks> those are useless now
<sohail> luks, ah
<luks> you can delete them, but I should add that the official answer is to not touch .bzr :)
<spiv> rusty: off the top of my head, that script sounds fine to me.  I'll see if I can reproduce some weirdness locally.
<sohail> luks, :-) I can leave it for now I guess
<AfC> luks: it's like the _next_ operation will auto-clean that for sohail, right?
<luks> sohail: nah, you really can delete them
<luks> AfC: the next packing will clean them
<AfC> yeah, I knew it was something l like that, modulo "things people have worked on that aren't released yet"
<spiv> rusty: oh,
<rusty> spiv: mailing appropriate bits now...
<spiv> rusty: what's the bzr+ssh:// URL you were using?
<sohail> luks, ok I'll do it
<spiv> rusty: with that script, you'll need just bzr+ssh://server/repo, not bzr+ssh://server/home/ccan/repo
<AfC> luks: (or sohail could just run `bzr pack` manually, right?)
<luks> AfC: yep
<sohail> well now it is less than git
<sohail> so good for you :-)
<sohail> although maybe git has the same problem
<luks> but of course, in both cases he he will have new ones there :)
<sohail> "problem"
<luks> sohail: I don't think git backups the old packs
<AfC> "problem". Doing apples and apples comparisons is hard, as different systems do different things at different points in the lifecycle. That said, I'm pretty excited about the compression work that's being done, because that will reduce amount-over-the-wire network pressure, etc
<sohail> luks, then bzr wins :-)
<luks> you could always tweak git to win
<luks> with long delta window, etc.
<rusty> spiv: Ah, that works!
<rusty> spiv: now, why didn't I get an error when I got the url wrong?
<spiv> rusty: the --directory= arg causes the bzr server to treat all paths from the client as relative to that directory (and doesn't let the client break out of that directory)
<spiv> rusty: I'm not sure why you didn't get an error
<spiv> rusty: presumably there's a /home/ccan/home/ccan/repo somehow!
<rusty> spiv: err... yeah :)
 * AfC tries to figure out exactly what script+ssh{,d} config rusty is using as he'd like to cloak actual paths as well
<rusty> spiv: and it has a .bzr dir in it...
<spiv> rusty: I'm betting "bzr revno /home/ccan/home/ccan/repo" on the server reports "51", too.
<AfC> Also, fwiw, Rusty, you might want to try running a newer version of Bazaar as your client if possible; I mean, 1.3.x will work, sure, but the bug fix and better performance factor between that and 1.5 has [subjectively] been impressive. As will be the case to 1.6 when it stabilizes.
<AfC> IANABH
<rusty> spiv: OK, so it's a symlink to my web dir... which means that repo is being rsynced across from my machine by my scripts... digging :)
<markh> is there a later version of the svn plugin that 0.4.10?
<rusty> spiv: sorry for the confusion.  Looks like I've creatively mixed my old and new setups, and got distracted halfway through.  but it mostly "just worked" until someone *else* pushed a rev :)
<poolie> hi rusty, afc
<rusty> poolie: hi!
<AfC> poolie: yo Martin
<spiv> markh: not released.  The development branch has a heap of changes since 0.4.10, but I don't think jelmer considers it stable enough for a release yet.
<spiv> rusty: ah, right :)
<markh> but 0.4.10 is complaining it is too old for the bzr version :)
<rusty> spiv: quite an impressive knot I created here.  Thanks for the injection of clue :)
<markh> maybe its misleading me and its actually the pysvn bindings that are too new
<spiv> rusty: not a problem
<rusty> AfC: can publish script, but real python hacker would do better.  Problem is that bzr doesn't say what repo it wants to access on the cmdline :(
<AfC> rusty: yeah, I know. Running `bzr serve` as a [read only] daemon was no problem; we serve up URLs like bzr://research.operationaldynamics.com/bzr/java-gnome/mainline/ too easy.
<AfC> rusty: But pushing to that ATM is bzr+ssh://epsilon.dal.operationaldynamics.com/export/web/com/operationaldynamics/research/bzr/java-gnome/mainline/ I mean, kill me now
<AfC> rusty: if you don't want to post publicly, I would be more than honoured to receive an email from one so respected :)
<rusty> AfC: sent
<rusty> AfC: with hg-ssh you can specify what repos to allow access to in .authorized_keys.  This one only allows you to restrict them to a particualr subdir.
<spiv> AfC: here's a quick thing I just made based on the snippet rusty pasted earlier: http://rafb.net/p/eHQs9285.html
<spiv> (Hmm, you probably don't want the --no-plugins bit, that was just to help me test it)
<cjwatson> lifeless: thanks
<AfC> Lookin'
<spiv> AfC: there's a fancier bzr_access script in the contrib/ directory in bzr itself, I think it can do that too.
<rusty> spiv: and humpty is back together again http://ccan.ozlabs.org/repo/
<spiv> Hurrah!
<jamesh> rusty: you might want to run "bzr whoami" to set your committer ID
<rusty> jamesh: thanks... is that permenant, per-repo or what?
<jamesh> rusty: it will store your committer ID in ~/.bazaar/bazaar.conf
<rusty> jamesh: ah found it.  Thanks.
<spiv> rusty: it's permanent, but you can have per-location ones by editing ~/.bazaar/locations.conf
<jamesh> it is possible to specify different committer IDs for different branches (or trees of branches), but that is a little more involved
<rusty> jamesh, spiv: thanks, I'm happy to have one non-sucky one for the moment :)
<jamesh> e.g. if you segregate work branches into a particular location, you can get bzr to use a work email for them while using a personal email for everything else
<markh> anyone know off-hand how I can have bzr ignore pycurl certificate errors - eg, like "curl -k ..."?
<sohail> hey, when bzr says: "N files ignored" how can you find out which files were ignored?
<luks> bzr ignored
<sohail> thanks :-)
<sohail> ah great, its ignoring the object files. :-)
<sohail> this is strange
<sohail> bzr clone /path/to/foo ... bzr commit ... bzr push => Error: Need to specify location?
<luks> it doesn't know where to push
<sohail> but I cloned it from /path/to/foo
<sohail> why didn't it remember that?
<bob2> it doesn't default to the parent for push
<bob2> just pull
<sohail> but... why
<bob2> often that isn't waht you want
<poolie> sohail: because you'd often be starting work on a new feature
<luks> because it doesn't mean you want to push there
<sohail> confusing...
<bob2> e.g. if you have a local mirror of 'trunk', and branch from that, you probably want to push to the remote 'trunk' or something
<poolie> sohail: if you do --remember on the first push you'll only need to give it once
<sohail> well ok I haven't got to that point yet so I'll take your word on it
<luks> poolie: er, you don't need --remember
<sohail> must say that bzr is just about as fast as git (I was using git for the past month but got sick of it's silliness)
<sohail> and now I must go to bed
<sohail> night night!
<poolie> great, glad you like it
<kiorky> jamesh: rah, its annoying that i cant not branch locally without reaching the svn server :/
<jamesh> did you mean jelmer then?
<kiorky> jamesh: yes, sorry for the noise
 * mwhudson bounces about http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48855B28.3070505@canonical.com%3E a bit
<jelmer> kiorky: can you try branching while you don't have a network connection and run with BZR_PDB=1 set?
<jelmer> kiorky: that should get you into a debugger
<jdobrien> larstiq: I pushed 3 blackbox tests for #30159 last night. https://code.launchpad.net/~jdobrien/bzr/bug30159
<LarstiQ> jdobrien: thanks
<yacc_> Any idea how to release a remote lock?
<andrea-bs> yacc_: bzr break-lock
<yacc_> thx
<kiorky> jelmer: BZR_PDB asan env. variable isnt it ?
<james_w> kiorky: yup, it will drop you in to a debugger on exceptions
<kiorky> jelmer_: https://bugs.launchpad.net/bzr-svn/+bug/250706/comments/4
<ubottu> Launchpad bug 250706 in bzr-svn "branching locally tries to reach forward svn server" [Undecided,Incomplete]
<kiorky> jelmer_: i gave you the backtrace yet, i will be happy to hack on it, but for now i cant :p
<kiorky> jelmer_: just for you to see if there is not an obious bug
<kiorky> *obvious
<Odd_Bloke> thumper: My sleeping patterns are just weird ATM, not really intentionally so. :)
<gnomefreak> how would i fix this Unable to obtain lock file:///home/gnomefreak/tbird-3.0/work/thunderbird-3.0.head/.bzr/repository/lock held by gnomefreak@ubuntu.com on host Development [process #15954]
<luks> we should have a bot that auto-replies "bzr break-lock" to anything with "lock" in it :)
<pygi> or just make bzr run that automatically :p
<gnomefreak> ah thanks ill try it
<gnomefreak> thanks it worked great
<gnomefreak> it would be nice if it sees that its locked to give you the choice to break the lock ;)
<james_w> I think the message might have been tweaked to suggest that now.
<beuno> it was, in 1.5 IIRC. It now tells you how to unlock it
<james_w> hi beuno
<gnomefreak> it doesnt here
<gnomefreak> 1.5-1
<beuno> evening james_w
<beuno> hmmmm...
<beuno> http://bundlebuggy.aaronbentley.com/request/%3C2422be180805201918p5baf7b5fq1c10ea8b300adfbe%40mail.gmail.com%3E
<beuno> it was merged in May
<gnomefreak> http://pastebin.mozilla.org/497775 is all i got
<gnomefreak> waited close to a minute than finally hit cntl+c
<gnomefreak> ctrl
<luks> there was no release since then, it will be in 1.6
<beuno> ah, time sure flies by...
<luks> nope, it's just that bzr releases are slowing down :)
<gnomefreak> oh so it missed 1.5
<steltho> I am trying to pull from a remote branch, and I am getting this error message:
<steltho> bzr: ERROR: Invalid http response for http://bzr.savannah.gnu.org/r/gnash/.bzr/repository/indices/2c779c251220f8afce08bcec69277e32.rix: Expected a boundary ("/E9'NLJ'Cd-jBKfDwKZv", application/plain) line, got '--/E9'NLJ'Cd-jBKfDwKZv
<steltho> anyone have any idea what might be causing this
<Peng_> steltho: What version of Bazaar?
<Peng_> steltho: I'm pretty sure this was fixed recently.
<steltho> 1.1.0
<meatballhat> what's the right way to specify a merge from a branch without a common ancestor (if possible)?
<Peng_> steltho: That's kind of old, and this was within the last couple months.
<Peng_> Hmm, the Savannah thing I was thinking of might be a different issue.
<jelmer> kiorky, still there?
<kiorky> jelmer: yep but at work
<jelmer> kiorky, does foo/.svn exist?
<kiorky> fog: jelmer LC_ALL=C ls bzrsvn/messaging/.svn friendArchives/messaging/.svn
<kiorky> ls: cannot access bzrsvn/messaging/.svn: No such file or directory
<kiorky> ls: cannot access friendArchives/messaging/.svn: No such file or directory
<kiorky> jelmer: :)
<kiorky> jelmer: http://www.friendpaste.com/8tMhhdet
<jelmer> kiorky, does "svn info foo" return anything?
<kiorky> jelmer: nope neither in the locally branched one
<jelmer> kiorky: You run:
<jelmer> >rm -rf foo;bzr branch  foo bar
<jelmer> "bzr branch" assumes foo already exists locally
<jelmer> does "bzr info" in the parent directory do anything?
<kiorky> jelmer: you mean in foo/..  ?
<jelmer> kiorky: No, in the directory above foo/
<kiorky> jelmer: so in foo/?
<jelmer> kiorky: no, in the parent directory of foo
<jelmer> kiorky, you seem to be running "bzr branch" on a directory foo that doesn't exist
<jelmer> since you remove it before you use it
<kiorky> jelmer: http://www.friendpaste.com/c6vWEJ5F and http://www.friendpaste.com/DwVJQ4KC
<kiorky> jelmer: foo exists !
<kiorky> jelmer: im not a fool :p
<jelmer> kiorky, in your paste http://launchpadlibrarian.net/16253623/trace
<jelmer> kiorky, you run ">rm -rf foo;bzr branch  foo bar"
<kiorky> jelmer: no i just replaced some content to hide the real folders
<kiorky> jelmer: i rm -rf bar
<kiorky> jelmer: not foo, sorry.
<jelmer> kiorky: This is happening because one of the the ancestor directories of foo and bar contains some svn working copy
<kiorky> jelmer: uhm, how can it be possible
<jelmer> maybe not /somewhere but one of the parents of somewhere
<kiorky> yep
<kiorky> on one parent more
<kiorky> but there is an ancestor common to the twice branches without any bzr or svn metadata directories
<jelmer> that doesn't matter
<jelmer> it'll browse down to the root of the fs
<kiorky> the branches are in /myproject/repos/bzrsvn/foo /myproject/repos/feature/bar, /myproject/repos has nither .svn or .bzr but /myproject/ has an ".svn"
<kiorky> jelmer: why ?
<jelmer> kiorky: What version of bzr-svn is this? I did fix something related to this earlier
<kiorky> jelmer: i gave you the versions on the bug report
<kiorky> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/250706 :)
<ubottu> Launchpad bug 250706 in bzr-svn "branching locally tries to reach forward svn server" [Undecided,Incomplete]
<kiorky> jelmer: basicly a few day earlier co
<jelmer> kiorky: I'll see if I can make it only create the remote connection a bit more lazily
<Peng_> Is bzr-svn supposed to break existing branches in the most horrible ways at the moment?
<Peng_> s/supposed/expected/
<LarstiQ> Peng_: ah yes, that combination of commit message and change :)
<Peng_> ?
<LarstiQ> Peng_: bzr log -r 1495; bzr diff -c 1495
<Peng_> Yeah
<Peng_> Are there any current issues?
<jelmer> Peng: yes, the 0.4 is an unstable branch
<Peng_> Uh-ohs.
<jelmer> Peng: It always has been this way, I've just clarified the warning a bit
<Peng_> Yeah, I know, but usually it's mostly working right.
<jelmer> since some people seemed to interpret "output can change" as the console output rather than the revisions outputted
<jelmer> yeah, it should still work well in most cases
<jelmer> nothing has changed there
<Peng_> Okay.
<VSpike> I'm trying to push a branch up to a directory I created on my main repository, using bzr push --use-existing-dir .. The repo is on a linux box, shared using Samba, mounted on a Vista machine which is running the Cygwin version of bzr (1.4).
<VSpike> I'm getting an odd error: bzr: ERROR: Could not acquire lock "[Errno 13] Permission denied"
<VSpike> /usr/lib/python2.5/site-packages/bzrlib/lock.py:79: UserWarning: lock on <open file u'/cygdrive/r/website/thurayalocate/web/.bzr/checkout/dirstate', mode 'rb' at 0x1329ad0> not released
<VSpike>  warn("lock on %r not released" % self.f)
<VSpike> Any ideas?
<matkor> does samba shares support file locks ?
<VSpike> Yes, AFAIK
<VSpike> I guess I have a bit of a mix of technologies going on here, but normally it all works really well :) Amazingly enough
<VSpike> Can't get sftp working on windows but smb does me OK
<matkor> IIRC I had similar prolbem with glusterfs ... and I had to enable posix locks which might be different than file locks used in samba
<VSpike> I can merge, push, pull, checkout to this repo normally from the vista machine
<VSpike> It seems to be pushing to an empty dir that is breaking
<VSpike> Does that use locks differently somehow?
<matkor> I am not expert but I was surprised that there are many types of locks
<matkor> I have to go, so goog luck with solving issue
<matkor> good
<vimes656> is bzr cp available in the latest version of bzr?
<jelmer> vimes656: I don't think there is such a command
<vimes656> jelmer: how can I copy a file keeping the revision history of the original file?
<jelmer> vimes656, there's no way to do that at the moment
<jjcroftiv> hello, i am new to bazaar and I am trying to find out how to create an external dependency like subversion externals, TIA
<jelmer> jjcroftiv, there's an experimental feature called "nested trees" that does something similar
<jelmer> abentley, thanks for the pqm updates
<abentley> jelmer: np
<jelmer> kiorky, I've pushed a fix - any chance you can verify it works?
<mgedmin> shouldn't bzr get lp:lxml show some progress indication?
<mgedmin> all I get is a long silent delay and then "Branched 2661 revision(s)."
<mgedmin> bzr 1.5
<mgedmin> this is nice and Unix-y, but I seem to recall progress bars in earlier versions?
<jjcroftiv> jelmer, do you have any info on where the "nested trees" feature is documented
<jelmer> jjcroftiv, I don't think it's very well documented yet since it's an experimental feature
<vimes656> jjcroftiv: if you know how to use zc.buildout you can use gf.recipe.bzr
<vimes656> I'm using it for a project and works quite well
<vimes656> http://pypi.python.org/pypi/gf.recipe.bzr/1.0dev-20080117
<jjcroftiv> vimes656, thanks for the link, i'm going to check it out
<jjcroftiv> no pun intended
<dash> Hi. bzrlib question --
<dash> i'm calling branch.create_checkout(). it takes an accelerator_tree argument; can it be a tree other than one associated with that branch?
<dash> say i've got branchA and branchB in a remote repository and I have a local checkout of branchA. can I use the tree from branchA as an accelerator_tree for checking out branchB?
<dash> man. wish that 'integrating with bzr' doc showed some stuff about merges :)
<james_w> dash: I believe you can. It will become less efficient the further the contents of the accelerator tree are away from the requested tree.
<dash> Sure.
<james_w> what problems are you having with merges?
<dash> james_w: figuring out how to do them :)
<dash> i'm reading builtins.cmd_merge
<dash> but there's a lot of it
<james_w> yeah, it's a problem that there is too much logic in some of the cmd classes
<dash> it's way better than some tools i've worked with... :)
<LarstiQ> with or on?
<dash> sure.
<LarstiQ> dash: gah :P
<chombee> Hey -- following the centralised lock-step workflow, I create a local repo and commit some stuff then do bzr push to push it to a central a location. At the central location I get a repo with no working tree. Is it safe to do bzr checkout on the central repo to get a working tree? Or must it remain bare as in git?
<dash> yes, you can checkout with no problem
<fullermd> The only gotcha is that future 'push's won't update that tree, so you'll have to remember to do it by hand.
<chombee> Next question, after the push the local repo seems to be a branch rather than a checkout of the remote repo. I guess I want do bind the local repo to the remote one, so I can do bzr updates?
<chombee> fullermd Yeah, isn't it safer to have a central repo with no tree, so no one gets confused?
<dash> chombee: possibly so
<fullermd> Well, depends on why you want the tree there.
<dash> but there's also this: https://launchpad.net/bzr-push-and-update
<dash> (perfect for developmenstuction environments)
<jam> dash: for merge, you probably just want "WT.merge_from_branch"
<jam> at least that is what I use 99% of the time
<dash> jam: hm!
 * dash looks at the docs
<jam> dash: The complexity in cmd_merge is because you can supply a bundle, or a working tree, or a file within a working tree, or a branch, or ....
<dash> jam: looks like that's exactly what I need, thanks
<dash> jam: Right
<jam> but for most people, they just want to merge a branch
<dash> yeah, i'm specifically just merging a branch in this case.
<chombee> With a centralised, offline workflow is it possible to use bzr as you would use git? i.e. bzr commit does a local commit, bzr push pushes local commits to a central repo, and bzr pull brings commits from the central repo into a local repo? Is it better to use the different centralised with offline commits workflow from the bzr manual?
<beuno> chombee, you can work exactly like that with bzr
<beuno> you just need to branch instead of checkout
<chombee> Hmm, so you can, cool.
<dash> oh, great
<dash> I can't use merge_from_branch because I need to be able to do the equivalent of "merge --force"
<dash> guess i'll do it the long way :)
<chombee> By default git makes a crypto hash of each revision, so it can tell me if any file corruption has happened in a repo. Can bzr do that, so I know my content is safe?
<luks> chombee: bzr does that too, but it's not visible
<fullermd> It stores a hash.  That protects you from incompetence, though not from malice.
<fullermd> For the latter, there's PGP signing of revs.
<chombee> Hmm
<chombee> So say some corruption occurred ina repo, would bzr notify me the next time I ran some bzr command on that repo?
<chombee> fullermd it's disk faults isn't it, rather than incompetence?
<fullermd> Well, hardware can be incompetent   :)
<fullermd> ('can be'...  ha.  I'm so diplomatic...)
<chombee> :)
<fullermd> Well, it certainly wouldn't catch it before the next time it has to grab that particular data for something.
<fullermd> 'check' will preen the whole thing.
<chombee> So if I do bzr check and it's okay then there's no corruption in the repo? Looks that way
 * fullermd nods.
<fullermd> (mod bugs in check of course, but you have to trust something)
<chombee> Cool, I like it btter than git, it just makes it easier to do the same thing
<chombee> Thanks
<kiorky> jelmer: i ll try it on the evening or tomorrow at least, doctour house time. Ill poke you as soon at it is done
<mgedmin> launchpad can currently import (some) svn and cvs repositories into bzr branches
<mgedmin> any chances for importing git repositories?
<Peng_> bzr-fastimport might be able to import git.
<fullermd> AIUI, it can.  But fast-import doesn't handle incremental stuff.
<fullermd> And of course you can't get move info from git...
<dash> can you from cvs or svn?
<fullermd> So, you can convert with it.  But LP does ongoing imports.
<Peng_> fast-import doesn't support incremental imports? Huh
<fullermd> I don't think so, no.
<fullermd> (based on vague recollections of discussions of course; igc would have a much more authoritative answer)
<lifeless> abentley: what is previewtree capable of?
<lifeless> abentley: and how efficient is it?
<abentley> lifeless: Right now, it's capable of being the source of a diff, but it should be able to represent any working tree state.
<lifeless> abentley: I'm thinking about implementation strategies for tree marks
<abentley> lifeless: It's not written for efficiency, but I want to find out what parts are bad, and fix those first.
<abentley> The goal so far has been to make it fully conform to the Tree interface and get it under test.
<abentley> lifeless: Tree marks are the sort of thing I'd like to see it become good at.
<lifeless> so for marks I need a tree that:
<lifeless>  - when reverted reverts the underlying working tree content, but only for the content the marks selected
<lifeless>  - does not slow commit down at all for the common case (where / is marked 'selected')
<lifeless>  - can 'remove' changes from the working tree where they do not meet the marks the tree is parameterised with
<lifeless> separately from that I need to figure out how to manage the marks data
<abentley> wrt revert: A preview tree is "written" to using its TreeTransform.  So this sounds like something that belongs in the revert code, not a characteristic of a PreviewTree.
<abentley> I would expect that commit of a PreviewTree is slower than WorkingTree in the common case.
<lifeless> abentley: or perhaps previewtree doesn't fit marks? the tree object used when marks are in use probably wants to be a proxy object
<lifeless> in that it wants to lazily calculate things and return them as asked for: precalculating all the differences could be arbitrarily large
<kiorky> jelmer: which branch? because pull gave me no revision update
<abentley> A PreviewTree can have arbitrary changes applied to it, so 'removing' particular changes is not a problem.
<kiorky> jelmer: i use : http://people.samba.org/bzr/jelmer/bzr-svn/trunk/
<jelmer> kiorky, the 0.4 branch
<abentley> lifeless: The way to use "marks" with a PreviewTree is probably to start with the PreviewTree as an unchanged version of the basis tree.
<jam> Peng_, fullermd: fast-import *does* support incremental conversions, by writing down whatever mapping it has performed so far
<kiorky> jelmer: is this safe to use on existing stuff with the version i have ?
<jam> I don't think it allows you to generate a "partial stream"
<kiorky> jelmer: i have pending work ^^
<abentley> Then as marks are added, the Transform is manipulated to apply the changes.
<jam> And I wouldn't ever count on an incremental conversion from CVS
<jam> because borking history is fairly standard practice there
<jelmer> kiorky, I would recommend only using released versions for production work
<salgado> hey, if I have an uncommitted merge, can I generated a bundle out of it?
<salgado> s/generated/generate
<abentley> salgado: No.  A bundle contains committed changes by definition.
<fullermd> Huh.  Learn something new every day...
<jam> lifeless: any luck with 'freeze' ?
<lifeless> jam: 2 seconds faster for st on bzr.dev with cold cache
<lifeless> 13 -> 11
<lifeless> no significant change in hot cache
<salgado> abentley, right.  how would I go about turning that into a bundle after I commit it?
<kiorky> jelmer: someone told me to take bzr.dev and bzr-svn.trunk to have goof svn integration and not much risks
<kiorky> jelmer: lifeless maybe if i remember well
<jam> lifeless: sounds about right for the time to load the python libs
<kiorky> jelmer: but i can afford bugs :), i just want to limit them and not shoot in my feet :)
<abentley> salgado: "bzr send"
<jelmer> kiorky, generally the 0.4 branch works pretty well. It may in rare cases break imports though
<lifeless> jam: consistently lower system time - about 0.03 seconds less
<abentley> salgado: That actually produces a merge directive, which is what people usually mean by "bundle".
<jam> lifeless: well, 30ms isn't 0, but not a lot to write home about
<kiorky> jelmer: OK
<lifeless> jam: its the cold cache I'm more interested in TBH
<kiorky> jelmer: so no backward risks with the bzr.trunk?
<kiorky> jelmer: no migration stuff or any other thbings ?
<jam> lifeless: so instead we should just write a background process that keeps things out of cold cache, right?
<jam> :)
<lifeless> jam: thwack
<jelmer> kiorky, it's definitely more risky than using a release
<kiorky> jelmer: i can co, replace and run directly bzr pull in my branches ?
<jam> lifeless: well, 'bzr service' comes to mind
<salgado> abentley, but it still contains the actual code changes that I could apply to a branch, right?
<lifeless> jam: it doesn't improve the cold cache case
<jelmer> kiorky, what do you mean with bzr.trunk?
<kiorky> jelmer: well i will tarball my stuff, time to test ^^ enought talk
<jam> lifeless: depends when you are measuring
<jam> as it keeps everything in mem
<lifeless> jam: OTOH the frozen bzr is 7.7MB :(
<jam> if you drop caches after starting it
<lifeless> jam: power on
<kiorky> jelmer: bzr.dev and bzr-svn.trunk
<abentley> salgado: Yes, it specifies the particular merge that would apply those changes to a branch, and includes all the necessary revision data in a bundle.
<lifeless> jam: first-use by a new user
<jelmer> kiorky, you really don't want bzr-svn.trunk but bzr-svn 0.4
<lifeless> jam: etc
<jelmer> kiorky, trunk is just more outdated than 0.4
<kiorky> jelmer: ok, good to know
<kiorky> jelmer: its branching
<jam> lifeless: you just put the service startup in your .login file
<jam> so it just seems like 2s more boot time
<lifeless> jam: I hope you are trolling
<jam> I'm somewhat serious if you are *just* trying to solve the cold boot process
<jam> it is really only 1 time
<jam> and there are a lot easier ways to trick it
<lifeless> its not about tricking though
<lifeless> its about being genuinely lighter-weight
<jelmer> kiorky: bzr-svn you mean or that particular branch you were trying to copy?
<jam> lifeless: well 'time cbzr status' with the service running is <100ms, 'time bzr st' is 220ms with a hot cache.
<kiorky> jelmer: im branching and installing the 0.4 you told me about
<kiorky> jelmer: http://people.samba.org/bzr/jelmer/bzr-svn/0.4
<jam> I get down to 80ms for a bzr.dev tree
<lifeless> jam: http://rafb.net/p/taLkYP27.html
<lifeless> jam: so I'm not against a service per se; but git does not need one.
<lifeless> a service seems to have more race conditions, and more chance for bugs like skew on package upgrade
<salgado> abentley, coolio. works just like I wanted it to. :)
<lifeless> jam: even with my long list of plugins there is a big difference loading the frozen version
<jam> lifeless: http://rafb.net/p/MuVvT317.html
<jam> I don't strictly agree with a service model
<jam> I'm not very happy with it
<jam> for the reasons you describe
<jam> but it is hard to argue dropping from 400=>100ms, when I can get you to 6ms
<lifeless> jam: service also won't pickup plugin changes dynamically
<jam> lifeless: you could make ti
<lifeless> it will be prone to failure-to-test
<jam> make it do so
<lifeless> jam: not _very_ reliably - reload() has serious issues
<jam> and with inotify sort of thing, it could do so cheaply
<jam> lifeless: if it was serious, it could respawn itself
<lifeless> I dug into inotify
<lifeless> its horrible to work with
<jam> lifeless: sure, there are about 5 different wrappers, and I know "bos" was complaining about one of the python ones destroying his system when in use
<abentley> salgado: I'm glad.
<jam> so he wrote another
<lifeless> you can't listen recursively
<lifeless> its not the wrapper; its the kernel facility itself
<lifeless> you have to listen to everything individually
<lifeless> another issue with service is when the user hits ctrl-C it kills the client not the demon
<lifeless> so it's harder for them to model what is really happening
<jam> lifeless: anyway, I would love for us to get "lighter", and service as a plugin really does need a lot of overhaul
<lifeless> and if they login N times resource use will shoot up
<lifeless> and python with its cavalier memory management really concerns me
<jam> what I would *rather* see is better python support for loading pre-cached information
<jam> like "take a snapshot of where these exist, and re-use it on the next invocation"
<jam> anyway, I'm certainly interested in where you get to
<jam> Also, for 'bzr' being 7MB
<jam> after frozen
<jam> it is 9M in my /usr/lib/python
<jam> and 24 in my bzr.dev folder
<jam> I suppose 8.7M if you just count the .pyc files
<fullermd> % du -sh /usr/local/lib/python2.5/site-packages/bzrlib/
<fullermd>  25M    /usr/local/lib/python2.5/site-packages/bzrlib/
<fullermd> (bzrtools is under there too)
<jam> bzrtools is pretty small
<jam> I think mine is smaller because it uses symlinks to pycentral
<fullermd> Just under a meg.
<lifeless> its about 30ms functional difference
<lifeless> plugins cost me about 150ms to load
<fullermd> bzrlib in my bzr.dev is ~12 meg.
<fullermd> The difference is the .pyo's I presume.
<lifeless> well
<lifeless> Ubuntu/Debian don't create .pyo files.
<fullermd> I'm not sure they serve any purpose.  The time or two that I tried, I couldn't measure a perf difference...
<jam> Interestingly, I think if you don't create them at install time, then future "python -O" runs would actually be *slower*
<jam> fullermd: all it really does is remove asserts
<fullermd> (not that I tried particularly hard, but...)
<lifeless> jam: thats correct
<lifeless> jam: I spent some time last week pointing this out :)
<jam> lifeless: like, dramatically, because it is on-the-fly recompiling all the .py
<lifeless> jam: yes
<lifeless> jam: and there are python upstreams that recommend the use of -O
<jam> fullermd: actually, I would expect "python -OO" to be quite a bit smaller, but we don't support that mode
<jam> as we have a *lot* of doc-strings that would then be stripped
<jam> (but then none of your commands would have help text, either)
<fullermd> Heck, nobody ever reads the help, right?
<lifeless> sometimes I think that
<jam> fullermd: sure, but how can you tell them to RTFM if you stripped it from the installer
<jam> it at least needs to be there
<lifeless> jam: how well do you know the patience code?
<jam> lifeless: fairly well
<lifeless> I'm looking at a C groupcompressor
<lifeless> what I need is two things - a matching blocks list that is _not_ constrained to be strictly increasing, and
<lifeless> a left-side lines-hash that is persistent
<lifeless> I looked at the patience diff C code, and its seems possible to do this, but I'm not entirely sure it will fit well
<jam> lifeless: I think it would fit ok
<jam> add_matching_line will only work on the existing block or start a new one
<kiorky> jelmer: seems to work :)
<jam> but I think that is fine for what you need
<jelmer> kiorky, cool :-)
<lifeless> jam: have a look at rev 14 of lp:~lifeless/+junk/bzr-groupcompress
<kiorky> jelmer: you can mark your patch working for my test case, i hope you can merge it :)
<jam> lifeless: as you are only going to be generating blocks at a time, right?
<jelmer> kiorky, it's already merged
<jelmer> (0.4 is the main branch)
<lifeless> I've cleaned up the compression code to be slower-but-clearer in preparation for a C accelerator
<kiorky> jelmer: ha, very cool so
<lifeless> jam: not sure what you mean by blocks-at-a-time
<lifeless> jam: its basically, start with "" as output, then for each input text
<jam> lifeless: you will match a range from A=>B, and then might come back later to mark < A, but you won't try to *combine* that with the existing block
<lifeless> match(output, input); for section of input: if new: emit 'i', if reusable: emit 'c' unless 'i' is cheaper. hash(emitted) and extend output by emitted
<lifeless> oh, with the caveat that we *don't* hash output lines that we know are not new
<jam> lifeless: so do you compress within a single text?
<lifeless> no
<jam> lifeless: it seems like you could, by incrementally adding the lines, but I don't know if you would gain a lot
<mwhudson> morning
<jam> mwhudson: morning
<lifeless> jam: it would make it into a plain dictionary compressor; increase the lookup size a lot, and prevent the one-parse extraction I think
<lifeless> hi mwhudson
<mwhudson> (review my branch)
<mwhudson> (please)
<jam> mwhudson: which one would that be?
<mwhudson> jam: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48855B28.3070505@canonical.com%3E
<jam> mwhudson: well, the instant review is bb:resubmit
<jam> Pending some time to actually fully review :)
<mwhudson> jam: heh
<mwhudson> it's the last fix we (know we) need in bzr to get stacking working on launchpad
<jam> mwhudson: well, a quick statement is that you should be raising "TestNotApplicable" rather than just returning
<jam> anyone have an idea how you make a window transparent in compiz? I just did it by accident and  Iwant it opaque again
<mwhudson> jam: just returning is what the other tests in the file do, want me to change them too?
<mwhudson> jam: ctrl-mousewheel, i think
<mwhudson> certainly <some modifier>-mousewheel
<jam> well, ctr+mousewheel in FF changes the font size
<jam> but alt+wheel did it
<jam> compiz and my trackpad don't get along very well
<mwhudson> that sounds familiar
<jam> The default to scroll to another window when you wheel on an edge
<jam> was really bad
<jam> because mousing to the edge of the trackpad
<jam> would give a couple scroll clicks
 * fullermd takes pleasure in avoiding both compiz and trackpads...
<jam> I'm having a hard time deciding if this is a troll or genuine: https://answers.launchpad.net/bzr/+question/40059
<beuno> jam, I'm not answering anymore, that's for sure
<beuno> Odd_Bloke did go to great lengths to answer
<jam> mwhudson: I would do consistency first, but I thought that TestNotApplicable was the "correct" way
<beuno> give 'em a URL, if they don't go away, tag him as a troll
<jam> I haven't dug deeply into the stacked stuff, but what you did looks right IMO
<lifeless> jam: what is the value of a line in a in patience sort?
<mwhudson> jam: looks like /most/ of the tests raise TestNotApplicable
<mwhudson> jam: so i'll fix the others
<lifeless> jam: is it the index of the line? if so how do you choose /which/ index to use?
<jam> lifeless: are you talking the C or Py code?
<jam> they differ, IIRC
<lifeless> C
<lifeless> well, to get the same result they can't really? :)
<jam> at least at a minimum C maintains the hashes
<jam> so in the C code, a 'line' is effectively a chain of matching lines
<jam> and "matching_line" the structure is the indexes
<lifeless> hmmm
<lifeless> I need to persist some of these structures
<lifeless> blah!
<jam> ?
<lifeless> as output is immutable, recalculating the hashes is O(N^2) times the cost of setting up the hash
<lifeless> no O needed there - there is a N^2 overhead in not reusing the hash
<lifeless> so I need to figure out the C api for exposing these things as python objects that can be reused
<jam> mwhudson: So, it looks good to *me*, but I would rather someone like poolie or lifeless who actually worked more closely on the stacking code to approve it
<mwhudson> jam: ok, thanks
<jam> lifeless: I can work out some quick pyrex magic
<jam> it isn't hard
<lifeless> jam: in a separate file you mean?
<lifeless> I can do that too ;)
<jam> lifeless: no, I mean I've done pyrex to do the wrapping, and I can check its output
<lifeless> jam: _patiencediff_c is a C source, not a pyrex source. I am confused about what you mean.
<jam> lifeless: in my walkdirs code, I export a C structure => PyObject
<jam> using Pyrex to generate the right C code to do so
<jam> we can crib fromthat
<jam> I just have to update my bzr.dev first
<scode> I have a repos with very little activity that i've been pushing to with bzr+ssh. Suddenly I notice that when trying to freshly branch, I get: bzr: ERROR: Error in data for index <bzrlib.index.GraphIndex object at 0x804fcd350>.
<scode> Any particular common cause for this, or have I encountered a bug?
<lifeless> jam: I get that; I thought your walkdirs was Pyrex based though? So pyrex is taking care of the headaches/updates/etc
<jam> lifeless: right
<jam> But it actually turns out to be relatively simple
<jam> (the part I like most about pyrex is the exception handling goodness)
<scode> Important "detail": Oh right, branching locally works. This only happens when branch:ing over http.
<jam> like getting a stack-trace into the pyrex code
<lifeless> scode: sounds like a bug, or some interfering proxy
<lifeless> scode: please do file  abug; the full backtrace from ~/.bzr.log is a good start
<scode> lifeless: No proxie, and I don't see 404:s or similar in the web server log excep tthsoe that I believe are expected
<scode> lifeless: Ok. Will do, either tonight or tomorrow.
<lifeless> scode: if you can give us the url to the branch that will help debugging
<scode> lifeless: http://bzr.scode.org/repo/pkgmanager-portssupport (I'll include in bug report)
<jam> lifeless: http://rafb.net/p/e3rzPV87.html
<lifeless> scode: no proxy at all? are you not going to the interwebs ? :) [ISP's often have 'transparent' proxies]
<scode> lifeless: Firstly, my ISP is sane :) Secondly, it happens with a local http branch from the same host.
<lifeless> scode: ok
<scode> lifeless: And I definitely don't have transparent proxying on my machine.:)
<jam> {"name", T_INT, offsetof(struct, member), READONLY, 0}
<lifeless> scode: please throw up a bug then and we'll take it from there
<jam> lifeless: ^- not too hard to repeat that a few times
<lifeless> jam: thats not the bit that I was going to have to look up
<scode> lifeless: Thanks. Will do - like I said either in a bit, or tomorrow. Thanks for confirming it seems unexpected.
<lifeless> jam: its the massive class definition and __init__ etc
<jam> lifeless: sure
<jam> though you can also do that in a separate pyrex definition
<jam> lifeless: I understand your concern, though, and I do like pyrex for that stuff
<lifeless> how do you feel about us making _patiencedif_c a pyx file?
<lifeless> seems to me its not exactly pure C and usable from C today
<lifeless> mwhudson: bzrdir's aren't stacked
<lifeless> mwhudson: branches are
<lifeless> mwhudson: your docstring confuses me
<mwhudson> Create a branch that is stacked on some other branch and return its bzrdir.
<mwhudson> ?
<lifeless> mwhudson: the change to TestNotApplicable is wrong in this case
<lifeless> +        """Create a bzrdir that is stacked on some other bzrdir.
<lifeless> well, I say wrong; I guess I mean 'I did not want the stacking tests to produce lots of irrelevant output'
<mwhudson> lifeless: ok, so test_stacking is inconsistent about this in bzr.dev
<lifeless> I've approved
<lifeless> but the docstring really needs more love
<lifeless> (its test only code, but still)
<mwhudson> lifeless: did you seem my suggestion for it above?
<mwhudson> lifeless: thanks though
<lifeless> mwhudson: that works better yes
<mwhudson> grr, too long though
<lifeless> """Gimme the bzr dir of a newly stacked branch, bitch."""
<mwhudson> i guess "Create a stacked branch and return its bzrdir." gets the point across
 * mwhudson gets ready to send yet another bundle
<lifeless> mwhudson: JFDI at this point
<mwhudson> lifeless: still needs another approve
<lifeless> mwhudson: jam gave one
<lifeless> jam: did you see my question about making the patiencediff file pyrex?
<mwhudson> lifeless: oh, then can someone grab http://people.ubuntu.com/~mwh/repos/bzr/bzrdir.clone-pass-on-stacking-base-bug-250418 (it has the better docstring in now) and send it to PQM?
<jelmer> lifeless, is it correct that "bzr branch --stacked" doesn't attempt to create a stacked format by default even if the repo it's being created in supports stacking?
<lifeless> jelmer: known defect
<lifeless> jelmer: poolie is about to post a branch to address it
<jelmer> lifeless, ok, I'll shut up then :-) Thanks
<lifeless> jelmer: oh hmm
<lifeless> jelmer: I misread
<lifeless> jelmer: do you mean 'the source branch and repo are stackable and the target repo exists and is stackable', so why doesn't --stacked work ?
<lifeless> or
<lifeless> jelmer: do you mean 'the source branch and repo are not stackable but the target repo exists and is stackable', so why doesn't --stacked work ?
<lifeless> the latter is what poolie is addressing
<jelmer> the source branch and repo are indeed not stackable (they're svn)
<lifeless> so yes, this is what poolie is addressing
<jelmer> awesome
<lifeless> his fix will need *your* review to say how bzr-svn will interact
<schierbeck> hi guys
<schierbeck> bug 238860
<ubottu> Launchpad bug 238860 in bzr-gtk "bzr visualise does not allow columns to be resized enough " [High,Confirmed] https://launchpad.net/bugs/238860
<schierbeck> sorry, just testing something
<jelmer> hey Daniel
<jelmer> lifeless, no problemo
<jam> lifeless: I would certainly consider it
<jam> sorry about the delay, had to pick up the baby
<lifeless> jam: no worries
<jam> I was thinking for group compress that you might be better off starting top-down into pyrex
<fullermd> Mmph.  Sucks when branches get big enough that check isn't practical anymore...
<jam> using _patience_diff.c as a crib sheet
<lifeless> beautiful: http://cgwalters.livejournal.com/17760.html
<lifeless> I _love_ the gcc wizard
<lifeless> jam: hmmm, I don't really want to rewrite $foo.
<lifeless> jam: I'm right now trying to decide if the patience sort we have is even correct :(
<jam> lifeless: well, it passes the test suite, though that certainly doesn't define "correctness"
<jam> lifeless: At least I've worked out how we know which line to match
<lifeless> jam: :P
<jam> which is that the hash-table buckets contain the head pointer and a "current" pointer
<jam> and that the equiv is only for identical strings
<jam> if you get a collision it walks to the next value (j = j + 1 & hsize)
<jam> lifeless: which sounds like it might mess up your groupcompress, as it doesn't want to match earlier than a line it has already matched.
<lifeless> yah
<lifeless> so AFAICT the value used for the patience sort is the line index in A
<lifeless> its the loop on line 306 that selects the index to use
<lifeless> and it skips lines that are duplicates
<lifeless> so patiencediff is looking more and more like 'really geared for humans' to me
<jam> lifeless: Yeah, the objects that are being *sorted* is the index in A which matches the line in B
<lifeless> jam: yup
<jam> and it is looking for the longest "interleaved" monotonically increasing sequence
<lifeless> interleaved ?
<jam> just that there may be gaps
<jam> where some lines matched earlier that we skip over
<jam> abcd bcad
<jam> will ignore the a matching to location 0
<jam> and give "bc_d" as the longest sequence
<lifeless> which I presume we then split to bc, d
<lifeless> ?
<jam> lifeless: correct
<jam> that is the "add_matching_line" code
<jam> which says "if this is the next in the sequence, add it to the block"
<jam> "else, start a new block"
<jam> lifeless: for "groupcompress" I don't quite understand "line_locations" has 2 sets with (N) and (N+1)
<lifeless> seems to me that a variant on recurse_matches should be doable
<lifeless> jam: its purely an optimisation
<lifeless> if you remember original sequence matcher, it does a loop lo:hi, trying each of the possible starting points
<jam> lifeless: so are you trying to find N possible matches as you move forward
<jam> and then just return whichever is the longest?
<lifeless> this has quite bad locality of reference, so I turned the loop into a set operation
<lifeless> starting will all the common points of a given line, and then advancing (transforming set(positions) into set(pos + 1 for pos in positions) each time)
<jam> lifeless: and doing the intersection so you only include matching lines
<lifeless> I found that precalculating the first step of this acts as a cache that saves enough steps (the first intersections removes a lot)
<lifeless> something like 3-4% performance difference, not radical but worth keeping until there is a _real fast_ version and then it can go to be a cleanest-possible reference version
<jam> lifeless: so if you were removing that
<jam> line 174 would change from:
<jam> sorry, looking at the wrong spot
<jam> you would change the line 185 to
<jam> copy_ends = next
<jam> =>
<lifeless> copy_ends = next -> copy_ends = set(loc + 1 for loc in locations)
<jam> copy_ends = set([l+1 for l in locations])
<jam> and that is all the second set is giving you right now
<lifeless> right
<jam> lifeless: so, "unique_lcs" is exposed to python
<jam> if you wanted to play with it as a starting point
<jam> though it doesn't save the cached hash lookups
<jam> so it isn't strictly a win
<lifeless> yeah
<lifeless> however 10 times faster might be enough to compensate
<lifeless> though gc is hella-faster than python patiencediff
<jam> gc?
<lifeless> groupcompress
<jam> ah
<jam> sure
<lifeless> bad-names-for-the-win
<jam> python patiencediff doesn't cache any hashes either
<jam> lifeless: so what would you persist, the "loaded_lines" for the current text, which would then be updated as you output more lines?
<jam> and presumably the hashtable itself
<lifeless> yah
<lifeless> self.lines in the GroupCompress object
<lifeless> with any transformations needed to actually operate on it
<lifeless> though the more I look at this
<jam> so for self.lines, it is the output lines?
<jam> Including the control codes?
<lifeless> and self.line_locations
<lifeless> yes
<lifeless> though we don't include control codes in self.line_locations
<jam> lifeless: and something about lines that would have been copies but Insert was shorter?
<jam> lifeless: and you didn't finish you "more I look at this" statement
<jam> so, you are looking for an "absolute mininum" diff between any possible matching block, right? You don't care if the same block is referenced multiple times
<jam> lifeless: I would say the hashtable code with exact equivalences could be easily ported over, the rest doesn't seem like a very good match
<jam> honestly, the "patience" portion of the code is not its speed bonus
<jam> tracking the stacks is not particularly fast
<jam> and doesn't give you what you want
<jam> which is the longest possible match for this chunk
<jam> lifeless: Also, as a bit of a torture test for this, imagine a text made up of all the same line...
<jam> ['a\n']*10000
<jam> lifeless: are you still there?
<lifeless> jam: yes, sorry
<jam> np
<jam> we're all allowed to go AFK once in a while
<lifeless> jam: we want a minimal construction recipe for B
<lifeless> jam: we reference the basis by bytes, and include new content by a line count
<lifeless> jam: so you think its the hashtable stuff that makes patience fast?
<jam> lifeless: yeah, I do
<jam> I'm poking around with it now
<lifeless> It seems to me the patience stuff is a large part of the speed bonus as it reduces the order
<lifeless> mwhudson: your eagle is landed
<mwhudson> lifeless: i saw, thanks!
<mwhudson> now we just need to fix launchpad...
<thumper> lifeless: thanks
<thumper> mwhudson: was that the 3rd of 3?
<mwhudson> thumper: yup
<lifeless> we really need to include <content-to-fulltext> in fetch always I think
<lifeless> it will avoid so many future problems
<awmcclain> What's the easiest way, given an svn repo i have no control over, to create a local bzr repo from a revision?
<mwhudson> awmcclain: from a revision?
<lifeless> awmcclain: bzr log svn:// | less - find the revno you want; bzr branch -r revno svn://... local
<awmcclain> mwhudson: Well, say, from HEAD. I say "from a revision" since I don't have... ah!
<awmcclain> lifeless: Thank you.
<awmcclain> lifeless: Is that a feature since 1.4?
<awmcclain> hrm
<awmcclain> What's the apt command to update a single package?
<awmcclain> open
<awmcclain> ooepn
<awmcclain> ung
<awmcclain> oops
<awmcclain> wrong channel. just ignore me.
<jelmer> awmcclain: Actually, "bzr branch -rsvn:<REVNO> svn://foo" should work too
<awmcclain> jelmer: What if I'm just looking for HEAD, and the svn branch is hosted over http?
<jelmer> awmcclain, don't specify a revno, bzr branch defaults to HEAD
<awmcclain> jelmer: So, in 1.4rc1 it thinking I'm looking at a bzr branch (bzr: ERROR: Not a branch: "http://code.sixapart.com/svn/perlbal/trunk/"). Should I upgrade to 1.6?
<jelmer> awmcclain, try "svn+http://code...."
<awmcclain> jelmer: Great.
<awmcclain> "unsupported protocol"
<jelmer> in newer versions of bzr-svn, the svn+ bit should no longer be necessary
<jelmer> awmcclain, you probably don't have bzr-svn installed or your svn was built without http support
<awmcclain> jelmer: Checking. Perfect.
<jelmer> awmcclain: Is bzr-svn listed when you run "bzr plugins" ?
<poolie> hi
<awmcclain> jelmer: That's the problem. Oh! Yes. I remember, it uninstalled when I upgraded to 1.4
<mwhudson> hi poolie
<awmcclain> jelmer: Does the 1.6 server have commit hooks yet?
<jelmer> awmcclain, not afaik
<awmcclain> jelmer: Ok.
#bzr 2008-07-24
<spiv> It will run pre_change_branch_tip and post_change_branch_tip hooks if used by a 1.6 client.
<spiv> pre_change_branch_tip is probably what you'd want to use to replace a pre-commit hook from SVN, I think.
<spiv> I haven't quite landed the change to make it possible for pre_change_branch_tip to reject a change cleanly, but I ought to have that done this morning.
<awmcclain> jelmer: Ah yes! This is the problem. The requirements for the bzr-svn ubuntu package are broken: bzr-svn: Depends: bzr (< 0.91~) but 1.4rc1-1~bazaar1~feisty1 is to be installed
<jelmer> awmcclain, bzr-svn isn't maintained in the ppa at the moment
<awmcclain> :(
<igc> morning
<jelmer> it hopefully will starting 1.6 if I can get autoppa working
<awmcclain> jelmer: ooo, autoppa
<awmcclain> jelmer: I like the sound of that
<jelmer> 'morning Ian, Andrew, Martin
<awmcclain> jelmer: What's the best way of installing?
<jelmer> awmcclain, You should be able to grab the package from Debian sid
<awmcclain> for ubuntu? what's the sources entry?
<jelmer> awmcclain, You should be able to download it manually from the intrepid repo
<awmcclain> jelmer: 0.4.10? Will that work?
<jelmer> yeah, it should. I think the dependencies are all available from either the ppa or hardy
<awmcclain> Ok, so I'll install the dependency packages from the ppa
<mathiaz> Hi - is it possible to set the submit_to option on a bzr branch so that people branching don't have to specify the email address when using the bzr send command ?
<awmcclain> jelmer: Great. Works. Thank you!
<jelmer> mathiaz, yes - it's called child_submit_to
<mathiaz> jelmer: well - I'd like to set in the public branch so that contributors don't have to do it themselves.
<jelmer> mathiaz, yes, that's exactly what child_submit_to is
<mathiaz> jelmer: gotcha - and how do I do that ?
<jelmer> submit_to is retrieved from the local branch
<jelmer> child_submit_to is retrieved from the submit branch
<jelmer> mathiaz, set child_submit_to in the .bzr/branch/branch.conf of the main branch
<mathiaz> jelmer: great - thanks :)
<igc> fullermd, Peng_: fastimport does have some limited support for incremental mirroring
<mathiaz> jelmer: but that will be pushed to the public location of the branch ?
<mwhudson> igc: oh yes, i want to talk to you about that at some point :)
<jelmer> mathiaz: how do you mean?
<jelmer> mathiaz, you need to set that option in the submit branch (e.g. the one you specify as first argument to "bzr send")
<fullermd> igc: Yeah, jam set me straight.  Sorry for spouting bs.
<mathiaz> jelmer: I'd like to setup ubuntu-doc@lists.ubuntu.com as the email address to be used to send patches for the ubuntu documentation (which is hosted in lp:ubuntu-doc)
<jelmer> mathiaz: launchpad doesn't make this very easy
<jelmer> you need to edit the .bzr/branch/branch.conf on launchpad to contain "child_submit_to = ubuntu-doc@lists.ubuntu.com"
<mathiaz> jelmer: right - that's what I thought - I'll check with the LP guys.
<jelmer> mathiaz, I think you should be able to create it locally and then upload using sftp
<jelmer> at least that's what I did for bzr-gtk
<spiv> gedit will probably work with an SFTP url... :)
<poolie> igc: i think deprecating both those two apis, get_tar_file and put_on_disk would be good
<poolie> they're very anachronistic there
<igc> poolie: yeah, they feel out of place
<poolie> there may even be others that should also go
<mwhudson> spiv: prompted by #twisted.web
<mwhudson> mwh@grond:bzr.dev$ PYTHONPATH=/home/mwh/src/pyflakes/support-lazy-imports /home/mwh/src/pyflakes/support-lazy-imports/bin/pyflakes bzrlib/ | grep -v 'could be lazy' | wc -l
<mwhudson> 1239
<spiv> mwhudson: btw, the supports-lazy-imports branch seems to give duplicate warnings sometimes.
<mwhudson> spiv: oh, hm
<mwhudson> i know the version in hardy does
<spiv> Hmm, I'm fairly sure I'm using supports-lazy-imports
<spiv> (the current tip)
<spiv> It's possible that I sometimes run from vim and thus side-step my bash aliases, though.
<mwhudson> spiv: in running it over bzrlib, four lazy imports used at module level come out twice
<mwhudson> that's all
<mwhudson> unless my unix pipeline foo is lacking
<spiv> mwhudson: Interesting.  I guess I'll pay more attention and file an actual bug report next time :)
<spiv> The "problem" is that it doesn't stop the tool being usefl :)
<mwhudson> heh, 89 flakes in bzrlib/tests/test_lazy_import.py
<mwhudson> bet most of those are false positive
<mwhudson> spiv: the import could be lazy one is probably a mistake
<mwhudson> it should at least be optional, or only spat out in files that already have lazy imports
<mwhudson> ah, that cuts out 2500 flakes
<spiv> Yeah, by default I wouldn't want to see those warnings for a file that doesn't use lazy imports.
 * mwhudson pushes that
<spiv> mwhudson: also, I wouldn't mind a way of whitelisting certain modules as ok to not lazy import.
<spiv> mwhudson: e.g. I don't really care if sys "could be lazy".
<mwhudson> spiv: you do know how much support pyflakes has for configuration, right?
<spiv> Happily, no :)
<mwhudson> "none at all"
<spiv> No wonder I was so happy :)
<mwhudson> it doesn't even take options
<mwhudson> mwh@grond:support-lazy-imports$ pyflakes --help
<mwhudson> Traceback (most recent call last):
<mwhudson>   File "/usr/bin/pyflakes", line 70, in <module>
<mwhudson>     main(sys.argv[1:])
<mwhudson>   File "/usr/bin/pyflakes", line 63, in main
<mwhudson>     warnings += checkPath(arg)
<mwhudson> TypeError: unsupported operand type(s) for +=: 'int' and 'NoneType'
<mwhudson> :)
<spiv> Just Works is awesome.
<mwhudson> i guess 'sys' can be whitelisted in pyflakes itself, mind
<lifeless> what is 'could be lazy' for?
<spiv> lifeless: an import that isn't used by any code run at import time, and thus can possibly by productively changed to a lazy_import
<spiv> s/by/be/
<lifeless> spiv: I'm currently looking at whether we can remove lazy_import completely :)
<spiv> lifeless: given that we use it to dodge circular import issues, probably not without some effort beyond just optimisation :
<spiv> :)
<mwhudson> ah yes, like bzr --no-plugins merge exploding?
<lifeless> spiv: keeping it for that might be ok, but actually I hit those regularly even with it
<spiv> lifeless: *nod*
<lifeless> however, its breaks freeze,py2exe,cxfreeze,pyflakes, pydoctor etc
<lifeless> it doesn't make the general case faster (because code that is needed is still loaded)
<spiv> It doesn't break pyflakes if you use mwhudson's branch :)
<jam> lifeless: we actually do have quite a bit of ancillary imports that don't always get loaded
<jam> like importing gpg.py
<jam> which imports subprocess
<jam> but is only used if you actually sign a commit
<jam> We could make that lazy in other ways
<jam> like by importing them in the function that uses them
<jam> we just have to be careful that those aren't in inner loops
<fbond> jam: Remember that issue that you debugged on my server (AssertionError: 442 != 443).  What do I have to do to work-around it?
<fbond> Is upgrading bzr on the remote server the only option?
<fbond> I guess I can use sftp, too...?
<lifeless> fbond: I thought it was a client bug
<jam> lifeless, fbond: I think you can upgrade the branch format
<jam> lifeless: I think it is caused because he is using Branch5 format branches
<jam> and the server is re-generating the history
<jam> but there is a ghost
<jam> or something along those lines
<fbond> jam: sounds familiar.
<fbond> bzr upgrade on the client will fix things?
<fbond> The server?
<jam> bzr upgrade on the server
<fbond> jam: great, thanks!
<arjenAU> so how is the stacked branch stuff coming along?
<jam> lifeless: looking at groupcompress... you start off with 'self.lines = []', do you only add things via "compress" ?
<lifeless> jam: yes
<jam> I'm just wondering why you didn't special case the first compress()
<jam> since you know there are 0 matches
<jam> or would you actually match against text you have already output
<jam> I think you actually *do* self compress texts
<jam> because output_lines() updates the line_locations
<jam> ah, but you don't do output_lines until you are done
<jam> so anyway, it seems like you could trivially say
<jam> if len(self.lines) == 0:
<jam>   self.output_lines(lines, [True]*len(lines))
<jam> return
<lifeless> jam: it doesn't seem worth special casing
<lifeless> jam: as we generally get thousands of texts in a group
<jam> lifeless: well, for a 10,000 line text you skip a fairly long loop
<jam> I suppose
<jam> lifeless: how did you benchmark it?
<jam> I didn't see any direct functions here
<jam> and I have some work done for a python version of the hashtable
<jam> and thinking to extend that to a pyrex one
<jam> though customized for what groupcompress actually needs
<lifeless> well I didn't benchmark special-cashing not-special casing
<jam> lifeless: no, I just mean *I* want to benchmark here
<jam> and am looking for pointers
<lifeless> oh
<lifeless> jam: mailed you my hacked-up scripts
<jam> lifeless: thanks
<lifeless> with the ability to do 'bzr branch' I'm benchmarking branching operations nowadays
<lifeless> get_matching_blocks is 23% of a branch of gc itself
<lifeless> flush_range 10%
<lifeless> and output_lines 8%
<jam> stupid special keys with compize
<jam> I don't know what they are and keep accidentally triggering them
<jam> I just resized my screen
<jam> "zoom"
<jam> only I can't pan
<lifeless> :P
<lifeless> I run metacity
<jam> brb
<jam> It seems I'm hitting everything today
<jam> since when does Ctrl+Alt+Backspace reboot your machine instead of just killing X?
<lifeless> rotfl
<jam> I might have hit it 2x, and maybe at exactly the wrong time?
 * igc lunch & doctor visit
<jam> igc: eat hardy, and feel well
<lifeless> jam: meh, should have shelved setup.py; pushed a new rev
<jam> lifeless: not a big deal, I already converged it with my setup.py :)
<jam> which did ~ the same thing :)
<lifeless> oh cool
<lifeless> so I have get_matching_lines up to 33%
<jam> get_matching_blocks ?
<lifeless> yes
<lifeless> jam: what are you working on, I don't want to overlap too much
<jam> lifeless: well, *right now* trying to get 'bzr branch' to actually work for me :)
<lifeless> ~/source/baz/btree-graphindex/bzr init-repo --gc-plain --no-trees gc
<lifeless> time ~/source/baz/btree-graphindex/bzr  branch ~/source/baz/plugins/index2/trunk/ gc/t
<jam> I get the feeling get_matching_blocks is getting stuck in an infinite loop
<jam> lifeless: do you have a custom bzr as well?
<lifeless> what are you branching?
<jam> bzr.dev
<lifeless> that will take quite some time
<jam> is gc that slow?
<jam> ah ok
<lifeless> its recompressing everything
<jam> I thought it was at the point of being real-world usable and that is why you said you were testing with "bzr branch" :)
<lifeless> I'm working up to bigger and bigger branches
<jam> lifeless: so... I was thinking about bringing a pyrex version of the hash-table
<jam> at the moment, I've just been prototyping it out
<jam> in python
<jam> interesting
<jam> my change at least doesn't slow it down
<djbclark> Am I correct in determing that none of the DVCS systems support svn-like versioned properties (metadata), but bazaar ir probably the closest to having that feature?
<jam> maybe 41s versus 43s for bzrtools
<jam> probably the big win is that you don't actually need to use sets() everywhere
<jam> as a plain list is just as good
<jam> (you know you won't get duplicates because of how the line lists are built up)
<lifeless> djbclark: seems plausible
<berto-> looks like i broke a bzr-svn repository by running "bzr uncommit" on it.  i get internal errors now.  any way to revert back to the committed state.  then, any way to safely have bzr forget what i committed?
<djbclark> ah, just found http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/40419/focus=40479 :-)
<jelmer> berto-, broke it how?
<lifeless> berto-: well, file bugs please :P
<berto-> lifeless: i want to see if it's really broken first.  :P
<lifeless> berto-: if you are getting internal errors, its a bug
<lifeless> jam: so - I'll work on getting the fetch order to be good
<lifeless> jam: as hacking on get_matching_blocks would collide with you
<jam> sure
<jam> sounds reasonable
<berto-> jelmer: hmm, may not be the uncommit that broke it.  i ran bzr merge on ~/.bazaar/plugins/svn and recompiled, got some error, ran make clean && find . -name '*.pyc' | xargs rm && make, and now i get an import error on from bzrlib.plugins.svn.versionedfiles import (SvnTexts, VirtualRevisionTexts[...]: File "/home/berto/.bazaar/plugins/svn/versionedfiles.py", line 18
<berto-> ImportError: cannot import name VirtualVersionedFiles
<jelmer> berto-: you need a newer version of bzr
<berto-> jelmer: cool, thanks, working on updating
<jelmer> VirtualVersionedFiles is only in a recent revision of bzr.dev
<berto-> jelmer: alright, working great again, thanks!
<jelmer> :-)
<berto-> jelmer: i take it bzr uncommit now works?  should i remove it from the wiki as an unsupported command?
<berto-> jelmer: how about bzr push --overwrite ?
<jelmer> berto-: what did uncommit do?
<berto-> jelmer: i ran bzr uncommit -r <revno>; that uncommitted a directory i had added as well as some other files i had modified.  it basically put the added directory back into an add state, then put the other files back in a modified state.  i was then able to run bzr ci -m'[...]' <dir>
<berto-> ... which just committed the added directory and left all the modified files alone.
<jelmer> Was that committing it back to svn as well though?
<berto-> jelmer: no, all that was local, i have not committed back up to svn as it's an svn repo i don't have commit access to.
<jelmer> berto-, ok, so that's all unrelated to bzr-svn
<lifeless> berto-: then you're operating purely in bzr land :)
<berto-> jelmer: ah, ok. cool.
<berto-> i see, awesome.
<berto-> so it's trying to uncommit something that was committed in svn that's not going to work right.
<berto-> [the current version of] svn has no concept of being able to uncommit, so will there ever be some sort of support for that, or is a revert mechanism as close as it gets?
<jelmer> it will be possible to uncommit, but it'll basically do a revert (copy from a revision in the past)
<jelmer> s/copy/replace/
<lifeless> back later
<berto-> jelmer: thanks again for the help!
<berto-> lifeless: thank you too.
<jam> lifeless: holy crap
<jam> compacting all of NEWS in 'topological order'
<jam> Compressed 3213 text with 437350320 bytes to 74265451 bytes (5.89:1) in 109.994s
<jam> and in *reverse* topological order
<jam> Compressed 3213 text with 437350320 bytes to 5814355 bytes (75.22:1) in 271.026s
<jam> 75:1 versus 6:1
<jam> bit of a difference
<mwhudson> i also guess that this is going to be quite a slow 'bzr upgrade'?
<mwhudson> but wow, nice numbers
<jam> mwhudson: well, I'm working on writing a C extension to improve the speed
<mwhudson> ah right
<jam> but the 75:1 compression ratio is pretty darn good
<jam> I have the feeling it owes the most to the multi-location abilities of groupcompress
<jam> basically, it follows *all* matches concurrently
<jam> and picks the one with the longest sequence
<jam> And NEWS is rather a special case
<jam> since it is 95% insert-only
<mwhudson> jam: yeah, i guess builtins.py is another obvious one to try
<jam> mwhudson: running it now
<mwhudson> :)
<jam> forward: Compressed 1837 text with 210568735 bytes to 38663891 bytes (5.45:1) in 80.498s
<jam> mwhudson: builtins.py was the one I used for my xdelta testing
<mwhudson> ah right, i remember now
<jam> though it had only 1300 texts, IIRC
<jam> reverse: Compressed 1837 text with 210568735 bytes to 21061973 bytes (10.00:1) in 76.862s
<jam> Don't trust the times completely, as I'm poking at the code while waiting :)
<mwhudson> heh
<mwhudson> less spectacular
<jam> less spectacular, but 2:1 for going in reverse versus forward
<bob2> and faster in reverse
<jam> bob2: well, as I said, I poked at the code in there, so maybe, maybe not
<lifeless> also
<lifeless> is that the raw output or the gzipped?
<jam> lifeless: raw
<lifeless> yah
<lifeless> thought so :)
<lifeless> but now you see why I think this has legs :)
<jam> lifeless: does that normalize a bit more?
<lifeless> jam: its the gzip phase takes the reverse output below git in size
<bob2> is gc similar to how git does packs?
<jam> bob2: git does xdelta compression
<jam> gc is a different algorithm
<jam> the idea of --reverse versus --forward is somewhat taken from git
<lifeless> jam: oh, it *does* do xdelta?
<jam> lifeless: yes
<jam> I'm not sure if it is xdelta 1,2,3
<jam> but xdelta
<jam> at least, that is what I remember
<jam> lifeless: interestingly, sorting by text size
<jam> is slightly better for group-compress
<jam> (without gzip)
<jam> rather than reverse topological
<lifeless> jam: as expected; though we don't cache size at a good place to use for this
<jam> at least, in my 2 trivial tests
<jam> lifeless: strictly because it gives more locations to match ?
<lifeless> yes
<lifeless> well
<lifeless> because it can encode longer sequences
<jam> lifeless: you may be interested in lp:~jameinel/+junk/test-groupcompress
<jam> You may not
<jam> but it provides direct GC testin
<jam> testing
<jam> by extracting the texts from the ancestry of a supplied file
<jam> and --lsp filename.callgrind will profile *just* the GC operations
<sohail> hey guys, I deleted directory foo in commit 560 but also a whole bunch of other stuff that I don't want. How can I bring back just directory foo?
<lifeless> sohail: bzr revert -r 560 foo
<sohail> lifeless, ah!
 * sohail tries
<sohail> lifeless, "ERROR: Path(s) are not versioned: foo"
<lifeless> sohail: oh :(
<lifeless> sohail: try -r 559 ;)
<sohail> lifeless, I did bzr merge -r560..559 aka svn :-)
<sohail> but what I really want to do is bzr cp foo@559 dir/foo
<sohail> but I can't figure out how to do that
<lifeless> sohail: well, merge -r560..559 foo should work
<sohail> lifeless, yeah that worked
<lifeless> sohail: revert -r 559 foo should have worked too
<lifeless> (clearly -r 560 can't as foo doesn't exist there :p)
<sohail> lifeless, trying now
<sohail> lifeless, you were right, it worked
<sohail> in the star trek universe, the person who figures out how to transport with shields still up will win the nobel prize
<spiv> bzrlib.tests.blackbox.test_info.TestInfo.test_info_standalone in bzr.dev is failing for me.
<spiv>   File "/home/andrew/code/bzr/bzrlib/tests/blackbox/test_info.py", line 158, in test_info_standalone
<spiv>     bzrlib.upgrade.upgrade('bound', knit1_format)
<spiv> AttributeError: 'module' object has no attribute 'upgrade'
<lifeless> spiv: funky
<lifeless> spiv: and does it?
<spiv> lifeless:
<spiv> $ PYTHONPATH=. python -c "from bzrlib.upgrade import upgrade"
<spiv> $
<spiv> Hmm.
<mwhudson> circular imports again?
<spiv> Ah.
<spiv> It's the 'bzrlib' object that lacks the 'upgrade' attr, not the 'bzrlib.upgrade' object.
<spiv> i.e. there's a missing "import bzrlib.upgrade"
<mwhudson> oh hee
<mwhudson> it makes a difference whether you selftest <that test>
<mwhudson> or selftest -s <that test>
<spiv> Yeah.
<spiv> Which is why I couldn't reproduce it with 1.5: I couldn't use -s :)
 * spiv fires off a trivial fix.
<Stumbles> hi, I've just read quickly through the bzr user guide, but couldn't see an example of how to make a topic branch. How do I do this?
<luks> bzr branch A B?
<Stumbles> what's A and what's B?
<Stumbles> as in, which is the trunk?
<luks> A is the original branch, B is the branch you want to create
<luks> A
<Stumbles> thanks
<Stumbles> Just trying to get my head around bazaar after using Git for a while. So if I do "bzr init repo" and then "bzr branch repo repo2", do I then have two full repositories?
<RAOF> Kindof.
<spiv> Stumbles: there's some terminology differences with Git that confuses things a little.
<RAOF> bzr makes a distinction between things that are conflated in git.
 * RAOF leaves it to the more knowledgable spiv
<spiv> Stumbles: you have two branches, each with a full copy of history in them.  (And so if you haven't done other set up to avoid this, you'll be using twice as much disk space as if you only had one branch).
<spiv> Stumbles: "bzr init" creates a what we call a "branch".
<spiv> Stumbles: "bzr init-repo" creates what we call a "shared repository".
<Stumbles> Thanks, this is a great help. So the way to go is "bzr init-repo myrepo", "mkdir myrepo/trunk", "cd myrepo", "bzr branch trunk mytopicbranch"?
<spiv> Stumbles: so for comparison, if you did "bzr init-repo repo", then "cd repo; bzr init branch-one; bzr branch branch-one branch-two", you'd have two branches inside one shared repository.
<spiv> Stumbles: right, except "bzr init myrepo/trunk" rather than "mkdir myrepo/trunk".
<Stumbles> lovely
<Stumbles> ok, right
<Stumbles> and that way the second branch doesn't take additional space until I change files?
<spiv> Right.
<spiv> The two branches will use the same storage for their revisions.
<Stumbles> ah right, I see, shared repository, but two full working copies
<Stumbles> shared history i mean
<Stumbles> thanks spiv, much appreciated
<luks> you can have just one working directory, but then it gets a little complicated
<spiv> Stumbles: you're welcome
<Stumbles> so if you were doing lots of short-lived branching, say one or two commits before merging with the main line, a shared repository would definitely be the way to go, right?
<spiv> Stumbles: yep
<Stumbles> if not using a shared repository, what would the difference be between "cp -r original branch" and "bzr branch original branch"?
<Peng_> Stumbles: Since it actually access the repo, it would somewhat verify that it isn't broken. It won't copy working tree modifications and unversioned files.
<Stumbles> thanks
<Peng_> accesses*
<RAOF> Even without doing lots of short-lived branching, you probably want a shared repository anyway.  Pulling other people's remote branches is orders of magnitude faster when you pull them into a shared repository which already contains most of the history.
<RAOF> And the way that I use bzr, pulling other people's branches is by far the slowest operation, so a shared repository makes a lot of difference.
<Stumbles> thans RAOF
<pitti> hi
<pitti> KnitCorrupt: Knit text:x_Matt_Zimmerman_<matt.zimmerman@canonical.com>_Sun_Mar_13_00:51:19_2005_1366.38 corrupt: line-delta from stream for version mdz@mizar-20051205230117-c327e75be767f237 references missing parent Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21
<pitti> oh, the late wrath of arch...
<pitti> I get that when trying bzr get lp:~ubuntu-core-dev/casper/trunk casper
<pitti> any idea what I can do to debug/fix this/
<pitti> ?
<james_w> hi pitti
<pitti> in the meantime I found some pointers to that
<james_w> I've heard rumblings about the casper branch.
<pitti> bug 246880 and https://answers.launchpad.net/launchpad-bazaar/+question/39693
<ubottu> Launchpad bug 246880 in bzr "Can't branch casper which misses some parents in old revisions" [Undecided,New] https://launchpad.net/bugs/246880
<cjwatson> I'm working on it
<cjwatson> mdz still has the old branch kicking around
<cjwatson> so I'll fetch the ghosts
<cjwatson> pitti: no point you working on this simultaneously :)
<pitti> right, I just started asking here
<pitti> cjwatson: thanks
<cjwatson> though first I have to remember how the hell to mirror an archive using baz
<cjwatson> recycled neurons FTW
<pitti> I might still have it in the REAME.Developers of postgresql-common in an ancient revision
<cjwatson> it's OK, I've got far enough to remember the basics
<pitti> ouch
 * pitti reads about make-archive, register-archive, branch, get, and gets painful memories
<pitti> "27 easy steps to check out a branch"
 * Kinnison giggles
 * Kinnison has utterly evicted that knowledge from his head too
<pitti> hey Kinnison, how's life?
<Kinnison> busy and full of windows, poorly written packet sniffers, and embedded RF microprocessors
<pitti> yay hardware development :)
<Kinnison> indeed
 * pitti was happy about the atmel toolchain back then, which ran fine under linux
<Kinnison> In this instance, I'm trying to work out why a three-byte payload packet ends up doing around 8 packets, comprising around 200 bytes over the air
<Kinnison> mmm 802.15.4+ZigBee2004
<cjwatson> Kinnison: hi! TLNS
<cjwatson> err, ^T
 * Kinnison grins
 * Kinnison is usually around :-)
<krani1> hi! I'm having a problem. a developer branched my repo, worked on something, created a bundle with "bzr bundle" and send it to me.. I worked on my branch too... Now everytime I want to merge his bundle "bzr merge file.bundle" I'm getting an error "Revision {('dev mail address-foo bar',)} not present...
<Peng_> Sounds like the bundle is broken, corrupt, or just missing some revisions you don't have.
<krani1> Peng_: the base_resvision_id on the bundle exists on my tree
<krani1> bzr jsut can't find the "revision_id" on my tree.. and I think it doesn't make sense... *after* aplying the bundle it shuld exist, not *before*
<Kinnison> has the bundle become corrupted in transit?
<Kinnison> E.g. has an email mangled it?
<Peng_> "dev mail address-foo bar" is a horribly weird revision ID; bzr would never generate that on its own.
<lifeless> Peng_: I think krani1 is paraphrasing
<krani1> Peng_: :)
<lifeless> Kinnison: bundles are base64 encoded
<lifeless> Kinnison: and checksummed: its not mangled
<Kinnison> aah
<Kinnison> cunning
<james_w> krani1: is the revision it complains about the base_revision_id mentioned in the bundle?
<james_w> also, is the branch it refers to the branch that you are trying to merge it in to, or another?
<krani1> james_w: no! the "base_revision_id" mentioned in the bundle exists on my tree! It complains about the "revision_id" mentioned in the bundle!
<james_w> do you get a backtrace?
<krani1> james_w: actually, I'm trying to merge on another branch... does that make a difference?
<james_w> if so, could you pastebin it please? If not, then please run again with -Derror
<james_w> another branch?
<james_w> I don't really understand, you are trying to merge it in to a branch, and that has the base_revision_id, but it is complaining?
<krani1> james_w here is the traceback with -Derror http://pastebin.com/m127de67c
<krani1> james_w: exactly! that! it doesn't make sense!
<james_w> that's in _verify_patch
<james_w> so it hasn't started merging yet
<krani1> I'm not merging into the "target_branch" mentioned in the bundle, can that be a problem?
<james_w> possibly
<james_w> at first look, this should never work, but that's obviously wrong.
<lifeless> krani1: that shouldn't matter, as long as the branch you are merging into has at least the same revisions the target did
<james_w> so, it's trying to regenerate the diff to check it, so it takes the repository you are trying to merge in to, and then extracts the trees of the base_revision_id and the target revision, but I can't see how that would ever be expected to work
<krani1> lifeless: well as I said it, the "base_revision_id" in the bundle exists on my tree.... something went wrong here... the dev is telling me he have more commits, and just sent me a particular commit using "bzr bundle -r ..."
<spiv> james_w: because from_mergeable does install_revisions to tree.branch.repository before it does get_merge_request.
<james_w> spiv: ah, thanks.
<james_w> krani1: this would suggest that the bundle doesn't contain all of the revisions.
<krani1> james_w: ok.. will talk to the dev and try to sort things out, thank you guys
<james_w> krani1: I'm just looking for a way to debug this a little more
<krani1> james_w: If I can provide you more info, feel free to ask
<james_w> the command to debug a bundle was removed I think, so I'm not sure what to do
<Peng_> ...Oh. Right. Paraphrasing. Heh. Never mind then.
<james_w> it would be useful to know what command and arguments they used to generate this bundle.
<krani1> I will try to get them, just a minute
<krani1> james_w: bzr bundle -o build.patch -r revno:107..revno:108
<krani1> that's the exact command he used
<james_w> just as aside "revno:" is default, so "-r 107..108" would be work and is less to type. That won't affect this though.
<james_w> is revno 107 something that you have in your branch?
<krani1> james_w: yes!
<krani1> he branched on that exact revno
<lifeless> krani1: are you editing the backtrace that we see ?
<krani1> lifeless: just the 'dev mail' everyting is verbatim
<spiv> krani1: I'm curious about why they didn't use "bzr send -o build.patch target_branch" to generate the merge directive?
<lifeless> krani1: ok, can you only edit the mail part of it, keep the UUID bit at the end intact ?
<krani1> spiv: cause bzr send generates a bundle that I can't apply on my local branch.. it seems I can only apply it on the branch the dev first got (target_branch)...... but that's another problem....
<spiv> krani1: bzr send tries pretty hard to automatically figure out what the right merge directive is, but using -r circumvents that.
<spiv> krani1: Hmm!  I have a very strong suspicion that that is actually a symptom of the same root problem.
<krani1> spiv: the workflow is. I have local branches, and push the changes to a shared server. the dev branches from the server, works, commits and sends bundle back to me, so I can review and push them back to server... does this help?
<spiv> I wonder if revno 107 in the two branches are actually the same revision...
<krani1> spiv: is there an easy way to verify that?
<lifeless> revision-info
<Peng_> krani1: If you gave devs push access to an area of the server, you wouldn't have to bother with bundles..
<krani1> Peng_: I'm working like a gatekeeper....
<lifeless> bundles should work fine
<spiv> krani1: Compare the output of "bzr revision-info -r107" in both branches.
<krani1> spiv: doing that
<lifeless> you don't need them though if you had the devs push up their own branches to a different area
<spiv> krani1: Or of "bzr log --short -r 107 --show-ids" if you want slightly more verbose output.
<krani1> spiv: OMG they are different! w00t???
<spiv> krani1: ta-da.
<krani1> spiv: how can this happen?!
<Peng_> Revnos are per-branch. bzr.dev has a different revision 107 too..
<lifeless> krani1: the dotted decimal revision numbers are just a convenience over the underlying UUIDs. they are specific to an individual branch
<krani1> lifeless: so how the dev should generate the bundle then?
<spiv> krani1: so, if they do "bzr send -o foo.patch target_branch", it should generate a workable bundle.
<lifeless> krani1: as spiv says, you don't need the -r parameters ever, unless you need to do a cherry pick
<spiv> krani1: so long as the branch you try to merge foo.patch into includes all the history of the target_branch given to bzr send.
<spiv> krani1: (e.g. it's the same branch, or it has merged that branch, etc)
<krani1> humm it all makes sense now
<krani1> I've got the lesson.. never trust revno :-)
<krani1> in the bundle, what does it really mean the "revision_id" and the "base_revision_id" ?
<james_w> krani1: the base_revision_id is the ancestor revision that the bundle is based on, revision_id is the tip revision in the bundle
<lamont> bzrlib/_dirstate_helpers_c.c:2161: warning: dereferencing type-punned pointer will break strict-aliasing rules
<lamont> and many others.
<VSpike> does anyone know if the bzr-upload plugin is in a useful state?
<beuno> VSpike, I sure hope so  :)
<beuno> quite a few people have been using it for months
<beuno> and we've had no major bug reports
<mtaylor> beuno: bzr-upload?
<VSpike> beuno: thanks - I couldn't really see any indication of its development status on the launchpad site
<mtaylor> oh, neat
<beuno> mtaylor, yes, it's a plugin to upload *just* the working tree
<mtaylor> very cool
<beuno> mainly for websites, but there must be all kinds of creative use cases
 * beuno looks at the lp page to make the status more obvious
<VSpike> beuno: are there any install/use instructions anywhere?
<beuno> VSpike, there's a README in the branch, and you can install it like any other plugin:  bzr co lp:bzr-upload ~/.bazaar/plugins/upload
<beuno> (basically, copy it to the plugins dir)
<VSpike> beuno: does lp: use ssh underneath?
<Peng_> VSpike: If you're logged out, it uses http. If you're logged in (bzr launchpad-login my_username), it uses bzr+ssh
<VSpike> Peng_: I'm not logged in .. it's just it's giving me "bzr: ERROR: [Errno 0] Error" which is what I get when I try use sftp
<Peng_> VSpike: What's the exact command you're running?
<VSpike> as beuno just typed
<VSpike> Peng_: ^
<Peng_> Oh.
<Peng_> I dunno, then, and I'm about to go to bed. Good luck. Hopefully someone else can figure it out.
<VSpike> Ta :)
<beuno> VSpike, what version of bzr are you using?
<VSpike> I may have found a fix, hold on
<VSpike> Cygwin version :)
<beuno> ah, ew   :)
<beuno> I'm off for a bit
<VSpike> You mention cygwin and people just leg it
<beuno> I'll read the backlog when I get back in case you run into more trouble
<VSpike> :D
<VSpike> Well, I found a fix for my sftp problem, but the lp one might not succumb
<VSpike> Ah no.. just had to mkdir -p ~/.bazaar/plugins/upload
<VSpike> beuno: Thanks for the help
<VSpike> If I already have the site uploaded, do I need to delete it before running bzr upload for the first time?
<VSpike> I'm getting an error "File exists: '/AllUsers': 500 /AllUsers: Access is denied."
<VSpike> If I know it's in sync with the current revision, can I create a revision ID marker on the site ftp so that it works without doing a full upload?
<beuno> VSpike, yeap
<beuno> you can trick it
<VSpike> beuno: what do I need to put there?
<beuno> VSpike, a file named: .bzr-upload.revid
<beuno> which contains the last revid
<beuno> of your branch
<beuno> (you get revids by adding --show-ids to the log command)
<VSpike> Thanks :)
<beuno> welcome'
<VSpike> Yes, although generally we would be expecting people to use Thuraya for messages so not an issue
<VSpike> I guess we should publish this info on the site
<beuno> probably the wrong window  :)
<VSpike> Ah yeah ta
<VSpike> Sheesh
<VSpike> beuno: how critical is the format of that file?  It's not finding it
<beuno> VSpike, it doesn't have much of a format
<beuno> just the name and the revid text in it
<VSpike> beuno: it contains -- johncc@gort-20080724140726-blahblahblah<LF>
<beuno> VSpike, what the <LF> at the end?
<VSpike> I mean it ends with a normal unix line ending
<beuno> no line ending
<fbond> Hi.  I used `bzr replay -r x..y' one day and was surprised to find that revision x had been replayed.
<fbond> `bzr merge -r x..y', `bzr diff -r x..y' don't seem to include revision x.  Right?
<beuno> VSpike, and, is that in the root of the dir?
<fbond> Is replay an odd duck?
 * beuno has no idea what replay does
<fbond> beuno: it is part of the rebase plugin.
<VSpike> beuno: yeah, it's in the root.  Still not working though.
<beuno> VSpike, it still tries to upload?
<fullermd> It doesn't sound odd, just a different meaning.
<fullermd> `bzr log -rx..y` includes x, frex.
<luks> what's the best way to upgrade branches on launchpad? I'm running an upgrade over sftp right now, but I'm starting to regret that
<luks> bzr+ssh just told me the branch is already up to date
<luks> (it probably tries to upgrade only the branch, not the repo)
<beuno> VSpike, bug report was a good way to go, thanks
<fullermd> I'm not sure it tries to upgrade anything; I think it still just sees a totally fake format.
<luks> oh
<fullermd> Try info -v:
<fullermd> Format:
<fullermd>        control: bzr remote bzrdir
<fullermd>         branch: Remote BZR Branch
<fullermd>     repository: bzr remote repository
<beuno> for some reason, bzr info via ssh always lies. Only http tells you the actual format
<beuno> (maybe sftp too)
<fullermd> Well, the reasin is because that's how the SS does its thing.
<fullermd> Info over bzr:// or bzr+http:// would presumably tell you just the same.
<VSpike> beuno: no prob.  Yes, it says "No uploaded revision id found, switching to full upload"
<luks> I was stupidly hoping it would just run an equivalent of 'bzr upgrade' remotely, so it doesn't have to transfer anything
<VSpike> Hmm maybe doing strace python /usr/bin/bzr upload .. was not such a good idea :)
<ddrreeeaaammss> When I install bazaar on vista whenever I fire up a new command prompt the workling directory is automatically "C:\program files\bazaar" how do  i change this?
<VSpike> ddrreeeaaammss: do you mean the bazaar command prompt entry in the start menu?
<ddrreeeaaammss> No
<ddrreeeaaammss> I mean if I go start "cmd" press enter I start in c:\program files\bazaar
<cjwatson> luks: there's a bug report asking for that
<cjwatson> (I don't have the number to hand but look for "upgrade" and "smart server" or some such)
<fullermd> luks: It's a good hope...
<fbond> fullermd: The inconsistency bothers me a bit.  replay is more similar to merge than it is to log, but merge is exclusive, and both replay and log are inclusive.
<fbond> It's confusing, and inspires doubt.
<fullermd> Well, merge is a stick point.
<fbond> rebase is inclusive
<fullermd> Merge is what merge is by analogy to diff.
<fbond> diff is exclusive
<fullermd> Where it's simple.
<fbond> fullermd: And why is diff exclusive?
<fullermd> "Show me the differences from state x to state y"
<fullermd> That wouldn't include the differences from state (x-1) to x.
<fbond> "Merge the differences from state x to state y"
<fullermd> Compare log, where it's "Show me the logs from revision x to revision y", where you'd expect to see both x and y.
<fbond> "Replay the differences between state x and state y"
<dash> hi. just got a traceback making a checkin on 1.5 --
<fullermd> That's now how I read replay.
<fullermd> (not)
<fullermd> I'd read it as "replay revisions x to y".
<dash> http://rafb.net/p/QokLZ842.html
<fbond> fullermd: I get it, but I think it is more arbitrary than you are portraying.
<dash> this look familiar to anyone?
<fullermd> Well, everything's arbitrary.  My reading feels more natural to me.  Doesn't mean it does to everybody, but it suggests that it does to whoever wrote replay.
<fbond> fullermd: I'm just saying that doing it arbitrarily in two different ways is confusing.
<fbond> I don't think the meaning follows naturally from the command.
<fullermd> It'd be more confusing otherwise.
<fbond> It is not obvious that replay replays revisions while merge merges deltas.
<luks> fbond: then `bzr replay -rX` should be invalid?
<fullermd> Well, it is to me...
<fbond> luks: Not necessarily.
<fbond> luks: merge -rX is valid, too...
<luks> it would be noop, if it's exclusive
<fbond> luks: For merge it means "from the beginning up to X".
<luks> fbond: but I think it does something very different from -rX..Y
<fbond> luks: I'm not sure what -rX should do for replay.
<fbond> But I don't think that that should dilute my point.
<luks> replay revision X, which means it should be inclusive
<fbond> Why should -rX syntax imply anything about -rX..Y syntax?
<fbond> The meaning of -rX obviously varies heavily from one command to the next, anyway.
<luks> -rX..Y in merge is a special case, "a cherry-pick"
<luks> what is confusing in case of replay is that is treats revisions as changesets
<luks> ideally it should use -cX..Y
<luks> that should be more clear, I think
<fbond> luks: Okay, now we're getting somewhere, I think.
<gnomefreak> has bzr changed to where bzr bd --merge --dont-purge --builder='dpkg-buildpackage -rfakeroot -kA5C42601 -i.bzr' . no longer waits for passphrase?
<gnomefreak> i had steppeed away for about an hour and came back and it told me invalid passphrase
<james_w> gnomefreak: shouldn't have
<gnomefreak> james_w: give me a minute or 2
<gnomefreak> i have output just lagging alot
<gnomefreak> james_w: http://pastebin.mozilla.org/498831
<gnomefreak> if that helps
<gnomefreak> it never waited for me
<james_w> nothing should have changed in bzr/bzr-builddeb to break that I don't think
<gnomefreak> i havetn used it since hardy devel cycle and it worked than
 * gnomefreak sitting and waiting for the source build to see if that atleast asks me
<gnomefreak> if it fails this time ill file a bug on LP about it in morning
<gnomefreak> dpkg-buildpackage still asks me so i figured it had to do with bze-builddeb
<gnomefreak> james_w: -S -sa gave me the passphrase popup dialog
<strk> is it possible to get keyword substitution on commit like for CVS ?
<strk> it seems $Id$ isn't substituted ...
<beuno> strk, you could probably script something with the pre-commit hook
<strk> urgh
<strk> really nothing built in for that ?
<dash> strk: you want the uuid in there?
<strk> don't even know what it is :(
<strk> whatever identifies a specific revision of the file
<dash> right, that'd be the uuid (because the short revision numbers aren't guaranteed to be unique or stable)
<strk> k
<strk> hope for me ? :>
<dash> so, something like foo@baz.com-20080722154412-x8m52mo7rj5umv9a
<dash> strk: I guess the question is, why do you want it in the file? :)
<dash> my experience has been that software version numbers are useful to have in the text of the files; if revision information is needed, it's pretty easy to ask the revision control system for it
<strk> dash: http://gnashdev.org/testcases/v6/array-v6.swf
<strk> see on top, between []
<dash> ah.
<strk> it comes from .as source containing the keyword
<strk> http://wiki.gnashdev.org/Testcases#Testcases
<strk> ^^^ more info about how that's useful
<strk> the uuid doesn't look as readable as the current RCSId :/
<strk> know what ? the best would be branch name and revision of that branch
<strk> possible ?
<strk> like: trunk 9532.
<fullermd> The best would be different per situation   :p
<strk> best in *this* situation ofc
<fullermd> At the least you'd want the options of {revno,revid,date} of last change to the {file,tree}.
<strk> ah, right, don't care about revision of the whole branch
<strk> but, dunno what revno,revid are (ie: why two?)
<fullermd> Yah.  Sometimes you do, sometimes you don't.
<fullermd> Because revid alone is user-hostile.
<dash> strk: a revision can appear in a bunch of different branches
<dash> strk: and have a different revision number in each
<dash> but the revid will be the same
<strk> the id being the ugly loooking thing above ?
<dash> right
<strk> it says revision date, that's fine
<fullermd> Not necessarily.
<fullermd> All it says is <opaque string>
<strk> mm, let's try to figure some use cases
<strk> case 1: we check website to figure if the versions up there are the most recent revision from official trunk
<fullermd> The ones bzr generates itself tend to include the committer and commit date, but that's happenstance.
<strk> is "happenstance" an english word ? I always wondered how would I say that :)
<fullermd> I hope so, otherwise I've confused a lot of people in my life   :)
<dash> it's an english word ;)
 * strk can't wait to use that ! :P
<strk> case 2: a user reports a bug in the testcase and we use that id to check if that bug was fixed already
<strk> I guess I'm out of cases
<fullermd> There's certainly no lack of cases calling for it.
<fullermd> The code that's recently in (or not in?  Discussed a lot anyway) for line ending stuff is also intended to handle cases like keyword expansion.
<strk> does it help if I jump in and put my vote ? :)
<dash> Hmm
<dash> is there an existing bzrlib method to determine if an URL specifies an existing branch?
<dash> previously I was just going with: bzrlib.bzrdir.BzrDir.open()
<dash> and expecting NotBranchError if it didn't exist
<luks> Branch.open?
<dash> hm
<dash> that seems more reasonable.
<mwhudson> beuno: hi there
<jelmer> Is Colin Bennett?
<jelmer> Is Colin Bennett here?
<beuno> mwhudson, mornin'
<Verterok> hi
<amanica> hi Verterok
<lifeless> `moin
<Verterok> mornin' lifeless
<beuno> mornin' lifeless!  back to AU time?
<mwhudson> hi lifeless
<lifeless> approximately
<beuno> good, AU fits me better than european   :)
<igc> morning
<beuno> mornin' igc
<beuno> how are you today?
#bzr 2008-07-25
<igc> beuno: no too bad thanks
<lifeless> jam: hi
<jam> lifeless: hi
<jam> $ bzr bench-gc bzrlib/inventory.py --reverse
<jam> Compressed 312 texts with 12471026 bytes to 1034947 bytes (12.05:1) in 2.403s
<jam> builtins.py --reverse
<jam> Compressed 1837 texts with 210568735 bytes to 21061973 bytes (10.00:1) in 113.506s
<lifeless> jam: sweet
<jam> NEWS --reverse
<jam> Compressed 3213 texts with 437350320 bytes to 5814355 bytes (75.22:1) in 116.813s
<lifeless> jam: this is with your C compressor?
<jam> lifeless: yes
<lifeless> jam: where is your branch :P
<jam> lp:~jameinel/+junk/bzr-groupcompress
<lifeless> reckon its merale ?
<jam> lifeless: ? It is well tested
<lifeless> mergable
<jam> I think so
<lifeless> will do
<jam> I have a couple tweaks yet to do
<jam> but I think it is a good start
<jam> anyway, I'm off for a bit
<lifeless> ok
<lifeless> nice work
<fullermd> % bzr bind :push
<fullermd> abentley++
<jiho> hello everyone. I am currently getting to know bzr and one thing I liked in git and can't get in bzr is nice colored output. there's cdiff in bzrtools but is there anything more general (color output on more commands, word diff with colored output etc.)?
<jiho> I am particularly after some nice word diff options. I do a lot of latex and having word diffs rather than line diffs is necessary.
<amanica> the lessdiff plugin does the trick for me
<jiho> thanks I'll check that
<amanica> (I dont know about word diffs though)
<lifeless> jiho: how do you do word diffs in git?
<jiho> git diff --color-words
<lifeless> thats built in ?
<jiho> yes
<lifeless> thanks
<jiho> well I think. I have wdiff on my system but it does not do color, wo I guess git uses its own code
<jiho> amanica: care to guide me one how to install lessdiff? I've just cloned it hoping to find a read me but there is just the source
<amanica> put it in ~/.bazaar/plugins/
<jiho> thanks
<amanica> I aliased my diff to use it. In ~/.bazaar/bazaar.conf in the [ALIASES] section I put the following
<amanica> diff = 'lessdiff --diff-options "-wp -U10 --strip-trailing-cr"'
<jiho> thanks for that
<jiho> too
<amanica> cool
<dash> I usually use meld for that
<jiho> dash: thanks for the tip but I am mostly on OS X
<mwhudson> should be able to use FileMerge somehow then
<jiho> yes I can indeed. bzr output is fine for that
<jiho> just: bzr diff --using="opendiff"
<jiho> FileMerge has UI glitches when opened this way but it mostly works
<jiho> the real problem is that it is yet another window open on a small laptop screen
<jiho> ;)
<lifeless> anything we can improve to fix the glitches?
<mwhudson> ah, right
<jiho> I'll check but my guess is that the issue comes from the opendiff command itself
<jiho> lifeless: that's right, the issue comes from opendiff (still present when diffing two files outside of bzr). so there's nothing you can do.
<lifeless> ah well
<jiho> OK, so the status on this seems to be that is it easy to get coloured line diffs, but not word diffs. I have yet to investigate vimdiff but since I am no vi expert I guess it won't be very productive to use it only to view diffs
<lifeless> jam: the pyrex step fails
<lifeless> /home/robertc/source/baz/plugins/groupcompress/trunk/_groupcompress_c.pyx:254:30: Expected an identifier or literal
<lifeless> jam: its the +=, &= operators
<lifeless> interesting, its about 10% faster :(
<jiho> correction on my self. using this in [ALIASES]:
<jiho> wdiff = 'lessdiff --using="wdiff -l"'
<jiho> makes it a pretty decent "colourized" word diff
<jiho> (where colour = bold/underline)
<jiho> (still there's something visual about it)
<jiho> cool I can ditch git
<jiho> ;)
<jiho> thanks everyone
<jiho> bye
<amanica> thanx for teaching me about wdiff
<amanica> bye
<AfC> "I can ditch git, kthxbye". That's a nice way to start the day.
<steltho>  bzr branch http://bzr.savannah.gnu.org/r/gnash/trunk gnash_new
<steltho> bzr: ERROR: Invalid http response for http://bzr.savannah.gnu.org/r/gnash/.bzr/repository/indices/2c779c251220f8afce08bcec69277e32.rix: Expected a boundary ("a3=Zi=KvaN:JowhY.VpV", application/plain) line, got '--a3=Zi=KvaN:JowhY.VpV
<steltho> '
<steltho> I am getting the above error message, trying to create a new branch with bzr.
<AfC> steltho: which version of Bazaar are you using as your client? [it probably doesn't matter, but people will be curious]
<steltho> I am using 1.5
<lifeless> pretty sure we had a bugfix for that during the 1.6 development cycle
<steltho> so, do you think if I tried version 1.6b3 this problem might be fixed?
<lifeless> I think it might be yes
<steltho> I am trying it now.
<lifeless>      Fix quoted boundary lines bugs exposed by tests in previous revision.
<lifeless> there are definite boundary improvements
<lifeless> it might be something else, like a broken local proxy
<steltho> It is weird because I never had any problems pulling from that location, and then one day it started to get this error message.
<lifeless> interesting
<steltho> I also asked on the gnash-dev mailing list and nobody else is having trouble.
<lifeless> that suggests a local issue of some sort - your machine/router/isp
<steltho> I just ran across this bug report https://bugs.launchpad.net/bzr/+bug/198646, which looks like it might be similar to my problem.
<ubottu> Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released]
<steltho> Hmm, it looks like who ever posted the bug is living in Thailand and thinks that there is some proxy there that is causing the problem.
<steltho> I also live on that side of the world, so maybe my request is also being distorted by some local proxy.
<lifeless> steltho: thailand has a country-wide intercepting proxy
<steltho> Yeah, I wonder if the country I am in has something similar.
<amanica> I better go sleep now. have to get up in a hour. cheers
<jam> lifeless: as I mentioned, I still have some tweaking
<jam> I just added a change which seems to improve things by about 20%
<jam> I'm hoping to get more from a deeper change
<jam> but honestly, you were using python dicts and lists like they were *meant* to be used :)
<jelmer> is .bzrrules is going to be part of the revision tree? I thought it was just going to live in the working tree but have a status similar to .bzr/ ?
<jam> jelmer: I believe it is going to have a life similar to .bzrigore
<jam> .bzrignore
<jam> so it will be versioned
<jelmer> ah :-(
<jam> $ bzr bench-gc bzrlib/builtins.py --reverse
<jam> Compressed 1837 texts with 210568735 bytes to 21061973 bytes (10.00:1) in 84.286s
<jam> lifeless: ^^ that is down from the 113 that I posted last commit
<Odd_Bloke> jelmer: How have your experiments with using autoppa on sid been going?
<jelmer> Odd_Bloke, patched a couple of things then got stuck trying to build bzr-svn
<jelmer> I haven't looked at it since, not sure how hard my last problem was to fix
<lifeless> jam: cool; I have pushed a merged version of the previous
<jam> next tweak drops it to 73s
<spiv> poolie:
<spiv>     * Knit format repositories are deprecated and bzr will now emit
<spiv>       warnings whenever it encounters one.  Use ``bzr upgrade`` to upgrade
<spiv>       knit repositories to pack format.  (Andrew Bennetts)
<spiv> poolie: is that NEWS entry ok with you?
<poolie> looks good
<lifeless> jam: 2% in time.clock()
<jam> lifeless: yeah, I'm taking that out now
<lifeless> and 12% in flush_range
<jam> lifeless: well, also be aware that lsprof "lies" and makes python functions much slower than they really are while not skewing the compiled functions.
<lifeless> jam: I know :)
<jam> but yeah, for 'builtins.py' you end up with 1837 texts, 1734373 calls to find the longest matching sequence for a given line, and 1727645 calls to 'flush_range'
<jam> lifeless: so it turns out that for builtins.py one of the major overheads was just reallocating the array of output lines
<jam> I changed "realloc()" to give myself some fudge room
<jam> and things got a lot faster
<jam> I probably am giving a bit too much room
<poolie> hello jam
<jam> but it went from 60s => 20s for builtins.py
<jam> poolie: hi
<lifeless> jam: nice
<jam> lifeless: I wish it was easier to profile Pyrex code, though
<lifeless> jam: gprof?
<lifeless> or oprofile
<jam> lifeless: well, I went for the "time.clock()" solution :)
<jam> the one thing I like about time.clock() is that it doesn't usually interfere with real-world time as much as some of the other solutions.
<jam> But thanks for the quote spiv
<jam> :)
<spiv> jam: It made me smile :)
<jam> lifeless: so, if I assume that the lsprof values for C code are exact, and the values for py functions are grossly overinflated
<jam> For the 20s to recompress all of builtins.py
<jam> 13s is spent in get_longest_matching
<jam> NEWS takes 38.8s, with 31.4s in get_longest_matching
<lifeless> the quote ?
<jam> So it is still a large portion of overall time.
<jam> lifeless: Quotes page
<lifeless> oh :)
<jam> still, it is finally a net win
<jam> I was actually seeing a net *loss* for a while there
<jam> I just checked memory consumption for a second and got a bit frightened
<jam> recompressing NEWS was taking almost 800MB
<jam> and then I realized, that is just because my bench-gc code extracts everything first
<jam> I don't know why I'm getting 2x the raw bytes
<jam> any ideas?
<jam> (reverting to an older version shows identical memory usage)
<jam> lifeless: 'time bzr branch plugins/bzrtools gc-repo/bzrtools" 42s
<lifeless> hmmm
<jam> did you ever get anywhere with changing the insert order?
<lifeless> in progress
<jam> (time bzr branch bzrtools into a packs repo is 4.5s)
 * igc lunch
<lifeless> I'm trying to decide whether to alter GenericRepoFetcher
<lifeless> or do a custom
<jam> lifeless: I don't think you want to "generically" fetch in reverse topological order, do you ?
<lifeless> jam: I am considering having get_record_stream(versions, self.target._fetch_order, not self.target._fetch_uses_deltas)
<lifeless> jam: how much of that 42 seconds is in reconcile ?
<jam> lifeless: lsprof breaks it down (as 105s0 into: http://rafb.net/p/HxGoOe37.html
<jam> 51s in 'insert_record_stream'
<jam> 31s in 'fetch revision texts'
<jam> 9s in fetch inventory
<jam> 12s in 'item_keys_introduced by'
<jam> insert_record_stream is 18.7s in 'compress'
<jam> 23s in 'get_bytes', and 18s in 'get_record_stream'
<jam> and down around 4.4s spent in 'get_matching_blocks'
<jam> flush_range goes way up on topo-order insertions
<jam> because it finds lots of short matches
<lifeless> yeah
<jam> lifeless: so... if I understand all this correctly, the re-compression time is actually pretty trivial
<jam> versus the api mismatches going from Pack => GC repos
<jam> probably just because we have to go through the GenericRepoFetcher
<lifeless> somewhat yeah
<lifeless> I'd like to make the delta format more C optimised
<jam> I think the 18s total in compress, versus the 23s in get_bytes + 18s in get_record_stream kind of point to the major slow-down being the *extract from packs* side of things.
<jam> lifeless: I don't know how you feel about it, but I would recommend unifying bytes versus lines for "copy" versus "insert"
<lifeless> we also are extracting from the group we're inserting into
<lifeless> jam: yeah, i(byte-count)
<jam> lifeless: and you *might* consider special casing inserting a newline
<jam> It may not be a huge win
<lifeless> I'm thinking a pure C extract facility
<lifeless> well
<jam> but I was seeing 26,000 "i1\n\n"
<lifeless> I mean i(byte_count)[bytes] - no more \n after the isntruction, self delimited count
<lifeless> e.g. a qw counter, or variable-length bitfield
<jam> lifeless: sure
<jam> I'm not sure if that gives you a lot after zlib
<lifeless> could be
<lifeless> so the 26K i1\n\n is because those 4 bytes are cheaper than a c instruction for the same
<jam> lifeless: sure, but a "n\n" is 2x cheaper still
<jam> again, that would save... 52K bytes
<jam> but again, the entropy encoder may nuke that anyway
<jam> And it is only about 0.2% of the total output size
<jam> (before zlib)
<jam> lifeless: wow: Compressed 1837 texts with 210568735 bytes to 657272 bytes (320.37:1) in 22.620s
<jam> After using zlib over the whole stream
<lifeless> yes :)
<lifeless> jam: you see why the threshold is set at 20MB currently :P
<jam> lifeless: though that means that to get *any* of the texts you need to read 20MB, right?
<jam> Or were you thinking to use Z_SYNC_FLUSH so that you could read any subset
<jam> also, my result is slightly skewed, as I forgot the final flush()
<jam> still 318:1, though
<mwhudson> impressive numbers :)
<jam> bz2 only gets 325:1 on builtins.py
<lifeless> jam: you need to read 650K to get any text
<jam> well, builtins.py is only 170k ATM, so that is a bit extra
<jam> mwhudson: NEWS is a special case, but there I get 1391:1 compression :)
<jam> (NEWS being a *big* file that only has lines appended to it, so not a lot of churn, and a lot of redundant lines between versions)
<jam> interestingly after zlib, I'm at 380k for NEWS, while NEWS on disk is 258k
<lifeless> right, so possibly 10MB before starting a new group
<jam> so *almost* compressed down to 1:1 :)
<jam> I guess there is *some* churn in NEWS
<lifeless> there are a few full-content patches
<lifeless> where we realigned stuff
<jam> ah, sure
<jam> and changed the formatting to ReST, etc
<lifeless> so my basic idea is
<lifeless> to tune this
<lifeless> so that while we read a bit more its a single read for many parts of a tree
<lifeless> which should be a big win
<jam> lifeless: Sure, though I again wonder about Z_SYNC_FLUSH after every text inserted
<lifeless> and yeah not reading 600K for the front text
<jam> or maybe just periodically
<lifeless> well
<lifeless> I'd rather not TBH :)
<jam> as a lot of the "texts" are just tiny "c,X,Y" bits
<lifeless> I'd rather just add e.g. 50K to the current position
<lifeless> zlib has a 32K buffer
<jam> lifeless: well, I was thinking about doing it: 1) After the first text, 2) after zobj.compress() returns data
<jam> And I thought it was a 64k buffer
<jam> but I certainly could be wrong about that
<jam> anyway I need to go sleep
<lifeless> gnight!
<treeform> hi all i am trying to get bzr working on windows ... its always been pretty easy (thats why i use bzr) but it let me down this time.  If i install bzr-win-standalone i dont get paramiko support and i cant seem to install it any place inside its installation .... if i install the bzr for python that i allready have then i cant get to ti form the shell please help.
<jam> make sure to get my latest version
<jam> revno 51 is a pretty big win
<treeform> jam for me??
<lifeless> jam: 0.05seconds faster on my test-load :P
<lifeless> markh: ^
<lifeless> treeform: jam was talking to me
<treeform> thats ok
<treeform> 1.5 works
<treeform> and i submited bug report
<markh> treeform; I've an experimental binary you can try if you are keen.
<treeform> sure give me 1 hour thouh
<treeform> be back
<markh> ok
<jml> lifeless: hi
<jml> lifeless: do you mind if I add something about the "loom now shows current thread on status" to NEWS?
<treeform> markh: ok
<treeform> back
<treeform> what kind of binary you have?
<markh> treeform: http://starship.python.net/crew/mhammond/bzr-setup-1.6b4-mh1.exe is fairly recent, includes paramiko and works fine for me with ssl, and includes an experimental tortoisebzr
<markh> So I'd really like to hear it works for you too :)
<treeform> tortoisebzr !
<treeform> wpw
<treeform> wow*
<markh> I've actually got another with the svn plugin included, but I havem't uploaded that yet
<treeform> one of the big reasons my artists done like using bzr is because its command line
<markh> I ran out of time for bzr this week :(
<treeform> if you get the tortoisebzr to work that would be great!
<markh> yeah, it will, and hopefully soon :)  You should be able to checkin files using tortoise if they are on your local disk with that release - but its *very* early and need lots more "meat" before it could be recommended.
<lifeless> jml: please do
<markh> but - the non-tortoise bits of that release should be rock-solid!
<treeform> markh: what is missing from the tortoise?
<markh> too many things to mention :)
<markh> the list of what works is much smaller :)  the readme should let you know
<markh> but there is lots of hidden "framework" in place
<treeform> ok
<treeform> are you contributing to the tortoisebzr or just packaging it?
<markh> I'm the main contributor
<treeform> oh great
<markh> the packaging more fell in my lap ;)
<treeform> :)
<treeform> yeah that is how it goes
<treeform> i am checking out my codes base on this new windows install (the code is 300mb) so its going a bit slow as soon as its done i will install your version and see how it works
<treeform> markh: what gui tool kit does tortosebzr use?
<treeform> last time i remmber it was some thing odd like GTK
<treeform> GTK on windows ...
<markh> yeah, I think bqzr is a better fit for windows - native l&f
<markh> I'm not sure the old tortoise ever was released as a binary either
<treeform> bqzr -- google did not find any thing cool
<treeform> markh: could you fill me in on history of windows bzr tools?
<treeform> it looks like lots of starts and no finishes
<spiv> I think he means "qbzr"
<markh> so I now intend advocating qbzr to everyone who will listen so tortoise gets all enhancements "for free" :)
<treeform> explain ... are the projects related?
<lifeless> spiv: can I ring your house to get poolie ? :)
<spiv> lifeless: yep
<markh> yes, sorry, qbzr.  The history or tortoise is that it was a google SOC project that didn't quite get finished.  This one will - clearing hurdles like binary releases and gui toolkits is critical, hence that is being done before it is "finished"
<markh> qbzr and the gtk extensions are developed independently of each other, and without Windows in mind.  However, tortoise doesn't need to invent yet another toolkit, so has to choose a bandwagon to jump on :)
<treeform> so you are just doing a framework around explorer shell that integrates with qbzr?
<markh> yes - tortoisesvn for bzr
<markh> in effect
<markh> it turns out to require a remote "cache/command" process and an RPC mechanism, which is much of the "invisible framework" I mentioned.
<treeform> oh
<markh> short version of the story: we don't want python+bzrlib embedded in every process that uses the shell, so we have a lightweight shell extension and heavier  process the shell talks to
<treeform> ok
<treeform> markh
<treeform> so i do bzr checkout
<treeform> it throws an error
<markh> that's no good :(
<treeform> unrecognizedCommandError: checkout
<treeform> bzr branch worked
<markh> hrmph - its listed in "bzr help commands"?
<treeform> yes
<treeform> way more commands then i am used too
<treeform> there is no "qcheckout"
<treeform> but there is "qbranch"
<markh> oh - you mean from tortoise?
<treeform> no
<markh> hrm
<treeform> from cmmand line C:\p>bzr help commands
<treeform> lists bunch of commands
<treeform> and checkout is there
<markh> so yeah, I have no 'qcheckout' either - but 'checkout' works for me.  Not all commands have 'q' versions.
<treeform> yeah
<treeform> i am trying to check out through tortoise context menu
<treeform> i think the command line checkout should work
<markh> yes - cmdline checkout should work - but tortoise not working wouldn't surprise me ;)
<treeform> oh
<markh> I mean, tortoise getting as far as displaying the menu and trying to execute *something* is great news from my POV :)
<pygi> so somebody is working on tortoise again?!
 * markh is
<pygi> markh, nice, thanks
<pygi> how is it going?
<markh> we have a solid framework in place and now need to fill it out a little.  Its not ready to recommend its use, but its looking good with that in mind :)
<pygi> marianom, who's "we"? :P
<pygi> and how do I signup to help after I'm back from vacations?
<pygi> actually, gimme bzr branch :P
<pygi> that's the best way to signup :)
<treeform> pygi: marh gave me a binary
<treeform> i am testing it now
<pygi> binary? A python binary?
<pygi> markh, what did I miss? xD
<treeform> http://starship.python.net/crew/mhammond/bzr-setup-1.6b4-mh1.exe
<treeform> and installer with tools
<pygi> ah, bzr :P
<pygi> no idea, can't test, don't use windows :)
<markh> stand-alone binary.  See the tbzr project on launchpad - branch is there and contributions welcome :)
<markh> well, help on qbzr, as we are leaning on that :)
<pygi> I don't have much idea about qbzr, I know bzr-gtk tho :P
<pygi> but we'll see :)
<markh> bugger :)  I knew that would happen!  But qt really looks much slicker
<markh> and look-and-feel matters on windows.
<pygi> markh, I mentored creation of Olive in bzr-gtk so :)
<pygi> markh, hm...
<markh> yeah - sadly the gtk extensions were more mature, but the qt framework really looks nicer on windows
<markh> with help it could be user configured ;)
<markh> for many commands I am literally just calling the plugin
<markh> adding zero value to the process :)
<pygi> hehe :)
<pygi> markh, btw!
<pygi> I think there was/is a really slick gtk theme for windows
<lifeless> there is/was a 'win32' theme engine which uses native widgets
<pygi> lifeless, that might be it :P
<markh> I don't know much about gtk - but the gtk plugin on windows looks alot like pidgin and very obviously gtk
<lifeless> http://charupload.wordpress.com/2007/12/02/gtk-theme-engines-for-win32/
<pygi> that being said, as long as it's functional, users will be happy
<pygi> lifeless, thanks ;)
<lifeless> hmm that is not what I was thinking of
<markh> and to be quite honest, I mentioned things on the list and one person pointed me at QBzr due to its look and feel and noone disagreed.  I checked it out and agreed.  But if you can get a mini-revolt together saying the project would be better served with gtk, I'd be happy to go along with it :)
 * lifeless keeps looking
<markh> ie, I'm completely neutral in this :)
<lifeless> markh: I don't really care :P
<markh> yeah :)  I more meant pygi :)
<markh> anyone who wants to advocate one over the other can borrow my soapbox ;)
<pygi> markh, as long as people are happy, I'm good :P
<pygi> so no need for fight :)
<markh> me too - cool :)
<markh> hehe - or voilent agreement ;)
<lifeless> http://gtk-wimp.sourceforge.net/
<lifeless> thats it
<markh> I must tell the pidgin and bzr-gtk guys about it ;)
<lifeless> http://gtk-wimp.sourceforge.net/screenshots/gfx/Gaim-WinXP.png
<pygi> markh, about what?? :P
<lifeless> markh: is that screenshot what pidgin looks like today?
<lifeless> http://gtk-wimp.sourceforge.net/screenshots/gfx/xp.gif
<markh> can see that exact dialog, but pretty much, yeah
<lifeless> markh: ok, so perhaps pidgin is already using it :(
<markh> yeah, I think it might be - just some parts of it don't quite look native
<jml> file dialogs won't
<lifeless> won't what
<jml> look native
<luks> gtk buttons will never look native on windows
<luks> but that's gtk's fault, not wimp's
<markh> I wish the choice wasn't there to be had, and instead there was one that got everyone's energy ;)
<pygi> markh, ++ on that, but heh
<luks> they will never have exact sizes and usually they also have icons (but that's applications fault)
<kiorky> hellon i need some advice or experience toward bzr hosting. What i need is something like a centralized bunch of repository like we can had do with svn. I ve done something similar with mercurial and its forest extension. But with bazaar i m wondering what is the right way to have a bunch of repositories inside repositories and then serve them. Serving include control access like with sv authz format (on this purpose,  i ve seen something called 
<pygi> kiorky, in theory my best answer would be "cheezburger"
<pygi> in practice, that won't be available 'till end August or sometimes in September
<kiorky> pygi: is that usable in some dev branch?
<pygi> kiorky, no, that's only usable in my head sadly
<kiorky> or are they just planned
<kiorky> pygi: hehe
<pygi> kiorky, but it's indented purpose is exactly what you stated
<kiorky> pygi: so how launchpad is handling the whole?
<pygi> kiorky, I guess they have their own settings with ssh keys.
<kiorky> pygi: branch per dev/ lots of branches per repo
<pygi> kiorky, will be possible I'm sure
 * pygi notes all the use-cases :p
<lifeless> kiorky: so our forest equivalent is 'nested trees'
<pygi> kiorky, the important thing is to get that working, but also the other workflow with mainline repos
<lifeless> kiorky: but its immature
<kiorky> pygi: am i wrong to say that shared repositories are intended to have branches from the same project?
<lifeless> kiorky: shared repositories can handle arbitrarily large numbers of projects
<lifeless> kiorky: I have one with 13K branches, of 13K projects
<kiorky> pygi: not a/Someproject a/Otherproject
<lifeless> kiorky: that works fine
<kiorky> lifeless: ok, can i partially check out just one branch ?
<lifeless> kiorky: do you mean get just some subset of the files on disk ?
<kiorky> lifeless: yep
<lifeless> igc: has been planning a 'views' feature that will do that
<kiorky> repo has a/b a/c, just a/c
<kiorky> where b and c are two distinct branches
<lifeless> kiorky: if the repo has a/b and a/c as branches you can get just a/c
<igc> kiorky: filtered views will provide that
<lifeless> kiorky: 'repositories' are _just_ storage optimisation - they don't affect how branches work
<igc> see http://bazaar-vcs.org/FilteredViews
<kiorky> lifeless: so i can checkout a/c or a/c/d/e/f if c and f are branches isnt it ?
<kiorky> lifeless: is there anyway to serve that over http
<lifeless> kiorky: yes. if c and f are branches you can check them out
<lifeless> kiorky: sure, that will work over http just fine:
<lifeless> bzr init-repo a
<lifeless> bzr init a/c
<lifeless> mkdir a/c/d
<lifeless> mkdir a/c/d/e
<lifeless> bzr init a/c/d/e/f
<kiorky> lifeless: to continue, so each project can be a separate branch in my shared repository ?
<kiorky> lifeless: but then how can i centralize the adfministrative stuff ? ~/.bazaar/access.conf ?
<kiorky> lifeless: plan is to move my company over to bazaar
<kiorky> i m planning the new layout :p
<kiorky> going to work, see ya in something like one hour :)
<kiorky> and trhx
<lifeless> ok
<lifeless> see you when you get back
<pygi> lifeless, eh, so we need to automate all that magic with cheezburger =)
<lifeless> pygi: IcanHaz?
<pygi> lifeless, yes, ICanHaz easy bzr :P
<pygi> told ya I wanna contribute finally somehow, it's been a while since I contributed by mentoring :P
<pygi> can't play that card all the time =)
<lifeless> :)
<kiorky> lifeless: pygi re
<pygi> kiorky, re
<pygi> you've got my mail in pm
<kiorky> yep i saw it before leaving
<pygi> kiorky, great, so send me a mail pls with all your requirements in it? :)
<kiorky> pygi: yep, something like this evening or tomororow i think
<pygi> kiorky, thanks
<pygi> appreciate it
<kiorky> pygi: what i need is a layout similar to the onse i use for minitage
<kiorky> pygi: http://trac.minitage.org/trac/browser
<kiorky> pygi: http://hg.minitage.org
<pygi> well, let's hope you'll be able to have it then =)
<igc> night all
<pygi> night igc
<pygi> kiorky, gotta make the layout flexible somehow anyway
<kiorky> pygi: and after that we ll like to have something like automatic bundle buggy integration and etc
<pygi> kiorky, and loggerhead integration, I know
 * pygi would gladly work on this full-time, but since there's no so much time ... :P
<kiorky> pygi: you push a new branch inside the "big repo", from there it will inherit the acls you have defined somewhere, it will be integrated into the viewers (loggorhead, trac, whatever) and the project will be registrated with tools like PQM, bundlebuggy
<kiorky> pygi: hehe , as many of us
<pygi> kiorky, ok, so you just mentioned tasks for like 3 months for a start at least xD
<kiorky> pygi: and it can be served though http, push via ssh, and maybe webdav, but im not sure we can push over webdav with bzr
<pygi> kiorky, sure we can, but I'd rather avoid pushing through webdav
<kiorky> me either
<kiorky> but its somthing usefull through firewalls
<pygi> there is bzr-webdav plugin
<pygi> do firewalls really block ssh connections? o.O
<kiorky> yep , i saw it before, but i dont know its status unfortunatly
<pygi> kiorky, it's recently been fixed so  it works now
<kiorky> pygi: yep, maany corp firewalls allow outcoming traffics only on specific ports
<pygi> evil :p
<kiorky> so commiting when you are at work will be diffcult, there are ways to work around :p like making a ssh tnnel oer http with apcache proxy
<kiorky> then commiting your stuff :]
<pygi> hehe
<pygi> ah, ok
<pygi> noted as well
<pygi> gotta get the basics layed out first tho :P
<kiorky> pygi: i ll can help to contribute, im relasing minitage i think this week end
<kiorky> and i will freeze devs for a bit to regenrate ideas to continue
<kiorky> so i ll have some time
<pygi> right =)
<pygi> I'm gonna do a bit of coding next week, then vacation, and then some more coding :)
<pygi> but contributions are more then welcome
<pygi> you're the third person this week that needs this, so xD
<kiorky> pygi: for acls, bzr_access seems good for the prupose
<kiorky> but i just had an eye on it
<kiorky>  i ll test it
<kiorky> last time i did that for mercurial
<kiorky> i reimplemented it :p
<kiorky> ( http://hg.cryptelium.net/hg/system/config/hg/file/aeebb5a560c0/hg-ssh/hg-ssh )
<kiorky> pygi: hte plus i have with zr is the really good jelmer's bzr-svn
<kiorky> pygi: i cant do that with hg :p
<pygi> kiorky, bzr_access can be used as a start for defining permissions, sure
<kiorky> pygi: on top of the script, i use posix acls to define file access
<pygi> we'll see =)
<kiorky> pygi: the configuration file is parsed with http://hg.cryptelium.net/hg/system/config/hg/file/aeebb5a560c0/hg-ssh/hg-ssh.aclmaker.py
<kiorky> pygi: and generate a shell script to set the acls :)
<pygi> :P
<pygi> what I was thinking for example is:
<pygi> bzr branch bzr@domain.com:repository/branch
<kiorky>   /B 3
<kiorky>  /B 3
<kiorky> rah
<pygi> hm?
<guyblak> I'm trying to use bzr + pageant + buildbot, and it works with from the commandline, but it keeps erroring out when buildbot is added to the mix, anyone have any suggestion where/how to fix this?
<lifeless> well, what error?
<lifeless> is pageant not found/some error logged in ~/.bzr.log ?
<j^> hi, after merging changes from another branch, trac-bzr 0.11 fails here with
<j^> NoSuchRevision: KnitPackRepository
<jelmer> j^, please file a bug
<pickscrape> Is igc here?
<bob2> it is 10pm
<james_w> pickscrape: he's probably sleeping
<james_w> or at least left for the evening
<pickscrape> Ah. The Bazzar success story he mailed to the mailing list about was the one I was doing
<james_w> I thought it might be
<pickscrape> The blog post was from a colleague of mine.
<james_w> did the switch go well?
<pickscrape> Very well indeed. It was a 27-hour working stint for me, but well worth it in the end.
<james_w> wow
<pickscrape> Yeah, I don't do that very often :)
<james_w> I'm glad it's working well for you though.
<james_w> were you the version control expert that was mentioned in the post?
<pickscrape> Yes, apparently I'm a guru. I didn't know that...
<LarstiQ> :)
<pickscrape> I've moved this company from CVS to SVN, then SVK and now bzr
<pickscrape> Hopefully I won't have to do it again :)
<uws> jelmer: ping
<uws> If I want to convert a SVN repo to bzr
<uws> and it has both trunk, tags and branches
<uws> how do I create a nice bzr repo from it?
<uws> jelmer: bzr init-repo  and then branching individual   svn+ssh://.../branches/foo  in there?
<uws> bzr branch svn+ssh://..../  works as well
<uws> but then I end up with trunk/, tags/ and branches/ in my bzr branch.
<james_w> you may want to try svn-import
<jelmer> uws: Hi
<jelmer> uws: Yeah, you probably want svn-import
<uws> jelmer: I'm trying that, but I fail in getting it to work
<jelmer> What error are you getting?
<uws> jelmer: the svn repo is    svn+ssh://...../path/to/svn/PROJECTNAME/{trunk/,branches/,tags/}
<uws> bzr svn-import --verbose --prefix=FOO svn+ssh://.../svn/FOO    fails
<uws> No Repository found at ....
<jelmer> Specify svn+ssh://.../svn without FOO
<uws> jelmer: no output
<jelmer> uws, what version of bzr-svn?
<jelmer> I did some fixes to this recently in the 0.4 branch, may work better withthat
<uws> ii  bzr-svn                        0.4.10-2                       Bazaar plugin providing Subversion integration
<jelmer> uws, is this a public repo?
<uws> jelmer: see /msg
<uws> (for the curious: I'm currently just branching the trunk/ and branches into a bzr repo instead of using svn-imort. that works)
<proppy> Hi, how do I drop a changeset (i.e: checkout a previous revision, and make a new changeset) ?
<proppy> do I need to branch to another directory ?
<LeoNerd> When you say drop, do you mean permanently forget you ever committed it?
<proppy> LeoNerd: yep, I accenditaly commit two changes in one changeset
<proppy> I want to split them
<luks> proppy: bzr uncommit
<LeoNerd> OK.. Well, I usually "bzr uncommit" to remove the top one
<proppy> ah nice
<proppy> I branched to previous revision
<LeoNerd> It forgets you committed, but leaves the workdir files just as they are... so a "bzr diff" will show all the changes again
<proppy> but I will use uncommit the next time I made the same mistake
<proppy> thanks
<uws> jelmer: still here?
<jelmer> uws, yep
<uws> The conversions and stuff have worked out pretty well
<uws> I've even convinced $colleague and $project_lead to make the switch official
<uws> so after I've setup an (internal) wiki page and prepared backup stuff, my project is officially hosted in bzr :)
<uws> jelmer: One problem though
<uws> for now we want to keep SVN in sync (for a little while)
<uws> but pushing one of the bzr branches (with a few commits already with some merges) back to SVN crashes bzr-svn
<uws> bzr: ERROR: svn.core.SubversionException: ("Failure opening '/SOMEUNRELATEDPROJECT/trunk'", 160016);
<uws> jelmer: This is the same SVN repo I told you about in /msg, i.e.   /path/to/svn/PROJECTNAME/{trunk/,tags/,branches/}
<uws> (so the SVN repo is shared between projects)
<jiho> hi everyone. Is that http://pastie.textmate.org/private/xqpf8v7jntqmbocs6tvza only happening to me or is it a known bug?
<jiho> I am using bzr 1.5
<james_w> hi jiho
<james_w> could you run "bzr -Derror diff" and pastebin the output please?
 * jiho pasted http://pastie.textmate.org/private/fgnjmiofirydr9i4dka
<jiho> here it is â
<spiv> Ooh, up arrow.  Fancy :)
<jiho> yes I love that ;)
<james_w> ah, you have lessdiff installed
<spiv> jiho: that error appears to be caused by the lessdiff plugin you have installedc
<james_w> I'm guessing you don't have "less" installed though
<jiho> argh
<spiv> jiho: I'm betting that if you try "bzr --no-plugins diff" the error won't occur.
<jiho> less? as a plugin or the actual less command?
<spiv> (obviously it won't use the lessdiff plugin either)
<spiv> jiho: the traceback says it's happening when the lessdiff plugin tries to do os.execvp(pager, [pager, '-R', '-'])
<spiv> jiho: so, the actual less command (or whatever pager the plugin is trying to use)
<jiho> ok I've found the issue
<jiho> sorry, nothing to do with bzr
<jiho> my $PAGER was set to "less -R" (to try and get git to wrap those %$\* lines, which did not work by the way)
<james_w> no problem
<spiv> Hmm.
<james_w> lessdiff should handle that though probably.
<jiho> so lessdiff was trying to find the command "less -R"
<spiv> It might be nice if bzr warned when errors are raised from inside a plugin, (i.e. the traceback includes a file inside the plugin path).
<spiv> I'll file a wishlist bug...
<philn> hello fellow hackers of the branches
<jiho> james_w: I've sent an email to lessdiff devs about that
<philn> i'm trying to branch lp:bzr-svn but i get this: http://pastebin.ca/1082570
<philn> with bzr 1.6 beta3
<james_w> jiho: great, thanks
<philn> jelmer: ?
<Peng_> philn: I think bzr-svn's branches are in a different repo format.
<Peng_> jelmer: Augh, you push --overwrite lp:bzr-svn too much.
<james_w> philn: I can't access pastebin.ca, could you stick it somewhere else, or paste the most important line here please?
<philn> http://pastebin.ubuntu.com/30298/
<james_w> thanks
<james_w> philn: could you run "bzr info" please?
<philn> Shared repository with trees (format: pack-0.92)
<Peng_> bzr-svn uses rich-root-pack.
<philn> is there a troubleless way to convert my repo?
<Peng_> So, you need to bzr init-repo --rich-root-pack and branch into that.
<Peng_> philn: You shouldn't convert your entire repo.
<philn> ok i'll start a new one then
<Peng_> Blah, my copy of bzr-svn is still pack-0.92-subtree.
<Peng_> philn: Just put bzr-svn in its own, rich-root-pack repo.
<philn> kthx
<philn> next one: http://pastebin.ubuntu.com/30303/
<pickscrape> Would a weekly cron job to bzr pack our server repositories be sensible?
<spiv> Well, basically harmless :)
<spiv> It might improve performance slightly and keep the autopacks a little bit smaller, I guess, but don't expect any dramatic changes.
<spiv> But cron jobs are cheap, so why not... it won't hurt.
<pickscrape> I wasn't looking to do it for improvements, mainly to prevent performance degradation.
<spiv> Well, the autopacking that happens automatically should prevent most of the degradation.
<pickscrape> Oh, I didn't know it happened automatically. Does that apply to remote repositories too?
<spiv> Yeah, it does it silently.  It does happen to remote repos too.
<spiv> Which can sometimes be a bit slow, because it has to download the packs it will combine, then reupload the same data.
<luks> even over bzr+ssh?
<spiv> But autopacking is gradual, so even when it does kick in most of the time it doesn't need to rearrange much of the repo.
<spiv> luks: currently, yes.  I sent a hackish patch to the list a while back to do it smarter.
<spiv> I hope to get back to that quite soon.
<pickscrape> I suppose it won't hurt to set up that cron job then :)
<luks> pickscrape: well, it will try to autopack regardless :)
<luks> hm, actually maybe no, 'bzr pack' creates just one pack?
<pickscrape> Yeah, but if there's less to do, that's less time for the user to hang around, which means less likely I'll be asked what's wrong :)
<jelmer> re
<jelmer> uws, that should be fixed in the 0.4 branch
<jelmer> uws, will hopefully be released within the next two weeks (parallel with bzr 1.6)
<Peng_> pickscrape: Your cronjob will use more disk space. When packing is done, all of the old packs are moved to .bzr/repository/obsolete_packs. When an autopack is done, it's just a few of the most recent packs, so not much disk space is wasted. But when "bzr pack" is done, it's *all* packs, so it will almost double the size of .bzr/repository.
<philn> jelmer: using trunk of bzr and bzr-svn i get this: http://pastebin.ubuntu.com/30306/
<Peng_> pickscrape: (Err, by "old packs", I meant "packs that are deleted".)
<pickscrape> Peng_: won't that maintain itself over time though? i.e. existing obsolete packs get removed when packing?
<Peng_> pickscrape: Oh, yes.
<luks> pickscrape: replaced, not just removed
<uws> jelmer: ok, great
<pickscrape> I'm not overly concerned about that: the server isn't short on disk space.
<Peng_> pickscrape: Okay, then. I just wanted to warn you.
<uws> jelmer: do you want a traceback to be sure?
<pickscrape> Peng_: thanks :)
<jelmer> uws, never hurts :-) can you privmsg one?
<uws> jelmer: sure
<jelmer> philn, hi
<jelmer> philn, what's the repository format you're trying to branch into?
<philn> jelmer: i think my installed bzr could be conflicting with the uninstalled bzr trunk i (try to) use
<jelmer> philn, looks like this is a regression in bzr.dev
<pickscrape> Does the bzr unit test infrastructure extend to plugins?
<philn> jelmer: i'm removing my installed bzr
<Peng_> pickscrape: Yes.
<Peng_> (Well, I think.)
<jelmer> philn, I'm filing a bug
<jelmer> pickscrape, yeah
<pickscrape> How do you tell it to just run the tests in a given plugin?
<philn> jelmer: ok i get same error :/
<jelmer> philn, where did you revert to?
<jelmer> pickscrape, bzr selftest --starting-with=bzrlib.plugins.PLUGINNAME
<philn> jelmer: i removed my installed bzr pkgs (installed via the ppa)
<pickscrape> jelmer: Ah, I'd suspected that, but wondered if there was a more direct method. Thanks, I'll have a play :)
<jelmer> philn: what version of bzr are you using then?
<philn> jelmer: trunk
<jelmer> philn, that's pretty much the same as 1.6b4 atm I think
<jelmer> philn, you'll need an older revision on bzr.dev from before poolie's stacking fixes landed
<cr3> when I try to branch a private project from LP, I get: bzr: ERROR: Not a branch: "https://code.launchpad.net/".
<Peng_> cr3: It's not.
<Peng_> cr3: Use the lp: URL.
<cr3> Peng_: I did use the lp: url, but that's the error it prints :)
<Peng_> Which bzr version, and which exact command did you run?
<cr3> Peng_: Bazaar (bzr) 1.3.1 and: bzr branch lp:~hardware-certification/hwtest-certify/trunk
<Peng_> I get 'Not a branch: "bzr+ssh://<my username>@bazaar.launchpad.net/~hardware-certification/hwtest-certify/trunk/"'
<Peng_> https://code.launchpad.net/~hardware-certification doesn't list any such branch.
<Peng_> OTOH, when I try to visit hwtest-certify, I get a 403 Forbidden, so I might just not be allowed to see it.
<Peng_> cr3: Have you run 'bzr launchpad-login your_username'
<Peng_> ?
<cr3> Peng_: that worked, but the error message is not obvious
<Peng_> Indeed.
<Odd_Bloke> cr3: File a bug please. :)
<beuno> Peng_, lp:~beuno/loggerhead/new_theme
<Peng_> beuno: Hmm.
<beuno> no
<beuno> wait
<cr3> Odd_Bloke: reported bug #251956
<ubottu> Launchpad bug 251956 in bzr "Unobvious error message before calling launchpad-login" [Undecided,New] https://launchpad.net/bugs/251956
<Peng_> cr3: Some of the related error messages have been improved since 1.3.1, but branch-exists-but-is-private may just have never been thought of.
<cr3> there was already a bug when branching unexisting projects, this is for a private project
<beuno> Peng_, pushing somewhere public now  :)
<Peng_> beuno: Why the secrecy?
<cr3> Peng_: makes sense, private projects are not common under Launchpad
 * Peng_ feels left out.
<beuno> Peng_, not me call  :)
<Peng_> beuno: Does it work with bzr.dev?
<beuno> Peng_, yeap
<Peng_> OK. Just wanted to check.
<beuno> Peng_, https://code.edge.launchpad.net/~beuno/loggerhead/new_theme_trunk
<Peng_> Can you just make the other branch public?
<beuno> Peng_, the ther branch is uninterestingly different
<Peng_> Any URLs changed?
<beuno> nope, it's trunk with a new theme
<beuno> Jc2k, you may me interested in  ^
 * Peng_ is still curious what the other branch is. :P
<beuno> although we should probably try to integrate it with the Gnome headeer
<beuno> Peng_, same branch, different colors
<beuno> I promise
<Jc2k> beuno: :O
<Peng_> Augh!
<beuno> Jc2k, take it for a spin, and, if youm like it, I'll try and have a gnome branch for that
<beuno> mwhudson, it's out  :)
<Peng_> After I changed all the files but before I restarted LH, I got a hit, and SimpleTAL decided to flood my log with errors.
<Peng_> Haha, it did it 9300 times.
<beuno> nice round number
<Peng_> Also, because I was surpised by that, there were over 2.5 seconds of downtime while I restarted it, totally ruining my average. :(
<Peng_> Anyway, on-topic, the new theme works, and it seems pretty nice.
<Peng_> No more Bazaar and LH logos at the bottom?
<beuno> ah, we should probably have those on there again, yes
<Peng_> Is performance different?
<beuno> there are no major reasons for it to be different
<beuno> probably less HTML
<beuno> so it may improve a bit
<beuno> the diffs are the biggest improvement for me
<Peng_> Honestly, I've never been a huge fan of having little icons everywhere, or smooth (un)collapsing.
<beuno> can you still find everything?
<Peng_> I think so.
<beuno> I've just proposed to merge this intro trunk, so if you find any blockers, let me know  :)
<Peng_> Well, the missing Bazaar logo, obviously... :P
<beuno> I'll add those on now
<Peng_> Everything seems okay, but I don't have a lot of experience using LH anyway.
<beuno> Peng_, cool, thanks
<beuno> once this lands, I can focus on features again
<Peng_> Hmm, I want to compare performance with one of the slower pages.
<Jc2k> beuno: don't suppose there is one running i can peek at?
<beuno> Jc2k, maybe Peng_ can let you peak at his?
<beuno> if not, I'll try and run locally
 * Jc2k hopes no one ever reads that sentence stand alone....
<Jc2k> xD
<Peng_> Woah: Rendering RevisionUI: 141.52576088905334 secs, 96439309 bytes, 42448684 (44.0%) bytes saved
<Peng_> Jc2k: http://bzr.mattnordhoff.com/loggerhead/imports/lighttpd/lighttpd-1.4.x/changes
<Jc2k> tasty
<Peng_> Am I misreading, or was that 40 MB of whitespace?
<Jc2k> beuno: that is very much WIN WIN WIN
<beuno> Peng_, is that faster or slower then before?
<beuno> Jc2k, so I should go ahead and do a gnome version of that?
<Jc2k> indeed =)
<Peng_> beuno: I don't know; I was just grepping my logs for slow pages.
<Peng_> beuno: I'm testing a smaller on right now.
<Peng_> one*
<Peng_> Not hugely scientific though.
<Peng_> Err, oops. It wasn't a very large page; it was just generating the annotate information that was slow. Anyway, the old one was 2.3 seconds, and the new one 1.3, and the sizes were 800k vs. 600k, I think.
<beuno> :)
<beuno> mwhudson, ^
<Peng_> Generating the annotate information was slightly faster too, oddly.
<Peng_> (13 seconds vs. 14-15.)
<Peng_> Actually, 13.0 vs. 14.9, I think
<Peng_> I'm afraid to try to render that 90 MB page.
<beuno> heh, I would too
<Peng_> OTOH, I've been known to be stupid. Hold on.
<Peng_> I mean, it managed to render before.
<Peng_> So far, it's using 44.7% of my VPS's RAM.
<Peng_> Seemed to peak there.
<Peng_> beuno: Dude, another page just tracebacked.
<beuno> Peng_, hmmmm, what traceback?
<Peng_> beuno: Here's what I could get of it: http://paste.pocoo.org/show/80322/
<beuno> hrmm...
<jelmer> hi beuno, Peng
<beuno> hey jelmer
<jelmer> beuno, Any news on the Debian upload of bzr-upload?
<Peng_> Argh.
<beuno> jelmer, no, sorry. Can you get it sponsored by someone else?
<jelmer> beuno, I'll ask around
<Peng_> It may have been the really gigantic page.
<jelmer> beuno, the number of DD's around here seems to've decreased :-(
<beuno> Peng_, is it a public branch?
<beuno> jelmer, yeah, and my favorate DD is procrastinating more than usual
<Peng_> Hmm.
<Peng_> For that really gigantic page, it took close to 4 minutes, and only downloaded 1.5 MB. So I guess it's the one that died.
<Peng_> beuno: Yeah. Googlebot has been indexing one of my trivial bzr branches.
<Peng_> Interesting, this time it downloaded that much after 30 seconds.
<Peng_> ...And I see that traceback again. So I guess it is that page.
<Peng_> Confirmed, it's this page: http://bzr.mattnordhoff.com/loggerhead/bzr/configobj-4.5.2/revision/1551.19.24?start_revid=aaron.bentley%40utoronto.ca-20071221022516-hd721fevdx6o7h8i&remember=1551.6.25&compare_revid=1551.6.25
<Peng_> beuno: ^
<Peng_> Hold on, I'm gonna revert to the old theme.
<beuno> Peng_, it renders fine, but gives you the traceback?
<Peng_> I dunno.
<Peng_> I thought that was the page that used to be 90 MB.
<Peng_> Switching to the old theme, it downloaded 51 MB (which is the size of the page after trimming whitespace).
<Peng_> So yes, the new theme is doing something wrong.
<Peng_> And there's no way in hell I'm gonna try to visit either of them in my browser. :P
<Peng_> Switched to the new theme again.
<beuno> ok, so the new theme is generating 90mb against 50mb for the old one?
<Peng_> No, the old theme generated 90 MB, which the whitespace stripper reduced to 50 MB. The new theme generates 1.5 MB and a traceback.
<beuno> ah, I see
<beuno> the new theme will generate smaller pages, that's for sure
<beuno> it doesn't do a lot of stupid things, and, it doesn't generate the diffs twice
<beuno> now, we need to fix that traceback...
<beuno> Peng_, can I can grab that branch from somehere?
<Peng_> (Note: I'm running the old theme again, so don't try to visit that URL...)
<Peng_> beuno: http://bzr.mattnordhoff.com/bzr/bzr/configobj-4.5.2/ -- it was merged with bzr.dev months ago, so bzr.dev would probably work too.
<beuno> Peng_, cool. I'll try revid aaron.bentley%40utoronto.ca-20071221022516-hd721fevdx6o7h8i
<beuno> Peng_, revid aaron.bentley%40utoronto.ca-20071221022516-hd721fevdx6o7h8i  doesn't give me a traceback
<beuno> and it's 56k
<Peng_> (OK, I can confirm those are the same revisions in bzr.dev.)
<Peng_> What does compare_revid do? Those two revisions are 1.5 years apart, so they're vastly different...
<beuno> Peng_, diff between the two revids
<Peng_> So It's doing an 18-month diff. No wonder it's slow.
<beuno> ok
<beuno> I found the traceback comparing  :)
<beuno> yes, it's probably not the best of the ideas
<Peng_> Heheh.
<Peng_> Poor Googlebot.
<Peng_> I should block it from doing arbitrary diffs.
<beuno> right, once it get remember= on the URL
<beuno> it'll take it with him through the whole branch
<beuno> not so smart of us
<Peng_> Think I should block remember= then?
<beuno> yeap
<Peng_> Or just compare_revid?
<beuno> remember
<beuno> there is no reason for Google to use remember
<Peng_> Without checking myself, what does compare_revid do on annotate?
<beuno> I have no idea   :)
<Peng_> It looks like compare_revid has been used on annotate, atom, changes, files, and revision.
<Peng_> Does LH sometimes just append the current URL's query string to all links?
<beuno> no, it's a bit less stupid about that
<beuno> not terribly smart yet though
<Peng_> 'remember' has been used on annotate, atom, changes, download, files, and revision.
<beuno> we want to get of remember all together
<Peng_> BTW, would filter_file_id ever be useful to Googlebot?
<beuno> it's the changes that have been amde to that specific file
<beuno> so probably
<Peng_> I already disallowed it on most pages, just not sure if it was all of them.
<Peng_> Oh, I didn't disallow it on atom.
<Peng_> I did on annotate, changes, files, and revision.
<jelmer> hi colbrac
<colbrac> hi
<colbrac> I'm checking the tick patch..
<colbrac> since I don't know how to test I'll leave it at eyeballing
<beuno> Peng_, you'll have to terach me some day to debug how you do  :)
<colbrac> jelmer: Only the ProgressPanel gets the tick()?
<jelmer> colbrac, what else should have it?
<colbrac> jelmer: The ProgressBarWindow?
<Peng_> beuno: Have you figured it out?
<colbrac> (I don't know exactly what a tick() does.. :P)
<beuno> Peng_, not yet, no. It's the content of the diff of some bzr change in the last 18 months  :)
<colbrac> jelmer: And why give ProgressPanel all that *args **kwargs when GtkProgressBar.tick takes no input? (def tick(self))
<jelmer> colbrac, allows us to not worry about it when GtkProgressBar.tick takes args in the future
<colbrac> jelmer: ok makes sense. :).. but what about the ProgressWindow?
<jelmer> colbrac, I didn't hit this problem with ProgressWindow yet but it does indeed make sense to add tick there as well
<colbrac> ok I'll tweak you then :)
<colbrac> done
<jelmer> thanks
<jelmer> beuno, what's the right address to send loggerhead merge requests to?
<colbrac> so.. how to test the seahorse patch? killall seahorse?
<beuno> Peng_, fixed, I'll push now. It's 14mb with the new theme  :)
<Peng_> beuno: Oh, great. What was the issue?
<beuno> jelmer, you can either sent it to the bzr list, or file a merge request to a branch through LP
<beuno> Peng_, the way I mangle strings now to be able to but them into nice little pieces to fit the screen
<Peng_> beuno: Err, what?
<Peng_> beuno: That size reduction is *really* great. :)
<beuno> Peng_, itgoes down from 114sec to 51 for me
<beuno> Peng_, if you see at the diffs now, they all fit on screen, instead of going way outside of it
<Peng_> Oh, line wrapping?
<beuno> that makes it sound less magical, but yes
<lifeless> ROTFL
<Peng_> Heheh.
<lifeless> several weeks of work reduced to 'Oh, line wrapping?'
<Peng_> Haha, sorry. :P
<beuno> exactly  :)   I was thinking about inventing a new term for it, but it seems I lack marketing skills
<Peng_> Pushed yet?
<colbrac> jelmer: How is seahorse used? Only in bzr sign-my-commits?
<beuno> Peng_, no, triple checking I didn't break something else
<jelmer> colbrac, to display revision signatures in viz
<colbrac> ok..
<colbrac> on a separate matter.. when I did 'bzr sign-my-commits' mentioning of all 56 commits of mine in trunk flashed by with a nice 'need passphrase to unlock key' message.. and afterwards bzr declares my commits signed :S
<beuno> Peng_, pushed
<beuno> jelmer, thanks for the patch, I'll apply it now
<beuno> hopefuly, that means you'll package LH once we release 1.6   :)
<jelmer> I've already packaged it
<Peng_> Hm.
<beuno> jelmer, cool!  do you have an ITP on it yet?
<jelmer> I'm waiting for the other packages I have pending to be sponsored first though
<Peng_> beuno: I still don't see antyhing to pull. lp:~beuno/loggerhead/new_theme_trunk, right?
<beuno> Peng_, argh, sorry, stupid 2 locations for everything
<jelmer> beuno, new_theme looks much better...
<beuno> jelmer, :)
<Peng_> beuno: OK, pulled
<colbrac> jelmer: I approved the seahorse patch. bzr vis nicely starts seahorse-daemon when I kill it beforehand.
<colbrac> jelmer: But now I have the issue that I signed all my commits on trunk.. with the main ID of my key instead of the launchpad/bzr-gtk ID
<beuno> Jc2k, if Peng_ can't break anything in the next 10 minutes, I'll try and port the gnome theme to it
<colbrac> jelmer: at least.. all broken seals :/
<beuno> Peng_, the new theme seems to use less memory for me in general  (probably due to generating smaller files)
<Peng_> Haha. I do manage to break things a lot, don't I?
<Odd_Bloke> Users, who needs 'em? :p
<Peng_> beuno: The massive diff page took 2:20.95. Rendering RevisionUI: 130.14956402778625 secs, 81780815 bytes, 44947311 (55.0%) bytes saved.
<Peng_> That's great; my last record for whitespace savings was 46%.
<Peng_> beuno: That's...35 MB downloaded, vs 51.
<beuno> cool, because that can (and will) be reduces quite a lot soon
<jam> Peng_: of course, if you put mod_gzip in front of that like a good boy, it wouldn't really matter
<beuno> I have evil plans to drop sqlite cache, and other ajax bling
<Peng_> jam: Yeah. I'm running Lighttpd 1.4, which doesn't support compressing dynamic content. 1.5 does.
<Peng_> I have 1.5 running; maybe I should have my main 1.4 proxy to it, then have it proxy to LH.
<beuno> Peng_, how's memory usage?
<Peng_> beuno: Seems about the same
<Peng_> But I've also received a few other requests, of course.
<Peng_> It might be 6 MB lower.
<beuno> not significant
 * Peng_ restarts LH to save RAM.
<colbrac> jelmer: Can you probe subkeys in seahorse.py line 239?
<jonnydee> Hi :)
<jonnydee> I'm just playing around with Bazaar and stumbled over a question...
<jonnydee> What happens when I create a shared repository within a shared repository?
<jonnydee> Bazaar seems not to complain
<radix> jonnydee: the innermost one will be used for any operation
<radix> or "nearest"
<jonnydee> aahh... ok I see
<jonnydee> And are there scenarios where creating such nested repositories makes sence? or is this approach not a recommended one
<jonnydee> btw thanks for you quick answer :)
<NfNitLoop> jonnydee: The only problem I know of is that the outer repository doesn't really know anything about the inner one.
<jonnydee> ok, I got it :)
<NfNitLoop> So if you ever need to check out a previous state of your project...
<NfNitLoop> you'd have to roll back each separately.
<jonnydee> I understand now...thanks :)
<jonnydee> But just another short question:
<jelmer> re
<jonnydee> In http://bazaar-vcs.org/SharedRepositoryLayouts there is mentioned a concept "container directory"
<jonnydee> used in shared repositories without trees
<jelmer> colbrac, I don't have a line 239 in seahorse.py
<jonnydee> is it just a normal directory? I mean without a .bzr subdirectory?
<colbrac> jelmer: Doh.. revisionview.py I mean
<NfNitLoop> jonnydee: the "container directory" on that page refers to an SVN repository.
<radix> NfNitLoop: wait, what? what do you mean rolling back each separately?
<colbrac> where you look up the key.get_display_name()
<radix> if you're using an inner repository, an outer one isn't touched at all; they're completely separate
<NfNitLoop> radix: right....
<NfNitLoop> radix:  I just mean they're not in sync with each other.
<NfNitLoop> radix: you can't just say "I know this was working X revisions ago, let me get that...."
<radix> why not?
<NfNitLoop> because your inner repositories may have changed too.
<jonnydee> Yes I understand, but there is a section "So the preferred way for Bazar would be:"
<radix> hold on a second
<jelmer> colbrac: I guess we could add a "has_uid()" function rather than using get_display_name()
<radix> NfNitLoop: I think you may be confusing repositories and branches
<radix> I'm pretty sure jonnydee is talking about shared repositories, not nesting branches themselves
<NfNitLoop> radix: I think I'm just misusing the terms, but I know the difference.
<jonnydee> And this section shows a layout with "A container directory"
<NfNitLoop> radix: he's actually talking about both.
<NfNitLoop> radix: in separate questions.
<colbrac> jelmer: Yes please :)
<jelmer> colbrac, any chance you can file a bug? I don't have time to look at the moment but it'd be nice if it wouldn't be forgotten
<NfNitLoop> jonnydee: aah.  Yes, there "branches" is just a normal directory.
<beuno> Jc2k, https://code.edge.launchpad.net/~beuno/loggerhead/new_theme_gnome
<jonnydee> right NfNitLoop - it was a separate question -- i'm sorry for any confusions
<colbrac> jelmer: Will do
<NfNitLoop> jonnydee: bzr will keep going up a directory (..) till it finds one containing .bzr and it will use that as the shared dir.
<NfNitLoop> jonnydee: so you can structure your branches however you like.
<jonnydee> thanks NfNitLoop -- that's exactly the information I need :)
<NfNitLoop> personally, I just have project/, which contains trunk/, branch1/, branch2/, etc.
<NfNitLoop> I don't see a need to separate everything out that is not trunk.
<jonnydee> I just have one another question regarding repository layout...
<NfNitLoop> My directory structures are already deep enough, thanks.  ;)
<NfNitLoop> jonnydee: ask away.
<jonnydee> Can a shared repository also act as a branch? One of the listed repository layouts seems to suggest this...
<jonnydee> project/             # The overall repository, *and* the project's mainline branch
<NfNitLoop> ermmm....
<Peng_> jonnydee: Yes, but that's really weird and yucky.
<NfNitLoop> Yeah.  If it can, I wouldn't.
<jonnydee> (But I do also prefer listing the mainline as trunk anyway)
<NfNitLoop> Probably don't want to mix your working tree and your branches.  would get confusing fast.
<jonnydee> Yes that's really weired..
<beuno> lifeless, are you running LH trunk on squid?
<beuno> looks like you're not
<jonnydee> I just was surprised bazaar can handle such a situation. I tried it out and it seems to work... But anyway, it's really confusing... so I will not use this feature
<jonnydee> Thanks a lot for your help :)
<colbrac> jelmer: 251992
<jelmer> colbrac, thanks
<jonnydee> Have a nice day / night ;)
<tsculpt> jonnydee: How did you get a shared repo to act like a branch?
<jonnydee> I did:
<jonnydee> bzr init-repo project
<jonnydee> cd project
<jonnydee> bzr init
<NfNitLoop> *shudder*
<jonnydee> I wanted to reproduce the mentioned scenarion from the tutorial so I tried this and played around a bit and it seems to work...
<tsculpt> so you init'd it a second time like you would an empty branch
<Peng_> Sure, it works, it's just awful.
<jonnydee> but ... yes *shudder*
<tsculpt> yuk
<tsculpt> it still acts like a shared repo too?
<jonnydee> @tsculpt: yes i did
<LarstiQ> why not? just colocation
<jonnydee> yes it seems to act as a shared repo
<jonnydee> I looked at the size of the .bzr directory after i added some files to a branch within that shared repo
<tsculpt> so you could merge a whole collection of branches at once?
<NfNitLoop> tsculpt: no...
<jonnydee> that's a goog question.... but I don't think this is possible
<NfNitLoop> the root is still only one branch.
<NfNitLoop> but it is also a shared repo.
<tsculpt> ah
<tsculpt> well, I'm new at this, but like it a heck of a lot better than svn
<NfNitLoop> tsculpt: Yep.  Doesn't it make you wonder why anyone still uses anything else? :p
<jonnydee> the same accounts to me -- I wish I could convince my company to use Bazaar instead of svn
<NfNitLoop> jonnydee: well, bzr has a way to go to catch up to all of the tools offered that are compatible with svn.
<jonnydee> well, I'm still trying...
<NfNitLoop> Hell, we still use CVS because our ancient software speaks CVS.  >.<
<jonnydee> ok, that's a good point NfNitLoop -- so I should be happy with our current situation
<NfNitLoop> jonnydee: yeah, at least with SVN you can use bzr-svn for your own work. : )
<jonnydee> I tried to use bzr-svn to talk with our svn repo, but it screwed up the repo
<jelmer> jonnydee, in what way?
<tsculpt> I really like the idea of using task branches like crazy, seen the merges are so easy
<jonnydee> however, I think there was a problem with wrong versions of svn, bzr and bzr-svn...
<NfNitLoop> jonnydee: it messed up the svn repository?  I haven't seen that....
<jelmer> jonnydee, Inconsiste versions may cause a traceback but shouldn't ever cause corruption in your repo
<jonnydee> when I pushed my changes to the svn repo bzr exited with an error (sorry, can't remember the message)
<jonnydee> but after that I think/guess there was a hanging transaction within svn
<tsculpt> How do you backup your repos? With svn being centralized, I used a post commit hook that did incremental dumps, and I just collected those to be replayed in case the repo was lost.
<lifeless> beuno: not yet
<NfNitLoop> tsculpt: just "branch" or "push" your repo to another location.
<tsculpt> I imagin with a distributed system you could forgo that, and just push to a backup repo
<tsculpt> yeah
<jelmer> jonnydee: in the bzr or svn branch?
<jonnydee> the log history of svn showed only some of my commit messages I submitted previously to my local bzr repo and their order got messed up
<lifeless> beuno: waiting for a release
<jelmer> jonnydee, was this with released versions of bzr, bzr-svn and svn?
<beuno> lifeless, good, we should have one soon after 1.6 goes out the door. Just have 2 small remaining things to land
<jonnydee> in the svn branch I there were some revisions missing... I couldn't even retriev them using command line
<jelmer> jonnydee, bzr-svn will only push the mainline revisions in your branch, not the other revisions. Could that be it?
<NfNitLoop> jelmer: what's the difference between "mainline revisions" and "other revisions" in a single branch?
<NfNitLoop> it sounds like you're saying that things you merged in don't get pushed?
<jonnydee> there was only one bzr branch -- with other words I did not branch my local branch
<jelmer> NfNitLoop, yes, that's correct
<NfNitLoop> ...   !?
<jelmer> NfNitLoop, It does store references to those revisions though
<NfNitLoop> I'm curious as to why that is?
<jelmer> NfNitLoop: where would those revisions have to be pushed? They can't be on /trunk since that would cause the diffs between new revisions to be very confusing
<jelmer> it would also mess up the revision graph
<NfNitLoop> being able to create branches from your bzr-svn repo, make changes, merge them back into your "trunk", and then push them to svn seems like a common use case?
<jonnydee> anyway, I think there were incompatibilities: svn server was 1.4.x, my local svn client was 1.5, my bazaar client was 1.6beta2 (I think) and bzr-svn was the one for bzr 1.5
<jelmer> NfNitLoop, that works fine
<NfNitLoop> jelmer: ah, then I'm misunderstanding the difference between the two types of changes.
<tsculpt> Have you used svn-import to convert a svn repo to bzr?
<jonnydee> Solution was to dump svn repo to the revision that existed just before I did the bzr push operation and create a new repository by importing that dump
<NfNitLoop> tsculpt: yes, though it's been a while, I think I did branch?
<jelmer> jonnydee: it would be nice if you can file a report about this if you can still reproduce it
<jelmer> jonnydee, this would be the closest anybody has come to repo corruption using bzr-svn as far as I'm aware
<jonnydee> when bzr 1.6 and the corresponding bzr-svn versions are out I will first upgrade the svn serve to 1.5, too, and then I will give it another try
<jelmer> jonnydee, thans
<jelmer> *thanks
<lifeless> so jam will you be wowing?
<tsculpt> So I am moving my workflow to use, bzr and I want to know what you think..
<jonnydee> @jelmer: I would like to reproduce it, but I had a lot work to do in order to recover from this event. By rolling back the svn repo I also messed up our CI-Platform...
<jonnydee> Before I did the "push" I told my boss to try out the bzr-svn push. He asked me if it would be better to try it out on another temporary svn repo
<tsculpt> I see using three shared repos, one without trees (on a usb flash drive).
<jonnydee> And I said. Don't worry, you cannot screw up the svn repo by design...
<tsculpt> With work performed at two locations, sans communication with one another, I just push to the flash drive repo in a centralized sense
<tsculpt> and pull when arriving at the other location.
<jelmer> jonnydee: Do you have a bdb or a fsfs repo?
<jelmer> jonnydee: There are tools for the first to recover from a repo that's abandoned halfway (since that happens if the process that was accessing it dies)
<tsculpt> So at any one time there are at least two copies of the shared repo distributed
<jonnydee> fsfs -- And as AFAIK there cannot be hanging transactions...
<tsculpt> then no dumps or anything like with svn, just three distributed repos.
<jelmer> jonnydee, what was the error then though?
<jonnydee> @jelmer: can you point me out to such a tool? is it part of the svnadmin suit?
<jelmer> bzr-svn access subversion repositories through the standard Subversion API
<jonnydee> @jelmer: I assumed exactly this
<jonnydee> So I cannot understand why I had these problems...
<jonnydee> But be assured, when I encounter this problem again I will do a bug report -- I promise. I should have done this right when I encounter this problem, but I was just shocked and tried to recover from that problem.....
<NfNitLoop> jonnydee: well, and you were probably still in software-evaluation mode at that point.
<NfNitLoop> not so much bug-reporting.
<NfNitLoop> If I submitted bugs for every piece of software I tried out that didn't work as expected...
<NfNitLoop> well, I wouldn't have time to IRC.  :)
<jonnydee> yes, that's in fact true...
<jonnydee> But in case of Bazaar I will bug-report everything now, because I love this software. The more I use it, the more I like it!!! (And the more svn sucks... ;) )
<colbrac> jelmer: Please check your patches.. the olive - merge one has all the progress bar changes. And perhaps you can also add a set_icon_from_file(bazaar-64.png) while you are at it? (or something like that)
<jelmer> colbrac, Sorry, I seemed to've uncommitted one revision too few before I sent it in
<jelmer> colbrac: icon? How's that related to this?
<colbrac> :) changes to merge dialog
<colbrac> (hey.. I can try ;) )
<jelmer> :-)
<jelmer> I think that's for a different commit..
<jonnydee> ok guys, thank you very very much for your interest and your help!!! I hope I can somehow give you some benefit back in the future...
<jonnydee> See you :)
#bzr 2008-07-26
 * chandlerc[g] beats on bzr-svn
<chandlerc[g]> errors in the middle of a branch... so weird
<jelmer> chandlerc[g], ?
<chandlerc[g]> setting it up on a clean box, all from development branches, and i'm getting "SSL negotiation failed: SSL error: parse tlsext" stuff
<chandlerc[g]> looking on bugs now..
<chandlerc[g]> jelmer: actually no bugs on this one... surprised
<jelmer> chandlerc[g], does svn itself work ok?
<chandlerc[g]> yep
<chandlerc[g]> at least
<chandlerc[g]> svn "ls"
<chandlerc[g]> lemme do a full checkout
<Peng_> beuno: FYI, your new theme branch of Loggerhead now has a conflict in NEWS with the trunk.
<berto-> is there a way to get bzr log to show the commit's patch?
<luks> no, there isn't
<AnMaster> Does loggerhead have some irc channel?
<bob2> not afaik, but the main devs are in here
<AnMaster> ah... How do you use loggerhead with lighttpd?
<AnMaster> I can only find instructions for apache
<Jc2k> i think the main devs are in the NZ timezone so might be asleep right now
<AnMaster> Jc2k, ah I will be asleep when they are up
<AnMaster> As I live in Europe
<bob2> proxying through lighttpd is probably simplest
<AnMaster> bob2, ah
<luks> isn't loggerhead now a WSGI application?
<AnMaster> no clue, I hoped for fastcgi would work
<bob2> not sure it is in trunk yet
<AnMaster> anyway I'm not a python coder!
<AnMaster> I'm just a bzr user who use lighttpd, and want a repo browser
<Peng_> AnMaster: I'm just using mod_proxy.
<Peng_> AnMaster: And Loggerhead's serve-branches.py.
<AnMaster> Peng, hm...
<AnMaster> Peng, is this last release of loggerhead? or do I need to get trunk?
<AnMaster> I can't find "serve-branches.py" in the download (1.2.1, last it seems?)
<Peng_> AnMaster: The trunk has some major improvements, and serve-branches.py is new in it.
<AnMaster> Peng, so what does serve-branches do then, why do I want it?
<Peng_> AnMaster: It's much simpler to run that start-loggerhead.py.
<Peng_> than*
<AnMaster> I see
<AnMaster> I need to server multiple branches, from several projects, some are stored in shared repos
<Peng_> AnMaster: apt-get install python-paste python-simpletal, edit serve-branches.py if you want to, then run it.
<AnMaster> other are free standing ones
<Peng_> AnMaster: Yeah, that's fine.
<AnMaster> Peng, I don't use Debian
<AnMaster> I use FreeBSD
<Peng_> AnMaster: (They probably have to be under one directory.)
<Peng_> AnMaster: Install Paste and SimpleTAL in some other way, then.
<AnMaster> Peng, what are paste and simpletal for?
<Peng_> AnMaster: Paste is a WSGI thingy, and SimpleTAL is a templating engine. Loggerhead uses both of them.
<Peng_> (Well, the trunk does.)
<AnMaster> ah
<AnMaster> found both in ports
<AnMaster> anyway I find it odd that in here everyone seem to assume you use Debian or Ubuntu
<AnMaster> just wondering why
<Peng_> I wasn't really assuming you did; just using it as an example.
<AnMaster> well it isn't just you, both here and in #launchpad there is a certain level of "assume ubuntu"
<luks> most people here really use debian or ubuntu, so I'd say it's normal assumtion
<Peng_> AnMaster: You do know Bazaar, Launchpad, and Ubuntu are all owned by Canonical, right?
<AnMaster> I know
<AnMaster> but I like bzr even though I'm no ubuntu user
<Peng_> :)
<AnMaster> I use Gentoo Linux, Arch Linux and FreeBSD
<AnMaster> all my servers run FreeBSD
<AnMaster> socket.error: (48, 'Address already in use')
<AnMaster> from the ./serve-branches.py
<AnMaster> how do I tell it to use a different port hm?
<AnMaster> $ ./serve-branches.py --help
<AnMaster> gives same error
<AnMaster> (not very userfriendly...)
<Peng_> AnMaster: You should just edit serve-branches.py.
<Peng_> AnMaster: It's designed to be simple and editable.
<AnMaster> ah....
<AnMaster> turbogears doesn't seem to install on FreeBSD :/
<AnMaster> Peng, so I guess I just can't use loggerhead
<Peng_> The Loggerhead trunk no longer uses TurboGears.
<AnMaster> oh?
<Peng_> They moved from TurboGears and Mako to Paste and SimpleTAL for simplicity and performance.
<AnMaster> ah
<Pilky> hey all, is there any single place that gives you a full run through of what it takes to make a repo specific post-commit hook?
<AnMaster> Peng, is there any way to get it to write a pid file or so...
<Pilky> I've been looking through the docs and I seem to be thrown all over the place
<AnMaster> Peng, well I guess I'll just use daemontools then to run it. sigh
<Pilky> first to the user reference which points to the user guide which points to another part of the user guide which points to the developer docs
<Pilky> it's like you need 4 tabs open just to get even a basic understanding of how to write a hook
<AnMaster> Pilky, I didn't even know bzr had commit hooks
<AnMaster> beyond full plugins
<Pilky> yeah, it does them as plugins, but you can set them up so they're called at various points
<Pilky> it seems a hook in bzr is just a way to call a plugin after/before an action
<Peng_> AnMaster: A PID file would probably be 4 lines in serve-branches.py.
<Peng_> Wait, maybe 6. I dunno.
<AnMaster> Peng, assume I know *no* python except that it lacks braces
 * AnMaster is a C coder
<Pilky> AnMaster: I'm in the same situation but I've just found this which looks good: http://www.diveintopython.org/
<AnMaster> I don't really have time to learn python :P
<Peng_> I think people have stopped recommending Dive into Python because of its age.
<AnMaster> (maybe I should switch to darcs? I know *some* Haskell, not much but more than python. Not that I like darcs really...)
<Peng_> AnMaster: What all does a PID file do? When the program starts, if it exists, error out; if it doesn't, create it? Then when it exits, delete it?
<AnMaster> Peng, well it would lock on it
<AnMaster> would be even better
<AnMaster> open() with O_EXCL basically
<Peng_> Oh.
<AnMaster> to hold it as a lock file
<AnMaster> that would be even more useful
<Pilky> Peng_: what would you recommend? I'm just looking for something online that will help me learn a bit of python, I'm not expecting to be doing a huge amount
<AnMaster> than just a pid file
<AnMaster> Peng, any idea how that is done in python?
<Peng_> Pilky: I'm not sure. I used Dive into Python. :P Maybe the official Python tutorial?
<Pilky> heh
<Pilky> well it seems to use Python 2.3 in here and I'm on 2.5 I've used older books to learn languages
<Pilky> hell, my primary resource for Cocoa programming was a book from around 2004 up until about a month ago :P
<AnMaster> <Pilky> well it seems to use Python 2.3 in here and I'm on 2.5 I've used older books to learn languages <-- you can still learn C using K&R...
<Peng_> Ehh.. I don't exactly know enough about PID files to want to hack it togehter.
<AnMaster> you just would have to learn about prototypes later :P
<Peng_> also, I'm a little tired and really lazy.
<luks> AnMaster: but C didn't evolve much since K&R
<luks> and K&R is the best book about C anyway :)
<AnMaster> luks, oh yes a bit :P, for example variable length arrays in C99, or the _Complex type
<Pilky> AnMaster: I did ;)
<AnMaster> anyway I got no idea where to start with writing a pid file in python
<nandersson> "Beginning Python" from WROX is a great book
<lifeless> AnMaster: Peng_ uses loggerhead with lighttpd
<lifeless> I think
<AnMaster> lifeless, yes he helped me
<AnMaster> lifeless, what about a pid file for it?
<AnMaster> loggerhead that is
<AnMaster> would be very useful
<AnMaster> Peng, I can't get it to work
<AnMaster> http://rage.kuonet.org/~anmaster/loggerhead
<AnMaster> that results in "127.0.0.1 - - [26/Jul/2008:13:43:45 +0000] "GET /%7Eanmaster/loggerhead HTTP/1.0" 404 - "-" "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.15) Gecko/20080708 Firefox/2.0.0.15""
<AnMaster> :/
<AnMaster> how do I make it not send the full path on
<AnMaster> I can't use a specific subdomain
<AnMaster> I need to use this directory
<AnMaster> hm I asked in #lighttpd, lets see if I get any answer
<AnMaster> lifeless, any idea?
<AnMaster> using the serve-branches stuff
<AnMaster> I guess no one knows :(
<AnMaster> well it can't be solved on lighttpd side it seems
<AnMaster> lifeless, Peng: tried webpath with start-loggerhead, doesn't work either
<AnMaster> :(
<jam> AnMaster: fn = os.open('path', os.O_EXCL | os.O_CREAT | os.O_TRUNC), something like that?
<jam> os.write(fn, '%s\n' % os.getpid())
<AnMaster> jam, that isn't the main issue now
<AnMaster> the main issue here is that loggerhead refuses to work when a sub directory is forwarded
<AnMaster> instead of a subdomain
<jam> I don't know a lot about loggerhead, I would imagine it should be possible, though potentially require a bit of code tweaking
<jam> I would have thought it would be the proxies job
<AnMaster> jam, well the proxy is just mod_proxy of lighttpd
<AnMaster> and it can't strip the leading bit it seems
<jam> AnMaster: Also, in the copy of loggerhead I have here, it seems to create a pid file. (if that matters at all)
<jam> Anyway, according to this page:
<jam> http://discuss.joyent.com/viewtopic.php?id=3231
<jam> You can only proxy by file-extension or by prefix
<jam> not suffix
<jam> http://trac.lighttpd.net/trac/wiki/Docs%3AModProxy
<jam> So I'd have to agree with what you were finding
<AnMaster> irc client crashed.... did I miss anything?
<Peng_> AnMaster: Yes.
<Peng_> AnMaster: Just a bit.
<Peng_> AnMaster: Anyway, there's some middleware in Paste Deploy that can strip part of the path.
<Peng_> AnMaster: Here's my serve-branches.py. It's got a horrible, complicated logging setup; the relevant part is the PrefixMiddleware part near the end. http://paste.pocoo.org/show/80377/
<Peng_> AnMaster: You will need Paste Deploy installed, not just Paste
<AnMaster> Peng, "paste deploy"?
<AnMaster> ah... /usr/ports/www/py-pastedeploy
<AnMaster> Peng, force port 80?
<AnMaster> Peng, anyway I would prefer using the start-loggerhead because it can do pid file it seems
<AnMaster> can I still use that?
<AnMaster> Peng_, it can also handle the repos not being in same place (they aren't)
<Peng_> AnMaster: I don't know what you would have to do with start-loggerhead.py; I've never used it.
<jam> beuno: I have to say, setting up loggerhead here seems pretty easy (on win32 no less).
<jam> The daemonize stuff doesn't work (obviously) but it was just a couple easy_installs, and tracking down simpletal
<jam> oh, and you don't mention that you need "ConfigObj" installed as a dependency
<jam> so Paste, ConfigObj, SimpleTAL, and things seem to work
<jam> hmm.. the auto_publish_folder didn't seem to work right
<jam> WAR [20080726-10:01:44.036] simpleTALES.Context: Exception occurred evaluating python path, exceptio
<jam> n: type object 'branch' has no attribute 'url'
<Odd_Bloke> Is LP running a recent Loggerhead, or is there a better place to point people who want to have a look at it in action?
<jam> Odd_Bloke: I don't believe it is running the "latest"
<jam> Odd_Bloke: This page is "shinier" http://bzr.mattnordhoff.com/loggerhead/imports/lighttpd/lighttpd-1.4.x/changes?remember=1117
<jam> That is Peng's page
<jam> I think LP *will* use the latest version, just doesn't yet
<jam> beuno: I *am* trying to figure out the box with-an-arrow link
<jam> It at least looks like it is redirecting you outside of the current domain
<jam> when often it is *just* a link
<jam> like, for *every* summary on the changes page
<jam> anyway, off to another machine
<Odd_Bloke> Peng_: Is pointing people to http://bzr.mattnordhoff.com/loggerhead/imports/lighttpd/lighttpd-1.4.x/changes?remember=1117 acceptable, or is it going to make your hardware break into floods of tears?
<AmanicA> this logger head looks sweet
<AmanicA> I like the way it expands when you click th triangle
<AmanicA> and the mouse-overs rocks
<AmanicA> can you guys get into bundlebuggytoday?
<AmanicA> can you guys get into bundlebuggy today?
<jelmer> no, it seems down
<jelmer> and also not replying by email to my merge requests
<AmanicA> cool so its not just me
<Peng_> My Loggerhead runs the trunk, or other branches. The different theme comes from https://code.launchpad.net/~beuno/loggerhead/new_theme_trunk
<Peng_> Odd_Bloke: Heh. I don't know how much traffic I can handle, but it should be fine, as long as it doesn't get on Slashdot or something.
<tacone> hello, is there a way to enable diff's syntax highlighting for bzr diff ?
<AnMaster> hey how do you check revisions signed with bzr sign-my-commits?
<AnMaster> also what is the rich-root stuff good for? I can't find details on it (tried google)
<tacone> mmh, found a way with vim: bzr diff | vim -u /usr/share/vim/vim71/macros/less.vim -
<Peng_> AnMaster: Rich roots aren't really useful for anything yet. In the future, I think they'll be necessary for things like subtrees and splitting a subdirectory out into its own branch (which is possible now, I guess).
<AnMaster> subtrees?
<AnMaster> what are they?
<AnMaster> Peng, I just use pack-0.92 format here
<AnMaster> Peng_, also what about the checking of signatures?
<AnMaster> signatures is one feature I would like to see expanded
<AnMaster> along with adding support for cherrypicking
<AnMaster> once those are in I will consider bzr perfect for my needs
<Peng_> AnMaster: I dunno about verifying signatures.
<AnMaster> and subtrees?
<Peng_> Ehh. /me handwaves.
<AnMaster> you mean like svn:external?
<AnMaster> or?
<Peng_> Yeah, basically.
<AnMaster> ah
<Peng_> Subtrees are still experimental (and have been for ages).
<AnMaster> anyway what does "handwaves" mean in this context? I'm not a native English speaker
<Peng_> I meant that I was avoiding trying to explain something, but I don't think I was using it entirely correctly.
<Peng_> It's in the Jargon File: http://catb.org/jargon/html/H/handwave.html
<AnMaster> are there any plans for cherry picking support in bzr?
<AnMaster> like the advanced cherry picking of darcs
<Peng_> Due to the model of Bazaar (and many other VCSes), cherrypicking is kind of difficult.
<Peng_> I don't know if there are any current plans.
<Jc2k> tacone: install bzrtools and then do bzr cdiff
<AnMaster> what a pitty :/
<tacone> sorry, how to apply a patch generated with bzr diff > ../my.patch ?
<tacone> patch -p0 < ../my.patch doesn't seem to work
<Odd_Bloke> tacone: Are you trying to apply the patch to a different bzr branch?
<tacone> Odd_Bloke: to more recent revision of the same branch
<jelmer> AnMaster, cherrypicking is already supported
<tacone> I am quite sure conficts shuold not happen.
<jelmer> AnMaster, tracking cherrypicks is not and support for that is planned for the future
<Odd_Bloke> tacone: Try using 'bzr merge -c<revision>' instead.
<AnMaster> <jelmer> AnMaster, tracking cherrypicks is not and support for that is planned for the future <-- GREAT!
<Ryan52> I saw somebody using a program like gitk on a bzr branch. What is that?
<tacone> I don't have a revision of the changes to apply, only that .patch.
<Jc2k> Ryan52: bzr-gtk perhaps?
<Odd_Bloke> jelmer: ZOMG commit spam. :)
<Ryan52> Jc2k: ah. thanks.
<jelmer> Odd_Bloke: (-: Sorry about that
<Odd_Bloke> jelmer: How's bzr-git coming along?
<jelmer> Odd_Bloke, nicely
<jelmer> Odd_Bloke: viewing history works
<tacone> Odd_Bloke: I guess I got it. it worked for everything but a erased (with bzr rm file). the revision to be patched has it and it's more big than before.
<Odd_Bloke> jelmer: Nice. :)
<jelmer> now working on supporting "bzr branch <git-url>"
<tacone> ok, solved
<Odd_Bloke> jelmer: \o/
<AnMaster> <jelmer> now working on supporting "bzr branch <git-url>" <-- nice!
<beuno> jam, oh, LH on windows...  that's unexpected...
<beuno> jam, the box with the arrow was originally intended to let you know it was a link you could click on, but that may of derailed a bit
<beuno> may be too confusing now...
<beuno> cool, patches for LH!
<beuno> nothing better than going to sleep and waking up with patches in your inbox
<jelmer> beuno, fwiw I also filed some bugs to keep you busy ;-)
<jelmer> I filed an ITP (cced to the list) for loggerhead as well but upload to NEW is not likely to happen soon
<beuno> jelmer, heheh, I saw  :)   I'm going through the remaining patches, and RC-bugs  :)
<beuno> jelmer, I saw, very cool, thanks.  When does the freeze disallow you from getting it into Lenny?
<jelmer> beuno, I think the freeze has already happened
<beuno> jelmer, ah, could be. I got dizzy after a few mails bounced back and forth
<jelmer> yeah, full freeze is planned for mid july so I guess that's already past
<beuno> heh, yeah, I just though the release would get delayed for at least a year  :)
<beuno> Peng_, synced my branch with trunk, no more conflicts
<Peng_> beuno: Do you pushed to your branch on LP? I don't see anything new.
<beuno> Peng_, I'm stupid, I keep pushing somewhere else. I just pushed and added --remember  :)
<rocky> don't suppose there's a quick way to get running with bzr 1.5 + bzr-svn on hardy heron ?
<jelmer> rockstar: grab the bzr-svn from intrepid
<rocky> jelmer: ah cool
<rocky> it's funny... all my paying projects are stuck on svn and every several months i try using bzr to access those svn repos but somehow get turned off
<rocky> don't suppose bzr-svn supports svn externals yet?
<jelmer> rocky, no, because bzr doesn't have nested trees yet (which we'd have to map externals to)
<rocky> gotcha
<Peng_> beuno: Heh, OK.
<fullermd> jelmer: 'minds me...   are stock svn 1.5.x bindings solid now, or are there still patches needed?
<jelmer> fullermd: bzr-svn >= 0.4.11 works with svn 1.4 and 1.5 out of the box
<Peng_> Oh yay, you resolved the conflict the same way I did.
<fullermd> Awesome.
<jelmer> beuno, loggerhead really seems to've come a long way since the original version
<rocky> jelmer: there's no releases of bzr-svn 0.4.11 yet right?
<jelmer> rocky, that's right, it's still in development
<jelmer> rocky, 0.4.11 won't work with bzr 1.5 anyway (only with >= 1.6)
<rocky> i can't seem to find a link for the download of bzr-svn intreprid ... i still find launchpad a bit hard to navigate
<jelmer> rocky: see http://packages.ubuntu.com/bzr-svn
<rocky> ah perfect, thanks
<rocky> where's the best place to look to get a high-level list of functional changes between 1.4 and 1.5 of bzr ?
<Peng_> Well, NEWS contains a long list, including many less-major things.
<rocky> guess i'm more looking for a release announcement sorta deal
 * rocky keeps googling
<jelmer> I think NEWS is what you're looking for
<jelmer> you may want to skip some of its sections though such as INTERNALS
<rocky> is http://packages.ubuntu.com/bzr-svn resolving for anyone? can't seem to get to it
<jelmer> looks like its down atm
<LarstiQ> rocky: NEWS is (or was) also what gets verbatim mentioned in release announcements
<zbrown> How does one apply a merge directive?
<jelmer> zbrown: bzr merge <file> or bzr pull <file>
<zbrown> ah ok
<zbrown> jelmer: is there a way to apply a merge directive without actually making it a revision?
<zbrown> that is, just flat apply the patch
<jelmer> zbrown: Not sure why you'd want to do that
<jelmer> "patch -p0 < FILENAME" should work though
<zbrown> jelmer: patch was broken
<zbrown> it needs completing
<jelmer> zbrown: In that case, "bzr merge" to merge the merge directive
<jelmer> then fix it followed by commit
<zbrown> oh so merge won't commit?
<jelmer> no, it'll just apply the changes, you have to commit it explicitly
<zbrown> ah ok
<jelmer> (and this sort of situation is exactly why it does't commit)
<zbrown> ah :)
<zbrown> I work mostly in git so still learning some of these things :)
<beuno> jelmer, yeah, I thought it would take longer to get to where we are
<rocky1> packages.ubuntu.com offline for everyone here? (sorry, was DC'd)
<zbrown> rocky: seems that way.
<beuno> jelmer, it's actually usable by most people now!
<jelmer> beuno, :-)
<Peng_> beuno: Shouldn't the SQL cache be deleted on shutdown?
<Peng_> I think it used to usually be deleted, but it isn't anymore.
<beuno> Peng_, ideally, no. It takes quite a few CPU cycles to generate it, not sure why we wouldn't want to take advantage of it already have been created
<Peng_> Ideally, then, you wouldn't use mkdtemp to pick it. :P
<rocky> jelmer: don't suppose there's a good link somewhere that i'm missing for svn users who haven't really used bzr on how to get going with bzr-svn ? or do you just refer people to standard bzr docs ?
<Peng_> Hmm, I bet I could monkeypatch it to do that.
<jelmer> rocky, see the FAQ included with bzr-svn for bzr-svn things
<jelmer> rocky, for everything else, the regular bzr docs apply
<beuno> Peng_, agreed. That's some of the left-overs ToDo's for serve-branches
<AmanicA> rocky: If youre new to bzr you might want to checkout the following too: http://bazaar-vcs.org/BzrForSVNUsers
<rocky> thanks
<rocky> is there a simple mirror for packages.ubuntu.com that is up atm?
 * Peng_ writes a stupid monkeypatch in serve-branches even though it would be easier to just edit loggerhead/apps/filesystem.py.
 * beuno cheers Peng_ 
<jelmer> rocky, you may be able to use the debian package
<jelmer> rocky, http://packages.debian.org/bzr-svn
<jelmer> woot, "bzr branch git-url" works \o/
<Peng_> beuno: My monkeypatch can't stop the mkdtemp directory from being created, so I'm automatically deleting it. :D
<jelmer> not at a workable speed though
<beuno> Peng_, hehe, ok, we may work a bit on top of that, but it'll get us started  :)
<rocky> is it just me or is there no bzr deb for hardy at:  https://launchpad.net/~bzr/+archive
<rocky> do i need to get the intrepid one for that too?
<rocky> um, actually, there is no intrepid one for that
<beuno> rocky, there was a problem with the package, you can find them here: https://edge.launchpad.net/~bzr-beta-ppa/+archive
<beuno> latest betas/rcs
 * rocky needs a "yes rocky, you're stupid, so here are the links you need for bzr 1.5 on hardy and bzr-svn"  ;)
<Peng_> Someone uploaded 1.6b3 for hardy (but no other series), then it was deleted, and 1.5 was never added back (I dunno if it's even possible). Right?
<beuno> I don't think you can upload an older package, no. We'll probably have to wait til 1.6 is out
<berto-> if i wanted to make a plugin to hook into the commit command, where would i learn how to do that?
<rocky> ugh ... well if i upgrade to bzr 1.6beta3 (which does seem to have a deb for hardy) that means i'm out of luck with a bzr-svn plugin version to match up right?
<ToyKeeper> Yay, just a page of shell to migrate svn tags to bzr.
<beuno> berto-, http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-hooks
<beuno> is a good place to start
<jelmer> ToyKeeper: bzr-svn 0.4.11 will also support importing tags natively
<jelmer> ToyKeeper, fwiw
<ToyKeeper> Yeah, but that's in the future.  :)
<jelmer> rocky, you can run the development version of bzr-svn
<Peng_> beuno: BTW, I wrote a one-line patch to call the sql_dir "/tmp/loggerhead-cache-XXXXXX" instead of "/tmp/tmpXXXXXX". Interested?
<beuno> berto-, http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#hooks is also good
<ToyKeeper> jelmer: any idea if it'll handle svn branches too?  Those seem more difficult.
<jelmer> ToyKeeper, heh, true
<jelmer> ToyKeeper, older versions already handle svn branches
<jelmer> ToyKeeper, e.g. bzr svn-import
<beuno> Peng_, yes, that's an improvment over what we have now. Send it over to the list please [loggerhead/merge]
<Peng_> beuno: OK
<ToyKeeper> Ah, okay.  I only tried that with 'bzr branch /blah/svn/repo'
<rocky> starting to wonder if it's worth all this or if i should just use hardy's native bzr 1.3 and whatever bzr-svn version comes with it
<berto-> beuno: thanks!
<jelmer> rocky, I would recommend just using 1.3 unless there are particular bugs you're hitting that are fixed in later releases
<rocky> i don't think there are
<rocky> just figured if i'm learning to use this system i should be using the latest
<berto-> is there an easy way to get the parsed command line from a plugin?
<Odd_Bloke> jelmer: I'm about to file an ITP on GitPython, have you looked at packaging it at all?
<jelmer> Odd_Bloke, nope, not yet
<jelmer> berto-, why would you need that?
<Odd_Bloke> jelmer: Cool, I'll take a look at it.
<berto-> jelmer: i'm looking into writing a pre-commit hook that checks for implicit commits.  i've grown accostomed to git where you either add something then commit, or explicitly specify the file[s] being committed.
<berto-> jelmer: so, i wanted to check the args part of the command from a pre_commit_hook
<jelmer> berto-: a pre_commit_hook can't modify what is being committed because of the moment in the commit process it's being called
<berto-> jelmer: i dont' want to modify, just raise a BzrError if no file was specified.
<berto-> it's really a pretty simple addition i want to make.
<jelmer> berto-: start_commit_hook can modify what is being committed but it doesn't receive the list of files to commit atm
<berto-> right now 90% of the time i commit, say doh, uncommit and then properly commit just the files i want.
<berto-> jelmer: but i dont' want to modify, just reference, which is why i wanted to check the command line.  if the args part of options, args = optparse.parse_args([...]) is empty i'll just raise BzrError.
<jelmer> berto-: well, sys.argv should contain the command line arguments
<berto-> jelmer: right, but all the options as well.
<berto-> i guess i can just exclude any that are prefixed with '-'.
<jelmer> berto-: right, so that's why you'd want start_commit_hook
<jelmer> but that needs to be modified to receive the list of specified files
<berto-> start_commit_hook rather than pre_commit_hook ?
<jelmer> yeah
<berto-> is there a page that describes all the hook invocations; like, what is the difference between pre_ and start_ ?
<jelmer> berto-: I'm not sure
<jelmer> start_commit_hook is part of MutableTree
<berto-> jelmer: hmm, start_commit_hook does not work, but pre_commit does.
<jelmer> berto-: Doesn't work in what way?
<berto-> when i try start_commit_hook, i get: Unable to load plugin 'explicitcommit' from '/Users/berto/.bazaar/plugins'
<jelmer> berto-: Are you sure you have the right name?
<berto-> i thought start_commit_hook was the right name.
<jelmer> bzrlib.mutabletree.MutableTree.hooks['start_commit'] rather than bzrlib.branch.Branch.hooks['pre_commit']
<berto-> jelmer: this works: http://dpaste.com/67613/
<jelmer> berto-, you'd need mutabletree.MutableTree where you have branch.Branch at the moment
<jelmer> and 'start_commit' where you have 'pre_commit'
<jelmer> and "from bzrlib import mutabletree" rather than "from bzrlib import branch"
<berto-> jelmer: hmm, alright.  sorry if you already explained this, but why is start_commit_hook better than pre_commit ?
<jelmer> berto-: start_commit is run before the tree is generated that is going to be committed
<berto-> jelmer: ah, cool. less processing is done.
<jelmer> berto-: and pre_commit is not intended to receive the list of files to commit, it operates on a tree
<jelmer> berto-: start_commit doesn't receive the list of specified files at the moment, but it will in the future
<berto-> jelmer: got it.
<bpeterson> lightweight checkouts don't store any of the revision data with them, correct?
<jelmer> bpeterson: yep
<bpeterson> so that's why just running bzr diff is so slow?
<jelmer> yeah, if the branch you've got a checkout is remote somewhere it can be pretty slow
<bpeterson> hmm, is this the same of stacked branches?
<james_w> not quite
<james_w> a stacked branch splits the storage of the revisions for a branch.
<james_w> create a heavyweight checkout where the local branch is stacked at a depth of one revision. This would be like svn, with the exception that the local size will grow as you commit.
<bpeterson> I don't want to carry the whole revision history around, but I would like bzr diff to be fast as a branch
<bpeterson> good that seems nice
<james_w> that last line should have started "what you could do is"
<james_w> so you wouldn't have the whole of the revision history, but you would have some
<bpeterson> I didn't think you could stack things at different revision levels
<james_w> you could recreate it periodically to prevent the local storage growing without bound
<bpeterson> well mostly I just don't want to download the whole history
<james_w> a stacked branch provides a fallback when revisions can't be found locally.
<james_w> so if you create an empty stacked branch then bind it to the parent and then either commit, or fetch the last revision, you get fast "bzr diff", but you have to hit the network for "bzr log", like svn.
<bpeterson> that's ok
<james_w> it's the sort of thing that would be good for a plugin once we have stacking
<james_w> the only problem would be thinking up a name for that arrangement :-)
<bpeterson> so it's not yet possible to ask Bazaar to pull a given number of revisions initially from the branch it's stacked on (i.e. 1000)
<bpeterson> ?
<bpeterson> for some reason I can't get Bazaar to stack on rich-root-pack repos
<jelmer> bpeterson: I think there was a fix that went into bzr.dev recently to help with this
<jelmer> what version of bzr are you running?
<bpeterson> bzr.dev, the latest
<jelmer> hmm, that's probably an unknown bug then..
<bpeterson> perhaps it hasn't been merged?
<jelmer> I'm pretty sure it's been merged since it broke bzr-svn :-)
 * bpeterson goes to file a bug report
<jelmer> bpeterson: thanks :-)
<a7p> hi everyone
<a7p> anybody using bzr under MacOS X? -- I've got a couple of problems and would like to know if other people share them, so I can file proper bug reports.
<bpeterson> a7p: it works fine for me
<a7p> bpeterson, ah, great, could you try to checkout lp:eclipse-bzr ... that one fails reproducible (works fine with under Linux).
<a7p> bpeterson, and do you get the progress display?
<bpeterson> it says: no such project eclipse-bzr
<Peng_> a7p: Are you using the same version of bzr on both?
<jelmer> a7p: did you log into launchpad?
<bpeterson> I can't find this project eclipse-bzr
<a7p> Peng, no, I am not, on Hardy I tryed 1.3.1 (which is default) and on macosX I tryed 1.5 (which is the Download-Package as well as the version distributed via macports)
<Odd_Bloke> jelmer: python-git package at http://packages.daniel-watkins.co.uk/
<bpeterson> jelmer: https://bugs.launchpad.net/bzr/+bug/252212
<ubottu> Launchpad bug 252212 in bzr "can't stack rich-root-pack repos" [Undecided,New]
<a7p> bpeterson, sorry ... bzr-eclipse is what I mean
<jelmer> Odd_Bloke, w00t!
<a7p> jelmer, it works fine with some other launchpad branches
<jelmer> Odd_Bloke, in order for python-git to be usable for bzr-git, the patches in my git repo are necessary as well
<a7p> my Macos installation is also much slower than the linux-ones
<bpeterson> knit-repos are deprecated now
<a7p> jelmer, and I registered my launchpad account with bzr.
<a7p> bpeterson, okay, so it can't work due to the too new version I am using under macos ...
<bpeterson> no
<bpeterson> It's working so far for me
#bzr 2008-07-27
<Odd_Bloke> jelmer: Are they general changes, or bzr-git specific ones?  (i.e. will they be forwarded upstream?)
<a7p> bpeterson, and you do get the progress bar?
<bpeterson> yes
<a7p> something really seems to be messed up here ...
<a7p> :(
<jelmer> Odd_Bloke, they're generic
<bpeterson> as in [                          ] Transferring ?
<Odd_Bloke> jelmer: Do you think it's worth getting the package uploaded and waiting for the patches to make it into mainstream (as bzr-git isn't production-ready yet anyway), or would you prefer them to be included in the packaging and forwarded upstream that way?
<a7p> bpeterson, exactly, that's the thing I am talking about.
<bpeterson> a7p: it's not doing anything if that's what you mean
<a7p> not even [ .. ] get's displayed here ...
 * a7p will read the manual and come back in a few minutes
<bpeterson> maybe your terminal is messed up
<a7p> works fine with anything else ... and I did not change anything from the defaults ...
<a7p> but nevertheless, likley ..
<a7p> -v also gives me nothing
<a7p> ahhh ...
<jelmer> Odd_Bloke, I don't think it's worth bothering to include them in the package atm
<Odd_Bloke> jelmer: OK, that makes my life easier for the time being. :)
<bpeterson> a7p: the branch complete successfully for me
<a7p> bpeterson, okay, thanks for your help ... something really seems to be messed up with my MacOS installation ...
<Odd_Bloke> jelmer: If you have time, I'd appreciate you giving the package a quick once over, as it's the first package I've created from scratch. :)
<jelmer> Odd_Bloke, is there a bzr branch I could review ? (-:
<Odd_Bloke> jelmer: I haven't made the jump to using bzr to version my packages.
<Odd_Bloke> (So no. ;) )
<a7p> mmm ... does not work in xterm either ... so I guess I can exclude terminal-compatibility problems.
<Verterok> hi
<Verterok> a7p: are you still having problems with bzr-eclipse branch?
<Verterok> a7p: I'm upgrading the branch to packs ATM
<a7p> Verterok, I'll give it another try
<a7p> Verterok, but my MacOS-bzr installation seems to be at least partial guilty ..
<Verterok> a7p: it's still upgrading, I'll let you know when it's done
<a7p> Verterok, thank you very much.
<Verterok> a7p: are using the Tiger DMG?
<a7p> no, Leopard
<Verterok> a7p: I asked, because I'm the maintainer of  the Tiger DMG :)
<a7p> sorry, do not have a tiger at hand.
<a7p> Verterok, but your bzr displays the progress bar, doesn't it?
<Verterok> a7p: it did the last time I tested it (I'm using bzr.dev ATM)
<Verterok> a7p: did you upgraded bzr from a previous dmg install?
<a7p> Verterok, nope, fresh install ..
<a7p> Verterok, strange the progressbar ist displayed when I co with --lightweight ...
<a7p> I'll give the trunk a try, see if my problem is fixed there.
<Verterok> a7p: maybe it's a knit<->packs problem (I'll digg the reported bugs)
<Odd_Bloke> Is there any chance I could get http://blog.daniel-watkins.co.uk/tags/Planet%20Bazaar?flav=rss added to Planet Bazaar?
<jelmer> Odd_Bloke, please mail poolie
<awmcclain> I have a remote, read-only SVN repo. I've created a bzr branch from it, made changes, and checked them in. Now, I want to use bzr diff to make a patch of all the changes I've checked in against the HEAD revision of the svn repo; how do I do that?
<Odd_Bloke> jelmer: Will do.
<Odd_Bloke> Thanks. :)
<a7p> Verterok, just gave 1.6b4 a try - it works fine
<Verterok> a7p: great to know
<a7p> Verterok, am able to checkout bzr-eclipse and the progress-bar gets displayed.
 * Verterok wonders if it's time to build a 1.6bx DMG for tiger
<Verterok> a7p: the upgrade to packs is still running :P
<jelmer> awmcclain, bzr diff -rbranch:svn://....
<a7p> thought so, got a warning from the new bzr.
<a7p> so, thanks for your help and the trunk-hint ... have to sleep now
<awmcclain> jelmer: Ah, of course. Thank you. When you branch off of an svn repo, does it save the original path anywhere?
<jelmer> awmcclain: .bzr/branch/branch.conf should contain the original url
<awmcclain> Hrm, empty.
<a7p> one more thing *g* ... should I file a bug for the nonexitant progress bar and the knit fail of bzr 1.5?
<awmcclain> Nm
<awmcclain> i'll just look it up again
<awmcclain> jelmer: Any way to see what SVN revno I originally branched from?
<Verterok> a7p: I assume it'll be marked as fixed, but do it anyway if you think it should be there for ccurrent 1.5 users :)
<a7p> okay.
<a7p> gn8
<jelmer> awmcclain; in newer versions of bzr-svn, the revno is listed in "bzr log"
<rocky> is there anything similar to psvn.el for bzr/emacs ?
<bob2> does vc-bzr.el count?
<rocky> not really ;)
<bob2> vc in recentish emacs cvs (or bzr;) has apparently incirporated incorporated some psvn features
<rocky> weird... anyone using DVC because i have no idea where to begin with it
<mtaylor> rocky: ?
<rocky> nvm ;)
<rocky> decided i'll stick with cmdline bzr until i get familiar enough with it
<mtaylor> fair enough
<ToyKeeper> rocky: Bzr has lots of good documentation, plus built-in help.  'bzr help' or 'bzr help commands' is a good place to start.  :)
<Ryan52> Can I combine 2 commits somehow?
<bob2> you could branch from before the first one, then merge them in together
<Ryan52> then will there be no way to tell that it was ever 2 separate commits?
<Ryan52> (that's what I'm trying to get...)
<bob2> no
<luks> if they are the last commits on the branch, you can just uncommit twice and then commit
 * Ryan52 will try that next time
<Ryan52> thanks
<markh> is anyone able to help me diagnose why bzr-svn says "not a branch" for a URL that svn is working fine with?
<dwt> Hey guys, I'm having a problem compiling the bzr-svn exgtension on mac os x
<dwt> because I't complains that my svn libraries are not fat
<dwt> but instead thing (only for i368)
<dwt> but I couldn't find a way to teach setup.py to only build i368 binaries
<dwt> as a result of this, bzr now always segfaults when loading
<dwt> which makes it a bit hard to use...
<bob2> markh: is bzr-svn working in general?
<markh> bob2: I'm not sure to be honest
<markh> I'm trying to find out :)
<markh> I'm on windows, but there are no obvious deps missing.
<bob2> bzr selftest -s bzrlib.plugins.svn
<markh> ouch - "exceptions.ImportError: cannot import name make_file_knit"
<markh> hrm
<bob2> are you using bzr.dev?
<markh> yeah, about a week or so old
<bob2> and which version of bzrsvn?
<markh> latest I could find - 0.4.10 - but it complains about being too old
<bob2> get the bzr-svn 0.4 branch
<bob2> I'm pretty sure bzr.dev generally requries dev bzr-svn
<markh> ok cool, thanks.  I'm actually trying to package windows binaries, so was trying to stick to "known" versions when I could - I'll give that a go.
<bob2> then you'd want bzr 1.5 and bzr-svn 0.4.whatever
<markh> trying to package ready for 1.6 ;)
<markh> and include the current state of tortoise which I'm working on. I'm hoping to be able to include the svn plugin as a convenience.
<markh> and trying to learn how it working in the meantime :)
<bob2> you want 0.4.11, which is unreleased
<bob2> so 0.4 trunk
<dwt> Ping.... can anyone help me with my bzr-svn compile problem?
<bob2> !sunday
<ubottu> Sorry, I don't know anything about sunday
<dwt> bob2: so thats the problem... nobody in. :)
<dwt> ?
<bob2> it's the weekend, yo'll have better luck during the week or asking on the list
<dwt> ah well, probably.
<dwt> Thanks for the answer bob2!
<AnMaster> well I'm in but I never used bzr-svn
<LarstiQ> dwt: I have never seen that error.
<LarstiQ> dwt: so I'm not sure what exactly the problem is, could you elaborate on it a bit?
<dwt> LarstiQ: Well, I'l paste a complete build log if you like - maybe I'm hunting for completely the wrong thing
<LarstiQ> dwt: sure, I can try and look at that.
<dwt> uhm, which paste is preffered here?
<LarstiQ> dwt: your libsvn is i386 only?
<LarstiQ> ubottu: paste?
<ubottu> Sorry, I don't know anything about paste?
<dwt> jup, installed via fink
<LarstiQ> dwt: I don't really care, use rafb.net/paste/ myself
<dwt> thx
<dwt> http://rafb.net/p/XJZq9w38.html
<LarstiQ> I see.
<dwt> its a bit strange really, if I look at the backtrace of the crash
<dwt> it looks like its really the libsvn that has the error
<LarstiQ> dwt: I'd be interested to know where setup.py gets its gcc line from, notably the -arch ppc
<dwt> http://rafb.net/p/p4boYu29.html
<dwt> yeah, me too.
<dwt> :)
<dwt> the setup.py file itself doesn't contain a thing in this direction, sadly.
<dwt> So it probably is something from distutils.extension
<LarstiQ> dwt: what does apr-config give you?
<LarstiQ> dwt: apr-config --cflags  I guess
<dwt> -g -02
<dwt> :/
<LarstiQ> ok, that's not it then
<LarstiQ> dwt: can you print the repos SvnExtension extra_compile_args?
<dwt> just a second
<dwt> looks innocent too:
<dwt> kwargs: {'libraries': ['svn_client-1', 'svn_subr-1'], 'extra_link_args': ['-L/sw/lib', '-lapr-0'], 'library_dirs': ['/usr/lib'], 'include_dirs': ['/sw/include/apr-0', '/usr/include/subversion-1']}
 * LarstiQ dives further into distutils
<dwt> is there a way to get those out after distutil did it's magic with them?
<LarstiQ> dwt: to test if it is really the fatness of the lib, you can rerun the gcc commands yourself, without -arch ppc
 * dwt slaps his head
<dwt> why didn't I think of that before?
 * LarstiQ still searches on for distutils knowledge
<dwt> I'l try that
<LarstiQ> dwt: it's early? :)
<dwt> true...
<dwt> LarstiQ: I did have a nice breakfirst with self-baked bread before though.
<dwt> :)
<LarstiQ> dwt: also, try: from distutils.sysconfig import get_config_vars; get_config_vars()['CFLAGS']
<LarstiQ> dwt: ooh
 * LarstiQ skipped breakfast today since he is going to a Nepalese restaurant for lunch in half an hour (and I got up at 11.00)
<dwt> :)
<dwt> LarstiQ: Well, no luck there either:
<dwt> Get Config Vars: -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -Os -Wall -Wstrict-prototypes -DMACOSX -I/usr/include/ffi -DENABLE_DTRACE
<dwt> not even in any of the config vars. :/
<LarstiQ> ah, but that does mean it is gcc $CFLAGS -arch stuff etc
<dwt> LarstiQ: Sorry, I don't follow...
<dwt> ah
<dwt> got it
<dwt> still unsure where it comes from though
 * LarstiQ plods on
<LarstiQ> dwt: hmm
<LarstiQ> dwt: do you have $CFLAGS set in your env?
<dwt> LarstiQ: well, not at all: echo $CFLAGS
 * dwt returns nothing
 * dwt is currently looking at the distutils source of Extension.py
<LarstiQ> dwt: I'm looking at syconfig.py customize_compiler()
<LarstiQ> dwt: how about CCSHARED?
<dwt> the environment variable?
<dwt> no env of that name here
<LarstiQ> yes
<LarstiQ> hmkay
<LarstiQ> dwt: does it still segfault if you build thin by hand?
 * LarstiQ starts rounding up to leave the house
<dwt> damn, I'm not done with that yet
<dwt> I'l hurry
<bob2> not using distcc or ccontrol or anything?
<dwt> bob2: Not that I know of
<dwt> LarstiQ: Compiling it by hand, it still segfaults
<dwt> not sure thogh that distutil isn't doing any more commands it doesn't show on the shell
<LarstiQ> right
 * LarstiQ runs off
<LarstiQ> dwt: maybe jelmer has an idea
<dwt> He probably has. :)
<dwt> Thanks a lot for your help though!
<dwt> jelmer: you don't happen to be around?
<_amanica_> jelmer: Is the loggerhead and bzr-gtk bundles supposed to show up in bundle buggy?
<_amanica_> because I know that bundle buggy can now support multiple projects, but I'm not sure how one is supposed to know from the frontend which bundles are for which project..
<jelmer> dwt, Hi
<jelmer> dwt, I'm around but I have no idea about Mac OS X
<dwt> jelmer: well, first Thanks for answeing
<dwt> and second: after investigating this a bit it doesn't seem so much like a problem of building fat binaries vs thin binaries
<dwt> burt more like maybe a bug in the bindings
<dwt> which causes a null pointer to be used
<dwt> jelmer: Maybe you could have a look at the stacktrace after a crash? http://rafb.net/p/p4boYu29.html
<dwt> I had a look at initrepos in repos.c - and it did look innocent to me - but I don't know the subversion libraries at all
<dwt> so maybe you can see something there
<jelmer> dwt: not sure what could be buggy there
<jelmer> dwt, so it could indeed be a local issue
<dwt> maybe my svn libraries are buggy?
<dwt> I'm still on 1.5.0 something
<dwt> and not on 1.5.1
<dwt> Do you know anything there?
<jelmer> dwt, not sure, it seems strange this sort of bug would end up in a release
<jelmer> dwt, I would suspect it's related to Mac OS X
<dwt> ok, thanks a bunch
<dwt> I'l look into this more
<dwt> if I see something I'l report it back here
<mrZeby> hi all
<mrZeby> there is somebody here ?
<mrZeby> somebady read me ?
<bob2> hello
<mrZeby> hello bob2 thanks for answering... i just would to be sure my irc client run correctly :-) have a nice day.
<nico-inattendu> Hi, i m a almost newbie on bazaar i try to set up a Distributed development workflow. And i ahave som e questions on the usage? and when to make commits. In the example given in tutorial http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#distributed-development , a branch mirror is created , then each modifications are made in new branches ( features branch). But i don't understand  what action to do when a modification is d
<bob2> (truncated after "modification isd")
<luks> anyway what's causing this: bzr: ERROR: Directory not empty: "/srv/bazaar.launchpad.net/push-branches/00/00/1d/59/.bzr/repository/lock/lzvfsm4v4t.tmp": [Errno 39] Directory not empty ?
<luks> on bzr push
<luks> oh, nevermind, it's probably a new "repository locked" message
<Peng_> Is it possible to convert a lightweight checkout to a stacked branch?
<bob2> reconfigure?
<Peng_> Really? Where do you set what it's stached on?
<Peng_> stacked*
<jelmer> Peng_: i would imagine it would create a new branch that is stacked on the branch your lightweight checkout is using
<Peng_> I'm just not seeing this.
<Peng_> "bzr reconfigure --tree" obviously turns it into an independent branch. Where do you tell it to stack?
<Peng_> Oh, right, isn't stacking on rich-roots broken anyway?
<jelmer> Peng_: I would imagine it to be possible to use a --stacked argument to reconfigure
<jelmer> not sure if such a argument is there yet though
<Peng_> jelmer: There isn't one in the help
<Peng_> Yeah, there isn't one.
<Peng_> Is it supposed to be possible to run "bzr branch --stacked some_rich_root_pack_url"?
<jelmer> Peng_: yes
<Peng_> I think there's a bug open about it?
<Peng_> jelmer: Is it just me, or is "bzr log" not showing the svn revisions anymore?
<jelmer> Peng_, I think it's you :-)
<jelmer> Peng_, you mean the "svn revno" entries in bzr log, right?
<Peng_> :(
<Peng_> jelmer: Yes.
<Peng_> Great, it works on one branch, but not another.
<Peng_> In fact, it works on one branch of the project, but not another.
<Peng_> jelmer: It doesn't show it on new revisions I just pulled, but it does on older revisions.
<jelmer> Peng_, it doesn't list them for revisions that have been created with bzr
<Peng_> jelmer: They weren't.
<jelmer> Peng_, does "bzr log --show-ids" show svn-v3: revids?
<Peng_> jelmer: No.
 * Peng_ blinks.
<jelmer> are you sure that branch was created with bzr-svn?
<Peng_> Yes...
<Peng_> I've had the branch for months, and I frequently "bzr pull" new revisions from svn.
<jelmer> what do the revids look ?
<Peng_> Like normal bzr revids.
<jelmer> that would suggest the branch you pull from is either a regular bzr branch or the revisions in svn were created with bzr
<Peng_> Ahh.
<jelmer> or perhaps it's not a bzr-svn branch but a launchpad import ?
<Peng_> The developers are transitioning to bzr-svn, so that's probably it.
<jelmer> ahh
<jelmer> it's not possible to retain the svn revno for that sort of revision since revisions are immutable
<Peng_> Yeah, they were made using bzr.
<Peng_> Thanks. :)
<awilkins> markh: bzr-svn win32?
<awilkins> markh: ping?
<poolie> hello all
#bzr 2009-07-20
<igc> morning all
 * fullermd_ waves at igc.
<fullermd_> igc: Are you currently (in general, not this second) working on filtering stuff, or is that pushed down the stack?
<garyvdm> Hi igc
<jml> morning #bzr
<garyvdm> Hi jml
<jml> I'm going to release Bazaar 1.17 today
<poolie> jml, you legend
<poolie> i hope you had a hearty breakfast
<igc> hi fullermd: back on the content filter bugs today (after higher priority reviews)
<jml> poolie, I haven't eaten, in fact.
<igc> hi garyvdm!
<poolie> i'm going to try to finish outstanding reviews and my assigned bugs
<poolie> ie not spend all week on phone and email, as i did last week :/
<fullermd_> igc: Sweet.  I don't have anything particular on it, was just curious where it fell.  Looking forward to it!
<fullermd_> It's amazing how much you can accomplish when you turn off the ringer  ;)
<igc> fullermd_: it's less important than making 2a stable
<igc> fullermd_: but I find it personally embarrassing and ...
<fullermd> Sure, but can't I have everything all at once?  Immediately?  And a pony?
<igc> I'd really like to ensure it's working properly by the 2.0 release
<fullermd> The sad part is that a key component of going from "works" to "usable" is per-branch config of it, and every time that comes up we all get eaten by a grue   :|
<igc> fullermd: if you provide the patches (and parent ponies), I'll merge them immediately :-)
<igc> fullermd: so I guess that makes you the bottleneck :-)
<fullermd> That sounds messy...
<poolie> jml, speaking of your stats on launchpad
<poolie> i was thinking after La Mola that it might be interesting to do brief stats on our releases as to
<poolie> what kind of bugs we fixed: plain bugs, new features, regression fixes,
<poolie> if it was late, or how controlled the release process was in general and maybe why
<poolie> this might not be worth it but it might be interesting to look back
<jml> poolie, well, my LP stats had the advantage of being really easy to get using bzr log + grep
<poolie> nb i'm not suggesting adding any additional work to your plate for today
<jml> poolie, good good :)
<poolie> yeah this would be at least partially manual
<jml> poolie, those would definitely be interesting stats to have.
<jml> although they'd all need strong not-a-metric qualifiers :)
<poolie> you could get some kind of medium-term feedback on it perhaps...
<poolie> s/on/from
<poolie> i may try it one jetlagged morning
<jml> good idea
<igc> garyvdm: those pending merge screen snapshots are nice - well done!
<garyvdm> Thanks
<mwhudson> jelmer: a bzr-git branch is doing this:
<mwhudson>   SHA1KnitCorrupt: Knit <bzrlib.knit._VFContentMapGenerator object at 0x86c7a10> corrupt: sha-1 of reconstructed text does not match expected sha-1. key ('git-v1:56599cc5b24f8a4e30423898c7cf5077c569b9ee',) expected sha d28a73fcdd473745fce7765c35fe419613e278e9 actual sha b3391cd0e3bc7a3c9a510c2055fd469ea5458821
<mwhudson> (i'm not actually sure which branch it is :()
<mwhudson> jelmer: heard of this?
<poolie> igc/garyvdm, is there already an option somewhere that does the equivalent of bzr commit --show-diff?
<igc> poolie: you mean on qcommit?
<poolie> mm
<poolie> preferably a gui option not a command line one
<igc> qcommit has a Diff button
<poolie> of course
<igc> poolie: and if you're using explorer, the status view shows you what's changed
<poolie> right
<poolie> i suppose i meant to pop that up automatically
<poolie> but that does sound pretty lazy doesn't it :)
<jelmer> mwhudson: hi
<mwhudson> jelmer: hello
<jelmer> mwhudson: haven't seen that before
<mwhudson> jelmer: ok, i'll try to find out where it's coming from
<garyvdm> poolie: Sorry - I was away. Not quite sure what you are asking.
<poolie> s'ok, igc answered it
<garyvdm> ok
<spiv> jml: I'm about to submit that patch for merging into 1.17
<spiv> jml: it's the same fix as Friday, but now I have a test :)
<garyvdm> poolie: Is this ok: http://bazaarvcs.wordpress.com/?p=39&preview=true ?
<jelmer> mwhudson: My guess would be that we're calculating and inserting a wrong SHA1 somewhere, or used to at some point.
<jelmer> mwhudson: possibly because we fail to update InventoryEntry.text_sha1 in a corner case.
<jelmer> mwhudson: when is it giving that error exactly? during "bzr pull" from git?
<mwhudson> jelmer: no, in trying to generate a diff for a revision mail
<jelmer> mwhudson: ah, interesting
<jelmer> mwhudson: so there would potentially be more branches with this issue, it just hasn't been noticed yet because nobody is subscribed to diff emails?
<mwhudson> jelmer: it's possible
 * mwhudson files a bug "job system oops reports don't tell you which branch is being processed"
<poolie> garyvdm: very nice, thanks
<jelmer> mwhudson: btw, did you see my reply to your bzr-svn + python2.4 bugreport?
<mwhudson> jelmer: yes
<mwhudson> jelmer: i'll try to reply sensibly soon
<mwhudson> (it's been one of those mornings)
<malibu> Hi there..  I just came across Bazaar...
<malibu> I'm trying to set up a repository on my windows machine.. Something like the dropbox idea.. how is bazaar at handling regular windows kind of files?
<lifeless> it should handle them fine
<malibu> I used to use svn but the repository was too big.. The local repo would be the same size as the actual fles
<lifeless> if your files are binary, you'll find that most VCS systems have that property, and those that don't are very slow ;)
<malibu> ugh.. how do sites like dropbox do it then?
<lifeless> on their server they will have a copy of your files
<lifeless> and if your files are binary, it will be about the same size as your files ;)
<malibu> Oh.. yeah but i don't mind that on the server
<lifeless> oh, you mean on your machine?
<malibu> What I mean.. is with SVN it doubles the local storage
<lifeless> it does that because it has local data
<lifeless> copies of the files to do diff operations with
<lifeless> VCS systems like to make 'diff' operations quick
<malibu> Does bazaar do that as well?
<lifeless> we keep a copy of all your history since you started the project
<lifeless> same as git, hg, darcs and monotone
<malibu> hmm.. not what I want then
<lifeless> perhaps you don't want a VCS?
<malibu> I want something like dropbox
<lifeless> do you need history? diffing? annotate?
<malibu> I want a history and versioning.  Not diffing or annotate
<lifeless> are you on a LAN, or working over the internet?
<malibu> mostly LAN, sometimes internet
<malibu> I need it to work over ssh, preferably
<malibu> I want a dropbox idea but on my own server
<lifeless> well, you could use bzr with lightweight checkouts
<lifeless> they don't have a local cache
<lifeless> but the tradeoff is that its a lot slower to do many operations
<lifeless> igc: I'm fixing apply-inventory-delta branch
<lifeless> igc: are there any issues other than test failures now?
<igc> lifeless: I'm just looking over the code now
<malibu> lifeless: I will look into that
<malibu> lifeless: What is the windows client like for bazaar?  Does it have something like TortoiseSVN?
<lifeless> There is a TortoiseBZR, yes
<malibu> cool
<malibu> bzr uses ssh?
<spiv> malibu: it can, yes.
<lifeless> if you want it to, yes
<malibu> ok
<igc> malibu: see http://bazaar-vcs.org/BzrExplorer as well
<lifeless> malibu: or iFolder, apparently it has an open source server component
<malibu> So say I do light checkouts.. bzr will still try to do things efficiently right?  For example, will it send a file if the last modification times haven't changed?
<lifeless> it does a sha1 check before uploading anything
<malibu> Because as long as it's efficient as, say, rsync.. I'm fine with that
<malibu> come to think of it, does it only send deltas of binary files?
<lifeless> that depends
<lifeless> :)
<malibu> ok.. I'm just going to try it.
<malibu> repo on my ubuntu machine, tortoisebzr on my windows laptop
<malibu> With light checkouts
<malibu> (rock on)
<poolie> spiv, re the inventory-delta branch, you're going to put back IDS?
<poolie> hm actually apparently you said you were going to do without it in the review...
<spiv> poolie: I'm currently thinking I'll put it back for now, so that the other changes aren't blocked.
<poolie> k
<spiv> I still think we want to get rid of it :)
 * igc lunch
<jml> spiv, lifeless: got any ideas on how I can trigger a logged exception onthe staging smartserver?
<spiv> jml: what bzr version? 1.16.1?
<lifeless> jml: what bzr version is it running?
<lifeless> jinx
<spiv> jml: if so, call any unknown smart method...
<spiv> jml: more creatively, issue a ('get', '../foo')
<jml> I'm not 100% sure, either 1.16.1 or 1.17rc1
<spiv> (lp:bzr-ping is a good, short plugin to crib from if you want inspiration for generating arbitrary simple requests)
<jml> spiv, thanks
<jml> although I get stopped on the client side when I try client.call('oprah')
 * jml digs around
<SamB> jelmer: what is this about?
<SamB> Now on revision 3127.
<SamB> Conflicting tags:
<SamB>     bzr-svn-0.6.3
 * SamB also wishes bzr would have told him what revision it started at at the end there ...
<SamB> oh, just four revs but tons of pyflakes fixes?
 * SamB wonders what pyflakes is
<SamB> well, I mean, I can rather guess that it's some sort of lint tool ;-)
<SamB> jelmer: oh, you tagged the wrong 0.6.2 as 0.6.3 :-P
<SamB> er. s/the wrong//
<malibu> When I try to do a checkout with tortoisebzr, I get error: TortoisebzrCommandError: Illegal command 'revert'
<spiv> jml: the client side will see the error bit in the response and raise the response as ErrorFromSmartServer rather than returning it.
<malibu> Sorry, unknown command 'revert'
<jml> spiv, I had to comment out this line -- #self._run_call_hooks(method, args, body, readv_body) -- for it to talk to the server at all
<SamB> malibu: geeze, they really should allow selecting the text in those dialogs so you can copy/paste it!
<spiv> jml: weird
<malibu> yeah I know
<spiv> jml: do you have some sort of weird plugin installed that installs a buggy hook?
<spiv> jml: oh, I know.
<spiv> jml: will fix, thanks for the report.
<jml> spiv, http://paste.ubuntu.com/222366/
<jml> spiv, np
<jml> back home
<spiv> jml: (it's a bug in the hook function installed by -Dhpss)
 * SamB is beginning to think there's a *reason* it's called Bundle Buggy
<spiv> Hmm, I'm pretty sure I type my gpg passphrase faster shortly after having a coffee.  Pity that I seem to also mistype more too...
<verterok> f
<lifeless> hmm, not bzr 1.18 milestone
 * lifeless maksifies
<lifeless> hmm
 * SamB hopes igc notices https://code.launchpad.net/~naesten/bzr-fastimport/400960-heredocs/+merge/9015 soon
 * SamB got his wires crossed and requested some random unrelated person to review it :-(
<poolie> spiv, i've wanted to write some program that tracks my typo rate
<poolie> and typing rate
<lifeless> WTB review: https://code.edge.launchpad.net/~lifeless/bzr/bug-367632/+merge/8928
<poolie> want to buy?
<lifeless> yes
<poolie> lol
<igc> lifeless: I took a quick look at that one this morning
<poolie> mary's sig the other day said something about "Do real heros start their career squashing household pests?"
<igc> lifeless: I thought we ought to get the apply-inv-delta one landed first
<lifeless> igc: why?
<lifeless> igc: the bug 367632 bad deltas are already caught
<ubottu> Launchpad bug 367632 in bzr "bzr revert '.' can fail when there are added, missing, directories." [High,Fix committed] https://launchpad.net/bugs/367632
<igc> given I think it depends on it doesn't it (wrt the corruption fix)?
<lifeless> this just fixes the cause
<lifeless> igc: bug 367632 was about the delta generation. bug 367633 was the corruption
<ubottu> Launchpad bug 367633 in bzr "errors on revert propogate to dirstate" [High,Fix committed] https://launchpad.net/bugs/367633
<malibu> hey is bazaar 1.17 not ready or something?  I can't seem to use tortoisebzr with it
<igc> lifeless: ok, I'll look a bit deeper later today
<lifeless> igc: its very shallow
<lifeless> though it took me ages to dig through the layers to find it ;)
<spiv> poolie: typo rate judged by % of backspace hits?
<igc> lifeless: maybe the bug comments confused me or something
<poolie> yes, or ^w or alt-backspace or similar
<poolie> obviously this is not perfect
<spiv> Yeah.
<spiv> It won't notice my mistyped passphrase, for example :)
<spiv> But that's a bit of a special case anyhow.
<igc> SamB: I'll take a look
<poolie> spiv, why not?
<poolie> because you tend to type C-a and retype the whole thing?
<poolie> also xchat ^w =close window sucks :)
<spiv> poolie: because I am usually typing it into mutt, hitting enter, then getting the 'bad passphrase' message, so no ^A, ^W or backspace is involved.
<malibu> Does bzr support nested repositories?
<SamB> malibu: seems to be in-progress
<poolie> oh i see
<spiv> I really should futz about with making mutt and gnome-gpg or whatever is shiny these days play nice with each other.
<SamB> spiv: it depends what GTK theme you have configured
<spiv> But anything related to driving gpg very quickly drives me into a mini rage about how awful gpg...
<spiv> 'how awful gpg is', that is.  It's very unfriendly software.
<SamB> it could be worse -- it could be x.509!
<spiv> Heh.
<spiv> My issue isn't with the underlying format/spec, it's just that the software to use and manipulate keys is so damn awful.
<SamB> what's the trendy PPA for bzr nightlies nowadays?
<poolie> google bzr nightly ppa
<poolie> :)
<SamB> spiv: well, okay, it has a UI that might have been nice when I was born ;-)
<poolie> pretty sure that's right
<SamB> for reference, I was born in '86
<SamB> poolie: okay ... that seems to be what I'm using ...
 * SamB wishes those things had the date in the version somewhere
<poolie> that would be nice
<SamB> I don't have a clue what to report that wish against, though!
<spiv> SamB: it has a UI that makes me pine for tla :P
<SamB> spiv: no, it's not nearly *that* bad!
<poolie> i hope that's not a pun :)
<SamB> I mean, you don't have to use it that much
<SamB> poolie: pretty sure it's not
<SamB> I don't see how tla relates to an email client he doesn't even use
<spiv> SamB: I dunno, tla made me want to drill holes in my head less than gpg.
<SamB> spiv: when was this?
<SamB> had you used a VCS with a half-decent UI at the time?
<spiv> Stiil, I can believe it's a matter of taste about whether awful thing A is more or less awful than awful thing B :)
<SamB> I mean, GPG may have a really rusty UI
<SamB> but it doesn't have those %@%^#^ stupid paths!
<SamB> or revision names or whatever the heck those things are
<SamB> jelmer: bzr-svn needz moar -D !
 * SamB can't seem to svn-import from https://dosemu.svn.sourceforge.net/svnroot/dosemu today :-(
<jml> spiv, has the fix for bug 400535 landed?
<ubottu> Launchpad bug 400535 in bzr "ChrootServer/ChrootTransport not used by "bzr serve"" [Critical,Fix committed] https://launchpad.net/bugs/400535
<jml> lifeless, bug 397705 is marked for 1.17 & not fix released -- what's missing?
<ubottu> Launchpad bug 397705 in bzr "inventory delta consistency checks are missing known problems and not universally applied." [Critical,Fix committed] https://launchpad.net/bugs/397705
<lifeless> jml: it was a placeholder
<lifeless> jml: ignore it
<lifeless> jml: it will be in 1.18
<lifeless> jml: (and you have the bit I wanted to get into 1.17 already)
<SamB> oh, actually, svn can't connect either :-(
<jml> lifeless, cool.
<jml> lifeless, consider it ignored :)
<malibu> So I created a repo on my ubuntu server, was able to check out the empty repo with tortoisebzr, but when I add files to the local working copy I don't get add or commit options in the context menu ?
<malibu> Not sure what I am doing wrong
<malibu> Oh ok now I get the commit option.. wierd!
<spiv> jml: I sent it to PQM (for bzr.dev) a while ago.
<spiv> jml: it's still playing, but on the second half of the test run by the looks.
<jml> spiv, cool. I guess I'll cherrypick it into 1.17 then merge back into bzr.dev
<spiv> jml: sounds good.  It should cherrypick neatly aside from the NEWS entry.
<jml> \o/
<jml> grunk.  I think I screwed up one of the commits to 1.17 :\
<SamB> quick! darcs rollback! ...
<lifeless> jml: tip looks odd
<jml> lifeless, yeah exactly.
<SamB> what, did he lose the old one somehow ?
<jml> lifeless, I'm going to uncommit it and then check the news file to make sure that all of the bugs marked for 1.17 are still present
<jml> (not being able to think of a better way to sanity check)
<SamB> you can do that?
<SamB> (uncommit, I mean)
<spiv> SamB: bzr help uncommit :)
<spiv> SamB: (often followed by a push --overwrite...)
<SamB> I meant in a "you won't get flayed alive for it"
<SamB> kind of way
<spiv> Well, that depends :)
<SamB> I did actually know about the command
<SamB> it's handy
<SamB> oh, yeah, and I did think some branches disallowed push --overwrite?
<spiv> I forget if the branch.conf option disables that, but certainly you could write a smart server hook fairly easily that would reject that sort of change.
<lifeless> jml: seems fine, get spm to uncommit the master for you
<spm> jml: ?
<jml> lifeless, I can do that myself, actually.
<spm> even better! :-)
<lifeless> jml: how?
<jml> lifeless, I have write permissions to the branch on launchpad.
<lifeless> jml: thats not the master
<spm> jml: you need access to balleny tho
<jml> lifeless, I thought PQM submitting the 1.17 branch to Launchpad these days?
<lifeless> jml: yes
<lifeless> jml: pqm pushes there
<lifeless> that doesn't make it the master
<spiv> jml: btw, my fix for 400535 has landed.
<jml> lifeless, what makes a branch the master branch then?
<jml> spiv, thank you
<lifeless> jml: the place pqm reads the branch from, which is a secured directory on the pqm server
<lifeless> pqm can be configured to read from launchpad, but we haven't done that.
<malibu> have you guys ever seen this happen?  Its happened to me again.. no add/commit options on my working copy
<jml> lifeless, ahh ok.
<lifeless> malibu: no, never
<lifeless> igc: Its fun, finding this many existing, hidden bugs
 * SamB has never even tried to use bzr on Windows
<igc> malibu: give bzr-explorer a spin - it's a bit better supported than TortoiseBzr is currently
<igc> lifeless: fun is one name for it :-)
<igc> samB: that fastimport change is good - merge to trunk now
<igc> SamB: ^^^
<SamB> igc: what, you think I'm case-sensitive or something? this is IRC ...
<SamB> ... but how am *I* supposed to do the merge?
<igc> malibu: I hope to release bzr-explorer 0.5 later tonight
<lifeless> igc: found one test making a delta of
 * spiv -> lunch
<lifeless> [('', '', None, InventoryDirectory(None, ...))]
<igc> SamB: I did the merge. Sorry typo above
<jml> spm, can you please uncommit the top revision of the 1.17 branch?
<lifeless> igc: that is, a root directory with file id None
<igc> lifeless: yuk
<SamB> igc: oh good
<SamB> that saves some awkward confusion ;-)
<igc> SamB: I always assumed IRC was case-sensitive
<igc> if not, you learn something new every day :-)
<SamB> IGC: I suppose you do ;-)
<SamB> at least, it's a pretty boring day if you don't
<lifeless> abentley: don't suppose you're around?
<igc> lifeless: maybe those groupcompress tests fail if make isn't run. I'll try running make and see if they go away
<lifeless> igc: if they fail, I suggest we let PQM decide
<SamB> igc: I found another bug and wrote a test ... would you like the test without a fix?
<igc> SamB: feel free to push the branch
<SamB> https://code.launchpad.net/~naesten/bzr-fastimport/401249-tag-from-ref
<SamB> or lp:~naesten/bzr-fastimport/401249-tag-from-ref
<igc> samB: I can't merge it to trunk though until the fix is there because 'bzr selftest fastimport' would start failing then
<SamB> igc: ah.
<spm> jml: to verify: uncommit+revert(?) revno 4531 in ~/archives/thelove/bzr/1.17
<jml> spm, that's right. thanks.
<SamB> igc: I think I could write an ugly fix pretty easily, but in the time that it took me to figure out how to write the test, I changed my mind about wanting to do it that way ;-)
<lifeless> igc: and \o/ found a form of corruption I'd overlooked
<spm> jml: bzr/1.17$ bzr revno ==> 4530
<jml> spm, thank you
<spm> np
<igc> lifeless: those groupcompress tests pass after running make
<lifeless> that needs a bug then  :)
<SamB> igc: well, thanks for merging that
<igc> lifeless: yup, I'll raise one now
<SamB> okay, how do I go back 4 revisions ?
<SamB> bzr-svn is acting up :-(
<igc> lifeless: so the tests pass until your patch is applied: "bzr trunk bzr.dev xx; cd xx; bzr selftest groupcompress" works fine
<igc> lifeless: it's not an existing bug then I feel
<lifeless> igc: thats interesting; howver I haven't touched the VFs layer, so I have to assume it just uncovers a latent bug
<igc> lifeless: wouldn't be the first one with this patch :-)
<SamB> ah ... bzr pull --overwrite -r 'last:5' .
<SamB> what the heck ... now lp:bzr-fastimport hangs when I try to pull from it :-(
<jml> spiv, can you please sanity check: http://paste.ubuntu.com/222407/
 * SamB decides to hope it goes away by morning ...
<jml> gosh it's nice being able to develop in karmic, as opposed to hardy chroot.
<spiv> jml: looks ok
<jml> spiv, thank you.
<poolie> biab
<lifeless> igc: done!
<igc> lifeless: sweet. I'll take a look.
<lifeless> as for the gc tests
<lifeless> they have
<lifeless> self.requireFeature(CompiledGroupCompressFeature)
<lifeless> so they explicitly don't expect to run without the .so
<lifeless> igc: I'm done for the day; if you can let me know about both merges that would be great
<igc> lifeless: np
<lifeless> igc: the new changes in the apply-delta branch are, a new check for the thing that was corrupt in the deltas from tree transform and test smart, and fixes to those two tests to not create bogus deltas
<igc> lifeless: yup - double-clicking the entries in qlog is telling me exactly that :-)
<igc> lifeless: do we allow unicode file-ids?
<lifeless> no
<lifeless> dirstate will barf
<lifeless> we used to, but we did a sweep over the code base ages ago and redefined as utf8 strings
<igc> lifeless: thanks
<lifeless> theres a certain amount of 'whatever works
<poolie> can we have bzr lolwhut too?
<jml> I just did this: commit, push, tag, push
<jml> but the final push says "No new revisions to push."
<jml> am I doomed to have this tag loiter eternally in my local branch?
<spiv> jml: no
<spiv> jml: the message is technically correct, but misleading
<spiv> jml: no *revisions* were pushed
<spiv> jml: the tags should have been, though.
<spiv> jml: there's a bug about this UI flaw
<jml> spiv, how can I verify this?
<spiv> jml: try "bzr tags -d URL"
<spiv> "bzr tags -d :push", even!
<jml> http://paste.ubuntu.com/222489/
<jml> I just got that error
<spiv> jml: ooh, that looks like a bug!
<spiv> jml: probably shallow, please file :(
 * spiv needs to head off for the evening.
<spiv> jml: happy releasing!
<jml> spiv, thanks.
<poolie> lifeless: what is the actual point of subunit2pyunit?+
<poolie> to turn it back into the same output format produced by subunit?
<lifeless> poolie: to replay a test via pyunit; this effectively gets rid of all the subunit encoding, and will tend to hide passing tests etc, depening on the pyunit parameters
<poolie> actually, i meant "in your example pipeline"
<lifeless> oh
<lifeless> so I can see it realtime
<poolie> in a nicer format than just letting subunit flow to stdout?
<lifeless> yah
<poolie> and as you say hiding passing tests
<lifeless> well the subunit-filter takes those out, in my example
<lifeless> after time reporting
<lifeless> my next main thing is progress data in the stream
<lifeless> once thats done I plan to do a subunit2bzrtest, or something like that, that will use bzr's progress bars to pretty-print streams
<bialix> igc: hello
<jelmer> moin
<igc> hi bialix - great to have you back!
<igc> hi jelmer
<bialix> igc: well, I'd like to be still on vacations, it was great but too short
<bialix> igc: I've merged branch of amanica before I've read your objections. Should I uncommit?
<igc> bialix: no
<bialix> I guess we can tweak it later
<igc> bialix: so how does it work exactly? I'm running trunk (1.18dev) yet that's not listed in the compatible set
<igc> but I can start explorer
<bialix> because bzrlib declares api_minimum_version = (1, 17, 0)
<igc> bialix: so it will fail on the next api bump?
<bialix> it seems so. I'll tweak the check in explorer now
<bialix> igc: http://pastebin.com/m4419d0a1
<bialix> are you ok with error message?
<igc> bialix: looks good
 * bialix committing
<bialix> igc: I've downloaded latest translations and put them into trunk. it's ready to release
<igc> bialix: can you test http://pastebin.com/d51aa252a for me?
<igc> it's a patch for bug 394314
<ubottu> Launchpad bug 394314 in bzr-explorer "unique/missing revisions tabs should catch NotBranchError" [Medium,Confirmed] https://launchpad.net/bugs/394314
<bialix> igc: I can't test it, there is error page: Unknown post id, it may have expired or been deleted
<lvh> hi
<igc> bialix: try http://launchpadlibrarian.net/29273483/394314.diff
<bialix> igc: it works
<igc> bialix: thanks
<bialix> Not a branch: file:///C:/work/Bazaar/repos/qbzr-repo-1.9/revno.769/
<bialix> though branch path cvould be better
<bialix> using url_for_display
<sender> can anyone help me to change the default method in tortoiseBZR checkout/branch to 'create local copy of the branch' instead of 'create a checkout'?
<sender> i tracked it to line 76 of getnew.py in qbzr plugin: self.ui.but_checkout.setChecked(True) - how can i suggest/implement that this can be set by a switch?
<lvh> okay, so, I branched twisted (a project) on lp, whats the first thing I do afterwards? Am I supposed to fake the directory structure I want or something?
<lvh> I'm guessing I'm supposed to push something. How do I not piss off the original authors? (It's supposed to be merged, eventually
<igc> sender: if you don't get a reply here, try the qbzr mailing list
<poolie> lvh: i don't understand
<poolie> what are you trying to do
<sender> igc: tx, will do
<lvh> poolie: Implementing a shiny new feature for twisted in a separate bzr branch.
<poolie> ok, so: branch from launchpad to your machine
<poolie> make your change
<poolie> push it back to lp:~lvh/twisted/shiny-feature
<poolie> then propose a merge of that branch
<poolie> why would this piss them off?
<igc> bialix: wrt bug 392797, can you switch on diagnostic mode and open the checkout for me?
<ubottu> Launchpad bug 392797 in bzr-explorer "branch specific settings: configuration: opens wrong file for lightweight checkout" [Medium,Confirmed] https://launchpad.net/bugs/392797
<igc> bialix: is branch-root wrong there?
<lvh> poolie: If I do a checkout now, it's empty -- I think that is because I havent pushed anything yet.
<bialix> igc: Branch Root = file:///C:/work/Bazaar/repos/explorer/trunk
<bialix> it's ok
<bialix> but it's a URL
<bialix> you need local path
<bialix> not URL
<poolie> lvh, what command are you running?
<igc> bialix: it really ought to be a url there - branch.conf can be across a network
<igc> bialix: something after that is incorrectly calculating the abspath
<bialix> but you can't edit the file acroos network
<igc> bialix: right and explorer won't let you I think
<bialix> you have to download file on the disk, edit, then upload it back
<bialix> my editor does not understand file:/// URL -- this is my best guess
<bialix> and I think it's wrong to pass URL here
<bialix> as you said explorer should not allow editing remote branch.conf
<bialix> sender: it may be problemativ
<bialix> sender: it may be problematic
<sender> bialix: why?
<bialix> sender: you can implement command line option for qgetnew command in qbzr, but then you need tell TBZR somehow to use it
<bialix> another way is to implement option for qgetnew and then use aliases
<bialix> I mean `bzr alias`
<sender> could it become a setting?
<bialix> could
<bialix> but where: in qbzr or in tbzr?
<sender> ideally a qbzr section under tbzr's settings item
<sender> I don't know how much work that would be.. how would the alias solution work? Something like: tbzrcommand.exe --command getnew would start e.g.: tbzrcommand.exe --command getnew --default=branch
<bialix> sender: I'm one of qbzr developers and I can give you some advices; but tbzr stuff you'll need to dig your self
<sender> thanx for the help, it would be great to implement this
<bialix> sender: basically you can define command with default options as new command or redefine the same name
<bialix> sender: check help for alias command
<bialix> so you can redefine qgetnew as "qgetnew --branch" or something
<bialix> sender: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-aliases
<sender> bialix: thanx, will check that in a min. Do we need to implement --branch for qgetnew?
<bialix> you can use flags like: --checkout, --branch and make --checkout as default, IMO
<bialix> see RegistryOption in bzrlib.option
<lvh> poolie: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~lvh-laurensvh/twisted/positioning/".
<lvh> poolie: bzr clone lp:~lvh-laurensvh/twisted/positioning
<poolie> btw if that's an automatically assigned username and you want to change it, it's better to do so before you start making branches
<lvh> poolie: my login name is just 'lvh'
<poolie> hm
<lvh> Oh, wait, found it
<lvh> lvh is already in use by another person or team. :-(
<poolie> https://edge.launchpad.net/~lvh-laurensvh and https://edge.launchpad.net/~lvh
<poolie> that's not you?
<poolie> another belgian?
<lvh> wait, that's me.
<poolie> https://launchpad.net/people/+requestmerge
<poolie> to join them
<poolie> this might be the source of some confusion
<lvh> Member since:  2005-09-29
<lvh> Holy... I didn't know I registered back then
<poolie> it might have been autocreated
<lvh> Unfortunately I don't have access to that email address anymore so proving that I'm me is kind of hard.
<poolie> then go to https://answers.launchpad.net/launchpad/+addquestion
<poolie> and explain it
<poolie> anyhow...
<poolie> can i suggest you read through https://help.launchpad.net/Code
<lvh> what's with the autocreation btw, how did that work?
<lvh> okay, thanks
<poolie> https://blueprints.edge.launchpad.net/launchpad-foundations/+spec/person-creation-rationale
<lvh> poolie: thanks a lot!
<poolie> you're welcome
<sender> bialix: had a little trouble following you ;) found only a bytecode version of option (guess i need an other package)
<sender> bialix: i added "qgetnew=qgetnew --branch" to [ALIASES] in bazaar.conf
<sender> do i need to restart something?
<bialix> sender: do you have bzr sources?
<sender> bialix:  it's all pyd/pyo so I guess not, will get them now
<bialix> if you're using standalone bzr.exe package -- you need either download latest tarball or get the lp:bzr branch (it will take time)
<bialix> then look at bzrlib\option.py, or bzrlib\builtins.py
<sender> bialix: branching now
<bialix> k
<lvh> why should I need to wait until my merge is done before I create branches though? don't the branches move along with me?
<lvh> poolie: oh, wait -- apparenty i did set my password at some time, I can log in into that account
<lvh> poolie: so, change email address, then merge?
<sender> bialix: something different: how hard is it to implement qpush and qpull into the context menu?
<sender> bialix: the ppl i
<bialix> ?
<bialix> "ppl i" -- I don;t understand tyhis
<sender> bialix: sorry
<sender> bialix: the people I'm implementing bzr for are not so good at the command line
<sender> bialix: it would be cool to add more q' commands to the context menu, if possible
<bialix> have you tried bzr-explorer?
<sender> bialix: nope *searching for it
<bialix> context menu -- you mean context menu in Windows Explorer, I guess.
<sender> bialix: yes
<bialix> sorry, I don't have time to work on TBZR
<bialix> sender: https://launchpad.net/bzr-explorer
<sender> bialix: thanx. ok i'll look into adding to the context menu
<jml> gah
<jml> still releasing
<jml> I am Jack's irate NEWS conflict.
<lamont`> Function `PyFrozenSet_New' implicitly converted to pointer at bzrlib/_known_graph_pyx.c:941 <-- known bug in 1.17rc1, or shall I file it>?
<lamont`> filed
<lifeless> lamont: function pointers are pointers ;P its in the standard!
<lifeless> its also a little insane :)
<lamont> lifeless: it's also fatal on 64-bit architectures
<lamont> though amd64 frequently has zeros in the upper 32 bits
<lamont> and undeclared functions return ints, not pointers
<sender> bialix: need to reboot for bzr 1.16 to work (necessary for bzr-explorer) ... brb
<igc> bialix: please try rev 184 wrt bug 392797
<ubottu> Launchpad bug 392797 in bzr-explorer "branch specific settings: configuration: opens wrong file for lightweight checkout" [Medium,Confirmed] https://launchpad.net/bugs/392797
<bialix> igc: it seems I have not pushed my better fix for check bzrlib API version
<igc> bialix: right - I didn't see it come through
<bialix> igc: rev 184 still not good: it tries to open path: "C:\C:\work\Bazaar\repos\explorer\trunk\.bzr\branch\branch.conf"
<lamont> lifeless: that is, the function pointer was implicitly converted from a 32-bit int to a pointer there...  please to tell the compiler about pointers, kthx
<bialix> igc: you have to use bzrlib.urlutils.local_path_from_url instead of slicing
<igc> bialix: can you send me a patch?
<bialix> wait a sec
<igc> bbiab
<bialix> igc: how about this: http://pastebin.com/m15756be4 ?
<bialix> igc: https://bugs.launchpad.net/bzr-explorer/+bug/392797/comments/4
<ubottu> Ubuntu bug 392797 in bzr-explorer "branch specific settings: configuration: opens wrong file for lightweight checkout" [Medium,Confirmed]
<sender> bialix: thanx for poiting out bzr-explorer, it looks really useful, just what we need. (should it not be listed at http://bazaar-vcs.org/BzrPlugins ?)
<bialix> I'm surprised if it not there
<bialix> igc: why you don't add explorer to http://bazaar-vcs.org/BzrPlugins?
<igc> bialix: just haven't got to it. Besides, it should soon be good enough to make the home page :-)
<igc> bialix: right at the top :-) :-)
<bialix> :-D
<TheJosh> Does anyone know how to get bzr+ssh to have a umask of 002 on uploaded files? Should I be hunting around in the SSH docs, or the BZR docs?
<TheJosh> I would prefer if I could set it up once on my server and all users would be forced to use that umask
<LarstiQ> TheJosh: I'd go with posix ACLs
<sender> can anyone help me to start a new translation of bzr explorer?
* jml changed the topic of #bzr to: Bazaar version control system | 1.17 released 20th July, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<TheJosh> what if I cannot use ACLs? I am running a VPS, and the physical server does not allow me to repartition or change my root partition mount options
<TheJosh> because its running OpenVZ
<TheJosh> Actually I did some more investigating. It may be possible :)
<jml> g'night folks.
<jml> enjoy bzr 1.17
<TheJosh> cool got ACLs working - as far as I can tell.
<rocky> don't suppose there's a good writeup on the 2a repo format someplace other than the couple notes in release notes?
<james_w> try the devnotes branch
<james_w> I think there is something in there
<james_w> or doc/developers in bzr.dev perhaps
<DaffyDuck_> new bazaar user here. Let's say I have a server which is where my "central" storage is. I create a bazaar project on the server, and then from my workstation run "bzr brach bzr+ssh://server.com/foo/bar"..
<DaffyDuck_> I now have a local branch to work on.
<DaffyDuck_> But it's on my server that all the heavy backups are created, so I want to push my changes to it from time to time.
<DaffyDuck_> I can use "bzr push bzr_ssh://server...." for that,.
<Arrrgh> hi guys. anyone knows - does Bzr support labels in any way?
<beuno> Arrrgh, you mean tags?
<Arrrgh> yes
<beuno> DaffyDuck_, yes, you can both push and pull
<beuno> Arrrgh, yes, "bzr help tags"
<DaffyDuck_> However, if \'ve understod it correctly, the "parent" is stored somewhere in my local repository. Is there a way I can just type "bzr push", and it'll know where to push it?
<rocky> jelmer: if i specify tags and branch directly in subversion.conf, will bzr still check parent paths? (i'm still getting 403 error)
<DaffyDuck_> I accidentiallly made a typo, so rather than updating the project on the server, it created a new branch.
<Raim> DaffyDuck_: use bzr push --remember $URL once and then you can use just bzr push
<DaffyDuck_> Raim: Ah! Thanks!
<Arrrgh> so they just named it in other way. thanks very much
<malibu> Hey there.. I'm trying to do a commit and I'm getting a memory error?
<malibu> Does bzn have memory issues?
<malibu> It gets to the point where it is collecting changes and then fails with a memory error
<bob2> how big a commit?
<malibu> 4.6 Gb
<beuno> right, I can see you running out of memory with commits that size
<lifeless> malibu: is that a single file?
<malibu> no, many files
<lifeless> memory usage in bzr commit can spike, but per-file
<lifeless> whats the largest file you're committing?
<malibu> So it's hitting a single big file
<malibu> 60Mb is the biggest file
<malibu> No sorry 618 Mb
<malibu> I didn't need it, got rid of it and will try again
<malibu> So what is the biggest file bazaar can handle?
<lifeless> the answer varies depending onw hat you're doing and what bzr format you're using
<lifeless> but between 1/4 and 1/2 of your system memory
<rocky> jelmer: in case you come around, i've debugged the problem with the 403 a bit more and no longer believe it has to do with bad branches/tags locations or anything
<jelmer> rocky: hi
<rocky> jelmer: it looks like bzr is checking for lock files at the root of the "repo base" which in the case of this svn repo, i don't have access to
<jelmer> rocky: yeah, bzr-svn will access parent paths
<rocky> i only have access a part of the rpeo
<rocky> *repo
<jelmer> rocky: we need access to the root of the repository for the cache?
<jelmer> s/?//
<jelmer> rocky: please try disabling the cache
<rocky> jelmer: no diff
<jelmer> rocky: you'll also need to explicitly specify where the branches are in that case
<jelmer> rocky: as bzr-svn won't be able to guess if it doesn't have access to the repository root
<rocky> jelmer: that's just by setting "branches =" for the repo in subversion.conf right?
<jelmer> rocky: yes
<rocky> what are the branch paths relative to? to the hostname or to the full url to the repo?
<jelmer> the repository root
<rocky> same error, i've tried variations on the branches param, etc
<jelmer> rocky: please run with -Dtransport and see what it's trying to do in ~/.bzr.loig
<rocky> jelmer: http://cluebin.appspot.com/pasted/403472
<dvheumen> Hi, is anyone familiar with this issue? (I couldn't find anything in the bugtracker, or it wasn't similar enough.) I did 'bzr upgrade' on a branch of lp:bzr and I got a message that the branch was converted, followed by a 'cannot convert to format' error. And the resulting branch is of 'unnamed' format. http://pastebin.com/m475f0eca
<dvheumen> bzr version 1.17, just installed it
<Kobaz> how do i unmerge
<Kobaz> i did some stuff in the wrong order, and now i have local changes mixed in with a merge
<jelmer> rocky: Hmm
<jelmer> rocky: please file a bug
<jelmer> rocky: bzr-svn shouldn't use the standard locking class as that attempts to do a stat on the root of the repositor when opening a branch
<james_w> hey jelmer
<jelmer> hi James
 * jelmer waves from DebCamp
<DaffyDuck_> Are push operations atomic?
<malibu> Hi there..  I was wondering if someone could help me out.  I installed TortoiseBZR but my folder icons aren't changing and my context menu isn't adapting to handle a working copy
<malibu> ..although I can do a commit from the command line
<beuno> DaffyDuck_, yes  (commit actually is atomic)
<DaffyDuck_> beuno: Excellent. Thanks!
<james_w> jelmer: how is DebCamp?
<jelmer> james_w: very nice
<james_w> good
<james_w> jelmer: I'll see you on Thursday (I hope).
<jelmer> james_w: cool
<fullermd> Whee, lots of plist churn in 1.17...
<luks> jelmer: I have a plugin that prints diff in svn format and I'd like to automatize some things. is there something in bzr-svn that can tell me svn revno of a bzr revision (assuming a mainline revision)?
<igc> night all
<jelmer> 'night Ian
<jelmer> luks: what do you mean with svn format?
<jelmer> luks: isn't the diff format of svn just unified diffs?
<luks> jelmer: exactly what "svn diff" produces
<luks> it's for review board
<jelmer> luks: ah
<luks> I need to include svn revision numbers and so far I've been entering them manually
<jelmer> luks: in that case, it would be nice I guess if we could integrate this into "bzr send --format=svn"
<jelmer> luks: but yeah, this information is available if you use bzrlib.foreign
<luks> jelmer: I found bzrlib.foreign, but it seems to work only for revisions from svn (but it's very likely I'm missing something)
<luks> my main use case are revisions coming from bzr, pushed to svn
<luks> ie, they don't have ids in the bzr-svn format
<jelmer> luks: you can only get the svn revno for those if you have access to the related svn repository
<jelmer> since there is no canonical svn revno for those revisions
<luks> jelmer: yeah, I meant something that talks to the svn repository
<jelmer> e.g. you could push one bzr revision to two svn repositories and it would end up with two different svn revno's
<luks> jelmer: SvnRepository.lookup_revision_id seems to be what I was looking for
<luks> I didn't know bzr send can output different formats, I'll look into that
<terry> hi guys. i install bzr on windows use windows installer, but when install finish, i can't find bzrlib in site-packages . how can i get it. thanks
<SamB> hmm ... am I the only one who can't pull from lp:bzr-fastimport over bzr+ssh?
<luks> jelmer: lookup_revision_id seems to work fine -- http://paste.pocoo.org/show/129745/ (you probably don't want to see this though :))
<jelmer> luks: ooh, neat
<jelmer> SamB: what breaks?
<abli> Hi! do I have to set the file/directory permission on a repository that multiple people will use? Might such permission problem be the cause of getting "Cannot lock LockDir" permission denied errors when trying to do a "bzr heckout"?
<LarstiQ> abli: possibly
<abli> is it documented somewhere? (what permissions to set?)
<LarstiQ> abli: I recommend using posix acls (`setfacl` and friends) to get rid of that problem
<LarstiQ> abli: well uhm, standard unix permissions apply
<jelmer> luks: It'd be awesome to see a merge request for this :-)
<luks> jelmer: are you serious? do you want to monkey patch bzrlib in bzr-svn?
<LarstiQ> jelmer: you're not denting about Debcamp/conf enough! ;P
<SamB> jelmer: bzr just hangs waiting for a response
<SamB> jelmer: would you like to see an strace?
<jelmer> LarstiQ: :-)
<jelmer> luks: I missed that bit :-)
<luks> the other option is refactoring the diff writing code in bzrlib
<luks> which is something I'm not going to do
<jelmer> luks: where is the monkey patching happening?
<luks> DiffText.diff = DiffText_diff
<luks> I'm temporarily changing the DiffText class to do what I want
<luks> I'd have to duplicate a *lot* of code if I wanted to do it properly
<luks> or I'd have to fix bzrlib
<jelmer> luks: fixing bzrlib shouldn't be too hard I think
<luks> yeah, but I lost all my hope in bzr development process :)
<jelmer> luks: Oh, ok
<luks> so I'd rather not go there
<jelmer> luks: Can you perhaps just file a merge request against bzr-svn and I'll take it from there?
<luks> jelmer: ok, I'll clean it up, add some tests and submit it
<jelmer> SamB: not particularly :-) I was just asking because it might be some easy problem
<SamB> jelmer: what happens when you try to access it?
<SamB> anyway, I was just suggesting strace because I don't know any other way to trace what goes between the SSH client and bzr
<jelmer> SamB: seems to work fine here
<SamB> jelmer: huh
<LarstiQ> hmeland_: yow!
<LarstiQ> hmeland_: someone reported having '' in sys.path with jaunty python 2.6.2, which python were you using?
<DaffyDuck_> If I have branched a repository, and edited locally, and made several changes -- how do I push the changes to the server without all of the history? (I essentially want one change only on the server though I have several on my workstation).
<LarstiQ> DaffyDuck_: I can probably think of something for that, but it usually isn't what one wants. Can you explain why you want to do that?
<LarstiQ> DaffyDuck_: ie, why isn't just merging the work enough?
<DaffyDuck_> LarstiQ: The repository on the server is the "central" one which others will use. I don't want to bother them with my "test001", "test002", etc. :)
<DaffyDuck_> ...but I assume there are other solutions for that?
<LarstiQ> DaffyDuck_: depending on the amount of bother
<LarstiQ> DaffyDuck_: so if you cd to a copy of the central branch, andd then `bzr merg path/to/your/work`
<LarstiQ> DaffyDuck_: and then look at `bzr log -n1`
<malibu> I committed a large amount of data this morning and now I am finding that traversing my working copy is very slow.  Is this normal??
<malibu> Furtthermore, folder and file icons for TortoiseBZR seem to be extremely varied.
<LarstiQ> malibu: traversing how? (And no, I'd say that is not normal)
<ndurner> It's very slow here, too.
<ndurner> TortoiseBZR doesn't do caching like TortoiseSVN, right?
<LarstiQ> ndurner, malibu: afaik TortoiseBZR does do caching
<LarstiQ> but I don't have much direct experience with it
<ndurner> Ah yes, there's a "tbzrcachew.exe" process running
<ndurner> Odd.
<LarstiQ> I do admit of having seen reports of that process running away with resources
<LarstiQ> malibu: you should be able to turn either the caching or the file icons off, could you test what that does to performance?
<LarstiQ> hmeland_: ah, I see you were instrumental in getting bug 72227 to a more or less resolved state, thanks!
<ubottu> Launchpad bug 72227 in bzr "should avoid loading modules from working directory" [High,Invalid] https://launchpad.net/bugs/72227
<lifeless> moin
<LarstiQ> moin lifeless
<thumper> does anyone have any groovey icons for indicating a conflict in a branch
<thumper> ?
<garyvdm> thumper: None I would call groovey
<LarstiQ> thumper: no, but I'd check bzr-explorer
<lifeless> jml: jelmer: a review please :) - https://code.edge.launchpad.net/~lifeless/subunit/time-support/+merge/9042
<poolie> hello all
<poolie> jam, still here?
<ndurner> Hello poolie
<ndurner> I have filed the proposal to merge here: https://code.launchpad.net/~ndurner/bzr/bzr-ftp/+merge/8906
<ndurner> Is there anything else (besides the testcase) I have to to?
<poolie> looks good nils
<poolie> i'll comment on the review
<ndurner> great, thanks!
<jml> lifeless, I've got it flagged to do later.
<lifeless> jml: thanks
<poolie> hi lifeless, jml, thumper
<lifeless> hi poolie
<thumper> hi poolie
<etank> im looking at trying to set up a shared repo on my server. looking at the docs it says to 'mkdir /srv/bzr/
<etank> what user should own the bzr dir?
<etank> should i set up the /srv/bzr/foo as root?
<DaffyDuck_> etank: If it's shared, it's more a question about group ownership.
<etank> so i should add a group and add users to it that need the access
<DaffyDuck_> etank: Yes.
<etank> i see
<etank> thanks DaffyDuck_
<DaffyDuck_> There's a really good page I found. Hang on, and I'll see if I can find it again.
<DaffyDuck_> etank: http://bazaar-vcs.org/SharedRepositoryTutorial
<etank> yeah thats what im reading now
<DaffyDuck_> Ah. :)
<etank> crud. i was one paragraph away from the answer :)
<DaffyDuck_> I figured something like that -- it's right at the bottom.
<etank> yeah i see that now
<etank> i should be more patient
<DaffyDuck_> etank: I did the same thing -- ask first, find five seconds later. :)
<etank> glad im not the only one
<easy4> I made some changes to the files in my trunk branch and now I want to create a new branch with these changes and revert trunk to the most recent commit.  What's the easiest way to do that?
<DaffyDuck_> easy4: I have no idea, but I'd probably commit, branch and then uncommit in trunk.
<lifeless> easy4: have you committed the changes?
<lifeless> easy4: if not:
<DaffyDuck_> ..but I'd backup first, since I'm new to bazaar, and I don't really know what I'm doing.
<lifeless> bzr branch . ../new-branch; cd ../new-branch; bzr merge ../trunk --uncommitted
<lifeless> easy4: if you *have* committed:
<lifeless> bzr branch . ../new-branch
<lifeless> bzr uncommit
<lifeless> bzr revert
<easy4> i see. thanks
<lifeless> igc: so, the good news is - your branch fails in real world tests - e.g.
<lifeless> robertc@lifeless-64:~/source/baz/pending/igc-commit$ bzr commit -m "foo" doc/developers/foo
<lifeless> Committing to: /home/robertc/source/baz/pending/igc-commit/
<lifeless> added doc
<lifeless> added doc/developers
<lifeless> added doc/developers/foo
<lifeless> aborting commit write group: InconsistentDelta(An inconsistent delta was supplied involving u'doc', 'doc-20050309044934-a811c79dd26eef58'
<lifeless> reason: Path already versioned)
<lifeless> bzr: ERROR: An inconsistent delta was supplied involving u'doc', 'doc-20050309044934-a811c79dd26eef58'
<lifeless> reason: Path already versioned
<lifeless> igc: this means that all the paranoia wasn't waste ;)
<lifeless> igc: the better news is that I've nothing listed as a pre-requisite for this now
#bzr 2009-07-21
<igc> lifeless: well done!
<igc> lifeless: I'll review that other patch this morning
<igc> morning all
<jml> good morning.
<faceprint> I've got what is probably a dumb question, but I haven't been able to find an answer in any online docs or mailing list archives.  Is there a way to put a setting into branch.conf, commit it (or something to that effect) so it is shared?
<james_w> thanks for releasing 1.17 jml
<lifeless> faceprint: not currently
<garyvdm> faceprint: you can push it some where that is shared though. What do you want to do exactly?
<faceprint> i've written a plugin, and I want to put some settings for it into branch.conf so the entire team doesn't have to manually keep settings in sync
<garyvdm> Ok - Now I understand. Sorry - can
<garyvdm> 't help
<lifeless> faceprint: you could have your plugin read from the tree
<jml> james_w, my pleasure.
<poolie> hi igc
<igc> hi poolie
<jml> can I set a submit branch without editing locations.conf?
<poolie> jml, i don't think so
<poolie> sending mail for a new rm
<jml> thanks.
<poolie> thanks jml, it's been good
<Raim> jml: bzr send --remember? but probably not what you were looking for...
<jml> Raim, it's pretty close actually, if I tack on a --no-bundle and -o-
<jml> hmm. I get a warning about masked values.
 * jml sets this problem aside
<poolie> jml, our 4w schedule would have 2.0rc1 on 6 August and the final on the 13th
<poolie> any comments on how that fits with lp rollout?
 * jml checks out the calendar
<mwhudson> launchpad isn't going to rollout in august most likely
<jml> Next roll-out after 2.2.7 is 2.2.9 on Sept 23rd. Someone's going to announce this properly on the blog soon.
<poolie> mm i saw that
<poolie> well, let's say not 'rollout' in particular, but lp's development cycle in general
<jml> poolie, a bzr upgrade is going to have to be special-cased no matter when it is.
<jml> poolie, so, those dates are just fine.
<poolie> k thanks
<poolie> you know some people at canonical would not have said the second sentence and would have just left me wondering :)
<jml> poolie, well, in this case I was figuring it out as I went along. the idiosyncrasies of a synchronous medium, don't you know?
<lifeless> http://paste.ubuntu.com/223141/
<lifeless> poolie: ^
<lifeless> I'm about to ring to double check this
<lifeless> and talk about the other stuff you msged me
<poolie> to ring me
 * poolie braces
<poolie> ok then
<mwhudson> more things that aren't thread safe in bzrlib!
<mwhudson> progress bars
 * mwhudson attempts to phrase this more usefully
<poolie> hm
<mwhudson> basically i think one wants a ui factory per thread
<mwhudson> i also don't know if the consequences of the unsafety are at all important
 * igc lunch
<mwhudson> seems likely it's pretty harmless
<poolie> mwhudson: it's not clear to me what kind of threadsafety it ought to work
<mwhudson> poolie: the
<mwhudson>             warnings.warn("%r is not the active task %r"
<mwhudson>                 % (task, self._task_stack[-1]))
<mwhudson> warning trips occasionally
<poolie> yeah
<poolie> this uifactory assumes the code is singlethreaded
<poolie> so the warning is saying, you need something else
<SamB> GTK isn't threadsafe either
<poolie> the text mode progress bars will be unhappy if you run multiple threads there
<SamB> it freaks out if you call the it from more than one thread
<poolie> if this happens even when you have them off, as it probably does, it's a bug
<poolie> that i may fix sometime
<poolie> but more seriously, lots of code in bzr has state that's unsafe to run concurrently
<lifeless> thats ok, python can't do it anyway
<poolie> there's not really any contract that you're allowed to do it
<poolie> or to do it under particular conditions
<SamB> poolie: just stop mutating stuff
<SamB> then you're fine!
<mwhudson> poolie: this happens with SilentUIFactory too
<poolie> ok i agree that's a bug; probably not worth filing as i'll probably fix it next time i refactor there...
<mwhudson> cool
<mwhudson> i got a bit worried that it was screwing things up, but that was something else
<mwhudson> if it just produces a warning now and then (which i think is what it does) i don't really care
<poolie> if you're keen you can change silentuifactory not to have that code
<mwhudson> i still owe you a patch to make TextProgressView more parameterizable i think
<mwhudson> hm, is merge --preview broken?
<lifeless> mwhudson: details
<mwhudson> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/402022
<ubottu> Ubuntu bug 402022 in bzr "merge --preview fails with TypeError: _do_preview() takes exactly 2 arguments (3 given)" [High,Confirmed]
<jfroy> $ bzr log -r -1 lp:rivenx/trunk/0.8
<jfroy> bzr: ERROR: bzrlib.errors.ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex()) is not locked
<jfroy> :sad:
<fullermd> Objects just wanna be free.
<poolie> mwhudson: looks like a qbzr problem, try updating that first?
<poolie> hi jfroy, look for an existing bug, it sounds familiar and may be fixed
<jfroy> well not in 1.17 :|
<jfroy> not a huge deal
<mwhudson> poolie: seems you are right
<mwhudson> sorry for the noise
<poolie> maybe apport should automatically google for the exception :)
<poolie> jfroy: https://bugs.edge.launchpad.net/bzr/+bug/389413
<ubottu> Ubuntu bug 389413 in bzr "ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex()) is not locked running diff across hpss" [High,Confirmed]
<jfroy> Similar, though my command was log
<jfroy> Added a comment to say so.
<spiv> jfroy: I think jml or mwhudson filed one about log recently
<jml> I did.
<spiv> Possibly the same bug, possibly not.
<jml> It's probably a dupe.
<jml> missing doesn't take a -d parameter. woe. :(
<SamB> grr ... latest bzr nightly seems to make the bzr-fastimport tests fail
<SamB> igc: did you notice that bzr-fastimport breaks w/ the latest nightly PPA bzr?
<igc> samB: no, but I half expected it
<lifeless> bad deltas?
<igc> samB: please raise a bug and I'll look at it soon
<igc> lifeless: I'd expect so
<fullermd> Is the expected half the fast or the import?   O:-)
<igc> fullermd: the import
<igc> fullermd: it will be *real* fast I expect
<fullermd> Shucks.  Oh well, at least it's still fast.
<lifeless> igc: I'd hope not
<igc> fullermd: it will exit quickly I suspect :-)
<igc> fullermd: it just won't work as such
<SamB> igc: I also discovered that bug #401249 is worse than I thought
<ubottu> Launchpad bug 401249 in bzr-fastimport ""tag from <refname>" gives KeyError" [Undecided,New] https://launchpad.net/bugs/401249
<SamB> well, that might also be better, though
<SamB> since it means I definately don't have to untangle anything from the head-tracking code ;-)
<SamB> igc: what format would you like the test results pasted in?
<igc> samB: not sure I understand the question
<SamB> just regular, or subunit, or?
<igc> SamB: regular is fine
<lifeless> :P
<SamB> https://bugs.launchpad.net/bzr-fastimport/+bug/402041
<ubottu> Ubuntu bug 402041 in bzr-fastimport "selftest breaks with bzr 1.17~rc1+4554+118" [Undecided,New]
<SamB> ubottu: that's not an ubuntu bug!
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<SamB> I sure don't!
<lifeless> SamB: wheee, fun
<SamB> lifeless: the selftest errors?
<lifeless> yah
<lifeless> EOD For me
<lifeless> see youall tomorrow
<lifeless> https://code.edge.launchpad.net/~lifeless/bzr/bug-367632/+merge/8928 still needs review
<lifeless> jml: any chance you'll review my subunit branch this avo?
<jml> lifeless, a reasonably strong one actually.
<lifeless> woo
<lifeless> thanks
<lifeless> I'm going to do another patch tonight to output time:
<lifeless> would you enjoy a subunit talk @ slug?
<jml> I haven't been to slug since 2007
<jml> :)
<jml> lifeless, but it sounds like a good idea.
<poolie> lifeless, all the cool kids go to fp-syd now :)
<poolie> it's just about functional too :)
<lifeless> poolie: sadly, fp-syd is on thursdays
<poolie> wow
<lifeless> poolie: ?
<poolie> the release
<poolie> that's great
<jml> which release?
<jml> :D
<bob2> 57408   .bzr/repository
<bob2> 174084  backup.bzr/repository
<bob2> ^ good work
<lifeless> welcome to bzr 2
<bialix> igc: helllo
<igc> hi bialix! How are you?
<bialix> I'm still trying to enter work-mode
<bialix> sorry for delay with tarballs
<bialix> I'll upload them now
<igc> bialix: yes, it took me several days last week to get going again - well after the 900 emails in my inbox were triaged :-)
<bialix> the same here
<igc> bialix: the tarball is done, the Windows installer is not
<bialix> ok
<bialix> will do
<bialix> last night I've realized there is hidden bug in my check of bzr version
<bialix> igc: so what revno I should package to installer? rev 191 tagged as release-0.5, but there is also rev 192
<igc> bialix: 192
<bialix> I'll update the tag
<igc> I tried to move the tag using qtag but it may not have pushed correctly
<bialix> push --overwrite should do. I've pushed updated tag. please, check it
<bialix> igc: there is two test package now?
<bialix> one in the root and other in lib
<garyvdm> Hi bialix/igc
<bialix> hi garyvdm
<bialix> igc: installer has been uploaded
<igc> bialix: thanks
<igc> hi garyvdm!
* poolie changed the topic of #bzr to: Launchpad's source released today! | Bazaar version control system | 1.17 released 20th July, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<bialix> garyvdm: I'd like to have buttons Refresh and Diff swapped in qcommit
<poolie> hi bialix, garyvdm
<bialix> hi poolie
<bialix> garyvdm: btw, your error dialog is very nice, but I wonder if we should suggest to users file bugs against qbzr and not bzr itself?
<LarstiQ> bialix: can you detect which part the bug lies?
<bialix> well, I mean errors in GUI very often occurs because of internal qbzr error
<bialix> anyway we can reassign bug later
 * LarstiQ nods
<LarstiQ> bialix: it sounds good to me.
<LarstiQ> bialix: but detecting where the problem lies would be cool. Even better if you can detect why, next step is automatically fixing it! ;)
<bialix> by recompiling python bytecode!
<bialix> like in Chrome browser
<LarstiQ> changing running programs I sometimes really miss
 * igc dinner
 * bialix bbl
<LarstiQ> lifeless: can you upload bzr 1.17 to Debian, or should someone else do that?
<lifeless> LarstiQ: someone  else should :)
<LarstiQ> ok
<lifeless> little busy atm
 * LarstiQ will see if he can prepare that
<jelmer> LarstiQ: I've got it prepared here, just need to find my gpg key
<LarstiQ> jelmer: sweet!
<jelmer> bzr: ERROR: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/.bzr/repository/packs/c0ae45a26df55c3bfbb79c0523c4de78.pack is redirected to https://launchpad.net
<LarstiQ> jelmer: does anyone over there know anything about openpgp cards with non-sha1 yet?
<LarstiQ> jelmer: could you try again? some admin fiddling was going on
 * jelmer tries again
<lifeless> jelmer: we had a server issue
<lifeless> jelmer: its resolved-for-now, but the root cause requires code changes. mwhudson is working on those.
<jelmer> lifeless: ah, thanks
<gnomefreak> is there another way to push to a branch other than lp:~? its stalling at 43%
<TheJosh> Hi all
<TheJosh> does a bzr+ssh server require regular ssh accounts on the server (i.e. user accounts)
<bob2> yes
<bob2> it is over ssh, after all ;)
<TheJosh> so is there a way to tell sshd to only accept bzr connections, but not shell connections? I would prefer if my various users were not able to have shell access to my server
<awilkins> TheJosh: Make the default shell for their user /bin/false
<TheJosh> thanks
<garyvdm> gnomefreak: I think you can push to lp using sftp.
<LarstiQ> bob2, TheJosh: you can also use a custom ssh server
<garyvdm> gnomefreak: try changing the the bzr+ssh://bazaar.lau... address to sftp://bazaar.lau...
<garyvdm> gnomefreak: It will probably be much slower.
<gnomefreak> garyvdm: as long as it doesnt stall im happy. ill try now
<TheJosh> Now I'm getting "bzr: ERROR: Connection closed: please check connectivity and permissions" when I try to checkout. I thought I read something about that somewhere, but I cannot remember where
<gnomefreak> garyvdm: this command? bzr push sftp://bazaar.launchpad.netgnomefreak/firefox/firefox.dev
<garyvdm> yes
<gnomefreak> garyvdm: thanks
<gnomefreak> im getting permission denied and i know my ssh key passphrase is right
<LarstiQ> gnomefreak: you're missing a slash there
<LarstiQ> and a ~
<gnomefreak> bzr: ERROR: Permission denied: "/gnomefreak/firefox/firefox.dev": [Errno 13] mkdir failed
<LarstiQ> gnomefreak: ~gnomefreak/
<gnomefreak> LarstiQ: i fixed the slash
<gnomefreak> ah thanks LarstiQ
<LarstiQ> TheJosh: does it mention a public key?
<TheJosh> Nope. What I pasted is the entire error message
<gnomefreak> LarstiQ: thats working ill let you know if it stalls too
<garyvdm> gnomefreak: I suspect that launchpad may be slow today due to a rush to download the launchpad code.
 * garyvdm checks if it's on slashdot yet.
<garyvdm> Nope not on slashdot yet.
<LarstiQ> garyvdm: this would be an opportune moment to make use of the decentralized nature of bzr
<LarstiQ> TheJosh: could you pastebin the complete transcript from the point where you enter the command used?
<TheJosh> sure
<garyvdm> larstiq: But of course people will want to get it from the _canonical_ location...
<TheJosh> http://pastebin.com/d67cd919
<garyvdm> lame...
 * awilkins beats garyvdm with the punstick
<LarstiQ> fwiw I have a copy I could seed
<awilkins> I've already decided to grab the LP sources _later_
<awilkins> Not least because the dependancies are huge and my ISP will throttle my connection unless I download them after 2100
<LarstiQ> TheJosh: k, you could try and see if adding -Derror enlightens more, but at this point I would try and see if `ssh TheJosh@chaoticrage.com` works
<awilkins> From #launchpad : < wgrant> Currently downloading Launchpad at 0KB/s
<TheJosh> It connects, and then dies instantly - because I set the shell to /bin/false
<awilkins> Methinks LP is doomed to be rather slow for quite a few hours
<garyvdm> Hi bialix
<bialix> hi Gary
<garyvdm> bialix: Can't reproduce bug 402103, and I have no idea what it could be.
<ubottu> Launchpad bug 402103 in qbzr "qcommit: refresh producing traceback" [High,Confirmed] https://launchpad.net/bugs/402103
<garyvdm> Can you try a minimal test case:
<garyvdm> cb = QtGui.QCheckbox()
<garyvdm> cb.setCheckState(0)
<bialix> you want me to check it in python shell?
<garyvdm> yes please
<bialix> it will be not fair experiment
<bialix> because I'm running bzr.exe
<LarstiQ> TheJosh: can you ssh in?
<TheJosh> I can SSH in
<TheJosh> LarstiQ, I can SSH in, but the shell exits straight away because I set the shell to be /bin/false
<bialix> garyvdm: QWidget: Must construct a QApplication before a QPaintDevice
<bialix> I have segfault
<LarstiQ> TheJosh: ah, that may be it.
<LarstiQ> TheJosh: have a look at contrib/bzr_access instead
<bialix> (Pdb) cb.setCheckState(0) *** TypeError: argument 1 of QCheckBox.setCheckState() has an invalid type
<garyvdm> bialix:  Please can you try:
<TheJosh> LarstiQ, How does that help my problem?
<garyvdm> cb.setCheckState(QtCore.Qt.Unchecked)
<LarstiQ> TheJosh: instead of setting to /bin/false, which I'm rather sure is what is denying you to login
<LarstiQ> or well
<LarstiQ> run bzr over ssh
<garyvdm> bialix: I suspect that if you upgrade to PyQt4.4 it will be fixed.
<bialix> garyvdm: I'm already running PyQt 4.4.3
<TheJosh> LarstiQ, isn't that what i'm trying to do, run bzr over ssh (i.e. bzr+ssh://)
<garyvdm> Oh
<LarstiQ> TheJosh: yes, but you can't, because your shell is /bin/false
<LarstiQ> TheJosh: I might be wrong, but that is how I analyze the situation
<bialix> garyvdm: as discussed we stopped to support 4.3, and I've switched to latest available
<awilkins> LarstiQ: That might be my fault... I was of the opinion that it would prevent shell logins.. .but not running bzr
<TheJosh> or I just run through sftp://
<bialix> awilkins: hi, can you explain what's wrong with qconflicts so you don;t use it?
<awilkins> bialix: Didn't know it was there!
<awilkins> bialix: Ooh, shiny
<awilkins> bialix: IT was absent when I first started using qbzr
<bialix> garyvdm: cb.setCheckState(QtCore.Qt.Unchecked) is worked
<bialix> awilkins: it was added many months agop
<gnomefreak> using sftp im getting Connection to bazaar.launchpad.net closed by remote host.d 1211/1295
<LarstiQ> TheJosh: sure, that is an option, though slower
 * garyvdm wonders how many other cool qbzr feature there are that people are not aware of.
<bialix> btw vila broke qpush
<gnomefreak> list them in bzr --help?
 * awilkins awilkins runs `bzr help commands | grep q`
<TheJosh> So why does bzr not have any decent access controls, thus preventing me from using the bzr:// smart-server directly. Argh so annoying!
<bialix> and vila away on vacation, rats, I have no person to poke
<garyvdm> awilkins: Not just commands.
<gnomefreak> i dont get it sunbird pushed fine but firefox branch wont push
<awilkins> TheJosh: The only access you can control in a DVCS is to transports, so it doesn't make sense for bzr to implement access controls when there are so many nice implementations on existing transports
<luks> awilkins: the first version of qconflicts was actually written for you exclusively, because you were complaining how that's the only thing you use bzr-gtk for :P
<bialix> hi luks
<luks> hey
 * awilkins blsuhes
<garyvdm> gnomefreak: I suspect that this is a hosting issue. Maybe they will be able to help you at #launchpad
<garyvdm> Hi luks
<gnomefreak> garyvdm: thanks ill ask
<garyvdm> bialix: How is qpush broken?
<awilkins> qbzr and external merge apps ; does it permit selection on patterns?
<awilkins> And does the definition permit formats?
<bialix> garyvdm: push complains when wt is not clean, me working with lightweight checkout, but qpush is started in the root of the master branch that has out-of-date tree
<bialix> so now we have to "fix" qpush, thanks to vila
<LarstiQ> bialix: --no-strict?
<bialix> maybe, but anyway it's not there right now
<luks> awilkins: I'm not sure I understand the question, but it uses the same format as extmerge
<awilkins> luks: I patched bzr-gtk for my own use to accept a python format-string because the way it built args didn't work too well on windows
<awilkins> luks: Looking at the implementation in qbzr it looks similar only it uses replace instead of format
<garyvdm> luks: I also use a patched version of extmerge. And I could not get conflicts to do what I wanted - I should just fix it my self but I've not had time.
<garyvdm> I want it to run meld bar.py.THIS bar.py bar.py.OTHER
<luks> "meld %t %r %o" doesn't work?
<bialix> btw, qconflicts does not support winmerge
<TheJosh> awilkins, surely a 'smart' server, which provides its own transport, should be able to proved basic authentication
<LarstiQ> TheJosh: very little people run bzr://
<LarstiQ> hmm, that came out wrong
<TheJosh> LarstiQ, perhaps because it doesn't have authentication
<LarstiQ> TheJosh: rather, because we alread have ssh I think
<TheJosh> yeah, but then I am opening up everyone to my entire VPS.
<LarstiQ> TheJosh: but have a look at http://pypi.python.org/pypi/ClueBzrServer/0.2
<TheJosh> thanks
<garyvdm> bialix: please will you see if lp:~garyvdm/qbzr/bug402103 works
<bialix> garyvdm: it works, but strange
<garyvdm> bialix: Your PyQt is more fussy than mine.
<bialix> if I have tree w/o changes and then change file and refresh there appears additional columns: date/size etc
<garyvdm> bialix: TreeWidget never shows the size.
<garyvdm> Is this is qcommit?
<garyvdm> *in
<bialix> garyvdm: it seems like PyQt4.4.x Windows build is much worse than 4.3.1
<bialix> in qcommit, yes
<garyvdm> bialix: That's surprising. Please will you imagebin a screenshot.
<bialix> may be I need file a bug?
<garyvdm> bialix: ok
<bialix> garyvdm: http://imagebin.ca/view/5nu7sR.html
<garyvdm> bialix: it should be easy to change qpush to change subprocess starting dir, instead of using -d
<garyvdm> bialix: that is a bug.
<bialix> I'll file it
<luks> speaking of qci, would somebody object if I get rid of the help text in the Branch group (when committing to a checkout)?
<bialix> garyvdm: any ideas about bug 402100?
<luks> I don't think it belongs there and it takes space
<garyvdm> bialix: looking at that screen shot, I realized that Bug 402100
<ubottu> Launchpad bug 402100 in qbzr "qcommit: filename is not fully visible and column is not resizable" [High,Confirmed] https://launchpad.net/bugs/402100
<garyvdm> is due to your pyqt version
<garyvdm> I'll boot into windows just now to fix it.
<bialix> luks: it was idea of Mark Hammond, I never was big fan of big texts there
<awilkins> What do you dudes use to make the UI? QtCreator?
<bialix> QtDesigner
<luks> I'd rather write a manual than have that text in UI
<garyvdm> aqilkins: some times
<bialix> some dialogs hand written
<garyvdm> ^^^ most of the time.
<bialix> :-)
<bialix> Designer is very good to mock UI
<bialix> garyvdm: btw about your cool idea to show revision message in qdiff: may be we need to do it all the time when qdiff running as qdiff -cN ?
<garyvdm> Yes
<luks> yeah, I'd like that too
<garyvdm> I personally don't use that very often. I normally go into qlog - then dbl click on a rev.
<bialix> IIRC gitk shows diff right in the log window when user selects revision
<garyvdm> and vis shows it in a tab
<bialix> garyvdm: https://bugs.launchpad.net/qbzr/+bug/402218
<ubottu> Ubuntu bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Confirmed]
<garyvdm> bialix: thanks
<luks> gitk can do that, because git is fast enough :)
<luks> even getting the revision delta is slow in bzr
<CaMason> hi guys. I took a branch, and I've made a number of commits to it. I've now made a change to a single file, and I'd like to merge that single change into the parent branch. Is this possible?
<awilkins> CaMason: Yes, for given values of yes
<garyvdm> luks: meld %t %r %o - gives me "Error while running merge tool (code 0)"
<luks> hm
<CaMason> would you mind explaining the process at all?
<awilkins> CaMason: You can i) Cherrypick that revision into parent, ii) start a new branch off parent, make the change there and merge it into both branches
<CaMason> brilliant, thanks I'll look that up
<CaMason> with option2, should I uncommit from my branch before merging it in from the new new branch?
<garyvdm> bialix: I can't reproduce  bug 402218.
<ubottu> Launchpad bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Confirmed] https://launchpad.net/bugs/402218
<garyvdm> I tried in a lw checkout
<garyvdm> Where the wt tip is older than the master branch tip
<bialix> bug 402218 is not related to lt checkout I guess
<ubottu> Launchpad bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Confirmed] https://launchpad.net/bugs/402218
<garyvdm> Ah - bialix: If you scroll to the right, do you see the status column
<garyvdm> I think that all columns are visible
<garyvdm> I originally thought that it was because it had a RevisionTree, and not a WorkingTree.
<bialix> garyvdm: yes, the status column here
<bialix> I've used small window size to reduce screenshot
<bialix> garyvdm: additional columns appears only if you start qci in clean tree (without any changes)
 * GaryvdM reading the comments in http://news.slashdot.org/story/09/07/21/1224259/Canonical-Fully-Open-Sources-the-Launchpad-Code while I wait for bzr to pull lp:qbzr very slowly...
<Tak> heh
<bialix> GaryvdM: another problem with qci: when I have pending merge and many many renamed files in subfolder then scrolling wt view does not repaint it until I click mouse on some item
<GaryvdM> bialix: Ok - please will you try get a screenshot
<bialix> screenshot?
<bialix> I'm not sure
<bialix> it's need to see in action
<GaryvdM> bialix: ok - Please log a bug.
<GaryvdM> I just managed to fix one of the column bugs. - Looking up the bug number.
<GaryvdM> bialix: Bug 402218 fixed :-)
<ubottu> Launchpad bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Fix released] https://launchpad.net/bugs/402218
<ubott2> Launchpad bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Fix released] https://launchpad.net/bugs/402218
<ubottu> Launchpad bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Fix released] https://launchpad.net/bugs/402218
<ubott2> Ubuntu bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Fix released]
<ubottu> Ubuntu bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Fix released]
<ubott2> Launchpad bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Fix released] https://launchpad.net/bugs/402218
<bialix> lol
<bialix> ubottu fight with ubott2
<GaryvdM> These bots need to chill!
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<beuno> I don't have op access to remove him  :/
<GaryvdM> Hi beuno
<beuno> hi GaryvdM!
<GaryvdM> Must be an exciting day for everyone at Canonical!
<beuno> it is  :)
<beuno> we're very happy about the release
<beuno> you don't drop a few million lines of code into the world every day
<bialix> amazing
<bialix> interesting, why codehosting is open sourced in the end?
<beuno> bialix, Mark decided to release everything. That's about as much as any of us know  :)
<bialix> hm
<luks> marketing is usually the reason for such decisions :)
<beuno> luks, not in Canonical  ;)
<luks> I don't believe that
<beuno> you should work for us for a while then
<GaryvdM> bialix: bug 402100 seems to be a qt bug with using ResizeToContents and having check boxes.
<ubottu> Launchpad bug 402100 in qbzr "qcommit: filename is not fully visible and column is not resizable" [High,Confirmed] https://launchpad.net/bugs/402100
<ubott2> Launchpad bug 402100 in qbzr "qcommit: filename is not fully visible and column is not resizable" [High,Confirmed] https://launchpad.net/bugs/402100
<ubottu> Ubuntu bug 402100 in qbzr "qcommit: filename is not fully visible and column is not resizable" [High,Confirmed]
<ubottu> Launchpad bug 402100 in qbzr "qcommit: filename is not fully visible and column is not resizable" [High,Confirmed] https://launchpad.net/bugs/402100
<ubott2> Ubuntu bug 402100 in qbzr "qcommit: filename is not fully visible and column is not resizable" [High,Confirmed]
<ubott2> Launchpad bug 402100 in qbzr "qcommit: filename is not fully visible and column is not resizable" [High,Confirmed] https://launchpad.net/bugs/402100
<bialix> any chance on workaround?
<GaryvdM> One solution would be to Stretch the filename and ResizeToContents of the status.
<GaryvdM> That did not work to well with qbrowse - cause the status is then to far away from the filename
<bialix> GaryvdM: maybe just to not use ResizeToContents in qci?
<GaryvdM> ok
<bialix> GaryvdM: btw, many thanks to qlog branch1 branch2 --> it's fantastic for doing complex repeated merge of 2 diverged branches!
<bialix> I mean refresh
<GaryvdM> :-)
<igc> night all
 * bialix waves
<KhaZ> Hrmm, weird problem I'm having.  I'm running bzr under cygwin.  I've got a ~/.bazaar/bazaar.conf with an alias set up for bzr st.  If I use the bzr that ships with cygwin, the alias gets triggered on bzr st.  If I use the win32 native bzr, the alias doesn't trigger.
<KhaZ> Does the native and the cygwin binaries have different locations for $HOME?
<KhaZ> Oh, just read online about %APPDATA%... Damn.
<luks> you can put your config to %APPDATA% and make a symlink to that from cygwin's home
<KhaZ> I thought symlinks don't work properly in cygwin - aren't they just copies?
<luks> I don't know actually
<luks> I just expected them to work
<KhaZ> Yeah; me too. :(
<KhaZ> That said, it would work.  The only irritation is that I version control my home directory, so now I have to install something outside of my home directory to make this work.
<KhaZ> I wonder why the difference between Windows an Unix versions?  It would be so convenient to always have it in $HOME, at least in (my) theory. ;)
<luks> native applications on windows don't put their data directly in the home directory
<luks> while native applications on unix do that
<KhaZ> Right.  So is it just a matter of following the default policy on the platform you're on?
<luks> I guess so
<KhaZ> As in, bzr has no requirement to use $APPDATA except for conforming to the OS it's on?
<KhaZ> (Just curious here.)
<luks> you can set $BZR_HOME if you want
<luks> yes
<KhaZ> Oh.  That sounbds awesomer.
<KhaZ> Huh.  Setting BZR_HOME yields a No handlers could be found for logger "bzr" error.
<KhaZ> "bzr: ERROR: [Error 3] The system cannot find the path specified: '/cygdrive/c/Documents and Settings/eparker/bazaar'"
<KhaZ> export BZR_HOME="$HOME" should work, no?
<luks> you can't access that path from native windows
<KhaZ> Oh.  Duh
<KhaZ> Right
<KhaZ> It's using the native binary but it doesn't know WTH /cygdrive is.
<KhaZ> My bad.
<KhaZ> Ack.  $BZR_HOME doesn't set the root of where the config files.  I still need to duplicate my configs.  I'm reading the ConfiguringBzr page and there doesn't seem to be an env-var for 'this is the root of bazaar\'s configs variable'.  Any chance you know of one, luks?
<KhaZ> (Right now I've got ~/.bazaar/[my config files] and ~/.bazaar/bazaar/2.0/[my config files], which is rather uggo.
<luks> can't you just set BZR_HOME differently on windows and cygwin?
<luks> make it point to %APPDATA%/bazaar/2.0 on windows
<luks> and ~/.bazaar on cygwin
<KhaZ> I can, but it looks like on windows/cygwin they append the directory bazaar/2.0/ to whatever BZR_HOME is.  On Linux they just append .bazaar to it.
<luks> oh, hm
<KhaZ> Hence my problem.  I need two directories to version my config files.
<KhaZ> I suppose I could read the source to figure it out if need be.
<KhaZ> It seems like a strange behaviour to have an env var for a partial path.
<luks> that sucks, there doesn't seem to be a way around it
<KhaZ> That does suck.  Maybe I'll write a ticket about it; see if the devs think it's a good idea.  Definitely would help me.
<luks> changing the behavior of BZR_HOME is most likely not an option
<luks> but a new variable could be added
<KhaZ> That's what I'm thinking.  I hate to suggest yet another env var, but that would probably hurt the least people.
<KhaZ> Ah; looks like there's already a bug for it.
<KhaZ> https://bugs.launchpad.net/bzr/+bug/348640
<ubottu> Ubuntu bug 348640 in bzr "Want a variable to override location of ~/.bazaar etc" [Low,Confirmed]
<ubott2> Ubuntu bug 348640 in bzr "Want a variable to override location of ~/.bazaar etc" [Low,Confirmed]
<luks> this is trivial to fix
<luks> but there is no way I'm sending a patch to bzr again :)
<KhaZ> Hah; why's that luks ? :)
<luks> let's not discuss that :)
<luks> http://paste.pocoo.org/show/129942/
<luks> if you want you can take this, add a test and submit it
<KhaZ> Oh, hot.  Easiest fix I never had to write. ;)
<KhaZ> I'll monkey with that and see.  I wonder if my last patch ever got taken... I never did follow up on it.
<nickoe> How do I update to a specific revision?
<luks> nickoe: you can't update a checkout to a specific revision
<luks> nickoe: what exactly do you want to do?
<nickoe> revert a file
<luks> then "bzr revert -rX FILE"
<nickoe> luks: $  bzr revert -rX main.c
<nickoe> bzr: ERROR: No namespace registered for string: u'X'
<luks> replace X is the revision you want
<luks> or use "bzr revert main.c" if you want the last committed revision
<luks> er, s/is/with/
<nickoe> $  bzr revert -r1 main.c
<nickoe> bzr: ERROR: Not a branch: "/some/silly path to my file/main.c/".
<nickoe> i am exec in /some/silly path to my file/
<nickoe> luks, what is wrong?
<luks> /some/silly path to my file/ is probably not a branch
<nickoe> luks, does it have to be?
<luks> you normally want to rever a versioned file
<luks> *revert
<luks> and such a file must be in a branch
<nickoe> ohh, ofc, I am in the woring project, :P
<Kinnison> Anyone know how harmful messages like this are: inconsistent details in skipped record: ('michael.hudson@canonical.com-20070704120851-qih0ajr8ie2csj6m',) ('97295 243 0 276', ((('michael.hudson@canonical.com-20070704120556-wd7z1ffquvavt3so',),),)) ('781826 243 0 276', ([('michael.hudson@canonical.com-20070704120556-wd7z1ffquvavt3so',)],))
<nickoe> luks, thank you, bye
<j^> why does  bzr branch lp:launchpad need like 500mb ram?
<j^> looks like its even still growing
<j^> this is with Bazaar (bzr) 1.16.1
<j^> 912m 708m 1592 S   44 36.3   3:07.53 bzr
<LarstiQ> j^: is that over http or ssh?
<j^> LarstiQ, i think http, i have an account on lp though and it usually uses ssh if i do bzr lp:something
<j^> upgrading now to 1.17 and will try again
<LarstiQ> j^: I think the relevant bug might be https://bugs.edge.launchpad.net/bzr/+bug/402657
<ubottu> Ubuntu bug 402657 in bzr "2a fetch over dumb transport reads one group at a time" [Medium,Triaged]
<LarstiQ> j^: hmm, or maybe a related one
<j^> [#########/          ]   3792KB    46KB/s | Fetching revisions:Inserting stream
<LarstiQ> j^: does ~/.bzr.log illuminate?
<j^> that looks like http
<j^> 159.916  25 bytes left on the HTTP socket
<LarstiQ> j^: right
<LarstiQ> j^: what does `bzr launchpad-login` report?
<j^> j
<LarstiQ> hmm, why doesn't it pick ssh then
<j^> 1.17 still uses all my ram
 * LarstiQ nods
<LarstiQ> j^: you can do it in bits and pieces
<LarstiQ> j^: were you using a shared repository to branch into?
<j^> bzr branch lp:launchpad/edge  launchpad uses ssh
<LarstiQ> ok
<j^> LarstiQ, i was not using a shared repository was just trying bzr branch lp:launchpad
<LarstiQ> j^: right
<LarstiQ> then it is slightly trickier to do it in batches
<LarstiQ> j^: bzr branch -r 1 lp:launchpad launchpad; cd launchpad; bzr pull -r 1000; bzr pull -r 2000; etc
<j^> i am happy to get it in a shared repos if that helps
<j^> how would i use a shared repos?
<LarstiQ> j^: if you plan to do development on launchpad that would be the recommendation
<j^> for now i wanted to read the code
<j^> since the webinterface does not list the files
<j^> it lists them but does not show the contents
<LarstiQ> j^: `bzr init-repo --2a ~/src/launchpad; bzr branch lp:launchpad ~/src/launchpad/trunk` for instance
<LarstiQ> j^: or you could use the trick I just showed you
<j^> will try the shared repos first, i might start hacking on it
<LarstiQ> j^: there, https://bugs.edge.launchpad.net/bzr/+bug/402139 might be the bug I was looking for
<ubottu> Ubuntu bug 402139 in bzr "Branching a large branch eats memory like crazy" [Undecided,New]
<Kinnison> Anyone have any idea why bar is giving me annoying messages like 'SHA1KnitCorrupt' when I try and pull the dulwich repo?
<LarstiQ> Kinnison: I do not, jelmer might
<Kinnison> Are there any bzr people at debconf this year?
<LarstiQ> Kinnison: Jelmer is
 * LarstiQ sadly is not :(
<LarstiQ> Kinnison: are you there?
<Kinnison> I am, sorry, was re-reading bits of soyuz and reminiscing
<Kinnison> jelmer: I should prod you about this dulwich problem, but perhaps tomorrow?
<jelmer> Kinnison: yeah, I should be around tomorrow
<Kinnison> coolbeans
 * Kinnison decides to head to the lobby with some cards
<LarstiQ> ooh
 * LarstiQ really needs to find some Debian people geographically close soon
<|malibu|> Help!
<|malibu|> I had a commit hang on me.  I broke out of it and now I have a remote lock
<|malibu|> Anyone know how I clear this out and redo the commit?
<beuno> |malibu|, and bzr break-lock REMOTE_URL doesn't work?
<|malibu|> didn't know about that one
<|malibu|> ok seems to have worked..
<LarstiQ> |malibu|: break-lock should be suggested to you if you try any operation on a locked branch?
<|malibu|> commit again should catch everything?
<LarstiQ> |malibu|: yeah
<|malibu|> ok cool, thanks
<|malibu|> I did bzr -h but didn't see break-lock in there
<LarstiQ> |malibu|: `bzr help commands` lists it
<|malibu|> ah
<Hillshum> How do I clone a cvs repo?
<Hillshum> anyone?
<Leonidas> Hillshum: CVS repos don't get cloned, they get checked out
<Leonidas> uhm, bzr 1.17 depends on zlib for building, why is that so?
<Hillshum> Leonidas, Yeah, I think I have it now, so "bzr checkout http://some.box.com/trunk" ?
<sender> Can anyone help me get started to contribute translations for bzr plugins?
<Leonidas> Hillshum: CVS does not use HTTP
<Hillshum> Leonidas, what protocol then?
<Leonidas> Hillshum: most of the time it is 'pserver'
<Leonidas> Hillshum: what do you want to do in the first place?
<sender> E.g. how do I add a new translation to bzr-explorer (https://translations.launchpad.net/bzr-explorer/trunk) ?
<Hillshum> Start woking on a antiquated cvs repos
<Hillshum> hillshum@ibook:~$ bzr checkout pserver://parliament.cvs.sourceforge.net/cvsroot/parliament
<Hillshum> bzr: ERROR: Unsupported protocol for url "pserver://parliament.cvs.sourceforge.net/cvsroot/parliament"
<Leonidas> bzr does not support cvs directly
<amanica> sender, I think you may need to join the team
<Leonidas> Hillshum: let launchpad import the project, then clone it.
<amanica> also it may automatically show your language if launchpad knows it
<amanica> sender: i.e if you added your language to your launchpad preferences
<sender> amanica: thanks, you are right. I notified LP of my language and now I can select it.. :)
<amanica> sender: I'm just guessing
<amanica> cool
<sender> amanica: do you know if I can use a local app to translate instead of the LP interface?
<amanica> yes you can
<sender> amanica: and how can I test bzr-explorer with the translation?
<amanica> I have not used it yet though
<sender> amanica: I've got poedit here, but do not have a clue how to start off
<amanica> sender: mmm.. maybe bialix or ianc can help you there
<LarstiQ> Leonidas: because bzr uses zlib and the C extension needs to include headers/build against it
<amanica> sender: maybe ask this on the mailinglist
<amanica> I'm sure you'd get a responce
<sender> amanica: will do, thanx :)
<amanica> cool
<Leonidas> LarstiQ: this seems to be a new feature, right?
<LarstiQ> Leonidas: yes. I can look up which exact bzr version introduced it if you want.
<lifeless> moin
<DaffyDuck_> Let's say we are two working on a project. A shared repository is located on a dedicated server. My friend makes changes, and "bzr push":es changes. Then I make changes and push changes. This causes a conflict. How is this handled? Do I merge from the server, and then push the merged changes?
<amanica> goodnight
<Leonidas> LarstiQ: thanks, don't bother. I just saw it today because the usual easy_install -U bzr failed and somewhere inside of the _terribly helpful_ messages of GCC was a missing header error.
<awilkins> DaffyDuck_: are you working in a branch, or a checkout?
<awilkins> DaffyDuck_: But yes, you can merge, and push the changes. Then your friend will have to pull your changes (or merge later after he commits some more)
<lifeless> DaffyDuck_: if youre pushing to the same branch, I suggest using a checkout
<DaffyDuck_> awilkins: Um.. What's the difference between a branch and a checkout? I always do "bzr branch ...", but I assume I can do a "bzr checkout ..."?
<DaffyDuck_> Ah, so a checkout is simply set of working files?
<awilkins> DaffyDuck_: Checkout is "bound" to the master branch so all commits are also comitted there
<awilkins> Unless they changed it already so that checkouts are all lightweight ones (no local repository branch)
<awilkins> If you've used SVN, a lightweight checkout is like an SVN working copy
<lifeless> DaffyDuck_: a checkout provides the cvs/svn style centralised workflow
<DaffyDuck_> Ah, ok. That makes sense.
<lifeless> where commits to a common object are serialised and the left hand history is preserved
<lifeless> at an implementation level the default checkout is a 'bound branch'
<lifeless> but you can also create one with no history attached, if you pass --lightweight. This is not a good idea from a performance angle if you're working over anythin other than a LAN
<DaffyDuck_> checkout = centralized, branch = decentralized (but push/pull can make it semi-centralized).
<awilkins> Or if you ever use your laptop on the train :-)
<DaffyDuck_> awilkins: I use my laptop on the train almost every day. :)
<lifeless> DaffyDuck_: a normal checkout will work fine on the train, you just can't commit
<lifeless> DaffyDuck_: the way I do this is I have a couple of branches for projects with shared mainlines
<DaffyDuck_> lifeless: Yeah, but it's commit I want. :)
<lifeless> one that is a checkout
<lifeless> and one that is a normal branch
<lifeless> when I'm offline, or doing speculative stuff, I use the normal branch
<lifeless> once its reviewed and ready to land, I merge it to the checkout and commit
<lifeless> which simultaneously pushes it and enforces the mainline
<awilkins> You can commit to Ã"heavy" checkouts, there are just extra steps (nd parameters)
<DaffyDuck_> lifeless: Thanks for the tip. That feels like a very natural way to work, so I just may adopt it.
<awilkins> I tend to have a local no-trees repository and take lightweight checkouts from it, branch as I wish locally, and merge and push my changes when required
<lifeless> awilkins: oh, I have these branches in a shared repo; but the key thing is checkout+regular branches ;)
<awilkins> I'll commit my patches, switch my working tree back to the mainline, merge from the local branch, and then push
<DaffyDuck_> So both of you have something like proxy checkouts. Hmm..
<awilkins> We do the same thing we just use different infrastructure
<|malibu|> Does bazaar have commit hooks on the server side?
<lifeless> yes
<|malibu|> awesome, tks
<awilkins> I'm really still interested in seeing a version of pipeline that supports parallel pipes
<awilkins> Or just a straight port of Mercurial pbranches
<awilkins> (which I was tempted to do after I saw it was just one source file)
<|malibu|> BTW.. bzr with light checkout makes an awesome dropbox-type thing
<|malibu|> I'd really like to get it to do a commit every time I write a file.. but even with a batched up commit it works great
<DaffyDuck_> Is "init-repo" (shared repository) merely a way of collecting several branches of a project in a single entity on a server?
<fullermd> No, it doesn't make a single entity of anything.  It's a way of sharing storage among branches with common history.
<DaffyDuck_> fullermd: So, if I have a dev, and a stable. I merge dev to stable, then stable actuallty uses the storage of dev (if I do no changes)?
<fullermd> Well...    yes, I guess, but that's a confusing way of looking at it.
<fullermd> Better is "if I have a dev and a stable, they both store their history in one common place"
<fullermd> (and thus any common history, which is probably most of it, is only stored once rather than twice)
<fullermd> Every branch always has a repository, because that's where revisions are stored.  init-repo is used to create shared repos, so that multiple branches can use the same repository.
<DaffyDuck_> fullermd: Ah, ok. From the init-repo example, it looked like they smiply created two different branches inside a "init-repo" directory, and I was wondering if the branches can simply be moved out of that init-repo directory and be used individually, but I guess there's more to it than that.
<DaffyDuck_> Hmm... It seems like init-repo is what I want to do. I need to experiment with it a little.
<fullermd> Yes, if you move them out of the shared repo, they can't find it anymore.  That would be Bad(tm).
<fullermd> You can move them around all you want underneath it though.
<DaffyDuck_> Oh. Hmm... I find that cool, yet confusing.
<fullermd> (of course, if you 'bzr init' two branches inside a repo, they don't have any shared history, so there's no real win)
<DaffyDuck_> fullermd: Yeah, I figured. You init one "branch", and then "branch" the others to get full usage?
<fullermd> Well, most of the time, you'd "branch" an existing branch of the project, then "branch" from that (or from other existing branches)
<fullermd> But 'init' creates a branch ab ovo.  There's no history [yet], and any future history is thus divorced from the history of any existing branch, or any separately init'd branch.
<DaffyDuck_> fullermd: Ah. So - technically - bzr will check if it is inside a?shared repo when a "branch" is created?
<lifeless> DaffyDuck_: if you're starting new stuff in bzr, I encourage you to pass --2a to your init-repo command
<lifeless> DaffyDuck_: this is the format that will be default in 2.0
<fullermd> DaffyDuck_: Yes, an existing repo will be used if it's found, otherwise we'll create a new (unshared) one specifically for that branch.
<lifeless> jam: around?
<DaffyDuck_> lifeless: Ok. The description doesn't tell me anything, but I'll take you advise.
<DaffyDuck_> fullermd: Excellent. The puzzle is coming together.
<fullermd> DaffyDuck_: So, if you have a repo at /repo, and you go to /repo and run "bzr branch http://some/project/ a", the branch 'a' will use the repo.
<fullermd> DaffyDuck_: And if you run "bzr branch http://some/project/ b" after that, b will also use the repo, so it will finish very quickly since it already has all the revisions in the repo from when it branch'd into 'a'.
<lifeless> DaffyDuck_: we're hopinh to make it the default in about a month
<DaffyDuck_> I'll start experimenting (best way of learning) with shared repos tomorrow. Thanks for the information, all of you.
<DaffyDuck_> I can't believe we stuck with subversion this long. :(
<DaffyDuck_> Expect more questions tomorrow. :)
<lifeless> DaffyDuck_: the only caveat is you need bzr 1.16.1 or newer
<lifeless> DaffyDuck_: but you want that anyway :)
<DaffyDuck_> lifeless: It appears I have 1.16.1.
#bzr 2009-07-22
<lifeless> igc: poolie: review plox https://code.edge.launchpad.net/~lifeless/bzr/bug-367632/+merge/8928
<litwol|mac> hello world
<spiv> Gar, my wireless keeps bouncing.
<litwol|mac> I've looked around but my lack of bzr knowledge is probably keeping me away from find the answer. i am looking for something similar to unfuddle that has bzr support. Does anyone know of such service ?
<lifeless> whats unfuddle
<litwol|mac> lifeless: http://www.google.com/search?client=opera&rls=en&q=unfuddle&sourceid=opera&ie=utf-8&oe=utf-8
<lifeless> launchpad.net
<litwol|mac> That is one option, yes.
<litwol|mac> Does any thing else come to mind ?
<lifeless> savannah
<lifeless> alioth
<lifeless> sourceforge
 * litwol|mac googles
<litwol|mac> lifeless: savannah.gnu.org ?
<lifeless> yes, that has bzr support
<lifeless> I'm curious why you seem to dislike launchpad.net
<mwhudson> huh, unfuddle is a new one on me
<litwol|mac> lifeless: silly reason really. i got spoiled by unfuddle's ease of use and pretty GUI
<lifeless> well, launchpad.net has the prettiest gui of all the bzr hosting sites I know of, IMO
<litwol|mac> i just finihed confirming account there :). though in the end i will have very little use of their GUI, its just nice when you're introduced to a project :). less things to go 'wtf' about.
<litwol|mac> by the way i'm very new to bzr, haven't even got a single repo init'd
<litwol|mac> Didn't want to bother until i found a way to host my repos remotely where proper backups exist :-p
<litwol|mac> hopefuly...
<poolie> hullo all
<spiv> Hello.
<litwol|mac> I heard bzr has very nice community with abundancy of documentation which is easy to understand.. unlike other solutions.
<mwhudson> litwol|mac: yes, we keep backups :)
<poolie> lifeless: i'll look
<lifeless> thanks
<litwol|mac> cool cool :)
<poolie> what is the plat du jour at chez spiv?
<litwol|mac> davidstrauss: "_
<litwol|mac> davidstrauss: :)
<spiv> plat?  My French vocab is pretty small...
<davidstrauss> litwol|mac: hi
<spiv> Oh, right.
<mwhudson> spiv: for the not-very-frenched "plat du jour" is atomic :)
<litwol|mac> davidstrauss: paul expressed his interest this morning to receive report if you haven't sent it yet .
<spiv> mwhudson: right.  In the regular context I'd have had no trouble :)
<litwol|mac> davidstrauss: do you host your own repository for pressflow ?
<davidstrauss> litwol|mac: yes
<litwol|mac> davidstrauss: hmm. Would it be too much to ask for you to describe your process with backups and management to make sure it doesn't get destroyed in ______ [insert a horrible/unlucky scenario]
<davidstrauss> litwol|mac: For my repo?
<litwol|mac> yes
<litwol|mac> davidstrauss: <<< /me 's learning process
<davidstrauss> litwol|mac: It's stored on a Dell 2950 III with RAID-1 10K RPM SAS disks in a Rackspace datacenter. It's backed up nightly to a geo-redundant location.
<davidstrauss> litwol|mac: But more importantly, every bzr checkout and branch I have of Pressflow has all the history, anyway.
<litwol|mac> oho
<litwol|mac> very nice. thx.
<davidstrauss> litwol|mac: It is very hard to lose the history of a Bazaar project. Everyone has it. It replicates everywhere.
<litwol|mac> hmm, you're right. I suppose i need to make an effort to avoid expectations based on my SVN/cvs experience
<davidstrauss> litwol|mac: I should also note that the actual server is also in one of the most geologically and natural-disaster safe cities in North America: Dallas.
 * litwol|mac nods
<davidstrauss> litwol|mac: Pressflow branches are probably one of the less important things on that box.
<litwol|mac> hehe. i bet.
<litwol|mac> i guess i need to find some docs on the subject of doing bzr backups. i know nothing bout it at this point. need to find out where all the hisotry is being kept.
<litwol|mac> davidstrauss: thx for the info. I'll attempt to use something similar... although on a cheaper host :-p
<lifeless> .bzr/repository
<davidstrauss> litwol|mac: Making a bzr backup simply involves branching
<fbond> This mean anything to anyone?
<fbond> bzr: ERROR: Server sent an unexpected error: ('error', "open() got an unexpected keyword argument 'ignore_fallbacks'")
<lifeless> fbond: outdated plugin on the server
<litwol|mac> lifeless: oh!. thank you.
<fbond> lifeless: Oh, probably loom.
<lifeless> litwol|mac: but as davidstrauss says just doing bzr push <somewhere> will copy everything there
<davidstrauss> litwol|mac: The first step to learning distributed tools is forgetting the annoying habits you've made using centralized ones.
<litwol|mac> That i know. What i didnt know is which directory specifically i need to backup on that (or other) machine to really back it up.
 * litwol|mac takes note.
<davidstrauss> litwol|mac: A push or branch does "really back it up"
 * litwol|mac nods.
<davidstrauss> litwol|mac: The only thing you'd lose are ghost revisions, which are basically trash revisions, anyway.
 * litwol|mac googles ghost revisions
<lifeless> litwol|mac: just backing up .bzr/repository doesn't backup branches or other metadata; but it does backup all the history
<lifeless> litwol|mac: generally to backup just use your normal backup tools ;)
<litwol|mac> lifeless: So what do i need to backup to perform an absolutely complete backup ?
<lifeless> as long as you're not committing at the same time it will get a consistent snapshot
<litwol|mac> lifeless: haha, i dont use anybackup tools yet. i'm trying to learn this stuff .
<lifeless> well
<lifeless> go get some ;)
<fbond> lifeless: How can I push from a loom but only push the current thread as a normal branch?
<lifeless> fbond: bzr init <target>; bzr push <target>
<fbond> lifeless: Ah.
<poolie> lifeless: done
<lifeless> fbond: there is also bzr export-loom, which will export every thread
<litwol|mac> Okey i think i've acquired enough info for now. i'll begin using it and i'm sure more specific questions will rise eventually. Cheers.
<lifeless> poolie: thanks
<litwol|mac> thank you davidstrauss and lifeless
<poolie> lifeless: want to re-read my uifactory branch?
<poolie> the incremental changes are fairly small
<fbond> lifeless: Yeah, I was hoping to avoid all those branches. ;)
<poolie> but i can't work out how to make lp give me the incremental diff
<poolie> probably i need to guess which revision was proposed before based on the dates or something
<poolie> i'll do that and attach it
<lifeless> poolie: sure, url me up or get lp to drop me a mail
<lifeless> poolie: I'm just implementing what we discussed yesterday
<poolie> as far as the additional delta tests?
<lifeless> tests and logic, yes ;)
<poolie> lifeless: thinking about bryce's bug
<poolie> i was contemplating a variation of check that would, very quickly:
<lifeless> the big pack on windows one?
<poolie> yeah, data loss apparently by the fs
<poolie> there've been a couple like that
<lifeless> we could read after write
<poolie> anyhow: check the hash of the pack files; if any are broken move them aside and try to pull something back from obsolete_packs
<lifeless> but thats rather slow except locally, and all it really shows is that its in cache
<poolie> we could
<poolie> right
<poolie> i suspect it would only help roughly as much as sleep(n) would help
<lifeless> and fsync() on networks is notoriously not-fsync
<poolie> we should sync if we want to be paranoid...
<lifeless> now interestingly
<poolie> and, right
<lifeless> hg has a thread right now
<lifeless> about NULL's being written to windows fs's by file.append()
<lifeless> which is the same API we use
<lifeless> I think I'd put that functionality you suggest into either check or reconcile
<lifeless> separately, I'm more interested in fixing the cause ;)
<poolie> automatically pulling them back?
<poolie> mm
<poolie> well, i guess there's a few things
<poolie> first, it'd be very quick compared to overall check to check the packs
<lifeless> I don't mean magically
<lifeless> it could be an option
<poolie> second, you could try to pull obsolete packs out
<poolie> but it's not guaranteed to fix it
<lifeless> I just don't think a third data-integrity command is a good idea
<poolie> yeah, when i said 'variation of check' i meant either a stage or an option
<poolie> or both
<poolie> not a new command
<poolie> https://code.edge.launchpad.net/~mbp/bzr/387717-progress-bar-tty/+merge/9012 btw
<lifeless> I'd like to see us make more of our core code more easily reusable. I just don't know how. Hooks are good. Layers are good. Separate packages would be interesting but perhaps a problem/difficult to manage
<lifeless> poolie: why the change to SilentUIFactory's input? we use it in tests...
<spiv> Yeah, there's some nice stuff in e.g. bzrlib.commands for instance that isn't particularly specific to a VCS at all.
<lifeless> spiv: I've nearly got that completely detangled with my patches over the last couple of releases
<spiv> Yeah, the code is pretty modular and independent.
<poolie> lifeless: i think it's ill conceived, almost impossible to use correctly as it stands
<poolie> do you really want to read user input with no prompts or output?
<poolie> tests are better served by CannedInputUIFactory
<spiv> But while it's part of bzrlib it's not really very convenient for others :/
<lifeless> poolie: well, we used apply_redirected to provide an appropriate stdin for SilentUIFactory
<poolie> yeah
<spiv> lifeless: I agree with your comments earlier/elsewhere about getting our unittest extensions into the wild and then, hopefully, into the stdlib.
<lifeless> poolie: so I don't quite see the impossible aspect
<poolie> well, i meant other than in testing
<lifeless> btw, looks like I am doing SLUG's indepth talk this month
<poolie> something like loggerhead doesn't want to be reading from stdin
<lifeless> poolie: ah, now I see
<lifeless> poolie: Ok, I'm +1 on making a clearer separation between silent and testing
<poolie> and in tests
<poolie> i think that applyRedirected means that you can't break in to pdb there
<poolie> because it sees the redirected stdin etc
<poolie> so that's an ugly big hammer compared to providing a CannedInputetc
<lifeless> poolie: blackbox tests are the apply_redirected case
<poolie> yeah
<lifeless> poolie: they redirect stdout and stderr anyway
<poolie> so there's a middle ground
<poolie> real blackbox tests need redirection
<lifeless> so pdb is totally borked regardless; redirecting stdin means that pdb at least doesn't hang
<poolie> but ones that are just testing something ui related i think are happier with cannedinput
<poolie> i think eventually it would be nice to do run_bzr with redirections that never actually uses sys.std*
<poolie> so that pdb could still work
<lifeless> I think that would reduce test coverage
<poolie> in other words have the only access to those variables be constructing a uifactory bound to them at a level somewhere near run_bzr
<lifeless> because the python standard library has a habit of writing to sys.std*
<poolie> that may be true
<lifeless> and we *do* catch deprecations and other nonsense from that level, in blackbox tests today
<poolie> well
<poolie> that is true that we may not be able to catch all code going there
<poolie> s/going there/using sys.std*
<poolie> it would probably be at least as reasonable to have those messages go to the test runner stderr
<poolie> at the moment if the test doesn't check its stderr, they'll just be ignore
<litwol|mac> oh!
<poolie> ignored*
<poolie> and i bet not all tests check it
<litwol|mac> does bzr understand what 'lp:' is ?
<lifeless> I try to have all my blackbox tests check stderr
<lifeless> because of this
<lifeless> litwol|mac: yes
<litwol|mac> gosh i just spent 1/2 hour finding a way to branch LOL.. until it hit me that 'may be launchpad is tightly integrated with bzr such that bzr would know that lp means launchpad'
<litwol|mac> gosh
<litwol|mac> good stuff
<poolie> anyhoo
<poolie> we could also stash away real_std* somewhere and have a function that reestablishes them and calls pdb
<spiv> litwol|mac: It's not so much tight integration as a simple plugin that's bundled with bzr, but yes :)
<litwol|mac> Is there a way to port git history+branches (whole repo) over to bzr lp ?
<litwol|mac> i'm sure there is, i rather should ask *how*?
<lifeless> poolie: I like that we get real solid integration coverage with blackbox tests; I don't want to see us shrink that. I like the idea of getting pdb support in those tests if we don't shrink coverage
<poolie> k, me too
<poolie> anyhow, that's a later change
<spiv> litwol|mac: there's a bzr fast-import plugin that can read the fast-import format dumps; there's also a bzr-git plugin that can read git repos directly (so you can use that to import their data into bzr format).
<lifeless> poolie: finally, I don't think we *should need* pdb in blackbox tests, because they are meant to be smoke-level, not comprehensive, and if we can't tell whats going on enough to write a lower level test, we'll have trouble handling user bug reports too
<poolie> :/
<lifeless> poolie: that thats a motivation-for-me thing, not a reason to avoid putting pdb support in
<spiv> litwol|mac: Launchpad has an import-from-git service builtin, btw
<litwol|mac> oh
 * litwol|mac goes to find it
<spiv> (built on bzr-git)
<lifeless> poolie: does that make sense? I'll happily support having pdb in blackbox tests for folk that want it, so long as we don't shrink coverage to get it.
<RAOF> spiv: But launchpad's service will only import a single branch, right?
<litwol|mac> oh crap
<spiv> RAOF: just trunk, yes.
<litwol|mac> i broke LP :-\
<litwol|mac> (Error ID: OOPS-1299A140)
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1299A140
<RAOF> litwol|mac: There's the git-import command (from bzr-git), which will create one branch per git branch.  You could then push all those to launchpad separately.
<litwol|mac> i wont be able to figure it out (yet) without a walkthrough tutorial... i just started >.
<poolie> so
<poolie> we want those tests to be realistic
<poolie> for what happens when you actually run bzr
<poolie> i'd draw an analogy to the fact that we don't start a new python subprocess for every blackbox invocation
<poolie> doing so would in a sense give better coverage
<lifeless> indeed
<poolie> but not in a very useful way
<poolie> and at a high price
<RAOF> litwol|mac: Well, git-import would be easy; you could just "bzr git-import $REPOSITORY" to grab all the branches.  But you probably want to do that inside a bzr repository, for speed and space.
<poolie> in this particular thing
<poolie> well
<poolie> actually, i'm planning to keep chipping away at this
<poolie> it sounds like we're not greatly at odds
<poolie> so let's talk about the next step when i get there?
<lifeless> the docstring for zrlib/ui/__init__.py may want to list CannedUIFactory
<poolie> k
<poolie> probabyl
<lifeless> poolie: its a long patch, so is it ok with you if I just make notes here?
<lifeless> and yes, lets talk more later
<lifeless> the long comment in that file talks about what we /had/
<lifeless> I think it would be better to be totally in the now
<lifeless> and if you want to avoid folk reintroducing subclassing, say so directly
<lifeless> it might even be best as the class docstring for TextUIFactory, so that pydoc shows it
<lifeless> or split between the base class and TextUIFactory
<lifeless> lastly, some tests for CannedUIFactory, if you haven't got any (I can't tell from the patch), would be great
<RenatoSilva> verterok: hi
<lifeless> poolie: ^ review done
<poolie> lifeless: just what you said there?
<poolie> or also on the web?
<lifeless> just here
<poolie> oh ok
<poolie> i just saw your comment
<poolie> <lifeless> poolie: ah, now I see
<poolie> <lifeless> poolie: Ok, I'm +1 on making a clearer separation between silent and testing
<poolie> good :)
<lifeless> :P
<poolie> so, basically just improving the documentation?
<lifeless> yah
<poolie> and the tests for CannedUIFactory
<poolie> ok
<lifeless> oh one more thing
<lifeless> a test for assertRaises
<poolie> actually this is a kind of interesting question
<lifeless> as you've changed it too
<poolie> we'd kind of like parameterized per_uifactory tests
<poolie> to assert all the methods are covered for every implementation
<poolie> but the way they're tested will vary
<poolie> hm
<RenatoSilva> how is this page generated, manually? http://doc.bazaar-vcs.org/bzr.1.17/en/release-notes/NEWS.html#bzr-0-0-0-69-2005-03-22
<lifeless> RenatoSilva: cron + make doc
<lifeless> poolie: so, the contract is the methods that can be called on it
<lifeless> poolie: the outcomes are specific to scenario
<poolie> right
<lifeless> include outcomes in the parameterisation
<lifeless> perhaps as curried things
<RenatoSilva> lifeless: a scheduled cron job running make's doc target?
<lifeless> RenatoSilva: yes
<poolie> RenatoSilva: is it broken or something? or you're just curious?
<RenatoSilva> lifeless: I'm not familiar with make, but what is the source of such information? Is it some text file updated manually?
<RenatoSilva> poolie: curious
<spiv> Reminds me a bit of the smart protocol tests: v1,v2,v3 all support a common set of features (requests with and without bodies, etc.), but the outcomes are different so it was hard to think of a way to reuse the tests.
<lifeless> RenatoSilva: make is a build system, it reads rules from 'Makefile', which we have in the top of the bzr source tree
<poolie> spiv, so what did you do?
<spiv> Currently there's no real reuse :(
<lifeless> spiv: re; being in bzrlib; it does get bzrlib 'out there' :P
<spiv> I did experiment with a test that all the v1 test *names* were also present on the v2 and v3 test cases.
<spiv> It actually found some small gaps, but the test itself was too ugly to merge.
<RenatoSilva> lifeless: the Makefile calls a self-made tool for generating such doc, isn't it
<spiv> poolie: so, basically, if you find a good answer, I'm interested :)
<poolie> mm
<spiv> Because I'm not particularly happy with test_smart_transport atm.
<poolie> at that point you might be better just measuring coverage
<spiv> Well, I think coverage would be a complementary thing to measure, not a replacement.
<lifeless> RenatoSilva: at this point, I suggest you look at the Makefile :)
<RenatoSilva> lifeless: ok
<lifeless> RenatoSilva: you've hit my cache threshold
<spiv> It did like the explicit statement that "every feature/behaviour we check for v1 should also be checked for v2/v3"
<RenatoSilva> heheh
<spiv> It would help in making sure the test method names (on the already large test case classes) wouldn't diverge too much, that the testing strategy was in sync across all three implementations.
<spiv> But the combination of the oddness of having a meta-test, and that actually there are parts where v1/v2/v3 intentionally diverge in behaviour, made it awkward.
<spiv> I still like the idea, though :)
<RenatoSilva> any date for a 1.17 windows installer?
<spiv> mwhudson: litwol|mac's earlier OOPS looks like a code import form bug: https://lp-oops.canonical.com/oops.py/?oopsid=1299A140
<mwhudson> spiv:
<mwhudson> https://bugs.edge.launchpad.net/launchpad-code/+bug/397220
<ubottu> Ubuntu bug 397220 in launchpad-code "Better validation for project field in new code import form" [High,In progress]
<mwhudson> actually fix committed now
<spiv> mwhudson: hooray!
<mwhudson> spiv: and one revision away from edge, in fact
<spiv> mwhudson: heh.
 * igc food
<JoaoJoao> hello
<|malibu|> Does anyone know how to tell where your plugins directory is?
<lifeless> bzr plugins -v, I think
<lifeless> will show where each plugin has been loaded from
<|malibu|> I have one in python2.5 path, one in python2.6 path, one in /usr/share/pyshared/bzrlib
<|malibu|> ok will try
<lifeless> if you mean where your per user directory is, bzr --version shows the config directory, and you can add a plugins directory there
<|malibu|> ok thanks.. that's probably more appropriate
<poolie> igc, nice work with the sphinx stuff
<poolie> i thought we'd use that only for the doc generation though
<poolie> it looks like you've put the overall site structure into it
<igc> thanks poolie. Whatever you think - a mockup is a mockup
<poolie> yeah, the choice of tool for the mockup doesn't matter a lot
<igc> poolie: as long as it drives the right conversation wrt content, then it's valuable
<poolie> but apparently i had missed your point yesterday
<poolie> i hadn't seriously considered using sphinx for the whole site
<poolie> maybe we should....
<Arrrgh> hi guys. I'm developing a VS plugin for Bazaar and have some problems understanding it's behavior. Anyone can help me?
<lifeless> sure
<lifeless> you might want to ask a question :)
<RenatoSilva> Visual Studio?
<Arrrgh> well.. when I rename some folder with files and after run "bzr status" for any files inside, it shows empty status :-/ Is this a bug?
<Arrrgh> yes, Visual Studio
<lifeless> Arrrgh: its not a bug, those files haven't changed
<lifeless> if you just run 'bzr st' it will show the folder as renamed
<lifeless> I'm completing a change at the moment that will make bzr st report the folder as renamed when you run 'bzr st' inside it
<lifeless> or for files inside it
<RenatoSilva> isn't renaming tracked by bzr? I thought so...
<lifeless> RenatoSilva: it is, the files haven't been renamed.
<Arrrgh> nice. when it'll be ready?
<lifeless> Arrrgh: tomorrow I suspect
<lifeless> Arrrgh: its a side effect of a change being made to ensure that partial deltas are always safe to apply to the source tree
<Arrrgh> anyway, it'll make this part of my work much easier =)
 * RenatoSilva gtg, thanks evybody
<spiv> Updated inventory-delta patch up for review.
 * spiv -> lunch
<lifeless> spiv: oh
<lifeless> spiv: if it doesn't get parameterised tests from test_inv, please add that in :P
<lifeless> spiv: it should I think, if it uses Repository.add_inventory_by_delta
<spiv> It does use that, yes.
<spiv> Thanks.
<lifeless> spiv: cool, as long as it doesn't add surface area that could be wrong I think its fine not to specifically interface test it
<lifeless> spiv: if it does add surface area (and perhaps it does, by having a new kind), then I'd be inclined to get it tested
<verterok> lifeless, thumper: ^ atm only bzr project group ;)
<verterok> hi bazaaristas!
<verterok> I'm pleased to introduce hal_, among other things the review list bot
<verterok> hal_ accepts commands like:@command_name and some commands via privmsg, e.g: @reviewlist or /msg hal_ reviewlist
<hal_> https://launchpad.net/~spiv/bzr/inventory-delta/+merge/9125 | No reviews
<hal_> https://launchpad.net/~mbp/bzr/387717-progress-bar-tty/+merge/9012 | No reviews
<hal_> https://launchpad.net/~bzr/bzr/smooth-upgrades/+merge/8921 | No reviews
<hal_> https://launchpad.net/~ndurner/bzr/bzr-ftp/+merge/8906 | Needs Fixing: 1
<hal_> https://launchpad.net/~jameinel/bzr/1.18-stack-and-annotate-393366/+merge/8840 | No reviews
<hal_> https://launchpad.net/~abentley/bzr/devnotes/+merge/8766 | No reviews
<hal_> https://launchpad.net/~amanica/bzr/log_returns_too_much/+merge/8538 | Approve: 1
<hal_> https://launchpad.net/~mbp/bzr/391411-reconfigure-stacked/+merge/8527 | Needs Fixing: 1
<hal_> https://launchpad.net/~garyvdm/bzr/register_lazy_decorated/+merge/8430 | No reviews
<hal_> https://launchpad.net/~amanica/bzr/mv_after/+merge/8179 | Approve: 1
<hal_> https://launchpad.net/~bzr/bzr/faster-commit-file/+merge/7885 | Needs Fixing: 1
<hal_> https://launchpad.net/~ian-clatworthy/bzr/faster-dirstate-saving/+merge/7537 | No reviews
<hal_> https://launchpad.net/~ian-clatworthy/bzr/faster-log-file/+merge/7535 | No reviews
<hal_> https://launchpad.net/~lifeless/bzr/check-1/+merge/7489 | Approve: 1
<hal_> https://launchpad.net/~mhammond/bzr/update-r/+merge/6980 | Needs Information: 1
<hal_> https://launchpad.net/~wjl/bzr/bug-317644/+merge/6978 | Resubmit: 1
<hal_> https://launchpad.net/~lovesyao/bzr/windows-utf8/+merge/1806 | Abstain: 1, Needs Fixing: 1
<verterok> a new name for the bot is welcome :)
<lifeless> verterok: cool, thanks
<verterok> lifeless: np :)
<fullermd> Yeah, considering HAL's behavior, I don't think we'd want him taking charge of reviews   :p
<lifeless> the user name review isn't taken
<lifeless> or, at least, not obviously
<verterok> fullermd: heh
<poolie> verterok: nice one
<poolie> verterok: maybe it could use irc color codes for the status?
<verterok> poolie: :)
<bob2> ansi blink sequence for critical unreviewed bugs
<verterok> poolie: sure!, but I know nothing about irc colors. if someone paste the strings, I'll use that :)
<poolie> lifeless:  when you said i changed assertRaises i assume you mean assertIsInstance
<poolie> i'll check its tests
<poolie> verterok: hello?
<poolie> woo
<poolie> bold
<poolie> http://www.ircbeginner.com/ircinfo/colors.html
<poolie> so it's just the ascii for ctrl-k, b, u, r, etc
<verterok> poolie: hi
<verterok> ack
<verterok> :)
<poolie> chaos reigns
<lifeless> poolie: yes
 * fullermd wonders if lifeless is confirming asserts or chaos...
<mwhudson> luckily my client doesn't support colour
<lifeless> poolie: meep no colours!
<mwhudson> (or said support is turned off)
<mwhudson> poolie: hi CTCP!
<poolie> you must have it off or something
<lifeless> it could well be filtered in the channel
<lifeless> I get lovely plain text
<bob2> channel is +c
<bob2> "This cmode activates the colour filter for the channel. "
<poolie> ah, i see them going out, of course
<poolie> i guess it's require dealing with either abuse or freenode egotrips
<poolie> :/
<ndurner> Hi poolie!
<ndurner> I have made the changes you suggested to my tree and replied to the merge proposal.
<poolie> yes i saw
<poolie> i'll try to re-read it but it sounds like it's all good now
<ndurner> okay :-)
<poolie> ndurner: oh i thought of one other thing - can you print the error to the user, rather than just to the log, if it makes sense
<poolie> lifeless: oh i think it might make that list more readable
<ndurner> sure
<lifeless> poolie: No comment ;). It might be nice to sort it though
<poolie> or maybe align the votes to the front
<poolie> that might be easier than coloring
<lifeless> poolie: colour doesn't mean much to me, until its painful, which is why I rarely reach for it as a tool
<spiv> It's a shame that there's no short identifier like a single number that list can use.
<poolie> heh
<poolie> we just had that conversation with jml :)
<spiv> The #twisted equivalent just lists trac ticket numbers, like "#aaa (spiv), #bbb, #ccc (fred), ...", all on one line.
<spiv> Ah, ok.
<poolie> he didn't want to emphasize the mp numbers
<jml> hahaha
<poolie> and he has a point,
<poolie> but the desire for a short id remains
<lifeless> was it voice?
<spiv> Yeah, meaningless numbers do suck.
<poolie> maybe they should be abbreviated by the bug number
<jml> spiv, there's a bug that you can wage in on
<spiv> But short ids are still nice :)
<poolie> having (slightly) overlapping integer sequences is unoptimal
<lifeless> you could hash them all
<jml> lifeless, only a little, everything interesting is on the bug reports.
<spiv> With the current LP model, the lp:~spiv/bzr/foo branch name is actually a possible key.
<jml> spiv, it's an almost-key
<bob2> etoolong
<lifeless> spiv: its not unique though
<spiv> Yeah, but there can only be one active proposal per branch AIUI?
<jml> spiv, this is one of the rare times where I disagree with mpt on what the ideal UI should be.
<spiv> And this list is all about active proposals, after all.
<lifeless> spiv: not AIUI
<spiv> jml: :)
<poolie> i think the user model for the meaning of an mp is unclear
<jml> spiv, but if I'm disagreeing with you, poolie & mpt then maybe I'm wrong
<poolie> like if you update and come back, do you create a new one?
<poolie> current practice says yes but it's not actually needed
<lifeless> spiv: what does mpt want?
<poolie> of course getting the experience with it is useful
<lifeless> sorry
<lifeless> jml: what does mpt want?
 * jml pulls up the bug report
<poolie> ndurner: if you just change that i'll approve it
<poolie> a test would be nice...
<poolie> if you ask vila he might write one
<jml> lifeless, mpt wants the canonical, final URL of a merge proposal to be something like https://code.launchpad.net/merge/5520
<jml> https://bugs.edge.launchpad.net/launchpad-code/+bug/400215
<ubottu> Ubuntu bug 400215 in launchpad-code "Merge proposal URLs are ugly and needlessly long" [Undecided,Incomplete]
<lifeless> jml: I'd like to have that as an alias
<lifeless> jml: further, I'd like to be able to merge from it
<lifeless> I don't care if the current merge proposal urls stay or go
<poolie> jml, i'd kind of rather have bugs.launchpad.net/400215/+proposal
<poolie> for the common case that there's one per bug
<poolie> this is just a random thought not a proposal
<lifeless> poolie: I suggest that that would be good as an alias, rather than a primary
<jml> lifeless, yes. poolie filed a bug about that first one, which is linked from that page.
<jml> lifeless, followed up with a bug about making the merge id prominent in the page & <title>
<jml> lifeless, and I think there's probably already a bug about being able to merge from the merge proposal url.
<jml> hmm.
<jml> I'd like to go into how I would redesign the merge proposal system
<lifeless> if you use a branch reference at the mp url
<poolie> i think you have a good point about a risk of premature grasping in saying "ooh a number let's use it"
<jml> but I won't, because I want to fix this easy & vitally important bug.
<lifeless> bzr will make merge Just Work
<poolie> yeah way to go :)
<poolie> lifeless: that works now, or it used to
<lifeless> poolie: it doesn't dtrt
<poolie> bzr walks up til it finds the branch page and that points to the right place
<lifeless> poolie: because it does a partial merge
<jml> lifeless, yeah, I seem to recall that implementation approach mentioned on the bug report too.
<poolie> oh, of a file that doesn't exist?
<lifeless> poolie: its /close/ but not correct
<poolie> yeah that would suck
<ndurner> poolie: it's in r4543.
<ndurner> (just committed)
<poolie> biab, going out for air before it rains.
<poolie> i hope
<thumper> Can someone please take a look at https://launchpad.net/~abentley/bzr/devnotes/+merge/8766 | No reviews ?
<thumper> I got Aaron to make sure he wasn't blocking this
<thumper> now it is blocked on you guys
 * ndurner hurries to work
<GaryvdM> Morning
<igc> hi garyvdm
<igc> thumper: I'm planning to review it this week
<igc> bbiab
<lifeless> EOD
<lifeless> iter_changes is making good progress
<nil1> back (ndurner)
<lifeless> jml: ping, subunit, review & design
<jml> lifeless, I'm pretty busy this evening, I'm sorry.
<lifeless> jml: thats ok
<lifeless> jml: when you can though :)
<jml> lifeless, will let you know.
<jml> lifeless, I've got a talk I need to prepare for tomorrow.
<lifeless> whats tomorrow?
<lifeless> oh fpsyd?
<lifeless> good luck with it
<jml> fp-syd
<jml> lifeless, they were short of speakers, and I said I had a lightning talk already prepared that I could probably pad out
<jml> thanks.
<jml> I'm hoping by the end of it, I'll understand monads better :)
<lifeless> jml: I'd come along and heckle^Wlisten attentively, but sadly I have a standing booking thursdays
<jml> lifeless, oh well.
 * igc dinner - night all
<jelmer> luks: hi
<luks> hey
<jelmer> luks: Did you still have that svn merge directive code around somewhere?
<jelmer> I was looking into writing something similar for bzr-git and I guess it would be a good starting point
<luks> jelmer: https://code.launchpad.net/~luks/bzr-svn/send
<jelmer> luks: awesome, thanks!
<luks> jelmer: but right now it does only what's necessary to fool review board
<luks> I'd like to implement full svn-like diff later
<jelmer> luks: ok
<lifeless> jelmer: hai
<jelmer> lifeless: g'day
<lifeless> jelmer: can I beg a subunit review off you?
<jelmer> lifeless: which bit in particular?
<jelmer> oh, the time stuff?
<lifeless> yes
<lifeless> thats the first half of it
<lifeless> second half is about to get committed and pushed
<lifeless> you could review that too if you're feeling up to it ;)
<jelmer> lifeless: we seem to be including two copies of iso8601.py ?
<lifeless> jelmer: ?! let me look
<jelmer> lifeless: oh no
<jelmer> lifeless: false alarm
<jelmer> lifeless: Sorry :-(
<lifeless> jelmer: I wanted to keep the upstream stuff around
<lifeless> I'm pushing the generation of timestamps stuff now
<lifeless> done
<lifeless> this should allow some pretty easy analysis of test performance
<lifeless> I'll resubmit the branch as you're here :)
<lifeless> https://code.edge.launchpad.net/~lifeless/subunit/time-support/+merge/9136 is the new review
<jelmer> lifeless: thanks
<jelmer> Kinnison: are you still around here somewhere?
<flutherben> Question: I'm using a pretty large, and pretty old bzr repository (maybe 3 years). I've just upgraded to 1.17, but it's still really slow. Should I do a "bzr upgrade" on my repo? Will it be stable?
<LarstiQ> flutherben: what does `bzr info` on that repo say?
<flutherben> Shared repository with trees (format: rich-root-pack)
<Kinnison> jelmer: aye, hacklab 1
<Kinnison> jelmer: I'm currently trying to document some IEEE 802.15.4 stuff, so feel free to interrupt
<LarstiQ> flutherben: you might gain from an uprgade then. What are you experiencing slowness with?
<flutherben> checkins, updates, merges
<flutherben> it seems even slower after the update
<flutherben> I had to download something with Hg a day ago, and it was 10-100x the speed. Made me think something is wrong with my repo
<flutherben> You think I'll see gains in speed? Is there any risk of instability?
<LarstiQ> flutherben: instability in what sense?
<flutherben> Well, I just mean all the same bzr functionality is well supported, and I shouldn't be worried about corruption or anything. As in, ready for a production environment
<LarstiQ> flutherben: of course
<flutherben> excellent
<LarstiQ> flutherben: 2a still might hit some codepaths that aren't as optimized as possible, but it works
<jelmer> Kinnison: heading over..
<LarstiQ> flutherben: if you don't want to go with 2a just yet, you can use the 1.14 format
<flutherben> What's the difference?
<DaffyDuck_> I have a shared repository which has the permissions rwxrws---. In there I created a directory dev (with the same persmissions) and ran "bzr init" inside it. The subdirectories and files appear to have the correct permissions. But when I branch it "bzr branch dev stable", the stable directory gets rwxr-xr-x. (run as root). Do I need to fiddle around with umask to get the proper permissions on new branches in the repository?
<LarstiQ> DaffyDuck_: I'd recommend posix acls
<LarstiQ> flutherben: 1.14 has been around longer, 2a is much much better
<flutherben> 2a sounds better then :)
<flutherben> 2a is --rich-root-development?
<LarstiQ> flutherben: Launchpad is in 2a, and bzr development will switch soon
<LarstiQ> flutherben: no, --2a
<flutherben> ah
<LarstiQ> flutherben: so the consequence here is that if you use older clients, pre 1.16 iirc, they won't be able to read 2a
<flutherben> yeah, I'm basically just using 1.16/1.17 from console
<LarstiQ> flutherben: sounds fine then
<DaffyDuck_> LarstiQ: Assuming I don't have access to posix acls...
<flutherben> ok, anything I need to know about backing up and upgrading?
<flutherben> I can just make a copy of my whole repository before I upgrade?
<LarstiQ> flutherben: just running `bzr upgrade` should be enough, it will make a backup of .bzr
<flutherben> sweet
<LarstiQ> flutherben: but security comes in layers, so make an extra backup if that makes you feel safer
<flutherben> yeah, I probably will
<flutherben> thanks a lot LarstiQ
<LarstiQ> flutherben: np. I'd like to hear what that does for your speed experience.
<flutherben> Yeah, I'll check back in and let you know
<LarstiQ> flutherben: do you only work local, or also interact with remote branches?
<LarstiQ> flutherben: because bzr+ssh is again faster than sftp/http
<flutherben> lots of remote branches, using bzr+ssh
<flutherben> still has been strangely slow
<LarstiQ> flutherben: ok, would like to have a look at that later then if that's ok
 * LarstiQ first goes for some grocery shopping etc, bbl
<flutherben> yeah, sounds great
<flutherben> thx
<DaffyDuck_> Here's a log illustrating the permissions problem I'm running into: http://pastebin.com/d673e2777
<DaffyDuck_> Is there a solution which does not require running chmod each time a branch is created?
<DaffyDuck_> Also, I'm afraid the same problems will arise when a testdev does a "bzr push" for the affected files.
<bob2> setgid the dirs?
<DaffyDuck_> bob2: Isn't that what the s denotes in rwxrws--- ?
<bob2> ah, I'm blind
<DaffyDuck_> The s-attribute appear to work for "bzr init", but not "bzr branch".
<Keybuk> so what's this "2a" format all about?
<LarstiQ> Keybuk: split inventories and group compression
<Keybuk> LarstiQ: should I use it?
<LarstiQ> Keybuk: if you're happy now I think I'd hold off a little while longer
<LarstiQ> Keybuk: Bazaar is about to switch it's own development branches over
<LarstiQ> Keybuk: since it's only in 1.16 and 1.17, there are plenty older clients out there that can't read it
<vxnick> are there any docs about the 2a format yet?
<Keybuk> LarstiQ: when will Launchpad support the new format?
<LarstiQ> Keybuk: launchpad the project itself is in 2a, hosted on launchpad, so that should be right now
<Keybuk> but I can't upgrade my branch
<Keybuk> something to do with stacked branches?
<LarstiQ> Keybuk: yeah, stacked branches need to be upgraded first afaik
<LarstiQ> Keybuk: so that's why I'd recommend waiting for a bit longer, https://bugs.edge.launchpad.net/bzr/+bug/390502
<Keybuk> but other people have stacked branches on top of mine
<LarstiQ> Keybuk: unless you're willing to act as a testbed
<Keybuk> I'm always willing to help test :-)
<LarstiQ> Keybuk: the approach outlined in that bug should be updated with the 'stacked branches first', I'll do that when I get back in a bit
<Keybuk> is there not a way without requiring somebody to upgrade their branch first?
<Keybuk> seems a bit broken
<LarstiQ> doing the upgrade dance ourselves will result in documentation for others
<LarstiQ> Keybuk: has to do with no cross-format stacking iirc
<LarstiQ> certainly not ideal
<Keybuk> what if someone created a branch, and then hasn't been contactable since?
<LarstiQ> Keybuk: LOSA intervention for now I think
<Keybuk> what's the eventual plan for that?
<LarstiQ> Keybuk: finding out how to handle things is part of bug 390502
 * LarstiQ honestly doesn't know yet
<ubottu> Launchpad bug 390502 in bzr "bzr's development should dogfood format 2a" [High,Confirmed] https://launchpad.net/bugs/390502
<poelzi> hi
<poelzi> i have a problem bzr branch lp:pybindgen; cd pybindgen; bzr st
<|malibu|> Do I need to be using the bazaar server to execute a post_commit plugin?
<jelmer> hi poelzi
<poelzi> it causes a hard lockdown on the bzr process
<poelzi> not even kill -9 helps
<jelmer> poelzi: I can't reproduce it here, can you do this reproducibly?
<|malibu|> I'm using bzr+ssh and my post_commit isn't getting fired.  It's just a simple os.system("<shell script>")
<poelzi> on ubuntu jaunty Bazaar (bzr) 1.13.1 it does
<poelzi> not only here
<poelzi> how can i enable the trace file ?
<jelmer> poelzi: bzr should be writing more information by default to ~/.bzr.log
<jelmer> poelzi: alternatively the output of strace might help to see what's going on exactly
<poelzi> nothing in the locks yet
<poelzi> i have a idea
<LarstiQ> |malibu|: where have you configured the post_commit?
<|malibu|> ~/.bazaar/plugins
<|malibu|> It's getting compiled, just not getting fired
<LarstiQ> |malibu|: so post_commit needs to be enabled for a branch
<|malibu|> enabled?
<LarstiQ> |malibu|: you can configure this in ~/.bazaar/locations.conf or .bzr/branch/branch.conf
<LarstiQ> also, if you're using a smart server, you need to configure it on the server, not locally
<poelzi> ok. that was it not. could it be that its a lock deadlock somehow ?
<|malibu|> I'm not using a server.. just bzr+ssh
<|malibu|> I will look up branch.conf.  Thanks
<LarstiQ> |malibu|: you are using the smartserver with bzr+ssh
<|malibu|> ah
<quicksilver> does the launchpad code have a repo browser for bzr repos? Or do they use loggerhead?
<jelmer> quicksilver: they use loggerhead
<quicksilver> jelmer: thanks.
<jelmer> luks: I've pushed some improvements to your branch to lp:~bzr-svn/bzr-svn/send
<jelmer> luks: in particular, using the 'svn' send format by default when submitting to a svn branch
<james_w> ooh
<james_w> what's the 'svn' send format?
<homy> Can I just rename or move a file to another subdirectory normally?
<jelmer> james_w: basically the format that "svn diff" would generate (including svn revision numbers) as part of 'bzr send'
<james_w> cool
<jelmer> james_w: it should make cooperation with upstreams that are using svn easier, as they wouldn't be interested in bzr bundles with bzr metadata
<LarstiQ> homy: `bzr mv file subdir/` sure
<LarstiQ> jelmer: will that roundtrip?
<LarstiQ> I'm guessing no, and that can be fine
<jelmer> james_w: the idea is also to support something similar for 'git am' style patches, but for that 'bzr send' needs to support multiple attachments first
<jelmer> LarstiQ: no, it won't roundtrip (unless there's some way to create svn revision properties from a svn diff that I'm not aware of)
<james_w> maybe we could look at that next week
<luks> LarstiQ: I don't think svn has any builtin tool to apply some patches
<luks> LarstiQ: this is mainly interesting for projects like Review Board
<LarstiQ> luks: I saw you coded towards that, how does it work?
<homy> LarstiQ: I meant can I just move the file normally without bazaar or do I need to use bzr mv?
<james_w> homy: you need to tell bzr about it at some point
<james_w> you can use bzr mv --after to do it after you move
<luks> LarstiQ: well, when working with svn-configured review board, it expects you to submit 'svn diff' patches. it parses the patch and looks up the revisions in the repository
<james_w> or bzr mv --auto to have it guess
<LarstiQ> homy: what james_w said, or try `bzr mv --auto`
<luks> and this allows me to generate such patches from bzr
<homy> ok. thanks.
<LarstiQ> luks: hoo boy
<LarstiQ> luks: and then you get a green light and can commit it?
<luks> yes
<pfctdayelise> hi, if I'm using bzr for a web app (Python), is there a way I can get the current bzr revision and insert/display it in my web app?
<LarstiQ> luks: at which point it may no longer apply?
<jelmer> flutherben: from bzrlib.branch import Branch; b = Branch.open(path_to_branch); print b.revno()
<luks> LarstiQ: what no longer applies?
<LarstiQ> luks: the patch
<luks> oh, well, yes
<james_w> pfctdayelise: have a look at "bzr version-info"
<LarstiQ> luks: or alternatively, `svn update` might give conflicts
<james_w> pfctdayelise: or something like jelmer suggests if you are in python
<luks> LarstiQ: but you have the same problem with bzr
<LarstiQ> luks: I'm sure it is an improvement in workflow
<luks> LarstiQ: you review a patch, commit something upstream and the patch might no longer cleanly merge
<LarstiQ> luks: ish, it is much easier to work with different branches
<LarstiQ> luks: right
<pfctdayelise> jelmer, james_w : thanks
<jelmer> fl	sorry, no, for pfctdayelise
<jelmer> lar	ah, awesome
<hno> Hmm.. any suggestions on how to recover an old dev repository? bzr 1.16.1 says bzr: ERROR: Unknown repository format: 'Bazaar development format 2 (needs bzr.dev from before 1.8)\n'.
<hno> I guess I need to downgrade to 1.7 or so, but what should I do next?
 * LarstiQ blinks
<LarstiQ> hno: that's new to me
<LarstiQ> hno: is there a public copy of the branch?
<hno> Not at the moment, and it's rather big to move around... (ca 500MB)
<LarstiQ> right
<LarstiQ> hno: speculating, if you have 1.7, I'd upgrade the branch to a newer format 1.7 can upgrade to and 1.16.1 can read from
<LarstiQ> hno: I suppose that would be 0.92
<LarstiQ> hno: but I'm not sure what the dev format 2 _is_, so perhaps we'll run into some upgrade path issues
<hno> Not sure either. But the branch isn't using any excotic features of bzr. I think it was "upgraded" to the dev format at the time for performance reasons only.
<hno> Hmm.. now I am truly confused. Exact same error with bzr 1.7.
<hno> .bzr/branch/format says "Bazaar Branch Format 7 (needs bzr 1.6)". .bzr/repository/format says "Bazaar development format 2 (needs bzr.dev from before 1.8)"
<LarstiQ> hno: oh hmm, 'bzr.dev' from before 1.8
<LarstiQ> hno: did you use a released bzr or bzr.dev to do the upgrade with?
<LarstiQ> hno: it might mean the branch is in a format that never got released
<cgratecos> hi there, does someone know if there's some french translators to the bazaar project ?
<hno> Released bzr I think.
<LarstiQ> hno: is the bzr.dev string literally in .bzr/repository/format ?
<hno> Those strings are the literal contents of the files.
<LarstiQ> cgratecos: there are French speaker developers, translation wise I think bzr-explorer sees the most action
<LarstiQ> cgratecos: though the documentation of bzr might be translated to French as well, there is a Russian translation at least
<LarstiQ> hno: ok
<LarstiQ> hno: in that case I think it is a reasonable bet to try a bzr.dev version then
<LarstiQ> hno: let me look up which revision
<jelmer> I think there also was work happening on a spanish translation
<LarstiQ> hno: r4265 disabled development2 at least
<hno> Checking the versions I have packaged... may have been 1.6.1rc2.
<hno> Argh.. need newer bzr to access launchpad... :)
<lifeless> hno: bzr dump-btree .bzr/repository/pack-names
<lifeless> hno: if that works, its really a 1.9 format and you can just edit the format string to match
<lifeless> if it fails, its a 1.6 format, and <ditto>
<hno> $ bzr dump-btree .bzr/repository/pack-names
<hno> (('29e78c8e7bb53e72a3dc28d4e341774f',), '317 350 3007752 72')
<hno> do that make sense?
<lifeless> yes
<lifeless> its a btree using format
<cgratecos> if you want some help for french translation !! (i didn't found any mailing list for translating !!)
<lifeless> do this:
<lifeless> bzr init-repo /tmp/foo --1.9
<lifeless> cp /tmp/foo/.bzr/repository/format .bzr/repository/format
<hno> Thanks!
<lifeless> np
<lifeless> good night
<lifeless> jelmer: if you could do that review... ;)
<LarstiQ> cgratecos: which part are you interested in translating?
<jelmer> lifeless: Sorry, got distracted
<jelmer> lifeless: I'm planning to do it later today though
<lifeless> thanks
<LarstiQ> jelmer: thanks for the 1.17 upload!
<jelmer> what was the ftp-like tool based on bzr transports again?
<LarstiQ> jelmer: lp:hitchhiker
<jelmer> LarstiQ: thanks
<cgratecos> LartiQ: i'm interested by making french people use bzr caus i like it !! and i didn't found any french translation on your site !! so tell me what to translate i'll do it !!
<LarstiQ> cgratecos: if you have a copy of bzr.dev, have a look at the doc/ directory
<LarstiQ> cgratecos: specifically doc/en for english, doc/es for spanish and doc/ru for Russian
<LarstiQ> cgratecos: you could start a doc/fr
<cgratecos> LartiQ: let's go !!
<cgratecos> LarstiQ: it's look easy to do !! is there someone allready working on french translation ? we could share the work and i hate to make something that have allready been made !!
<LarstiQ> cgratecos: I'm not aware of that, but you could search the list archives
<LarstiQ> cgratecos: 'google site:lists.canonical.com bazaar french' I guess
<LarstiQ> cgratecos: however, you could try getting in touch with the translators for bzr-explorer
<LarstiQ> cgratecos: https://translations.edge.launchpad.net/bzr-explorer
<sender> cgratecos: what's your question?
<cgratecos> sender: i want to translate the bazaar site and the documentation in french !
<cgratecos> LarstiQ: thanks
<LarstiQ> cgratecos: ah, for the site I recall there might be prior work
<sender> cgratecos: great! I almost finished the dutch translation for bzr-explorer last night, it's quite easy to do
<sender> cgratecos: create a login on launchpad and set your 'prefered language' to include french
 * LarstiQ quickly jumps on the Dutch bandwagon
<sender> cgratecos: now you can edit the translation here: https://translations.launchpad.net/bzr-explorer/trunk/+pots/explorer
<sender> LarstiQ: :)
<Kinnison> jelmer: Is it a known side-effect that translating from pack-0.92 to 2a will add a file-id ? (is that the 'rich root' ?)
<LarstiQ> Kinnison: 2a is a rich-root format (finally!), so that sounds plausible
<cgratecos> sender: i create my login and i'll do the work (there's allready a lot of work done !!)
<Kinnison> LarstiQ: cool
<sender> cgratecos: yes, still 88 untranslated to go.. those are the hard ones probably, good luck ;)
 * Kinnison is playing with his branches to check they all translate
<Kinnison> the one with umpteen arch branches merged into one, plus several other branches merged with the 0..-1 trick seems to play ball nicely
<sender> LarstiQ: did you do some dutch translations on lp?
<LarstiQ> sender: not yet
<sender> LarstiQ: ah ok thought I'd used some translation suggestions from a certain Lars ;) What's your opinion on keywords like branch, commit, update, merge, etc.. translate to NL or not?
<LarstiQ> sender: I'm very very biased on that topic. My opinion is to not translate them, but then, everything I use is in English so I'm not the exact target demographic.
<cgratecos> sender: i'm working on the french translation on launchpad, my nickname is gtechnix, i'll go back home in 10 minutes but  on it tonight
<cgratecos> oups
<cgratecos> i'll work on it tonight
<sender> cgratecos: great, take your time ;) thanx!
<hmeland_> sender: For documentation I'd think it could make sense to differentiate between the command and the concept (but I speak NO rather than NL, and I'm also happy using everything in English).
<sender> LarstiQ: same here... i never like changed shortcuts b/c of localization and especially the Dutch functionnames in excel :/
<sender> hmeland_: I think we agree.. in documentation the concept should be explained using the native language (just like help and statusbar text in the app) and the keyword itself can better stay in english for sake of unanimity
<LarstiQ> sender: translating the API was a really stupid decision for Excel
<sender> LarstiQ: I never saw it in any other app/language.. hope that that flaw never occured somewhere outside MS hq ;)
<Kinnison> jelmer: when you file those bugs, please let me know so I can subscribe to them
<jelmer> Kinnison: will do
<mickstephenson> Hi, can someone help, I'm trying to checkout some code from launchpad and I'm getting this error "Permission denied (publickey)." It's only occurred since i entered my launchpad login to bzr
<Kinnison> Is your SSH key registered with launchpad and do you have the key present?
<mickstephenson> I think the key I have on bzr is from another computer, I thought this would only be important when committing code? this is basically just an anonymous checkout.
<Kinnison> Not GPG key, SSH key
<Kinnison> once you give bzr your LP login, it will try to use bzr+ssh instead of http to fetch content
<mickstephenson> oh ok, i'll upload my key anyway, thanks
<Kinnison> No problem
<Kinnison> You'll want your key on launchpad if you want to push branches to it anyway
<Kinnison> so it's a handy thing to do
<garyvdm> mickstephenson: You can still download using http with out a ssh key
<garyvdm> It will be slower though
<mickstephenson> I think I will need to, it must take some time after pasting the key inot launchpad that it propagates to bzr
<mozmck_work> Hi, If I have deleted versioned files from my working directory, what do I need to do to tell bzr they are gone?
<Kinnison> it will notice, type 'bzr status' and check
<mozmck_work> ah, so a commit will do it all?
<Kinnison> it does for me. But I make no guarantees :-)
<mozmck_work> good!
<igc> night all
<wadesworld> hi guys, looking for some help importing a CVS repository....I have the actual repository (not a checkout)  - I *think* I can use bzr cvsps-import....correct?
<LarstiQ> wadesworld: I think so, though no experience with it
<awmcclain> Well, hrmph. Updating my local repository is failing miserably
<awmcclain> starting repository conversion
<awmcclain> Python(2806) malloc: *** mmap(size=20480) failed (error code=12)ring revisions:
<awmcclain> *** error: can't allocate region
<awmcclain> *** set a breakpoint in malloc_error_break to debug
<awmcclain> bzr: ERROR: Must end write group before releasing write lock on CHKInventoryRepository('file:///Users/andrew/clownfish/panda-repo/.bzr/repository/')
<LarstiQ> awmcclain: woo
<LarstiQ> awmcclain: what command is that?
<LarstiQ> awmcclain: just `bzr upgrade`?
<awmcclain> --1a
<awmcclain> eep
<awmcclain> sorry
<awmcclain> bzr upgrade --2a
<LarstiQ> right
<LarstiQ> awmcclain: with bzr 1.17?
<awmcclain> correct
<agrippa> heyas
<agrippa> Trying to get a diff tool that will work with bzr on OS X.  Any suggestions?
<awmcclain> agrippa: opendiff?
<awmcclain> soo...any suggestions about how to upgrade my repo?
<wadesworld> agrippa, I think I got it set up to use FileMerge at one point
<wadesworld> but it was a long time ago, and I don't remember the specifics
<awmcclain> wadesworld: Yeah, i think if you install filemerge and then alias opendiff to it... or you may not even need to
<awmcclain> if i run bzr diff --using=opendiff it opens filemerge
<agrippa> It just seems to send it to stdout for me if I do that
<agrippa> But I did find the FileMerge utility, so that's good.  I don't need to go and purchase Changes now.
<awmcclain> what does man opendiff give you?
<agrippa> It describes opendiff as "a command line utility that provides a convenient way to launch the FileMerge application from Terminal..."
<agrippa> OK, nice, it does launch FileMerge when I use it, just doesn't seem to want to play nice with bzr
<awmcclain> bzr diff --using=opendiff doesn't work?
<agrippa> Yeah, just exits immediately
<agrippa> When I do something like "bzr -r1..10 --using=opendiff" it just sends the diff to the terminal instead of opening FileMerge
<agrippa> erm, bzr diff -r1..10 --using=opendiff rather
<awmcclain> hrm
<awmcclain> *shrug*
<agrippa> Oh, maybe I need the difftools plugin installed
<agrippa> Going to try that
<agrippa> OK, that worked.
<malibu> Hello folks.
<malibu> A question about 'hooks'
<malibu> I cannot find any documentation on enabling them for the smartserver
<malibu> Where can I find something like that?
 * LarstiQ pipes back up
<LarstiQ> malibu: can you describe exactly how you configured the hook, and how you are accessing it?
<LarstiQ> malibu: for me, if I use bzr+ssh://source/srv/bzr/foo/bar, I use [/srv/bzr] in source:~user/.bazaar/locations.conf for a pattern
<malibu> I put a commit_plugin.py into ~/.bazaar/plugins
<LarstiQ> malibu: or in earlier versions, that might be chroot-*:///srv/bzr/
<LarstiQ> malibu: right, remotehost:~/.bazaar/plugins ?
<malibu> It uses the install_named_hook method to register a function
<malibu> yes, on the repository host
<malibu> basically the function just attempts to call a shell script
<malibu> using import os, os.system("script")
<malibu> The hook compiles fine,
<malibu> it shows up in bzr hooks
<malibu> ..but it does not fire
<malibu> I need it in ~/.bazaar/locations.conf you say?
<LarstiQ> malibu: right
<LarstiQ> malibu: well, normally you'd have to configure a hook to be run for a branch. If you don't, it won't fire.
<LarstiQ> but then again, if you have written your own plugin, you could be doing things differently
<LarstiQ> malibu: can you share your plugin?
<malibu> sure
<malibu> is there a bzr pastebin?
<LarstiQ> malibu: any pastebin will do if it is just one file
<malibu> http://pastebin.org/3597
<malibu> I just took the sample from the docs and modified it a bit
<malibu> thx
<LarstiQ> not too complicated :)
 * LarstiQ tries it
<malibu> lol, sure you can handle it
<LarstiQ> malibu: what version of bzr are you using?
<GaryvdM> malibu: post_commit will never be fired on the server. You should rather hook onto tip_change
<GaryvdM> I think it is tip_change, but I'm not sure - so look for something like that.
<malibu> tip_change?  what does that mean?
<LarstiQ> oh shoot, I forgot about that
<malibu> 1.13.1
<LarstiQ> malibu: the tip of a branch is the most recent revision
<GaryvdM> malibu: It's called when the latest revision (tip) of a branch
<malibu> ah
<GaryvdM> changes
<GaryvdM> So post_commit will only get called if you do bzr commit
<GaryvdM> but tip_change will get called if you commit, push, pull etc...
<LarstiQ> GaryvdM: which with a checkout could happen against bzr+ssh, but yes
<malibu> But it gets called on the client side
<LarstiQ> malibu: your post_commit hook gets called clientside? Yes, that underlines what GaryvdM said and I forgot about
<malibu> Well I don't know if it is getting called client side, there is no shell script client side
<malibu> But I was trying to understand what GaryvdM was saying by reiterating
<malibu> trying it now
<GaryvdM> malibu: The correct name of the hook is "post_tip_change"
<malibu> ahhh.. shoot
<malibu> thnaks
<malibu> was just going to bitch about it still not working!
<malibu> but you are gone now o it don't matter!
<malibu> ah there you are
<siliu> Does anyone know why I can not use bze qlog?
<LarstiQ> siliu: not without more information :P
<GaryvdM> malibu: What did you say when I was gone?
<malibu> just thanks, and that I was just coming in to bitch that it still wasn't working
<malibu> but I used tip_change
<GaryvdM> siliu: What does it say when you try run bzr qlog?
<malibu> shoot, still didn't work
<GaryvdM> malibu: I just figured out - you can get the documentation on hooks by running bzr help hooks
<GaryvdM> Sorry - post_change_branch_tip
<LarstiQ> malibu: which hooks documentation were you reading earlier?
<siliu> GaryvdM,  I got the message bzr: ERROR: unknown command "qlog"
<LarstiQ> ok, so I was confused by the bzr-email plugin also installing a post_change_branch_tip hook
<GaryvdM> siliu: qlog is apart of the qbzr plugin. This is probably not installed.
<LarstiQ> siliu: do you have qbzr installed?
<LarstiQ> siliu: it should be in `bzr plugins` output
<GaryvdM> siliu: Windows or other os?
<malibu> I fond 'how to make a plugin' on the wiki
<malibu> Also I was reading the Bazaar manual
<malibu> but there wasn't very much detail
<siliu> fedora 10
<malibu> GaryvdM no prob, will try that
<GaryvdM> siliu: I don't thing that there are any rpm for qbzr, so you are going to have to install it manualy.
<LarstiQ> malibu: if you can point me to the exact locations I'll see about changing them to point at `bzr help hooks`
<GaryvdM> siliu: I lie. There do seem to be rmps - see http://rpm.pbone.net/index.php3/stat/4/idpl/12544874/com/qbzr-0.11-1mdv2010.0.noarch.rpm.html
<GaryvdM> Thats for 0.11 - Latest release is 0.12
<malibu> LastiQ: hard for me to do it now, slow vnc connection.  Will look for you later
<LarstiQ> malibu: ok
<LarstiQ> malibu: http://bazaar-vcs.org/WritingPlugins is a bit old
 * LarstiQ updates
<siliu_openmedian> thanks GaryvdM  I will try that
* garyvdm changed the topic of #bzr to: Launchpad's now open source! | Bazaar version control system | 1.17 released 20th July, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<garyvdm> twas released yesterday...
<LarstiQ> point, point :)
<malibu> holy cow!  My post_change_branch_tip hook worked!
<LarstiQ> woo!
<malibu> Of course, I'm not sure why creating one empty text file caused it to do a 'writing local files' of 10Gb.....
<LarstiQ> malibu: heuh?
<jfroy> Has the 2a migration document been published?
<jfroy> Specifically the steps to migrate branches on Launchpad to 2a without hosing everything because of stacking.
<LarstiQ> jfroy: working on it, https://bugs.edge.launchpad.net/bzr/+bug/390502
<ubottu> Ubuntu bug 390502 in bzr "bzr's development should dogfood format 2a" [High,Confirmed]
<jfroy> That seems specific to bzr?
<jfroy> I vaguely recall a 2a migration document was being prepared, I'm just not sure where the draft is.
<LarstiQ> jfroy: doc/en/upgrade-guide/ ?
<jfroy> mm
<jfroy> I see
<jfroy> it's not in the 1.17 distro.
<LarstiQ> nor in the 1.17 branch
<LarstiQ> jfroy: yeah the bug is about dogfooding, you can upgrade now (with the bzr.dev document) or you could wait a bit for bzr.dev to go through the process
<jfroy> I see
<jfroy> the process is mostly to sidestep the entire issue
<jfroy> by keeping the old format trunk around (and thus not breaking any stacked branch)
<jfroy> And blessing a new 2a format branch as the development focus moving forward
<LarstiQ> right
<LarstiQ> I'm not sure I'm entirely happy with that arrangement
<jfroy> neither am I
<jfroy> seems messy
<LarstiQ> having people's stacked brances upgraded to 2a automatically is less ideal though :/
<jfroy> :/
<jfroy> is there going to be a conflict on the name of the branch, I wonder
<jfroy> not that it matters much in so far as the development focus branch is aliased when using lp:
<SamB> stacked branches will break?
<jfroy> they won't, not if you keep the old development focus around
<SamB> I mean, would
<SamB> if you upgraded what they were stacked on to 2a in-place?
<jfroy> one worry is that because bzr has no way to mark a branch as closed, people could still be operating on the old trunk...
<SamB> why?
<jfroy> might because a nightmare where you have 2 development focus diverging
<SamB> jfroy: I has a way
<SamB> chmod -w
<jfroy> how do you do that on Launchpad hosted branches, exactly :p
<SamB> you get a sysadmin-priviliged person to do it
<jfroy> fair enough
<SamB> well, that only helps for bzr.dev
<SamB> but you could presumably automate that
<SamB> thereby adding such a way to launchpad ;-)
<jfroy> feels like a hack-ishy way though
<SamB> what worries *me* is how do you get people to stop pulling from that branch?
<jfroy> may be nicer to have a formal way to close a branch, perhaps providing a "use this one instead" message of sort.
<SamB> an MOTD mechanism might not be unwelcome
<jfroy> which bzr could display on push, pull and branch
<jfroy> *files a bug*
<SamB> darcs has such a thing for pulls/branches, at least
<jfroy> so does hg
<SamB> dunno about git
<SamB> ... why the heck is bzr in the "devel" section?
<SamB> shouldn't it be in "vcs" instead?
<jfroy> https://bugs.edge.launchpad.net/bzr/+bug/403203
<ubottu> Ubuntu bug 403203 in bzr "A a "close branch" command with optional message" [Undecided,New]
<jfroy> lol double As
<jfroy> fixed >.> (eternal thanks for inline editing on Launchpad)
<SamB> jfroy: a mutable "message of the day" would be sufficient
<jfroy> not strong enough IMO
<jfroy> It would be preferable for bzr to error out of commands like branch, push and pull.
<jfroy> Which requires additional state.
<LarstiQ> SamB: it is in "vcs" in Debian afaik
<SamB> LarstiQ: hmm.
<LarstiQ> SamB: so where are you seeing this?
<SamB> apparantly aptitude picks one of the sections at random?
<SamB> or ... dunno
<SamB> all of these available versions seem to be in "vcs"
<SamB> but the listing for bzr was in "devel" in aptitude's UI
<SamB> oh, wait
<SamB> Section: devel
<SamB> Version: 1.17+4556+119
<LarstiQ> SamB: in unstable?
<SamB> LarstiQ: so are you saying it's in "vcs" for Debian but "devel" for Ubuntu?
<SamB> no, that's the PPA
<LarstiQ> SamB: PPA or?
<LarstiQ> ok
<LarstiQ> SamB: it is devel for the PPA I think
<SamB> still odd
<LarstiQ> SamB: it _used_ to be devel in Debian too
<SamB> yeah, I thought that might be the case
 * LarstiQ checks the changelog
<SamB> I wasn't even assuming that it wasn't supposed to be now
<SamB> ... so what's the new URL for bzr.dev?
<LarstiQ> SamB: no change yet
<LarstiQ> SamB: hmm, http://packages.ubuntu.com/search?keywords=bzr still has it at devel
 * SamB wonders where the branch for the ubuntu packaging is
<SamB> oh, all the plugins too?
<SamB> wow this page looks odd to me: http://packages.ubuntu.com/karmic/bzr
<SamB> it's like someone took packages.debian.org and tried to theme it
<SamB> ... and took out some of the links :-(
<SamB> why no "ubuntu package tracking system"?
<LarstiQ> I don't know
<LarstiQ> I do know that when packages.ubuntu.com got set up it was run by the same admin as packages.debian.org
<LarstiQ> same code too
<SamB> LarstiQ: well I can *see* that it's largely the same code
<LarstiQ> :)
<SamB> jelmer: where it says "Debian Package Source Repository (VCS: bzr)\n    http://bzr.debian.org/pkg-bazaar/bzr/unstable" at the bottom of http://packages.ubuntu.com/source/karmic/bzr, does it actually mean that's where the ubuntu package source comes from too?
<SamB> I mean, should it say "Ubuntu Package Source Repository" there, or?
<LarstiQ> SamB: I think that is parsed from Vcs-Bzr: http://bzr.debian.org/pkg-bazaar/bzr/unstable
<LarstiQ> SamB: and for Ubuntu the process is different, so there is no equivalent header, the Debian is left intact
<SamB> LarstiQ: how does it work for Ubuntu?
 * LarstiQ speculates further
<LarstiQ> SamB: judging from a james_w dent, package branches on Launchpad
<SamB> LarstiQ: anyway, I wasn't sure about that myself which is why I decided to ask the one whose name is on all the changelog entries for both projects that I see ;-)
<LarstiQ> you mean jelmer? :)
<LarstiQ> SamB: afaik bzr is just synced into ubuntu from debian most times
<james_w> SamB: it's hit and miss whether that is where the Ubuntu code is stored
<james_w> in bzr's case it is correct
<SamB> LarstiQ: yeah
<SamB> anyway -- how does one find these "package branches on launchpad"?
<SamB> what exactly is a "remap"?
 * SamB wonders why bzr repacks packs in a log_10 fashion
<lifeless> SamB: latency
<lifeless> if you mean why log10 rather than logn or log2, that is mostly arbitrary
<SamB> is it going to insist on repacking when there are 10000 revisions in the repository?
<lifeless> yes
<SamB> ouch
<lifeless> not really, that doesn't happen often :)
<SamB> I don't know if my computer can handle it though
<lifeless> its expoential backoff
<SamB> how much does it cost to do a repack, RAM-wise?
<lifeless> depends on format and how unpacked it is
<lifeless> a 2a format recompresses
<lifeless> 1.9 and before just shuffle data around to consolidate packs
<SamB> how much redeltaing does it do ?
<lifeless> in 2a, a lot
<lifeless> its pretty fast though
<SamB> what computational complexity ?
<lifeless> and memory wise, if you managed to commit you will be able to pack
<SamB> oh.
<LarstiQ> bar bugs
<SamB> okay.
<lifeless> [with some fuzz]
<SamB> ... oh, while we speak of RAM, I saw a thread in the bzr list about a memory profiling tool. do you know the current URL of that tool?
 * SamB forgot even the name, but doesn't remember the URL being too informative ...
<lifeless> its in jams +junk
<lifeless> pymemdump
<SamB> and his LP id is jam?
<lifeless> jameinel
<SamB> thanks
<jam> SamB: lp:~jameinel/+junk/py_memory_dump IIRC
<jam> hi lifeless
<lifeless> hi jam
<SamB> jam: why no project?
<jam> SamB: I never came up with a nicer name for it
<SamB> the name seems an adequate description of how it works
<jam> I was hoping to have something fun
<LarstiQ> jam: was lp:~ian-clatworthy/bzr/sphinx-userdocs/ the 2a upgrade docs you had in mind?
<LarstiQ> jam: ehm, doc/en/upgrade-guide/ in bzr.dev
<jam> LarstiQ: I don't think it would be under "sphinx"
<jam> LarstiQ: upgrade-guide sounds about right
 * SamB hands jam a stack of Monty Python DVDs and tells him to knock himself out, then
<jam> data_migration
<garyvdm> jam: how dose that compare to heapy?
<jam> LarstiQ: data_migration.txt subheading Migrating Branches on Launchpad
<jam> garyvdm: The #1 difference is that it dumps the information about memory consumption to disk with a *very* lightweight process
<IRConan> hi... I'm trying to import an hg repo into bazaar but I get this error: http://pastebin.com/m43e0952e
<jam> so if you interrupt your 1GB consumption, it can actually work
<IRConan> anyone know what's going on?
<jam> and then you run a separate bit to analyze it
<garyvdm> jam: I see
<jam> also, it works on windows, mac, 64 bit, etc
<jam> garyvdm: heapy liked to crash or just not compile for me
<jam> also, by dumping to disk, you can do your own data mining a bit easier
<jam> like 'grep' is a surprisingly useful memory debugging tool :)
<LarstiQ> jam: I read that, it seems suboptimal, though it has the merit of keeping things working
<jam> LarstiQ: what would you consider "more optimal" ?
<LarstiQ> jam: cross-format stacking
<jam> given that you break a stacked branch if you upgrade the source underneath it
<jam> LarstiQ: if you want to implement that, feel more than welcome
<garyvdm> jam: and cause it writes to disk, you can look at someone else's dump
<jam> garyvdm: sure
<jam> just be aware, the dumps are pretty big
<jam> I went with JSON, and it ends up at least the same size as in ram
<garyvdm> Ok
<jam> but bzip2 works well
 * SamB thinks he would prefer the new lzma format
<LarstiQ> jam: it is not the pragmatic move no. I'll mull things over tonight (bedtime now) and get things rolling again tomorrow
<SamB> (why new? because they smartened up and added magic bytes, that's why!)
<garyvdm> jam: vila says that qlog mysqlbranch can use up to 2gb - but I can't reproduce, and have only seen max 400mb.
<LarstiQ> night
<garyvdm> maybe I can use that to debug
<jam> garyvdm: might be a 64-bit vs 32-bit thing?
<garyvdm> Yes - vila did mention that.
<jam> given that 90% of objects double in size on 64-bit
<lifeless> poor irconan, got no answers
<SamB> jam: that doesn't explain 400mb -> 2gb
<lifeless> igc: http://pastebin.com/m43e0952e
<lifeless> jelmer: hai
<lifeless> https://code.edge.launchpad.net/~lifeless/subunit/time-support/+merge/9136 :)
<SamB> oh, does bzr send work with 2a in 1.17+4556+119 ?
<mwhudson> bzr send (well, bundling) is a bit broken with 2a
<SamB> I'd heard it was
<SamB> I thought maybe you'd gotten it fixed
<SamB> ;-)
<mwhudson> ah
<mwhudson> i don't think so, but i've not been paying super close attention
 * SamB hopes there are at least some failing tests for it
<jam> mwhudson: "bit broken" aka completely unusable?
<jam> I guess you can use "bzr send --no-bundle" :)
<poolie> hi jam
<jam> hi poolie
<jam> SamB: I'm working on it right now, in fact
<jam> I'm down to 2 test failures
<mwhudson> jam: right
<jam> poolie: up for a phone call?
 * SamB supposes he'll just have to push to launchpad ...
<poolie> yes, up specifically for a phone call :)
<jam> poolie: skype/call my house/call my cell, up to you
<SamB> hey, if I push a 2a format branch and launchpad wants to stack it on bzr.dev ... what will happen?
<poolie> ok
<jam> SamB:  it will break
<jam> but patches/bundles/etc from a 2a branch won't be compatible with bzr.dev (right now) anyway
<jam> since it will be generated in a rich-root repo, which can't be stored in a non-rich-root
<jam> note that LarstiQ was looking into what it would take to get all of us upgraded to 2a for bzr branches
<jam> but he is sleeping now :0
<SamB> jam: well, what it took me was jelmer's branch on debian.org having rich-roots ...
<SamB> where is "rich root" explained?
<SamB> while we're on that subject, where are "ghosts" explained?
<lifeless> bzr help repoformats, or some such
<lifeless> ghosts are explained on the wiki
<SamB> lifeless: it doesn't actually say what it IS
<SamB> it just says that changes from rich-root aren't compatible with non-rich-root
<lifeless> ah
<maxb> How is it possible for "bzr ls --ignored --versioned --unknown ." to output nothing, in a directory full of files?
<SamB> if someone symlinked /usr/bin/python to /bin/true ?
<maxb> hah
<maxb> no
<SamB> what's that? you wanted a serious answer?
<lifeless> maxb: works for me
<maxb> hrm
<DaffyDuck_> lifeless: I have a question. First, can you take a look at http://pastebin.com/d673e2777?
<DaffyDuck_> I'm wondering if there's anything bzr can do to make the permissions stick in branches as well.
<SamB> someone should set up a 2a mirror of the bzr repo soon ...
<DaffyDuck_> Someone suggested I use posix acls, but they aren't available for my platform (yet).
<lifeless> SamB: 2a is rich roots; we want to transition, but we can't accept merges from 2a until we transition
<SamB> but what ARE they?
<lifeless> SamB: I think it was covered on the list this morning
<SamB> ah. thanks ;-)
<lifeless> DaffyDuck_: your umask is filtering out the write bit
<DaffyDuck_> lifeless: Yeah -- I know, but "bzr init" does something which properly inherits the permissions. I was wondering if the same procedure can be applied to branching.
<lifeless> DaffyDuck_: I'm not sure; you could file a bug with your demonstration of this
<DaffyDuck_> lifeless: Ok, I'll do that. Not a biggie, but currently I need to run a "fix_bzr_repo_perm.sh" script each time someone has created a branch in the shared repository. After that, everything works like a charm.
<jelmer> lifeless: I was about to "vote approve", but lp is down for maintainance
<lifeless> jelmer: sweet, thanks
<lifeless> I'll land it all
<jelmer> lifeless: awesome
<jelmer> lifeless: I've had positive comments from other Samba devs about subunit
<jelmer> lifeless: proper reintroduction of duration reports was one of the oft-reported bugs
<lifeless> please encourage them to file bugs upstream
<lifeless> feedback is a major source of inspiration
<jelmer> lifeless: the code that handles subunit in samba is independent of upstream though
<lifeless> jelmer: yes, but unless there is something upstream about it, I can't know what they are thinking
<jelmer> lifeless: I'll see if I can forward bugs upstream wrt the specification though if any are reported to me
<lifeless> and I am very keen to get all your code upstream *anyway*
<jelmer> lifeless: that's got the stuff wrt "start-testsuite: "..
<lifeless> I recall that discussion :)
<jelmer> lifeless: and the other bit (the buildfarm) is parsing subunit based on regular expressions that match the behaviour of our testsuite
<jelmer> rather than properly parsing subunit
<jelmer> the latter will change at some point, when we get the other projects on the buildfarm across to subunit
<lifeless> I think it will be great when you are able to be building on the subunit commandline tools/tools in trunk
<lifeless> I'm doing a talk at the end of the month about subunit at the local LUG
<jelmer> lifeless: yeah, being able to hook into the system subunit would be nice
<jelmer> it's on my todo list :-)
<lifeless> jelmer: I missed the shouldStop attribute, I'll add that as a property - ok?
<jam> poolie: still there?
#bzr 2009-07-23
<jml>  Launchpad uses Bazaar  1.17.
<lifeless> grats
<mwhudson> jml: yay
<jelmer> lifeless: I think I may've missed something - where would that be necessray?
<jelmer> mwhudson: hi
<lifeless> jelmer: test suites ask the test result whether to stop
<lifeless> to allow aborting a run early
<jelmer> mwhudson: It was interesting to finally see the lp code :-)
<jelmer> mwhudson: I noticed a trivial thing that could be fixed, lp:~jelmer/launchpad/default-rich-root
 * jelmer looks again
<mwhudson> jelmer: oh i suspect i didn't fix that because it would actually downgrade all the bzr-git branches now
<jelmer> mwhudson: it would only affect new ones, but that's a good point..
<mwhudson> jelmer: if it's the change i think it is, not true
<mwhudson> launchpad rollout issues, full attention in a bit :)
 * SamB wonders where launchpad is rolling to
<spiv> mwhudson: it's this change: http://bazaar.launchpad.net/~jelmer/launchpad/default-rich-root/revision/8303 :)
<mwhudson> jelmer: http://bazaar.launchpad.net/~jelmer/launchpad/default-rich-root/annotate/8303/lib/lp/codehosting/codeimport/worker.py#L65
<spiv> jelmer: also, congrats, that's probably the first launchpad branch from a non-canonical LP dev that I've seen :)
<jelmer> mwhudson: ahh, sorry
<mwhudson> jelmer: np, the comment is misleading
<mwhudson> jelmer: also the code should probably be changed to do a reimport rather than an upgrade for the brisbane-core transition
<jelmer> mwhudson: yeah
<igc> morning all
<jelmer> hi Ian
<lifeless> mwhudson: why reimport?
<lifeless> mtaylor: perl!
<mwhudson> lifeless: (a) quicker probably (b) the packs imports have squashed commit messages
<mtaylor> lifeless: muah!
<mtaylor> lifeless: question on "best" way to figure out a specific chunk of bzr data...    I have a local branch... how do I find the GCA between the local branch and the submit branch? (like, the rev from which a revision bundle would start)
<mwhudson> there's the ancestor: revspec
<lifeless> mwhudson: will it get the same revids? if so, and the root conversion isn't identical to the conversion logic, then its a problem
<mwhudson> lifeless: yes
<mwhudson> lifeless: they're in rich root already
<lifeless> mtaylor: as mwhudson says. do you want command line or python?
<lifeless> mwhudson: ok, if they are already rich root its fine
<mwhudson> lifeless: i'm only talking about bzr-git imports here
<mwhudson> lifeless: not cscvs ones
<lifeless> mwhudson: converting from packs should be faster than a reimport btw
<mwhudson> for bzr-git
<mwhudson> ?
<lifeless> I'd expect so
<mwhudson> anyway, the fidelity is the real reason
<mtaylor> mwhudson, lifeless: ah - sorry - irc client misbehaved. command line
<jelmer> lifeless: last I checked an import from git is faster than an upgrade
<lifeless> jelmer: thats surprising
<lifeless> mtaylor: do you want the revid or revno?
<lifeless> mtaylor: there is --show-base to some commands
<mtaylor> lifeless: well, I think both would eventually be nice ... but revid would be probably more useful
<mtaylor> lifeless: on the other hand, if I need to use bzrlib to do this, I can live with that
<lifeless> mtaylor: so, for the specific case of where a bundle will start at
<lifeless> I think its
<lifeless> bzr revision-info -r submit:
<lifeless> mtaylor: also, perl!
<jelmer> lifeless: upgrade seems to be a lot better now
<jelmer> lifeless: unscientfic tests: bzr-git 8s, upgrade 5s
<mtaylor> lifeless: that gives me ... hrm.
<mtaylor> lifeless: that just gives me my head revision
 * mtaylor looking further...
<spiv> poolie: good morning.
<poolie> hello spiv :)
<poolie> hello lifeless, all
<jelmer> hi poolie
<garyvdm> Hi poolie
<mtaylor> lifeless: so, I think revision-info is giving me the right thing from one perspective- I think it's giving me the GCA of the local branch that it shares with the remote...
<mtaylor> lifeless: but what I want is the GCA in the context of the remote branch...
<mtaylor> oh wait
<mtaylor> lifeless: nevermind... /me smacks self in head
<spiv> jam: ping -- want to review my inventory-delta branch?
<garyvdm> When you do a merge, is the revision that is used to get .BASE the same for all files, or can it be different?
<lifeless> by default the same
<lifeless> but there are options that can make it different
<garyvdm> Like a different merge type?
<lifeless> yah
<garyvdm> Is it the same with --lca?
<SamB> so ... how come "bzr upgrade" to --rich-root-pack or --2a seems to go nearly to the end of the progress bar pretty quickly, but then stay near the end for a long time ?
<lifeless> I'm not sure garyvdm
<lifeless> SamB: Possibly incorrect phases, or that a single logical step has more work to do
<garyvdm> lifeless: I need to investigate that for something I'm doing for qbzr, and figure how I'm going to handle --weave...
<SamB> [#################\  ] Copying content into repository.:Transferring revisions
<garyvdm> lifeless: As allways - Thanks for the pointers
 * SamB wonders what causes the bar to stop spinning
<lifeless> ask instead what makes it spin at all
<poolie> hello lifeless
<SamB> 6611.394  Auto-packing repository <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x8cf81cc>, which has 15 pack files, containing 15000 revisions. Packing 10 files into 1 affecting 1000 revisions
<igc> lifeless: thanks. Raised as bug 403272
<ubottu> Launchpad bug 403272 in bzr-fastimport "bundled hg-fastexport exception re changelog.count" [Undecided,New] https://launchpad.net/bugs/403272
 * garyvdm is writing a reply to "Nubee question"
<SamB> what was that Pyrex alternative?
<SamB> Cython?
<lifeless> yes
<JoaoJoao> hello
<JoaoJoao> is there a command to rename a bzr branch
<JoaoJoao> ?
<spiv> JoaoJoao: typically "mv oldname newname" on your filesystem does the trick :)
<spiv> JoaoJoao: or is this a branch on launchpad?
<JoaoJoao> spiv, that doesn't work when I'm using shared repos + lightweight checkouts
<jml> JoaoJoao, there isn't a command for that: it's a bit of a pain
<JoaoJoao> hmmm looks like mv + bzr switch --force could do the trick
<jml> JoaoJoao, give it a try.
<jml> JoaoJoao, what I do is: mv ~/repos/project/old ~/repos/project/new; echo -n 'file:///home/jml/repos/project/new/' > ~/src/project/old/.bzr/branch/location; mv ~/src/project/old ~/src/project/new
<mwhudson> yes, switch --force should help
<JoaoJoao> thanks jml, mwhudson
<JoaoJoao> btw, does bzr support or has some plugin for interactive commits?
<lifeless> theres a plugin I believe
<lifeless> also the qbzr commit dialog can select bits
<JoaoJoao> yup, bzr-interactive works fine :)
<JoaoJoao> bzr plugins rock
<garyvdm> If you have 2 branches, with the same file-id's, but no common ancestor, how do you merge?
<garyvdm> nvm - bzr merge ../dev2 -r -1..0
<lifeless> garyvdm: uhm, probably you want 0..-1
<garyvdm> ah
<JoaoJoao> any estimated release date for bzr2?
 * fullermd admits to mild curiosity as to what -1..0 will DO...
 * igc lunch
<garyvdm> Please can someone read this:http://paste.ubuntu.com/225619/ I want to make sure that the advice I'm giving this guy is good.
<garyvdm> http://paste.ubuntu.com/225619/
<lifeless> abentley: around?
 * garyvdm sends mail
 * SamB wonders how jam runs the tests for pymemdump
<GungaDin> hi
<GungaDin> How do I tell bzr to ignore committing a file?
<GungaDin> I mean... not to commit a file that was changed.
<SuperMMX> GungaDin: there is an option "-x" or "--exclude" for commit
<mwhudson> bzr ci -x
<SuperMMX> or just specify files that you wanna commit
<GungaDin> sure thx
<abentley> lifeless: kinda around.
 * SamB wanted to file a bug against pymemdump for not having a name and then realized it'd need to have one for him to do that ... jam!
<lifeless> abentley: I mailed the list
<lifeless> abentley: copied to you
<abentley> lifeless: I see it.
<abentley> lifeless: I'm not deeply opposed to PreviewTree.inventory, but I thought omitting it would help us explore what's needed to go inventory-free.
<lifeless> abentley: I think it has helped us do that
<poolie> http://fishbowl.pastiche.org/2009/07/22/a_letter_to_my_younger_self/
<lifeless> nice
<lifeless> garyvdm: if you're around, and jelmer: too; I'm looking [well, I *will be*] looking for a GUI progress bar
<lifeless> I want to pop up a little progress bar in the bottom right of my desktop.
<lifeless> pointers appreciated
<poolie> lifeless: http://bzr.pastebin.com/d7c92d84a <- just adding a plain Reconfigure class
<poolie> i don't want to tease apart the existing code for now
<lifeless> poolie: sure; I don't think you should tease it apart. The only concern I have is that this makes the module be mixed in style, which muddies things more.
<lifeless> poolie: I will let you be the judge of how important that i.s
<spiv> Incremental steps to a better style is probably better than adding more code to an unwanted style.
<lifeless> spiv: as long as its really clear to other folk coming along that this is the trend
<lifeless> spiv: without clarity its just unclear ;)
<spiv> lifeless: agreed
<poolie> lifeless: pydoc debug is documented to 'Run the test without collecting errors in a TestResult'
<poolie> that might be something you'd want to call from inside a debugger i guess...
<lifeless> poolie: yah
<poolie> i'm disappointed that it doesn't remove my bugs :)
<lifeless> poolie: its a underdeveloped aspect of te interface
<garyvdm> lifeless: lp:~jameinel/qbzr/progress
<garyvdm> lifeless: If you want, I can hack up a minimal plugin.
<garyvdm> bbl
<lifeless> garyvdm: oh, its not bzr
<lifeless> garyvdm: its for subunit
<garyvdm> lifeless: Then this diff is a good sample: http://bazaar.launchpad.net/~jameinel/qbzr/progress/revision/813
<lifeless> thanks
<GungaDin> How do I check a log given a rev id?
<poolie> spiv, btw lifeless said you might have fixed something recently to make tests rm their working directory as soon as they finish?
<poolie> GungaDin: bzr log -r revid:blah
<spiv> Hmm, I don't remember fixing anything like that very recently.  I did make some change about six months ago maybe.
<poolie> spiv, also it should have a smiley when reporting 0 vfs :)
<poolie> as this pull just did :)
<spiv> :)
<lifeless> jml: jelmer: http://paste.ubuntu.com/226322/ feedback sought
 * igc dinner
<fullermd> I love comments like "# XXX: Update this after 0.10 is released"...
<LarstiQ> igc: I have time to look at the sphinx users docs in ~1.5 hours if that's ok
<igc> LarstiQ: cool
<jelmer> 'evening Ian
<LarstiQ> igc: done
<LarstiQ> LenZGr_: did you see the bzr-svn 0.6.3 announcement, and was that helpful for your packaging?
<LenZGr_> LarstiQ: Yes, thank you! 0.6.3 should be available shortly (I commited it already, but made a mistake which caused the build to fail)
<DaffyDuck_> I'm looking for a good way to create archived backups of my repositories. I don't want to backup unless I need to, so I was thinking about parsing "bzr info -v" and using the "revisions" under "Repository:", and use the revision number in the file name. That way I can check if the revision is backed up already. Is there a problem with this?
<LarstiQ> LenZGr_: good, that makes me happy :)
<LarstiQ> DaffyDuck_: there shouldn't be that many files, so why not let rsync do it's job?
<DaffyDuck_> LarstiQ: The data needs to be encrypted and stored on external media. We're not fooling around when it comes to backups.
<Raim> even if you encrypt it, it should still be stored efficiently by your backup software. so backing up an unchanged bzr repo again should not be a problem...
<LarstiQ> DaffyDuck_: as Raim said, I'd expect the backup software to be able to detect changes. Other than that -
<LarstiQ> DaffyDuck_: in theory revisions could be removed, in practice they probably only get added. How serious about the backups are you?
<bialix> igc: hi
<igc> hi bialix
<bialix> igc: can we disable bugmails in bzr-explorer-dev mailing lists?
<bialix> I've got 2 copies of those mails
<bialix> one from LP and another from ML
<igc> bialix: you might be subscribed separately?
<bialix> I don't understand
<igc> the people notified list on some of them was 'bialix + Bzr Explorer Devs'
<bialix> on all of them actually
<bialix> I'm trying to disable bugmails on bugs page
<igc> bialix: go for it
<bialix> ok, will see how it will going
<igc> bialix: I'm not sure how to do it fwiw
<bialix> https://bugs.launchpad.net/bzr-explorer/+subscribe
<bialix> I was under impression you explicitly subscribe ML to receive bugmails, no?
<igc> bialix: I can't see anything in the ml or team configuration re that. Ask on #launchpad maybe
<bialix> igc: can you explain your comment: https://bugs.launchpad.net/bzr-explorer/+bug/393615/comments/6 please?
<ubottu> Ubuntu bug 393615 in bzr-explorer "Initialise shared repository hangs [Windows]" [Medium,Triaged]
<bialix> what's fixed in 1.18?
<spiv> jam: hey
<igc> bialix: bug 394227
<ubottu> Launchpad bug 394227 in bzr "bzr init sometimes fails to complete and saturates cpu" [Medium,Fix committed] https://launchpad.net/bugs/394227
<jam> hi spiv
<spiv> jam: If you are inclined to review my updated inventory-delta patch, that would be lovely :)
<spiv> jam: I also heard that you were surprised to hear that inv-delta streaming was much better than IDS over localhost HPSS?
<spiv> jam: try comparing bzr push -r2000 of bzr.dev into a "bzr init bzr://localhost/ --1.9-rich-root" -- I found ~7.5 min real time vs. 31 min, and much less memory consumption and IO too.
<jam> spiv: I was, though there are ways to explain it.
<jam> mostly in the marshalling/unmarshalling overhead
<spiv> As in, 30M transferred vs. ~740M.
<jam> spiv: Not a 2a format?
<jam> spiv: also, I've always focused on "pull/upgrade" and not "push"
<jam> not sure if that matters here
<spiv> jam: that would be interesting too, but I thought I'd measure something simpler.
<spiv> I wouldn't expect it to affect IDS, it might affect streaming but probably not.
<spiv> (the difference between pull/upgrade vs. push, that is)
<spiv> Anyway, the current patch reinstates IDS for local fetches.
<jam> my bigger concern ATM is why things are breaking
<spiv> Given that IDS is known to have pretty bad performance on the network that seems like the best compromise to me.
<jam> is it a bug that already existed that you are now testing
<jam> or did something break with the new changes
<spiv> The test failure I reported?
<jam> yes
<spiv> I'm pretty sure it's an existing bug.
<spiv> I extended the test coverage significantly.
<spiv> That particular test is more precise in verifying that it can actually stream the revisions now, and I also added several new scenarios to the parameterisation.
<spiv> It may be that IDS is actually broken for local stacked branches, but even if so my branch isn't a regression there.
<spiv> It *might* shed some light on some of our bug reports, though.
<spiv> It may be worthwhile extracting the part of the patch that extends per_interrepository's scenarios, and it's test_fetch module, trying it on bzr.dev, and perhaps landing it directly.
<spiv> Maybe with a KnownFailure if it really does uncover an existing bug.
<spiv> I'm pretty confident that my changes would not have introduced it, the refactorings I did to IDS to make its code reusable by the streaming path were fairly simple... but I've been wrong before :)
<spiv> jam: I *think* the issue may be that the tests in bzr.dev don't test any rich-root -> rich-root IDS paths.
<spiv> jam: only non-rr -> rr.
<wadesworld> just to verify, the only way to run bzr serve and allow only some users write access is to leave it read-only but have the ones with write access use bzr+ssh, correct?
<jam> spiv: weird
<jam> your review request is in the "other" category
<jam> Maybe because of how you resubmitted it?
<jam> (I was having trouble finding it)
<spiv> jam: oh, weird.
<jam> It didn't have any "requested reviews"
<spiv> jam: I guess that's possible, just changed the "status" to "resubmit".
<jam> especially not of 'bzr-core' like the other ones
<jam> I fixed that
<jam> Probably a UI bug for launchpad-code reviews
<spiv> Which I thought was the way to resubmit, but perhaps not.
<spiv> Yeah.
<jam> spiv: I think it *is*, with the caveat of about 3-4 bugs I've opened on it so far :)
<spiv> jam: so, I see this bug in bzr.dev
<spiv> jam: if I add 6RichRoot->2a to the interrepo scenarios and run interrepo.*test_fetch.*stacking.*2a I see the failure.
<spiv> jam: needless to say, my inv-delta streaming code passes that test ;)
<spiv> Hmm, or rather, I see a failure, not necessarily a valid failure now I look at it.
<spiv> This failure is why I changed the assertion to "can stream these revisions" rather than directly checking for inv parents in the repo.
<spiv> Because things seem a bit different in 2a...
<jam> spiv: so the inventory roots should be present in 2a formats
<jam> (as should all the chk pages underneath)
<jam> which is what we had worked on with the "get_stream_for_missing_keys()" a while back
<jam> "can stream" might be a stronger assertion because of the need for child chk pages...
<spiv> jam: ah, but it does still fail the "can stream" check.
<jam> spiv: so it is very likely that IDS doesn't fill in parent inventories into a stacked branch
<jam> as the only code that does 'get_stream_for_missing_keys()' is the. .... streaming code :)
<jam> stacking
<jam> the bane of my last few months
<jam> really, it breaks all sorts of things. Especially when coupled with the "RemoteRepository" are not actually stacked anymore...
<spiv> Yeah, I know what you mean!
<jam> so the abstraction we put in, is removed, and then everything is exposed again
<spiv> "AbsentContentFactory" bugs etc.
<jam> yep
<spiv> So, the bug is in bzr.dev; I have fix ready to go, just merge my patch and disable IDS ;)
<Kinnison> jelmer: didja file the bug in the end?
<jam> spiv: I actually thought IDS was disabled when stacking was involved
<jam> but I guess that is more it is disabled when the formats are identical
<spiv> In doing the timings of streaming vs. IDS over localhost I did fix one performance bug, btw.
<spiv> (in streaming, that is)
<jam> spiv: btw, my loopback can stream 700MB in about... 1s
<spiv> There's almost certainly a fair bit of low hanging fruit there, performance-wise.
<jam> so I doubt that is a specific cause of slowdown
<jam> probably the serialization/deserialization is, though
<spiv> Right, but my disk can't seek back and forth that fast, particularly when bzr is pushing the disk cache out of memory...
<spiv> With IDS, -Dmemory reported VmPeak of 333840.
<spiv> vs. 126328 for inv-delta.
<spiv> (and VmHWM and VmRSS had similar ratios)
<jam> spiv: I'm curious if you just tweaked the size of the internal cache, how much effect that would have
<jam> (batch_size, and one other flag IIRC)
<spiv> So, if you can bzr push -r2000 of bzr.dev over localhost with IDS in 1s I'll be impressed :)
<spiv> Possibly the overhead of 103958 HPSS calls started to matter?
<spiv> It was certainly reading back a lot of the data it had already written (in addition to the regular repacking over the wire).
<jam> spiv: Right, I'm saying the cost of marshalling/serializing 700MB was important
<jam> not the fact that it was 700MB
<jam> over the loopback
<spiv> Sure.  700MB over any other network interface is pretty important, though :)
<jam> spiv: so 4519 is your latest, right?
<spiv> That inv-delta was so much faster, even though it's paying CPU cost on both sides (and I don't have dual core), is a good sign for streaming I think.
<spiv> jam: yep
<jam> spiv: but time 'bzr branch x y' and compare
<spiv> jam: interesting, IDS and inv-delta were much much closer in time on -r1000
<jam> spiv: very little interesting in bzr.dev pre 1500
<jam> that is where we got merging support
<spiv> (-r1000 is only 1102 revs, -r2000, is 7410 revs)
<jam> 1-~1500 are all just simple commits by martin
<jam> hm... maybe that changed with some of our history mutations
<spiv> As in, within 20% rather than over 4x slower.
<jam> there is a mainline history switch with robert as a committer
<spiv> Obviously it's many more revs and larger trees, but it's still seems disproportionate.
<spiv> (hmm, about 10x more data in knit pack format)
<jam> spiv: computing inventory deltas is generally O(N^2)
<jam> spiv: so what to do about the 'bloat' factor?
<jam> as in, taking 400+MB on disk, rather than <100MB?
<spiv> I think the 2a sink needs to be smarter.
<spiv> (possibly the smarts should be builtin to the generic sink, rather than making a 2a specific sink...)
<spiv> i.e. do a pack midstream if a certain volume of records has been received, on the assumption that can probably save significant disk space.
<jelmer> Kinnison: not yet, I forgot about it :-)
<jam> spiv: I'lll at least argue that perhaps the source can stream the content in a more efficient manner
<spiv> Currently the StreamSink is smart enough to do that at the end, but that's a bit late.
<jelmer> jam: Is there any situation in which an InventoryEntry could have a symlink_target that is None ?
<Kinnison> jelmer: *pout*
<Kinnison> jelmer: How can I be anything less than the most important person in your life?
<spiv> Yeah, that seems likely too, but tweaking StreamSink is likely to be easier.
 * Kinnison sobs
<jam> jelmer: I believe InventoryEntries from a WorkingTree.inventory are set to None, because we want you to go read the symlink directly
<spiv> I'd also love to make the stream resumable while we're on the topic ;)
<spiv> But the branch is already pretty large!
<jelmer> Kinnison: :-)
<jelmer> Kinnison: I'll do it now, while I have my mind on bzr
<jelmer> jam: ah, thanks
<jam> spiv: so IDS does a repack every 1k revs or so, is that possibly the extra data you were seeing over the wire?
<jelmer> jam: In that case bzrlib/export/dir_exporter.py should possibly special case that situation?
<jam> jelmer: perhaps. I don't really know what export w/ a workingtree as a source is really meant to mean
<spiv> jam: it's some, but not all of it.
<spiv> jam: even when it's not repacking I see an enormous number of readvs.
<spiv> In fact, I suspect repacking isn't even a majority of the traffic.
<jelmer> jam: it's done in bzr builddeb, which allows you to build based on either the current working tree or a historic revision.
<jam> jelmer: I'm not really 100% familar with the code. But building from an uncommitted tree seems foolish
<jelmer> jam: Since it has a tree object around as well I'll change it to use tree.get_symlink_target
<jam> jelmer: tree.get_symlink_target would be the safest bet
<spiv> ~740M of traffic for 27M of packs isn't accounted for by repacks every 1k when there's only 7410 revs.
<jelmer> jam: It's pretty common to not commit until you've tested that building the package works
<jam> spiv: except the size on disk *before* repacking is probably a bit larger?
<jam> I guess you are testing with --1.9-rich-root
<spiv> jam: this target is 1.9-rich-root, though.
<jam> which doesn't change much
<spiv> Right.
<jam> so... currently testing your code and it is "hung"
<jam> as expected
<spiv> Yeah, it has some long pauses :(
<jam> and, as someone else mentioned
<jam> it pauses at:
<jam> [###################/]  14218KB    94KB/s
<jam> which looks like it is almost done
<jam> when in reality, it has barely started
<spiv> Two parts where it has long pauses, I think.
<jam> spiv: any idea why we don't even get transport progress updates?
<spiv> One where it's busy doing lots of generate_root_texts Â» _find_root_ids Â» iter_rev_trees (judging from sampling backtraces with SIGQUIT)
<jam> are you computing all deltas at once?
<jam> (if only SIGQUIT worked on windows...)
<spiv> Then another pause after it's sent the full stream and is waiting for the server to respond.  Apparently the server does some lengthy work at end of stream.
<spiv> (check references, find missing keys?)
<jam> spiv: neither of those should be minutes...
<jam> repacking?
<spiv> Although in fact I noticed during that pause for the server that it the pack file in the upload dir was slowly growing.
<spiv> Which seems odd, I would have expected it to have spooled out to disk as it was received.
<jam> spiv: converting inventory deltas to full inventories?
<jam> adding them to the repository as fulltext
<jam> and recomputing a "knit-delta"
<spiv> Hmm, not a repack on after a single insert into 1.0-rich-root I don't think.
<jam> would be my guess
<spiv> Yeah, that could well be it.
<spiv> I assume applying deltas is faster on 2a?
<jam> spiv: faster than --1.9-rich-root, most likely
<jam> fast as you would think... not always
<jam> finding minimal deltas helped a lot here
<spiv> Well, I'm used to that :)
<spiv> The streaming code currently makes a delta against every parent and chooses the shortest to send.
<jam> spiv: so I noticed that you are still using Inter1and2Helper... which means we have to re-read all the inventories. is that correct?
<spiv> Yes, probably.
<spiv> I think that maybe we can improve that...
<jam> spiv: why is the api:
<jam> _stream_inventories_as_deltas(..., fulltexts=??)
<jam> seems a bit strange to ask for fulltexts when you want deltas
<jam> spiv: so here is *my* summary with mysql-525
<spiv> jam: get_stream_for_missing_keys also generates inv-deltas.
<jam> "time bzr branch"
<jam> real    3m20.731s
<jam> "time bzr IDS push bzr:///"
<jam> real    3m45.805s
<spiv> jam: but we don't want missing "compression" parents, we want "fulltexts" at that point.
<jam> "time bzr IDelta push bzr:///"
<jam> real    9m40.311s
<spiv> jam: so that flag causes it to generate deltas from an empty revision.
<spiv> jam: an alternative that doesn't work would be to send a fulltext inv in the native format
<spiv> jam: that doesn't work because the sink expects the inv in the *source* serialisation, but gc formats don't have a functional inv serialisation.
<jam> spiv: well they do after I finish my patch to the bundle code
<spiv> jam: (they actually try to serialise as xml5, which doesn't support rich-roots, but looks like they do if the rich-root version is the revision...)
<jam> but stuff like accidentally inheriting from a non-rich-root capable xml inventory serializer needs to be fixed
<spiv> So I thought that given that I just defined a format-independent serialisation I should just use that :)
<jam> spiv: I have a patch which fixes that sort of thing :0
<jam> I agree
<jam> just can't do it for bundles just yet
<spiv> Right.
<jam> spiv: I would probably recommend not using 'fulltexts' as the flag, as I find it confusing, I'll see if I can come up with a better name.
<spiv> I agree that part of the code is a little unclear, feel free to mention that in your review :)
<spiv> Thanks!
<jam> spiv: and I would recommend retrying with --2a as the target. I think that may be a major difference between what we are seeing.
<spiv> Yeah, I will.
<jam> spiv: I noticed that you don't delta against revisions you haven't sent... I'm wondering if that is optimal
<spiv> (I also have high on my todo list trying the blackbox hpss acceptance tests with 2a to make sure the hpss call counts don't regress)
<jam> consider "bzr push" is just adding 1 rev to a branch
<jam> it will have to extract and send the whole inventory
<spiv> Yeah.  It was a cheap way to avoid having to figure out what inventories I could depend on the remote having.
<jam> spiv: code like this is der very bad:     parent_inv = from_repo.get_inventory(parent_id)
<jam> as in, you re-extract every inventory at least 2x
<jam> actually 3x for rich-root conversion
<jam> which is probably the bulk of 3min => 9min
<spiv> Probably now that I have the get missing keys working probably I don't need to be so pessimistic...
<jam> pushing bzr doesn't show it
<jam> because they are small
<jam> spiv: depending on how your StreamSink works, hard to say
<jam> would it buffer an inventory delta it can't extract
<jam> until it fills in a missing parent
<jam> if so
<jam> what about all the other deltas chained on top of it
<spiv> Oh right, yes, that was why.
<jam> and where are those buffered
<jam> spiv: now I would imagine *not* caching any inventories would be the reason your peak memory consumption went tdown
<jam> but at a fairly high cost
<spiv> It would potentially be fine, except that we don't have a way to store format-neutral inv-deltas between HPSS calls.
<jam> "time bzr branch mysql mysql-19-rich-root" real    6m2.345s
<jam> so it is 2x slower to branch 1.9 => 1.9-rich-root than to branch 1.9 => 2a
<spiv> Whereas we can store arbitrary pack knit-delta records with missing compression parents (by not inserting that pack, and reporting the missing keys)
<jam> spiv: which brings up some design questions
<jam> of doing this
<jam> though I guess we still have "optimized" paths when the formats are the same...
<spiv> We can fudge it -- make a new pack to hold dummy records that store the inv-deltas verbatim.
<spiv> And then don't insert it in the final commit, obviously.
<spiv> Yeah, that was basically my thinking... we don't really need to tie ourselves in knots to get maximal cross-format performance.
<spiv> The main thing is avoiding the pathological performance we currently get, while moving towards a unified code path.
<spiv> I'm finally going to go sleep shortly.
<spiv> Anything else I can do for you before I do?
<jam> spiv: well, in my trivial loopback test, I saw a 3x degradation still... but yeah, I'd like more unified code paths.
<jam> and I like the concept of using inventory deltas more
<jam> spiv: ah, I bet that with --1.9-rr you are seeing such a difference because of "add_inventory_by_delta"
<jam> spiv: RemoteRepository.add_inventory_by_delta is not a smart method
<jam> it is an _ensure_real one
<jam> which means for --1.9-rr we have to read back the whole inventory we just wrote out
<spiv> jam: perhaps I should try with CHK1->2a :)
<jam> spiv: 1.9 => 2a would be reasonable as I think that is a common case we will be hitting
<spiv> Yeah.  I will definitely try that out.
<spiv> I should grab a mysql tree at some point, I guess...
<jam> spiv: so clearly what we need to do is leave IDS alone
<jam> and just have add_inventory_by_delta use the serialized inventory deltas
<jam> and apply them on the other side :)
<spiv> Hah.
<jam> honestly, I think IDS as a *source* is pretty optimal
<jam> as a Sink, obviously we need some work
<spiv> Well, I've borrowed large chunks of its logic for the source already.
<spiv> We can conceivably try borrowing more...
<spiv> But IIRC we start running into issues with different expectations about when things happen in IDS vs. streaming.
<spiv> Perhaps not insurmountable.
 * SamB wishes the bzr .debs would display their Debian versions as well as their internalized versions
<jam> time bzr inter-delta push localhost/mysql-19rr real    4m28.411s
 * SamB doesn't know where the PPA gets it's debian dir from, though :-(
<jam> spiv: So interestingly, for *1.9-rich-root* your delta code is faster than IDS locally
<spiv> jam: so, I am a bit puzzled about parts of Inter1and2Helper.generate_root_texts
<jam> but it is still 50+% slower than IDS to 2a formats
<jam> though
<jam> I *do* have dual cores here
<SamB> jam: can you tell the kernel to stop using one for a while ?
<SamB> hmm
<spiv> I get the feeling it is doing more work, or at least more work up-front, than is strictly necessary.
<SamB> I think there's some kind of CPU mask you can set on processes?
<spiv> If I were to keep using more of IDS's code I'd probably see if I can replace that part.
<jam> spiv: from what I understand
<jam> generate_root_texts reads all the inventotries
<jam> and then compares the root to see how it should create the per-file graph for the root key
 * SamB wishes the progress text would stop getting cut off just before the really useful part
<jam> it does it in a bass-ackwards way
<jam> but that was how we do rich-root conversions
<SamB> hmm
<jam> was/is
<SamB> bzr doesn't seem to handle SIGWINCH correctly
<spiv> jam: and in fact it makes actually revision trees, not just reads the inventories.
<spiv> Which seems like overkill to me.
<jam> spiv: rev trees are trivial overhead over an inventory
<jam> the problem is the inventory reading
<spiv> Sure.
<jam> spiv: so one thing from you before you go
<jam> do you have any idea *how* to share more code between IDS and the streaming stuff?
<SamB> so what is rich about the root in rich-root?
<jam> Is it to put the members onto repo
<jam> or what?
<SamB> and where is this documented ?
<spiv> jam: my vague thinking was "replace Inter1and2Helper.generate_root_texts with an equivalent based on IDS' code."
<jam> spiv: what surprises me the most is how much worse the push to 2a is versus push to 1.9-rich-root
<jam> 4.5min => 9+min
<spiv> Yeah, that surprises me too.
<spiv> jam: btw, regarding SIGQUIT...
<spiv> jam: windows has SIGBREAK
<jam> spiv: and how would one generate that :)
<jam> ?
<spiv> jam: perhaps you could hook the pdb hack into that?
<spiv> jam: the Break key (Alt-Pause or something)
<spiv> Fn-Pause on this laptop keyboard, apparently.
<spiv> Or rather Python on windows has SIGBREAK, it's not a real posix signal of course...
<jam> spiv: Ctrl+Pause on this keyboard
<jam> Fn+Pause on my laptop as well
<spiv> But it should work well enough for this, I think.
<spiv> jam: any luck with SIGBREAK?
<jam> spiv: i can get it to stop the process
<jam> checking on whether I can trap it
<jam> spiv: so far, doesn't look like I can actually trap SIGBREAK
<spiv> Oh, that's a shame.  ISTR I could, but it's been a long time since I tried...
<jam> spiv: I see stuff online that claims you can
<jam> I'm checking
<spiv> (weird that the stdlib docs don't seem to mention it)
<jam> ah, just doing it wrong
<jam> It seems that win32 signal doesn't have the *attribute* SIGQUIT
<jam> so it wasn't installing the hook
<jam> trying again
<spiv> Right, it wouldn't.
<jam> yep, seems to work
<spiv> It probably only has SIGINT and SIGBREAK.
<jam> need to poke a bit more
<spiv> A hasattr-style check in breakin.py is probably appropriate.
<jam> yeah, we have that now for SIGQUIT
<jam> doing the same for SIGBREAK
<spiv> Cool, glad you don't have to miss out :)
<spiv> jam: and update the boilerplate stderr text about SIGQUIT to be parameterised I guess...
<jam> yep
 * SamB finds http://msdn.microsoft.com/en-us/library/ms686016(VS.85).aspx from http://twistedmatrix.com/pipermail/twisted-python/2006-September/014113.html
<spiv> jam: Ctrl-Break is in some ways more appropriate
<jam> sure
<spiv> jam: "give me a breakpoint where you are now" ;)
<spiv> And of course the module name is "breakin"
<spiv> Anyway, -> zzz time.
<spiv> jam: thanks for taking a look at the inv-delta patch.
<spiv> And for the timings.
<jam> sleep well
<dvheumen> hi everyone. I've got a branch ready that fixes one of the 'easy' marked bugs (I'm trying to become familiar with bzr and python), and know I'm wondering how I should push this branch to launchpad/bzr? (So I can request a merge)
<dvheumen> isn't there anyone who knows how to push a branch to launchpad?
<jelmer> dvheumen: bzr push lp:~userorteamname/projectname/branchname
<SamB> dvheumen: well, you could push it to lp:~<insertyourusernamehere>/bzr/<bugno>-descriptive-text
<dvheumen> okay, so I don't need to be part of a team or something to push there ... tnx guys, I'll do that :)
<jetole> hey guys. I just pushed a repo into bazaar on launchpad and then realized after the fact that it had more files then I had thoght. Is there a way to delete them from bazaar on launchpad so that you can't see past revisions etc
<jetole> ?
<beuno> jetole, yes
<beuno> on the branch page
<beuno> next to the title
<beuno> there's a trash can icon
<beuno> that will delete the branch completely
<Jesse> hi
<jetole> not sure what the branch page is but I don't see a trash can. I am in loghead I think it's called
<jetole> loggerhead
<jetole> how do I get to the branch page?
<beuno> jetole, right, you need to go to the branch page in launchpad
<beuno> there's a few ways
<beuno> one of them is running, from the branch:  bzr lp-open
<Jesse> hi folks, i know this might be 50% off-topic, but i just saw the screen shots http://bazaar-vcs.org/BzrScreenshots?action=AttachFile&do=get&target=bzrk.png
<beuno> the other is going to your profile page, and clicking the "Code" tab
<jetole> ok, one sec
<Jesse> and i'm wondering what those panels in the bottom are
<jetole> beuno: bzr: ERROR: bzr+ssh://jetole@bazaar.launchpad.net/~jtole/+abc/def is not registered on Launchpad.
<Jesse> i mean i can't get gnome-panel to work like those
<jetole> beuno: does that mean much to you? I created the launchpad base by simply doing a bzr push with my user name after I uploaded my ssh keys so I didn't register a project per se
<beuno> jetole, +abc?
<beuno> jetole, what's your launchpad username?
<Jesse> @jetole you can push to your +junk folder
<Jesse> @jetole like bzr push lp:~jetole/+junk/myawesomebranch
<beuno> jetole, https://code.edge.launchpad.net/~jetole
<beuno> according to Launchoad
<beuno> you have not pushed any branches to it
<jetole> beuno: I just found the branch page and deleted it, I did use +junk but I didn't know that was a standard name and didn't really want to say too much as some content was personal
<beuno> jetole, gotcha
<Jesse> so anybody knows about the panels in the screen shot?
<jetole> beuno: last quick question, on my own personal branch on my computer, do you know how I can remove a file so when I push the branch again there is no revision included?
<jetole> I want to keep the details of the files I want to push i.e. history etc
<beuno> jetole, if you added a file a few revisions back
<beuno> it's in the history, and the only real way to get rid of it
<beuno> is to get rid of that history
<jetole> ah fine, I am just going to create a new repo
<Jesse> i once wrote a script to sanitize history like you wanted
<Jesse> that was before i pushed code on to lp
<jetole> it's actually all right. One I find out how to remove a directory from bzr I will create a subdir, move the files in and re init
<jetole> or wait, can I create a subdir as part of this repo and push just the subdir?
<garyvdm> Hi all
<Jesse> "as part of this repo and just push subdir" no
<Jesse> if you want to sanitize your repo, you can only start clean and import it with some cleaning routine
<jetole> Jesse, Thanks for the info. I already created a new repo and published it
<Jesse> remember to sanitize stuffs when you import
<jetole> btw, does my folder have to be +junk? Can I use anything else I want?
<Jesse> i'm personally ok with the name
<jetole> heh
<jetole> I'm taking a smoke brake. bbiab
<Jesse> funny that i 'mkdir junk' in my own $HOME
<Jesse> ciao
<Jesse> i don't know if this is rude, but anybody (either from bzr team or not) use gnome?
<jelmer> sure, there are quite a few people here using gnome
<Jesse> http://bazaar-vcs.org/BzrScreenshots
<Jesse> i'm wondering what that panel is
<Jesse> i mean the two at the bottom
<Jesse> hmmm seems john added those
<Jesse> i mean the two bzrk pics
<jelmer> Jesse: no idea, sorry
<Jesse> thx jelmer anyway
<Jesse> maybe i'll need to raise it to john when he's online
<Jesse> arr sorry to go off-topic
<jelmer> Jesse: I think that screenshot was made by Keybuk
<Jesse> really?
<Jesse> i got that info from http://bazaar-vcs.org/BzrScreenshots?action=info
<jelmer> Jesse: yeah, he originally wrote bzrk and his username (scott) can be seen in the screenshot
<jetole> Jesse: I use gnome
<Jesse> jelmer can it be that john took the screenshot when he was looking at a commit by scott? you know bzr is distributed :p
<jetole> although I don't use bzr in gnome
<jetole> I do that from the terminal
<Jesse> Jelmer: I meant I could only find "scott" in the bzrk history window
<Jesse> jetole: me too
<jelmer> Jesse: scott == keybuk
<Jesse> jetole: i use qbzr for diff and log though, it's a great piece
<jetole> do you know how or if it's possible to set a push to launchpad as private?
<jelmer> jetole: I don't think you can unless you have a commercial subscription
<Jesse> jelmer: a silly question, where can i see the user name other than in the history window
<jetole> I haven't had to do a diff in bzr yet but I probably will still use the term since I used that back when I used svn and have used diff -u a million times
<jetole> plus I use vimdiff from time to time
<Jesse> jetole: i have an incredibly short attention span so when i get back to work i usually "bzr diff -r -1" to see where i was
<jelmer> Jesse: the shell
<Jesse> jelmer: oh my bad. i shoulda noticed that ...
<jetole> Jesse: makes sense although I would use a more current revision then again I am not a programmer but a network admin so I only program occasionally
<Jesse> jetole: -1 is at the tip
<Jesse> it's kinda pythonic notation
<jetole> Jesse: oh I thought that was implying the first revision
<jetole> I guess that would be -r 1
<Jesse> yeah
<Jesse> and if your working tree is clean, then bzr diff -c -1 would also be helpful
<LarstiQ> evening
<bialix> heya
<pygi> hi LarstiQ
<pygi> bialix, too
<pygi> :)
<garyvdm> Hi bialix, pygi, LarstiQ
<bialix> hi
<bialix> heya!
<pygi> oh noes, garyvdm !
 * pygi hides
<LarstiQ> hi bialix, pygi, garyvdm :)
<bialix> lol
<garyvdm> Hi jelmeer
<bialix> beuno?
<garyvdm> err s/jelmeer/jelmer
<jelmer> hi garyvdm
<garyvdm> bialix: How are the changes for qcommit/qadd/qrevert working for you?
<bialix> bbl
<jetole> is it possible to have bzr do a push after every commit?
<Tak> you could use a bound branch
<jelmer> hi Tak
<Tak> hello jelmer
<Tak> what's up?
<LarstiQ> abentley: is http://bundlebuggy.aaronbentley.com/project/bzr/ still supposed to work? I get a Proxy Error
<abentley> LarstiQ: Yes.  Presumably, it's hung.
<LarstiQ> right
<abentley> LarstiQ: restarted.
 * LarstiQ hasn't looked at reviewing for a long time, so wasn't sure if bb was supposed to be up
<LarstiQ> abentley: thanks
<LarstiQ> !
<LarstiQ> jam: yeah, will have to go do the development focus dance. Would be nice to have LP ui to mass upgrade branches
<LarstiQ> feh, sleep
 * LarstiQ will attach his plan for action to #390502 in 10 hours
<Kinnison> jelmer: bug number
<Kinnison> jelmer: ?
<bialix> garyvdm: hi again
<garyvdm> Hi bialix
<bialix> ask me again
<garyvdm> bialix: How are the changes for qcommit/qadd/qrevert working for you?
<bialix> I have not used qadd/qrevert recently -- can't say
<bialix> I'll try to try them in next days
<bialix> qci another thing
<bialix> recently I'e made a lot of merges
<bialix> and a lot of qci for renamed files/dirs
<garyvdm> There was a bug for renamed files which I've fixed.
<bialix> I can't say new reports for renamed files/folders is very cool, sometimes I have strange feeling
<bialix> nothing specific, but mostly unintuitive
<bialix> maybe it's because I've used to old way
<bialix> I need more testing
<garyvdm> Yes.
<bialix> in #lp channel one man said: qbzr is ideal
<bialix> err, looks ideal
<bialix> garyvdm: so what is your question about? user feedback?
<garyvdm> how long ago?
<bialix> just
<garyvdm> bialix: yes - just wanted some feedback
<garyvdm> Maybe I need to relook at renames in qcommit.
<bialix> I feel maybe I'd did something differently for new wt view, but you did incredible work
<garyvdm> The change makes senses when you look at renames in qbrowse.
<garyvdm> Thanks
<bialix> unfortunately I have a lot of urgent tasks on my real job
<garyvdm> np
<bialix> I really need to finish redesign of saved commit/uncommit data
<bialix> recently there was bug about qbzr and changes in core cmd_merge
<garyvdm> Yes - I should take a look at that.
<bialix> maybe we really need to drop merge decoration?
<bialix> we can move qpreview support in qmerge
<bialix> maybe it will be more intuitive
<garyvdm> I don't think that would be better.
<bialix> qpreview could be our diff counterpart for qmerge
<garyvdm> Yes - but qmerge should just have a ui to append --qpreview to the args
<bialix> mmm, no
<bialix> I think we need Preview button in left bottom corner, as Diff button in qlog and qci
<bialix> so user can press Preview and got the result
<bialix> and then actually do merge or not
<garyvdm> Ok - I see your point.
<bialix> I'm trying to use more q-commands now, esp.with explorer
<garyvdm> A question we need to look at then is - for the revisions that are needed to be fetched - do we do a fetched, so that they are then stored in the local repo, or do we just retrieve them temporarily.
<bialix> one thing that all the time bother me is selective qdiff
<garyvdm> Yes - we don't have a nice solution there.
<bialix> what's about at least provide --exclude option for qdiff?
<garyvdm> what would that do?
<bialix> use case: I have big tree with separate folder with tests data
<bialix> very often I want to see changes w/o changes in that folder
<garyvdm> Ok - I see
<bialix> so I can at least : bzr qdiff -x tests
<bialix> are you using -A -M -R -D options?
<garyvdm> Nope
<bialix> I found them useful, esp. -M
<garyvdm> bialix: This is what I would like for you to be able to do (not possible right now):
<bialix> so back to your question about fetching
<garyvdm> go into qlog
<garyvdm> highlight a revision range
 * bialix listen
<garyvdm> the file list in qlog should show all changes for the revision range.
<bialix> yes, it will be nice
<garyvdm> At the moment - it only shows for the top revision selected.
<bialix> yeah, it's a bit wrong
<garyvdm> Then you should be able to select a number of files in that list, and do a diff on them
<bialix> and what should be shown in rev details view then?
<garyvdm> At the moment, you can only select 1
<garyvdm> Maybe show all revisions selected.
<garyvdm> One under the other
<bialix> maybe
<garyvdm> I think that would that give you the ability to do what you want?
<bialix> not really
 * garyvdm is cold - and going to find a heater.
<bialix> our weather tomorrow +37 probably
<garyvdm> The command line option --exclude is something we should do anyway.
<bialix> there is still problem with qdiff before commit
<bialix> maybe new qbrowse with real wt view can help here
<garyvdm> What is that problem
<bialix> can it be used and qstatus?
<bialix> ?
<bialix> s/and/as/
<bialix> btw about qci and wt view
<garyvdm> In qbrowse and qci, qadd, qrevert - you can now highlight a selection of file, and do a diff for that.
<bialix> if there is changed empty folder (renamed or added) it shown with + sign to expand the subtree, but there is no subtree
<garyvdm> I allways show the + if the item is a directory
<garyvdm> That would be easy to change though
<bialix> qbrowse is fine, but maybe we can provide qstatus as qbrowse of wt with only changed filter applied?
<garyvdm> Like we show in qcommit
<bialix> I'd better to not run qci without reason to actually commit
<bialix> yes, like we show in qci
<garyvdm> Would be simple to do.
<garyvdm> Do you think fixing bug 390918 is important?
<ubottu> Launchpad bug 390918 in qbzr "qcommit: Select unversioned files donot show in diff." [Low,Confirmed] https://launchpad.net/bugs/390918
 * bialix looks
<bialix> this is the same problem like in qadd?
<bialix> we can fix it for qci and built-in qdiff
<garyvdm> Well qadd does not have a diff button...
<bialix> even w/o adding files to inventory
 * bialix checks
<garyvdm> Yes - When I filed the bug, I was thinking that we would need to create a temporary inventory, but I have since realized that that is not nessesery.
<bialix> hmm
<bialix> qadd has Open acion
<bialix> why not using qviewer for this instead?
<bialix> it runs python scripts
<dazjorz> guys, I'd like to drop you a little note
<dazjorz> bzr-svn: PERFECT
<dazjorz> after reading about Hg-Svn - bzr-svn is a breeze!
<david__> Hey all... Trying to get a newer version of bzr working on ubuntu 9.04 so I downloaded the bzr-1.17.tar.gz for jaunty from https://launchpad.net/~bzr/+archive/ppa ....  and I am getting a lot of errors .. can anyone point me in the right direction or help me debug the problem ?
<jelmer> dazjorz: thanks :-)
<garyvdm> jelmer ^^^
<dazjorz> jelmer: I take it you're the developer for bzr-svn or so? :)
<bialix> jelmer is our wizard of svn
<jelmer> dazjorz: yeah :-)
<dazjorz> let me thank you personally jelmer ;)
<dazjorz> very, very nice work
<bialix> garyvdm: I suppose you're using some std icons for file items in wt view?
<bialix> garyvdm: folders are great, but plain files have terrible look on windows
<garyvdm> Yes - qt  get the os desktop std icons for folders and files.
<garyvdm> I would like to be able to show the icon of the file type.
<bialix> QDirModel can use accosiated icons
<garyvdm> It can???!!!???
 * garyvdm looks
<bialix> in explorer
<bialix> it can
<dazjorz> jelmer: could you explain to me why "svn up" says I'm at rev 5129, and "bzr up" says I'm at rev 4297? :)
<jelmer> dazjorz: bzr revision numbers are per-branch, svn revision nunbers are per-repository
 * bialix tries to imagebn screenshot for garyvdm
<garyvdm> bialix: not in gnome - Must be just windows.
<dazjorz> jelmer: ah, so there were 5129-4297 commits outside of my current working directory? :)
<garyvdm> I take a look to see how they do it, and reproduce in in TreeWidget
<jelmer> dazjorz: yep
<dazjorz> thanks
<jelmer> dazjorz: "bzr info" should also show you the svn revision number
<bialix> garyvdm: http://imagebin.ca/view/tqiRJKJ.html
<jelmer> dazjorz: and "bzr log" should show both the bzr and the svn revision numbers
<dazjorz> jelmer: I don't see it, but it does tell me the checkout of this branch is at the SVN URL
<garyvdm> bialix: Thats cool - I must make TreeModel be able to do that.
<dazjorz> jelmer: bzr 1.17rc1, bzr-svn 0.6.3-1
<lifeless> moin
<garyvdm> Hi lifeless
<jelmer> dazjorz: bzr info will only tell you if you run it against the svn URL directly
<bialix> garyvdm: QDirModel has fileIcon method
<jelmer> moin lifeless
<dazjorz> bzr info tells me "Lightweight checkout (format: subversion-wc), under Location, light checkout root and shared repository have ., checkout of branch has the correct checkout URL
<lifeless> dazjorz: what sort of problem?
<dazjorz> lifeless: none, really - just checking out bzr-svn :)
<bialix> garyvdm: I suspect it can provide access to native icos
<lifeless> david__: what sort of errors are you getting?
<dazjorz> jelmer: you mean in the repository root, or with the URL as an argument? 'cause I don't see the svn rev when I run bzr info https://... too
<jelmer> dazjorz: my bad - try with -v
<david__> Cannot build extension "bzrlib._chk_map_pyx".
<lifeless> david__: any reason you aren't using the prebuilt versions?
<garyvdm> bialix: yes - would be nice to be able to use qviewer for unversioned files (like in qadd)
<dazjorz> jelmer: ah, yes! it syas Branch history: 4297 revisions, 838 days old; Repository: 5130 revisions
<dazjorz> says*
<david__> lifeless: the latest prebuilt version I could get working was 1.13
<dazjorz> jelmer: it does say, by the way, that the first revision was in 2007, while when I run svn log -r1 I see the first commit being in 2003
<lifeless> david__: if you at the apt url to your sources, you should be able to do apt-get update; apt-get install bzr and have it work
<david__> I need 1.16 +
<lifeless> david__: before we debug why building it is failing, I'd like to understand why the built version isn't working
<jelmer> dazjorz: But this particular branch was perhaps created in 2007 ?
<dazjorz> jelmer: my workout directory was changed in commits r1, r2, r6, r7, r8, all february 2003
<david__> lifeless: apt-get install 1.13 .. i am a little new to the deb way of doing things .. always been a redhat guy until recently so I am a little out of sorts with ubuntu
<dazjorz> jelmer: this is trunk :) from the repository root, it's /trunk/kmess
<david__> lifeless: its probably user error
<lifeless> david__: ok; try this then
<lifeless> as root, make a file /etc/apt/sources.list.d/bzr-ubuntu.list containing:
<lifeless> deb http://ppa.launchpad.net/bzr/ppa/ubuntu jaunty main
<lifeless> deb http://ppa.launchpad.net/subvertpy/ppa/ubuntu jaunty main
<lifeless> those two lines contain our upstream builds of bzr for ubuntu
<lifeless> oh, what version did you say you have of ubuntu ? 9.04?
<david__> yes
<SamB> hmm ... would it be extremely bad style to monkey-patch the traceback module to print variable bindings ?
<david__> 9.04
<lifeless> where it says jaunty, put intrepid, in those lines
<david__> I thought I had jaunty
<lifeless> 9.04 is intrepid
<david__> are you sure ?
<lifeless> lsb_release -a
<lifeless> what does that output
<david__> No LSB modules are available.
<david__> Distributor ID:	Ubuntu
<david__> Description:	Ubuntu 9.04
<david__> Release:	9.04
<david__> Codename:	jaunty
<david__> I think 8.x in intrepid
<lifeless> oh, man,
<lifeless> <- E NO MORNING CAFFEINE
<jelmer> abentley: hi
<abentley> jelmer: hi.  On a call.
<lifeless> ok, you have jaunty, and i comes before j
<david__> it happens .. thanks for your help .. so will this make apt-get install the newer version ?
<jelmer> abentley: ok
<lifeless> its one step of four to do that
<david__> oh
<SamB> why are you using apt-get?
<lifeless> the next step is to tell your system about the gpg keys that are used by these repositories
<SamB> get with the times -- aptitude is the thing ;-P
<dazjorz> jelmer: do you want me to report failing tests in "bzr selftest svn" or do you already know? :)
<jelmer> dazjorz: please report them
<david__> lifeless: how does that work
<lifeless> to do this,  run "sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys XXXXXXX" with the XXXXXX bit replaced by the key ids for the two repositories we listed
<lifeless> the key id is found on the web page - https://edge.launchpad.net/~subvertpy/+archive/ppa and https://edge.launchpad.net/~bzr/+archive/ppa
<lifeless> (take thy bit after the 1024R/
<dazjorz> jelmer: all three in one bug or one bug for every failure? :)
<dazjorz> correction, all six, up til now
<david__> lifeless: thanks thats done
<Kinnison> lifeless: has jelmer filed the interesting bug about stacked branches and ghosts?
<dazjorz> seven :)
<lifeless> david__: now, sudo apt-get update
<lifeless> this should complete without errors
<SamB> okay ... I want to MONKEY-PATCH the traceback MODULE!
<david__> it dfid
<david__> did
<lifeless> and you can then sudo apt-get install bzr
 * SamB is zippyizing that to attract attention
<david__> lifeless: perfect .. thank you so much
<jelmer> dazjorz: depends on the error message
<jelmer> dazjorz: what platform are you on?
<lifeless> david__: no problem
<dazjorz> jelmer: kubuntu karmic, normal linux (2.6.31), amd64, with bzr 1.17rc1 and python 2.6.2
<dazjorz> jelmer: after 1100 tests, I get 3 err, 2 fail, 2 xfail
<dazjorz> the err are all "delete() takes no keyword arguments"
<lifeless> Kinnison: I don't know
<lifeless> Kinnison: ask him :P
<Kinnison> jelmer: didja? huh? didja? :-)
<Kinnison> jelmer: I'm only bugging you so that it doesn't get forgotten and lost
<Kinnison> jelmer: esp. if it can be fixed before 2.0
<jelmer> Kinnison: No, I didn't yet.
<jelmer> lifeless: Actually, now that you're around
<jelmer> lifeless: Kinnison was getting NoSuchRevision errors trying to pull from a branch with ghosts into a branch stacked onto lp:launchpad
<lifeless> SamB: if you need more details, inspect is easy to work with
<lifeless> both in 2a format?
<jelmer> lifeless: it looked like the code path that dealt with pullling into a repository with fallback repositories didn't consider ghosts but assumed that everything that wasn't present was going to be brought in by the fetch.
<lifeless> jelmer: it deals with ghosts by looping
<lifeless> if it doesn't get every revisions, ce la vie; but if it misses texts or inventories the alarms go off
<jelmer> Kinnison: Do you still have the backtrace handy?
<Kinnison> nope, someone decided to unplug my machine overnight
<Kinnison> and the vmware stopped it suspending
<dazjorz> jelmer: I'll file them as one bug and if one of them requires more attention, I can re-file it or so.
<lifeless> Kinnison: ~/.bzr.log
 * Kinnison is remaking it
<Kinnison> please wait
<lifeless> also, in cases like this, feel free to just file a bug
<lifeless> we can mark as dup if it is
<Kinnison> nod.
<Kinnison> It's a dumb sequence of commands which triggers it
<lifeless> speaking of stuff over night
<Kinnison> rocketfuel-get decided that it was a good idea to use "bzr branch --no-tree --stacked /path/to/lp-branches/devel foo" and then "bzr pull --overwrite lp:...."
<jelmer> lifeless: I promised to file one when we looked at this together, including details, but then never got round to it
<lifeless> jelmer: did you see my proposed progress stuff for subunit?
<lifeless> Kinnison: thats uhm, an interesting choice
<Kinnison> lifeless: I have no idea why it did
<Kinnison> http://paste.debian.net/42539/
<Kinnison> there's an example
<jelmer> Kinnison: yeah
<jelmer> s/kinnison/lifeless/
<dazjorz> jelmer: http://bugs.launchpad.net/bzr-svn/+bug/403783
<ubottu> Ubuntu bug 403783 in bzr-svn "Failing selftest (2 failures, 3 errors, 2 known failures) on Kubuntu Karmic amd64, bzr 1.17rc1, python 2.6.2, bzr-svn 0.6.3-1" [Undecided,New]
<Kinnison> lifeless: is that enough for you to reproduce?
<lifeless> jelmer: what did you think of it? :)
<lifeless> Kinnison: its a dupe, but its an insane command anyway
<lifeless> Kinnison: its pulling cscvs on top of lp
<Kinnison> lifeless: blame rocketfuel-get
<lifeless> file a bug on that
<lifeless> or seek help in #launchpad-dev
<Kinnison> meh, I fixed it manually by branching them sanely
<Kinnison> I assume rocketfuel-update will just cd in and do bzr pull
<Kinnison> Mostly I only wanted to branch lp to take a look at how much of my crap was left in it :-)
<Kinnison> lifeless: what bug is it a dupe of, so I can subscribe to it?
<jelmer> lifeless: So
<jelmer> lifeless: I think the + / - bit is clever
<lifeless> 402778
<jelmer> lifeless: I'd like to be able to use this for Samba as well though, and wouldn't be able to do so in the current situation
<jelmer> lifeless: since samba uses testsuites and can only report the number of testsuites that will follow rather than the number of individual tests
<Kinnison> lifeless: ta
<jelmer> lifeless: It would be nice if the progress indication could take care of that somehow, but I haven't figured out how
<lifeless> jelmer: you should definitely reply to the list ;)
<jelmer> lifeless: perhaps by somehow indicating how long the rest of the test run will take compared to how long it's already been running?
<jelmer> lifeless: good point (-:
<lifeless> so, I did think about that
<lifeless> but I don't have great answers
<lifeless> one way you could do it is to placehold every remaining suite as being 1 test long
<lifeless> and issue +suitecount -1 as you move forward
<lifeless> the basic question is 'how do you do a global fraction with local data
<jelmer> the problem with placeholding every remaining suite as being 1 test long is that it makes it hard to e.g. give a sane progress bar
<jelmer> lifeless: perhaps we can allow a fraction as well as a number?
<lifeless> how does that avoid the global/local problem
<jelmer> lifeless: it allows the test runner to pick whether it'll report using global or local data
<lifeless> jelmer: so, say I run two separate test programs
<lifeless> how does the first know to adjust for the second
<lifeless> or if the tests are on multiple ec2 machines
<poolie> hello
<lifeless> jelmer: separately, by fractions, how would it work?
<lifeless> jelmer: would it essentially set an upper cap on the current set of tests?
<jelmer> re
<jelmer> (where did the coffee go ??)
<jelmer> lifeless: that wouldn't work - only the top-level test runner would be able to use this indication
<jelmer> at least, I can't think of a way to make this work properly with multiple test runners
<jelmer> you would have to have some way of identifying them to track their progress
<lifeless> right
<SamB> lifeless: oh, doing the monkeypatching will be the easy part ... the part I'm having trouble with is where to put the code to do the monkeypatching
<lifeless> so this is why I think it reduces to just global/local
<lifeless> jelmer: I think this is how I'd summarise it:
<lifeless> if you have a test runner with more info, it can output that info
<lifeless> knowing that there are 50 suites tells you little about the relative time of each suite
<SamB> I think I want to monkeypatch traceback.format_tb to do what I want ...
<lifeless> While it would be great to get an accurately scaled progress bar, I don't see how that can be done simply.
<lifeless> doing a stacked approach like bzr does allows hierarchical knowledge
<SamB> but can bzr display the stack of progress bars?
<jelmer> lifeless: atm we get a pretty good progress bar using the testsuites, mostly because the run time of the testsuites doesn't vary too wildly
<lifeless> which in a large subset of cases permits forward-only progress bars
<lifeless> SamB: nothing to do with bzr; and yes it can
<SamB> on the terminal?
<lifeless> SamB: or a gui
<SamB> why isn't it doing that, then?
<lifeless> SamB: it does.
<SamB> I only ever see one line of progress bars on *my* terminal
<lifeless> thats right
<lifeless> thats how we render the stack
<SamB> except when things screw up
<SamB> oh, I meant why not actually display all of the bars?
<SamB> or rather ... I wish it could be done
<SamB> but that needs termcap/terminfo etc.
<lifeless> indeed, it also needs more VWS
<SamB> VWS?
<lifeless> vertival space
<lifeless> erroneous W
<SamB> ah
<lifeless> so we render it collapsed onto one - the higher tasks take up a smaller fraction of the bar, constrained within the position of the next one down of the stack
<lifeless> anyhow
<lifeless> jelmer: so
<SamB> I don't expect that gets you very far down the stack often ...
<lifeless> SamB: you should experiment a little
<SamB> I mean, how many characters wide is the progress bar, usually?
<lifeless> bzrlib.ui.ui_factory.get_nested_progressbar()
<SamB> not that many!
<lifeless> doesn't need to be
<jelmer> lifeless: so
<lifeless> anyhow, I'm switching my conversation back. pop()
<SamB> oh ... anyway ...
<jelmer> lifeless: I think your proposal is definitely a step forward
<jelmer> lifeless: I might propose an extension in the future to make things easier for Samba
<lifeless> jelmer: my goals are: streams remain concatable; smarter code can do more than concat; runners with more data can do better.
#bzr 2009-07-24
<jelmer> lifeless: those are good goals
<jelmer> lifeless: and I think your existing proposal is in line with those goals, so +1
<lifeless> thanks.
<jelmer> lifeless: I'll keep thinking about a good way to have Samba use this, while not losing our existing progress bar functionality
<lifeless> I'm open to having a heirarchy
<lifeless> something like
<lifeless> progress: 5
<lifeless> progress_push:
<lifeless> <suite runs>
<lifeless> progress_pop:
<lifeless> progress_push:
<lifeless> <suite 2>
<lifeless> progress_pop:
 * emmajane waves from her flaky wifi connection at oscon
<lifeless> I think push/pop is a better idiom than fractions, because fractions require global knowledge in each stream
<lifeless> hi emmajane
<emmajane> lifeless: hey :)
<lifeless> emmajane: have you played with 2a formats yet?
 * jelmer waves back from a less flay wifi connection at debconf
<emmajane> lifeless: not yet.
<jelmer> lifeless: Yeah, that makes sense
<emmajane> jelmer: nice :)
<jelmer> lifeless: actually, push/pop seem to match start-testsuite/stop-testsuite pretty well :-)
<dazjorz> if I understand correctly, "bzr pull" is for when you want to keep two repositories *exactly* the same, and "bzr merge" is when you want to get your changes from a master repository into your local repository?
<dazjorz> (which has been modified)
<jelmer> dazjorz: basically, yeah
<dazjorz> nice, I like bzr's syntax :O
<dazjorz> and its integration with svn is one of the best surprises I've had in a while :P
<poolie> hi emmajane
<emmajane> poolie: hey :)
<emmajane> poolie: I got your email and that looks fine. I need to get a real mail client so that i can do offline email. gmail != win.
<dazjorz> emmajane: gmail == win, just configure your client to do imap :p
<poolie> emmajane, i got an HTC Magic android recently and it does gmail on flakey connections very well
<poolie> and also imap
<emmajane> nice!
<emmajane> Clearly I just need better toys. :)
<emmajane> dazjorz: I'm just doing browser-based email right now. I installed ubuntu about 12 hours before I left onto my netbook and forgot things like a useful mail client (sorry evolution)
<lifeless> evolution needs some
<emmajane> I'm even using pidgin for irc. It feels so... wrong.
<poolie> it's a shame, 12h would have been about enough time for evolution to sync too :)
<emmajane> LOL
<fullermd> mutt's worked fine for the last 11 years or so   :p
 * dazjorz uses Quassel for IRC, Thunderbird for e-mail
<emmajane> fullermd: I have too many family members who insist on HTML email and clients that want to send attachments.
<emmajane> fullermd: I used mutt for years with righteous indignation though.
<fullermd> Nothing a little tasering can't cure...
 * emmajane chuckles.
<emmajane> I'll be sure to let them know.
<emmajane> my main computer has Kontact and Xchat-gnome.
<lifeless> poolie: I fixed that bug :P
<poolie> lifeless: i was thinking last night about reconfigure
<lifeless> dangerous times
<lifeless> how was the talk?
<poolie> "lifeless is right, writing code really is easier than thinking
<poolie> or more specifically, easier than talking about it in advance"
<poolie> sometimes.
<poolie> the talks were ok
<poolie> jml's was good but not new to me
<poolie> the other one, about ocamlp4 was, well, ok
<poolie> summary is that you can use macros to let you write your program in more amenable syntax
<poolie> ... even in ocaml
<emmajane> poolie: are you at debconf too?
<poolie> nup, that was fp-syd, the sydney functional programming seminar
 * emmajane nods
<lifeless> poolie: so, reconfigure was easier to do that think about ?
<poolie> yep
<poolie> well, easier to do this specific case than to describe the general one
<poolie> i think there is some kind of general lesson here but
<poolie> one step at a time
<lifeless> :)
<jelmer> hmm, I guess I should start doing reviews on lp:bzr now ... :-)
<lifeless> jelmer: yes indeed
<jelmer> abentley: any chance you could remove bzr-gtk, bzr-stats and trac-bzr from bb ?
<jelmer> abentley: (we discussed switching bzr-gtk to lp during UDS, and the other two projects already are using lp rather than bb in practice)
<jelmer> abentley: there's one open merge request in bzr-gtk atm which I can migrate manually if necessary
<abentley> jelmer: Hmm.  I'm sure there's a way, but I don't have code that actually *deletes* projects rather than adding them.
<jelmer> abentley: ah, ok
<jelmer> abentley: We can just point out lp to people who use bb I guess
<abentley> jelmer: I'll do it, but I can't do it immediately.
<jelmer> abentley: thanks, no hurry
<dazjorz> jelmer: for bzr-svn, does "bzr commit" push the patch forward to the SVN repository already?
<jelmer> dazjorz: in a checkout, yes
<dazjorz> jelmer: can I tell it to keep the changes local until I run bzr push, or something like that? :)
<jelmer> dazjorz: you can keep the changes local if you use a standalone branch
<jelmer> dazjorz: this works in the same way as it would for "native" bzr branhces
<dazjorz> I see
<dazjorz> can I make a standalone branch of an SVN repository, and alternatively, can I make a standalone branch as a copy of this dual-bzr-svn-checkout I already have? :)
<jelmer> dazjorz: yes
<dazjorz> jelmer: oooh, this seems to be a bug...
<dazjorz> jelmer: I ran "bzr commit", and in a different window, I edited another previously not modified file
<jelmer> dazjorz: ?
<dazjorz> the ChangeLog
<poolie> spiv, shall we meet up today?
<dazjorz> then the commit went through, but it didn't send in ChangeLog; now, ChangeLog has its new contents but both bzr and svn say it's up-to-date with the repository when it actually isn't
<jelmer> dazjorz: ah, this is a svn lightweight checkout?
<spiv> poolie: good morning,
<jelmer> dazjorz: if you can reproduce this, please file a bug (including the steps to reproduce)
<dazjorz> jelmer: I think so, I just ran "bzr status" in my SVN checkout
<lifeless> poolie: You still have a chinese lunch scheduled with me ;P
<dazjorz> jelmer: I'll do that
<dazjorz> jelmer: I'll file it tomorrow :)
<spiv> poolie: sounds good.  First I'll call.
<emmajane> talk time. woo! :)
 * emmajane turns off her flaky wireless.
<jelmer> dazjorz: thanks
<poolie> beuno: hi?
<lifeless> poolie: were we going to do that lunch we talked about last week?
<poolie> ah, ok
<poolie> i'm double booked, can we push that back again
<lifeless> lol sure
<lifeless> spiv: have you seen the bugs about pulling cross format?
<lifeless> spiv: I think your new one is a dupe
<spiv> lifeless: quite possibly, none of them jumped out at me as the one obvious dupe though so I figured I'd file and let someone more knowledgeable dupe it if so.
<spiv> And the test patch may be useful.
<lifeless> spiv: ack
<lifeless> spiv: look at bugs by newest first
<lifeless> I targeted one against 2.0 this morning
<spiv> lifeless: "NoSuchRevision error when branching with rocketfuel-get"?  (402778)
<spiv> Could well be.
<spiv> Or "upgrading branch on launchpad to 2a resulted in missing revision error" (399140)?
<lifeless> spiv: 402778 specifically
<lifeless> possible 399140 as well, mtaylors upgrade bug
<spiv> lifeless: well, it's not clear to me that they are dupes.  If you're sure then of course go ahead, but I'm not planning to dig deeper into that today.
<lifeless> spiv: I'm not 100%
<lifeless> spiv: I suggest your new bug be 2.0 targeted though
<spiv> Fair enough.
<igc> morning
<spiv> igc: g'morning.
<igc> hi spiv!
<RenatoSilva> How can CVS be just cvs.exe with ~700KB and Bazaar ~54MB (without plugins)?
<RenatoSilva> ok remove 17,5MB for python's dll and library
<RenatoSilva> It is 36,5MB yet!
<RenatoSilva> it seems that it's not strictly because of bazaar itself, but secondary stuff like qt gui, etc...
<lifeless> and docs
<lifeless> are you talking about a windows binary install?
<RenatoSilva> yes
<RenatoSilva> other ones too
<lifeless> we bundle everything
<RenatoSilva> I just need to get the essential files
<RenatoSilva> compared to cvs.exe
<lifeless> the core (source, docs, tests) is 18MB uncompressed
<RenatoSilva> docs are not essential
<RenatoSilva> cvs.exe does not contain such docs
<lifeless> and if you compress it, 4.6MB
<RenatoSilva> just the part whcih would just work,, I mean
<lifeless> well, this is true
<RenatoSilva> just bzr.exe + python files
<RenatoSilva> but I don't know if any other files are needed
<RenatoSilva> dlls etc
<lifeless> however, its our experience that the more things to download, and options about it, the easier it is for users to download the wrong thing
<lifeless> so we just provide a single package with it all, to make it as likely to work as possible.
<RenatoSilva> I just want to compare the size of cvs.exe with {bzr essential files}
<lifeless> why though?
<lifeless> its not like they do the same thing...
<RenatoSilva> it's noteworthy you can have a full-featured cvs environment with just a ~700kb executable :)
<lifeless> I can have a full featured OS with a 1.44MB floppy too, but that doesn't make it useful or even desirable
<lifeless> where full featured, means 'very well defined and not extensible or robust'
<lifeless> :)
<dazjorz> hm, how did kernels ever fit on a 1.44 mb floppy
<dazjorz> they supported nothing?
<dazjorz> my current Mach kernel is 10 mb
<dazjorz> all vmlinuz kernels on my Linux machine are at least 3.6 mb :P
<dazjorz> just *everything* compiled out or so? :)
<lifeless> dazjorz: I remember one particular microkernel unix which had a GUI web browser, web server, generic PCI networking and disk, all on a floppy
<dazjorz> whoa nice
<lifeless> damned if I can remember the name though
<dazjorz> even damn small linux is 50 mb now
<lifeless> anyhow, for embedding you use things like busybox, strip docs, man pages, compile with -Os, compress heavily
<lifeless> RenatoSilva: I don't mean to say that wanting bzr to be small is bad; its a good thing to want
<lifeless> RenatoSilva: but comparing the size of two hugely different tools with wildly different capabilities, written in totally different languages, isn't a meaningful comparison
<lifeless> RenatoSilva: it can be summarised as 'compiled C is smaller than python'
<RenatoSilva> lifeless: well, it is more about the cvs size
<lifeless> RenatoSilva: that its small? Its mainly small because it doesn't do much. Try 'cvs push'. or
<lifeless> 'cvs uncommit'
<RenatoSilva> lifeless: we like it or not, bzr x cvs is more about vcs x dvcs than any super feature of bzr missing in cvs, or than cvs sucks absolutely and does not work
<RenatoSilva> lifeless: maybe as I become more familiar with both tools I can get the complexity involved in a dvcs or in bzr
<RenatoSilva> lifeless: actually I'm not that impressed with bzr size, but with CVS
<RenatoSilva> lifeless: we can do more or less the same sort of work we do with bzr
<AfC> lifeless: lost cause, Robert.
<RenatoSilva> lifeless: I was considering adopting bzr at work, but cvs is enougth for us. At least, it does the basic job. A possible argument would be the leak of atomic commits in CVS, however Eclipse does magic. We just need to define ourselves 2 points of comparison (tags, branches or dates), and the result is the same as viewing a revision in bzr: you see a list of modified files, each one with the changes made.
<lifeless> RenatoSilva: We'll be here when you're ready :)
<lifeless> RenatoSilva: Its a shame that bzr isn't doing what you need (and I'm really not clear what that is, download size surely can't be it...
<lifeless> not if you're using eclipse!
<RenatoSilva> I'm just thinking of tracking each commit. Currently we'd have to create a tag for each commit, which is a bit non-sense. I've heard cvs 1.12 has commit-ids which would make it possible to emulate atomic commits, but I don't know if Eclipse supports it
<lifeless> RenatoSilva: CVS is essentially dead
<lifeless> RenatoSilva: I really wouldn't hold out any hope for improvements in it, or support for it.
<lifeless> if you could make sure bugs are filed for the things that make bzr not comfortable for you, I'd appreciate that.
<RenatoSilva> lifeless: if we started from nothing, bzr or another modern vcs like git or hg would certaintly be my option. The problem is that we have all of our code base under cvs. It would need a migration _effort_, including training to the whole team. Also, Eclipse's CVS support is _very_ mature (Eclipse itself uses CVS), while BzrEclipse is still in beta (ok I solved some bugs and I could help the project more, but CVS in Eclipse is far more mature and does magic
<lifeless> RenatoSilva: Yes, migrating does take investment
<RenatoSilva> CVS is not dead. I don't like these flamewars. When I go to #cvs, they say the contrary, and that some dvcs (git I guess) is not a vcs, but just a patching system
<lifeless> ;)
<lifeless> they may mean darcs, which is very patch focused
<AfC> RenatoSilva: admittedly, you are in the Bazaar hackers' IRC channel, so you need to expect a certain bias. The people here aren't in the business of fixing CVS.
<RenatoSilva> certaintly it is git, bzr or hg. Can't recall
<RenatoSilva> AfC: bias?
<lifeless> preconceptions
<RenatoSilva> I think that's really really bad
<RenatoSilva> we are technicall people
<lifeless> Yup. And I've spent the last 10 years working on/with/around VCS systems
<RenatoSilva> we shouldn't be sfanatic I think
<AfC> RenatoSilva: Yes, but this is the Bazaar IRC channel, not the "let's all just chat about what CVS isn't good at" channel. We had that conversation 15 years ago.
<lifeless> including CVS - written a python implementation of the protocol (nods to Kinnison who did a chunk of that too)
<lifeless> *I* am not being fanatic. I did consider fixing CVS at one point. Why I didn't go down that path is a fascinating dicussion, but not one to have right now.
<lifeless> bzr isn't perfect
<lifeless> theres lots of things we haven't got right; and many things we have.
<lifeless> anyhow, I'm *primarily* interested in knowing what does and doesn't work for you with bzr
<lifeless> because that helps us make bzr better than it is
<tethridge> I'm trying to get loggerhead setup on a hardy system.  I've ran through the instructions and I'm able to start it, but it dies immediately.  Nothing in the logs.  Anybody know what is going on?
<lifeless> tethridge: when you say dies, what do you mean?
<lifeless> and how are you starting it?
<tethridge> no process
<tethridge> the pid is created and then it disappears
<lifeless> there is no output at all?
<tethridge> I'm just trying to use the start-server script to verify it works before I setup the script in init.d
<RenatoSilva> I do agree that bzr/git/hg/dvcs is so much better than CVS, I just don't think that CVS sucks completely. We can live with it and that's what matters for me. These software 'gangs' are so prejudicial to the sofwtare world ihmo.
<tethridge> no,
<tethridge> strange
<lifeless> tethridge: serve-branches, or bzr serve --http, are the current ways to start loggerhead
<tethridge> it tells me "Launching loggerhead into the background" and it tells me the location of the pid file, but that is it
<tethridge> this is the 1.10 release
<lifeless> RenatoSilva: I think you've taken me saying 'essentially dead' and turned it into a much larger statement than I meant to make.
<lifeless> RenatoSilva: I didn't say, nor did I mean to imply, that CVS sucks
<RenatoSilva> lifeless: I think you're more open than them actually
<spm> tethridge: suggest strace'ing the startup and seeing if anything obviously broken leaps out
<lifeless> RenatoSilva: what can I do to help you at the moment?
<tethridge> using serve-branches starts it and keeps it going
<RenatoSilva> lifeless: sorry, I was just talking
<lifeless> RenatoSilva: nothing to apologise for
<lifeless> I'm going to go put my head down and get some complex stuff sorted out
<lifeless> later y'all
<tethridge> thanks for the help
 * igc lunch
<cogita> hello all.  I have a question.  According to StackOverflow
<cogita> (http://stackoverflow.com/questions/97850/version-control-on-a-2gb-usb-drive)
<cogita>  its posible to install Bazaar on a USB drive using portable Python as the python framework.
<cogita> I was wondering if there was anyone who could tell me which version of Portable python to use, and how to install Bazaar correctly for this solution?
<dazjorz> hmmm
<dazjorz> bzr push in my bazaar repository checked out from svn, says "no push location known or specified"
<dazjorz> shouldn't it have remembered that when I checked out from svn? :)
<poolie1> dazjorz: is it a checkout or a separate branch?
<poolie1> if it's a checkout, you don't need to push, committing will implicitly do it
<dazjorz> ugh, netsplits
<dazjorz> poolie1: it's a seperate branch
<spiv> Huh, test_branch_from_trivial_stacked_branch_streaming_acceptance in blackbox tests blows up if you change it to use a 2a branch.
<poolie1> bzr doesn't assume that you want to push back on top of the parent
<dazjorz> ah, and then "bzr pull" / "bzr up" didn't tell me there were new svn revisions to merge, but bzr merge handled them nicely
<dazjorz> I figured it would be something like that :)
<dazjorz> hmmm
<dazjorz> okay so now I have a merge conflict between a committed revision on my checkout, and a pulled/merged revision from SVN
<dazjorz> when I run bzr status, I see "pending merge tips:", then the remote revision which made for a conflict in Changelog which I already resolved (bzr resolved ChangeLog after editing it)
<dazjorz> so what now? :/
<dazjorz> running "bzr merge" again makes the conflict reappear
<dazjorz> any ideas? poolie1 maybe?
<lifeless> you need to commit
<lifeless> the sequence for merge is:
<lifeless> merge; resolve if needed; commit
<dazjorz> even if bzr diff shows no differences atm?
<lifeless> if 'bzr st' shows anything
<lifeless> such as a pending merge
<lifeless> or  altered files
<dazjorz> okay
 * dazjorz wonders how that will show up on SVN
<lifeless> well without the commit it can't show up on svn :)
<dazjorz> so, lifeless, what exactly am I committing when I commit now? a sign to bzr that says "merges nicely against that and that remote revision" ?
<lifeless> yes
<lifeless> if you don't want to make that record, you can 'bzr revert'
<dazjorz> hm okay
<lifeless> to get rid of the pending merge
<lifeless> but it sounds like *it does not merge cleanly*
<dazjorz> that will revert the commit I already made, right?
<lifeless> so in fact, you're recording what it should look like when merged.
<lifeless> no, revert doesn't get rid of commits
<lifeless> uncommit gets rid of commits
<dazjorz> lifeless: so if I already did the merge itself and everything is resolved, if I run bzr revert now I have to do that again when I run bzr merge, but when I bzr commit I actually get, from the outside, an "empty" commit that just makes for a better merge against that remote revision?
<dazjorz> oh shi-
<lifeless> I have no idea what you just said
<lifeless> perhaps you should start from the beginning :)
<dazjorz> 1) I made a bzr branch from a SVN checkout
<dazjorz> 2) while I was editing, the SVN checkout got another commit that changed the ChangeLog
<dazjorz> 3) I ran 'bzr commit' on my changes, but when I wanted to push, it said I had to merge
<dazjorz> 4) I ran 'bzr merge', and got a conflict on ChangeLog
<lifeless> is there a 5?
<dazjorz> 5) I resolved the conflict and I'm trying to figure out what to do next
<lifeless> commit
<lifeless> until you do this commit the merge isn't saved
<dazjorz> okay oh well
<dazjorz> we'll just see how it looks in svn :p
<lifeless> bzr diff should be showing you the contents of the change made to svn in 2)
<lifeless> if bzr diff *isn't* showing you that contents, then you've actually done something else in the middle, that you've forgotten about
<dazjorz> it showed me nothing
<fullermd> A perhaps better solution would have been to go the other way, and use the svn checkout to gate changes in/out of svn.
<lifeless> did you perhaps run 'bzr revert .' ?
<spiv> Hmm, "bzr commit" on a fresh stacked 2a repository looks like it can make a repo that fails without the fallback present.
<dazjorz> lifeless: for the life of me, I don't know that command, so I didn't run it, no :P
<lifeless> dazjorz: ok, do this for me
<lifeless> 'bzr revert'
<lifeless> 'bzr st'
<lifeless> (should show nothing)
<lifeless> 'bzr merge' - should conflict again
<dazjorz> btw, I just committed the empty revision 4300 and bzr commit said, under the line "this line and those below won't appear", that there was a pending merge, and just that
<dazjorz> nothing else
<dazjorz> oh
<lifeless> 'bzr diff' - should show the changes made to svn in 2), as well as the conflicts you had
<lifeless> dazjorz: ok, lets roll it back
<lifeless> 'bzr uncommit'
<dazjorz> want me to uncommit it? :)
<lifeless> that will pop off your commit
<dazjorz> do I need to add 4300 or will it default to the last local commit? :)
<lifeless> 'bzr revert' - that will discard any changes that were in the commit
<lifeless> run what I put between the ' ' ;)
<dazjorz> okay, done
<lifeless> 'bzr st' - should show nothing
<dazjorz> it shows nothing
<lifeless> 'bzr merge' - should conflict
<dazjorz> yep
<dazjorz> 1 conflict in ChangeLog
<lifeless> bzr st
<lifeless> sorry, 'bzr st' - that should list the changes made to svn
<lifeless> including ChangeLog
<dazjorz> I see modified ChangeLog, unknown ChangeLog.{BASE,OTHER,THIS], conflicts: Text conflict in ChangeLog
<lifeless> sounds like the only changes made to svn were to ChangeLog :)
<dazjorz> and a pending merge tip, dazjorz 2009-07-23 [log message for the SVN commit]
<dazjorz> lifeless: yep, in that commit, the only change was the ChangeLog
<lifeless> ok good
<lifeless> edit the ChangeLog and resolve the conflict
<lifeless> then run 'bzr resolve'
<dazjorz> done
<lifeless> and 'bzr diff' should show you the change still, but no long conflicted with <<<< markers
<dazjorz> bzr diff shows no output
<lifeless> so , when you resolve, you're just deleting the svn changes?
<dazjorz> note that I already locally committed (not pushed) the change that conflicted with the SVN revision
<lifeless> ah
<lifeless> ok, *thats* why you're seeing no difference
<dazjorz> lifeless: no - the thing is, my commit made the same changes to ChangeLog, plus one extra line, which is in that committed commit ;)
<lifeless> 'bzr commit'
<dazjorz> lifeless: vim shows me "----- This line and the folowing will be ignored ------" and below that one pending merge, the SVN revision
<dazjorz> is that all ok ? :)
<lifeless> yes
<lifeless> here is whats happening
<lifeless> you're getting a false conflict; we're conflicting where it would be better if we didn't
<lifeless> once you resolve it you have no textual differences.
<lifeless> the commit says 'the way to resolve this conflict is to use this new version of ChangeLog', which happens to be the same as you already had.
<lifeless> in general it would be different.
<dazjorz> ah, okay
<dazjorz> so the actual SVN commit, in a second, will have an empty diff, since it doesn't really change anything
<dazjorz> since SVN doesn't have all that additional DVCS merging cargo for each commit or so? :)
<dazjorz> okay so I have a commit 4299 with some changes to source plus some changes to ChangeLog, and commit 4300 which is actually empty
<dazjorz> going to push now...
<lifeless> The SVN commit will have an extra line, according to what you told me
<dazjorz> o_O
<dazjorz> bzr: ERROR: Operation denied because it would change the mainline history
<lifeless> jelmer: ^
<dazjorz> et the append_revisions_only setting to False on branch "https://kmess.svn.sourceforge.net/svnroot/kmess/trunk/kmess" to allow the mainline to change.
<lifeless> svn has this set always
<dazjorz> aw shit, am I really this bad? :P
<lifeless> its a bit odd to tell you that warning
<dazjorz> of course, svn most probably doesn't allow you to change earlier commits
<lifeless> right
<lifeless> so if I can make a couple of small suggestions
<dazjorz> 1) throw out your SVN repository
<dazjorz> 2) ???
<lifeless> you can either 'bzr dpush' at this point, to push into svn
<dazjorz> 3) profit
<lifeless> this does a local rewrite-of-history to make it fit what svn thinks happened
<lifeless> this is fine, unless you're sharing your branch with other people. (Its the same as rebase, basically)
<dazjorz> I'm not, so that's ok
<lifeless> alternatively, and this is the way I'd tend to do it.
<dazjorz> (why would it be a problem if I am sharing it with other people? because it invalidates their cache of my branch or so?)
<lifeless> handwaving, yes.
<lifeless> it creates new uuids for all the history that you're pushing
<lifeless> anyhow, the way I would do it is to have two branches
<lifeless> one that is a /checkout/ of svn
<dazjorz> does it push all commits as one commit or does it still have two seperate commits?
<lifeless> (bzr checkout https://kmess.svn.sourceforge.net/svnroot/kmess/trunk/kmess trunk)
<lifeless> and then your other branch that you work on offline and so on
<lifeless> to land something in svn
<lifeless> cd trunk
<lifeless> bzr update
<lifeless> bzr merge ../your-branch
<lifeless> bzr commit
<lifeless> that reflects what svn is limited to
<lifeless> and is standard for doing centralised management of a branch with bzr
<dazjorz> maybe I'll put that bzr checkout repository on a remote server, and push my changes there
<dazjorz> and have it automatically sync with SVN and vice-versa
<lifeless> if you push to it, it won't work
<lifeless> because push is a mirror operation, it will stop it corrsponding 1:1 with svn
<lifeless> which is the point of using checkout + update
<lifeless> rather than branch + merge
<dazjorz> yeah
<lifeless> now, if your branch is small this will perform just fine out of the box
<lifeless> if its a large tree theres a couple of small steps to give you a single working tree and use switch to switch between the trunk checkout and your feature branches
<dazjorz> may I ask you for some advise -
<lifeless> of course
<dazjorz> the reason I'm playing with DVCS integration with SVN, is that I'm going on a holiday this sunday, and I'm going to work on the project there, too
<dazjorz> most probably
<lifeless> cool
<dazjorz> however - it's going to be offline and I still want to commit now and then
<lifeless> yup, your own branch for that is a good idea
<dazjorz> previously, that was a pain, since I had to sum up all my commits, or commit one large change and suffer some hours of manual merging to get it right again
<dazjorz> so what do you recommend me to do - make a bzr checkout, and then make a seperate bzr branch where I merge and commit to, and every time I get internet access I bzr update the checkout, bzr push my changes to that checkout, then bzr push the changes from the checkout back to svn?
<lifeless> nearly
<lifeless> a complete recipe would be:
<lifeless> bzr checkout <svn> trunk
<lifeless> bzr branch feature1
<lifeless> hack in feature 1
<lifeless> when online:
<lifeless> cd trunk
<lifeless> bzr update
<lifeless> bzr merge ../feature1
<lifeless> bzr commit -m "Current stuff -> SVN"
<lifeless> cd ../feature1
<lifeless> bzr pull ../trunk
<lifeless> --fin--
<dazjorz> that seems to make perfect sense
<dazjorz> one thing: that will make all my changes one single commit to SVN, or won't it?
<dazjorz> except, of course, when I make a branch for every group of changes I make
<lifeless> right
<lifeless> you can have as many features as you want
<dazjorz> and the exact branch command is, if ./trunk is the bzr svn checkout, bzr branch trunk feature1 ?
<lifeless> yup
<dazjorz> nice
<lifeless> try it now :)
<dazjorz> I was about to, just need to get bzr-svn installed on my macbook :)
 * dazjorz will package it to Fink, too
<dazjorz> what is the system-wide alternative to ~/.bazaar/plugins if there is one?
<dazjorz> ah, must be bzrlib/plugins/svn
<dazjorz> uh, bzrlib/plugins
<lifeless> yes
<lifeless> setup.py in the plugin should install it there for you
<spiv> "Ideally chroot transports would know enough to cause the external url to be the exact one used that caused the chrooting in the first place, but that is not currently the case.
<spiv> "
 * mwhudson lacks context but agrees
<spiv> What does that sentence in Transport.external_url's docstring mean?
<mwhudson> admittedly i don't know why it's not true
<spiv> I guess I'm not sure exactly what "the exact one used that caused the chrooting in the first place" means.
<lifeless> spiv: Neither am I
<spiv> (urls don't kill people^W^Wchroot, code kills people^W^Wchroots...)
<lifeless> but I would guess at 'the original url'
<lifeless> or something
<spiv> Yeah, that's my guess too.  I was hoping to avoid guesswork, but I guess I'll cope :)
<spiv> It seems like a bit of a non-sequitur for that docstring.
<poolie1> spiv i think it means the real absolute url
<poolie1> but i don't think i wrote it
<poolie1> (igc) i'm reading https://code.edge.launchpad.net/~bzr/bzr/smooth-upgrades/+merge/8921
<igc> poolie1: thanks
<jetole> can anyone tell me if there is a way to do a push on commit?
<poolie1> jetole: if you use a checkout, committing implicitly synchronously pushes
<jetole> hmm, I used branch but checkout sounds familiar from my limited history with svn
<jetole> I will delete the dir and do a checkout
<jetole> yep
<jetole> checkout did it when I commited
<jetole> poolie1: I am recreating the branch
<poolie1> jetole: you could have also just used 'bzr bind' :)
<jetole> do I need to do an initial push or is there a way I can specify the master in commit or some other way I should do thi
<jetole> *this
 * jetole reads bind
<jetole> poolie1: what is the proper way to initiate a master?
<jetole> should I push then bind?
<fullermd> There isn't a "master" per se.  Commit goes to what you checked out from.
<jetole> fullermd: I haven't checked out. I deleted the local repo and the repo on launchpad and then recreated the dir, copied the source back in and did a bzr init, now I know I can do a push to launchpad
<jetole> but I am wondering if that is how I should go, push then bind?
<lifeless> that will be fine
<jetole> ok
<jetole> also fullermd, bzr help bind => "...commits must succeed on the master branch..."
 * fullermd adds a bit of documentation to add to his list to take out behind the shed and beat the crap out of.
<jetole> lol
<jetole> also how come the only valid launchpad url starts with +junk for me?
<poolie1> they must have either a project name or +junk
<poolie1> do you want to work on an existing or new project?
<jetole> new project
<jetole> btw, although this is probably rather implied, I am a complete bzr newbie and been months to a year since I used svn
<fullermd> Well, you should be well on the road to recovery then   8-}
<jetole> heh
<poolie1> igc: done
<poolie1> jetole: https://help.launchpad.net/Projects/Registering
<poolie1> lifeless: want to merge your check-1 branch, it's reportedly approved...
<poolie1> lifeless: also, it looks like your review of https://code.edge.launchpad.net/~garyvdm/bzr/register_lazy_decorated/+merge/8430 is conclusive
<poolie1> therefore it needs to be resubmitted, not reviewed by anyone else
<poolie1> if that's true, mark it so?
<poolie1> otherwise i'll read it if desired
<lifeless> poolie1: check - yes, i should
<lifeless> gary's branch I don't recall offhand
<lifeless> I don't think I read the entire thing, just bits based on other peoples reviews.
<lifeless> igc: did you see my comment on mp 8921 about --pack being unneeded
<lifeless> (and infact a bug, as it will cause double packs)
<igc> lifeless: yes, I saw it
<lifeless> kk
<lifeless> EOD
<lifeless> closing in on this
<dazjorz> btw -
<dazjorz> I got bzr-svn working nicely on Fink (os x), and I'll package it sometime soon :)
<dazjorz> along with subvertpy :)
<verterok> Hi! any OSX 10.5 user around willing to help test the 1.17 DMG?
 * verterok just got working a semi automated build script for 10.4 and 10.5 (still needs a some love, but works!)
 * spiv is off
<spiv> Have a good weekend, all!
<dazjorz> lifeless: seems to work perfectly, the commands you gave me - thanks a lot :)
<igc> poolie: any chance of a *quick* call?
 * igc dinner
<jelmer> moin
<LarstiQ> morning
<ronny> jelmer: for dulwich, ever tought of using binascii.hexlify/unhexlify for converting digests and hexdigests?
<jelmer> ronny: not until now :-)
<ronny> hmm, git trees  have bad parsing properties
<ronny> zero terminated strings in quasi-binary file formats
<jelmer> ronny: Thanks for pointing that out, it seems like a good alternative to our own custom implementations
<ronny> jelmer: are trees basically matching r"((?P<mode>[0-7]+) (?P<name>[^\0]+)\0(?P<digests>.{20}))+" ?
<jelmer> ronny: generally, yeah
<jelmer> ronny: (any reason for parsing manually btw, rather than through dulwich?)
<ronny> jelmer: just diging around in dulwich, trying to figure if there are good way to implement it without c
<jelmer> ronny: ah
<ronny> jelmer: going to implement history listing for anyvc soon
<jelmer> ronny: implement it without C and perform well you mean :-)
<ronny> jelmer: perform well == good
<jelmer> ronny: heh, ok
<ronny> i wonder how re.findall compares to your parser
<jelmer> only one way to find out (-:
<jelmer> I'm pretty sure my parser will be faster than re.findall
<jelmer> Not sure whether the difference will be significant enough to really matter though
<ronny> jelmer: re.findall is 3 times slower, and dosnt yet convert the data propperly
<jelmer> ronny: and in comparison to the existing python implementation?
<ronny> mom
<ronny> jelmer: got sidetracked, will try to get it tested the next hour
<jelmer> ronny: *nod*
<ronny> jelmer: ok, compiledre.findall seems to be ~9 times faster than the parser in python, however it doesnt yet convert the data
<jelmer> details, details, .. :-P
<ronny> so i hope ~7-8 times the speed is possible
<dazjorz> hmmm
<dazjorz> jelmer: I just ran bzr up on a checkout created by bzr checkout http://..[svn repository]
<dazjorz> uh, bzr merge, even
<dazjorz> and the remote changes were added as changes to my local checkout
<dazjorz> hm, wait, I talked about this with lifeless earlier, he said I had to recommit it
<ronny> jelmer: ok, re.findall in naive use + correct converting is about 6 times faster than the normal python implementation, and about 3,7 times  slower than the c implementation
<ronny> jelmer: i think the time loss can be accounted in the python loops
<jelmer> ronny: cool
<ronny> jelmer: i wonder if it can be done more efficient tho
<jelmer> ronny: without C extensions? I think it's hard
<jelmer> ronny: depending on the application it might also not matter very much
<ronny> jelmer: im im still hoping to get in a range of half the speed of the current c implementation
<jelmer> ronny: for bzr-git we have to access and parse every single tree when fetching data but generally this is not the case
<ronny> (better loop, smarter regex)
<jelmer> ronny: for anyvc I would imagine this isn't particularly performance-critical - being able to look up objects in packs and resolve deltas would be much more important I think
<ronny> yes
<ronny> i'll take a look at that, to
<ronny> hmm, and i need to implement the "pythonic fs apis" on top of the vcs's
<ronny> next week will be much fun
<ronny> generating + reading linear history for all vcs, generating dags of history for the dvcs's and figuring a mapping for svn
<homy> What is a "rich root" format? It is used in loads of places in the documentation, but I couldn't find its explanation anywhere.
<ronny> homy: the difference is in the amount of places where metadata may be, basically all newer formats are rich, any you never ever want a non-rich one
<jelmer> igc: hi
<maxb> Does bzr have an option for pointing at a branch which is not the current directory?
<homy> ronny: thanks.
<maxb> i.e. bzr --something foo revno, instead of cd foo; bzr revno; cd ..
<dazjorz> ewww
<dazjorz> jelmer: there?
<dazjorz> or lifeless
<dazjorz> this could possibly be seen as a bzr-svn bug
<dazjorz> same problem as yesterday: a conflict is preventing me from being able to push back a revision to SVN
<dazjorz> in other words: I merged, got a conflict, solved it and committed it to my local branch, but bzr is trying to commit that merge fix back to svn
<dazjorz> expected behaviour: it sees that that commit only merged a svn commit locally, and doesn't try to edit the commit at svn because it knows it won't work
<dazjorz> real behaviour: bzr says "you're asking me to change commit history, but I'm not allowed to do that here" (note how it doesn't even say "I can't do that here")
<dazjorz> "operation denied because it would change the mainline history, set [...] to false on branch [...] to allow the mainline to change"
<igc> hi jelmer
<jelmer> dazjorz: hi
<dazjorz> hey
<jelmer> dazjorz: I'm not sure I understand what the problem is exactly
<dazjorz> the problem is that, after I run bzr merge on a bzr checkout of a svn repository and I get some conflicts, and resolve them then commit, I can't push anymore
<dazjorz> I get the error under "real behaviour" instead of the behaviour under "expected behaviour"
<dazjorz> do you think that could be fixed? :)
<LarstiQ> maxb: `bzr revno [LOCATION]` from `bzr help revno`
<jelmer> dazjorz: that's correct behaviour
<jelmer> dazjorz: the operation you did would change the mainliune in svn
<jelmer> since you probably don
<jelmer> t want that bzr-svn requires you to set an option before you can do so
<dazjorz> jelmer: I don't want it, but it's not even possible, I'd say, so how does it work when you indeed set that option
<dazjorz> also
<dazjorz> jelmer: behaviour may be correct - but it would be more "natural" for bzr-svn to handle that situation gracefully and understand that commit doesn't *have* to be changed in SVN history, since it's the same one, just a local merge :)
<jelmer> dazjorz: it would not require that option to be set previously and that's gotten people upset (because it did change their svn mainline while they weren't expecting it)
<jelmer> dazjorz: the merge changed the mainline
<jelmer> dazjorz: e.g. see "bzr log -n1" and compare that to the current revisions in your svn branch
<dazjorz> jelmer: well, I don't want to change my svn mainline, but I do want to tell bzr to just not push that commit since it's already there, and stop acting up and just do what I ask it: push the rest of my commits
<dazjorz> jelmer: is it possible to make an option to just ignore changes to the mainline instead of failing to do everything?
<dazjorz> failing the complete push operation because it's not allowed to merge that one commit in that I don't even *want* to be merged in? :)
<jelmer> dazjorz: bzr push (by definition) pushes the existing history from the local branch to the target branch without changing it
<jelmer> dazjorz: if you don't want a change to the mainline, use rebase instead of merge
<dazjorz> jelmer: okay, I'll take a look, thanks :)
<dazjorz> (the thing about that is: it does push existing history from the local branch to the target branch - but as far as I'm concerned, the fact I had to manually merge the revision doesn't actually *change* the revision, so it doesn't have to be pushed back for me)
<jelmer> dazjorz: it might in this particular case not change the contents of the tree, it does change the contents of the history
<awilkins> Can I clarify the exact events here, because I'm using bzr to work with SVN and it's starting to worry me? What is occuring is that dazjorz has a "trunk" branch from an SVN repo, and a "local" branch of that trunk, and he's merged a revision from "trunk" to "local"?
<jelmer> awilkins: yeah, that's what he's done
<awilkins> And that revision gave rise to conflicts? And if you want to merge local back to trunk, and push that to SVN, it gives the error described?
<awilkins> Or are we talking pushing local straight into the SVN/trunk
<jelmer> awilkins: pushing local straight into the svn/trunk
<jelmer> awilkins: something that bzr-svn refuses as it would involve removin the merged revision from mainline in svn
<awilkins> Right, so would merging bzr/local to bzr/trunk and pushing that back to SVN/trunk work?
<jelmer> awilkins: yeah, as that wouldn't change the mainline
<awilkins> Good, I think that's the practice I've been intuitively doing anyway :-)
<awilkins> Oh, I mean merging bzr/local with the merged revision containing the conflict, back to bzr/trunk and pushing that
<awilkins> Just to be super-clear
<jelmer> awilkins: conflicts aren't relevant here
<awilkins> Ah, it's the merge
<awilkins> How would it overwrite an existing revision in SVN anyway? I didn't think that was possible remotely (do you have to enable some evil on the server?)
<jelmer> awilkins: it would overwrite anything, but it can change the history of a branch in subversion
<jelmer> awilkins: e.g. by replacing /trunk with an older copy of itself
<awilkins> Eww.
<jelmer> awilkins: well, that's what changing the mainline involves in svn, but bzr-svn won't do this by default unless you set that option
<awilkins> jelmer: I think that's fair... so keeping trunk as a bzr branch and merging back to that seems to be the right way to go?
<jelmer> awilkins: yeah
<dazjorz> jelmer: is there a way to tell bzr to throw away the changes to the history, and will that make it behave "correctly" for me?
<jelmer> dazjorz: bzr uncommit can remove revisions from the local branch
<jelmer> dazjorz: "bzr revert" can be used to update the working tree
<dazjorz> okay
<dazjorz> maybe you should add a note about that in the message I said
<dazjorz> "if you don't want to change the history, use uncommit to revert your merge commit, then use revert to update the working tree to the correct version"
<dazjorz> since the current notice is really unclear
<jelmer> dazjorz: The current notice assumes some knowledge about bzr's model
<jelmer> dazjorz: uncommit + revert only gets you back to the state before the merge
<jelmer> dazjorz: it's also very specific for your current situation
<dazjorz> I think many of the people using bzr-svn come from svn and simply want to use bazaar as their client, and therefore start without a lot of knowledge about bzr's model
<jelmer> dazjorz: I can't explain bzr's model in a single error message
<dazjorz> uncommit + revert brings my working copy back to before I started my changes, effectively throwing away my changes so I can update cleanly, and then can hope I still have the patch or I'll have to fix the bug again - sounds like exactly the thing a dvcs with advanced merging capabilities is designed to circumvent
<awilkins> dazjorz: How about uncommit + shelve in this case
<awilkins> You get to keep your changes and reapply them afterwards
<dazjorz> sounds good
<dazjorz> I didn't know about shelve
<dazjorz> jelmer: what about putting that in the error message?
<dazjorz> explaining to the user that he merged the conflict in a way that changes SVN history, and if that's not what he meant, he should uncommit and shelve, then update and apply again?
<awilkins> I think it's essentially the same as what rebase does but i) included and ii) manual
<awilkins> (is rebase in core now?_
<dazjorz> bzr: ERROR: No help could be found for 'rebase'.
<awilkins> Guess not then
<dazjorz> I guess not, then? Or at least in my version
<dazjorz> 1.15, which is old
 * dazjorz downloads the newest bzr to update the fink package
<awilkins> dazjorz: Which OS?
<jelmer> awilkins: rebase is still a separate plugin
<dazjorz> awilkins: Fink - Mac OS X
<jelmer> dazjorz: uncommit + shelve would be very specific to your current situation
<awilkins> jelmer: I should know that... I updated my plugins a few days ago
<dazjorz> jelmer: as far as I understand the situation, many users which tried to update and got a conflict would get that error message
<jelmer> dazjorz: this is unrelated to update
<dazjorz> jelmer: and you'd help all of them with a little hint "if you [.....], try uncommit + shelve, see the help for foo"
<dazjorz> jelmer: this is caused by update -> get conflict -> fix conflict -> commit conflict fix -> changed history but not patch, right?
<awilkins> I think what would be most helpful is a recipe for working from an SVN repo using Bazaar that doesn't encourage working in a branch of svn/trunk.
<awilkins> And prominently linked to from wherever people get introduced to bzr-svn from
<jelmer> dazjorz: I don't think uncommit + shelve is what you would want here actually
<jelmer> dazjorz: no, this is unrelated to conflicts
<jelmer> dazjorz: unrelated to *file* conflicts
<dazjorz> do you mean to say it could be unrelated to conflicts but in my specific case it turned out to be?
<dazjorz> related*
<jelmer> dazjorz: it's caused by the fact that you are pushing a mainline into subversion that doesn't match what's there at the moment
<jelmer> dazjorz: no, even in your case it's not related to merge conflicts
<dazjorz> jelmer: well, history was changed because of that file conflict, because I had to commit it
<dazjorz> maybe I misunderstood someone's explanation
<dazjorz> but when I ran bzr up in my changed working tree which had a commit not in svn which I was about to push, bzr told me of a conflict, and applied the changes in svn to my working tree
<jelmer> dazjorz: history wasn't changed, the mainline was
<dazjorz> as lifeless recommended, I fixed the conflict, ran bzr resolved, and committed the changes
<dazjorz> then tried to push, since I thought the conflict was resolved and now my commit could be pushed..
<dazjorz> oooooh
<dazjorz> I get it
<dazjorz> you mean I'm trying to insert a commit *before* the last commit on svn?
<dazjorz> instead of appending my commit to the top of the tree, like `svn commit` would do
<awilkins> You've already done it...
<awilkins> Just not pushed it up
<jelmer> dazjorz: I'm not sure I'm following what you've done exactly.
<jelmer> dazjorz: You were working in a checkout of your svn branch?
<dazjorz> a bzr checkout of the svn branch, yeah
<dazjorz> I made some changes, then committed - but as it turned out, svn was changed while I was editing
<dazjorz> and I wanted to commit my changes to the top of that
<jelmer> ok
<jelmer> so the commit was refused I guess
<jelmer> ??
<jelmer> then you ran update and then commit?
<dazjorz> well, the bzr push was refused because my checkout was out of date
<dazjorz> so yeah, I ran bzr merge to get up-to-date with svn again
<jelmer> dazjorz: So you weren't working in a checkout but in a standalone branch?
<jelmer> dazjorz: (otherwise the commit would have failed, because the local branch was out of date with the master branch)
<dazjorz> I think I was working in a checkout, I think I created it with "bzr checkout http://...", is there anyway to check that?
<dazjorz> either way, the commit was local
<dazjorz> so maybe it was a standalone branch, yeah
<jelmer> dazjorz: if the commit was local you would be working in a standalone branch indeed
<dazjorz> okay
<dazjorz> sorry for the confusion, then it was a standalone branch
<awilkins>  http://pastebin.ubuntu.com/230489/ # << this seems to be what we are discussin
<awilkins> http://imagebin.ca/view/pBuP7v1.html  # illustrated with this
<dazjorz> thank you awilkins
<jelmer> awilkins: right
<jelmer> dazjorz: so in the screenshot awilkins posted the second svn revision has disappeared from mainline
<awilkins> http://imagebin.ca/view/oGTTEoWU.html ## here we've fixed it
<jelmer> dazjorz: bzr-svn would push revisions 1, 2 and 3 onto mainline but that would mean removing 1.1.1
 * dazjorz is confused by the "bzr switch local" and "bzr switch trunk", but for the rest, seems about what I was doing
<jelmer> awilkins: alternatively, you could just merge into a checkout of trunk *or* rebase
<awilkins> In screenshot 2 ; we've merged local into trunk (which is our mirror branch for SVN)
<awilkins> This revision pushes to SVN cleanly
<awilkins> jelmer: Screenshot 2 is the former ; switched our checkout to trunk and merged into it
<awilkins> bzr switch trunk ; bzr merge ../repo/local ; bzr commit -m "Fixed problem"
<dazjorz> jelmer: it would mean inserting 2 in front of 1.1.1, while 1.1.1 is latest in the SVN revision and you usually don't want to insert a revision in front of another one in svn
<dazjorz> right?
<jelmer> awilkins: no, screenshot 2 contains an extra unnecessary merge commit
<dazjorz> actually I think awilkin's paste is even more complex than what I did
<jelmer> dazjorz: no, 1.1.1 wouldn't be on the mainline at all anymore given screenshot 1
<jelmer> dazjorz: (revision numbers without dots are on the mainline)
<dazjorz> okay, as a SVN user, I'm jumping through hoops to follow you while you're talking about mainline and moving that SVN revision to a branch off the mainline
<dazjorz> I never wanted to do that, but apparantly, that's how it turned out :P
<jelmer> dazjorz: I'd recommend using checkouts if you're only familiar with svn, they are most similar to svn checkouts
<jelmer> dazjorz: rather than standalone branches, which don't really exist in svn
<dazjorz> well then I could just as well use svn directly - I'm looking into this specifically because I need a DVCS on my client, sending commits to a central SVN repository
<jelmer> dazjorz: if you alternatively you could look into using "bzr rebase" to pull in new revisions from mainline
<dazjorz> but if possible, I'd like to avoid problems like this and having to uncommit and stack up changes because I can't make bzr-svn correctly merge svn changes with my changes so I can still send my changes in nicely
<jelmer> dazjorz: I guess that matches more closely what you would do in subversion
<dazjorz> yeah
<dazjorz> I'll look at it
<dazjorz> lifeless also gave me a different solution which came down to having a bzr checkout, and a bzr branch of that checkout
<dazjorz> so I could bzr update in the checkout, then merge my changes from the branch, and commit them as one large patch, then update the branch back from the checkout
<awilkins> That's effectively what I do but not quite the same way
<jelmer> dazjorz: yeah, that would work as well
<awilkins> I use a no-trees repository with a trunk branch in it and use switch (as illustrated in paste)
<dazjorz> I think bzr rebase sounds like what svn does: basing your repository on a different version, while keeping your changes "on top" of the rest
<dazjorz> amirite?
<jelmer> dazjorz: yeah
<dazjorz> great
<jelmer> dazjorz: it keeps your history linear
<awilkins> lifeless's way has it's advantages in that because "trunk" is a checkout it won't let you commit "inserted" revisions accidentally.
<dazjorz> yeah
<dazjorz> but then rebase works around that problem by changing "inserted" revisions to become revisions "on top" of the ones already in svn
<awilkins> I only find out I screwed it up when I try to push
<awilkins> But I usually pull / merge / push quickly enough not to bump into other peoples commits
<awilkins> It helps that everyone else is in another timezone :-)
<Tak> blargh, I just had the same issue as dazjorz
<dazjorz> Tak: you made my day ;)
<Tak> hmm, rebase tells me no revisions to rebase
<dazjorz> I think you may need to uncommit until before the merge, then rebase?
<awilkins> Tak: Are you passing the svn branch as the parameter to rebase?
<Tak> the upstream branch?
<awilkins> Yes
<Tak> same result
<awilkins> Hmm
<Tak> my flow of events: I pulled this morning, fixed a bug, committed locally, went to push, was notified that the trees were out of sync, merged, went to push again, got complaint about changing mainline history
<awilkins> Tak... ok, try this. Branch your current branch to a sibling folder (say "trunk"). cd trunk ; bzr pull <svn url> --overwrite
<awilkins> cd ../original_branch ; bzr rebase ../trunk
<Tak> No revisions to rebase.
<awilkins> What does bzr missing ../trunk say ?
<Tak> shows 2 revisions
<awilkins> Both yours? Or theirs too?
<Tak> my bugfix rev, and the merge commit
<awilkins> I think dazjorz is right, you might have to uncommit that merge and rebase instead
<Tak> in that case I agree with him
<awilkins> It's small risk - it will tell you which revision you are (not) trashing
<awilkins> It doesn't think you have to rebase that revision because you already merged it
<awilkins> Bah, these things do my head in
<dazjorz> or, bzr diff -r[yourcommit-1]:[yourcommit] >yourcommit.diff; bzr uncommit [yourcommit]; bzr rebase; patch -p0 <yourcommit.diff; bzr commit
<dazjorz> maybe.
<awilkins> I don't think you need to take special measures to preserve your changes
<Tak> I diffed just in case
<awilkins> That's what rebase is doing ; it's effectively replaying your patches on top of the new history and forging a new history
<Tak> but bzr uncommit -r-3; bzr pull; bzr commit; bzr push  seems to have worked
<awilkins> If you'd had more than one revision committed locally that would have smunged them all together, but that works equivalently as well as rebase for 1 revision
<Tak> better, because it actually saw my revision ;-)
<SamB> how do I find out the HTTP URL corresponding to an lp: URL?
<beuno> SamB, http://bazaar.launchpad.net/$whatever comes after lp:
<SamB> ... without the nonexistant lp-logout command or going and hand-editing the config file that it would edit?
<beuno> unless it's an lp:project URL
<SamB> I wonder why that isn't in the web UI
<SamB> beuno: well, it is a project URL yes
<SamB> but I have the SSH URL so I can figure it out
<beuno> SamB, you want the web UI to expose the long URL?
<beuno> why?
<beuno> it's not needed
<SamB> it might be handy
<SamB> especially since when I run "bzr info" on the lp: one it gives me back useless info
<SamB> with -v, I get this about the format:
<SamB> Format:
<SamB>        control: bzr remote bzrdir
<SamB>         branch: Remote BZR Branch
<SamB>     repository: bzr remote repositor
<SamB> oops, missed a y. still, doesn't that seem pretty useless?
<beuno> "it might be handy" is not a great argument to pollute the Launchpad UI  :)
<beuno> yes, that's a problem with bzr
<beuno> not being able to read remote formats properly with the smart server
<SamB> one more line would hurt?
<beuno> yes, *anything* extra on theUI hurts
<beuno> more places competing for your attention
<SamB> hmm, actually it could be a very subdued-tone link after the "bzr branch" command or something ...
<SamB> a short one
<SamB> with the URL only in the href field
<beuno> again, without a reasonable use case....
<beuno> and
<beuno> Launchpad *tells* you the format already on the UI
<SamB> is that the same thing bzr would say?
<SamB> no, it gives it to you in some "human-readable" format that is useless for figuring out what to pass to init-repo ...
<beuno> well, there yout go
<beuno> that's the problem we need to fix  :)
<SamB> ah, but so does bzr on the part I pasted before ;-)
<SamB>         branch: Branch format 6
<SamB>     repository: Packs containing knits without subtree support
<beuno> right
<SamB> but at least the first line is helpful here:
<SamB> Standalone branch (format: pack-0.92)
<SamB> I'm looking at https://code.launchpad.net/~mailman-coders/mailman/3.0 if that matters ;-)
<beuno> file a bug on launchpad about it, and I'll chase it up and see how we can show that instead
<SamB> but if "bzr info" isn't displaying enough info in those lines, isn't that an issue too?
<beuno> yes
<SamB> so do I need to report those seperately or together ?
<beuno> two bugs!  your karma will go through the roof!  ;)
<SamB> heh
<SamB> I've reported a lot more than that
<SamB> hmm, looks like someone did already: https://bugs.launchpad.net/bzr/+bug/248900
<ubottu> Ubuntu bug 248900 in launchpad-code "More understandable format strings needed" [Medium,Triaged]
 * SamB renames the bug
<SamB> bug 248900
<ubottu> Launchpad bug 248900 in launchpad-code "More understandable format strings needed" [Medium,Triaged] https://launchpad.net/bugs/248900
<SamB> wrong!
<beuno> heh
<beuno> you now know that ubottu caches  :)
<beuno> SamB, I'll chase developers about that bug
<bialix> igc: hi
<igc> hi bialix
<amanica> igc: btw. nice new doc frontpage
<igc> amanica: thanks
 * emmajane waves
<emmajane> bazaar made it to the front page of slideshare.net. :)
<igc> emmajane: well done!
<emmajane> thanks :)
<corporate_cookie> if I want to use bzr+ssh to check something out do I just run bzr serve --directory=foo  ...then open up port 4155 on the remote machine ?
<SamB> corporate_cookie: bzr+ssh seems to use the usual SSH port
<corporate_cookie> amazing : )
<SamB> and attempt to invoke bzr as if it were in fact connecting to an ordinary SSH server
<amanica> yes --serve is for the custom and not-secured protocol
<SamB> not to say that this is by any means necessarily the case ;-)
<amanica> you can also use sftp://
<SamB> but if it is the case, it should work without special configuration as long as you're allowed to run whatever command you like on the server ;-)
<corporate_cookie> ive been using sftp ....but im curious in checking out hpss
<corporate_cookie> there is only a couple of lines in the users guide referring to it
<SamB> it's pretty typical of ssh-based access to VCSs that they work without any special configuration for people who have ssh shell access
<SamB> the trickiest bit being to make sure that the VCS (or subsystem of VCS needed to commit) be findable
<SamB> basically meaning either it has to be in the PATH used by the sshd to find the command, or the VCS client has to specify an absolute path to it
<agrippa> Getting an error when trying bzr status
<agrippa> bzr: ERROR: Could not acquire lock "/Volumes/web$/tipsv2/.bzr/checkout/dirstate": [Errno 45] Operation not supported
<agrippa> Using bzr 1.16.1 on OS X 10.5.7
<agrippa> Is this a current bug that needs to be fixed?
<SamB> agrippa: what does mount say ?
<LarstiQ> corporate_cookie: all you need is ssh access and a runnable bzr on the remote side
<corporate_cookie> thanks SamB : )
<LarstiQ> agrippa: what is /Volumes/web$ for a filesystem (what SamB said)
<agrippa> It's mounted via SMB
<SamB> hmm
<SamB> my guess is it's an issue with OS X's SMB driver and/or SMB
<SamB> jelmer___: do you know anything/
<agrippa>   Volumes/web$ (smbfs, nodev, nosuid, mounted by rsmith)
<SamB> s|/|?|
<agrippa> hmmm
<SamB> agrippa: so what is this volume provided by?
<agrippa> It's mounting a share off of our Windows development server
<agrippa> The server is a Windows 2003 SP1
<Tak> is there a way to flag another email address as "me" on launchpad?
<SamB> poor you, having to develop for windows :-(
<SamB> Tak: you can add it to your account, yeah
<agrippa> Well, we're developing Flash, but we use Windows for the web server
<SamB> just go to your account and then find the little edit icons (I think they look like exclamation marks?)
<SamB> agrippa: odd thing to do
<agrippa> Although I wish we didn't use a Windows server sometimes
<agrippa> Well, when you're organization buys whole hog into MS, that's what happens :p
<Tak> hmm, I don't have one of those next to the email
<LarstiQ> agrippa: in or on Flash?
<SamB> agrippa: but not so whole-hog that *you* have to use Windows on your machine?
<LarstiQ> SamB: some people actually like windows :P
<agrippa> Larstiq: Well, in Flash, and ActionScript
<SamB> LarstiQ: but for a server ?
<Tak> blargh - also, why can't I sign the CoC with my ssh key?
<LarstiQ> SamB: yes
<SamB> it doesn't seem like a suited job for the software that's available on Windows
<agrippa> SamB: Yeah, our central IT likes Windows, we use OS X in our group though
<SamB> well, maybe there's more stuff available there than there used to be ...
<SamB> well, I suppose it's better than using Novell services :-(
<SamB> ... maybe I'm just biased because I've never really had money to spend on development tools :-)
<Tak> aha, found it!
<SamB> and they didn't used to offer those free for Windows
<agrippa> SamB: Windows 2003 isn't too bad really, it's pretty easy to manage, does most of what I need.  There are more OS web apps developed for Linux in some situations, so I wish we had a Linux server, but our central IT doesn't have the skill set for it.
<SamB> I mean, MS didn't
<SamB> but I still wish it had SSH and a decent network filesystem -- though the latter could be said of *nix as well, I think?
<SamB> ... one thing I really hate about windows is the cost of process creation :-(
<agrippa> SamB: By it, you mean Windows 2003?
<SamB> agrippa: well, in general
<SamB> I actually only have XP
<agrippa> SamB:  Our version does not have SFTP which is a bummer, but more recent versions do
<agrippa> In general though, you can get SSH for Windows
<SamB> is that an actual variant of FTP, or some SSH-based protocol, or both?
<SamB> agrippa: without paying for it ?
<agrippa> SFTP, I think it's built on top of SSH
<SamB> I thought there might be two SFTPs or something
<agrippa> SamB: Yeah, I've been using puTTY for years
<agrippa> I think there are two SFTPs
<SamB> I meant an sshd for windows, actually
<agrippa> They both run on top of SSH though, if I'm right
<jelmer___> luks: hi
<SamB> agrippa: even worse!
<jelmer___> luks: I've finished and merged the 'bzr send --format=svn' branch
<SamB> jelmer___: so do you know anything about locks not working over SMB from OS X?
<jelmer___> luks: It'll now also report property changes
<SamB> jelmer___: what does that do?
<SamB> hmm. I guess I should just try it?
<jelmer___> SamB: Sorry, not familiar with the Mac OS X client
<agrippa> SamB:  I think MS would have to improve their shell for sshd to be any good on Windows :p
<SamB> jelmer___: thought it was worth a try :-)
<jelmer___> SamB: it generates a files similar to "svn diff"
<jelmer___> SamB: without any bzr metadata
<SamB> agrippa: oh, but it could spawn bash or something
<agrippa> SamB: Yeah, I guess spawning a bash shell from Cygwin would be cool
<SamB> jelmer___: is that "without" supposed to be a feature?
<jelmer___> SamB: yes
<SamB> agrippa: and even cmd is better than nothing!
<agrippa> But MS did do a decent job with RDP
<SamB> agrippa: hmm.
<jelmer___> SamB: there's no point in sending complex bzr bundles when upstream isn't using bzr
<SamB> agrippa: does that forward a terminal ?
<SamB> jelmer___: yeah ...
<agrippa> You could open a DOS prompt in RDP or a bash shell if you had Cygwin installed
<SamB> jelmer___: but it's too bad you can't get the bzr metadata into svn that way :-(
<SamB> agrippa: well, yeah ...
<SamB> but it seems kind of an inefficient way of going about things
<agrippa> SamB:  Have you tried this http://web.mit.edu/pismere/ssh/ssh-port.html
<SamB> maybe I should try it before I say that though
<agrippa> Oh wow, I just found out that OS X allows tabbed terminals by accident
<SamB> oh, cygwin has sshd now?
<SamB> well ... I guess that's *kind* of nice
<agrippa> SamB: You know, I did get SVN working over SSH from a Windows server a while back, so maybe it might just work
<LarstiQ> anyone got an idea what time lifeless tends to get online nowadays?
<SamB> well, it looks like he left around midnight EST last night
<SamB> and got on around 17:52 EST
<SamB> it's now about 14:19 EST, so I guess you'd best wait 3-4 hours ?
<LarstiQ> right
<LarstiQ> which is around my midnight
<SamB> or you could try to see him in your morning?
<LarstiQ> yeah, I will. In the meantime updated the bug and going to do some more investigative work.
<agrippa> blarg, tried to create a symlink and that did not work either :(
<SamB> agrippa: well, I'm pretty sure that would be MS's fault
<agrippa> SamB: heh
<agrippa> Well, if I copy locally it works, but meh, I don't want that
<agrippa> Does bzr use the svn  you have installed on your system or does it have its own copy?
<SamB> agrippa: it probably depends on where you get bzr ;-)
<SamB> for me, it uses the installed SVN, but I'm running Debian
<SamB> (though I imagine it would for anyone who had built from source as well ;-)
<SamB> (Well, built subvertpy from source, that is)
<agrippa> hmm
<agrippa> I might get ambitious and give it a shot, but I generally do have a harder time compiling things from source on OS X
<SamB> agrippa: I can't say as I have any idea what svn subvertpy from the OS X will use
<LarstiQ> agrippa: I think it's highly likely that it will use the standard system OSX, but I can't verify
<jam> any qbzr developers here?
<jam> I'm seeing a lot of deprecation warnings with a checkout of qbzr trunk
<jam> Most notably:   /home/jameinel/.bazaar/plugins/qbzr/lib/subprocess.py:600: DeprecationWarning: bzrlib.plugins.qbzr.lib.subprocess.SubprocessUIFactory was deprecated in version 1.18.
<jam> Presumably bzr.dev started deprecating using CLIUIFactory directly
<jam> and qbzr inherits from it?
<jam> garyvdm: so you *are* around, just not responding :)
<garyvdm> jam - I just signed on now
<jam> np
<jam> I just submitted a bunch of qbzr bugs so that you can feel loved
<jam> mostly, I'm doing a demo, and ran into a bunch of niggles
<garyvdm> Thanks
<jam> The SubprocessUIFactory being the one I'd like to see fixed first
<jam> bug #404269
<ubottu> Launchpad bug 404269 in qbzr "SubprocessUIFactory inherits from deprecated CLIUIFactory" [Undecided,New] https://launchpad.net/bugs/404269
<garyvdm> jam - I like your suggestion for bug 404276
<ubottu> Launchpad bug 404276 in qbzr "qannotate double clicking in per file graph gives diff rather than changing the annotation" [Undecided,New] https://launchpad.net/bugs/404276
<jam> \o/
<jam> Mostly it is just changing the default action
<garyvdm> Yes
<jam> Oh, I meant to submit another one
<jam> which is that when you annotate to a new rev, it keeps the same line num
<jam> but likely lines have moved
<fullermd> jam: BTW, can you comment on my mail about that comment?  It's your rev (though to be sure your memory is 3 years cold on it)
<jam> fullermd: "comment on my mail about that comment"
<jam> that is the 0.10 thing?
<fullermd> Yah.
<fullermd> (not necessarily right this second of course, just in general)
<garyvdm> Right now - I'm feeling a overwhelmed. Lots of attention to qbzr lately has result in lots of good ideas and bug, and too few hours to work on them. :-~
<jam> fullermd: responded
<jam> garyvdm: yeah, mostly just wanting to record ideas right now
<jam> i had some thoughts to work on qannotate for what I've been doing
<jam> and then i found that you implemented the things I was most pressed to add :)
<garyvdm> Annotate old revision?
<jam> garyvdm: per file graph being displayed, and moving around the revision graph
<jam> I'd still like to get things hooked into the new Annotator code, and get caching working
<jam> which would make jumping around *much* faster
<jam> Working on 2a polish etc bugs right now, thoug
<garyvdm> That would be cool
<garyvdm> And I want to get it to annotate the wt
<LarstiQ> polish?
<flvr8> hey guys, one of our developers is getting: ERROR: exceptions.KeyError: 'pop(): dictionary is empty' on his branch. are there steps he can take to fix that other than completely getting a new checkout?
<jam> LarstiQ: well, stuff like making "bundles" work
<jam> :)
<flvr8> he can't do a bzr diff to see his changes, because that gives the same error.
<LarstiQ> jam: pfew :)
<SamB> jam: that's called "fix" ;-P
<jam> flvr8: a bigger traceback is usually helpful to understand what is going on
<LarstiQ> jam: any idea how far to comletion that is?
<jam> in the short term, things like this are often caused by plugins
<jam> so doing "bzr --no-plugins XXXX" might work around it.
<jam> LarstiQ: I have a branch, it has 2 tests failing that I know of
<jam> got side-tracked into a meeting today
<flvr8> jam: https://bugs.launchpad.net/bzr/+bug/235407 - same stacktrace, he says
<ubottu> Ubuntu bug 235407 in bzr "'pop(): dictionary is empty' in tsort when showing pending merges" [High,Fix released]
<flvr8> he was on 1.5 until very recently
<jam> flvr8: see the comments
<jam> The current workaround is to 'bzr revert' and re-do whatever merge got you into this situation. (As new bzr's won't let you get back into the same situation.)
<SamB> flvr8: what's he on now ?
<jam> or try applying the patch
<flvr8> 1.16
<flvr8> er, 1.16.1
<flvr8> macports doesn't have 1.17 yet
<jam> flvr8: according to the bug, the problem is older revs of bzr wrote down bogus data
<agrippa> :(
<jam> there is a patch that tells bzr to ignore it
<jam> as part of the bug
<LarstiQ> agrippa: ?
<jam> alternatively, "bzr revert; bzr merge"
<agrippa> LarstiQ: 1.17 not being available on OS X
<agrippa> LarstiQ: I can't get around this dirstate thing
<LarstiQ> agrippa: I feel I'm missing something, dirstate thing?
<jam> agrippa: as of 1:45am this morning (about 13 hours ago) someone posted to the list saying that they made a 1.17 installer.
<jam> just not macports, I guess
<agrippa> LarstiQ: Problem I was talking about earlier, I've been getting "Could not acquire lock" when doing bzr status
<agrippa> jam:  I saw the 10.4 installer, but not sure if that will work for 10.5
<flvr8> jam: thanks, let him know that
<jam> agrippa: new versions probably don't help, as you are probably running "bzr commit" in the other window
<jam> and if the lock is taken, status can't aquire it
<SamB> oh, yeah, that's in launchpad
<SamB> as what, I don't remember ;-).
<agrippa> jam:  Not the case here
<SamB> but it's sure a pain that when you do a bzr commit and it puts you in an editor, you can't interrogate your working directory+repo
<agrippa> SamB: Just use bzr commit -m "message"
<jam> SamB: pretty sure it is bug #98836
<ubottu> Launchpad bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed] https://launchpad.net/bugs/98836
<LarstiQ> agrippa: ah, didn't realise it was that
<agrippa> Yeah, this is what I'm dealing with basically: https://bugs.launchpad.net/bzr/+bug/31006
<ubottu> Ubuntu bug 31006 in bzr "dirstate file locking doesn't work on smb mount on osx - bzr add, bzr status, and bzr commit fail over a SMB share (dup-of: 98836)" [High,Confirmed]
<ubottu> Ubuntu bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed]
<agrippa> ubottu's link includes that link
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<Tak> is bzrlib gpl or lgpl?
<LarstiQ> flvr8: it was verterok who uploaded the OSX installers, but didn't update the wiki yet because he wanted testers, volunteer? :)
<LarstiQ> Tak: gpl
<Tak> kthx
<LarstiQ> flvr8: http://edge.launchpad.net/bzr/1.17/1.17/+download/Bazaar-1.17-OSX10.5.dmg
<agrippa> LarstiQ: I'll volunteer
<flvr8> LarstiQ - heh no, i'm on a sane operating system. but i'll pass that on to my colleague
<LarstiQ> agrippa: cool!
<verterok> agrippa, LarstiQ: thanks!
<agrippa> verterok: I've got 8 procs you can crash :p
<verterok> heh
<LarstiQ> verterok: np, thanks for building it. And the config.py!
<verterok> LarstiQ: heh, sure! it stills needs a lot of work, but at least isn't a 100% manual build anymore ;)
<LarstiQ> verterok: very very nice
<agrippa> verterok: So, is there someplace I can download the installer?
<verterok> agrippa: http://edge.launchpad.net/bzr/1.17/1.17/+download/Bazaar-1.17-OSX10.5.dmg
<flvr8> ok, he reports that revert/merge doesn't work. he's committed some changes to his local repository but apparently is blocked from pushing to launchpad. noob question, since I haven't come across this before, how can he see which files he committed locally?
<agrippa> Halp! All my files are deleted!
<LarstiQ> flvr8: bzr st -r -3..-1 ?
<LarstiQ> agrippa: hmm?
<agrippa> LarstiQ: kidding
<LarstiQ> agrippa: tsk :P
<agrippa> Well, the installer seemed to work just fine.  bzr --version gives 1.17
<verterok> agrippa: cool!
 * verterok updates the wiki
<agrippa> verterok: I looked at your launchpad page.  So you work on the Eclipse plugin?
<verterok> agrippa: yes  trying to get some spare time to get things moving)
<agrippa> verterok:  Is there a way to get the Eclipse plugin to work with filesystem links?
<verterok> agrippa: filesystem links?
<flvr8> Larstiq - thanks. this is probably the revision that caused him grief fwiw. http://bazaar.launchpad.net/~daisyextension/daisyextension/main/revision/714 ... i tried uncommitting it, but bzr wants me to commit the uncommit, so i'm not sure if that'll help him out at all. (somehow my pull of his changes required a merge, which then required a commit before bzr was happy, which was why it's there)
<flvr8> Larstiq - so if i understand the problem fully, his 1.5 client dumped bad data in there, which confused my client, which then screwed the pooch for him(?)
<agrippa> verterok: Yeah, I've got a linked folder in Eclipse and can't seem to get the Team menu to come up
<LarstiQ> flvr8: uh, I haven't been fully following along
<LarstiQ> agrippa: symlink?
<LarstiQ> agrippa: or something more exotic?
<flvr8> oh well, that's a general question then. how do we fix the branch's metadata?
<agrippa> LarstiQ: It's  in Eclipse, but not a real symlink.
<LarstiQ> agrippa: aah
<verterok> agrippa: ooh, linked resources! the support is *experimental* I need to chase down all the places where resource checks are done and also check for links
<LarstiQ> flvr8: I'm a bit overloaded to go check backlog fully, but for me to get what is going on I'd need some more debugging information
<flvr8> Larstiq: ok, i can just file a bug. but yeah, let me know what else would be useful to include?
<LarstiQ> flvr8: not necessarily a bug
<LarstiQ> flvr8: pastebinning the command and traceback (you may have already done so?) as a start
<agrippa> verterok: Yeah, was trying that on this machine to see if I liked using a linked folder better for my source
<LarstiQ> flvr8: but I'm going back to bug 390502 for a bit now
<ubottu> Launchpad bug 390502 in bzr "bzr's development should dogfood format 2a" [High,Confirmed] https://launchpad.net/bugs/390502
<verterok> agrippa: btw, linked resources are (or are going to be) ignored by bzr-eclipse, at least regarding Team menu
<verterok> agrippa: as the Eclipse team framework don't allow to do much with them (I must to check 3.5 to see if something changed related to this)
<agrippa> verterok: Ah, ok.  Thanks for the info.
<verterok> agrippa: np
<poolie1> hi all
<poolie1> hi jam
<garyvdm> jam: Bug will take me a while, because I need to try take advantage of the new apis (e.g. I can now override make_progress_view, rather than setting _progress_view)
<garyvdm> bug 404269
<ubottu> Launchpad bug 404269 in qbzr "SubprocessUIFactory inherits from deprecated CLIUIFactory" [Medium,Confirmed] https://launchpad.net/bugs/404269
<garyvdm> jam: while still staying compatible with older versions of bzr
<garyvdm> jam: so I need to check if make_progress_view is not there, if not, I need to set  _progress_view...
<garyvdm> jam: I would like to stay compatible with bzr 1.16
<garyvdm> poolie1: Hi - Maybe I have the wrong approach here. Any recommendations here to make things easier for me?
<poolie1> hi gary
<poolie1> garyvdm: possibly you need to inherit from different classes depending on the bzr version?
<garyvdm> poolie1: I guess I'm looking for a silver bullet. The changes that you have made are good. It's just really hard to take advantage of them, while staying backward compatible.
<garyvdm> bbl
<poolie1> garyvdm: do you actually need to override the progress methods?
<poolie1> you don't seem to do anything with them
<poolie1> sure, cheers
<LarstiQ> don't they get called by pbs?
<garyvdm> poolie1: We implement a custom TextProgressView
<poolie1> oh of course
<poolie1> it's also unfortunate that you need to deal with stacking
<poolie1> that should maybe be in the view or something
<jam> hi poolie1 you're up early
<poolie1> i am
<lifeless> heh
<jam> hi lifeless
<jam> especially given that it is poolie1 nad lifeless 's weekend :)
<poolie1> i woke up too early, i'm trying to be quiet
<lifeless> paaaaaaa
<lifeless> tay
<jam> luulllaabby and goooodniiitee
<jam> goooo to sleeep now, dear poooliee
<LarstiQ> hah
 * LarstiQ is about to crash
<lifeless> night
<LarstiQ> lifeless: thanks for the reply
<LarstiQ> lifeless: did subunit actually have any stacked branches?
<lifeless> yes
<lifeless> your problems are real
<LarstiQ> ok
<lifeless> by they aren't intrinsic to upgrade
<pygi> hi folks
<LarstiQ> lifeless: sure, I'm not claiming that there is no situation in which it would work
<LarstiQ> lifeless: this question I specifically asked because I upgraded everything before I noticed it was 0.92 and no stacking was going on
<LarstiQ> and I'll expand it into bugs tomorrow
<LarstiQ> night
<lifeless> LarstiQ: thanks
<garyvdm> Hi pygi
<garyvdm> poolie1: I like to make a change to the ui factory, and I just want to run the idea by you first.
<garyvdm> I would like to split TextProgressView up into ProgressView and TextProgressView
<poolie1> sure
<poolie1> that sounds good
<garyvdm> The code which keeps track of the last task message, the transport activity rate and formats the transport activity - that would go into ProgressView
<garyvdm> All the terminal rendering code would stay in TextProgressView.
<jam> garyvdm: 'formatting the activity rate' sounds like a higher level activity (IMO)
<garyvdm> That would make it easier for qbzr to implementing a ProgressView
<poolie1> garyvdm: that sounds ok
<poolie1> if all the time-dependent or stateful stuff is localized that will help with testing too
<garyvdm> jam: this line?  msg = ("%6dKB %5dKB/s" %  (self._total_byte_count>>10, int(rate)>>10,))
<garyvdm> jam: I doubt that gui's would want to ever format it differently.
<jam> garyvdm: that looks like something where you'd want the total byte count, and could put it on separate lines, or etc.
<jam> certainly I think of rendering as formatting from logical information (bytes) to a string
<poolie1> i think there should be a class that accumulates this
<poolie1> it's almost an ActivityModel
<poolie1> or a little state machine separate from rendering
<garyvdm> jam, poolie1: Ok - I'll keep the formatting in TextProgressView. ProgressView will just keep state, and conduct.
<poolie1> garyvdm: you could make the formatting available in a higher class
<poolie1> but not assume it'll be used
<poolie1> then guis could use it if they want to
<garyvdm> poolie1: Yes
<poolie1> well in that case i might go and have a saturday :)
 * SamB wishes "bzr viz" supported ^revid like git ...
<jelmer___> SamB: what does ^revid do?
<jelmer___> SamB: also, file a wishlist bug :-)
<SamB> jelmer___: not show revid and it's ancestors
<SamB> of course, first it would be important to allow revision specs ...
<SamB> not just branches
 * SamB thinks ...
<garyvdm> SamB - I assume this is when looking at multiple branches?
<SamB> garyvdm: well, actually it's also useful if you want to see what's changed between bzr ppa builds ;-)
<garyvdm> So you are using ^ revid as a stop revision?
<SamB> no, I'm wishing I could
<ali_> Hi, what does asterisk "*" mean in bzr status? One guy reported a bug about it, lovely enough he didn't put the answer there. Sad. https://bugs.launchpad.net/bzr/+bug/74333
<ubottu> Ubuntu bug 74333 in bzr "Asterisk in status not documented (dup-of: 46636)" [Wishlist,Confirmed]
<ubottu> Ubuntu bug 46636 in bzr "meaning of '*' in bzr status is undocumented and unverbose" [Low,Confirmed]
<ali_> thank you
<sender> can anyone tell me what's the diff between workbooks.Open() and workbooks._Open() - or the "_" notation in general?
<sender> _Workbook workbook = workbooks.Open() and Workbook workbook = workbooks.Open() ...
<SamB> jelmer___: https://bugs.launchpad.net/bzr-gtk/+bug/404358
<ubottu> Ubuntu bug 404358 in bzr-gtk "support a revision-graph-specification language like that of git-rev-parse(1)" [Undecided,New]
<SamB> now I know what you're probably going to say -- why should this be in bzr-gtk ? -- and you're right ;-)
<sender> apologies.. wrong window :(
<SamB> oh, what was the bug for "bzr send" not working with 2a?
#bzr 2009-07-25
<BBHoss> anyone know why bzr would lock up pulling a large repo ~300 MB on a system with only 256MB RAM?
<SamB> huh
<SamB> some people!
<suji1> Hi, I give the command bzr add filename , it shows an error the current directory is not a branch (bzr: ERROR: Not a branch)
<cody-somerville> Anybody seen this before? http://pastebin.ubuntu.com/232826/
<cody-somerville> ah, appears so
<mneptok> cody-somerville: kneilsen in our team encountered the same behavior - https://bugs.edge.launchpad.net/bzr/+bug/375898
<ubottu> Ubuntu bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [Medium,Triaged]
<cody-somerville> guh
<cody-somerville> And I've just been bitten by the bzr format incompatibilities :(
<LarstiQ> cody-somerville: which formats?
<cody-somerville> pack-0.98 and rich root pack I think
<LarstiQ> right, non-rr vs rr
<LarstiQ> cody-somerville: I'm happy to note that once we get 2a where we want it, there is a default format with rich roots, no more of that one-way-barrier after that (well, everyone will be on this side of the barrier)
<LarstiQ> cody-somerville: right now it's a huge pain
<james_w> we should probably improve that error message before 2.0
<james_w> I imagine a lot of people will hit it and it's not the most helpful error
<LarstiQ> james_w: you mean the trans_id one or the rr-format one?
<james_w> rr-format
<LarstiQ> right
<james_w> the trans_id one should just be fixed :-)
<jelmer___> moin!
<LarstiQ> hoi jelmer___
<LarstiQ> verterok, agrippa: does the new installer include enough to have qbzr working? ref bug 349143
<ubottu> Launchpad bug 349143 in bzr "no lp-logout command" [Low,Confirmed] https://launchpad.net/bugs/349143
<jelmer___> LarstiQ: how's the 2a upgrade process going?
<LarstiQ> jelmer___: I have bugs to file.  If we agree we can go ahead with the upgrade-guide approach before fixing them, a date should be picked for the upgrade.
 * LarstiQ needs to find out some stuff about upgrading pqm first too
<LarstiQ> jelmer___: it's moving, but no ETA yet
<jelmer___> LarstiQ: ah, ok
<LarstiQ> jelmer___: bug 390502 if you weren't aware of the bug number
<ubottu> Launchpad bug 390502 in bzr "bzr's development should dogfood format 2a" [High,Confirmed] https://launchpad.net/bugs/390502
 * LarstiQ goes afk for a bit
<LarstiQ> jelmer___: (I'm guessing something like next weekend for the upgrade, if we get agreement and announcement out this weekend)
<lifeless> LarstiQ: I really don't like breaking *all* the metadata about existing branches
<lifeless> LarstiQ: I'd /much/ much much much rather fix the bugs
<lifeless> upgrading bzr itself won't teach us much if we haven't fixed the bugs such that we can do the process other people will to
<mathrick> hiya
<mathrick> does anyone know if bzr-svn supports history horizons yet?
<mathrick> I know it does stacked branches, but that's a bit excessive in that it needs network for *all* access to old data, if I understand correctly
<mathrick> jelmer___: poke
<jelmer___> mathrick: hi
<mathrick> jelmer___: does bzr-svn do history horizons yet? If I understand correctly, --stacked will want to access network for all past revisions, no?
<mathrick> also, I have a repo that fail a stacked get with 0.6.2 here
<jelmer___> mathrick: history horizons != stacked branches afaik
<jelmer___> mathrick: what command are you trying to run exactly that fails?
 * fullermd suspects getting history horizons in bzr-svn will be somewhat difficult before there are history horizons in bzr...
<mathrick> jelmer___: http://pastebin.com/f1df8f6df
<jelmer___> mathrick: stacked branches don't work in bzr-svn
<jelmer___> mathrick: svn doesn't support stacking itself
<jelmer___> mathrick: and bzr doesn't support stacking between different formats
<mathrick> jelmer___: Ã¦h? But you tell to use stacked branches in the FAQ
<jelmer___> oh, is that still there?
<jelmer___> bzr-svn supported stacking for a while through a hack, but I removed that a while ago
<mathrick> oh
<jelmer___> mathrick: I don't see any comments about that in the FAQ, only " 30 In the future it should hopefully be possible to use stacked branches.
<jelmer___> "
<mathrick> it should just fail with "stacked branches not supported" then
<mathrick> jelmer___: http://samba.org/~jelmer/bzr-svn/FAQ.html#cloning-a-large-subversion-branch-is-very-slow :)
<jelmer___> mathrick: ah, I should probably remove that copy
<mathrick> I believe it's also there in the bzr wiki
<jelmer___> mathrick: I agree the error message could be clearer but afaik you get the same error message when trying to stack a bzr branch onto a different format bzr branch
<mathrick> jelmer___: well, sure, but if you know svn doesn't support stacking, you could just catch it and tell the user outright, instead of after all the metadata is fetched
<jelmer___> mathrick: nope, that can only be done in bzr itself, as bzr-svn doesn't know when a stacking clone is happening
<jelmer___> mathrick: I've removed the FAQ from my homepage, can't find any references on the wiki though. Where did you see it?
<jelmer___> mathrick: sorry for the confusion
<mathrick> jelmer___: nah, I was wrong about the wiki
<mathrick> and no problem, it's still a good solid plugin you have there :)
<visik7> anyone using bazaar + buildout ? which parts of your project did you version ?
<jelmer___> mathrick: thanks :-)
<lifeless> visik7: the only folk I know doing that are the launchpad folk, someoe in #launchpad-dev may be able to tell you
<fullermd> Hmm...
<fullermd> Am I missing the magic to make branch: revspecs not blow up with a ReadOnlyError?
<verterok> LarstiQ: no, the installer don't include PyQt nor Qt itself, but checks if PyQt is available and [dis|en]able the qbzr option
<fullermd> igc: BTW, keywords plugin is making selftest fail, looking for now-renamed workingtree_implementations.
<jelmer____> "bzr send --format=git" works for the most part, main thing missing is support for sending more than one revision since that implies sending multiple attachments :-)
 * fullermd doesn't understand how the RevisionSpec_branch tests are passing   :|
<ronny> yo
<ronny> is there anz convention/notion to figure the "default" branch of a shared repository
<ronny> ie something semilar to trunk in svn, master in git and default in hg
<fullermd> 'trunk' is probably the more common, but I don't think there's any particular community pressure one way or another.
<ronny> hmk, so i go for try trunk, try the repo itself, then fail
<fullermd> Well, I think that's more than blown my bzr-time for this week...
<jelmer____> fullermd, good stuff
<jelmer____> fullermd: I think this is a very useful change (haven't looked at the code yet though)
<fullermd> Yeah,  I got grumpy waiting for somebody else to do it for the past 3 years, and really didn't want to touch the Real Work I should have done instead.
<fullermd> Potent combination.
<Luke-Jr> jelmer____: please re-review my patch ;)
<jelmer____> Luke-Jr, I don't see any new merge reviews..
<LarstiQ> lifeless: good, I'd personally prefer fixing bugs first so that we can upgrade in place, I agree it is a far preferable workflow
<jetole> hey guys, I just copied the wrong file over a repo file minutes after I checked it in to launch pad, how can I tell bzr to revert it back to what launchpad has on my system?
<LarstiQ> jetole: `bzr revert`?
 * jetole reads it over (although sounds right from what I remember from SVN)
<LarstiQ> if that's not what you're looking for, I didn't understand your description of the situation correctly
<jetole> no it was
<jetole> it worked perfectly
<jetole> thanks LarstiQ
<Moof> hi
<Moof> I'm trying to get to grips with something here.
<Moof> I'm goign to be developing various projects on my machine. They'll all be stored in directories in remote servers. On my local machine, can I get away with creating one repository, and storing multiple branches form different servers in it?
<NEBAP> it's possible to init a repository on a ftp server
<NEBAP> is it also possible to recursively add folders and files to it?
<NEBAP> directly on the ftp server
<NEBAP> no ideas?
<NEBAP> or is it not possible?
<NEBAP> hmm
<NEBAP> no ideas how I can add the files remotely?
<NEBAP> no one online?
<mzz> NEBAP: I think there's a plugin for that somewhere
<NEBAP> I've used the init to initialize a standalone branch on the ftp server which worked without problems
<NEBAP> then I've used checkout to create a local branch
<NEBAP> and added the necessary files there
<NEBAP> after changing some files I've commited the bind branch to the ftp server
<NEBAP> which also worked without problems
<NEBAP> but the files on the server are not changed
<NEBAP> what is wrong?
<NEBAP> the history is up to date
<NEBAP> but the files arent
<NEBAP> I've just used "bzr update" on the bound branch
 * LarstiQ discovers bugmail is a task he can do on low energy
<LarstiQ> reading/triaging
<jelmer____> LarstiQ!
#bzr 2009-07-26
<zenwryly> Since archival backup and DVCS have such similar semantics, I'm exploring using bzr for my backups.  The idea would be to collect changes locally, push them to a remote repo that holds all archival revisions, and then remove old history from the local revision.  Is there a way bzr might be able to accomodate this?
<zenwryly> err, "remove old history from the local *repo*"
<jelmer____> zenwryly, removing history is hard at the moment
<jelmer____> zenwryly, it involves rewriting the repository from scratch
<NEBAP|work> morning
<NEBAP|work> how can I install a bazaar plugin right from launchpad?
<NEBAP|work> k, I found
<NEBAP|work> is it possible to get only the head revision of a branch?
<NEBAP|work> would be usefull if I donÂ´t have to download the complete history ..
<jelmer> join #samba-technical
<jelmer> argh
<jelmer____> james_w, thanks :-)
<Adys> http://dpaste.com/71605/ ochie
<LarstiQ> jelmer____: sorry, I just had went to bed at that point :)
<jelmer____> LarstiQ, :-)
 * LarstiQ observes jelmer____ accumulating an ever longer tail
<jelmer____> LarstiQ, Freenode doesn't have SSL support and I need authentication for jelmer_, jelmer__ and jelmer___ :-)
 * LarstiQ blinks
<LarstiQ> jelmer____: I see :)
<ronny> anyone remembering the specific reason for .bzr/branch/tags being a set of netstrings?
<DaffyDuck_> When I commit files, the files in the bzr repo get wrong permissions. This means that other users can't read/write the repository. Can these kind of things be solved with post-commit scripts?
<lifeless> moin
<lifeless> DaffyDuck_: they could, but why are they getting the wrong permissions?
<DaffyDuck_> Because of users' umask, I guess.
<DaffyDuck_> The problem doesn't occur when using the repositories remotely (bzr+ssh). But as soon as someone tries to work with the repository locally on the server, the permissions  get screwed up.
<lifeless> DaffyDuck_: you could set their umask in bzr itself I guess
<ronny> what api should i use if i want to do something like "bzr branch"
<lifeless> or file a bug; I thought we used to have a facility to control this
<lifeless> ronny: foo.bzrdir.sprout
<DaffyDuck_> lifeless: Yes, in some cases it appears to be handled correctly, but in others it is not. I have filed a related bug, but no one has commented on it yet.
<lifeless> ah, well I'm sure we'll get to it soon
<DaffyDuck_> lifeless: Under normal circumstances we're working remotely, so this slight problem won't stop our conversion from subversion to bazaar. But sometimes when I'm anyways peforming work on the server, I'd like to be able to use the bazaar repositories without worrying about doing bad things to them in the process.
<lifeless> DaffyDuck_: you could try setting your umask; if thats it then nothing bad will happen to them
<lifeless> you could even replace bzr with
<lifeless> #!/bin/sh
<lifeless> umask <>
<lifeless> bzr.orig $@
<DaffyDuck_> lifeless: Yes, I've thought of that -- but it has its potential problems. I would prefer if bzr handles all the permissions as it knows best how to.  Looking at some of the change logs, it appears that bazaar does have some sort of infrastructure to manage permissions in repositories.
<DaffyDuck_> I get the feeling that it's just that no one has come around to using those systems everywhere.
<lifeless> setting the umask to allow group write shouldn't cause any problems for bzr
<lifeless> if it does, they are definitely bugs
#bzr 2010-07-26
<spiv> Good morning.
<ptman> is it possible to checkout only a subdirectory of a repository in bzr like it is in svn?
<ptman> I tried looking in the documentation and faq but didn't really find an answer
<GaryvdM> ptman: you can use a filter, but it is not going to save bandwidth.
<ptman> ok, thanks
<GaryvdM> Bla - I can never get rebase to do what I want.
<jelmer> GaryvdM, what are you trying to do ?
<GaryvdM> Hi jelmer
<GaryvdM> I commit a revision (call it A) and then merge rev M and then commit B and C. So I have A M B C
<GaryvdM> I wan A B C
<GaryvdM> I want to lose the merge
<GaryvdM> jelmer: lp:~garyvdm/bzr/bzrw
<GaryvdM> The merge was just a temporary thing, with I ment to uncommit.
<GaryvdM> I wish I could do bzr rewrite -r 5344..5346 --onto 5342
<jelmer> GaryvdM: patches welcome :-)
<GaryvdM> Ok
<maxb> oh, you want rebase to sever the parentage of the start of the range
<maxb> yeah, tricky
<maxb> well, not tricky, just not exposed in the UI, I guess
<GaryvdM> I cant seem to work out  what to put into the upstream_location to trick it to do that.
<jelmer> GaryvdM: you'd want rewrite, not rebase (except that doesn't have --onto yet)
<GaryvdM> jelmer: Hmm - I don't have a rewrite command. I installed with apt-get. Busy installing from source.
<GaryvdM> jelmer: I've install from source, but I still don't have a rewrite command (using lp:bzr-rewrite)
<GaryvdM> http://pastebin.org/420172
<jelmer> ah, sorry - I meant replay
<jelmer> rewrite is a hypothetical command at this point
<GaryvdM> Ah - Ok
<GaryvdM> jelmer: Thanks - I came right. One can use uncommit -r && revert to simulate --onto.
<GaryvdM> Hi jam.
<jam> morning GaryvdM
<GaryvdM> jam: I would like to connect to the ec2 machine from home. I tried to do a ssh tunnel through work, but I could not get it to work.
<GaryvdM> Please could you add my home ip.
<GaryvdM> jam: I'm building a bzrw test.
<jam> GaryvdM: I should mention that I think 2.2rc1 is going to be this week
<GaryvdM> Ok - I'm actualy on leave this week.
<GaryvdM> So I'm hope fully going to do a bunch of bugfixes for qbzr :-)
<jam> GaryvdM: if you have a break from using the ec2 instance, let me know. I'm using the more expensive instance because I thought we wouldn't keep it running 24x7.
<Crshman> Hey guys, is there a way to apply a patch generated from a git user to a bzr repo?
<Crshman> nvm, I figured it out
<jelmer> Crshman: The plan is to be able to use "bzr pull" or "bzr merge" on git patches, but that change hasn't landed yet
<Crshman> jelmer: thanks, It turned out to be something trivial
<Crshman> i was using -p0 rather than -p1
<Crshman> I wish the git-bzr connectors worked a little better
<Crshman> Is there an official 2.2b4 package for ubuntu 10.04 ?
<mkanat> bzr should support UTF-8 in checkin messages, right?
<jelmer> mkanat: Yes.
<mkanat> I thought so. One of my developers' checkin messages looks like cp1252 instead.
<mkanat> And he claims that he used the same editor he uses to write localizations, which are in UTF-8.
<mkanat> For a smart server, does it do something like use the LANG and try to translate from the console encoding into UTF-8?
<mkanat> (Which could be problematic for doing "bzr commit" on a remote branch when your local terminal has a different encoding.)
<jelmer> Internally everything is utf8, so the commit command converts from the terminal encoding to utf8 and then passes that on to other functions in bzrlib
<mkanat> Okay. But in this case the "terminal encoding" will be the server's encoding, not the client's encoding, right?
<mkanat> Or is it converted on the client?
<jelmer> it's converted (at least it should be) on the client.
<mkanat> Ahh. So if the client is a Windows machine, even if the editor believes it's writing UTF-8, bzr will interpret it as cp1252.
<jelmer> well, it depends on what bzr thinks the terminal encoding is I think
<mkanat> Sure, but on Windows, if it's using OutputCP, it will almost always be cp1252. I mean, terminals are pretty much never UTF-8 on Windows.
<jelmer> it might only be converting if you use -m, not if you use an editor
<mkanat> Ahh, hmm.
<jelmer> but I'm speculating at this point..
<jelmer> rather, s/speculating/guessing/
<mkanat> Yeah, so am I--I'm not the person having the problem. :-)
<mkanat> But I am going to file a bug and point him at it.
<mgz> feel free to subscribe me to that bug, can probably fix it relatively easily.
<mkanat> mgz: Okay.
<mkanat> mgz: I don't know your lp name, but here's the bug: https://bugs.launchpad.net/bzr/+bug/610229
<ubot5> Launchpad bug 610229 in Bazaar "Commit messages on Windows are interpreted as cp1252 even if they are UTF-8 (affected: 1, heat: 8)" [Undecided,New]
<TodoInTX> this is probably a n00b question but I haven't found the answer in google yet... does anyone know how to relate a specific revision number to the tag that it's under ?
<TodoInTX> i.e.  Rev = 1700.87.1  tag would be something like  mysql-5.1.22-ndb-6.2.9
<samd_> hi, is this the right place for some questions aobut bzr serve?
<jelmer> samd_, yes, sure
#bzr 2010-07-27
<samd_> jelmer: thanks, im trying to set up a personal server, i made up a upstart job to start bzr serve on boot, the upstart job executes the command "bzr serve --port=1234 --directory=/srv/bzr/repo", im able to log, branch just fine, i just cant push anything, i get the error "ERROR: Cannot lock LockDir(filtered-44592336:///quiniela/.bzr/branch/lock): Transport operation not possible: readonly transport"
<samd_> jelmer: i can push just fine using sftp://host/project method just fine
<samd_> i guess im missing something about authentication/permissions or something
<jelmer> samd_: You need --allow-writes
<jelmer> samd_: but please note that that will allow write access to anybody who can connect to that port
<samd_> jelmer: ohh, i see, thank you very much, yeah i see that risk, so id be better be using sftp as it provides authentication, or there's a way to add authentication to bzr serve?
<samd_> jelmer: ooo im seeing this on  the man page, it seems like authentication has to be implemented externally, thank you very much, i apreciate your help
<doug> hulo
<doug> where's the Right Place to put a push(commit) hook?
<doug> especially if i'd prefer everyone i put on the server to be using it w/o additional setup
<doug> a'la svn post-commit-hook
<doug> mmm, a bit harder than i'd think.
<mkanat> doug: See "bzr hooks"
<mkanat> doug: You probably want post_change_branch_tip.
<mkanat> doug: If you're somehow enforcing use of the smart server, then installing it globally on the server will enforce its use.
<GungaDin> how should the output of 'bzr blame' be read?
<spiv> GungaDin: with delight! ;)
<GungaDin> :)
<GungaDin> I don't really understand how to read it, to be honest.
<GungaDin> some lines have revno.something.something name next to them..
<GungaDin> some don't...
<spiv> Actually, I mainly use 'bzr qannotate' (or 'bzr gannotate', I'm not very loyal...), because it's a bit more convenient to view it as a GUI format.
<spiv> A run of lines from the same revision only have the top line marked, to keep the output a little easier to read.
<GungaDin> my bzr doesn't understand these commands.
<spiv> Install the qbzr (or bzr-gtk) plugins to get them.
<GungaDin> but there is revid.x.y
<GungaDin> what's x & y?
<GungaDin> and why is it that bzr st -c revid doesn't indicate this file was changed?
<spiv> Dotted revision numbers are explained here: http://doc.bazaar.canonical.com/latest/en/user-guide/zen.html#understanding-revision-numbers
<spiv> Not sure why 'bzr st -c revid' wouldn't show a change in that case, though :/
<fullermd> If you weren't putting in the whole revno, just the first segment.
<michaelh1> Afternoon.  I'm looking at building the same bzr branch on three machines, each with different architectures
<michaelh1> I want to build continousally, and throw the branches away quite often
<michaelh1> Can I put some type of cache in the middle to cut the download time?
<michaelh1> Ah, figured it out: run a mirror branch and branch off that
 * spiv celebrates the netsplit by going to lunch
<schlangen_> hey, I've messed up sth with bzr(gui?) and now I've got 3 dead heads. what shoud I do (or read)?
<GaryvdM> schlangen_: You can merge dead heads with merge -r revid:....
<wgrant> But, in general, dead heads are not a problem.
<LeoNerd> E.g. every 'bzr uncommit' operation will create one
<wgrant> They might just indicate that you've used 'bzr uncommit' at some point, for example.
<wgrant> Right.
<GaryvdM> I just checked, and I have 72 dead heads in my qbzr repo. I use uncommit alot...
<schlangen_> but its my active code! I did some local commits, then an update and all my local changes where gone
<LeoNerd> Indeed. They're not causing any damage.. They're just dead-ends in the branching path that represents your history
<schlangen_> like here: http://srtsolutions.net/blogs/chrismarinos/archive/2008/10/24/don-t-loose-your-head-with-bazaar.aspx
<LeoNerd> If you really care about them, you can 'bzr push' the branch elsewhere, then move the directories around. 'bzr push' will only see the live revisions, so skip over the dead ones
<LeoNerd> All this will do is save you a bit of disk space
<GaryvdM> schlangen_: So that can happen if you do bzr update, and then bzr revert before you commit.
<wgrant> If you 'bzr update' with local commits, your local commits will appear as a pending merge.
<GaryvdM> schlangen_: If they are stuff that you need, then merge them.
<schlangen_> don't know if I did revert, maybe (new to bzr and don't really like the gui, but have to work on win for few days)
<schlangen_> so how can I fix it now and get all my changes back to "normal" commit history?
<GaryvdM> schlangen_: bzr merge -r revid:<revid of dead head>
<GaryvdM> sorry
<GaryvdM> schlangen_: bzr merge . -r revid:<revid of dead head>
<schlangen_> ok, I'll try
<schlangen_> GaryvdM: yay, I think it worked :D thanks
<GaryvdM> Hi mgz
<mgz> hey gary.
<GaryvdM> Could you please test a build for me. I'm at home, and my windows machine is at work.
<GaryvdM> mgz: http://dl.dropbox.com/u/4494367/bzr-2.2b4-bzrw-setup.exe
<mgz> getting.
<mgz> what did you change?
<GaryvdM> Thanks. Add a windows target, bzrw.exe, so you can run bzr explorer, with out having a console window open.
<GaryvdM> lp:~garyvdm/bzr/bzrw and lp:~garyvdm/bzr-windows-installers/bzrw
<mgz> well, seems to work, but still need to shell execute `bzrw.exe explorer`
<mgz> would be nicer if just had something called explorer.exe that double clicking on worked with
<GaryvdM> mgz: The start menu/desktop short cuts should have been changed?
<mgz> ah yes, that's fine.
<GaryvdM> mgz: I've also had request from people who want to run bzrw qlog, or bzrw qpull...
<GaryvdM> So I think that a generic command is better.
<GaryvdM> I also want to get rid of tbzrcommandw.exe and tbzrcommand.exe. They tbzr should just call bzrw.exe directly.
<GaryvdM> mgz: Thanks for testing that for me. I'm going to post to the mailing list.
<jam> morning all
<rubbs> morning jam
<GaryvdM> Hi jam
<jam> hey GaryvdM
<GaryvdM> jam: If I have KnownGraph object, what would be the best way to do an is_ancestor query?
<jam> GaryvdM: heads()
<jam> head = kg.heads(x, y)
<jam> if head == x: then y is an ancestor of x
<jam> if heads == (x, y) then neither is an ancestor, etc
<GaryvdM> jam: So Is it ok to be reimplementing Graph.is_ancestor?
<jam> GaryvdM: if you look, it is just doing a heads call itself
<jam> I think somebody was wanting a clearer statement in code
<jam> but it is really is a single line function
<jam> also note, that it will be more efficient than doing "is_ancestor(x, y), is_ancestor(y, x)"
<jam> but I don't know what *you* want isancestor for
<GaryvdM> jam: If the user has qlog open with more than one branch, an the right click, and chose say tag, I only want to show the branches for which the rev is an ancestor.
<GaryvdM> For merge, only the branches which it is not an ancestor.
<GaryvdM> For cherry pick, not
<GaryvdM> for reverse cherry pick, is
<GaryvdM> etc.
<jam> GaryvdM: so in those cases, you can probably check across multiple branches simultaneously
<jam> maybe not
<GaryvdM> jam: Ah - right.
<jam> You could tell if it was an ancestor of one of the branches, and if the branches were related, but I think it would get muddy to tell if each branch was an ancestor, etc
<jam> however, kg.heads() is *much* faster than Graph.heads()
<jam> the latter is known to be O(N^2)
<_Andrew> hi, is there a way to revert all the file permissions changes in a repo? I have a bzr repository from windows and viewing it on ubuntu just shows everything as modified
<jam> _Andrew: unfortunately, the easiest thing to do is to "bzr co --lightweight onto a non fat/ntfs partition"
<GaryvdM> jam: A cool - kg.heads caches it's self.
<jam> GaryvdM: yeah, though it may not actually need to. I think it was useful for annotation where you get the same requests many many times
<jam> which was the original kg motivation
<_Andrew> damn, thanks anyway
<jam> _Andrew: Under Linux we trust the filesystem to report executable bit properly
<jam> which we shouldn't, but that is how it is for now
<jam> (it sounds like mounting -x might also help)
<jam> GaryvdM: so are you still done with the ec2 machine for now?
<GaryvdM> jam: Yes
<GaryvdM> jam: Please shut it down.
<jam> thanks
<jam> creating a snapshot and shutting down now
<jam> spiv: what are you doing up so early?
<Meths> Can you make a checkout forget a push location? (without overwriting with another)
<jam> Meths: bzr push --remember
<Meths> Nope, that just pushed to the already stored location
<jelmer> jam: hi
<michaelh1> Hi there.  I'm a bit worried about the memory/CPU bzr is using - I'm doing a checkout and it's sitting at 600 MB of RAM and 50 to 100 % CPU
<michaelh1> It's a really large branch, but still
<poolie> this is linaro-gcc?
<poolie> you should try with 2.2b4 if you're not already
<michaelh1> OK.  Will do.
<poolie> it has some memory use improvements over 2.1
<poolie> not sure if that's in maverick yet
<poolie> or if you're on maverick :)
<michaelh1> Ah, this is a server so it's on Lucid
<poolie> ok
<poolie> we may not yet have it in the ppa
<michaelh1> I'll be chrooting into maverick later on
<poolie> you could build from source if you want
<poolie> if you want file a bug tagged linaro
<michaelh1> I'll see how 2.2b4 goes
#bzr 2010-07-28
<michaelh1> Hmm.  bzr branch -v lp:gcc-linaro/4.5 as part of creating a mirror branch is sitting there at 1kB/s after about 300 kB.  I see the same on a machine with a good network connection like chinstrap
<michaelh1> Ah!  It hit ~380 kB, finished the 'fetching revisions' stage, and is now at ~1MB/s
<michaelh1> Hi there.  I could use some help with performance.
<michaelh1> I'm working on the gcc-linaro branch, which is huge, and pull and/or checkout operations take a long time
<michaelh1> A pull on one machine has been in the 0/3 merge phase for the last 15 minutes
<michaelh1> 2.2b4 is much better, but still too slow with how I'm using it
<poolie> spiv, can you help michael?
<spm> ref http://www.mail-archive.com/bazaar-commits@lists.canonical.com/msg07202.html <== I'm sure there's a page on the bzr wiki/docco somewhere that describes this - using bzr/tc for slow networks etc, but am having finders failure; anyone have a link handy?
<poolie> hi spm
<spm> heya poolie
<poolie> well the specific thing that patch is updating is http://doc.bazaar.canonical.com/bzr.dev/developers/testing.html#simulating-slow-networks
<poolie> there may be other pages that mention it
<spm> ahh perfect. that looks like the one I was looking for. ta!
<poolie> i'd like to believe there's a good reason the syntax is so obtuse :)
<spm> "because"
<lostinspace_46> This will sound really stupid, but I want to get the grub 2 graphical manager from a bazaar branch, and I can't figure out how
<ddaa> maybe "bzr branch lp:grub"
<ddaa> or maybe the "graphical manager" is something else
<ddaa> Oh, btw, someone at Canonical should really redraw the icon of the "VCS Imports" user, it does not make sense anymore since we switched away from GNU Arch.
<spiv> Hmm, I have some productively failing tests.  I guess that's a good time to clock off for the day.
<VSpike> Having trouble using mv --after here... can anyone help? http://pastebin.com/wvjdKR2R
<jelmer> VSpike: That file isn't versioned, you can't use 'bzr mv' to move it
<VSpike> jelmer: if you look at the "bzr st" output, it lists deployment/connections.geonixlocate.config as a removed file
<jelmer> VSpike: if it's removed, you have to revert it again first before moving it I think
<VSpike> Hm I'm sure I've never had this problem before. In fact, I succesfully did it in this branch with other files that I'd moved and then wanted to tell bzr about
<jelmer> I'm not sure in that case.
<VSpike> jelmer: this doesn't look good, does it? http://pastebin.com/GS4ztGni
<VSpike> I moved the files back to where they were before and that is the result
<jelmer> VSpike: You need to re-add ("bzr add") them
<jelmer> VSpike, Right now some of those files are present but not versioned, hence them showing up in "removed" and "unknown"
<VSpike> If I re-add them, then the show in removed and added
<VSpike> But surely I will still lose the history of the file that way?
<jelmer> VSpike: "bzr revert" should be able to help
<VSpike> Normally if you remove a file and bzr st shows it removed, if you put it back it just vanishes from the bzr st output
<VSpike> Yeah, I was thinking that.  Because they were moved and changed, I'll have to rename the new versions, revert the removed ones, copy the changes in, then bzr mv them
<VSpike> Well, worth a try anyway
<VSpike> seems to have worked :)
<jam> hi jelmer
<jam> (4am is usually a bit early for me to respond :)
<jelmer> jam: 'morning!
<sinasalek> Hi everyone
<jelmer> hi sinasalek
<sinasalek> I have a question about branches located inside repositories
<sinasalek> When i push a branch into a repository it act like a working copy
<sinasalek> Is it possible not to have files checked out on branches inside repository.
<sinasalek> ?
<sinasalek> Is my question clear?!
<LeoNerd> If you e.g. ssh on to the repository server and "bzr checkout" in that branch directory, a checkout will be created yes
<LeoNerd> But... "bzr push" from elsewhere (or the implied push that happens during a bound commit) will not keep that checkout updated
<LeoNerd> So it will become stale, unless you find some other mechanism to "bzr up" it each time
<sinasalek> Tx but that wasn't what i meant. lets ask it in another way. How can clone a branch but only clone its working tree and not the checkout files inside it?
<sinasalek> And another way!
<sinasalek> Reproducing
<sinasalek> 1. Create a shared repository
<sinasalek> 2. Create a trunk branch inside it
<sinasalek> 3. Push a checked out branch else where to trunk
<sinasalek> What i expected?
<sinasalek> I expected push to only copy the working tree of the "checked out branch" and not the checked out files inside it.
<sinasalek> Why do i need it?
<sinasalek> To preserve disk space, checkedout files are not compressed
<sinasalek> Any idea?
<sinasalek> In subversion repository is only repository you can't use it directly for development. If you want to you have to checkout a branch on another location. In bazaar however it's different.
<sinasalek> How can i make bazaar repository to act similar to subversion (to only contain working trees and not checked out files!)
<sinasalek> chx: I'm looking for a command or a switch to ignore the checked out files
<terrycojones> anyone up for looking at problem i'm having with bzr merge?  explanation at http://dpaste.com/222815/
<terrycojones> in summary: diff of two files looks fine, but the conflict shown by bzr merge does not (it's missing a line). i guess i must be doing something wrong... but don't know what.
<sinasalek> http://pastebin.com/KFWfDGVW
<sinasalek> Does any one have time to have a look at my repo structure and lighten with his vauable advices? http://pastebin.com/VfK7KCbY
<rubbs> sinasalek: I'm not sure I understand your question, you are looking to make a repo that is just for servers? one without a working tree? You just want the revision history so people can checkout from it correct?
<rubbs> sinasalek: if so, than bzr init-repo --no-trees will create a repo with no working files, just the revision history.
<sinasalek> rubbs: yes exactly! thanks
<rubbs> sinasalek: np
<rubbs> sinasalek: also, there is no magic repo structure, anytime you branch ( or clone) from the repo, you create your own repo. It's kind of hard to understand at first, but once you understand it, it becomes that much more clear
<sinasalek> rubbs: Yes it seems that i still have problem understanding how bazaar works exactly :) i thought that working tree was the same thing as revision history in bazaar!!
<rubbs> sinasalek: it's hard, took me a while. Just keep asking questions, someone here will help you out
<rubbs> basically think of each branch as it's own repo. You get your own personal repo each time you branch
<rubbs> you actually merge repos when you merge branches... or at least that's how I conceptualize it
<sinasalek> rubbs: i see,  with people like you around i'm not worried at all ;)
<fullermd> That...   sounds like it would just be more confusing in the long run...
<rubbs> fullermd: well, I should clarify, that's how i used to conceptualize it. it's enough to get started at least
<fullermd> Actually, it makes me crosseyed on the short run too   :p
<rubbs> fair enough.
<rubbs> DVCS is hard to nail down one good way to conceptualize IMHO
<fullermd> sinasalek: I'd like to know if http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief is any help to you.
<sinasalek> rubbs: Aha! it's good! i read dozens of documents but i didn't see this one!
<rubbs> oh, thank fullermd not me ;)
<sinasalek> :)
<rubbs> I didn't know about that one either, fullermd. I'll use that for further questions, thanks.
<sinasalek> fullermd: Aha! it's good! i read dozens of documents but i didn't see this one! DVCS is a hole great new world
<sinasalek> fullermd: why don't yuo move it to official doc? it's very helpful for newbies
<fullermd> The SpotDocs are an ongoing (in the sense of "not done", sadly not in the sense of "I get a lot of time to keep working"  :(  ) project of mine to try and give complete answers to specific questions.
<fullermd> The PiecesIn* bits are groundwork below that to nail down vocabulary and base concepts.
<sinasalek> fullermd: This is great work you're doing. Are you on Bazaar doc team?
<fullermd> Oh, no.  I've just used bzr for a while.
<sinasalek> rubbs: i just tried bzr --remove-tree  an it has fixed!!! This was one of my few major issue with bazaar. Thanks man you rock
<rubbs> sinasalek: np. glad to hear you're making progress
<sinasalek>  fullermd: You should notify them about your work, they might be able to give you a hand and include at least part of it in official doc
<fullermd> Oh, it's known.  It's jut very much a WIP (and I'm not quite sure it really fits into any good slot in the existing official doc gestalt)
<sinasalek> My article has quite some visits, i included a link to your doc page. least i can do. keep up the good work :) http://sina.salek.ws/node/1314/revisions/1459/view?diff=1
<sinasalek> Do you consider Bazaar 2.2b4 stable enough to use?
<fullermd> Well, I track the dev head, so...
<jam> sinasalek: yes
<jam> the beta means that we are allowed to change internal apis
<jam> so plugins may not work
<jam> etc
<jam> it doesn't mean the code is actually unstable
<sinasalek> jam: I tought that was what alpha is for
<sinasalek> fullermd: You mean you're using dev?!
<fullermd> No, alpha is for sacrificing on an altar to try and get people to buy Itanium  ;p
<jam> sinasalek: bzr.dev (the trunk branch) must pass its full test suite for every revision
<jam> most of the developers use it (dogfooding)
<sinasalek> jam: That's great, i'm ok with crashes as long as it does not corrupt my repo
<jam> sinasalek: nothing to worry about for repo corruption
<sinasalek> jam, fullermd: thanks , lets try it then :)
<mtaylor> bzr bd - I've got a branch which is working fine for both me and several other people, but one guy gets:
<mtaylor> <letterj> mtaylor: bzr: ERROR: Unable to find the needed upstream tarball: swift_20100728203750.orig.tar.gz.
<mtaylor> it's using pristine-tar/import-dsc and all... he has the same version of bzr-builddeb I have - any ideas on where to look?
<jam> mtaylor: do you already have the .orig.tar.gz laying around on your system?
<jam> If you move it out of the way, and run again, does 'bzr bd' still work ?
<poolie> mtaylor: perhaps it's an out-of-date version of builddeb?
<jam> hi poolie
<mtaylor> jam: I tried in a completely fresh dir
<poolie> otherwise i'd look at the traceback in that error to see just what it's checking
<jam> mtaylor: does that include not having it in the parent dir?
<jam> IIRC it always looks in ../ for the .orig.tar.gz
<mtaylor> jam: yup
<mtaylor> jam: I went to a completely unrelated tree
<mtaylor> poolie: same version of builddeb - although I will say that what apt says the version is and what bzr says the version is do not match
<jam> mtaylor: and your bd output *does* include a line about 'pristine-tar' ?
<jam> mtaylor: that would indicate a plugin vs a system-wide install
<jam> (probably)
<mtaylor> jam: <letterj> started back from scratch and repulled the code. A dependency error came up for python-all.  Fixed that and everything worked ok
<jam> mtaylor: well then, no problems here :)
<mtaylor> jam: $ bzr plugins | grep builddeb
<mtaylor> builddeb 2.2.0
<mtaylor>  apt-cache policy bzr-builddeb
<mtaylor> Installed: 2.4.2
<mtaylor> also - I cleaned out my ~/.bazaar/plugins dir
<mtaylor> this isn't bothering me - I just thought I'd let you know about it while we were talking
<jam> mtaylor: bzr plugins -v should also show you what plugin it is loading
<jam> It is also possible that somebody updated one version string without updating the other.
<mtaylor> jam: /usr/lib/python2.6/dist-packages/bzrlib/plugins/builddeb
<jam> I think I saw something recently from statik that hard-coded a version in setup.py and didn't use the one from package/__init__.py, which is certainly the type of thing that can cause skew.
 * mtaylor pokes statik in the eye
<jam> I'm not sure if that is bzr-builddeb or another project right now
<jam> poolie: you seem to be back in your regularly scheduled TZ. How were your flights?
<poolie> hi there jam; they were pretty tolerable
<poolie> qantas sent me a voucher as an apology for the long delays on the way over, which was nice
<jam> poolie: I'm past due on stopping for the day, but it would be fun to chat when we can get a chnace
<jam> chance
<poolie> ok, i'm away tomorrow to visit igc
<poolie> i'll try to be online early tuesday and we could talk then
<poolie> or you can call me later tonight
<james_w> mtaylor: it's possibly an issue with the version of pristine-tar, but I guess you are on the same version?
<mtaylor> james_w: it got sorted... somehow it was a missing python-all
<james_w> ah
<james_w> odd
<poolie> python-all was not installed?
#bzr 2010-07-29
<mtaylor> does a tag get associated with a revid or a revno?
<jelmer> mtaylor, a revid
<mtaylor> ok. good
<mtaylor> I just had a brief hrm
<poolie> hey spiv
<poolie> feel free to do some more merge cleanups after your submission :)
<poolie> on a brief readthrough that patch looks fine
<spiv> I will :)
<poolie> i'm going to keep scrubbing add
<poolie> if i can stay awake  :)
<spiv> It's daytime in Europe, should be no problem ;)
<poolie> hm
<NET||abuse> hmm, pushing bzr repo's up to my web server seems to be very slow and i'm never certain it'll work
<poolie> NET||abuse: over what protocol? what goes wrong?
<NET||abuse> ssh
<NET||abuse> it just hangs for ages
<NET||abuse> it worked this time,, but i've often had it push up most of the files,, then it just hangs,, i ctrl+c out of the process after an hour,, but the files seem to have been put up
<NET||abuse> i just feel worried at this piont that there's an error in my repository somewhere
<NET||abuse> i run bzr check on the repo
<NET||abuse> and it comes back clean
<NET||abuse> it's just really weird
<AfC> NET||abuse: you have full shell on the target server? If so, why not go there, bzr init-repo a new reository, bzr branch in whatever's already there (to pre-popuplate it), and then try your over the wire push again
<AfC> [ {shrug} ]
<NET||abuse> AfC, that's a good suggestion, i'll try that the next time i'm pushing up
<NET||abuse> should be in the next 24 hours i'll be doing that again :)
<NET||abuse> the repo i was pushing up was about 80MB
<NET||abuse> so it wasn't too small
<AfC> not too big, either
<NET||abuse> yeh, but over my teathered android phone connection :)
<NET||abuse> on the bus on the way to work :P
<AfC> urgh
<NET||abuse> hehe
<AfC> Ok, well it's TCP that's burning you.
<NET||abuse>  :) hmmm i see
<AfC> 3G UTMS is famous for dropping long duration connections at Layer 1 and/or Layer 2 (which then reestablish) but which
<AfC> will result in TCP interpreting that as lost traffic (due to late or lost return ACKs)
<NET||abuse> should bzr maybe have a little more in the way of timeouts and retry methods?
<AfC> which will result in traffic congestion kicking in,
<AfC> which will result in TCP thinking you're available bandwidth is sqrt(fuck all)
<AfC> NET||abuse: it's got nothing to do with Layer 8
<NET||abuse> hmm, ok
<AfC> NET||abuse: there's nothing bzr (or your web browser, or wget, or anything else) can do
<NET||abuse> right fair nuff
<AfC> if your network connection is lossy or "randomly" delays packets
<AfC> TCP/IP, right?
<NET||abuse> i'll have to push with git or other things for a while and see how that behaves..
<AfC> Should be TCP vs IP
<NET||abuse> TCP vs IP?
<NET||abuse> how do you mean?
<AfC> Bazaar works *VERY* hard to do the right thing and is optimized for a) not losing things, b) performance over stable links
<AfC> if you've got an unstable link, well, all bets are ff
<NET||abuse> that's fair enough
<AfC> because bzr+ssh rides over SSH which rides over TCP and TCP (by its design) cannot push large data volumes over lossy links.
<AfC> and 3G modems are right back to the dark ages as far as actual link stability is concerned.
<NET||abuse> i thought that it's design was good for exactly that? as opposed to udp
<AfC> TCP will guarantee (mostly) delivery
<AfC> of what it thinks the best average rate it can get away with is
<AfC> if you're losing (say) return ACKs
<NET||abuse> well the phone is the htc desire, so it's the H connection,, is that HSDPA or something else?
<spiv> TCP copes very well with a very small percentage of dropped packets.
<AfC> then it'll think that the available bandwidth is miniscule.
<AfC> spiv: yeah
<AfC> indeed, its designed to loose .... one
<AfC> which is when it decides it's reached it's limit. Then it backs off one, tries again, etc
<AfC> linear & sawtooth
<NET||abuse> according to htc it's call HSPA/WCDMA
<NET||abuse> they dropped the D?
<AfC> spiv, NET||abuse: Paul Drain pointed me at a paper written by Glen Turner on this topic; you might enjoy it <http://www.gdt.id.au/~gdt/presentations/2010-07-06-questnet-tcp/glen-turner-tcp-performance-notes.pdf>
<AfC> I've been doing a lot of work network tuning lately, so it was timely.
<AfC> spiv: (do you know [of] Glen?)
<AfC> spiv: frequent voice on linux-aus, etc
<NET||abuse> that's an interesting read,, thatnks :)
<NET||abuse> quick question,, obviously this is #gzr so there's a bias, but is there a set of circumstances where you'd choose git over bzr?
<NET||abuse> or what task types do you use each for?
<AfC> NET||abuse: no
<AfC> none whatsoever
<AfC> ever
<AfC> [we comprehensively rejected Git ~2006, and remain pleased with that call]
<AfC> but that's just my firm. Others will be more even handed in a perceived need to be even handed for some reason. :)
<spiv> AfC: I've occasionally seen the name on mailing lists, but that's all I think.
<AfC> spiv: he's good people
<NET||abuse> ok, auto deployment,, i push a repo up to a test domain on a web server, so i can show a client or someone, i push up to a repo, it's adjacent to my webroot dir, i want to update the working copy on the remote server any changes, and then deploy to the app and webroot directory the relevant directories in the working copy
<NET||abuse> so my server under /var/www/mydomain/   has a www/ dir    the bzrrepo/   and i have a static copy of cakephp libraries there, and i have the app/ directory outside of the cakephp directory
<NET||abuse> if i want to script a post receive push hook on the remote repo,, is there a good way to do that?
<spiv> Write a plugin to use Branch's post_change_branch_tip hook, install it on the server.
<spiv> (and use bzr+ssh to push, if you haven't already)
<spiv> (Or possibly take a completely different approach and use bzr-upload on the client to just upload files rather than pushing branches?)
<NET||abuse> spiv, yeh, i use bzr+ssh already :)
<soren> Tags are not part of the revision data, are they? They're kept as a separate index somewhere, right?
<soren> So if I merge a branch that has some extra tags in it... Do I get those tags, too?
<poolie> soren: yes
<maxb> Tags are pretty much a dictionary of name->revid that is kept in a *branch* (not a repo)
<soren> poolie: Ok. Are there other things that do not show in "bzr diff" that I might be getting when merging a branch?
<maxb> I am unsure, but signatures, perhaps?
<soren> maxb: I'm not sure I understand the difference between a branch and a repo.
<soren> In fact, I'm sure I don't understand :)
<maxb> A repository is a store for revisions. Nothing more, nothing less.
<maxb> A branch is a pointer to a specific revision id (the tip of the branch), plus tags
<soren> I see, ok.
<maxb> signatures go... somewhere. I'm not sure. I don't use them
<soren> The reason I'm asking is that we (OpenStack) have a trunk that is handled by Tarmac. Someone submitted a branch with some extra tags in it, intending for those tags to be in the trunk, too. After the merge, the tags are not there.
<maxb> soren: that's a little odd. I would *expect* a bzr merge to copy all (non-conflicting) tags
<soren> ...and I'm trying to work out if that expectation was reasonable at all, and if so, what the problem might be.
<maxb> However, if tarmac runs bzrlib functions, not the bzr command line, it's possible it fails to also run the stuff that merges tags
<soren> maxb: https://code.edge.launchpad.net/~mordred/nova/release-0.9.0/+merge/31168
<soren> maxb: Tarmac does call bzrlib functions, afaics.
<soren> maxb: Branching the proposed branch reveals the tags.
<soren> maxb: Branching the trunk (which has the proposed branch merged into it now) shows no tags at all.
<spiv> soren: it is a reasonable expectation, and suggests a bug in Tarmac (or the bzrlib API it is relying on)
<maxb> It sounds to me like the first thing to do is to investigate whether tarmac *ever* merges tags
<maxb> It is soundling like it does not
<spiv> I think PQM had (has?) a similar issue.
<soren> spiv: I checked the bzr trunk, and it definitely has tags in it.
<soren> spiv: IIUIC, they cannot have gotten there by any other means than PQM?
<spiv> Assuming PQM is the only way that branch was ever written too...
<soren> Right.
<spiv> s/too/to/
<soren> Well, there are recent tags, even. I imagine cowboying pathes onto the trunk would have been a thing of the distant past by now.
<soren> builtins.py:cmd_merge does seem to take special care to merge the tags.
<soren> Yet tarmac seems to just call tree.merge_from_branch(...).
<soren> *headdesk*
<soren> mtaylor already reported that bug.
<soren> ...and rockstar apparantly fixed it.
 * soren is always a step behind :)
<bialix> hello bzr!
<jelmer> Hi bialix!
<jelmer> Haven't seen you in a while, how have you been?
<bialix> Heya jelmer! recently has returned from vacation
 * bialix just finished to read mails
<GaryvdM> Hi bialix!
<mgz> anyone know what Jonathan Lange's irc nick is?
<GaryvdM> mgz: jml
<jml> hello mgz
<mgz> thanks! saves me bouncing on things via email.
<bialix> Heya GaryvdM, mgz~
<bialix> Heya GaryvdM, mgz!
<mgz> jml: there are a few things that need shaking out still with the testtools unicode traceback stuff
<jml> mgz, more than just trivial_last_time_for_this_line?
<mgz> I've got one more brown paper bag thing to fix, and you variable name error you spotted is because that's currently dead code, until I turn the shelve I have for bug 592262 into a mp
<ubot5> Launchpad bug 592262 in testtools "testtools breaks if a string exception is raised (affected: 1, heat: 3)" [Wishlist,Incomplete] https://launchpad.net/bugs/592262
<mgz> bialix: did you have a nice holiday?
<jml> mgz, hmm.
<mgz> basically, it just needed a bit of real-world testing, as there are still codepaths the unittests don't cover
<jml> mgz, well, that's not entirely true
<jml> mgz, I mean, the test suite hasn't actually passed in some time.
<mgz> hm? passes here on all the python implementations I've got.
<mgz> we managed to screw up the one line in _details_to_str like, five times without the tests catching it.
<jml> mgz, testtools revisions 74 through 80 don't pass for me on lucid.
<jml> mgz, at least, not when run with make check.
<jml> python2.6, standard build
<jml> mgz, perhaps there's a locale config issue masking the problem on your machine (or causing the problem on mine, for that matter)?
<mgz> hm, maybe that's just me being lame then.
<jml> mgz, well, it's actually me being lame for not having some kind of automated gateway that tests things before landing them on trunk.
<mgz> okay, so you're right, the tests *did* catch that one-line error (repeatedly)
<jml> they catch it by completely exploding :)
<mgz> anyway, I'll get a test and fix up for the remaining dumb error I left behind, then check what remaining shelves need acting on sooner rather than later
<jml> mgz, can you please file critical bugs for all of these?
<jml> mgz, once all this is done I want to make a release asap
<mgz> well, most of this is just minor improvements as marked by # GZ ... comments in the current source
<mgz> I'll file a bug for the current one
<jml> (race against the clock: can we do this before pypi comes back up?)
<mgz> (which is what's needed before release)
<jml> ok thanks.
<bialix> mgz: yeah, good holiday, warm sea and beautiful mountains (in Crimea). but too short :-(
<mgz> okay, nearly there
<mgz> jml: mp up.
<jml> mgz, ta.
<mgz> now I need some coffee...
<GaryvdM> \o/ New qlog feature: http://imagebin.org/107278
<hazmat> if i do an update my working copy to a previous revision, how do i tell what revision my working copy is in? bzr stat just reports 'working copy out of date', bzr revno, just shows the latest rev in the repo... is there any way to identify the revision of the working copy?
<GaryvdM> hazmat: use update, and not revert
<bialix> GaryvdM: WOW \o/
<hazmat> GaryvdM, i'm basically bisecting to find a bug being introduced.. i've bzr update -r REVNO to get to a particular revision in my working copy.. but once i do that, its not clear how i can find out what the REVNO of the working copy is from the bzr tools
<GaryvdM> hazmat: Hmm, not sure how to see it from the command line. You can see it in bzr qlog
 * GaryvdM off to hockey practice. bbl
<hazmat> GaryvdM, cheers.. sadly qlog tosses me an exception traceback , looks like a pyqt version mismatch on lucid
<hazmat> GaryvdM, fwiw traceback at http://pastebin.com/S2eNEg4r
<bialix> hazmat: you have out-of-date qbzr version
<bialix> hazmat: /home/kapil/.bazaar/plugins/qbzr [0.17.0dev]
<bialix> hazmat: please, update to latest 0.18.6
<hazmat> bialix, thanks
<hazmat> cool, so qlog does show the current revno for the working tree.. would be nice to figure out how to do this from the cli as well though
<bialix> I think there is open bug about that
<jam> hazmat: bzr revno --tree IIRC
<bialix> heya jam
<jam> hi bialix
<jam> looking good GaryvdM
<jam> now you just need a way to select a range and do the same thing :)
<bialix> yep :-)
<bialix> ~~~
<mtaylor> anybody around who can help us out a bit with tags and tarmac?
<mtaylor> I've got a trunk branch protected by tarmac, which is using lightweight checkouts of the trunk
<mtaylor> then, I make a tag in a branch, propose it for merge, and tarmac merges it in
<mtaylor> problem is-  no taggy in trunk
<mtaylor> lifeless had told rockstar a while back to change from heavy to lightweight checkouts and that everything should be fine - but perhaps we're still missing something?
<rockstar> jam, maybe you can help? ^^
<jam> rockstar: how are you doing the merge in tarmac?
<rockstar> jam, I create a lightweight checkout of the target branch, merge the source branch in, and then commit.
<jam> rockstar: 'merge the source branch in' using bzrlib ? or using bzr?
<rockstar> jam, bzrlib.
<rockstar> jam, lemme find the code.
<jam> rockstar: looking at cmd_merge, I see:
<jam>         from bzrlib.tag import _merge_tags_if_possible
<jam> ...
<jam>         _merge_tags_if_possible(other_branch, tree.branch)
<jam> So I think you have to do something like that in your code. As 'branch.merge(other_branch)' doesn't merge tags, only fs contents
<jam> anyway, I'm off to lunch, etc. I'll be back later
<rockstar> jam, great, thanks.
<jam> rockstar: you should probably only do that after the test suite passes
<jam> otherwise the target branch will get tags even if it doesn't actually merge the code
<jam> (one of the clumsy parts about our tagging scheme)
<rockstar> jam, so, I'm working with a tree, and I think that may cause complications.
<jml> mgz, you still around?
<mgz> jml: I am again now.
<jml> mgz, I've landed the MP you put up
<jml> mgz, we still need one for the sclass thing, iirc.
<jml> mgz, do you already have a patch w/ tests for that?
<mgz> right, question on that front, you've got no moral objection to handling string exception on Python 2.4 and 2.5 right?
<jml> mgz, not at all.
<mgz> ^I've got a disabled test for the main part, just need to fiddle with RunTest._run_user
<jml> mgz, cool. if ping me when that's up, I'll review & merge straight away
<mgz> my current shelve for that it probably over-ambitious, it falls down on Python 3 because traceback._some_str is still pretty basic there
<mgz> I'll pull it down to the essentials and put up a mp.
<jml> mgz, other than that, are there any other known issues with the Python 3 compat?
<jml> mgz, cheers.
<mgz> nothing else known, want to check that what was causing problems on babune on 2.7 is now resolved, but even if it isn't may well be a bzr or subuit bug, not something I've broken in testtools
<mgz> jml: mp up, and I'm just going to grab some food, but will be generally around all evening
<jml> mgz, cool. thanks.
<tbnorth> hi all - what's the status of nested branches?  Googling leaves me feeling support is incomplete / not in trunk, but I'm unsure?
<cody-somerville> why does switch require a working tree?
<rockstar> cody-somerville, why would you switch without a working tree?
<cody-somerville> basically I have a cache of branches
<maxb> Because without a working tree involved, a switch would be degenerate with a pull?
<cody-somerville> and I want to be able to take a branch in the cache and make it a 'clone' of some arbitrary branch
<maxb> pull --overwrite?
<cody-somerville> the branches are all checkouts currently
<rockstar> cody-somerville, wait, if you have a checkout, you have a working tree.
<cody-somerville> yes I do
<cody-somerville> was trying to with no working tree to see if that would avoid the conflicts and weird file moves
<cody-somerville> I can get it to work with a 'working tree' but it says every file has been moved to the same place it was before
<cody-somerville> ex.
<cody-somerville> renamed:
<cody-somerville>   project => project
<cody-somerville>   sources-list/ => sources-list/
<maxb> I'm guessing that indicates the tree root file-id has changed
<cody-somerville> yea, I'm switching between two completely different branches
<maxb> I would guess that it's a bug that bzr doesn't switch the tree root, but rather switches everything under it
<cody-somerville> Is there a difference between a checkout and a bound branch?
<fullermd> Absolutely.  Also: absolutely not.
<maxb> hah
<maxb> Well, a checkout must have a working tree involved, whereas the terminology "bound branch" doesn't specify whether there's a tree or not
<mgz> jml: have you done the 0.9.5 testtools release yet? I don't see a version number bump in the log.
<jml> mgz, uhh, which log are you looking at?
<cody-somerville> maxb, how does it distinguish a bound branch with a working tree from a checkout?
<jml> mgz, the answer is yes
<maxb> I would say a bound branch with a working tree is identical to a heavyweight checkout
<mgz> er, just on my branch which launchpad tells me is up to date
<fullermd> A very long semantic discussion, in the end.
<jml> mgz, what url?
<cody-somerville> maxb, 'bzr info' seems to know the difference. I want to know how it figures it out.
<mgz> ah, trunk. did you create a new one for the release and change the version there?
 * mgz downloads the ta
<fullermd> It doesn't, because there isn't a difference.  Sorta.  It just gives particular names to particular conglomerations.
<mgz> r
<mgz> wait, now I'm really confused, launchpad tells me the 0.9.5 tar is 20 hours old.
<mgz> ...it does have the right __version__ there though, so I shall stop worrying.
<cody-somerville> hmmm... on a checkout, bzr update is about 3 seconds faster then bzr pull --overwrite -- I wonder why.
<fullermd> Noise, I expect.  It's all the same work.
<lifeless> pull overwrite is likely doing a full history traverse
<cody-somerville> creating a new branch from scratch takes the same amount of time
<cody-somerville> or at least on this branch... Is it possible I'd see better performance with bzr pull --overwrite vs. bzr branch on bigger / more active branches?
<lifeless> in principle yes
<lifeless> it may nto be tuned to the limit
<cody-somerville> lifeless, Basically I have a cache of branches containing config for each project. The URL to the config branch for a project could possibly change so I want to be able to update the cached branch to be a clone of the branch specified regardless if its the branch its already binded to or not. unbinding and then doing a bzr pull --overwrite seems to be the only way I can do this reliably but because it appears to takes the same amount o
<cody-somerville> f time as it does to create a new branch from scratch it sort of defeats the purpose. Do you have any insight to a better solution?
<lifeless> how long are you talking? 3-4 seconds ?
<cody-somerville> lifeless, for the branches I've been testing with, 3-5 seconds yes
<lifeless> sounds ok as it is
<lifeless> though you don't need to unbind and pull overwrite
<lifeless> you can just call bzr switch
<cody-somerville> bzr switch has a bug I think
<lifeless> or not be bound at all and use pull  - if you want a mirror thats the usual idiom
<cody-somerville> '<maxb> I would guess that it's a bug that bzr doesn't switch the tree root, but rather switches everything under it'
<lifeless> that would suprise me a lot
<lifeless> however, if its breaking - file a bug - - really
<jam> cody-somerville: interesting. Though doing "bzr bind $NEW_URL; bzr pull --overwrite $NEW_URL" should be equivalent to "bzr switch" if you just want a workaround.
<cody-somerville> its not. I looked at the source code.
<jam> cody-somerville: as for tree-root id changing. we can't rename the root directory, so everything just appears as renamed into a new directory, which is at the same location
<jam> if you do
<jam> bzr mv directory other dir
<jam> bzr mkdir directory
<jam> bzr mv other_dir/* directory
<jam> you should end up with similar behavior
<cody-somerville> its equiv to bzr unbind; bzr pull --overwrite $NEW_URL; bzr bind $NEW_URL
<jam> bzr st will show everything as renamed into the same dir
<jam> cody-somerville: I'm pretty sure you can just do the bind $NEW without unbind
<GaryvdM> jam: You can select a range and do a cherry pick, or reverse cherry pick.
<jam> GaryvdM: \o/
<jam> very nice
<GaryvdM> jam: The other options (tag, revert, and update) are only available if one revision is selected.
<michaelh1> Morning.  Is there a way of retroactively marking a revision as fixing a bug?
<jelmer> michaelh1: Not yet.
<michaelh1> jelmer: ta.  I'm planning to use tickets to track the upstream patch state but I need to fix up past revisions
<michaelh1> jelmer: an entry in the ticket log will do it
<lifeless> michaelh1: then surely you can just write that up :)
<michaelh1> lifeless: write what up?
<lifeless> go to their ticket tracker
<lifeless> and put a comment in saying 'fixed in rev abc'
<michaelh1> lifeless: Yip, plan to.  Something like fixed-in: revno
<michaelh1> has to be machine readable
<lifeless> if you want machine processing consider using the revid ( a UUID) or branch + revno
<michaelh1> related question: what's a nice short name to a revision on a branch, say rev 93543 on lp:gcc-linaro/4.4 ?
<lifeless> lp:gcc-linaro/4.4,revno=93543 is planned but we haven't finished hooking up all the bits
<lifeless> the -r parameter to many commands will accept lp:gcc-linaro/4.4:93543
<lifeless> but it has the context to know its doing a revision lookup already
<michaelh1> Which format should I use for my fixed-by comment?
#bzr 2010-07-30
<michaelh1> Using bzrlib, how can I get a list of log entries from revision n to tip?
<michaelh1> (I'm afraid I got lost in bzrlib/log.py)
<mwhudson> michaelh1: bzr log -r n..
<mwhudson> oh bzrlib
<michaelh1> Yeah, I thought I'd be good :)
<mwhudson> michaelh1: if n is a integer, i.e. you're looking for a mainline rev
<mwhudson> start at tip, walk back along parent_ids[0] counting down the revision number until you get to n
<michaelh1> mwhudson: how do I access tip from a branch?
<michaelh1> s/branch/Branch instance/
<mwhudson> michaelh1: last_revision_info() i think
<michaelh1> Hmm. last_revision_info is a tuple - how do I match that up with parent_ids[]?
<mwhudson> michaelh1: like this http://pastebin.ubuntu.com/470870/
<michaelh1> Ta.  I'll give it a try
<michaelh1> So --fixes is encoded as a revision property called 'bugs', which is a string with one 'URL fixed' per line?
<mwhudson> michaelh1: yes, something like that
<james_w> michaelh1: branch.last_revision() is just the revid part of last_revision_info() fwiw
<davidstrauss> Where can I get the plugin for fast-export?
<davidstrauss> Is it part of fast-import?
<lifeless> yes
<rioch> how do I create a new branch? I want to use this branch to develop a feature that may a while, and during that time people may want to try it out.
<rioch> so I basically want a copy of my trunk, but as a new branch, if that makes sense
<fullermd> That would be the common case   :)
<fullermd> bzr branch trunk whatever-you-wanna-call-it
<fullermd> For other people to try it out, you'd just have it (or push it) somewhere they can access it.
<rioch> it's hosted on launchpad
<rioch> so if I do all this locally, and then push, I'll have my new branch. Then I push the changes I make to that new branch, et voila!?
<fullermd> Well, it would only be et voila if LP had a French translation of course, but...
<rioch> :)
<rioch> fullermd: so what happens when you do the branch command? Couldn't I just push trunk to a new location?
<fullermd> When you `bzr branch trunk foo`, you create a new branch foo that is (at present, anyway) just a duplicate of trunk under another name.
<fullermd> It could just remain forever a sometimes-out-of-date copy of trunk of course, but in this case you'd go on and work with it so that it becomes something new based on trunk (presumably with trunk periodically merged in to keep up-to-date).
<parthm> rioch: the bzr tutorial has a section on launchpad that you might find useful: http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/using_bazaar_with_launchpad.html#accessing-code-in-launchpad-using-bazaar
<fullermd> Then you'd have that foo to push a copy of somewhere for other people to access.
<rioch> so should I first make some changes and then push to a new branch, or should I first push to the new branch and then make changes?
<fullermd> Six and a half of one, half a baker's dozen of the other.
<rioch> So make changes first. ok.
<rioch> Just need to find a whisk.
<fullermd> You can tear up a spatula with a sharp knife in a pinch.
<rioch> Just need to find a knife.
<rioch> And a spatula.
<rioch> Dammit.
<fullermd> If we had some eggs we could have eggs and ham...
<rioch> I crave marmite.
<fullermd> Well, you're own your own there; bzr can't help you  :p
<rioch> :)
<ronny> hi
<ronny> whats a good way to ask bzr for the number of revisions in a repo
<jpds> ronny: bzr revno ?
<ronny> jpds: thats not the number of revisions
<bialix> bzr info -v
<bialix> hello bzr
<ronny> hum, how do i do it with bzrlib, i already god a repository object and a branch object
<ronny> i used to count the results of iter_merge_sorted_revisions but since that just started to break i tought i should do it propper now
<lifeless> theres a stats method
<lifeless> I don't recall what it is offhand - check pydoc bzrlib.repository.Repository
<lifeless> gather_stats or something
<ronny> lifeless: yup, that works, thanks
<magcius> ow ow ow
<jelmer> hi magcius
<magcius> uggh, so another project on Launchpad decided to change its trunk branch
<magcius> for no reason
<magcius> I'm stuck here with the outdated URL on my branch for about three or four weeks because it doesn't update
<magcius> now I have no clue how to get my patches back on trunk, there's no real "pull --rebase" like in git
<magcius> how do I create a patch?
<jelmer> magcius: there is bzr rebase
<magcius> there is?
<jelmer> magcius: It's part of the bzr-rewrite plugin.
<magcius> oh, a plugin
<magcius> hm
<magcius> is there any way to do it without it?
<magcius> That's the worst endorsement of a system I've ever heard: "it needs community plugins and support to make it actually usable"
<magcius> I'll stop trolling now. I just want to get this to work.
<LeoNerd> rebase is evil, try to avoid it
<LeoNerd> It rewrites history, so it's very rude to anyone else watching your branch
<AnMaster> I have a question: how to make bzr *not* ignore *.~[0-9]+~  files?
<AnMaster> yes I have some rather good reasons for it, trying to version a historical system using that for versioning. But since I have problems setting it up I want to not have to extract a pristine tar ball every time.
<bialix> AnMaster: new ! syntax in .bzrignore does not help?
<GaryvdM> magcius: Rather merge than rebase
<AnMaster> bialix, hm, didn't know about that. How new is it? As I said historical system. Due to bitrot I'm using an old debian version in a vm to contain it. So I guess I might need to update bzr in the vm first. Since it seems to be bzr 0.90
<AnMaster> XD
<magcius> GaryvdM: harder said than done
<bialix> AnMaster: it's new in 2.1
<AnMaster> ah, do you happen to know if that works with python 2.5 ?
<bialix> 0.90 is archaic, you know
<AnMaster> bialix, I'm well aware of that it is archaic
<bialix> AnMaster: another solution is to edit global ignore file
<bialix> heya GaryvdM
<GaryvdM> magcius: ??? A rebase involves doing a merge, just it is not recorded. So if you are getting conflicts with merge, you are also going to get them with rebase.
<AnMaster> bialix, I don't have any issues with upgrading it as long as I don't need to update half the system to do it, which is quite probable
<GaryvdM> Hi bialix
<AnMaster> oh well *goes to test if it works*
<magcius> GaryvdM: uhh
<bialix> AnMaster: 2.1 is python2.4-python2.6 compatible
<AnMaster> bialix, ah, no issues then
<magcius> GaryvdM: ok
<bialix> GaryvdM: https://bugs.launchpad.net/qbzr/+bug/487115/comments/12
<ubot5> Launchpad bug 487115 in QBzr "qcommit: qt warning message in the console when files grouped into directory (affected: 1, heat: 4)" [High,Confirmed]
<AnMaster> bialix, by the way, in case you are curious: The historic system is OpenGenera, related to lisp machines. :)
<bialix> AnMaster: never heard of
<AnMaster> ah
<AnMaster> strange, reactions are always "never heard of it" or "wow cool", never in between.
 * bialix is mostly windows guy, but don't say anybody
<AnMaster> bialix, suffice to say, the documentation contains references to ARPANET ;P
<GaryvdM> bialix: Cool. going to close the bug then.
<bialix> wow cool
<bialix> GaryvdM: I found some minor issues with new installer
<GaryvdM> bialix: What's that?
<bialix> GaryvdM: qbzr should be dependecy for explorer. now it's not. some other subtle items, I need some time to articulate them
<bialix> qbzr used to be such dependecy
<bialix> and maybe we should bundle the latest version of explorer, now there is stable 1.0.2
<GaryvdM> bialix: ok
<bialix> GaryvdM: nothing serious, really; just things I've noticed
<GaryvdM> bialix: Just pushing my bzr-windows-installers branch to trunk.
<bialix> ok
<bialix> GaryvdM: we should release qbzr 0.19 ASAP
<bialix> this Saturday maube?
<GaryvdM> Ok
<bialix> when the Ubuntu freeze?
<bialix> GaryvdM: freeze at Aug 12; we have 2 weeks
<GaryvdM> I've been trying to fix some bugs I've missed today. (like bug 537202)
<ubot5> Launchpad bug 537202 in QBzr "qcommit: ignored files added when non-versioned and select all checked (affected: 2, heat: 2)" [High,Confirmed] https://launchpad.net/bugs/537202
<GaryvdM> I have a test case, and 3 different ways to fix it...
 * GaryvdM pushed to lp:bzr-windows-installers
<bialix> hmmm
<bialix> GaryvdM: ok, maybe we should make release next week
<GaryvdM> bialix: Ian rewrote the .iss generation code, so it is likely that the dependency bug has crept in there.
<bialix> tomorrow is not the best idea
<bialix> GaryvdM: yup
<bialix> GaryvdM: how you're building the installer?
<GaryvdM> Bla - keyboard short cut + dvorak fail
<GaryvdM> bialix
<GaryvdM> bialix: I'm building on the ec2 server
 * GaryvdM not sure if that's what you were asking...
<GaryvdM> bialix: What are your thoughts on my bzrw patch (https://code.edge.launchpad.net/~garyvdm/bzr/bzrw/+merge/31133)
<bialix> GaryvdM: sorry, don't look at it yet.
<GaryvdM> bialix: short story: I've cleaned up Naoki's stderr patch, and I want it to ship with 2.2
<bialix> I will try to look at it on weekend
<GaryvdM> bialix: Ok - thanks
<bialix> GaryvdM: ping
<GaryvdM> Hi
<GaryvdM> bialix: pong
<bialix> new PyQt draws qlog graph differently.
<bialix> is it intended?
<GaryvdM> No. Please imagebin screen shot.
<GaryvdM> bialix
<GaryvdM> bialix: Is it bad?
<bialix> circles are smaller, lines are thickier
<GaryvdM> bialix: Circle sizes are based on the row height.
<GaryvdM> bialix: Has that changed?
<bialix> GaryvdM: yes, it's different now
 * bialix creating screenshot
<bialix> GaryvdM: http://imagebin.ca/view/qxZPmviW.html
 * GaryvdM looks
<GaryvdM> bialix: Have you maybe changed you system font sizes?
<bialix> no
<GaryvdM> hmm
<GaryvdM> bialix: Do we maybe want to do a if sys.platform == 'win32': fontsize += 1
<bialix> wait a min, I'll do the picture for the old PyQT
<GaryvdM> bialix: http://doc.bazaar.canonical.com/explorer/en/_images/dialog-log3.png
<bialix> GaryvdM: 4.7 http://imagebin.ca/view/LvTlCj.html
<bialix> 4.4 http://imagebin.ca/view/wjCxOk.html
<bialix> so it seems pyqt 4.7 uses smaler interval between rows
<GaryvdM> Yes
<bialix> I don't like it
<bialix> all the dude wanted
<bialix> if you look at 4.4 screenshot then you can see it was clear
<bialix> now it's smooth and blur and looks dirty
<bialix> :-(
 * bialix re-installing 2.1.2 again
<GaryvdM> bialix: I agree.
 * ddaa wishes to wake up one day and find that all software developers have figured out that windows was not a serious operating system
<LeoNerd> It's not the developers you need to worry about. It's the managers/etc... who actually buy ity
<ddaa> in this fantasy world, managers would give up on windows after tiring of being ridiculed every day at the coffee machine.
<bialix> blah blah blah
<ddaa> don't take that personally, it's great that people work on windows support, so we can reach through to those lost souls
<idnar> how do I "unadd" a file? the help for bzr revert suggests it'll delete the added files
<ddaa> it won't if the file was not committed
<beuno> idnar, bzr rm FILE --keep
<ddaa> you can also "bzr rm --keep", but bzr will do the safe thing by default
<beuno> although, yeah, once it's committed, it's going to live in the history for ever and ever
<idnar> okay, cool
<beuno> unless you uncommit, which you should *not* do if that revision has been sent into the wild
<idnar> yeah, I just added some stuff too soon
<idnar> I don't want to commit it along with some other stuff, and it's easier to "unadd" it than to pass the relevant paths to commit all the time
<ddaa> you could also shelve the problematic file
<idnar> that's probably a good idea, I haven't played around with shelve yet
<ddaa> something like 'bzr shelve --all my/file; bzr commit ; bzr unshelve'
<ddaa> --all will bypass the command line interaction and just shelve the changes of all specified files
<ddaa> (or all changes if no file was specified)
<idnar> I guess I tend to be fussier about commits than I need to be with bzr
<ddaa> no, fussy commits are good
<ddaa> it helps when people go back inspecting the history
<idnar> I usually end up working on a couple of things at once in my working directory, and then making a lot of small commits every now and then to break everything up
<idnar> I'm used to using darcs, where it actually makes a difference wrt to merging; with bzr, it's not as important, but it's still nice to have a clean and sensible change history
<ddaa> maybe you should be more liberal with creating branches
<ddaa> bzr merge --uncommitted is pretty cool to pick "that change I started there but should really be in a different branch"
<idnar> it's too much work to create a whole branch just for, say, a 5-line change to some file; although I suppose you could blame that on my dev environment
<idnar> I think bzr shelve is probably the way to go
<idnar> is there a way to do a "cherry-picking" commit or shelve? I seem to recall seeing something about that somewhere, but I forget the details
<idnar> as in cherry-picking changes within files, not separate files
<ddaa> if you just look about the number of different ways there are in bzr to break up commits, you realize that bzr folks love to be fussy over their commits
<ddaa> shelve does that, it asks for each diff hunk, unless you specify --all
<LeoNerd> shelve does that.
<LeoNerd> I -believe- there's a plugin to imlpement  'bzr record'  which works like darcs record, offering interactive per-hunk selection
<LeoNerd> Though personally I dislike that.
<idnar> ah, that may be what I'm thinking of
<LeoNerd> The advantage of shelve; commit; unshelve is that you can compile and test just before commit.
<ddaa> the bzr way tends to be "commit what's in the tree", so you can do some basic testing before committing
<LeoNerd> If you have a per-hunk partial commit it's very easy to accidentally commit files that don't even compile, let alone do what you wanted
<idnar> ddaa: darcs test runs your tests against what was actually recorded, so it's not a problem there
<ddaa> idnar: I'm not sure what you're trying to say, to run your tests you need a checkout anyway
<ddaa> and it's better to run them before committing
<ddaa> but I admit having no idea what darcs record does
<ddaa> is that one of those "what the vcs sees is not what the filesystem sees" (so all bets are off when you try compiling/testing)
<idnar> when you run "darcs record", after you've selected what you want to record, if you have a "test" command set up, then iirc it creates a checkout of the source tree that includes your newly-recorded patch and runs your test on that
<idnar> if that fails, then the patch won't be recorded
<LeoNerd> Ahyes, a big integrated approach.
<LeoNerd> The bzr way is that bzr is the revision control tool and it stays out of your way wrt. testing, etc... More unixy
<idnar> anyhow, the main thing is that it's automated
<idnar> if I have to manually create a new branch/checkout/whatever, I'm going to spend 5x as much time on that as I did on the actual change I want to commit, which is silly
<idnar> so with bzr, I usually don't bother creating a whole new branch for the small things, and I don't bother testing them individually; I'll run the tests after I've changed everything, and then just commit pieces individually
<idnar> I'm never committing directly to trunk, and I'm not as concerned about "broken" revisions in a branch, as long as the end result is correct
<idnar> but ideally each of those chunks would be tested individually, so I guess I need to work on making it easier to break things out like that
<jelmer> idnar: Any chance you could file a wishlist bug about this?
<ddaa> it's true, it would be nice if there was a "shelve --except FILE ..." option
<jelmer> idnar: It certainly sounds like a useful feature, if only as a plugin (like a local PQM?)
<idnar> jelmer: hmm, "this" being the "test after commit" feature?
<idnar> (well, test before commit, whatever)
<jelmer> idnar: yeah, the test after commit bit
<idnar> jelmer: okay, will do
<jam> morning all
<jelmer> hey John
<GaryvdM> Hi jam
<GaryvdM> Bla
<GaryvdM> qannotate is very slow for me due to http://bugreports.qt.nokia.com/browse/QTBUG-4977
<bialix> today is shelve bug reports today
<bialix> today is shelve bug reports day
<idnar> jelmer: okay, created lp#611745
<jelmer> idnar, thanks
<bialix> ~~~
<ChrisCauser> Hello Bazaar mailing list. I was wondering if anyone can help me undo a mistake I've made.
<ChrisCauser> I have two repositories. The first is a subversion repository with x number of commits. I decided to try out bazaar and now have y commits in a bzr branch The stupid thing is that I did a simple copy of the working copy and initialized the branch so there is no link between these two repos. Does anyone know of a way I can stitch these two back together into a bzr branch so it looks like 1...x...x+y commits? I can't find anything useful on the web,
<maxb> Hmm. that sounds a little painful
<maxb> Is the history currently in bazaar entirely linear? (no branching or merging?)
<ChrisCauser> It's linear all the way
<maxb> I would propose converting the Subversion history using bzr-svn, and then using 'bzr replay' from the bzr-rewrite plugin to transpose the commits in bzr onto the converted branch
<ChrisCauser> maxb: Ah, this looks to be very promising
<ChrisCauser> I'm getting conflict errors, but I think you've set me on the right path. Many thanks maxb for your help
<LukeD> I have a repo structure (no-trees) that has a bunch of mainline branches for different projects, some that I'm tracking with bzr-svn, some local libraries. I want to set up a project branch that includes branches of these mainlines as externals. Essentially, when I do a remote checkout of the project, I'd like it to pull checkouts of all the external branches as well... I can't seem to get it to work though. Anyone done this before?
<jelmer> LukeD: that's the nested branch feature, which has not been implemented yet.
<LukeD> ahh
<jelmer> However, there are some plugins that provide similar functionality (with limitations). See the bzr-externals and bzr-scmproj plugins.
<LukeD> I've been trying with bzr-externals, but haven't had success
<LukeD> will look at scmproj
<LukeD> I feel like bzr-externals probably does what I need, but I'm just not doing it right
<LukeD> sigh
<ddaa> AFAIK you're on your own
<ddaa> as long as your bzr commits are just linear
<ddaa> it should be only moderately painful to write a shell script to replay the stuff using "bzr diff" and "bzr patch"
<ddaa> going through diff/patch is needed to get over the file-id mismatch
<lifeless> replay can handle that if you supply a mapping file
<lifeless> AIUI
<ddaa> oh, bzr replay, completely forgot about this one
<ddaa> I don't see anything about mapping files in its help message, though
<lifeless> its in the guts
<lifeless> sadly
<ddaa> in the guts as in "the option is not document", or as in "there's no UI for it" or as in "some guy coded it once, no idea if it works"
<lifeless> middle
<lifeless> its used by bzr-svn mapping upgrades
 * ddaa is scared
<jelmer> the mapping upgrades are done without any mapping files on disk but based on the revision properties/revision ids
<jelmer> see also "bzr pseudonyms"
<jelmer> though Rob is right that all of the infrastructure is present to do this sort of stuff, just not exposed at the ui
<lokkju> on windows is there any way around the 255 char limit with the bzr client?
<jelmer> lokkju: 255 char limit on what exactly?
#bzr 2010-07-31
<lokkju> jelmer, paths
<lokkju> we're trying to do a branch operation from a remote repo, and it's telling us one of the files exceeds that limit
<jelmer> lokkju: yes, that might very well be possible
<lokkju> so...  any way around it?  Window XP and newer's limit is actually 65K, but I've seen this same issue with svn - it is something about the libraries that are being linked to or something
<lokkju> ack, 32K
<AfC> How can you restrict bzr+ssh to a specified directory path rather than bzr+ssh+//user@hostname/path implyng / ?
<AfC> ie, something like http://thias.marmotte.net/2009/05/creating-a-restricted-bzrssh-smart-server/ but serve side. Is that possible with some sshd_config magic, maybe?
<fullermd> authorized_keys entries are server-side...
<AfC> fullermd: oh,
<AfC> duh
<AfC> right
<AfC> Ok, so maybe a different question
 * fullermd gets you an extra coffee mug   8-}
<AfC> That's fine for users who are *only* doing bzr+ssh when they connect,
<AfC> but what about users who also have normal accounts there?
<AfC> (ie, me as opposed to everyone else)
<AfC> fullermd: ie, I have bzr://research.operationaldynamics.com/bzr/java-gnome/mainline/ and http://research.operationaldynamics.com/bzr/java-gnome/mainline/ for public serving, but it sure would be nice
<AfC> fullermd: to have bzr+ssh://research.operationaldynamics.com/bzr/java-gnome/mainline/ for pushing, rather than the current
<fullermd> Clean and/or pure-bzr solutions?  I don't know of any.  I can dream up a few somewhat hackish things.
<fullermd> Of course, you can use authorized_keys and use different keys, which isn't without drawbacks.
<AfC> fullermd: too-muc-info bzr+ssh://epsilon.dal.operationaldynamics.com/export/web/com/operationaldynamics/research/bzr/java-gnome/mainline/
<fullermd> (but can work, depending)
<AfC> I mean, obviously I could put a symlink in / as /bzr -> path, but that seems so wrong
<AfC> I'm wondering if sshd gets any information about the hostname that was requested
<fullermd> Marginally less wrong would be a symlink at ~/bzr and bzr+ssh://blah/~/bzr/ of course.
<AfC> (outbound, ssh_config keys on hostname target
<fullermd> I don't think so.
<AfC> what about receiving side in [well, not sshd_config, but something?)
<AfC> fullermd: actually, yeah, the home directories might be a better option, in the final analysis.
<AfC> hm
<AfC> right now we have a shared repo, but...
<fullermd> Well, I didn't mean _moving_ stuff under homedirs, just adding the symlink for shorter typing on access.
<AfC> oh
<AfC> hm
<AfC> {shrug}
<AfC> yeah,
<AfC> that's not bad
<AfC> fullermd: good thinking
<fullermd> One variant of the uglyhack solution would be to tweak shell rc files so that noninteractive logins get a 'bzr' that's a wrapper script setting --directory.
<AfC> yeah, I'm just pondering along those lines
<AfC> maybe
<AfC> well, maybe a different sshd instance on a different port
<AfC> or some kind of port forwarding, or...
<AfC> hm
<fullermd> Another is to hack up bzr one way or another (direct hackery, maybe something can be done in a plugin, etc) to fiddle with the command it invokes when you bzr+ssh.
<fullermd> Different port wouldn't gain you anything over using a separate key with the authorized_keys fiddling.
<AfC> yeah
<AfC> damn
<AfC> this seems like it should be simple
<AfC> well
<AfC> well. If the server is ONLY for bzr, then hacking the authorized_keys (or whatever) would do it I suppose. My problem is that this server does a few other things.
<fullermd> Or you could pretend you're Launchpad, and just build your whole thing on top of a fictitious pseudofs  :p
<fullermd> You can have multiple keys.  Just have a special one for bzr stuff.
<fullermd> You can use your local .ssh/config and a separate hostname to auto-choose it for "bzr.myhost" instead of "myhost" (or whatever other trickery you may want)
<AfC> yeah, but then I'd have to make `bzr push bzr+ssh:host` use a different one than `ssh host` does... erum oh
<AfC> well,
<AfC> yeah
<AfC> duh
<AfC> that could work
<AfC> client side, ssh_config
<AfC> specify a different IdentityFile
<fullermd> Well, if you wanted to go systemwide...
<AfC> yeah, I meant .ssh/config
<AfC> nice
<fullermd> One downside is that you end up not taking such advantage of connection sharing there, assuming you're doing so in the first place.
<AfC> sort of a bother to have to have another key, but hey, yes, I'll live
<fullermd> Of course, given the sorry state of manglement for connection sharing...
<AfC> yeah
<AfC> I gave up on connection sharing when I realized (duh) that a root@ and user@ wouldn't share the connection.
 * fullermd is amazed and how that hasn't improved in $YEARS.
<fullermd> Sure, but who ssh's as root?   :p
<AfC> (I also noticed that even user@ and user@ has a lot of ugly race conditions if you start doing any port forwarding
<AfC> fullermd: not me, of course.
<AfC> fullermd: [our security team had a hard think about that, and decided that inhibiting sysadmins from being root was stupid]
<AfC> fullermd: [in fact, more mistakes were being made on servers as a result of people sudoing when they shouldn't or, not using it when they should, etc etc etc]
<fullermd> I've used pure sudo everywhere since sometime last millennium.  Makes management so much simpler.
<AfC> {shrug} on desktops and other shared multi user systems, sure
<fullermd> And saves all that trouble with connection sharing, X11 forwarding and key handling, blah blah blah.
<AfC> right
<AfC> so our definition of where the dividing line is is whether X is involved or not
<AfC> anyway,
<AfC> different key.
<AfC> Good call.
<AfC> fullermd: did the rest of http://thias.marmotte.net/2009/05/creating-a-restricted-bzrssh-smart-server/ look right to you? I've been trying to find an authoritative reference to that. Seems problematic to have to list all that stuff in so many people's home directories.
<fullermd> It looked reasonable; I've never messed with it myself so I don't know if it's actually correct or works.
<AfC> well, just tried the whole setup and it works... nice
<AfC> yup, seems sound
 * AfC should blog this
<AfC> fullermd: thanks for your thoughts
<fullermd> Yay, justified my oxygen use for the day.
<mathrick> hey, is there an existing command to apply a patch that reverses an existing commit to the tree?
<mathrick> ahh, merge
<nebuPookins> I tried to do a checkout of a project from launchpad, but it seems to make bazaar crash.
<nebuPookins> I posted the error message I get at https://bugs.launchpad.net/bzr/+bug/611949
<ubot5> Launchpad bug 611949 in Bazaar "bzr crashes during checkout of gnome-do (affected: 1, heat: 6)" [Undecided,New]
<nebuPookins> Wondering if anybody had any idea of what I could try next.
<asabil> nebuPookins, just tried it over here, same issue
<nebuPookins> Thanks; good to know it's not a config problem with my system.
<nebuPookins> I'm also talking to the folks on #gnome-do
<nebuPookins> Yeah, they said they're getting the same error too now. "I guess i haven't really rebranched lp:do for a long time"
<asabil> there is already another bug open: https://bugs.launchpad.net/bzr/+bug/522637
<ubot5> Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 11, heat: 60)" [High,In progress]
<lifeless> spiv was working on a fix
<lifeless> I'm sorry that I don't know more than that
<nebuPookins> Ok thanks, I'll subscribe that bug too.
#bzr 2010-08-01
<cody-somerville> Hey
<cody-somerville> I have a branch on launchpad that is stacked on a branch that was moved which means I can't branch or check it out anymore.
<cody-somerville> How can I fix this?
<jelmer> cody-somerville: hi
<jelmer> cody-somerville: I don't think there is an easy way to do that, Launchpad shouldn't have allowed you to move the branch on which your branch was stacked in the first place.
<jelmer> Is there perhaps some way you can create the base branch again?
<jelmer> ah, live-helper was renamed to live-build ?
<cody-somerville> jelmer, aye
<mtaylor> cody-somerville: also, I believe you can sftp in to your branch and edit the stacked on setting
<cody-somerville> aye
<cody-somerville> thats what I've done
<mtaylor> excellent
<mtaylor> although I agree with jelmer that you should have been prevented :)
<mtaylor> anybody around know how to go back through and edit revisions in a branch - in this case, someone has committed without setting bzr whoami and I'd like to fix it - but I don't want to replay the whole revision history just to do it.
<lifeless> mtaylor: replay
<lifeless> mtaylor: + my patch to permit changing the committer which still has no home
<lifeless> mtaylor: sorry, rebase + my patch
<mtaylor> lifeless: do you mean rewrite + your patch (hasn't it been renamed again?)
<lifeless> the rewrite plugin
<lifeless> the rebase command
<lifeless> + my patch
<mlh> nebuPookins2: you're bouncing
<josh> anyone around?
<josh> anyone have time/interest in helping me with bazaar and plugins?
<jelmer> josh, hi
<josh> hello
<josh> let me try to explain what i've figured out and hopefully then my question will seem clear
<josh> we have these configuration files that are notoriously difficult with regards to syntax... so we have a perl script that checks them for syntax errors
<josh> we'd like to have this script run on every perl script before committing and fail the commit if there are syntax errors
<josh> i've been able to do this with the pre_commit_check hook
<josh> however, that would require us to make sure everyone has this plugin installed locally... this isn't difficult as a "one-time" thing, but it's a bit more difficult to make sure that newcomers get this installed
<josh> so, is there any way to do this on the server?
<josh> sorry for the novel
<josh> i have attempted to recreate the logic on the server using a pre_change_branch_tip but I'm not quite sure how to get access to the actual file (i.e. the perl script needs to be able to open the file and process it)
<fullermd> Well, bzr has the text available.  Maybe it could run over stdin?
<josh> hmm, interesting
<fullermd> 'course, it could as easily write out a temp file somewhere and yada yada, but using stdin would save you from all the cleanups and corner cases and race conditions that entails.
<josh> ok, so am I on the right path with making sure the pre_change_branch_tip is where I want this to run?
<fullermd> Probably, though I'm hardly an expert.
<Leav> Hello, i need some pointers on to use to use bazaar for newbies
<Leav> how to use*
<Leav> are there any toturials?
<Leav> (for the GUI)
<jelmer> lifeless: Hi
<lifeless> hiya
<jelmer> lifeless: So, I've spent some time on Bazaar this weekend, mostly trying to get all of the tests to run without failing - including running tests against foreign branches.
<lifeless> \o/
<jelmer> I'm down to 170 failures across the tests of all plugins I have installed, which I think is pretty good.
<lifeless> thats awesome
<jelmer> I ran into some tests that can obviously never run properly against foreign formats, since they make assumptions that are very much tied to Bazaar's formats (such as .bzr existing, or .bzr/checkout/merge-hashes). I've filed bugs for those.
<lifeless> coolo
<jelmer> What I wanted to ask at UDS and the GHM about this was basically to check with you that I'm doing the right thing by moving those tests (and those tests alone) to a per_bzr_bzrdir or something directory.
<lifeless> yeah
<jelmer> That reminds me, we really should rename that class to ControlDir..
<lifeless> o/
<jelmer> also, you'll find I filed some testrepository bugs
<jelmer> "testr run --failing" is awesome when fixing a large number of test failures
<lifeless> \o/
#bzr 2011-07-25
<jelmer> helloooo spiv
<spiv> Hey, go enjoy your weekend while you still have it :P
<spiv> Morning poolie
<poolie> hi there spiv
 * jelmer waves from DebConf
<poolie> hi jelmer
<poolie> have fun
<spm> heya jelmer
<poolie> spiv, so you're going to be pilot this week?
* poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv
<spiv> Apparently so! :)
<poolie> it's negotiable :)
<kgoetz> jelmer: in bug 811460 you link me to bug 811460. is 811460 a  'please allow import-dsc to only bring in debian/' , or would that be a separate issue?
<ubot5> Launchpad bug 811460 in bzr-builddeb "please allow multiple debian/ dirs in one repo" [Undecided,New] https://launchpad.net/bugs/811460
<kgoetz> oh, i pated it three times
<kgoetz> bug 331986  is what the send and third references were meant to be
<ubot5> Launchpad bug 331986 in bzr-builddeb "import-dsc doesn't work for merged build" [Medium,Triaged] https://launchpad.net/bugs/331986
<thomi> Hi, I've just proposed a merge (https://code.launchpad.net/~thomir/bzr/fig-bug-747958/+merge/69023) to fix bug #747958. I'd welcome any feedback.
<ubot5> Ubuntu bug 69023 in ppscsi (Ubuntu) "ppscsi won't build with module-assistant under kernel 2.6.17-10-generic (or newer)" [Undecided,Confirmed]
<ubot5> Launchpad bug 747958 in Bazaar "values given to make_log_request_dict are overridden" [Medium,Confirmed] https://launchpad.net/bugs/747958
<poolie> thanks for the patch thomi, i'll have a look after lunch, or spiv will
<kgoetz> can bzr compress its repo? or parts of its repo? i've not found anything obvious in the commands list
<spiv> kgoetz: it's already compressed (and it automatically repacks it gradually from time-to-time to keep it well compressed)
<spiv> kgoetz: but you can use 'bzr pack' to trigger that manually, although it's unusual to do so.
<kgoetz> spiv: ok. i'll just put up with it then.
<poolie> kgoetz: 'put up with'...?
<kgoetz> poolie: 870kb of .bzr when i have 8kb of text 'top level' (it tar cjf's down to 250k, so i thought some of the old history might be properly compressable. other then historical interest itsnot useful for reference anymore)
<poolie> kgoetz: you can see if there are files in obsolete_packs
<poolie> they can safely be deleted
<poolie> bzr will delete them itself later
<lifeless> jelmer: given you're patching lp, you might like to idle in #launchpad-dev
<lifeless> jelmer: we're talking sprdata atm :>
<poolie> spiv i might send my einval patch to 2.4
<kgoetz> oh, poolies gone
<kgoetz> well, thanks for the tip :)
<kgoetz> half the repo size is obsolete_packs
<bob2> it'll get cleared up shortly-ish
<kgoetz> if bzr handles it i'll leve them alone. thanks
<lifeless> every 10 commits at most
<bob2> hm, i thought it only stuck around at all to avoid races
<spiv> bob2: sure, but we don't check obsolete_packs on every write to the repo, just on every repacking of it.
<AfC> spiv: why not? Once the repack is done, why further waste the disk space?
<lifeless> AfC: many popular OSes lie about persistence, and / or have no cheap way to record that something matters without triggering immediate IO
<bob2> spiv: ahhh, right
<lifeless> bob2: checking on every write would itself be a race condition :>
<kgoetz> i've seen the $magic happen every 10 commits. i'm on 172 atm, so i'll see what happens in 8 commits (:
<lifeless> kgoetz: is this a project with many (k's) or large (10's of MB's or more) files ?
<kgoetz> lifeless: no, nothing like it. its my cv. formerly (until 3 commits ago) stored in xml (+~20 supporting files), now in rst
<kgoetz> lifeless: so two files, one 8kb one 1kb
<kgoetz> got to dash, catch you later
<kgoetz> and thanks for the help :)
<lifeless> kgoetz: so thats why 50% space is in the obsolete packs
<lifeless> kgoetz: because your data is small, and the individual commits don't contain compressed data - its only as they repack that compression happens.
<lifeless> kgoetz: obsolete_packs isn't transmitted on push/pull.
<KombuchaKip> Is it possible to just commit a portion of the changes of a modified working branch to the checkout branch? e.g. just the contents of one subdirectory, as opposed to them all that have changed.
<spiv> lifeless: can I ask a favour?  I have an approved branch for bzr-builddeb, but it turns out I'm not in the (moderated) team that can commit to it and you are.  Would you mind pushing lp:~spiv/bzr-builddeb/trunk-merge-of-use-dpkg-mergechangelogs to trunk?
<spiv> lifeless: normally I'd just join the team, but I'm fairly sure this is the last change I'll be making to that code :)
<poolie> KombuchaKip: sure, just 'commit SUBDIR'
<KombuchaKip> poolie: Roger. Thanks.
<KombuchaKip> poolie: What about if I've unbound and I rebind to the upstream? Still ok to do that?
<poolie> hm
<poolie> commit makes a new revision on whatever branch the tree addresses at the time you run it
<poolie> what's the concern?
<KombuchaKip> poolie: If I've made many commits to my unbound local branch, when I rebind and commit to upstream, will the upstreams revision number be incremented just by one, or by N, N being the number of local commits I've made since unbinding?
<poolie> you will make one new upstream commit (which will be numbered N+1) which will be a merge of all your local commits
<poolie> it doesn't matter what's in the comimts
<jam1> poolie: /wave
<poolie> hi jam
<jam1> I'm feeling a bit ill today, so I'm probably going to be a bit in-and-out.
<jam1> But I figured I could say hi, at least.
<poolie> i'm finishing the fdatasync branch
<poolie> sorry to hear that; it's nice to see you
<poolie> hm if this is always on, it's probably going to slow down the test suite on magnetic disks
<jam> anyway, off to take the kid to school, I'll see you in a bit
<KombuchaKip> poolie: Thanks.
<lifeless> spiv: am really EODish now, but will dig around for a branch etc tomorrow if jelmer doesn't do it.
<spiv> lifeless: thanks!
 * jelmer waves
<thomi> poolie: thanks for the feedback - I've made the changes and re-pushed.
<poolie> thanks thomi
<thomi> no worries. It'll be good to get that fixed... means I can clean up some work-around code in sloecode :)
<poolie> cool
<spiv> thomi: thanks for returning to that bug!
<poolie> what was the selftest error you got?
<poolie> you can file a bug or question for that
<poolie> it's supposed to be clean, or at least to give a clean message if you're missing something we need
<thomi> spiv: it snowed, so I couldn't go to work. I was bored ;)
<spiv> thomi: I hope it snows more often then ;)
<thomi> I'm browsing the bzr bug list right now. Can't find any more easy looking ones though ;)
<thomi> Although I regularly run into #82555
<poolie> thomi there are some bugs tagged easy
<poolie> bug 82555
<ubot5> Launchpad bug 82555 in Bazaar "Merging to an empty branch doesn't work" [High,Confirmed] https://launchpad.net/bugs/82555
<jelmer> spiv: while you're looking at bzr-builddeb, can you perhaps review https://code.launchpad.net/~jelmer/bzr-builddeb/contains-upstream-source/+merge/69017? It's a one line change (and some tests)
<spiv> jelmer: done!
<jelmer> thanks :)
<poolie> thomi: i have an easy fun useful bug which is to add a system-wide configuration file
<poolie> you just need to arrange for it to be opened and then to go into the Stack objects in config.py
<Riddell> hola chicos
<poolie> och aye
<spiv> salut
<spiv> jelmer: if you could land my bzr-builddeb change that'd be great (should just be a simple push, see mp comments)
 * spiv is done for the day.
<jelmer> spiv: will do
<jo-erlend> dch keeps adding username@hostname instead of using my email address. Where do I configure that?
<poolie> EMAIL or DEBEMAIL should do it?
<jo-erlend> no configuration file?
<Riddell> no
<mgz> morning all!
<poolie> hi mgz
<poolie> i'm just reading your test patch
<poolie> it sounds good
<mgz> hey poolie
<poolie> mgz i might have another go at https://code.launchpad.net/~mbp/bzr/test-errors/+merge/64485
<poolie> thanks for narrowing it down
 * fullermd slaps qdiff for not having any exit function.
<jimis> jelmer: you had told me lp:gcc has about 2K tags... More like 200K it seems :-) http://launchpadlibrarian.net/73597623/vcs-imports-gcc-trunk.log
<jelmer> jimis: the numbers there are a progress indicator
<jelmer> jimis: it's the number of revisions
<jimis> jelmer: I see, it was too much to be real :-)
<kgoetz> lifeless: thanks for rthe info above
<maxb> Gah. The new package branch up-to-dateness checking throws an exception in foreign branches
<jelmer> maxb: that shouldbe fixed in the foreign branch plugins
<maxb> Seems like a workaround in the new code would be the friendly thing to do, to avoid making compatibility more bumpy than it needs to be
<jelmer> well, arguably this was a big in the foreign branch plugins
<jelmer> *bug
<jimis> can I permanently set (with some config file) the option --diff-options=-p?
<jelmer> jimis: you can set an alias for diff that sets that option
<jelmer> see 'bzr help alias'
<jam> jimis: bzr alias diff="diff --diff-options=-p"
<jimis> thanks
<jimis> Is there a way to apply a specific commit from another branch?
<jelmer> jimis: bzr merge -c REVNUM BRANCH
<jimis> jelmer: thanks, I was using merge -r and I got all changes until that revision :-)
<jimis> "bzr help merge" is not clear about the difference
<notmyname> Is there any estimated timeframe for getting OS X (py2.7) installers up?
<mgz> afternoon.
<jelmer> hi mgz
<lxsameer> what is the difference between bzr pull and bzr merge
<LeoNerd> pull is for updating when you are strictly-behind in progress
<LeoNerd> merge is for re-combining two divergent trees of history.
<Anteru> Hi
<Anteru> What representations of the file contents exist in bzr at run-time? Is it only passed around as plain strings in-memory, or is there some stream-based abstraction somewhere?
<mgz> they tend to be passed around as chunks, but still tend to be held in entirety in memory
<Anteru> Hm
<mgz> there are a bunch of different problems on the really-big-files angle
<Anteru> Yeah, I start to understand what's going on.
<Anteru> I assume having a real "chunk" class which can convert to string if required but tries not to would require an extensive rewrite?
<mgz> perhaps not, part of the issue with the content filtering line you're trying is that they've just not been widely used yet,
<mgz> so there are probably a whole bunch of little issues that need ironing out with the core bzr code
<mgz> big files generally don't work well because there's no benefit using any of the VCS techniques on them
<Anteru> Hm. I'll be trying to get a prototype working which side-steps the issue and handles large-files manually (using a stream approach) but it would be much easier if the content filter wouldn't get the complete file contents as input.
<Anteru> Yeah, I see your point, that's why I thought that a thin wrapper which behaves like a string but optionally allows you to query the size would be the easiest/fastest-to-add solution.
<Anteru> In 99% of the cases, you would just pass it around but if needed, you could try to use the stream interface (diff, content filters.)
<Anteru> For instance, I'm using a checkout with Bzr to store large binary files.
<mgz> yeah, and you (and others on the mailing list) are right that there are benefits from being able to keep your not-usefully-versioned files in the repo along with the rest of the stuff
<mgz> I wonder if you could get your code working against the current chunks interface, then see what changes would be needed to work against an iterable rather than a list
<Anteru> Ok
<Anteru> The problem with the chunks interface is that I'll be storing only a hash in the file so I can keep the binary blobs completely off the repository.
<Anteru> This is going to be a glorified hack which creates the bin files on update and uses a pre-commit hook to check/update the hash file.
<jelmer> 'evening Anteru, mgz
<Anteru> Evening jelmer
 * mgz waves at jelmer
<Anteru> Anyone here who developed a plugin on Windows?
<jelmer> Anteru: it shouldn't be all that different than on linux
<Anteru> I'm wondering how to debug it; tried to print from the plugin but either it doesn't get called or the print goes elsewhere.
<Anteru> And I can't get PyDev/Eclipse to run bzr commands ... should I get bzr source + a python 2.6 interpreter?
<mgz> trace.mutteras you noted in your list post plus tail on .bzr.log should work
<Anteru> Thanks
<timrc> I think "bzr duff" should return ascii art of Duff beer
<mgz> you could write a plugin for that :P
 * timrc is tempted
<jelmer> timrc: I think it should punish you as well, by making you wait - like sl
<timrc> jelmer, lol.. the sad truth is, sometimes I find myself intentionally typing 'sl'
<poolie> hi all
<teratorn> any way to remove a tag from a local commit?
<teratorn> ah, I found it
<jelmer> hey poolie
<poolie> hi jelmer
#bzr 2011-07-26
<spiv> Good morning.
<jelmer> hi spiv
<poolie> hi spiv
<thomi> poolie: you mentioned yesterday something about a config file related bug? Do you have a bug report I can take a look at?
<thomi> I just proposed a merge that applies the patch from bug #250296 and fixes the unit tests for the new message text.
<ubot5> Launchpad bug 250296 in Bazaar "bzr missing gives confusing 'up to date' message" [Low,Confirmed] https://launchpad.net/bugs/250296
<poolie> thanks thomi
<poolie> let's see
<thomi> poolie: BTW, I notice you've worked on loggerhead as well. Is there an IRC channel for that? #loggerhead is empty...
<poolie> just talk here
<poolie> https://bugs.launchpad.net/bzr/+bugs?field.tag=config
<poolie> probably 419854 would be really nice and not too hard
<thomi> ok, so I need to open the file somewhere, and then work out how to add it to bzrlib.config.Stack?
<poolie> yep
<poolie> you should be able to open it with something very similar to the per-user configuration file
<thomi> hmmm, I'll certainly give it a go.
<poolie> we might need to update some existing callers that currently open just that one file to use a stack instead
<thomi> should I assign the bug to me while I'm hacking away at it?
<poolie> if you want, it's up to you
<poolie> you can just say on the bug you'll have a go at it
<thomi> I think I'll try and make some headway first. I'm still trying to get my head around bzrlib
<poolie> don't hesitate to ask
<jam> hi all
<thomi> poolie: so (correct me if I'm wrong), currently there's "global" config, location config, and branch config, represented by GlobalStack, LocationStack and BranchStack?
<poolie> correct
<poolie> hi jam
<robert_ancell> bzr broken in oneiric?
<thomi> is there an equivilent to bzrlib.win32utils.py for Mac OSX? *or* does anyone know what the correct system-wide config directory should be for a mac?
<robert_ancell> spiv, can you help me with your workaround in https://bugs.launchpad.net/bzr/+bug/772935?  lp:lightdm can't get branched anymore
<ubot5> Ubuntu bug 772935 in Bazaar "ErrorFromSmartServer: Absent factory for StaticTuple" [High,Confirmed]
<Riddell> poolie: https://bugs.launchpad.net/bzr-explorer/+bug/814408
<ubot5> Ubuntu bug 814408 in Bazaar Explorer "Exception "bzr: ERROR: Could not acquire lock" occurs very often. " [High,Confirmed]
<poolie> Riddell: https://bugs.launchpad.net/bzr/+bug/680529
<ubot5> Ubuntu bug 680529 in QBzr ""Lock was renamed into place, but now is missing"" [High,Confirmed]
<seb128> Riddell, could anyone help robert_ancell with his "ErrorFromSmartServer" issue?
<poolie> jam, for me, os.fsync does take a fileno parameter
<seb128> it's blocking a lightdm update in oneiric
<poolie> and it seems to pass on winepython
<jam> poolie: interesting. It definitely doesn't here
<poolie> hi sed
<seb128> which robert_ancell wants to get out before being on holidays
<seb128> Riddell or somebody else
<poolie> seb128: where?
<seb128> robert_ancell, ^
<jam> hmm...
<seb128> poolie, try to checkout lp:lightdm
<robert_ancell> in bug 816296
<ubot5> Error: Launchpad bug 816296 could not be found
<jam> it does take one here, so why was it failing?
<robert_ancell> (private)
<seb128> he gets something similar to bug #785029
<ubot5> Launchpad bug 785029 in bzr (Ubuntu) "bzr crashed with ErrorFromSmartServer in _raise_smart_server_error(): Error received from smart server: ('error', "Absent factory for StaticTuple('__init__.py-20100827182754-i149503ctn97gm7c-2', '<email address hidden>')") (dup-of: 772935)" [Undecided,New] https://launchpad.net/bugs/785029
<ubot5> Launchpad bug 772935 in Bazaar "ErrorFromSmartServer: Absent factory for StaticTuple" [High,Confirmed] https://launchpad.net/bugs/772935
<Riddell> bzr branch ubuntu:lightdm  works fine for me
<Riddell> robert_ancell: what version of bzr are you using?
<poolie> jam, actually nm that, i'll investigate
<jam> poolie: so disregard my statement, it does take "filedescriptor"
<poolie> help robert if you can
<seb128> Riddell, try lp:lightdm
<robert_ancell> Riddell, 2.4b5
<Riddell> mm, yes, boom
<robert_ancell> Riddell, the branch is lp:lightdm that doesn't work
<poolie> thomi: hi
<thomi> Hi poolie
<jam> I can replicate that here as well
<jam> grabbing a copy from LP real quick
<poolie> thomi, probably through distutils.sysconfig or something
<jam> it fails with bzr.dev as well
<thomi> poolie:  ahh of course, that would make sense.
<thomi> poolie: I think I have something working, but it seems like there's lots of places in the code that call GlobalCOnfig() directly rather than GlobalStack
<jam> ah, it is failing with "AbsentFactory"
<jam> meaning it is missinga file text
<poolie> excellent!
<poolie> yes, they're going to need to be updated
<jam> something pushed up a revision that referenced a file text that didn't get copied.
<poolie> but i hope it will be pretty mechanical
<jam> I don't specifically know why
<poolie> you could do the update separately
<jam> robert_ancell: there are potentially 2 fixes
<thomi> I have it as separate branches, I'll decide whether to merge them before pushing or not later.
<jam> 1) figure out what rev that is (not too hard), and then do surgery to remove that revision from the repository (trickier)
<jam> 2) Use spiv's fetch-everything to try to fill in that missing text
<robert_ancell> jam I don't know what the first branch is in spivs command
<jam> robert_ancell: presumably you have another copy of the branch on your local machine, which likely has the content
<robert_ancell> yes, with some other changes committed and pushed to another location
<jam> ugh, the revision is quite old
<jam> '...-20100710034239-8eysy1lpccerztec'
<robert_ancell> So spiv's command is: bzr fetch-all-records lp:? lp:lightdm, but what do I put in ?
<jam> 2010-07-10
<jam> robert_ancell: "bzr fetch-all-records local-branch lp:lightdm" I believe.
<robert_ancell> will that bring those extra commits I made?
<jam> robert_ancell: it will put them in the repository, but it won't change the branch pointer
<jam> so the history looks the same to someone doing "bzr branch lp:lightdm"
<jam> but there happens to be some more content that they don't fetch
<seb128> robert_ancell, does your vcs has what is in lp:lightdm with new commits or did they divert?
<seb128> robert_ancell, because you can copy the your checkout to a new dir, bzr uncommit until the revision you want and bzr revert
<seb128> robert_ancell, that should give you a checkout without the new commits
<robert_ancell> ok, so I rewound my local branch, so I have ~/bzr/lightdm which is what should be on the server.  What's the next step to fix lp:lightdm?
<poolie> night all
<seb128> jam: ^ do you know about robert_ancell's question?
<spiv> jam: another workaround is nosmart+
<spiv> jam: and another may be to not fetch into a shared repo
<spiv> jam: (or perhaps to fetch into a shared repo?  I forget.  There's definitely at least one case where one way triggers and the other doesn't)
<jam> spiv: are you talking about the lightdm stuff? The branch itself is broken. After using hitchiker to copy it down, I can't "bzr branch lightdm other"
<jam> I don't know how it lost a text which was a year old, though
<jam> there are no "obsolete_packs" in it
<jam> I wonder if someone repacked and deleted them
<spiv> jam: oh, ok.
<spiv> jam: I was just guessing from the symptoms, I must of guessed wrong!
<jam> spiv: right, AbsentContentFactory in this case is because a text is referenced which is not present in the repository.
<spiv> A year ago *might* be old enough to mean someone used a version of bzr with stacking bugs?
<jam> spiv: certainly possible, though this is a development focus branch...
<spiv> Odd.
<jam> though maybe it wasn't in the past
<spiv> And it's unstacked currently?
<jam> $ cat .bzr/branch/branch.conf
<jam> stacked_on_location = ""
<jam> parent_location = ../../../~robert-ancell/lightdm/trunk/
<spiv> Hmm, that suggests it was stacked in the past
<jam> yeah
<jam> and I have a clue where it was stacked on :)
<spiv> So probably a stacking bug.
<spiv> Yeah :)
<spiv> jam: I find the repo-has-key command helpful for identifying which repo has the necessary record
<spiv> Anyway, food time!
<spiv> Happy bug squishing.
<jam> spiv: and lo-and-behold, the text key is present in lp:~robert-ancell/lightdb/trunk
<jam> (lightdm even)
<jelmer> spiv: bon appetit
<jelmer> spiv: it looks like dpkg-mergechangelog behaves slightly different on Debian sid :-/
<spiv> jelmer: better? </optimism>
<jelmer> spiv: The odd thing is that it's the same version as on oneiric
<jelmer> spiv: it actually generates a conflict for the first test case in test_3way_conflicted
<jam> spiv: looks like a bad unstacking job. If I manually re-add stacking, I can branch locally again.
<jam> so I think someone decided to unstack by removing the config setting
<fullermd> Less "unstacking" than "toppling" then  ;p
<spiv> jam: I recall a scary XXX in Branch.unstack, but yes that sounds probable
<jam> spiv: of course, I'm trying to post that to the bug and LP is timing out now...
<exarkun> Can I convert one directory of an svn repository to a bzr branch?
<exarkun> It looked like maybe I could point bzr svn-import at it with --layout=root, but apparently not
<jam> exarkun: bzr branch svn:.../subdir
<jam> I'm pretty sure "bzr branch path" always works
<jam> svn-import doesn't because it tries to come up with multiple branches to import
<exarkun> Meh http://codepad.org/f4MHt3FZ :(
<jelmer> jam, exarkun: --layout=root means treat the root of the repository as a branch
<jam> exarkun: my immediate thought is to just delete your svn cache and try again
<maxb> My local copy of bzr-svn is modified to never use tdb even if it's installed, for various performance and fragility reasons
<exarkun> maxb: Uh, so you use the SQLite backend?
<maxb> yes
<exarkun> which is full of concurrency bugs that I think I maybe heard no one was interested in fixing
<maxb> It's not buggy, it just doesn't let you run two operations against the same svn repository at once
<maxb> On a client workstation, you very rarely would want to do that anyway
<exarkun> maxb: nah, it's buggy.
<jelmer> maxb: what's fragile about tdb?
 * exarkun trying with old caches moved aside now
<maxb> As exarkun is experiencing, it can get itself into a state which bzr-svn cannot resume from
<maxb> Granted this is bzr-svn's usage of it that's the problem, not tdb itself
<maxb> $ bzr branch svn://svn.twistedmatrix.com/svn/Twisted/trunk/emacs
<maxb> Branched 10 revision(s).
<exarkun> Great, bzr branch worked
<exarkun> maxb: :)
<exarkun> Thanks.
<maxb> My other problem was TDB is that it turned pathologically slow once my cache DB became sufficiently huge, to the point at which I was habitually cat-ing it to /dev/null to prime the disk cache
<maxb> Since switching to sqlite, I've been happy
<maxb> Even though my cache-v5 file is 1.1GB :-)
<jelmer> maxb: I wonder if that particular problem is really the tdb backends fault or somethng else
<jelmer> maxb: in SQLite "SELECT * from paths WHERE revnum = 42" just yields no results rather than an error if that entry was never filled in
<maxb> IIRC from when I looked into this, the problem was with bzr-svn's storage of the minimum / maximum revno present in the cache, and them being updated inappropriately
<maxb> Basically the maximum revno was being advanced before the data had actually been filled in
<jelmer> maxb: would be nice to have that in a bug report :)
<jelmer> I think there's one or more bug reports about that KeyError, but I haven't had time to look into them yet
<maxb> Yes... I was intending to understand it some more first, but then I got distracted and switched to sqlite
<jelmer> maxb: So my understanding of it would be that with sqlite you have an incomplete cache, which is even worse I think
<maxb> I think sqlite just tended to roll back the transaction and leave you with wasted work, but a correct cache
<maxb> It was a while ago, though
<jelmer> maxb: hmm
<jelmer> Riddell: did you see bug 812749 ?
<ubot5> Launchpad bug 812749 in bzr-builddeb "Misuses bzr 2.4's new set_commit_message hook to disable editor prompting for a commit message entirely" [Undecided,New] https://launchpad.net/bugs/812749
<Riddell> jelmer: no, I'll comment
<zyga> hi
<zyga> any way to have revision id from command line
<zyga> bzr revno --with-revision-id or something?
<james_w> bzr log --show-ids has it
<jelmer> zyga: bzr version-info
<zyga> jelmer, oh, wow, I have no idea how I have missed that! brilliant
<jelmer> zyga: or 'bzr revision-info'
<zyga> the other is even better
<zyga> is there any reference for return values on commands
<zyga> like bzr status and bzr pull
<zyga> I'
<zyga> I'm trying to implement a small wrapper around bzr
<zyga> and I need methods such as is_dirty(), pull_without_merge()
<zyga> I did this with bzrlib before but it was rather hard to read and not something I felt confident with
<mgz> jelmer, did you have a paste accident in the comment you pasted to the selftest-xfail-msg mp?
<mgz> I see the diff twice but not the output.
<poolie> hi all
<jelmer> hey polie
<poolie> hi jelmer
<jelmer> *poolie
#bzr 2011-07-27
<peitschie> hiya everyone
<peitschie> is there someone here that can lend a hand troubleshooting a corrupted repo?
<AuroraBorealis> oh gee
<spiv> peitschie: sure
<peitschie> I'm getting the following error every time I run a command: bzr: ERROR: No such file: u'/vsl/bedrock/BSDSRG/Projects/Bond Advance/Bazaar/.bzr/repository/indices/1243d19cced51e076aaf9e36f173c9ee.rix': [Errno 2] No such file or directory: u'/vsl/bedrock/BSDSRG/Projects/Bond Advance/Bazaar/.bzr/repository/indices/1243d19cced51e076aaf9e36f173c9ee.rix'
<peitschie> hi spiv :)... it's been a long time btw... bzr has been humming along without incident for almost 10months since the svn ghosting issues :)
<spiv> peitschie: hmm, take a look in .bzr/repository/obsolete_packs, it might have that file
<peitschie> it looks similar to this: https://answers.launchpad.net/bzr/+question/96346 ... I'm walking through those now
<peitschie> no joy on the obselete packs
<spiv> Was there a system crash around that time?
<peitschie> only one file in there which has a vastly different name
<peitschie> spiv: looking into it now...
<jam> morning all
<peitschie> spiv: looks like some nfs issues somewhere...
<spiv> peitschie: ah, ouch
<spiv> poolie's just-landed patch to call fdatasync may help avoid this problem in future.
<peitschie> spiv: mm... could be fun... what are the chances I can save the repo if this has caused some kind of file corruption?  the thing will have done this in the last few hours
<peitschie> spiv: interestingly, I can see the desired pack file listed in the pack names, just the actual indicies file seems to be missing
<peitschie> spiv: there also appears to be no actual pack name with that file under packs
<spiv> peitschie: the suggestions on that link you found are probably your best bet
<spiv> peitschie: i.e. remove that entry from pack-names, on the assumption it was only that new pack that is missing.
<peitschie> spiv: ok.  I'll give that a shot and see what happens :).  What will that do to any clients that believe the file was uploaded to the server?
<spiv> peitschie: most likely there's a single new revision that's been lost
<spiv> If there's a client that had a repository stacked on this one, that might be an issue (although probably they'll have the necessary data locally)
<spiv> If there's a lightweight checkout using that repo that thinks it's current version is the lost revision it'll be understandably sad and confused :)
<spiv> Probably though other repositories will be fine.  If there's a branch in that particular repo that was pointing to the missing revision it'll be broken and need to be repaired to point to an existing revision
<AuroraBorealis> seems like bzr is pretty easy to break.
<AuroraBorealis> is there no safeguard for when one file goes magically missing?
<peitschie> spiv: mmm... well.. once IT gets their NFS stuff together again we shall start the great exploration I guess.  Most of these are straight checkouts so hopefully things are not lost yet :)
<spiv> AuroraBorealis: if the filesystem randomly loses data from under you without warning?  yes
<AuroraBorealis> i mean...if the OS crashes, if the internet dies in the middle of a commit, seems like a lot of things could cuase this...
<spiv> AuroraBorealis: the repair tools could certainly be better, but usually the best answer to FS corruption is "restore from your backup"
<spiv> AuroraBorealis: we're robust against network connection dropouts
<AuroraBorealis> even if the repo is on a dumb ftp server?
<spiv> AuroraBorealis: this case is bzr has committed it's transaction, i.e. renamed files into place, then finally updated the central index file to refer to the new files, and then somehow those files that were totally definitely there a moment ago are gone
<spiv> AuroraBorealis: yes, even on FTP
<spiv> AuroraBorealis: at worst bzr might ask you to run 'bzr break-lock'
<spiv> AuroraBorealis: but it won't damage the repository
<AuroraBorealis> ok
<fullermd> We need a bzr plugin that punches you in the head if you use FTP.  And ideally, the server's admin too.  Twice.
<AuroraBorealis> uhhh
<AuroraBorealis> i use ftp
<AuroraBorealis> because i dont have root access to my box
 * fullermd winds up...
<AuroraBorealis> what else am i supposed to use
<fullermd> Punching the person with root in the head.
<AuroraBorealis> that doesn't answer my question
<AuroraBorealis> its a cheap hosting plan, they never give you root access
<AuroraBorealis> and since the documentation for the supposed 'bazaar smart server' is laughably nonexistant
<fullermd> That probably calls for high explosive.
<fullermd> There are things in life more infuriating and revolting than the continued existence of FTP.  But it's a short list.
<AuroraBorealis> since you since to be a troll, i'll stop now :>
<poolie> hrm
<poolie> AuroraBorealis: if the os dies in the middle of a commit, bzr has various ways to recover
<AuroraBorealis> ah ok.
<poolie> the recent sync patch is to respond to ext4 and xfs caching very aggressively
<poolie> which means if the machine crashes or powers off suddenly, a lot of data can be lost
<AuroraBorealis> i thought that the caching time of ext4 was shortened for that reason hehe
<fullermd> poolie: Speaking of that, I wondered in passing how much of the added time in your test on that could come from it rooting around to find fdatasync || fsync || nothing on every call (as it looked to do)
 * fullermd has no idea at all of the expense ballpark on that.
<poolie> fullermd: almost certainly nothing
<poolie> that's just one python object lookup
<poolie> and this should only be hit about say 5 times in a bzr commit command
<poolie> it's trivial compared to physically moving disk heads around
<poolie> reasonable question though
<poolie> if it was wrapping a very cheap operation and called very often it could be a probelm
<fullermd> Well, you did your test on a memory filesystem, AIR.  So it occured to me.
<spiv> poolie: Unless testing the flag accidentally triggered a fresh reload of the various potentially-relevant config files...
<fullermd> The time delta did look a little higher than I'd expect just for the extra jumping into the kernel.
<poolie> actually that is more feasible
<spiv> poolie: a bit like not opening the wt object in the test tear down (to check isolation) was apparently causing locations.conf to be re-parsed
<spiv> Or maybe I'm getting confused with Branch.open reading the stacked_on_location value
<spiv> Which we also fixed to avoid looking at the whole config stack :)
<poolie> you are quite right this might cause more config work
<spiv> I think vila has some preliminary bits to count config file opens in the test suite
<poolie> in the test suite on a tmpfs i would have thought that io would be pretty cheap too, though perhaps the cpu overhead is significant
<spiv> poolie: I guess do a run with and without the patch and compare what 'time' says for user and system time?
<poolie> that should have been in there...
<fullermd> Going into the kernel to look at files is expensive, even if it's all in memory.  See that comment I made on the find_branches bug...  last week?
<spiv> Or use the new-fangled perf thingy that gives more numbers and less clarity ;)
<poolie> wow, interesting
<poolie> and, there is indeed a lot more userspace cpu time
<spiv> fullermd: I guess all that repeatedly resolving paths to dentries takes some work
<fullermd> Yeah.  Almsot 5 minutes longer, but only 9 more seconds system.
<spiv> poolie: hmm
<spiv> poolie: I would actually start to be suspicious of the config system at this point.
<poolie> likewise
<poolie> i might profile a single run of a commit
<spiv> poolie: I suppose you could try hacking the points that test the flag to just be hard-coded True without looking at the config?
<poolie> indeed
<fullermd> Well, probably not dentries in this case of course   ;)
<fullermd> But going into the kernel and walking through the VFS isn't free, especially when you do it a crapload of times.
<poolie> spiv, i'll try that
<jelmer> 'morning spiv, poolie, fullermd
<poolie> istm that the tests probably want to by default just not have a file for the per-user or per-location config
<poolie> we know it won't have anything in it
<poolie> hi jelmer
 * fullermd waves at jelmer.
<spiv> poolie: and generally they don't
<poolie> generally they won't care
<spiv> poolie: yet apparently the cost of looking for them is noticeable
<poolie> of course it does make an interesting benchmark in this case, but not a totally representative one
<poolie> is anyone else seeing test_unicode_bzr_home failing on linux?
<jelmer> jam: hi
<spiv> Grar, wireless dropping out.
<jam> hi jelmer
<poolie> hi jam
<poolie> it looks like you touched this last in https://code.launchpad.net/~jameinel/bzr/2.3-unicode-home/+merge/46015
<spiv> Ah, back.  I'll just assume a neighbour was using the microwaveâ¦
<poolie> the cosmic rays of our time
<jam> poolie: that code is all done inside an "if win32" block
<poolie> true
<Riddell> happy Wednesday all
<poolie> hello riddell
<poolie> ok, good night all
<spiv> poolie: g'night
<jelmer> hmm, is there a UDD meeting today?
<jelmer> it has been two weeks since the last one but I don't see anything on the wiki
<poolie> hi
<poolie> i was expecting one
<exarkun> What is the state of https://bugs.launchpad.net/bzr/+bug/427773 ?  It's not clear why it is "Confirmed" for "Bazaar" and "Fix Released" for 2.0.
<ubot5> Ubuntu bug 427773 in Bazaar "empty limbo dirs cause error about left-over files" [Medium,Confirmed]
<poolie> exarkun, vila's last message is not very helpful is it?
<poolie> exarkun: are you hitting this bug, or something that looks like it?
<poolie> if so, saying so on the bug would help
<exarkun> I'm hitting it on a somewhat old version of bzr that will be a real pain to upgrade.
<jam> jelmer, Riddell, poolie: Hey guys, Kareem just came home with a 41C fever. So I'll be out for the afternoon. At this point I have to figure out if I can still go on vacation...
<poolie> sorry to hear that jam, i hope he gets better soon
<Riddell> ouch, good luck jam
<poolie> there seems to be a lot of it around
<exarkun> Hm, not that old though, 2.1.1.
<jam> poolie: yeah, I didn't get nearly as bad of a fever. And the only childrens medicine they seem to have is a suppository, which he is not taking very well... :(
<jelmer> jam: ouch :( good luck, I hope he gets better soon
<jam> jelmer: do you just not have childrens liquid paracetamol ?
<jam> (or motrin/ibuprofen )
<jelmer> I dont think I have ever seen it.
<jelmer> jam: I would expect a pharmacy to have it though, maybe not a drugstore
<jelmer> jam:
<jelmer> I am off again, back in a couple of hours
<jam> jelmer: well, I went to the pharmacy and asked for something in liquid form, and this is what they gave me.
<jam> but maybe if I try harder
<jelmer> p
<spiv> jam: eek
<spiv> jam: hope he gets better quickly
<jelmer> jam: they should be able to recommend something else in the pharmacy perhaps?
<jam> jelmer: yeah, we see the doctor in 20 min, we'll certainly ask then
<jam> spiv: your comment on: https://code.launchpad.net/~jameinel/bzr/2.4-launchpad-package-freshness-609187/+merge/69218
<jam> it seems to be rendering like I wanted. Did you have something in mind?
<poolie> riddell, jelmer, #ubuntu-meeting?
<jelmer> I am not really here, on my cell
<poolie> np
<spiv> jam: no, just that the ReST looks weird to me, but it must be a corner of the syntax I'm not familiar with.
<spiv> (Or have forgotten)
<SeTTleR> hi, how can i create such a shortcut like lp: for bzr, so that I do not have to write a full url everytime i want to create or delete a branch?
<fullermd> Take a look at the bookmarks plugin.
<SeTTleR> ok, will do that. thx!
<jimis> Is there a way to mark a branch as closed, so that I don't accidentally commit in the future?
<fullermd> `chmod -R a-w .bzr`?   ;)
<fullermd> No explicit way.  I could probably dream up a few more horrific hacks that would pull it off...
<jimis> :-)
<jimis> thanks fullermd, I also found this has been asked before: https://answers.launchpad.net/bzr/+question/80723
<fullermd> Ooh, I think there's some way to put a plugin directly in a branch (so it only triggers on that).  So maybe you could make a plugin that hooks in pre-commit and puts on the brakes there.
<jimis> it would be useful
<jml> looks like loom is broken in oneiric?
<jml> http://paste.ubuntu.com/653183/
<peitschie> you around spiv?
<poolie> hi all
<poolie> 4rgbmjcn3
<poolie> well, i won't be using _that_ one again
<poolie> :)
<fullermd> Red Gallumphing Bottles of Merely Juvenile Collected Nailpolish?  :p
<poolie> hi fullermd
#bzr 2011-07-28
<peitschie> hi poolie, fullermd :)
<poolie> hi
<mlh> something for the SCA folks: http://www.popularmechanics.com/technology/digital/fact-vs-fiction/medieval-knights-on-a-treadmill-put-historical-myths-to-the-tes
<mlh> oops wrong chan
<poolie> heh
<thumper> poolie: hi
<poolie> hi there
<thumper> is there a way to get bzr to apply a patch file?
<thumper> or do I just use patch?
<poolie> "bzr patch" :)
<thumper> gah, here I was looking for a merge option
<poolie> from bzrtools i think
<poolie> is this a bzr bundle, or just a plain patch?
<poolie> if it's a bzr bundle with metadata, you want 'bzr merge'
<thumper> it is a plain patch
<thumper> which fails to merge
<poolie> thumper, can you search your brain and social network for someone suitable for bit.ly/ubuntu-vcs-job
<thumper> so I'll be editing the files manually by the look of it
<poolie> try the external tool 'wiggle'
<thumper> poolie: I mentioned the job to thomi
<thumper> poolie: he is mildly interested
<thumper> but committed to teach until Dec
<poolie> yeah he could be interesting
<thumper> wiggle?
<AfC> Interesting to see Go in that job description
<thumper> AfC: Go has been added to almost all the new canonical jobs
<thumper> someone is becoming a fan
<thumper> poolie: bit.ly is timing out for me :(
<AfC> thumper: the same person who became a Qt fan? :)
<thumper> AfC: perhaps
<AfC> {sigh}
<thumper> I couldn't possibly comment :)
<thumper> that said, Go does look interesting
<thumper> I've been trying to think of something interesting to write in it
<AfC> thumper: http://www.dilbert.com/fast/1995-11-17/
 * thumper sighs
<thumper> it seems vodafone's 3G is having issues
<thumper> some ports are fine
<thumper> but 80 doesn't seem to be one of them
<poolie> afc, more like http://twitter.com/#!/gniemeyer
<poolie> also, http://browsertoolkit.com/fault-tolerance.png
<poolie> and hi
<AfC> poolie: and unto you, hi
<AfC> hahahah
<poolie> i love that
<AfC> that's bloody awesome
<mlh> go and qt huh?  has someone put them together?  I goog'd but didn't find anything
<mlh> also, that ft comic is awesome; does anyone know where the original is?
<thomi> poolie: got a second?
<poolie> hi, sure
<thomi> I've managed to get the system-wide config file working under Linux, with a few caveats:
<poolie> hooray
<thomi> first, as far as I can see, the only place in bzrlib that uses the config stack rather than the old config store API is when picking which editor to use for commit messages.
<thomi> Second, I'm unsure how to go about writing tests for the new code.
<poolie> it's mostly not updated yet
<poolie> vincent's in the middle of working on this
<poolie> hm
<thomi> oh ok, cool.
<poolie> but if you update some of them that are relevant to your work, i'm sure he won't object
<poolie> so, what do we want to test?
<poolie> i'd say it's mostly that when you ask for one of these stacks, you get something that includes the global config fie
<poolie> *file
<thomi> right
<thomi> there are tests already for the stack stuff.. let me see....
<poolie> for the purposes of test isolation, we might want to make sure we don't see the actual real global file
<poolie> so i'd probably add something in osutils or config.py that says where it is
<poolie> then that can be overridden by the test suite
<thomi> So there's already a test that makes sure that the stack works as expected with mutliple config sources.
<thomi> There's also tests that ensure that the config file stores work as expected.
<thomi> Do we need a third test that explicitly tests with two files on disk? It seems like the functionality has already been covered by other tests; I'm not sure what I'd actually be testing...
<poolie> so i think your incremental test mostly needs to be that the pre-canned class stacks are including something that points to the global one
<poolie> i don't think so
<poolie> we can add that if we find there's actually a problem
<thomi> when you say "pre-canned class stacks" you're referring to "GlobalStack", "LocationStack" and "BranchStack"?
<poolie> yes
<thomi> hmmm, those Stack classes create the config store instances in their constructors, so unless I'm missing something (possible), I can't see how to write that test and keep it independant of the files on disk.
<poolie> hm
<poolie> it's ok if they read the file on disk during the test
<poolie> we may want to make sure that other tests don't read the global config though, or it will tend to leak in
<poolie> one way is to use overrideAttr to monkeypatch the method that gives you the file name
<poolie> maybe you should push your branch and propose it and then we can look at that together?
<thomi> ahhhh
<thomi> ok, it's pushed, I'll propose it now, although you have to understand that it's really not finished yet ;)
<poolie> that's totally ifne
<poolie> *fine
 * thomi waits for the diff to update...
<thomi> Here we go:
<thomi> https://code.launchpad.net/~thomir/bzr/add-global-config/+merge/69592
<thomi> nuts - my editor automatically trims trailing whitespace, which makes the diffs in launchpad look a bit messy.
<poolie> hm
<poolie> that's ok, there's not meant to be any whitespace
<Riddell> hello all
<poolie> hello riddell
<tmm1> is there a way to set the default repo/pack format to use?
<tmm1> i'm dealing with a legacy remote and don't want to do the on-the-fly conversion all the time
<jelmer> tmm1: hi
<jelmer> tmm1: you can set an alias for init, e.g. "bzr alias init='init --format=pack-0.92'"
<tmm1> jelmer: thanks
<thevibe> bzr 2.1.1 break-lock not working - can't break the lock? how can I break a lock? Any ideas?
<thevibe> so... any ideas?
<Riddell> thevibe: what doesn't work about it?
<Riddell> oh, too late
<kjbbb> hey everyone. quick question. i created a branch with --no-trees. How do i get a working tree back?
<jelmer> kjbbb: "bzr co"
<kjbbb> ah, easy, thanks :)
<lamont> if I want to alter a single tree on a machine such that "bzr uncommit" requires extra effort to do, maybe even blatting out a "no really, don't do that" message, is that trivial, or painful to do?
<fullermd> There's that param to require the head to stay on the left path.  It's really aimed at keeping people from pushing over something changing the left path (e.g., 'merge X ; push X'), but it prevents uncommit too.
<fullermd> No override for it other than commenting out the config param, AFAIK.  So that may be too heavy for you?
<poolie> hi all
* poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie
<Riddell> good morning poolie
<poolie> hi there, good evening
<Noldorin> jelmer, heya
<jelmer> Noldorin: hi
<jelmer> hi Riddell, poolie
<Noldorin> jelmer, i'm back (after much time) to trying to install bzr-git ;-)
<Noldorin> thought i could use your assistance a bit
<Riddell> how's Republika Srpska jelmer?
<Noldorin> so firstly
<Noldorin> how do i install dulwich so that it gets included by the precompiled version of bzr on Windows?
<jelmer> Riddell: it's great, much nicer than I had expected
<jelmer> Noldorin: you'll have to compile dulwich yourself, the standalone installer doens't include it
<Noldorin> jelmer, sure...are there instructions anywhere? i see none
<jelmer> Noldorin: I don't think there are; if you're ok with running just the python source (not the optimized compiled versions) it should be a matter of putting dulwich somewhere in your $PYTHONPATH
<Noldorin> jelmer, no INSTALL file in the package...
<Noldorin> just dloaded 0.7.1
<jelmer> Noldorin: The installation should be like any other Python package
<Noldorin> python setup.py install
<Noldorin> yes
<Noldorin> jelmer, that works but remember i am running the Windows bzr binaries...which ignores PYTHONPATH i believe
<jelmer> Noldorin: you can't use the standalone python installer if you do that
<jelmer> I think
<Noldorin> jelmer, so i cannot use the standalone python installer + bzr-git at all?
<jelmer> Noldorin: as far as I understand, no
<Noldorin> right
<Noldorin> got it
<Noldorin> jelmer, time to uninstall the standaloen version and re-install the python 2.7 version :-)
<Noldorin> jelmer, shouldn't affect how i use it, right?
<jelmer> Noldorin: I don't think so, but I have almost zero experience using bzr on windows
<Noldorin> ok sure
<Noldorin> yeah think you've said before
<Noldorin> jelmer, it sounds logical though
<Noldorin> jelmer, any x64 builds of the windows installer?
<Noldorin> bzr-2.3.4-1.win32-py2.7.exe
<Noldorin> but i want x64
<jelmer> no idea, sorry
<Noldorin> sure
<jelmer> Noldorin: the bzr-windows mailing list might also be of use
<Noldorin> yeah
<Noldorin> found something there already
<Noldorin> jelmer, ok i've installed bzr-python (with a bit of trouble on my x64 box)...where is its location on disk?
<Noldorin> also no tortoisebzr i guess? :-(
<jelmer> Noldorin: sorry, I have no idea about those things
<Noldorin> ok sure
<jelmer> Noldorin: the bzr-windows list might be a better bet, or jam/bialix when they get back from holidays
<Noldorin> jelmer, no-one else here eh??
<jelmer> Noldorin: I'm not sure if there is anybody else here at the moment familiar with the internals of the windows installer
<poolie> i think you can still catch jam today before he leaves but you'd better send mail
<Noldorin> ok sure
<Noldorin> poolie, nickname is 'jam' too?
<poolie> yes
<Noldorin> thanks
<Noldorin> poolie, the code for building the windows installer is in the standard bzr branch?
<Noldorin> maybe i can just modify that
 * jelmer gets some sleep
<Noldorin> g'night
<poolie> Noldorin: i think it's in a separate project https://launchpad.net/bzr-windows-installer
<Noldorin> ok cool
<Noldorin> poolie, might be my best bet if i want dulwich/bzr-git on windows?
<poolie> yes
<Noldorin> ta
<poolie> if you get that and update it to include them it could well work
<Noldorin> yeah
<Noldorin> that's the plan
<Noldorin> and also make the installer x64 if it's not too hard!
#bzr 2011-07-29
<poolie> lifeless: could you give me a quick http review https://code.launchpad.net/~mbp/bzr/198646-http-boundary-2.3/+merge/69440
<lifeless> poolie: so does that transparently retry ?
<poolie> yeah that's the bit around line 109
<lifeless> will it be clear in .bzr.log that this happens?
<lifeless> (readv -> full read imposes quite a heavy network cost on big pack files / indices)
<lifeless> (both the re-read, and making 2 requests, and the original that gets thrown away using the downward pipe
<poolie> there's a mutter statement
<poolie> unconditionally
<poolie> based on henrik's statement this will be somewhat intermittent
<lifeless> the one I can see doesn't say anything about retries
<poolie> nb this isn't immediately going to read the whole thing
<poolie> it's going to fall back to reading one range at a time, and only if that fails, the whole thing
<lifeless> ok
<poolie> based on the description of the squid bug i think that will be enough
<poolie> obviously it also somewhat sucks
<poolie> oh, actually
<poolie> _degrade_range_hint does explain what it's doing
<poolie> thanks
<lifeless> poolie: no worries
<lifeless> its nice to get corner cases like this addressed
<poolie> yeah, it's not really our bug but it's nasty when someone hits it
<Merwin> Hi everybody! I've a question about Bazaar, if I want to create a branch to do some experimental stuff, I have to create a new directory with the new branch. The problem is that in Eclipse, I must create or reconfigure my project to work on this branch...
<Merwin> Is it possible to work on a new branch in the same directory and switch to an other when we want without changing directory ?
<poolie> hi Merwin, yes, i recommend you use the bzr-colo plugin
<Merwin> poolie: looks exactly what I want, thank you ;)
<poolie> it's really good
<blackarchon> hi all
<blackarchon> bzr: ERROR: exceptions.ImportError: cannot import name shlex_split_unicode
<poolie> hi blackarchon, that's interesting
<poolie> nothing else?
<blackarchon> i got this when trying "bzr explorer" with bzr trunk and bzr-explorer trunk
<poolie> sounds like a broken installation or something
<blackarchon> i just installed them
<poolie> which version?
<poolie> oh, trunk
<poolie> really, current trunk?
<blackarchon> bzr-explorer is rev 527
<blackarchon> and bzr is rev 6046
<poolie> were they installed on this machine before?
<blackarchon> yes, before there was bzr 2.3.3 and explorer 1.1.3
<poolie> could you please run 'bzr --version' and 'bzr plugins -v' and check it's fetching things from the directories you expect?
<blackarchon> bzr --version: http://pastebin.com/87xu73UX
<Noldorin> jelmer, hey you still around>
<blackarchon> plugins -v: http://pastebin.com/TWEgDpn4
<blackarchon> ah i see, it's still using old explorer
<poolie> great, remove that or point it at the correct one and you should be ok
<blackarchon> ah thx, I renamed my plugins folder and it works now :)
<poolie> you're welcome
<blackarchon> another issue was that I had to use "python setup.py install build_ext --allow-python-fallback" to install bzr trunk
<blackarchon> because otherwise I get an error:
<blackarchon> building 'bzrlib._annotator_pyx' extension
<blackarchon> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c bzrlib/_annotator_pyx.c -o build/temp.linux-i686-2.6/bzrlib/_annotator_pyx.o
<blackarchon> cc1: error: bzrlib/_annotator_pyx.c: Der Wert ist zu groÃ fÃ¼r den definierten Datentyp
<blackarchon> what's the matter with this one?
<poolie> !
<poolie> nothing else?
<spiv> Missing Python.h maybe?  (wild guess)
<blackarchon> Cannot build extension "bzrlib._annotator_pyx". Use "build_ext --allow-python-fallback" to use slower python implementations instead.
<poolie> ok, now i'd guess maybe this used to be an amd64 machine and now it's 32 bit, or vice versa?
<blackarchon> error: command 'gcc' failed with exit status 1
<poolie> any warnings before the error?
<blackarchon> http://pastebin.com/YdQAdcyJ
<blackarchon> this is all
<blackarchon> it's a 32 bit debian squeeze
<poolie> can you run it with LANG=en_US so i can see the exact english error
<blackarchon> ok
<poolie> no 64-bit parts anywhere?
<blackarchon> the message is: Value too large for defined data type
<blackarchon> it's a pure 32 bit debian
<poolie> is it this: http://stackoverflow.com/questions/2438890/cc1plus-error-include-value-too-large-for-defined-data-type-when-compiling-wit/2496749#2496749 ?
<poolie> ie it's on an exotic filesystem or something?
<blackarchon> well it really IS on a smb mount - let me check this on a native ext3 file system
<poolie> hooray for google
<blackarchon> i would never expect the file system being responsible for such an error...
<poolie> it's pretty cryptic
<poolie> it would be nice if gcc at least gave a clue which operation was failing
<blackarchon> really, this would be quite helpful
<Noldorin> jelmer, you didn't fully remove all refs to lru_cache un dfulwich
<Noldorin> jelmer, also there is this relevant bug: https://bugs.launchpad.net/bzr/+bug/743256
<ubot5> Ubuntu bug 743256 in Bazaar Windows Installers "No way to install extra Python modules with stand-alone bzr installation on Windows" [High,Fix released]
<blackarchon> /usr/local/lib/python2.6/dist-packages/bzrlib/plugins/explorer/lib/explorer.py:264: DeprecationWarning: bzrlib.config.GlobalConfig.get_editor was deprecated in version 2.4.0. result = self._user_config.get_editor()
<blackarchon> :(
<jelmer> Noldorin: hi
<jelmer> blackarchon: that shouldn't be harmful
<Noldorin> jelmer, what shouldn't?
<jelmer> blackarchon: the deprecation warning he is seeing
<Noldorin> oh sorry
<Noldorin> not to me
<Noldorin> jelmer, hi
<Noldorin> jelmer, so yes, i can actually include custom modules in standalone bzr now thanks to that :-)
<Noldorin> did you see my brief bug report?
<blackarchon> jelmer: ok :)
<Noldorin> jelmer, 2nd problem now: the new dulwich does not define ThinPackData....the latest bzr-git requires it though :-S
<Noldorin> in remote.py
<Riddell> spiv: good luck with future adventures
<jelmer> Noldorin: don't use dulwich trunk with a release of bzr-git
<Noldorin> jelmer, i had to so that i could get --pure
<Noldorin> or maybe i don't need that now?
<jelmer> I think --purge has been in a few releases now
<jelmer> *pure
<Noldorin> jelmer, oh ok, never mind, working with the old dulwich now :-)
<Noldorin> jelmer, just a note regarding your dulwich trunk and lru_cache btw...hope you got that
<Noldorin> jelmer what does dulwich rely on for ssh?
<jelmer> Noldorin: you need to have an external ssh client installed
<Noldorin> jelmer, will putty do?
<Noldorin> jelmer, i think it's looking for standard openssh...
<jelmer> Noldorin: it has to be a command-line client, named ssh
<Noldorin> yeah
<jelmer> putty ships "plink" which might work if you rename it to ssh.exe
<Noldorin> jelmer, seems to yes...except it asks me whether to trust key...and stdin is redirected :-S
<Noldorin> error: index-pack died of signal 11
<Noldorin> bzr: broken pipe
<Noldorin> jelmer, well, let's discuss this tomorrow
<Noldorin> you know the issue
<Noldorin> thanks so fgar
<Noldorin> good night
<jelmer> Noldorin: g'night
<spiv> Riddell: thanks! :)
<jimis> Hi, I want to do "bzr switch -b newbranch" but create newbranch from a previous revision of current branch
<jimis> Is -rREV the way to do it?
<jimis> "bzr switch -rREV -b newbranch" didn't work, it created the new branch from current's branch tip
<jimis> any ideas?
<jimis> ok solved the problem by uncommiting the new branch to the revision I wanted
<jimis> but isn't it a bug that "bzr switch -rREV -b newbranch" didnot work?
<dobey> hi all
<dobey> would this behavior: http://pastebin.ubuntu.com/654553/ possibly be the cause of launchpad not showing a diff for https://code.launchpad.net/~ubuntuone-control-tower/ubuntuone-installer/trunk?
<Noldorin> hi jelmer
<ablmf333> Is there any bzr command to remove backup file generated by "bzr revert"?
<dannf> i'm looking to import / tag several releases of a piece of software from tarballs. my first stab was to look for something like svn_load_dirs, but bzr-equiv tools seem to all be deprecated. is there a canonical "right way" to do this?
<jelmer> hi dannf
<jelmer> dannf: it seems like what you want might be "bzr import" from the bzrtools plugin?
<dannf> hey jelmer :)
 * dannf read through the help...
<dannf> huh - yeah, that might be all i need. kinda obvious in retrospect :)
<santagada> why would a directory that I see on the web on launchpad do not show up in my local branch
<santagada> I did both bzr update and bzr merge
<santagada> both says its ok but the directory don't show up
<santagada> it is a --stacked branch
<jelmer> santagada: perhaps you have local revisions that deleted the directory?
<santagada> jelmer: no, I didn't even know it existed until today
<santagada> jelmer: and bzr status says its clean
<jelmer> santagada: what did you do to merge the remote branch?
<santagada> jelmer: I had some changes to two files before, which I didn't want to commit
<santagada> jelmer: now I did bzr revert * and it is saying that my tree is out of date
<jelmer> santagada: bzr up should fix that
<santagada> how the frack was it uptodate just before the rever
<santagada> revert
<santagada> and now it says it is out of date
<santagada> makes no sense
<santagada> jelmer: I tried bzr update, then tried bzr merge
<jelmer> santagada: is it a bound branch (created with "bzr co") or a normal branch?
<santagada> between then I tried also bzr pull but I think it started pulling all history of the repo
<santagada> jelmer: bzr branch --stacked
<santagada> or bzr checkout --lightweight I dont remember
<santagada> I learned to never ever use --lightweight or --stacked ever again after that, but this is an old tree
<santagada> great now I think it is working, but it is downloading the whole tree just to trhow it out after the update
<santagada> /tree/repo/
<jelmer> santagada: it sounds like you had an empty branch before
<santagada> jelmer: yep, but bzr did download 200mb, just to throw all out I think... who would ever ever whant that?
<jelmer> santagada: that's because of --stacked, which still is suboptimal for local branches
<santagada> jelmer: --stacked and --lightweight are suboptimal period
<santagada> I had like 20 problems with it... people that told me to use this think it is better because its faster
<santagada> it is never faster
<jelmer> santagada: it depends on what you're doing
<jelmer> santagada: --lightweight for local branches works fine
<santagada> if I didn't want to store revision data I could just delete .bzr
<santagada> jelmer: bzr doesn't do hard/simbolic links like mercurial?
<jelmer> santagada: why hardlink if there is no need to have those files in the lightweight checkout at all?
<jelmer> there is also an option to hardlink
<santagada> jelmer: because if I don't want to have history I could just delete the .bzr dir
<jelmer> santagada: see "bzr co --hardlink"
<santagada> always re-downloading it is like the worst idea. it makes bzr seems awfully slow
<santagada> now it downloaded 300mb and in the end I think I will have to do it again because It will probably throw the data out
<jelmer> santagada: that is more of an odd side-effect of using --stacked than a design decision
<jelmer> there are plans to allow --stacked (e.g. don't pull in remote data) but allow storing the data that has to be retrieved from the remote to be stored locally when we have to fetch it anyway.
<santagada> jelmer: can I open a bug report for deprecating it, or do anyone think this is usefull?
<jelmer> santagada: stacking is very useful, just not the way you're using it
<jelmer> santagada: e.g. launchpad stacks by default if you push to it
<jelmer> so you only have to push 3 revisions if you push a new branch
<jelmer> if you committed only 3 changes
<santagada> well mercurial and git do that and don't have --stacked
<santagada> they also don't have 400mb repositories
<jelmer> santagada: git has stacking
<jelmer> santagada: it's just got a different name
<santagada> jelmer: well by default when using github it just works
<jelmer> santagada: sure, but the same goes for Launchpad
<santagada> no, I see even docs on bzr about using --lightweight
<jelmer> santagada: same thing - there are situations in which --lightweight is a bad idea
<jelmer> santagada: if there are places in the docs where we recommend the wrong thing, I think we should fix them
<santagada> I see zero places where it is a good idea
<santagada> either hardlink or deleting .bzr solves everycase I seen of --lightweight
<jelmer> santagada: it allows you to do a commit to a large tree without pulling down all the history, for example
<santagada> jelmer: it does download all history
<jelmer> santagada: if it does, that's a bug
<santagada> jelmer: or at least a large subset of it
<santagada> I don't know, but a bzr update download 580mb of data seems like a bug to me
<jelmer> santagada: that does indeed sound like a bug
<santagada> well I'm just give up trying to understand it, delete all repos that I have and do a simple branch
<santagada> and continue using github for my stuff
<jelmer> hi Noldorin
<jimis> hi jelmer, any updates on lp:gcc?
<Noldorin> jelmer, hi :-)
<Noldorin> jelmer, so i've set up things now, but am getting an error when i dpush:
<Noldorin> h://git@github.com/alexreg/ircdotnet.git
<jelmer> jimis: sorry, nothing yet
<Noldorin> jelmer, i think this is a git error
<Noldorin> (using plink.exe btw)
<jelmer> Noldorin: what's the error?
<Noldorin> jelmer, that's it
<Noldorin> C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\0.4>bzr dpush git+ss
<Noldorin> h://git@github.com/alexreg/ircdotnet.git
<Noldorin> error: index-pack died of signal 11
<Noldorin> bzr: broken pipe
<jelmer> Noldorin: you might want to try with the very latest dulwich and bzr-git
<Noldorin> jelmer, ok sure
<Noldorin> will do
<Noldorin> jelmer, the repos for bxr-git and dulwich are on LP and Github respectively right>
<Noldorin> ?
<jelmer> Noldorin: yep
<Noldorin> ok
<Noldorin> jelmer, if i get this working i will right together a little blog post :-)
<Noldorin> jelmer, then maybe you can just link future people to that
<jelmer> cool :)
<Noldorin> jelmer, different error now:
<Noldorin> error: unable to find fb1c6f6b77779fe32a31c04494b385bc53aac21f
<Noldorin> fatal: object of unexpected type
<Noldorin> bzr: ERROR: unpack index-pack abnormal exit
<jimis> jelmer: please let me know if there is a bug I can subscribe to
<jimis> I'm a GSOC student for gcc, and that affects my work :-s
<jelmer> jimis: there is a bug, let me find the #
<jelmer> bug 797915
<ubot5> Launchpad bug 797915 in Launchpad itself "large bzr-svn imports failing" [Critical,In progress] https://launchpad.net/bugs/797915
<jelmer> jimis: what's your project?
<jelmer> Noldorin: what's the branch you're trying to push?
<jelmer> Noldorin: I can give it a try on linux, that way we at least know if it's a problem specific to windows
<jimis> thanks for the bug
<Noldorin> jelmer, git+ssh://git@github.com/alexreg/ircdotnet.git
<Noldorin> jelmer, sure
<Noldorin> jelmer, i think i added you as a committer a long time ago already :-)
<jimis> jelmer: GCC optimisation, see an outdated wiki page at: http://gcc.gnu.org/wiki/OptimisingGCC
<jelmer> Noldorin: but what branch are you trying to push?
<Noldorin> jelmer, oh sorry. lp:ircdotnet/0.4
<jelmer> jimis: I can do another one-off import if that helps
<jimis> jelmer: it's just that patches I post need to be against current trunk, for now I manually download the files that have changed and that I need to produce the patch
<jimis> thanks for the offer to help, I'll let you know when these files will be too many to handle manually :-)
<Noldorin> jelmer, any luck?
<Noldorin> jelmer, ?
<jelmer> Noldorin: sorry
<jelmer> Noldorin: got distracted by something else
<jelmer> Noldorin: I can reproduce it here
<Noldorin> no prob
<Noldorin> ok
<Noldorin> interesting
<Noldorin> jelmer, what should we try now then?
<jelmer> still looking
<Noldorin>    jelmer sure, just ping me :-)
<Noldorin>   jelmer getting closer to stability here!
<jelmer> 333433333333/win 3
<Noldorin> jelmer, hey
<Noldorin> jelmer, any updates? :-)
<Noldorin> jelmer, around still?
<RenatoSilva> is there a way/hack to revert a non-last revision without uncommitting the whole revision stack?
<Noldorin_> RenatoSilva, "revert a non-last revision" ?
<Noldorin_> are you missing a preposition there perhaps?
#bzr 2011-07-30
<RenatoSilva> I think if it doesn't conflict with any further revision, there could be a way to do it, it's just reverting the diff (because of no conflicts, it'd be just like undoing the revision manually)
<Noldorin_> explain what you mean first
<RenatoSilva> Noldorin_: I'm not NES. Non-last is one that is not the last, that is, one from 1..-2
<RenatoSilva> revert is undoing the changes
<Noldorin_> RenatoSilva, "revert a revision" is not well-defined though... we normally talk about "revert a working-tree" :-)
<RenatoSilva> Noldorin_: imagine revisions 1..230
<RenatoSilva> Noldorin_: the changes made by revision 222 need to be undone. I don't want to do this manually
<RenatoSilva> Noldorin_: that is, if the diff was -foo+bar, I need to -bar+foo, got it?
<Noldorin_> RenatoSilva, ah i see
<Noldorin_> RenatoSilva, so not "Revert" in ths bzr sense
<Noldorin_> RenatoSilva, no that is not possible
<Noldorin_> with any VCS i know
<RenatoSilva> Noldorin_: no, not $bzr revert
<fullermd> A better term would be 'reverse'.
<Noldorin_> it would require major changes to the way DVCS branches work.
<Noldorin_> fullermd, indeed
<fullermd> You can do it with merge.
<fullermd> You can't _remove_ the rev.  But you can make a new rev that _reverses_ it.
<Noldorin_> RenatoSilva, just commit the "un-diff" of that changeset
<Noldorin_> fullermd, oh, with merge?
<RenatoSilva> what's the diff between revert and reverse terms? Revert is rollback to a previous state, reverse is inverting/undoing?
<fullermd> The change you want to reverse is describable as "221..222" in this case.  So the reverse of it is "222..221"
<Noldorin_> RenatoSilva, pretty much correct, yes
<fullermd> So a `bzr merge -r222..221 .`  (don't miss that last '.', to tell it 'merging from myself') would use the merge logic to reverse the changes, taking into account the stuff since then.
<RenatoSilva> fullermd: I don't want to remove the rev, ok with new rev undoing it
<Noldorin_> there's inverse, converse, reverse...it's a bit confusing even to a NES sometimes!
<fullermd> (which may Just Work all shiny, or may have a giant pile of conflicts, depending on what all has happened since.  Luck of the draw.)
<RenatoSilva> what if I miss the dot?
<Noldorin_> fullermd, self-merging? and that simply modifies the working-tree?
<Noldorin_> RenatoSilva, command won't run
<Noldorin_> you need a merge source
<fullermd> It'll run, it'll just try to use the existing default merge source.  Which may not be what you want.
<Noldorin_> oh, fair point
<Noldorin_> but yeah, not appropiate.
<fullermd> Conceptually, it'll do the same thing as `bzr diff -r222..221 | patch`  (a.k.a, diff -r221..222 | patch -R; same thing).  So it leaves changes int he working tree.
<RenatoSilva> so "dot matters"
<Noldorin_> yes
<Noldorin_> it's crucial.
<fullermd> (it's better than just diff | patch of course.  It'll take into account renames since then, for instance, and deal with lots of shifted-around lines.  But if the lines in question are themselves changed, it's gonna get ugly and rely on Natural Intelligence resolution methods)
<fullermd> It would still work right if, for instance, the default merge source were the parent branch, which was just an exact mirror.
<fullermd> Or any time when 221 and 222 in whatever branch is resolves to are the same as the ones you have here.
<Noldorin_> fullermd, to clarify: bzr merge -r -1..221 is equivalent to bzr revert -r 221 right?
<Noldorin_> or bzr revert -r 220 perhaps
<fullermd> But it would take way longer to check if that was true than to just give it the .  ;)
<fullermd> It would be 221; remember that revs denote _states_, not _changes_.
<RenatoSilva> Natural Intelligence resolution methods => it will just point out conflicts to be solved manually right? or is it worse?
<fullermd> I'd certainly call it 'roughly equivalent' at least.  I'd have to think a lot more to convince myself the end result would be exactly the same.
<fullermd> It'd certainly be slower anyway...   you could use merge (with --force) to have uncommitted changes kept around.
<Noldorin_> fullermd, yeah...interesting. if there are differences, they must be subtle...
<fullermd> RenatoSilva: Yah.  I was being a bit whimsical, compared to Artifical Intelligence.  Merges are just textual, and if they don't just resolve, it would take an entity understanding the code semantics (e.g., the programmer) to make it right.
<RenatoSilva> fullermd: ok fullermd, big thanks. It's nice to think something could exist and it actually does :)
<Noldorin_> anyone here got bzr-git working on Windows?
<RenatoSilva> here's the issue (three last comments): https://code.launchpad.net/~renatosilva/bzr-eclipse/cleanup/+merge/68626
<RenatoSilva> done, thanks all! https://code.launchpad.net/~renatosilva/bzr-eclipse/cleanup/+merge/68626
<Noldorin_> jelmer, bug report at https://bugs.launchpad.net/bzr-git/+bug/818318.
<ubot5> Ubuntu bug 818318 in Bazaar Git Plugin "Error using dpush" [Undecided,New]
<Noldorin> hey jelmer
<bogglin> when I run bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk emacs I get the following error: bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<bogglin> how can i fix that?
<bogglin> this is bzr from macports on OS X
<jelmer> bogglin: hi
<jelmer> does "bzr revno bzr://bzr.savannah.gnu.org/emacs/trunk" work?
<bogglin> jelmer: thanks for your help - but I switched to git clone and that worked, so I guess this is a solved problem
<Lekensteyn> Is it possible to ignore certain files when checking out, or even checkout a single directory without having to download the whole history? http://stackoverflow.com/q/6870801/427545
<jelmer> Lekensteyn: it's not possible to check out a single directory or anything like that
<jelmer> Lekensteyn: that said, it seems like a bug that it needs that much traffic
<Lekensteyn> This is a related bug: https://bugs.launchpad.net/loggerhead/+bug/240580
<ubot5> Ubuntu bug 240580 in loggerhead "Ability to download a tarball for a revision" [Low,In progress]
<kgoetz> bzr does sometimes use bizzare amounts of bandwidth for stuff :/
<jelmer> 2.4 should be a lot better in that regard
<kgoetz> would hte server need to be 2.4 too?
<jelmer> I'm not sure
<kgoetz> ok. i'll see next time i do 'stuff' with savannah :)
<kgoetz> thanks
<jelmer> kgoetz: oh, that reminds me
<jelmer> I need to upload some bzr backports for squeeze
<idnar> why is bzr rebase telling me "No revisions to rebase"?
<idnar> I think this has something to do with having merged from the target branch, but I'm not sure what to do now
<jelmer> idnar: yeah, you can't rebase after merging because the changes are already present
<idnar> so... I guess I don't understand rebasing then
<jelmer> is there a particular reason you want to rebase?
<idnar> I decided to extract some changes from this branch into another one, and now I want to rebase on that, so I thought the conflicts might be easier to deal with if I rebased on trunk first
<idnar> anyway I guess I'll just do the other rebase directly
<idnar> (maybe I should always rebase feature branches instead of merging from trunk)
<jelmer> idnar: merging trunk should work better than rebase to prevent conflicts
<idnar> well, I managed to do this replay anyway, but I had some really weird conflicts
<idnar> I guess that's mostly due to hand-cherry-picking stuff into the other branch to separate it out
<Noldorin> hi jelmer
<Noldorin> jelmer, hopefully you're around now..
<Noldorin> jelmer, ?
<jelmer> Noldorin: hi
<jelmer> Noldorin: just popping in for a minute or so, will be out for most of the night
<jelmer> Noldorin: can you file a bug about the issue you saw? I can reproduce it here
<Noldorin_> jelmer, i already did :-P
<Noldorin_> jelmer, i linked you to it
<Noldorin_> jelmer, https://bugs.launchpad.net/bzr-git/+bug/818318
<ubot5> Ubuntu bug 818318 in Bazaar Git Plugin "Error using dpush" [Undecided,New]
#bzr 2011-07-31
<exarkun> Why does this checkout take so long?  http://buildbot.twistedmatrix.com/builders/hardy32-py2.5-select/builds/795/steps/bzr/logs/stdio
<lifeless> exarkun: this seems relevant Upgrade to svn 1.5 or higher for faster retrieving of revision properties.
<lifeless> (it has the word 'faster' in it
<lifeless> exarkun: also, what bzr version are you using?
<exarkun> bzr 2.3.4
<exarkun> It's sort of hard to get a newer version of svn on hardy, but I guess it's possible.  If someone can confirm that that will definitely speed it up, then it'll be worthwhile for me to pursue it.  I'd rather not chase any wild geese though.
<lifeless> I am not sure when the 'copy all tags' behaviour came in
<exarkun> It's not totally obvious to me that "faster retrieving of revision properties" translates to "don't issue a request to the svn server for every revision in the branch history"
<lifeless> It may be relevant.
<exarkun> Hmm
<exarkun> Okay, there's a svn ppa, so I guess I should just try that.
<jelmer> exarkun: with svn 1.5 it will indeed avoid a single request per revision
<jelmer> per revision in the repository, that is
<exarkun> jelmer: Thanks
<jelmer> exarkun: you'll also need a new python-subvertpy that was built against the newer libsvn
<exarkun> Hummmmmm
<exarkun> python-subvertpy is in the bzr ppa, right?  I'm using that already.
<exarkun> is that good enough?
<jelmer> exarkun: yes, but the python-subvertpy in the bzr ppa for hardy was built against the hardy libsvn
<jelmer> so even if you install a new libsvn, it'll only use the svn 1.4 API
<exarkun> :(
<exarkun> So I have to compile something.
<jelmer> an alternative would be to get libsvn backported into the bzr ppa for hardy
<jelmer> I'm not sure how hard/easy that would be
<exarkun> For now I think it will be easiest for me to switch back to svn in this configuration.
<jelmer> (fwiw, that checkout seems reasonably fast with svn 1.7, bzr 2.4, bzr-svn trunk)
<Noldorin> jelmer, hi. let me know when youre around :-)
<exarkun> How should I fast-export this project?  http://twistedmatrix.com/trac/browser/sandbox/exarkun/merit/
<exarkun> I did mange to get trunk using `bzr fast-export-from-svn Twisted.repo/ --trunk-path=/sandbox/exarkun/merit/trunk --branches-path=/sandbox/exarkun/merit/branches merit`, but how do I get the branches?
<Noldorin_> hey jelmer, you around yet?
<Anteru> Hi
<exarkun> How should I fast-export this project?  http://twistedmatrix.com/trac/browser/sandbox/exarkun/merit/
<exarkun> I did manage to get trunk using `bzr fast-export-from-svn Twisted.repo/ --trunk-path=/sandbox/exarkun/merit/trunk --branches-path=/sandbox/exarkun/merit/branches merit`, but how do I get the branches?
<Noldorin> hi jelmer
<glyph> exarkun: "When a shared repository is created or found at the destination, branches are created inside it. In the simple case of a single branch (refs/heads/master) inside the input file, the branch is project.bzr/trunk."
<glyph> http://doc.bazaar.canonical.com/plugins/en/fastimport-plugin.html
<glyph> exarkun: I have obviously never tried this, but that sounds to me like you should have gotten a '.fi' file at some point
<exarkun> too late
<exarkun> jonathanj pointed out that the feature is unimplemented
<exarkun> (but documented as though it is implemented)
<glyph> man I'm glad we have a policy of never writing documentation for Twisted
<glyph> that must be embarrassing
<exarkun> I'm just going to use bzr branch and fix it up
<glyph> exarkun: fix it up how?
<exarkun> rebasing maybe?  or maybe that wasn't actually necessary, but I did it already anyway.
<maxb> Generally I'd try to use bzr-svn whereever possible for bzr/svn conversions
<maxb> It seems to be far more advanced than the rather naive fast-exporter code
<jo-erlend> I have a project to translate some manuals and tutorials. I thought about using LibreOffice Writer for this, but would that work well with bzr? Would I be able to easily see diffs, etc?
<nbjoerg> trying to use the fast-import plugin and get
<nbjoerg> 23:03:28 WARNING: Cannot import multiple branches into a standalone branch
<nbjoerg> 23:03:28 WARNING: Not creating branches for these head revisions:
<nbjoerg> what is it trying to tell me?
<exarkun> maybe you need to make a shared repository
<exarkun> "When a shared repository is created or found at the destination, branches are created inside it. In the simple case of a single branch (refs/heads/master) inside the input file, the branch is project.bzr/trunk."
<nbjoerg> I've started from "bzr init"
<nbjoerg> all branches but trunk from the import seem to be on the list
<exarkun> nbjoerg: shared repository is created with 'bzr init-repo'
<exarkun> I don't really know though, just guessing
<exarkun> I just gave up on fast-import a while ago in favor of bzr-svn.
<lifeless> jo-erlend: you could write a bzr plugin to call out to the libre office diff utility
<lifeless> jo-erlend: the raw diffs themselves are binary - libre office writes gzip compressed xml
<jo-erlend> ah. Right. But there is a libreoffice diff utility? Where do I find it?
<lifeless> somewhere
<poolie> hi all
<maxb> Yay for nice empty PPA build queues :-)
<poolie> hi maxb
<maxb> Evening
#bzr 2012-07-23
<mgz> morning!
<vila> hi all !
<mgz> hey vila!
<mgz> how was the holiday?
<vila> great :)
<mgz> good :)
<seany> are there any resources on the kndx and knit file internals?
<seany> i have a revision that doesn't show in the series of revno's, and shows only in the log only by specifying -r revid:user@...
<seany> what's the likely scenario here?
<mgz> it's no longer present in the branch, but is still in the repo?
<mgz> eg, after pull --overwrite or uncommit.
<fullermd> Merged rev?
<mgz> I don't see any seperate docs on knits under doc/developers but you can always look at bzrlib/knit.py
<seany> thanx mgz and fullermd
<seany> i suspect that it is part of a merged rev
<mgz> ah yes, and just use log -n0 to see everything
<fullermd> (though the case could be made that if you're looking for knit docs, the right answer is probably more like "hey, y'know, the Flood has receeded..."  ;p)
<fullermd> If it's a merged rev, the log output probably has a dotted revno for it.
<seany> hmm that particular revision doesn't show even under -n0
<seany> let me try again
<fullermd> You probably need --show-ids to make it show the revids in the output, if you were looking for it that way.
<fullermd> But if it's truly not there, then it's not in the branch history.
<seany> yeah i'm using the --show-ids flag..
<fullermd> You may be able to craft up an invocation of missing to tell you more too.  But I wouldn't be confident in saying how without experimenting, which kinda reduces the usefulness...
<seany> so the only likely scenario is an uncommit?
<seany> thought that'd get rid of the revision from the repo as well..
<mgz> nope, deliberately leaves it in, so you can undo
<seany> ah ok
<fullermd> Oh, there are a handful of ways.  An uncommit.  A --overwrite of some sort.  Repo shared with another branch.
<mgz> anything else that changes the branch head also can do it
<fullermd> Pulled in via a merge that was reverted instead of committed.
<fullermd> Probably a bunch of other ways that don't immediately come to mind.
<mgz> one thing you can do is branch -rrevid:... . /somewhere_else which will give you a branch with just the history of that rev
<mgz> some of the qbzr tools are also useful for visualising this stuff.
<seany> Hmm yeah I'll give that a shot now and let you know how I go..
<seany> can a shared repository be a repository tree at the same time?
<seany> i'm looking at one of our legacy codebases, and 'bzr info' returns:
<seany> Repository tree (format: unnamed)
<seany> Location: shared repository: .
<jelmer> seany: in theory, I think so
<mgz> you can do some weird things, some of which aren't useful
<mgz> I just make this trying to reproduce that:
<mgz> Repository checkout (format: 2a)
<mgz> Location:
<mgz>   repository checkout root: r
<mgz>         checkout of branch: b
<mgz>          shared repository: r
 * fullermd hates those rollup names...
<seany> let me try that example
<seany> right so in a nutshell, do a checkout into a shared repo
<seany> is that right?
<mgz> right, that's what I did there. it's not a sensible thing to do, because it mixes tree contents in with branches
<seany> hmm in the example i mentioned earlier, bzr info recognizes a repository tree
<seany> but i guess it could've come from an earlier tree format
<seany> format: unnamed looks suspicious
<mgz> it's less suspicious than it looks
<seany> what's an unnamed format?
<mgz> it's anything that's not an exact mix of repo/branch/tree formats that happen to have a name
<seany> oh right
<seany> so precisely what we have in your example
<seany> well we could've embellished and complicated that example a bit
<mgz> right, and remember info -v gives you more details
<seany> yep
<mgz> it's pretty easy to make something like you have there: <http://pastebin.ubuntu.com/1106220/>
<mgz> right fix is probably `bzr branch r r/b && bzr rmbranch r`
<mgz> plus force, then use pull --remember to fix the parent
<seany> hmm not sure why anyone would not make a subdirectory inside the shared repo for a branch..
<mgz> likely just a mistake
<seany> the legacy codebase looks really messed up
<seany> anyways if you guys get a chance to come to sydney then call me up for lunch or something : >
<mgz> we used to be more antipodean than we are presently :)
<seany> as in an expat aussie?
<mgz> at one point half the people who worked on bazaar were in aus or nz
<fullermd> I tried being antipodean once, but I pulled my shoulder.
<seany> haha i see ;)
<mgz> you're still far from home fullermd :)
<abentley> mgz: What sort of extra documentation do you suggest?
<mgz> there's a shelving_changes.txt under doc/en/user-guide/ though doesn't seem to be a switch equivalent
<mgz> a file with a couple of short examples like that which would appear on website and get indexed would be helpful I think
<abentley> mgz: This doesn't have an interactive mode, so there's not a lot of examples to give.
<mgz> abentley: basically just wants your test_store_and_restore_uncommitted blackbox test in example style with some explaining I think
<abentley> mgz: okay.
<mgz> could be a seperate mp if you want to land that one first
<jelmer> urgh, one of my emails just escaped from a mail queue somewhere
<mgz> as in you sent something that should have been deleted?
<mgz> or just a very delayed email?
<jelmer> *very* delayed
<jelmer> from 15 june :)
<mgz> sometimes the epostman takes the long way round :)
<jelmer> one of our local mailmen was fired a while ago for hamstering mail
<james_w> yeah, sorry jelmer, it was held in moderation
<jelmer> james_w: ah :)
<mgz> blame james!
<james_w> hopefully you won't fire me?
<mgz> jelmer: well, sometimes breeding season comes and they just have to make a nest
<mgz> without a good bed of letters there wouldn't be lots of new little posties
<jelmer> I would expect mwhudson to be the one keeping emails behind in that case ;)
<bitglue> so let's say i had a branch, and I merged that branch into trunk. Then I decided it was a bad idea, and in trunk, I reverted the commit where I did the merge. Now I fixed the problem in the branch. How can I reconcile the two branches?
<james_w> bitglue, merge trunk back in to the other branch
<james_w> that will likely cause some conflicts, but hopefully they will be easy to resolve.
<james_w> if trunk only did the revert in the meantime then a "bzr revert ." might suffice for that
<james_w> then commit and merge the branch to trunk again
<bitglue> what if trunk did more than just the revert in the meantime?
<james_w> your conflict fixing will be more involved
<james_w> but the process is the same
<james_w> a "bzr revert ." in that case would revert the other changes trunk made, which you presumably want to keep
<bitglue> there are no conflicts, but merging production also merges the revert, thus discarding all the changes in my branch.
<james_w> right, so you could fix that up during the merge
<bitglue> ok, can you elaborate on "fix up"?
<james_w> or replay the commits on the branch back on top
<bitglue> i mean, besides going through all the changes line-by-line and essentially re-writing my branch.
<james_w> fix up = make the branch contain all of the changes again
<james_w> yeah
<james_w> if you lost everything merging back then replaying the commits might be easiest
<james_w> jelmer, mgz: am I missing an easier way to do this?
<abentley> bitglue: What I do is merge trunk upto the revision before the trunk reverted the branch.  Say trunk's revert is 10.  I'd merge -r 9 and commit normally.
<abentley> bitglue: Then merge -r 10, revert ., commit.
<bitglue> won't that include the revision in trunk where i merged the branch? So, when I later re-merge my branch, it won't include changes I made before the reverted merge?
<abentley> bitglue: It will exclude the revision in trunk where you merged the branch, because that revision is the last common revision, so it is selected as the BASE.
<abentley> bitglue: Sorry, that's wrong.
<abentley> bitglue: It will include that revision.  But I don't understand what you think will happen because of that.
<bitglue> well, say in trunk, r10 is the revert, but r9 is the merge
<bitglue> now, if i merge trunk's r9 into the branch, and I do what you said, keeping the merge marker but not the changes for r10, then my branch has the right code in it. But, when I later merge this into production again, I'm afraid it won't include the changes I originally made, because r10 will be the LCR.
<bitglue> I think the significant thing here is that I will have merged r9 from trunk into the branch, so now as far as bzr is concerned, everything from before the merge-then-revert is reconciled between the branches (but it's not, because it was reverted)
<abentley> bitglue: It will include your changes, because the revision that could have removed them (r10) is something you've already merged.
<abentley> bitglue: That means your changes take precedence over the changes r10 made.
<bitglue> i don't understand how that works, but i'll try it
<abentley> bitglue: What happens is r10 becomes the BASE revision in your final merge.
<bitglue> so after i merge, revert, commit the revision from trunk that reverted the merge of the branch into trunk, i can merge the head of trunk, to also get other things that changed in trunk, right?
<abentley> bitglue: Right.
<abentley> bitglue: but you don't have to.  Your choice.
<bitglue> understood. Well, it seems to work. A bit odd, but I can't argue with the result.
<abentley> bitglue: the first merge ensures that you've got everything merged except the revert, so that in your next merge, it's safe to completely revert.
<abentley> bitglue: The complete revert makes it as if you make your changes from scratch, based on -r10.
<bitglue> i guess that makes sense
<bitglue> the mental trap seems to be in merging r10, but committing something other than r10. ie, committing nothing.
<bitglue> it's like the branch says, "yeah, I know about r10. Except it doesn't exist."
<bitglue> which i guess...is really what i wanted all along.
<abentley> bitglue: I think of it as saying "I'm overriding what the results of this merge should be.  My changes should survive this merge".
<abentley> bitglue: It's not really saying r10 doesn't exist.
<abentley> mgz: http://pastebin.ubuntu.com/1106630/
<abentley> mgz: What is it about the case where both branches have uncommitted changes that you find interesting?
<abentley> mgz: Is it the fact that it errors?  Because that happens regardless of whether the target branch has uncommitted changes.
<mgz> abentley: I think it's interesting because it's what I'd end up with if shelves were tied to branches
<mgz> I'd be switching from feature_a to feature_b both of which could have pending uncommitted changes
<mgz> that doc page looks really good.
<mgz> nit, paragraph starting 'switch --store', I'd put a 'Using ' in front of.
<mgz> and maybe wants some ``markup`` round inline commands?
<abentley> mgz: It's pretty rare that feature_a will already be storing uncommitted changes when you switch to feature b, but if you do, it doesn't matter whether feature_b has uncommitted changes.
<mgz> nothing else jumps out.
<mgz> abentley: so, what I'd expect is to start with a branch with one set of changes, then switch, and have a different set of changes, which as I understand it will work find if --store is passed and the switched to branch has 'stored-transform'
<abentley> mgz: You're sure you mean "branch with one set of changes", not "working tree with one set of changes"?
<mgz> well, a store is attached to the branch, rather than the tree
<mgz> but yeah, the tree gives one diff, you switch, and get a different diff
<abentley> mgz: But why would the changes be stored in the first branch already?  That happens as part of the switch.
<mgz> right, that's not really the common case, the current branch would be creating its 'stored-transform' and the target branch would be applying its one
<abentley> mgz: Right.
<abentley> mgz: So if I tweak test_store_and_restore_uncommitted so that we have uncommitted changes when we switch to "orig", that tests what you wanted to test?
<mgz> I'd add it as a new varient and probably switch back again but yup
<abentley> mgz: I wouldn't, because then it's trying to unit tests instead of integration tests.
<mgz> blackbox tests end up being a bit of both
<mgz> you've already got good coverage for the lower level bits with more unit-y tests
<abentley> mgz: What will having two variants tell us that having one variant does not?
<mgz> probably nothing, my thinking is just that a regression with say, ordering of operations, might make one tes fail and not the other
<mgz> your pick
<mgz> the other potentially interesting integration test case is switch --store -b fresh with changes in the tree
<mgz> do what ever feels right for you.
<ccxCZ> is there tool that would open conflicts in vimdiff, tab per conflict, similarly to diffuse?
<glyph> Hello bizarros
<glyph> I have hit the dreaded 'BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys' yet again
<glyph> and I am looking for a way to save my ~300-revision branch without writing a giant shell script
<glyph> is there a way to do rewrite which works exclusively on patches and won't try to do common-ancestor reconciliation or whatever the heck triggers that error?
<wgz> is this involving bzr-svn again?
<glyph> wgz: Yes.  We're not going to switch off SVN until we've had at least a month with bzr not emitting a catastrophic, data-losing traceback ;-)
<glyph> I am currently trying really hard to avoid coming to the conclusion that this isn't worth the trouble and we should just switch to git because git-svn doesn't seem to have these issues.
<glyph> So, here's a question.  It looks like I am going to have to write the shell script, but I'd like to automate this workaround since it seems like I'm going to have to do it a couple dozen more times before all the repos which are infected with this bug have been cleaned up.
<glyph> In order to automate it, the question "what is the most recent revision which has an svn revision associated with it in this branch" is interesting.
<jelmer> hi glyph
<jelmer> glyph: "bzr log" and grepping for "svn revno:" should tell you, or alternatively "bzr log --show-ids" and grepping for "revision-id: svn-"
<glyph> hi jelmer
<glyph> sorry to always be such a downer :(
<glyph> jelmer: I know how to look for it manually, I was just hoping there would be a convenient command, or maybe a revisionspec, that would give it to me
<glyph> like, svn:-1
<glyph> show-ids might get me close enough though
<jelmer> glyph: there is no revisionspec for anything like that
<jelmer> I'm afraid scanning is the only thing you can do (either from the bzr python API or in a script that parses the "bzr log" output)
<glyph> I am probably just going to write something in python with plumbum, because I already know what bzr's output looks like but I have no idea what its API looks like :)
<glyph> Looks like --xml doesn't work with --show-ids or -p?  That's unfortunate.
#bzr 2012-07-24
<lifeless> I think --xml is in a plugin
<lifeless> written for IDE integtation
<mnn> hi everyone... has been there any progress on this?
<mnn> https://blueprints.launchpad.net/bzr/+spec/tls-and-ssl-support
<Noldorin> mnn: yeah, sounds highly advisable. the python 2.7 argument doesn't quite work for me...
<Noldorin> it can always be conditional functionality
<Noldorin> on the build or version of python installed
<mnn> and what about gnutls along with python-gnutls?
<mnn> that way python 2.7 won't be required
<Noldorin> py2.7 seems like the more elegant way
<Noldorin> but yeah, that's feasilbe
<Noldorin> especially as a plugin
<Noldorin> mnn: there way forward with this, as with most experimental/new technology in bzr, is a demonstration plugin
<Noldorin> as proof-of-concept at the very least
<mnn> Noldorin: I have little knowledge about ftp/ssl but I could try it... anyway I have more pressing concern:
<mnn> https://bugs.launchpad.net/bzr/+bug/1027529
<ubot5> Ubuntu bug 1027529 in Bazaar "Cannot push/operate on SFTP; no useful error message" [Undecided,New]
<mnn> seems like old issues with SFTP transport are crawling back:
<mnn> https://bugs.launchpad.net/bzr/+bug/681047
<ubot5> Ubuntu bug 681047 in Bazaar "Random failures on SFTPTransport tests on windows" [Low,Fix released]
<mgrandi> i haven't had any problems with sftp on windows or mac...
<mnn> however, I believe the sftp server I'm using is not hosted on windows
<mnn> most likely linux
<seany> is it possible to `bzr log` all revisions that aren't part of the branch anymore?
<seany> i.e. do not have revno anymore
<lifeless> seany: bzr heads
<ls3> hello. Is it safe to remove some older /tmp/bzr-index-* files ?  (2 wks+)
<ls3> I'm trying to read about what they are but all I've gained is they are used for caching
<ls3> i just have 440 3M files clogging up /tmp ..
<spiv> (in case ls3 comes back): anything bzr leaves in /tmp is safe to remove, and probably also a bug (in the bzr-index plugin maybe?)
<seany> lifeless: thanks!
<jelmer> moin
<mgz> morning
<bzrnewb> hi guys
<bzrnewb> Anyone around?
<jelmer> hi bzrnewb
<bzrnewb> hey jelmer
<bzrnewb> are you well acquainted with bzr hooks by any chance?
<bzrnewb> i require very specific assistance and google seems to be failing me today
<jelmer> bzrnewb: a bit
<jelmer> bzrnewb: please just ask your question - if there's somebody around who can help they'll hopefully speak up
<bzrnewb> sweet thanks
<bzrnewb> well
<bzrnewb> is it possible when pushing to run a post_push hook only if there are changes in a specified directory
<bzrnewb> ?
<jelmer> bzrnewb: inside of your hook you could check if there were any changes?
<bzrnewb> ah that's not a bad idea.
<jelmer> bzrnewb: the hook params should contain the old and the new revid
<jelmer> so it should be a matter of just checking that those are different
<bzrnewb> Would you do it file by file?
<jelmer> bzrnewb: what do you mean exactly by "changes in a specified directory" ?
<bzrnewb> excuse my ignorance here, I've only just started setting up a continuous integration environment at my new office
<jelmer> bzrnewb: committed changes that were pushed that weren't present remotely before the push?
<bzrnewb> yes
<bzrnewb> but only for one of the directories in the branch
<jelmer> bzrnewb: you could probably call Repository.revision_tree() for old-revid and new-revid, and then use new_tree.changes_from(old_tree) to get the list of files that have somehow changed
<bzrnewb> great stuff
<bzrnewb> I'll go investigate
<bzrnewb> Thanks jelmer
#bzr 2012-07-25
<maxb> vila: OOI, was it intentional to omit the leading 'bzr-' from the tag name for 2.6b2?
<seany> is it possible to show all revisions that used once to belong to a branch? bzr heads doesn't show it for some reason..
<spiv> seany: what do you mean by "used once to belong to a branch", exactly?  How is it different to the output of "bzr log"?
<seany> spiv: for example if the revision is a dead head, it will not show in the bzr log
<seany> (correct me if i'm wrong here :> )
<spiv> That's true.  But then you can find dead heads with 'bzr heads --dead-only'.
<spiv> There's no reliable record of which branch that dead head was originally created on, though.
<seany> spiv: thanks -- another confusing thing for me has been with shared repo's.. it seems that I can pull out a rev by specifying a revid even if that rev doesn't belong to that branch..
<bob2> sure, the repo is a big bag of revisions, a "branch" is just a pointer at a particular rev
<seany> bob2: so is there no easy way of figuring out if a given revid belongs to a branch?
<seany> i guess i could grep through..
<bob2> that's a different question to what you asked earlier
<bob2> bzr log somerev..somebranch I guess
<seany> ah yes that'll do the job, thanks
<seany> essentially grabs the subsequence from somerev which is ill-defined if it didn't belong to the branch in the first place
<bob2> s/illdefined/defined as empty/ :)
<seany> well it errors :P doesn't just return an empty log
<seany> bob2: is there a way of deducing which revision 'killed' a dead revision?
<bob2> don't even know what that means
<seany> well say if it was overwritten
<bob2> that's not how things work
<seany> or time of uncommit?
<spiv> seany: bzr doesn't record that data
<seany> thanks
<spiv> seany: when you uncommit, it just updates the branch to say "the latest revision of this branch is now X"
<spiv> It doesn't also keep a history-of-the-history
<seany> ah alright, just thought there could be some kind of meta history
<bob2> but waht if it was altered
<spiv> It would certainly be useful sometimes, but also confusing, especially if people start demanding features to manipulate and edit the meta-history
<bob2> you need infinite-meta-history
<spiv> You'd then need a meta-meta-history :)
<spiv> You can sometimes reconstruct that by hand by looking at your ~/.bzr.log
<seany> ah yes true
<seany> a particular dead revision does not come up when i run bzr heads --dead-only
<seany> (unless i'm not getting the concept of dead heads properly..)
<bob2> sounds like it's not dead or not present then
<seany> a dead head is a revision that's childless and not part of any branches?
<bob2> yes
<maxb> jelmer: Hi, I've pushed a minor new upstream merge and a fix to a malformed patch to pkg-bazaar/bzr/2.6/; just pinging you as a reminder to pull before working on it next
<jelmer> maxb: please just use ~bzr for versions - if we use ~+ now, I don't think we can't switch back to ~bzr, safe specific tricks with ~
<maxb> jelmer: 2.6.0~+beta2+bzr6666 ? :-)
<jelmer> maxb: I would rather switch it around - 2.6.0~beta2+bzr6666
<jelmer> euhm
<jelmer> maxb: I would rather switch it around - 2.6.0~bzr6666+beta2
<maxb> Ah, my implication was different
<maxb> I was suggesting that a future post-beta2 pre-beta2 snapshot would be represented as 2.6.0~beta2+bzrXXXX
<maxb> or rather 2.6.0~+beta2+bzrXXXX
<jelmer> in short, having two different versioning schemes is a pain.. I would rather stick to the one that always works
<maxb> Can do, though it's slightly less informative
<maxb> I guess it mostly depends on how much you expect to be uploading non-beta-release snapshots to unstable for the rest of the 2.6.0 cycle
<jelmer> maxb: it's been fairly common so far
<jelmer> maxb: the upstream-2.6.0~+beta2 tag seems to be missing, btw
<jml> how can I tell which release a particular revno of bzr is in?
<mgz> jml: compare <http://packages.ubuntu.com/search?keywords=bzr&searchon=names&suite=all> with `bzr tags lp:bzr`?
<jml> mgz: thanks.
<jelmer> vila, mgz: I've put up a mp for the missing chk root reference issue
<jelmer> there is 'bzr reconcile --canonicalize-chks' which fixes it, courtesy of spiv
<jelmer> I had completely forgotten about that
<jelmer> unfortunately it seems dead slow on the gcc repo
<vila> approved, mention it in the bug report so they can try it for themselves
<vila> jelmer: dead slow as in ? hours ? days ?
<jelmer> vila: it's taken 2 hours to process the first 55 out of 115544 inventories
<vila> :-/
<mgz> heh
<fullermd> Well, if you go by the book, hours can seem like days.
<jelmer> fullermd: what is this "the book
<jelmer> " you're talking about?
<fullermd> Mostly a collection of numbskull ideas that worked.
<jelmer> fullermd: ISBN?
<fullermd> 0-671-21833-6
<jelmer> vila: ... and thakns for the review
<vila> don't mention it, I wonder how many bugs / import failures can be addressed this way...
<jelmer> vila: depends on how much patience people have :)
<jelmer> I don't think it will fix any import failures, just people having problems with merge
<vila> yeah couldn't find import failures, dunno why I thought this was triggered there... may be they occurred long ago and have been fixed since then
<vila> or it's just my memory playing tricks ;)
<jml> vila: hello
<jml> vila: welcome back
<vila> thanks
<jml> vila: fwiw, we had issues with our udd & config expansion with an old bzr. The 'if bzrlib.version < (2,6)' was being evaluated as false for trunk r6468 (2, 6, 0, 'dev', 1), which meant we weren't getting config expansion...
<jml> vila: I'm pretty sure we've resolved it by switching to a more recent bzr though
 * jml has very poor visibility into our production system
<jml> vila: so, no action required from you, but I thought you might be interested.
<vila> 8-/
<vila> jml: the relevant revno is 6488 if you used an earlier trunk... you were doomed
<jml> vila: yeah, thanks. I figured that out eventually :)
<vila> revno 6468 was too old
<jml> vila: on the plus side, bzr made it really easy to find the relevant changes :)
<vila> jml: there is a test that should have failed for udd... (two even)
<jml> vila: interesting. I don't know exactly how running tests integrates with our deployment process. udd is somewhat non-standard.
<vila> yeah, and it's not part of deployment to run tests, just mentioning, no worries
<vila> or more to the point, it would be nice that running tests becomes part of deployment :)
<vila> even if only a subset of the test suite or a dedicated one is needed
<jelmer> vila: yeah, this isn't going to work.. still not at rev 100 yet
<mnn> hi, I've found the culprit with the sftp: https://bugs.launchpad.net/bzr/+bug/1027529
<ubot5> Ubuntu bug 1027529 in Bazaar "Cannot push/operate on SFTP; no useful error message" [Undecided,Invalid]
<mnn> it could be possible, if server does not support moving files to just copy file and delete original, right?
<vila> mnn: it would be nice to emit some more meaningful message, the bug is pretty terse about what additional info could be obtained from the server which would allow a fix that will relay this additional info
<vila> mnn: copy + delete is not on the agenda until we get a better understanding of what is going on. Keep in mind that the rename is probably already part of a "create tmp file/rename over existing file" dance
<mnn> yes, I've already crawled through the bazaar's code and paramiko's too
<mnn> so I've pinpointed location, where the exception is thrown without any meaningful information
<vila> great !
<mnn> bzrlib/transport/sftp.py - line _after_ this one:
<mnn> if e.args == ('Operation unsupported',):
<mnn> so basically more_info could be passed into TransportNotPossible() right?
 * vila checks
<vila> hmm, yeah, you can use the orig_error parameter probably
<vila> mnn: sry, family time here, I may be back later, if not, comment on the bug
<vila> mnn: alternatively, a specific exception (class in errors.py) can be created if needed
<mnn> true
<mnn> vila: so, I was thinking something like TransportOperationNotSupported exception
<mnn> with argument operation
<mnn> however operations within sftp.py itself, call _translate_io_exception() and they only provide more_info... not name of the operation itself
<vila> mnn: yup, you probably want to catch the exception at a higher level (depending on how many higher level calls fail, but so far, you found one right ?)
<mnn> well in theory any operation could fail, but only handful wouldn't be supported
<maxb> Hmm, is it known that lp:bzrtools is currently incompatible with bzr.dev?
<maxb> AttributeError: 'CHKInventoryRepository' object has no attribute 'get_ancestry'
<maxb> jelmer: Hi. Your changes to pkg-bazaar/bzr/2.6/ include a bzr-builddeb malfunction reverting the branch content back to 2.6b2 from the snapshot you imported. Do you mind if I uncommit that and replay the debian/changelog changes on top of the clean snapshot merge?
<jelmer> maxb: go ahead
<maxb> thanks
<maxb> pushed
<mnn> vila: something like this?
<mnn> http://pastebin.com/RV70HTC9
<thumper> hi folks
<thumper> before I get into doing this complicated cherry pick branch
<thumper> I wanted to check that bzr is going to do what I think it is going to do
<thumper> if I do a cherry pick merge like... bzr merge ../trunk -r1234..1235
<thumper> it still uses the file ids?
<thumper> just after release, we had a massive code reorg
<thumper> and I'm hoping that I'm not going to have to do this manually
#bzr 2012-07-26
<spiv> jelmer: wow, that's an impressively slow reconcile :)
<spiv> jelmer: possibly the gcc inventories are so large the default lru cache sizes are ineffective?
<lifeless> thumper: it does
<thumper> lifeless: yay
<mgz> morning all!
<vila> morning mgz
<mgz> how are you today vila?
<vila> hot :)
<mgz> heh, reverse here, is overcast today
<vila> 33C as yesterday, yummy
<fullermd> Shoot, that's all?
<mgz> I'm not going to feel sympathy for the heat you have to endure fullermd
<fullermd> Nobody ever has sympathy for me  :(
<mgz> it's because everyone's too busy admiring you? :)
<fullermd> I s'pose it IS time consuming, all that time people spend thinking of nice things to do for me.
<vila> well, my favorite Stone's song is Sympathy For ... wossname
<fullermd> What, more than Gimme Shelter?
<vila> yup
<BY0LOG1C> hello folks, mind if a cvs n00bie ask for support in here?
<BY0LOG1C> ill make it short. im an indie developer for a small studio and i had the *poor?* idea to put our whole 50gb project under version control. commiting the whole folder would cause OOM so i broke it down into smaller commit.
<BY0LOG1C> large binary files would still crash so i had them ignored. all fine, except the 10 commit triggers a repack - which crash, no matter what i do
<BY0LOG1C> i tried the bzr repack -nosmart+[url] found on the forum but that also crash around file 50k/80k on a win7 machine. is there anything i can do to help my cause?
<mgz> why version the large binary files?
<mgz> this is something people (eg games developers) have asked for, but none of the dvcs systems are really designed to handle that sensibly
<BY0LOG1C> i am fine with that issue, i had the large binary ignored. the problem is now that bzr will OOM on any commit/repack
<mgz> if it's not human-editable text, there's not much point putting it in version control as opposed to using some other archive+update method
<mgz> BY0LOG1C: probably you committed at some point, then removed it? instead, you want to not add it it the first place
<fullermd> I have an archive+update mechanism; it's called "version control"  ;p
<mgz> for videos and photos from your camera fullermd?
<mgz> most people use something better suited.
<BY0LOG1C> thanks for the help mgz. yes ive had added the whole directory and tried commiting that - which failed on the ~1gb video files. so ive went to the bazaar explorer and had the file removed
<mgz> games development is interesting, because they generally have two different groups that still want to combined form to be synced in some manner
<fullermd> Heavens no.  I don't want any paper trail for my videos and photos...   safer that way.
<fullermd> I mean...   what videos and photos?  I don't know of any videos and photos.
<mgz> all those risquÃ© self-portraits fullermd...
<fullermd> Oh, you're supposed to do them yourSELF?
<fullermd> Well, shucks.  I could have saved all those subpoenas...
<mgz> BY0LOG1C: I'd go from the start again, clearly you had at least one commit that included big things
<BY0LOG1C> so, i should delete my .bzr folder and start over and be more careful what i commit? ok ill try that, but it does seems kinda fragile, isnt it?
<mgz> there's a thing in 2.5 that warns you when adding a file larger than 10MB or somehing
<BY0LOG1C> i'd like to keep my whole(as mush as possible) my full game project under version control - is that impossible, am i required to manually browse each folder and add relevant files myself?
<BY0LOG1C> im using 2.5.1(?) and i havent seen warning or anything
<mgz> I'd have an assets folder for all art/music etc that is stored and updated elsewhere but the sourcecode build process knows how to fetch and update
<mgz> if you've currently got stuff scattered around all over the place that's a little harder to manage
<BY0LOG1C> yeah i understand that starting a project with cvs in mind would've helped us greatly
<mgz> so then you just ignore ./assets, and make creates and populates it from a well known location
<BY0LOG1C> right, that should work
<mgz> and ftp server that gets backed up regularly or something, and you give upload rights to your artists
<BY0LOG1C> so i really should version my assets myself - in a totally separate manner than code files
<mgz> probably don't need to version, just keep a few checkpoints to prevent one person accidentially screwing stuff up too much
<BY0LOG1C> ok, so an example pipeline could be to commit changes, zip up an asset folder and mark it with the revision id, i guess that could keep things clean and simple
<BY0LOG1C> well, thanks for the help. i guess this project's kind of ruined but the next ones should hopefully work great
<mgz> well, you can filter out the bad bits of history with fast-export/fast-import but that's probably not gaining you much over just versioning from now minus the big files
<BY0LOG1C> yeah, well, after hearing your advices. i guess my idea of versioning the 'project' and all its pre-compiled stuff was wrong. my idea was that one could switch between versions with only a few clicks within the bazaar contextmenu
<BY0LOG1C> i really should version only the source code directory and then have the engine recompile that when required
<mgz> that's something that games dev do want, it's just not well supported by anything at the moment, given the rather different content storage requirements
<BY0LOG1C> im amazed at the quantity of commands and possibilities that cvs offers, versioning really is an art
<mgz> btw, it's vcs, or dvcs (for bzr, hg git), cvs is a specific vcs without the d
<fullermd> Well, CVS is...  _like_ art...
<BY0LOG1C> oh ok,ty
<fullermd> In the "fingerpainting with your own intestines" sense, anyway.
<BY0LOG1C> lol
<BY0LOG1C> how can i un-version a project? will just deleting the .bzr folder do the trick?
<BY0LOG1C> it looks like some connection remains
<BY0LOG1C> nvm, looks like that dit it, my bad -_-
<james_w> vila, hi
<james_w> vila, you think there should be lock_for_script(name) that does the locking, and prints a useful error message, and that is used by all scripts?
<vila> james_w: yes
<james_w> sounds good
<james_w> vila, I'm not sure I understand your point about the makedirs() though?
<vila> I think we're close to that already and I really realized it when seeing your proposal
<vila> so,
<vila> ensure_dir makes sure the dirs are created so, only doing it in the tests means it will fail on a new install (at the worst possible time ;)
<vila> that is: we don't have (yet) a script to ensure all the needed dirs are created
<vila> your patch is fine as is for running the tests, for jubany and probably for your other udd instance but if I create a local one for tests purposes, I'll have to create the lock dirs manually
<james_w> yes, it will fail on install
<james_w> but it will also fail if e.g. the config options aren't being expanded and it's trying to lock ${pi.locks_dir}/whatever, which is obviously not what is wanted
<james_w> it's a case of failing noisily so the admin can be sure it is doing what they want
<vila> <shudder> Ha right
<vila> hmm, but that expansion issue has been solved right ?
<james_w> I think that's the right way to go, so I'd like to look for ways to go that way and mitigate the fallout
<james_w> yeah, we had to upgrade bzr
<james_w> the version check didn't match exactly when the API changed
<vila> well, ideally the way to go is to have a postinstall script
<vila> yeah, my bad, I was hoping for people using trunk to upgrade often
<vila> the bug was there for only a couple of revisions
<vila> well, a mormon couple :)
<james_w> vila, so are you happy if I land with the lock_for_script() change?
<james_w> and we can add a script to create dirs for new installs or something?
<vila> hehe, if the script appears soon enough *then* I'll be happy :) On the other hand, if you start with just creating the obvious dirs, it shouldn't be hard to write
<vila> hmm,
<vila> in fact, the script is what you started to add in the test setup
<vila> no more no less
<james_w> yeah
<james_w> have a function that creates needed dirs
<james_w> run it in test setup
<james_w> have a script that calls it too
<vila> perfect
<james_w> then it can't get out of sync
<vila> and is tested by design :)
<james_w> vila, I'll make those changes, thanks
<vila> thanks to you
<vila> oh, since you're there, I had to struggle a bit to run the tests for this branch (install postgres, find postgresfixtures (damn, not packaged ?), install python-fixtures as recommended in 'requirements.txt'), but succeeded then
<james_w> should I add a Makefile?
<vila> I was wondering if we should add them as dependencies for udd if only to be able to run the tests after installation
<vila> hmm, not sure I would have thought of the Makefile (I did find requirements.txt quickly)
<james_w> on other projects we have "make bootstrap" create a virtualenv with everything you need to run tests
<vila> I mention that because I mentioned to jml  that running the test suite would have caught the expansion bug
<vila> never used virtualenv :)
<vila> I do chroot, lxc, kvm, vbox and so on but no venv yet :)
<jml> james_w: oh right I forgot to chase that up ... did we actually end up upgrading bzr? no one got back to me from ops
<james_w> jml, oh, I was assuming it was done
<jml> james_w: yeah. me too :\
<vila> james_w: so, summary, no Makefile needed, for now it's up to the dev to setup his env properly, I think I'll add them as dependencies to bzr-package-importer as some point
<vila> s/as some/at some/
<james_w> ok
<vila> and if you add the postinstall script, it will also find its place there ;)
<vila> james_w: oh, and jokes aside, I *did* at various points in the past installed a local udd in vbox then kvm then lxc then chroot ;)
<james_w> vila, you ran a chroot in an lxc in a kvm in virtualbox?!
<vila> lol
<vila> on my BeBox !
<james_w> heh
<BY0LOG1C> ive got some more beginners questions if you guys dont mind.
<BY0LOG1C> what exactly is the purpose of repacking? is it only to save space or is there a speed benefit?
<fullermd> I imagine there's a moderate theoretically speed benefit.  Larger practical one.
<BY0LOG1C> also, is there a way to ask bazaar to not repack automatically?
<BY0LOG1C> oh ok, thanks. so repacking is primarily to save space?
<fullermd> Not really.  You could probably monkey around via a plugin and shortcut the autopacks away.
<fullermd> No, and yes.  x-ref "larger practical".
<BY0LOG1C> hmm, i guess i can handle the auto-repack
<BY0LOG1C> thanks. i had been committing a 50gb project into smaller pieces and the 10th commit triggered auto-repack, which took forever when i was one commit away from completion
<fullermd> There are basically 2 times that the auto-repack will hurt you a lot.
<BY0LOG1C> not a real issue, but it got me wondering
<fullermd> (1) you're doing a lot of dumb server work, in which case DDTT applies
<fullermd> (2) you have ginormous mounds of data, in which case you're probably going to be in trouble from other things anyway.
<BY0LOG1C> yeah i was working locally but was actually commiting the full game project. i talked a little in here today(you were there) and i learned that wasnt a good idea in any case
<BY0LOG1C> still, im trying to figure the whole versioning idea
<BY0LOG1C> is there a platform similar to launchpad that allows non-public shared project for free?
<ccxCZ> I believe bitbucket allows a few of private repos for free
<ccxCZ> hg or git only though
<ccxCZ> also, launchpad is opensource, you can run it on your machine :]
<BY0LOG1C> you mean i'd host my own repo?
<ccxCZ> single repo is trivial, via ssh or something
<ccxCZ> but you can run the whole suite with project management, teams, bug tracking etc..
<BY0LOG1C> hm, ill have to check it out, could be interesting
<ccxCZ> or you could just slap on bzr plugin on trac or redmine
<BY0LOG1C> though i guess it'll be complicated enough that i'll mess up something. i hoped for an external solution heh
<BY0LOG1C> im sorry if those are dumb questions. is bazaar somehow based on svn or are they completelty different projet?
<ccxCZ> private hosting solutions are out there, you just need to pay for them :]
<ccxCZ> completely unrelated
<ccxCZ> similar goal, different approach, completely different implementation
<BY0LOG1C> right. im kind of just checking out vcs. im just an indy game developer with a little codebase i can easily handle
<BY0LOG1C> but i share code with a few team, i thought it could be fun to see how the big guys do stuff. i guess i can just drop it on launchpad and nobody will bother with it
<BY0LOG1C> thanks a lot for the suggestions though.im just not too sure im able to apply them :)
<ccxCZ> you don't need to use launchpad for just one project
<ccxCZ> VPSes are pretty cheap if you need to share some space with others and you don't already have always-on accessible computer
<BY0LOG1C> is that something i could setup on my hosted domain?
<lamont> bzr st
<lamont> bzr: ERROR: exceptions.AssertionError: get_next() called when there are no chars left
<lamont> do we know about that one?
<lamont> 2.3.4-0ubuntu1
<lifeless> lamont: there should be more in ~/.bzr.log, but my WAG is you have a corrupt status file.
<ccxCZ> BY0LOG1C: depends on what hosted domain actually means. for smart-server to run (which is quite beneficial) you basically need to be able to run custom apps, which is usually known as "shell account"
<ccxCZ> VPS is more than that, you get control over whole (virtual) server, with user accounts etc.
<ccxCZ> bzr can run with just file access, as most webhosts provide, but it would be suboptimal
<BY0LOG1C> oh i see. well i believe ive got a shell account - im the cpanel admin anyway. ive setup a small test where i just uploaded a versioned folder and i could easily pull from it with bazaar
<BY0LOG1C> i didnt try pushing but at this point i guess it works too. so that should be simple and efficient enough for me. im a happy camper
<BY0LOG1C> but wait, so im goint the suboptimal way, arent i?
<ccxCZ> if you can install bzr on the server, you will be able to use bzr+ssh:// style uris too (aka smart-server)
<ccxCZ> if the server has python installed already it should not be hard
<ccxCZ> easy_install --user bzr  might just do the trick
<BY0LOG1C> i notice a ssh/shell section where i can setup key. but i cant find where i'd install it. i guess i should search around a little and see what i find. i dont want to bother you all day
<ccxCZ> assuming you come from windows: http://www.howtoforge.com/ssh_key_based_logins_putty
<BY0LOG1C> great info, thanks again!
#bzr 2012-07-27
<mnn> hi... has anyone thought of a bit better support of autorenaming in either bzr or bazaar explorer?
<mnn> I mean bzr move --auto is great, but when files are moved into new folders, I have to add those new folders by hand (bzr add --norecurse)
<mnn> and that's the most annoying thing about renaming files
<spiv> mnn: that seems like something that could be fixed.  Want to try writing the patch to do it? :)
<mnn> well, I could... but I would like to do it a "proper" way... because I hack my own code pretty bad :)
<mnn> first - at what level should this be implemented? bzr or explorer? I'm thinking of bzr... but then it would have to scan new folders if files in them were moved
<spiv> Yes, in bzr.
<mgrandi> bzr explorer is a plugin for bzr so do it there
<mnn> so what's it gonna be then?
<mgrandi> hmm?
<mnn> for me, I could just use adding folders without recurse... just add folders (if necessary) and then auto rename
<mnn> mgrandi: spiv suggested that this should be done in bzr itself
<mgrandi> yeah
<mgrandi> bzr explorer uses bzr
<mnn> I know :)
<mgrandi> so doing it in bzr means that bzr explorer can also use it
<mgrandi> =P
<mnn> yeah, but I'm not very familiar with internal structure of bzr or explorer.. that's why I had to ask :)
<mnn> also explorer could get an UI for move --auto
<mgrandi> im not familiar with it either >.>
<cody-somerville> I'm curious. with bzr, you can basically just cp the directory to create another branch yet actually running bzr branch on the same local branch takes significantly longer. Why is that?
<lifeless> cody-somerville: if its inside a repo, it shoudn't.
<lifeless> cody-somerville: if its cross-repos, its cloning the repo, which validates all the internal data.
<cody-somerville> Ok, good to know.
<cody-somerville> I was playing around with git and bzr the other to see how they compare performance wise these days. I found that it took 10 minutes to do a local bzr branch of launchpad but only 30 seconds to git clone local copy of linux. I am using version of bzr from beta PPA though. Does that sound right or is it possible there could be a performance regression in the version I'm using?
<lifeless> its possibly git clone locally just hardlinks or something
<lifeless> its valid to do that for bzr too.
<lifeless> bet you that doing an actual validating clone would be more than 30 seconds for linux :)
<cody-somerville> lifeless, I bet it did do something clever because just cping the git repo took 1m55s
<cody-somerville> (whereas cping the launchpad bzr branch only took 30 seconds since it's only 312M vs. linux's 1.1G)
<mgz> morning all!
<mgz> vila: how is `bzr resolve --all` different from `bzr resolve --done`?
<vila> mgz: looking at the code is the fastest way to get it, but roughly, --all == rm .bzr/checkout/conflicts
<vila> probably there to cover early bugs and get out of them
<mgz> the code paths look equivalent, apart from using a different working tree function to gather the files
<mgz> which is why I'm asking if there's an intended difference :)
<vila> ha right, looking at the code again it's not obvious from the command itself, so, from memory, 'done' means 'I did what was needed, forget about the conflict'
<vila> with no check
<mgz> vila: okay, seems you've done all the hard bits, just needs some refactoring and deprecation of cruft
<mgz> bug 383396 is not what this comment intended...
<ubot5> Launchpad bug 383129 in xserver-xorg-video-intel (Ubuntu) "duplicate for #383396 x server dies with a SIGSEGV when gnome screen saver blanks the display" [Undecided,Fix released] https://launchpad.net/bugs/383129
<mgz> I'm guessing bug 389396
<ubot5> Launchpad bug 389396 in Bazaar "bzr resolved does not resolve shape conflicts" [High,Confirmed] https://launchpad.net/bugs/389396
<vila> mgz: you're right
<vila> 3 6 9, too many multiple of 3 for my brain ;)
<jelmer> hehe
<mgz> okay, I've bascially got this fixed.
<mgz> main fun bit is keeping compat with old oddness for now
<jelmer> mgz: what do you have fixed, the resolve stuff?
<mgz> have we got a bug for making 'auto' an allowable resolve action, or for making bzr resolve FILE not default to --done?
<mgz> yeah, I was ignoring the thread, but read it this morning and had the "this can't be that hard to just fix" feeling
<mgz> and how to we deprecate params to commands normally?
<jelmer> mgz: I think we add a bit of code that spews to standard error inside of the command if the option ws specified
<mgz> okay, 10 failures from change to semantics
<mgz> vila: TestResolveUnversionedParent methods test_take_this and test_take_other... don't actually use those args
<mgz> that's just a mistake, or am I missing something?
<mgz> hm, I understand it now, it's test_take_this is not like test_resolve_take_this, it'd doing the same actions manually
<vila> mgz: just back from launch, question still pending or ok now ?
<mgz> okay, I'll put up some mps shortly which should cover the remaining queries
<mgz> ...think I might just fix some of these old conflict bugs while I'm in the area
<mnn> I'm having trouble with making a test - assertRaises doesn't "catch" the exception thus making the test fail
<mgz> mnn: pastebin me some stuff?
<mnn> ok
<mgz> generally the form is: self.assertRaises(UnicodeError, str.decode, "\xff", "ascii")
<mnn> yeah, I already found that out by searching already written tests
<mgz> if the error raised is not a subtype of the first arg, it propogates
<mnn> http://pastebin.com/w4fjEm2p
<mnn> http://pastebin.com/TBAS98PX
<mnn> http://pastebin.com/xhCFU6b3
<mnn> and simple patch, if you wanted to try it out:
<mnn> http://pastebin.com/eija9Y1d
<mgz> you're giving assertRaises an instance not a class
<mnn> yeah... I found it out just now :)
<mnn> thanks anyway
<mgz> checking e is the right thing to validate the details
<mgz> I'd assert on the attributes of the exception rather than its stringification in those kinds of tests
<mnn> yeah, I noticed that other tests do this when they test if right exception is raised
<mgz> and add a test in bt.test_errors that the stringification is sane
<mgz> mnn: some suggestions <http://pastebin.com/dPHqEyzZ>
<mgz> I'd look at avoiding the need for an actual sftp transport for the test too
<mgz> is/can _translate_io_exception be made a classmethod or staticmethod
<mgz> mnn: you need to name the extra string param somthing other than 'msg' which is used by the base error class
<mnn> ah... I wasn't aware of that
<mnn> thanks
<mgz> ....well, you probably don't, some of the other subclasses use that, but it would be less confusing
<mnn> yeah I noticed that too
<mgz> looks like you're making good progress
<mnn> well thanks... I wasn't sure if I should dive into all this, because of my lack of knowledge/experience with Python (the only dynamic language I have experience is Lua)... and lack of Bazaar exprience :) but it seems it works so far
<mnn> mgz: well I'm not sure about making _translate_io_exception static/classmethod... it calls _translate_error from its super/base class
<mnn> however that doesn't use anything from the instance
<mgz> right, just checking that
<mgz> Transport._translate_error also does not use self
<mgz> I'd decorate both with @staticmethod
<mnn> ok, thanks for advice
<mnn> but self has got to go away, right?
<mgz> they have the leading underscore as a private hint, so fiddling is fine
<mgz> right, you remove it from the arg list
<mgz> def method(self, arg): ...
<mgz> ->
<mgz> @staticmethod
<mgz> def method(arg): ...
<mnn> ^^ and that's what I didn't like about python, when I stumbled upon it a few years back... something as "private" doesn't really exist there
<mgz> then you can just use the base TestCase from bzrlib.tests and skip lots of transport setup
<mgz> mnn, it's amazing how much time it saves, not being strict about stuff
<mgz> makes it really hard to write robust libraries, but such are the tradeoffs
<mnn> yeah sometimes it really is handy to access private stuff of the class
<mnn> mgz: so, I've finished the tests... I've read online that it is possible to rebase my branch to reorganize my commits... however the are opinions on not doing rebase at all
<vila> mnn: IMO, *not* rebasing means the readers of your code will have a better way to understand your intent
<mnn> well from what I've read I think you're right
<mgz> mnn: I wouldn't worry about it, unless you have a couple of messy commits on the end that you've not pushed up yet, then I tend to uncommit and tidy up
<mnn> however as I said opinions differ
<mgz> hm, the help for bzr st doesn't document 'missing'
<mnn> does anyone know, if it is somehow possible for a branch to override user ignore config?
<vila> mnn: not sure what you mean here, 'bzr add FILE' will start versioning FILE *even* if FILE is ignored (i.e. 'bzr add' won't add FILE automatically)
<mnn> oh, thanks, you're right... I'm still new to all this stuff, so I occasionally miss simple things like this
#bzr 2012-07-28
<BY0LOG1C> is it possible to version each of my project individually and add them all to a master branch?
<BY0LOG1C> so i could branch out at any level of my 'full repository'
<BY0LOG1C> i basically just want to be able to bind to either the full repo or a single project within it
<wgz> okay, I've reviewed just about everything apart from mnn's branch, which is what I was going to do at the start...
<jelmer> hey wgz
<wgz> hey jelmer
<wgz> the merge-grep proposal bounced, seems like it needs updating for deprecations/removals on trunk
<jelmer> ah
<jelmer> I'll have a look
<wgz> in all the email spam from me there are probably a few other things specifically targetted at you...
<jelmer> wgz: oh?
<wgz> ah, you found the odd diff bug for bzr-git
<jelmer> wgz: that one doesn't make much sense to me, and I can't reproduce it
<wgz> the other thing is what to do about bug 1021537
<ubot5> Launchpad bug 1021537 in Bazaar ""missing referenced chk root" while merging gcc into gcc-linaro" [Medium,Fix released] https://launchpad.net/bugs/1021537
<wgz> ^right, he's added a ref to a specific repo now, which may help
<jelmer> wgz: just commented on that one
<wgz> oh, and the last thing is lp:~jelmer/bzr/lazy-registries seems to have been a test case for when pqm was borked, but I'm not sure what's actually preventing it landing
<wgz> and that's your lots.
<wgz> -s
<jelmer> wgz: okay
<jelmer> wgz: yeah, I think there was something funky going on in that lazy registries branch
<wgz> I noted the dutch athetes had quite sensible outfits last night, apart from the mandatory violent orange
<wgz> better than the germans in tasteless blue and pink pastels
<jelmer> wgz: there was more to it than just the mandatory violent orange?
<wgz> mostly just suits, with a smattering of the "suprise" trousers thrown in
<wgz> outdid bermuda on blinding legwear
<wgz> they just had red shorts.
<jelmer> they were bare-chested?
<wgz> ehehe, no, just in comparison, not just in clothing.
#bzr 2012-07-29
<mnn> while looking into RenameMap, I've found a bug - bzr move --auto tries to move parent directory, even though that wasn't actually moved
<mnn> pastebin of commands should explain better:
<mnn> http://pastebin.com/5aL3Qrnn
<mnn> this is present both in trunk and also in 2.5.1
<mnn> no idea if this is intended or not, but I'd like to post a bug on launchpad, if there are no objections
<wgz> mnn: I tend to go with a file-first policy, marking a bug as a dupe or invalid later if I learn something else works fine
<wgz> I think we may have a bug for this though, search for "inconsistent delta"
<wgz> maybe bug 373319?
<ubot5> Launchpad bug 373319 in Bazaar "mv --auto does not handle directory adds mixed with the contents of a directory splitting in two: InconsistentDelta error" [High,Confirmed] https://launchpad.net/bugs/373319
<wgz> the dirstate code is frustratingly hard to hack on, but people have managed to dive in and fix problems with it in the past
<mnn> wgz: well I actually wanted to adjust move --auto to handle moving into new directory, while stumbled upon this
<mnn> wgz: I think I have identified the problem
<mnn> I need to try the fix and run the tests, if I haven't broken anything in the process
<mnn> ok, it seems we have a winner:
<mnn> http://pastebin.com/QRfpeZjx
<mnn> here's test with reproduction script from 373319
<mnn> http://pastebin.com/tZKzTjrF
<mnn> ok, the code doesn't choke on complicated cases... so I guess it's ready:
<mnn> http://pastebin.com/0GaUf7UJ
<mnn> what is this???
<mnn> 'bzr: ERROR: unknown command ""status""\n'
<mnn> first I did simple self.run_bzr('status') but got exception about result code mismatch - so I tried self.run_bzr('status', 3) and got this nonsense
<wgz> mnn: using bzr from outside its normal initialisation, you need a bunch of extra silly steps
<wgz> see lp:~gz/+junk/call_bzr_init for an example
<mnn> my working directory is actually a branch ... I'm aware that bzr's working directory needs to be in such directory
<mnn> I'm writing a test
<wgz> okay, then you just want to look at the tests under blackbox for actually running commands
<wgz> the base test class doesn't support doing things with bzr commands or things on disk
<mnn> I'm modifying TestRenameMap which is a TestCaseWithTransport
<mnn> TestAdd is TestCaseWithTransport too
<mnn> and it uses self.run_bzr(), obviously
<wgz> okay, I need to stop answering your questions before thinking properly :)
<mnn> yeah :) because unfortunately they haven't been helpful
<mnn> and btw could you take another look at this?
<mnn> https://code.launchpad.net/~mnn282/bzr/sftp-unsupported-operation-more-info/+merge/116849
<wgz> yup, I shall, stop being slack and respond to that
<wgz> some of my advice from the other day wasn't completely ideal either :)
<mnn> yeah... but I was able to work around them :)
<wgz> so, for instance, @classmethod would probably be better than staticmethod for the _translate_io_error function, which then takes cls as the first argument and saves importing and upcalling to Transport
<wgz> and a few other little niggles, otherwise it's great
<mnn> well write all those niggles there, I will take a look at them later... now I want bzr status! :)
<wgz> ...not having any ideas on your self.run_bzr("status") problem, looking at bzrlib/tests/blackbox/test_status.py (especially the simpler tests at the bottom)... it should just work
<wgz> pastebin me the smallest test you get weirdness with?
<mnn> well even such small test gives me save result:
<mnn> http://pastebin.com/wddFKXNj
<mnn> I definitely must be doing something wrong
<wgz> give me a whole test class and method
<mnn> wow, this is just weird... suddenly it works :) I've tackled issues with locks and inequality issues
<mnn> will push the branch and make merge proposal
<wgz> right, that looked like it should be fine given the right test class
<wgz> have you discovered the neat way of running just a subset of tests yet?
<wgz> do `python bzr selftest -s bt.test_source` for instance
<mnn> I use bzr selftest -v source_name (i.e. bzr selftest -v test_rename_map)
<mnn> btw. https://bugs.launchpad.net/bzr/+bug/373319
<mnn> wow, it took 3 years to fix a bug from its original discovery... and such high priority bug
<ubot5> Ubuntu bug 373319 in Bazaar "mv --auto does not handle directory adds mixed with the contents of a directory splitting in two: InconsistentDelta error" [High,Confirmed]
<wgz> using -s and the path (bt. short for bzrlib.tests. and bb. being short for bzrlib.tests.blackbox) avoids loading all the other modules so is nice and quick
<mnn> yeah.. it is much faster... however it seems to print less information than -v
<mnn> wgz: btw. more reviewing :)
<mnn> https://code.launchpad.net/~mnn282/bzr/auto-rename-fix/+merge/117203
<wgz> mnn: looks like you could simplify that test a little but doing:
<wgz> tree = self.make_branch_and_tree('.')
<wgz> rather than 'tree'
<mnn> yeah, right
<mnn> I'm still new to all this
<wgz> the rest is going over my head right now
<mnn> no problem... just don't forget about me :)
<wgz> and you do want to run `bzr selftest -s bt.test_source` on your branches
<wgz> because we have a test that fails if there's not a unix-style newline terminator at the end
<wgz> and I think both branches have a file that like that
<wgz> shows up in the diff on the mp as:
<wgz> \ No newline at end of file
<wgz> (picky I know... but it's there)
<wgz> good work on both though, even if I nitpick things a fair bit, it's only because the fundamentals are good and you're just not familiar with a few style things
<mnn> no problem... that's why I always ask about stuff
<mnn> ... and sometimes hitting a wall here :)
<wgz> mnn: can you do <http://www.canonical.com/contributors>?
<wgz> there's an online form and the terms a less silly than they used to be
<wgz> john.meinel@canonical.com is who you want to cc at the end.
<mnn> yeah, I see him on the page:  John Arbash Meinel (john.meinel {at} canonical {dot} com)
<mnn> it's actually the first license agreement that I'm reading fully... since it's so short :)
#bzr 2013-07-23
<mathrick> jelmer: what's the proper way of doing bzr missing against a remote git repo? Do I need to have a local synced branch to be able to do so, given the inability to do it remotely via git smart protocol?
<jelmer> mathrick: yes
<mathrick> ok, thanks
<mathrick> how can I refer to other branches in the same colocated workspace, when using development-colo?
<mathrick> bzr-colo had colo: URL handler
<mathrick> oh, file:,branch=foo
<mathrick> also diff doesn't like colocated branches
<mathrick> bzr diff --new=file:,branch=hig-cleanup --old=file:,branch=origin
<mathrick> shows no changes at all
#bzr 2013-07-24
<thomi> I'm confused: Can I install a hook by placing it somewhere in the branch's .bzr folder?
<thomi> in some places in the docs it says hooks need to be installed via ~/.bazaar/plugins, and in other places it seems to suggest tat you may be able to install the hook into the branch/repo directly
<lifeless> thomi: you cannot install them in the branch/repo
<thomi> :(
<lifeless> thomi: it would be a huge security hole to run arbitrary code in something you clone; we permit /config/ but not /install/ there.
<lifeless> thomi: if you want a plugin active for just one repo, the plugin should consult config in that repo.
<lifeless> as in, branch.get_config() and drill in from there.
<thomi> lifeless: I want to make peopel contributing to a particular project unable to commit code unless pep8 passes - it sounds like I can't do that without them having to install the plugin manually
<thomi> I guess I can do it at package build time instead.
 * thomi is feeling draconian today
<lifeless> you could put the check in your test suite
<thomi> lifeless: yup, but I'd still need to trust the developers to actually run the tests :-/
<lifeless> thomi: ...
<lifeless> thomi: your CI system should reject their merges before you see them, no?
<thomi> Yeah, I'll implement the check at the CI level
<dlpenguinlover> Hello, I'm having some trouble with a bazaar repo i'm trying to get working. I'm trying to install a launchpad instance on a virtual Ubuntu Server, however while i'm downloading a repo to install Launchpad, bazaar is erroring out saying the repo is corrupt. I do not want to redownload 400+ mbs of data, is there any way to "fix" the repo?
<mathrick> dlpenguinlover: I'm not exactly sure what you ended up with, but if you have a bzr branch in an accessible state, you can bzr check it
<mathrick> it will do so some sanity checks and tell you if/what issues there are
<dlpenguinlover> "No working tree found at specified location."
<mathrick> dlpenguinlover: bzr check --repo and possibly --branch
<dlpenguinlover> mathrick: $ bzr check --repo --> Checking repository at 'file:///home/david/launchpad/lp-brakches/'. ----
<mathrick> yes
<mathrick> it will take time
<dlpenguinlover> checked repository file:///home/david/launchpad/lp-branches/ format RepositoryFormat2a() -----> 0 revisions 0 file-ids
<mathrick> uh
<dlpenguinlover> $ bzr check --branch -------> No branch found at specified location.
<mathrick> then it hasn't actually downloaded anything it seems
<mathrick> dlpenguinlover: what does "du -hsc file:///home/david/launchpad/lp-branches/" say?
<mathrick> err
<mathrick> without file://
<dlpenguinlover> 237M   /home/david/launchpad/lp-branches/       237M total
<mathrick> well, not sure how to help you with that
<mathrick> but it seems to be broken completely
<mathrick> dlpenguinlover: how exactly did it error out in the first place, and is it consistent?
<dlpenguinlover> mathrick: well, the launchpad installer (called rocketfuel-setup) was the one executing the bzr commands, but this is what it outputted. "bzr: error: No WorkingTree exists for "file:///home/david/launchpad/lp-branches/devel/.bzr/checkout"/ ERROR: Your trunk branch in /home/david/launchpad/lp-branches/devel is corrupt. Please delete /home/david/launchpad/lp-branches/devel and run rocketfuel-setup again."
<mathrick> and did you do that?
<dlpenguinlover> Yes, and it gives the same error message.
<mathrick> dlpenguinlover: aight, so you have sub-branches under that dir
<mathrick> what does bzr info file:///home/david/launchpad/lp-branches/devel give you?
<jelmer> hi mathrick
<jelmer> mathrick: there is also "co:" which behaves similarly to "colo:"
<mathrick> jelmer: oh, I couldn't find that mentioned anywhere
<jelmer> mathrick: it's undocumented - don't use development-colo, as it is unfinished
<jelmer> (hence the "development-" bit :-)
<mathrick> jelmer: I know, but it kinda beats having mysterious path errors when cloning colocated branches across OS
<jelmer> mathrick: okay, up to you :) Just be wary of bugs
<mathrick> I am!
<mathrick> jelmer: in fact I ran into a couple where various things get horribly confused when I ask them to compare colocated branches
<mathrick> diff says no changes, missing doesn't even understand what I'm asking it to do, etc.
<jelmer> mathrick: please file bugs and tag them "colocated"
<mathrick> OK
#bzr 2013-07-25
<mathrick> jelmer: is there any hope to allow bzr to branch from the recently-changed github ssh urls?
<mathrick> ie. git@github.com:mathrick/muffin.git rather than git+ssh://git@github.com/mathrick/muffin.git
<mathrick> especially the : is problematic
<mathrick> is there a rename-branch command yet?
#bzr 2013-07-26
<Wiz_KeeD> hey guys
<mathrick> hi
#bzr 2014-07-21
<thrustcore> how come my bzr folder has a 26 GB folder called ".bzr" full of binary junk? Can I safely delete this folder? (It's become so big that I can't run bzr update anymore)
<spiv> thrustcore: 'bzr pack --clean-obsolete-packs'
<spiv> and *maybe* 'bzr pack', but that happens periodically automatically
<spiv> You can't safely delte .bzr though, it contains your revision history!
<fullermd> Also, don't version blurays   :)
<thrustcore> I'm pretty sure we're not versioning blu rays
<thrustcore> but how come it's storing 20 gb's of packs that aren't obsolete
<thrustcore> what the hell is in there
<fullermd> The stuff you've committed.
<thrustcore> jesus shit, I can't believe I've committed so many gb's
<thrustcore> this folder is just going to keep growing then
<thrustcore> I'm out of hard drive space, what do I do?
<fullermd> I'd start by figuring out what the heck you're committing that's getting that big.  I suspect you haven't written 20 gig of source code.
<thrustcore> probably virus definition files
<thrustcore> I'm not in charge of the repository
<thrustcore> and the text file that I commit the most often is only about 65K lines
<thrustcore> I should be able to commit that thousands of times
<thrustcore> it's only 8 megs
<thrustcore> why do I even need to keep these committed packs around?
<fullermd> If you don't have revs that reference them, you theoretically don't.  But you presumably do, unless you toss history regularly.
<fullermd> VCSen as a rule deal poorly with the case "big lumps of binary data changing all the time"...
<thrustcore> I don't really get what you mean by tossing history
<thrustcore> is that something I can do to save disk space?
<maxb> As in, throwing away all your history and starting version control afresh
<fullermd> Well, sorta.  You don't need to spend space storing the history, if you throw away the history...
<maxb> Not generally a particularly viable solution though
<thrustcore> why the hell do I have to store the history locally though, why isn't it stored somewhere else
<fullermd> That comes along mostly by definition in the 'D' part of 'DVCS'.
<thrustcore> bzr is distributed eh?
<thrustcore> goddamn, no wonder
<thrustcore> fullermd: is it possible to store the revision packs on a different drive? (windows)
<fullermd> Oh, probably a few ways, of varying degrees of intrusiveness.  The easiest would just be to move the whole workspace over; no reason to complicate things beyond that unless some part of it really needs to be in the current location.
<spiv> 26 GB is unusally huge.  I'd suspect there's unwanted large binaries in there.  It may be simplest to throw the history away and start again (or if you really care, filter it via fastexport/import perhaps).
<spiv> Depends on what you need.
<thrustcore> it's 30Gb now
<thrustcore> what the hell lol
<thrustcore> I've only been committing the same text file over and over
<thrustcore> what exactly is the difference between the "packs" and "upload" folders?
<thrustcore> packs has 21 gigs but upload only 5
<beuno> thrustcore, you could try running "bzr pack" manually
<beuno> and it'll optimize as much as it can
<beuno> it does so automatically every now and then
<beuno> but that's as small as you'll get it, after the pack
<thrustcore> beuno: I can't run bzr pack because I have no disk space
<thrustcore> can I run the pack so that it uses another volume to work on?
<spiv> If pack can't run, that will exacerbate your problem :(
<thrustcore> gah, that's horrible
<thrustcore> I'll move my virtual machine to the slow disk and try again :(
<beuno> spiv!  hey there
<spiv> beuno: howdy!
<spiv> (I'm actually in London this week, as it happens)
<jelmer> hey beuno, spiv
<beuno> it's a reunion!
<jelmer> beuno: :)
<jelmer> beuno: what are you working on these days?
<beuno> jelmer, the appstore for the ubuntu phone
<beuno> and surrounding things like payments and sso
<beuno> lots of juju and scaling
<beuno> fun
<beuno> you?
<jelmer> beuno: ah, cool :) That's the server side of the store then?
<jelmer> beuno: I'm working on google's frontend
<jelmer> mostly DNS related things
<beuno> jelmer, yeah, with the new click format, which is much easier to work with than debs
#bzr 2014-07-22
<mark06> anyone knows a solution for this? http://i.imgur.com/PtfK5y5.png
<zyga> hey, I'm trying to debug a bug in bzr join
<zyga> what I'm seeing is that a bzrlib.inventory.Inventory has a duplicate entry
<zyga> the curious thing is  that the file_id of the entry is just the filename
<zyga> both entries seem to be coming from a git import of some repositories
<jelmer> zyga: that's normal, file ids from git imports are mostly just paths
#bzr 2014-07-23
<zyga> jelmer: so now I get duplicates because I already have a bzr-joined git import (of another tree) in this tree
#bzr 2014-07-24
<hbeck> hi, hoping someone can help answer a question. We had a non-controlled subdirectory under a checkout, the directory was then added with a subset of files. When the other person updated to get the latest, the non-vcs-controlled directory contents were erased
<hbeck> is this correct behavior?  Why would the update remove all the existing stuff?
#bzr 2014-07-26
<mmu_man> ahh,finally found where all the hardcoded paths are for ssl certs in there...
<mmu_man> would be much more handy to have --with-certs to setup.py :^)
<mmu_man> FWIW:
<mmu_man> http://bb.haikuports.org/haikuports/src/3cabb3cfe21740caa81d01d886cad98e00826e36/dev-vcs/bzr/patches/bzr-2.6.0_gcc2.patchset?at=master
<mmu_man> Haiku port
<mmu_man> (yes, we require gcc2 because we use it for binary compatibility with BeOS R5, and we only ship gcc2-built python for now, and bzr needs libpython)
<jelmer> mmu_man: fwiw bzr doesn't strictly need libpython, though it will be a lot faster if you build the c extensions
<mmu_man> ok, well it seems to work this way
<mmu_man> not a big issue
<mmu_man> after R1 we'll drop gcc2 anyway
#bzr 2015-07-21
<kyrofa> If I merge branch A into branch B and then delete branch A, is there a way to get it back from the merge into branch B?
<LeoNerd> Probably. Though it might need some careful inspection of raw revids
<kyrofa> LeoNerd, ah, brilliant! Thank you
<kyrofa> LeoNerd, I was able to just branch one of the parent IDs and there it was
<LeoNerd> Ah :)
#bzr 2015-07-24
<SpamapS> Hi, how do I ask bzr which tags contain a certain commit?
#bzr 2016-07-26
<smoser> hey.
<smoser> if i bzr fast-export, i get all the merged commits
<smoser> bzr nicely "nested" these commits
<smoser> but exporting to git, i see lots of little commits that people did on branches that you could see with bzr log --include-merged
<smoser> but generally were not bothered with
<smoser> i'm willing to accept the loss of those commits to keep sane commit messages in 'git log'
<smoser> any ideas?
#bzr 2016-07-27
<smoser> well, in case anyone is reading backscroll, i ended up just accepting it.
<smoser> git log can not show them with --first-parent.
