#bzr 2008-02-04
<simony> local, but I had a bind to a remote non-responding server
<simony> I tried making a bundle with a remembered location of that server, and then to break lock when that hung, also hung, possibly because I was still bound
<abentley> lifeless: ping
<igc> bbiab
<lifeless> abentley: pong
<jamesh> morning lifeless
<lifeless> hi jamesh, nice to see you hacking on bzr desktop stuff :)
<abentley> I am confused by a comment you added to KnitVersionedFile._get_content_maps.  It's the one that begins with FUTURE
<lifeless> abentley: paging in
<jamesh> lifeless: I'm about half way through redoing bzr-avahi
<lifeless> abentley: right, its about avoiding memory pressure and copying
<abentley> It looks like the suggestion has already been done, and was done in the same commit.
<abentley> Oh, I see.
<abentley> It's about tracking it on a per-component level.
<lifeless> right
<lifeless> compent X may be needed for 400 children
<abentley> Rather than just having the multiple_versions toggle.
<lifeless> yeah
<lifeless> ideally if we extract two texts at once with no common components no component should be copied
<lifeless> and two texts with X components in common - a Y shape tree - we should not copy any of the X common components, only the single point at which it bifurcates
<abentley> One issue I'm trying to sort out is how to handle memory pressure in iter_files_bytes.
<abentley> Even if you get rid of components as soon as you don't need them, you can still wind up with old fulltexts for all the files in memory at once.
<jamesh> lifeless: I don't know if it is relevant to your bzr-dbus plugin, but I got bzr-avahi broadcasting signals over the session bus without a central daemon (other than the session bus itself)
<jamesh> lifeless: maybe you could use something like that to simplify bzr-dbus?
<lifeless> jamesh: possibly; actually I want to have the central service provide a recent-history list
<jamesh> ah.
<jamesh> lifeless: for bzr-avahi, the use case was to notify any interested server processes when changing the "advertised" state of a branch
<jamesh> in which case a simple signal broadcast fit well
<lifeless> yah
<lifeless> it may be overengineering of course
<lifeless> abentley: re memory pressure - indeed; this is why I think we may not want to optimise for IO performance over everything else; find a balance.
<lifeless> abentley: we know how big the components are; so we can say 'up to X MB in memory at once', and plan extractions that only exceed that when they have to (ISO's anyone)
<abentley> Good idea.  That should be reasonably easy to achieve.
<lifeless> spiv: ping
<lifeless> abentley: its tricky figuring out how much memory is reasonable, I would say 50MB or so of components?
<lifeless> abentley: or even 10MB is enough to massively reduce round trip latency
<abentley> Yeah, those numbers are okay.
<abentley> I'm planning to start with a version that just assumes infinite memory, and then tune it.
<abentley> but 50 MB about the size of the Bazaar repository.
<lifeless> abentley: I'd like to write a hook for people wanting to do \r\n conversions, and $Id$ conversions
<lifeless> abentley: Do you think its reasonable for us to have a single API point for writing-to-a-tree-file and reading-from-a-tree-file ?
<lifeless> abentley: I'm thinking a chain of filters, each of which has an 'in' and 'out' direction, that respectively adds/removes the filters changes.
<lifeless> abentley: and presumably a reference to $configuration data to determine when to operate
<abentley> That sounds pretty reasonable.
<abentley> We currently have a wacky set of overlapping file read functions.
<abentley> TreeTransform does most of the file writing, but I think there are some exceptions, like .bzrignore.
<abentley> It would be nice to avoid invoking the filters for files to which they don't apply.
<abentley> Rather than having the filters themselves determine that.
<abentley> I don't know if there would be significant performance degredation for files that needed no filtering.  Perhaps we wouldn't notice.
<lifeless> so I am thinking that the default is no filters present
<lifeless> and tree transform etc would do a single lookup to get the callables/object to use for a given tree, so that will in the case of no filters be identical performance to now
<fullermd> Might you need some add'l logic in dirstate to properly catch [un]changes?
<lifeless> avoiding invoking the filters for some files seems like an abstraction violation to me
<lifeless> fullermd: dirstate will have to work with this yes, in particular it needs to see the filtered version for a given sha1 etc
<lifeless> fullermd: and turning on a filter for an existing tree needs care
<lifeless> it will be a tree format bump at a minimum to do this AFAICT
<fullermd> Could be some trickiness in there too.
<fullermd> Like if I had an $Id$ in the file, and manually collapsed it.
<lifeless> fullermd: yes, but if you are insane enough to want $Id$ support, you get what you deserve.
<fullermd> :P
<lifeless> spiv: ping
<poolie> spiv, ping :)
<poolie> spiv, can you make that protocol update doc public somewhere?
<spiv> poolie: ok, on phone with lifeless atm :)
<poolie> haha
<mlh> poolie: I think your1.2 release rc mail was truncated
<poolie> hm
<poolie> it left here ok
<poolie> oh i see, just the last sentence
<mlh> yar
<mlh> To get them ... out on time?
<mlh> Just mentioning it in case there was a chunk left off
<lifeless> jamesh: was my gnome-gpg patch correct?
<jamesh> lifeless: I didn't get round to checking it out last week (busy at LCA).  I'll do so this week though
<lifeless> no worries
<jamesh> I ran into this bzr bug last week: https://bugs.edge.launchpad.net/bzr/+bug/86838
<ubotu> Launchpad bug 86838 in bzr "locations.conf gets rewritten, dropping necessary quotes" [Undecided,New]
<jamesh> was a bit puzzling
<jamesh> on mDNS naming conflicts, I was trying to write the new name for the branch from "foo" to "foo #2"
<jamesh> and reading that config value back gave "foo" ...
<poolie> that sounds bad, though maybe a configobject bug
<lifeless> eek
<jamesh> the configuration file does seem to retain the trailing comment though
<jamesh> so on the next loop it rewrote the config to "mdns-name = foo #2#2"
<jamesh> etc.
<lifeless> rotfl
<abentley> spiv: ping
<spiv> abentley: pong
<abentley> Could I get your opinion on the Storage API I proposed?  I'd like your opinion on whether it's a reasonable minimum API for remote repositories.
<Nephyrin> And that's how you know when you're on freenode.
<spiv> abentley: I'll take a look
<abentley> Thanks.
<Peng> Hmm, what happens if a remote branch gets updated while pulling?
<abentley> Peng: You get a correct copy of the branch before it was updated.
<Peng> Oh, cool.
<Peng> I think "import bzrlib.lazy_import" imports 30 more things in 1.1 than it did in 0.90 or 1.0 or whatever I had before. How nice. :P
<mtaylor> Peng: lazy_import does a really good job of confusing editors that are IDE's and parse the code, too :)
<jamesh> https://bugs.edge.launchpad.net/bzr/+bug/188855 <- MemoryTransport.list_dirs() seems busted
<ubotu> Launchpad bug 188855 in bzr "BzrDir.find_branches() goes into an infinite loop on MemoryTransport" [Undecided,New]
<ubotu> New bug: #188855 in bzr "BzrDir.find_branches() goes into an infinite loop on MemoryTransport" [Undecided,New] https://launchpad.net/bugs/188855
<Peng> mtaylor: Heh, yeah.  It confuses my more basic text editor's auto-indendation too.
<Peng> Mercurial's demandimport is better there. It replaces __import__ so it intercepts all imports and you can use the regular import statement.
<Peng> Importing just it also doesn't import half the stdlib. :\
<Peng> Not all modules can be imported lazily, so it has to keep a blacklist though.
<Peng> But it does save on code, since it doesn't have to parse the string of import statements lazy_import does.
<spiv> Hmm, just "import bzrlib.lazy_import" it does seem to import 52 modules.
<spiv> Which does seem a touch high..
<Peng> Thanks to bzrlib.__init__.
<Peng> ISTM it imports either 70 or 100 other modules.
<spiv> And bzrlib.errors
<Peng> It only lazy-imports bzrlib.errors.
<Peng> Isn't the email module in stdlib supposed to have a working lazy-importer?
 * spiv foods
<Peng> (It lazy-imports its submodules since they apparently all import each other.)
<Peng> Ohh, it does work. It just doesn't prevent the AttributeError the first time one tries to access a submodule.
<Peng> But it works the second time.
<Peng> That's not so useful.
<Peng> email's LazyImporter is precisely 9 lines long. But if it doesn't work, I guess that doesn't mean much compared to the 200 lines bzr uses and the 50 or 75 lines hg uses.
<Peng> (Not counting setup code.)
<poolie_> hm
<poolie_> Peng, hg's approach is reported to cause problems for other programs trying to import it
<poolie_> there is one idea we could take from email.py, which would be to explicitly know about all submodules, and create their importers in bzrlib at load time
<poolie_> i'm not sure if this would be very practical
<mwhudson> hg's interfere's with hg's own setup.py last i checked :)
 * mwhudson zzz
<Peng> Bzr is way too large, and still rapidly-evolving, to do that.
<poolie_> mm
<Peng> mwhudson: Oh, is that the reason easy_install doesn't work with it?
<poolie_> i think we add modules rarely enough that having a list in bzrlib/__init__ would be ok
<poolie_> however, i think it would mean everything had to be referenced through fully-qualified names, which would be tedious
<Peng> Would you list all modules recursively, or just the top-level ones?
<poolie_> i hadn't got that far
<poolie> do you think it could work even for top level mods/
<Peng> As of 1.1, there are 121 top-level ones and 558 total, not counting the 4 or 5 C ones.
<Peng> That can't be right.
<Peng> Yeah, it is.
<Peng> Yikes.
<spiv> Peng: Hmm, with a bit of hackery here, I can get the number of imports caused by "import bzrlib.lazy_imports" down to 43.
<spiv> Still not quite as quick on "bzr --no-plugins rocks" as the 0.92 version in my /usr/bin/, though.
<Peng> I was just using it in a random script I hacked together for one module, so that's still about 42 modules more than I'd like. :P
<poolie> what were you calling in bzrlib?
<Peng> Nothing.
<Peng> I think lazy_import is neat and just wanted to use it. :)
<asac> hey ... if a branch is locked like "locked 176 hours, 7 minutes ago" ... how can i resolve it manually?
<asac> (doing a push)
<quicksilver> bzr break-lock, or something
<quicksilver> I thought there was a hint in that message telling you, actually
<asac> what location to use?
<asac> http://paste.ubuntu.com/4161/
<asac> e.g. Usage:   bzr break-lock [LOCATION]
<quicksilver> the location of the branch which has a lock?
<asac> yep works
<asac> thanks
<zurgutt> is it documented somewhere what happens if one has several repositories on one work tree?
<awilkins> Do you mean nested trees?
<zurgutt> i guess so
<awilkins> I have an interest but I've not had time to experiement with it
<zurgutt> cd root;bzr init;cd subdir_under_root;bzr init
<awilkins> http://bazaar-vcs.org/NestedTrees
<dato> zurgutt: but, are they independent?
<zurgutt> i expected for it to work transparently, meaning the two branches should not get in eachothers ways, but seems that outer branch does not "see" into inner one
<dato> you just have to take care of not "adding" inner into outer, and it should work? (that is, they'll be completely independent)
<zurgutt> that means every file created in inner must be explicitly added, recursion doesnt work
<zurgutt> ?
<awilkins> Ah, so if is issue "bzr add outer", you want it to also imply "bzr add inner"  ?
<dato> what I mean is: "if you want outer to know nothing about inner (that is, inner could as very well be somewhere else), that works. if you want for outer to know about inner, that's nested trees, what awilkins said." afaik, anyway.
<zurgutt> basicly its web tree of a big project, i want to have one repo for "everything" as kind of archive and separate ones for subtrees, for speed and convenience
<awilkins> zurgutt: You can use the same repository to store a whole bunch of branches and use something to manage how you check them out?
<zurgutt> not what i look for i think, how do i describe it.. ok very basicly - can one file in a work tree belong to 2 different branches at same time?
<johnny> describe the use case?
<zurgutt> cd /webroot/subsite;bzr init;bzr add;bzr commit   ; cd /webroot;bzr init;bzr add;bzr commit - now if i add a file in /webroot/subsite i would expect cd /webroot;bzr add;bzr commit would include and version that file
<zurgutt> what DOES seem to happen is bzr in /webroot does not seem to see any changes in /webroot/subsite anymore
<johnny> it shouldn't
<lostylost> I have a question: What would happen in the scenario where I have created some changes in the working tree of a bound branch, then run update before doing a local commit. What happens to my changes are they overwritten?
<zurgutt> johnny: what do you mean
<johnny> i mean.. it should
<johnny> that's expected behaviour atm prolly
<dato> lostylost: no, they will be retained. *maybe* there will be conflicts, at most.
<lostylost> ok cheers
<lostylost> I figured as much, just wanted to be clear
<zurgutt> johnny: ok, if i run a test case and pastebin the console log, can you look at it?
<johnny> i prolly wouldn't be the best person to answer
<johnny> but by looking at what you said, and then looking at the nestedtree doc
<johnny> it seems like that is how it should work
<zurgutt> can you give url to doc you mean, i tried to look it up but ones i found did not have much info
<johnny> somebody already did
<johnny> they said you have to use configmanager, there is no in bzr support for nested tree
<zurgutt> configmanager appears to be tool to deploy files from separate branches into one tree, what i am looking for is the reverse process
<johnny> it doensn't exist
<johnny> afaik
<johnny> wait for a few hours and ask again i guess
<zurgutt> thats strange because it would not need any extra functionality whatsoever and just seems to be arbitrarily blocked
<johnny> i know many vcs don't support it
<johnny> so tha'ts not the case
<zurgutt> see the example in http://pastebin.ca/891133 , can anyone tell why this happens?
<Peng> zurgutt: That would be horribly confusing.
<Peng> zurgutt: Should the higher-up branch version the .bzr directory of the lower one too?
<zurgutt> how come?
<zurgutt> no of course not, it should not touch . dirs
<zurgutt> every branch should just see normal file tree under it
<Peng> How is the lower branch related to the upper one? If you do "bzr log" for the upper one, should it show the lower one's log too?
<Peng> If you commit a change in the lower one, you'd have to also commit it in the upper one.
<zurgutt> neither branch should not be aware of other one
<zurgutt> so yes, change in sub would need separate commit in sub and the container
<Peng> That would be horrible.
<zurgutt> why?
<zurgutt> i see no problem whatsoever and nice possibilities of granulation
<Peng> You'd have to remember to commit twice for every change you make, copying and pasting the commit message or rewriting it or something.
<Peng> Now that you mention granulation, something like this would be useful, but I think doing it this way would definitely not be worth it.
<zurgutt> not necessarily, these repos would not necessarily be committed in sync, in fact in my case idea was to commit the sub often between developers and the containing folder once a day or so, for general archive of whole project.
<zurgutt> very neat and useful
<Peng> Why?
<Peng> Meh, never mind on the "Why?".
<Peng> Having a shorter summary could be useful, but going about it this way isn't right.
<zurgutt> Why?
<zurgutt> Currently this possibility has been artifically blocked, withou it giving any benefit.
<Peng> The benefit is lack of confusingness.
<Peng> FWIW, in bzr, when you merge a branch, you have to commit the merge, and you can provide a summary. "bzr log" will show the merged revisions indented.
<zurgutt> There is no confusion.  It is not the place of bzr to care what tools are used to change the source files right?  So why would it block using bzr itself?
<Peng> For one thing, that's throwing away history.
 * Peng shrugs.
<Peng> I suck at arguing.\
<Peng> I could lose an argument that water is wet.
<zurgutt> explain? its actually keeping more history it seems to me because both sub and container keep it
<zurgutt> im just trying to see the ligh, not arguing for its sake
<Peng> Sure, but why shouldn't container have it too?
<Peng> zurgutt: I didn't think you were arguing just for argument's sake.
<zurgutt> exactly, but currently it cant becaue access to sub is blocked from it
<Peng> And I should s/argue/debate/.
<Peng> zurgutt: Why do you want to have a separate sub?
<zurgutt> so currently the container loses all history and versioning of the sub
<Peng> I'd prefer container be entirely separate than have a low-fidelity copy of sub's history.
<Peng> Nested trees should solve this in some awesome way, when they're done.
<awilkins> jelmer: log from win32 test of revision 904 > http://filebin.ca/bgrfkf/log.zip
<Peng> On another subject, why does my tongue hurt?
<muffinresearch> So are nested tree not currently finished? I thought they were available from 0.15?
<zurgutt> what _are_ the nested trees? i thought what i was describing was it but apparently not
<zurgutt> could not find any definition
<Peng> Yeah, what you are describing is nested trees.
<Peng> http://bazaar-vcs.org/NestedTree
<Peng> That page also has links to two pages on what Bazaar's nested tree support will be like.
<awilkins> Do a "bzr help join" ; you may find that helpful
<Peng> Has join's help been updated to mention pack-0.92-subtree?
<jelmer> awilkins: thanks!
<awilkins> Peng: Join says "dirstate-with-subtree"
<jelmer> awilkins: I've committed a fix that should take care of the executable bit errors. This should reduce the number of failures by 18.
<muffinresearch> I see it's initial support: http://jelmer.vernstok.nl/blog/archives/164-Bazaar-and-Subversion-nested-tree-support.html
<jelmer> muffinresearch: there is by-reference nested tree support but it is experimental
<jelmer> It is probably not a good idea yet to use it in a production environment
<awilkins> jelmer: I say that ; the problems are mostly errors in the tests either down to Windows or my particular environment (I get similar results on all three of my win32 machines (XP, XP, Vista)
<awilkins> jelmer: *SAW that (your executable bit patch)
<awilkins> There are a few things like the path being double-escaped (path looks right apart from the extra backslashes)
<jelmer> awilkins: Yeah, I'm not sure yet what's causing that
<awilkins> Looks like it's in Branch
<awilkins> Or just Branch.__repr()__
<jelmer> it's not just the double escaping though
<jelmer> it should be using forward slashes
<awilkins> If it was using forward slashes, the double escaping wouldn't be a problem :-)
<jelmer> it should be using forward slashes now
<jelmer> that may also fix some other problems
 * awilkins runs tests
<jelmer> awilkins: any luck?
<awilkins> Still running
<jelmer> wow
<awilkins> Windows filesystem performance sucketh
<jelmer> it usually takes around 1000s to run the tests here
<awilkins> THe main reason git is so staggeringly fast on Linux is because i) The guy who did the silesystem code in the kernel wrote it and ii) Linux filesystem performance kicks the crap out of win32
<awilkins> Plus fork() is really slow on windows as well
<awilkins> (it not having fork() for starters)
<jelmer> what system are you on exactly?
<awilkins> And these mahcines are loaded down with a ton of evilware from IT services
<jelmer> the tests take a little less than twice as much time on your system
<awilkins> Windows XP, P4 D 3.4Ghz
<awilkins> 2GB of RAM
<awilkins> It's about the same on my desktop at home, Vsita, 2.4Ghz dual core
<jelmer> mine is a Core Duo 1.66 Ghz machine
<awilkins> http://filebin.ca/chxdoc/log.zip
 * Debolaz gave up on running git on windows.
<jelmer> awilkins: thanks. seems we've managed to fix 1 failure and 9 errors
<awilkins> Just running those logs through a diff here :-)
<Debolaz> Although it's still my main scm on *nix.
<awilkins> I do far more windows dev than *nix
<awilkins> Something that integrates nicely with SVN is also a must (git does, but I could never get it working properly)
<awilkins> I have some code in Monotone, but it's not ideal
<jelmer> awilkins: I've fixed a couple more issues
<awilkins> Did you get the one in test_convert?
<awilkins> I was just going to find it and patch it :-)
<awilkins> Another one of thse "no root on windows" paths things
<jelmer> yep, committing it now
<awilkins> My fault, by thte looks of it, half patching it in the first place.
 * abentley just got his Bazaar T-shirt in the mail
<jelmer> awilkins: ok, committed. Any chance you can run the test suite again?
<jelmer> I wonder what the "Can't find parent directory's entry while trying to add ..."
<jelmer> is being caused by
<awilkins> How do you permanently change the default pull path?
<jelmer> bzr pull --remember
<awilkins> cheers
<awilkins> Had it bound to the mirror
<igc> night all
<jelmer> g'night Ian
<jelmer> I wonder if it's possible to get launchpad to do simple redirects rather than a full mirror
<awilkins> Is that test trying to commit files to a directory that has been created but not committed to the SVN repo yet?
<awilkins> Not that that seems to cause a problem : -(
<jelmer> it's testing the bzr-svn support for working with Subversion working copies
<jelmer> that path in the error doesn't indicate any path characters being converted incorrectly
<awilkins> Is there a way to stop bzr using a proxy?
<awilkins> It appears to be using my IE proxy setttings in the absence of HTTP_PROXY variable
<awilkins> which is most annoying for repos inside the firewall
<abentley> jelmer: I doubt it's possible to get Launchpad to redirects.  Even a reference branch will get turned into a mirror, because uploads are done to a "quarrantine" area, then pulled over into the http area.
<awilkins> Freeow, never knew you could go itno an svn WC and do bzr status
<abentley> jelmer: btw, I'd be interested what you think of the Storage API I proposed.  Would it be practical to use for bzr-svn?
<awilkins> jelmer: Is going into an SVN WC and doing a "bzr status" supposed to work?
<zurgutt> awilkins: thanks for "bzr help join" tip, from help it seems to be what i want, transparent
<vila> awilkins: try setting the no_proxy env var instead ;)
<awilkins> vila: Aha, is that a common thing, or does it just affect pycurl?
<vila> pretty common, but the real solution will be to update your IE proxy settings...
<zurgutt> awilkins: i dont seem to see the dirstate-with-subtree that it needs in list of formats tho
<awilkins> zurgutt: It's hidden ; it should be there in v 1 (or 1.1)
<vila> so that you have one place to setup right
<zurgutt> tried --rich-root which makes join crash
<awilkins> My trees all seem to be in that format anyway so I guess it's the default in 1.1
<awilkins> vila: IT services have a stupid little script which fubars the proxy settings every time we log in
<vila> awilkins: ha ! Great ! I love these ones :-(
<awilkins> jelmer: Looks like that proxy was causing my Not a Branch errors
<vila> awilkins: then you must go the env var route :-/
<awilkins> Or I can stick my proxy auth details in a plain textfile in my %appdata% folder
<awilkins>  :_0
<zurgutt> is there a way to convert existing repo to new storage format?
<awilkins> bzr help upgrade
<abentley> awilkins: dirsate-with-subtree will probably never be un-hidden.
<awilkins> abentley: What's it being turned into?
<zurgutt> indeed its not in bzr help formats in 1.1
<abentley> It's a format that doesn't use packs, and we don't need another of those.
<zurgutt> why? is it usable?
<abentley> zurgutt: The format itself is fine, but the functionality it enables does not work properly.
<zurgutt> ehh.. :P
<awilkins> Does the server repository influence the format the client repository is when it pulls?
<awilkins> Because my copy of bzr-svn is in a dirstate-with-trees repo and I didn't make any effort to say so.
<awilkins> Are the features going to be written into a future packed format?
<abentley> awilkins: The formats already exist.  rich-root-packs and rich-root.
<awilkins> abentley: Excellent.... so nested-tree jsut hasn't caught up to them?
<abentley> Nested trees hasn't been under active development for almost a year.
<awilkins> jelmer: http://filebin.ca/hdpoga/log.zip
<awilkins> Scratched another 10kb off the log
<awilkins> abentley: I figured that from the "0.15" version number on the Progress page :-)
<zurgutt> weird, because there just isnt any development needed for it
<abentley> zurgutt: Nested trees is not the same thing as what you were originally asking for.
<zurgutt> ah, ok, someone said it was.
<abentley> zurgutt: And there is plenty of work remaining to be done.
<abentley> zurgutt: You wanted one file to be part of two trees.  That's not supported and is unlikely to be supported.  Nested trees allows whole trees to be contained as part of other trees, so that you can split a large project into pieces.
 * awilkins cackles, rubs his hand toghether, and puts bzrsvn through the torture of mirroring a 13,000 revision repository with about 1.5 GB of data in it. Bwahahahaa!
<zurgutt> i tried my setup with "bzr init --rich-root-pack" and "bzr join subsite --reference" in container, which goes ok but after it "bzr add" in container will make it crash. suppose it should be reported?
<awilkins> Reporting bugs is a contribution to a feature as much as anything else, but I suspect that unless one of the developers need his itch scratching it isn't getting fixed.
<awilkins> Which is a shame because I'd like to see it working too :-)
<awilkins> My Python is as yet undeveloped
<awilkins> jelmer: Well, it ate 13,000 revisions worth of history without too many troubles, now let's see what it does with the actual data ;-)
<abentley> zurgutt: Yeah, that should be reported.  "bzr join subsite --reference" should not work at all in a rich-root-pack tree.
<jelmer> awilkins: woot
<abentley> You need "dirstate-with-subtree" or "pack-0.92-subtree" for that to work.
<jelmer> awilkins: thanks for the new log
<abentley> And as I've already said, the --reference functionality doesn't work properly anyhow.
<jelmer> whoops, looks like I missed a few lines in my backlog
<jelmer> abentley: I haven't looked at the Storage API yet - where can I find it?
<jelmer> awilkins: yes, bzr status in a workign copy should work
<abentley> http://bundlebuggy.aaronbentley.com/request/%3C479CF3D8.1090907@aaronbentley.com%3E
<jelmer> abentley: thanks!
<jelmer> abentley: It seems a little bit too low-level for the Subversion protocols
<abentley> Can you give me an example?
<jelmer> So, the way you retrieve the contents of a revision is to ask the subversion server for an update between revision X and Y
<jelmer> (where X can be 0 for a new checkout)
<jelmer> and you specify a CommitEditor object which functions get called for all of the changes
<jelmer> on the protocol level, the server sends a series of commands
<jelmer> "open root", "create directory", "create file", "change property", "apply delta to file"
<awilkins> Those things would make a nice addition.
<awilkins> Being able to ask for deltas (although rather overkill for local storage)
<jelmer> afaik the fsfs backend does use a per-revision blob but that's only in their storage layer, not exposed
<abentley> awilkins: A nice addition to the Storage API?
<jelmer> abentley: The storage layer could be useful to support local Subversion backends without relying on the Subversion libraries, but I'm not sure I want to go there...
<zurgutt> abentley: reported it. One more question and then ill be done for today:)  Situation: one root dir has 2 subdirs that belong to project A and another 2 which belong to project B - how(if) is it possible to create one branch to both projects? Container can just have one branch i think.
<ubotu> New bug: #188954 in bzr "add after join --reference crashes" [Undecided,New] https://launchpad.net/bugs/188954
<abentley> jelmer: So if you left out iter_raw_items, and just implemented iter_byte_streams, would that work?
<jelmer> abentley: Only if I would reimplement the Subversion protocols rather than rely on the Subversion libraries
<abentley> jelmer: So does bzr-svn implement iter_files_bytes?
<jelmer> abentley: not at the moment. It could, but such an implementation wouldn't be very efficient
<abentley> zurgutt: I wouldn't recommend using one branch for two projects.
<jelmer> abentley: You can only obtain deltas or fulltexts for a complete tree rather than per file.
<zurgutt> abentley: one branch per project was the idea, problem being that project does not have single container dir, there is several under one
<jelmer> abentley: Supporting a Storage object in general (or perhaps a subclass of Repository that uses bytestreams?) makes sense to me though
<abentley> jelmer: So how does bzr-svn construct a workingtree?
<jelmer> abentley: a native svn one? It just calls out to the Subversion client library to do that
<jelmer> abentley: a bzr one is created by simply calling out to bzr
<abentley> jelmer: But transform.build_tree uses iter_files_bytes, so bzr-svn must be enabling it somehow.
<jelmer> abentley: in which code path should it be using that?
<jelmer> abentley: revert and merge are not supported in subversion working copies
<jelmer> because inventory deltas are hard to apply
<zurgutt> can bzr be made to work through symlinks?
<abentley> For the scenario of creating a Bazaar checkout from a Subversion branch.  build_tree is used by WorkingTreeFormat.__initialize__, IIRC.
<jelmer> abentley: We never use a Bazaar WorkingTree with a Subversion Branch
<jelmer> Subversion WorkingTree with Bazaar branch
<jelmer> sorry
<jelmer> we support Subversion WorkingTree with Subversion branch and Bazaar WorkingTree with Bazaar Branch
<jelmer> there's no way to construct a bzr wt with a svn branch afaik
<zurgutt> bzr add from symlinked dir also crashes :|
<zurgutt> is there any documentation for configmanager?
<awilkins> http://www.robertcollins.net/config-manager/trunk/HOWTO
<zurgutt> nothing about usage there, nothing about bzr and very scant info on config file. have you used it, got examples?
<zurgutt> i was figuring i could symlink the dirs i want in one repo into some outside dir and invoke bzr there but that does not work either :|
<CardinalFang> Hi all.  I'm interested in the (relatively obscure so far) per-file commit messages, and how I can add the functionality to the built-in text-editor commit.  I think I have a good way of encoding it so it's obvious and minimally disruptive.  I have two questions, though:
<CardinalFang> 1) The text "This line and the following will be ignored" will no longer quite be true.  I think putting the messages inline with the "status" output would be best.  I'd rather have a message that is true for everyone regardless of whether they're ever using per-file-messages or not, and not conditional, and not confusing.  Any suggestions?
<CardinalFang> 1b) Also keep in mind that there may be a "diff" at the end, which should not be touched.
<CardinalFang> (I realize that I used "message" to mean two different things in that question.  One, warn people not to edit some parts.  Two, what the user inserts.
<CardinalFang> 2) There appears to be a de facto design of two-parts in the text file.  A place for the user to type, delimiter, read-only stuff.  Does anyone know of anything that could break if I extend it to be:  A place for the user to type, delimiter, structured user-editable area, delimiter, read-only area ?
<CardinalFang> There are a few parameters in functions in  bzrlib/msgeditor.py  that make it extensible, but seem to enforce the idea of two parts.
<abentley> CardinalFang: bzr send can also use the msgeditor functionality, so it could break if you change the API.  Generally, you should avoid changing the API in incompatible ways.
<pcc1> anyone here know about bzr-builddeb? is leaving the .bzr-builddeb/default.conf file in the diff.gz intentional? thanks
<jelmer> pcc1: Yes, that is intentional
<piem> hi. why is 'bzr bd' sticking .bzr-builddeb/default.conf in the .diff.gz?
<jelmer> it's part of the bzr branch
<pcc1> jelmer: is this congruent with any policy?
<piem> the builddeb conf has nothing to do in the .diff.gz. there is a 'def remove_bzrbuilddeb_dir', but i'm not sure it's being called in merge mode
<jelmer> pcc1: not sure
<jelmer> feel free to file a bug about it
<jelmer> afaik it hasn't been discussed before
<pcc1> is launchpad the canonical (no pun intended) place to report bugs?
<Peng> Bzr uses Launchpad for its bug tracker, yes.
<dato> pcc1: bzr or bzr-builddeb?
<pcc1> bzr-builddeb
<dato> pcc1: then I'd use debian's bts, the author is pretty active there
<dato> (and I'm not sure there is a bzr-builddeb launchpad product)
<dato> (and I could be wrong, of course)
<pcc1> dato: https://launchpad.net/bzr-builddeb but both have only 5 or 6 bugs reported
<dato> ok, then your pick :)
<Peng> Yay, I can pull dirstate-tags into dirstate.
<AnMaster> Peng, hum?
<AnMaster> why do you want plain dirstate?
<Peng> Upstream is plain dirstate.
<AnMaster> anyway isn't the new format "pack-0.92" or something like that iirc?
<Peng> Yes.
<AnMaster> or is that repo, and dirstate* is for branches?
<Peng> Well, there's only one name. pack-0.92 uses the same branch format as dirstate-tags.
<AnMaster> ah
<Peng> I mean, you only pass one overall name to bzr upgrade or whatever.
 * AnMaster uses pack-0.92 for his projects
<AnMaster> anyway I do use tags quite a bit
<Peng> Well, I use the same format as upstream does.
<Peng> I'd use packs and tags too, but..
<AnMaster> packs? isn't it just an internal data format?
<Peng> Yeah..
<Peng> The upstream developer uses dirstate and doesn't use tags, so I'm not going to either.
 * Peng wanders off.
<kjcole> Today's silly question: On a Mac, given the line-end issue, is there any plugin, patch, branch or other intelligent way to view diffs?
<kjcole> (was hoping qbzr would handle such things a bit better, although the fix to handle such I expect to be elsewhere.)
<mwhudson> kjcole: you still have files with \r line endings?
<kjcole> mwhudson: Yep, and when I mess with that, it interferes with the program that interprets the scripts.
<mwhudson> wow
<mwhudson> i think bzrtools adds a --using parameter to the diff command
<mwhudson> so if you have a \r-friendly diff tool, you can use that
<dato> mwhudson: it's in core now
<dato> (since 1.1)
<kjcole> I'll check that out. (I'm a Linux guy, not enough of a Mac guy.  The program in question is PsyScope, written for OS 9 (apparently) but modified enough to run natively in OS X.
<mwhudson> well, i'm slightly a mac guy, and i haven't seen a \r line ending file in years :)
<dato> mwhudson: it's in core now
<kjcole> The issue may only be that tweaking the file removes the FileInfo, which I then manually have to set with SetFile.  If I don't PsyScope chokes.)
<mwhudson> dato: heard you first time :)
<kjcole> It insists on wanting type = "TEXT", though I don't know if it cares at all about creator = "tach".  In any case, it seems silly to change line endings just for a pretty compare.  I'll look into alternate diff apps.
<dato> mwhudson: irc proxy hiccup, sorry
<mwhudson> ah hah
<Peng> Ok, done converting dirstate-tags -> dirstate, but I still have inconsistent and sucky parent references.
<igc> morning
<ubotu> New bug: #162496 in bzr-svn "bzr svn advertising still a little common" [Low,Fix committed] https://launchpad.net/bugs/162496
<Peng> Oh yay, only one inconsistent parent.
<Peng> Ooh, the bzr+http path issue fix needs a post-1.1 client.
<Peng> Unless the server magically broke.
<Skinkie> hi there... is GIT pulling now supported or not?
<ubotu> New bug: #174690 in bzr-svn ""pull" should handle removal of bzr:ancestry property" [Low,Triaged] https://launchpad.net/bugs/174690
<spiv> poolie: https://bugs.edge.launchpad.net/bzr/+bug/185394 is that critical bug
<ubotu> Launchpad bug 185394 in bzr "Generic bzr smart protocol error: bad request '232' when connecting to bzr 1.0 smart server" [Critical,In progress]
<mahmoud_> Why Bazaar changes the default directory that Windows Command Prompt opens on ?!
<rolly> It doesn't do that for me..
<mahmoud_> rolly : It does that under vista for me
<rolly> Windows XP here
 * rolly tries shell-hooks in the hopes of versioning his DB schema
#bzr 2008-02-05
<lifeless_> working adsl FTW
<Zectbumo> Are there instructions on how to add bzr to the SCM in XCode?
<poolie> spiv, thanks for your mail to sg
<poolie> Zectbumo, not that i know of
<poolie> i believe there are some people who do use it there though
<poolie> a post to the list may shake them out
<Zectbumo> where is the list?
<poolie> bazaar@lists.ubuntu.com
<poolie> or you could post where you're got up to in adding it
<Zectbumo> thanks poolie, I'll try that
<jml> lifeless: I would like to know more of this 'working adsl' of which you speak.
<lifeless> the electrons move
<lifeless> from node to node
<lifeless> on wires copper
<poolie> like autumn leaves
<Zectbumo> in the summer time
<lifeless> igc: ping
<lifeless> the living is easy
<igc> hi lifeless
<lifeless> igc: do you want to talk about this plugin stuff
<lifeless> igc: or just rapid fire emails ?
<igc> as in auto-loading of plugins?
<igc> I'm yet to look at it to be honest
<lifeless> as in I b:rejected your patch - you may not have seen that
<igc> ah - no I hadn't seen that
 * igc looks
<poolie> lifeless, are you in need of relief from skull drills?
<lifeless> poolie: no drilling so far today
<lifeless> poolie: if it starts up I'll ring you and run for a train
<lifeless> igc: you seem to be reimplementing bzr 0.8's hook system, which is sad.
<lifeless> igc: so I'd like to understand what you want to achieve, and hopefully suggest a smaller way to do it.
<igc> lifeless: fire away
<lifeless> uhm, you're the one with a mission in this area:) how about you describe what you want to achieve
<igc> lifeless: I want an easy, scalable way of configuring command line scripts as hooks ...
<igc> a few people have rejected Bazaar for Hg on this feature alone
<lifeless> igc: Ok. I think this is a rather restrictive and difficult to work with medium, so don't want our core to get cluttered; we can do this entirely as a plugin.
<igc> I don't care a lot about the Python hooks stuff because we support that already
<lifeless> theres a /lot/ of friction between object-model and command line
<lifeless> and requiring that every object model hook be command line exposed - urgk. Not to mention locking coherency and performance.
<lifeless> and windows.
 * Toksyury1l wonders absently if there are any plans to rewrite bzr in a compiled language someday in the future
<lifeless> Toksyuryel: python can be compiled FWIW :)
<igc> ok - so we can make it selective as to which hooks can exposed if you wish
<lifeless> Toksyuryel: but more seriously we have rewritten the inner loops in C already
<Toksyuryel> oh, sweet ^^
<igc> s/can/get/
<lifeless> Toksyuryel: (Not all inner loops, but selected critical ones)
<lifeless> spiv: you seem to put success/failure before body content in replies; this doesn't work in the general case
 * Toksyuryel nods "well it is nice to know that it's even being attempted ^_^ bazaar is a great system, and I think being available in a version with far less overhead would get a lot more people interested in using it :)"
<spiv> lifeless: chunked replies can be interrupted with an error
<mwhudson> python is already a compiled language
<mwhudson> but this isn't a helpful response :)
<lifeless> spiv: smells like duplication to me
<lifeless> spiv: I would be strongly inclined to have [BODY] STATUS
<spiv> So most errors would tend to always have no body, then the error status?
<spiv> That seems reasonable.
<lifeless> well the idea I have is that pure errors have no body
<Toksyuryel> my understanding is that compiling python would still lag behind something like C, and could potential introduce strange compile-time errors that interperted python wouldn't experience
<lifeless> HTTP's 'errors are html pages' is nasty
 * Toksyuryel could be wrong about this
<spiv> Right, I agree.
<spiv> I was just referring to the case where an error doesn't occur until the body has already begun.
<spiv> That does sound like a good simplification to me, thanks.
<foom> except in the case of http 1.0 indeterminate length replies, you can just treat a connection which closes unexpectedly as an error.
<lifeless> igc: reviewing your patches now
<lifeless> igc: I get the impression that you are cloning hg's style here or something, but it has a smell about it that is quite un-bzr-like.
<lifeless> igc: I appreciate that some folk may say 'we have to have shell hooks' - but lets not copy an inferior system to give them their feature.
<lifeless> (if hg was superior, we wouldn't be hacking on bzr ;))
<igc> thanks lifeless. The design is meant to be better than Hg's fwiw :-)
<igc> and it is
<igc> (not saying it can't be better though)
<lifeless> Right now I have a pretty strong conviction that this all belongs in a plugin
<lifeless> the shell command wrapper stuff is probably good to put in the core once the code duplication is removed
<lifeless> oh, I missed another spot of duplication, the unit test support for running real sub processes.
<lifeless> the config stuff made me wince; I've replied to it
<lifeless> but only comment because I may be being conservative
<lifeless> igc: right the main one I've looked closely at as well. I think you got the wrong end of the problem and pulled the thread there
<lifeless> igc: if you instead start with adapting a config driven shell interface into the existing hook structure, with no changes to the current api (it doesn't need any) I think you'll find it works a /lot/ better and more smoothly.
<lifeless> (And yes, I do mean start over on the third patch - sorry)
 * igc digests that
<lifeless> hint: If shell hooks are configured in *Config, then *Config knows the hook exists and should register it
<lifeless> the current precommit hook also has a performance problem
<lifeless> its recreating the work of the commit by calling changes_from
<lifeless> anyhow, I need caffeine apparently, so I'll be back in a few minutes; I'm very happy to have a voice call if you think more bandwidth will help
<lifeless> igc: you have mail; I'm not arguing against having shell scripts, I'm arguing against an implementation that is problematic (and makes changes to core it should not)
<igc> lifeless: understood
<igc> I'm ok with going back to [] instead of init_hook
<igc> the tricky bit I don't see ...
<igc> is how your auto-register approach can work when the set of hooks ...
<igc> is dependent on the *branch*
<igc> That's the important api change ...
<igc> get_hooks[hook_name, branch) instead of hooks[hook_name]
<lifeless> igc: when the branch reads its config file it can add hooks, can it not ? And clean them up when unlock() drops the lock count to 0.
<lifeless> igc: -> no api change needed :]
 * igc thinks
<lifeless> Branch.hooks is branch independent, its global.
<igc> sounds ok (which is great)
<lifeless> We can *either* make it branch specific, which has some possible benefits, but some downsides as well.
<lifeless> OR we can do what I just described, which will also work well.
<igc> lifeless: I'd probably prefer making it branch specific but ...
<igc> I'll try the other way if you'd prefer
<igc> as long as locations.conf overrides branch.conf ...
<igc> I'm happy enough
<lifeless> igc: I am not wedded to it being global (well, more precisely, Branch.hooks must stay global, but you could clone the current global hooks with a deep copy to aBranch.hooks, which is then local and can be tweaked by the branch. But I think thats a mistake due to interactions with bound branches, which is why I think singleton is better in the first place.
<igc> ok - let me get the run-shell-command patch resubmitted and I'll go with your 'stay global' approach
<igc> lifeless: thanks for the reivews btw - much appreciated
<lifeless> np
<lifeless> abentley: ping
<abentley> lifeless: pong
<lifeless> abentley: is there a trivial method to apply an inventory delta to a tree: to actually do the tree rearrangements requested
<abentley> Yes, WorkingTree.apply_inventory_delta
<lifeless> abentley: that only alters the inventory
<lifeless> abentley: I want to shuffle directories on disk; write file content out to new files and symlinks etc.
<abentley> True, but that's all the inventory delta was meant to describe.
<lifeless> abentley: I know. the use case is 'I have a partially committed tree - all the content is in but not the revision id.' Now I want to extract this to disk. Hmm, perhaps export will do it
<abentley> I think the best option would be to convert it to _iter_changes format, which revert uses.
<jml> what's the eta on the RC?
<lifeless> abentley: no need, export() will work just fine
<lifeless> I brain farted for a second :)
<abentley> lifeless: So I've got an implementation of iter_files_bytes that reads each pack only once.
<abentley> Now 50% of the time is spent reading the index to determine the build-dependencies.
<lifeless> abentley: cool; I guess that means its faster ?
<abentley> Yes, it's faster for the checkout-from branch case when there's no accelerator tree.
<abentley> But it's about half the speed of checkout using an accelerator tree.
<abentley> So I'm looking for ways to reduce the cost of index lookups.
<abentley> Any ideas?
<lifeless> paste your index using code
<lifeless> but in general: less trips to the index layer - better. And we need to do the next iteration of the index layer too - I have a half prepped branch working on that
<abentley> http://paste.ubuntu-nl.org/54807/
<lifeless> abentley: its pretty dense; I guess thats doing inventory and text in a single pass ?
<lifeless> abentley: or is it because its part of the refactored knit layer, which inventory and revision still use ?
<lifeless> not saying its bad btw
<abentley> Yes, knit_kind can be "file", "inventory", "revision", "signature".
<lifeless> k. I'm a little confused as to what streams are, I suggst a comment or something
<abentley> stream_id would be a better name; they are tuples of (file_id, version_id)
<lifeless> thats a component isn't it ?
<lifeless> so I would say component_key
<lifeless> 'the name of a component'
<abentley> Well, they are actually the names of the desired streams, i.e. fulltexts.
<lifeless> fulltext_keys perhaps ?
<lifeless> I use key fairly consistently elsewhere when talking about a tuple of ids
<abentley> Could work.
<lifeless> trivial note: while pending_versions: is faster than whiel(len(pending_versions) > 0: and IMO just as readable
<abentley> There's currently a lot of pointless conversion between various tuple formats, so I'm not sure exactly what the inputs will be when I'm done.
<lifeless> one thing you could do to reduce overhead
<lifeless> make pending_versions a set of the native keys
<lifeless> that will reduce conversions
<lifeless> if you had per-kind build_maps that would do it. But maybe that doesn't fit further out
<lifeless> another alternative would be (kind, key) tuples
<lifeless> where key is (revision_id,) or (file_id, revision_id)
<lifeless> less conversion - just wrapping
<lifeless> one suggestion here - move requirements,update(new_requirements) out of the inner loop
<lifeless> instead, when you do pending_versions = new_pending
<lifeless> also do requirements.update(new_pending)
<lifeless> but otherwise that seems fine - you spider out nicely
<abentley> The output is expected as (kind, file_id, revision_id), so it seemed simplest to retain that format.
<lifeless> so I suspect you'll be payin bisect() costs in index.py
<lifeless> thats something that is possibly optimisable without changing the disk format.
<abentley> But your (kind, key) notion is interesting.
<abentley> I see what you mean about requirements.update().
<lifeless> sets are fast its unlikely to be a problem, but little bits add up :)
<abentley> I'll probably see how iter_all_entries performs, but it's questionable to use that IRL.
<lifeless> iter_all_entries skips the bisection
<lifeless> and I know the bisection to be a problem
<abentley> Would stink rather badly for many cases, though.
<abentley> Yeah, looks like ~all of the iter_entries time is spent in the bisect code.
<lifeless> feel free to improve it :) but your current patch is orthogonal I think
 * igc food
<lifeless> you won't be slower than the current code
<abentley> lifeless: This would probably require me to have more than a superficial understanding of bisection...
<lifeless> abentley: fair enough ;)
<lifeless> abentley: I can describe the theory in an email if the code is too obtuse
<abentley> lifeless: The bisect code is slow, but iter_all_entries is slower.
<lifeless> abentley: what project? bzr?
<abentley> Yes, doing a checkout of Bazaar takes 8 seconds with iter_all_entries, and 5 with iter_entries.
<lifeless> heh
<lifeless> so, thats size_history issue showing up:)
<lifeless> a project with less deep history might see a different ratio
<lifeless> something like mozilla iter_entries will be faster ;)
<fullermd> We don't have a way of storing arbitrary metadata on revisions, right?
<bob2> how does --fixes do it?
<fullermd> I thought it had a particular field.
<abentley> lifeless: Especially mozilla with only one commit
<lifeless> fullermd: we do, its abused
<lifeless> I regret us adding it :(
<lifeless> abentley: well moz with one commit, iter_all will be fasster
<lifeless> abentley: moz with all its commits, iter_entries will be faster
<fullermd> Oh, we do?  Hm.
<abentley> Oh, gotcha.
<fullermd> I thought the whole point of such things was to abuse them   :)
 * lifeless abuses fullermd
<fullermd> Whip me.  Beat me.  Make me maintain AIX.
<lifeless> now thats cruelty
<abentley> Ah, but if we made him rewrite AIX in Perl...
<fullermd> I could rewrite it in APL, and it'd probably be more comprehensible than the original...
<abentley> Plus you could use the insanity defence if you happened to go on a killing spree afterward.
<fullermd> Did I mention that my first sysadmin job was on AIX?
 * fullermd loads another magazine.
<fullermd> Anyway, some damn fool opened up Yet Another VCS Thread on $MAILING_LIST, and it got me thinking about the question "How do I find foo/bar/baz.c r1.1384.1.7 post-conversion".
<fullermd> Seems like stashing in random-metadata-slot at conversion time is the least evil answer.
<lifeless> fullermd: that can be one in the revision properties list, but it makes the revision object rather large :|
<abentley> fullermd: if we're talking about CVS, we don't have to worry about renames, so we can use the filenames as file_ids.
<abentley> You could use r1.1384.1.7 as part of the revision-id.
<lifeless> abentley: N files in a commit though
<fullermd> Urg.  That would be Really Ugly(tm) when you have a few dozen files in a commit...
<abentley> Okay, clearly I haven't given this enough thought.
<fullermd> Of course not.  It involves CVS.  Your mind shunts itself aside in self-defense.
<abentley> Though it could be argued that CVS has only one file in each commit...
<fullermd> Well, yeah.  But converting it that way would be a good way to ensure no project ever gets far enough to ask bzr the question...
<igc> bbiab
<abentley> lifeless: Okay, I looked at the bisect_multi_bytes code and it kinda made sense.  What's wrong with it?
<lifeless> abentley: its slow
<lifeless> so there are two separate sets of bisection occuring
<abentley> But the algorithm is suitable?
<lifeless> abentley: one is down at the disk level where we are finding the location of the key and reading its data (and data adjacent to it).
<lifeless> abentley: this bisection is completely fine AFAICT, reading the right data, and not slow.
<lifeless> abentley: the second set of bisection is occuring in memory
<lifeless> where we have a list of ranges that have been parsed
<lifeless> in a file like |-----------------------------|
<lifeless> we mark the bits we've parsed:
<lifeless> |+++----------+++-----+++--+--+++-------|
<lifeless> (for instance) - thats a file after looking up one key 2/3's up the file or so
<lifeless> --lsprof suggests that we're examining that map or parsed regions expensively
<lifeless> it may be that the map needs to be represented in memory in some better fashion
<lifeless> or just that the way bisect is used/how the results pan out can be improved
<abentley> One option that might improve performance is if we can turn it into a coroutine.
<abentley> Because I suspect it's got keys cached that we need to find on the next lookup.
<abentley> Even if not, the position data could be quite useful, I'd expect.
<lifeless> if by key you mean the (file_id, revision_id) tuple stuff - thats should not trigger a lookup in the parsed regions, unless the key is not fully parsed
<lifeless> remember that a key on disk is [key, present_flag, references(pointers), byte_value]
<lifeless> so if I read the content for key X, I need to issue a second readv request to resolve its references into strings
<abentley> I mean that when I'm building a list of dependencies, I have to call GraphIndex.iter_entries() multiple times.
<lifeless> right
<abentley> And I assume there's no caching.
<lifeless> there is caching
<lifeless> iter_entries is slow because of the in memory data structure that represents what parts of the file we have parsed
<abentley> Where is the caching?
<abentley> self.bisect_nodes?
<lifeless> self._nodes_by_reference is part of it
<lifeless> sorry
<lifeless> _keys_by_offset
<lifeless> that maps a pointer to a parsed key
<lifeless> self._parsed_key_map is the bitmap of the parts of the file we have cached
<abentley> Hmm.  Would we want some kind of tree structure?
<lifeless> I don't know :). I'm paging this in as we speak.
<lifeless> mainly I want to ensure you see the bit that is a problem (in memory data structure) vs the bit that is ok (the actual IO's we perform)
<lifeless> it may be the structure is ok but we don't use it well
<lifeless> or it may be that the structure is not ok
<abentley> I do see that.
<lifeless> cool
 * abentley is off to sleep
<lifeless> night
<mrevell> Hello bzrrrrr!
<poolie> hello matthew
<bob2> "bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: file u'/etc/resolv.conf' entered as kind 'file' id 'resolv.conf-20071108133634-j0pcs1k03mehwsbd-106', now of kind 'symlink'"
<bob2> what's the rationale for having an error for that instead of just versioning the change?
<ubotu> New bug: #189182 in bzr-hg "unexpected keyword argument 'find_ghosts' in hg-0.9.5" [Undecided,New] https://launchpad.net/bugs/189182
<poolie> bob2, you shouldn't be seeing that, we're meant to fix it at another level
<poolie> unless you're using a very old bzr?
<lifeless> gotta be old bzr I would have though
<xinity_mbp> hy all
<xinity_mbp> anyone may help, i have bazaar installed on my laptop and my desktop , i'm tried to push the repo i have on my laptop into my desktop bazaar repo using bzr+ssh command but i fail, any clues ?
<rolly> .bzr.log is a good place to look for clues
<xinity_mbp> on both sides rolly ?
<rolly> on the remote side, sure. If you are successfully establishing an ssh connection
<xinity_mbp> let's see if this file exists ;)
<rolly> "but i fail" doesn't say much about your problem, so I can't say
<xinity_mbp> the ssh connection succeed, but the bzr smart server says something about permissions
<xinity_mbp> bzr push bzr+ssh://username@myhostname/Projet, error : Generic bzr smart protocol error: Permission denied: "/Projet": [Errno 13] Permission denied: '/Projet'
<xinity_mbp> the Projet dir is in my home on the desktop
<xinity_mbp> and when i take a look at the /var/log/secure, i can see, the successfull ssh connection
<weigon> xinity_mbp: /Project is to the root of your filesystem, you logging in as root ?
<xinity_mbp> nop weigon
<xinity_mbp> the Projet dir is in ~username dir
<xinity_mbp> wich means ~username/Projet
<xinity_mbp> i found this on .bzr.log
<weigon> the "permission denied" smells like it tries to access /Projet instead of ~username/Project
<rolly> you need to put the full path in there
<rolly> bzr+ssh://username@myhostname/home/username/Projet or whatever it may be
<xinity_mbp> http://cl1p.net/xinity_bzr/
<xinity_mbp> ah better now :)
<rolly> I love bzr, even when it crashes :D It's so easy to tell what's wrong
<yacc> rolly: you love in practice Python. Most Python programs show this attribute: "Easy to debug" ;)
<rolly> yeah it's true
<xinity_mbp> seems to be working , here is my last log :
<rolly> I have 0 python experience and I was able to patch a bzr module
<yacc> rolly: And now you need to be a selfemployed contractor for Germans biggest mail portal, and you can charge premium prices for patching (complex and hard Python)  modules without understanding them :-P
<rolly> Well, I can certainly provide the lack of understanding
<yacc> Oh, sorry, was an complete non appropiate assocation that I had.
<yacc> But this guy managed to sit around for more than 2 months, and providing exactly 3 1-line changes replacing constants, as a contractor. That's upmanship.
<rolly> those must have been some pretty important 3 lines :p
<rolly> (for him to charge premium)
<spiv> xinity_mbp: I think a newer client version would have reported that error properly.
<rolly> anyways, past my bedtime. Goodnight all
<spiv> (or perhaps a newer client *and* server version)
<xinity_mbp> Using fetch logic to copy between RemoteRepository(bzr+ssh://xinity@myhostname/home/xinity/Projet/.bzr/)(remote) and KnitPackRepository('file:///Volumes/Home/Users/xinity/Documents/Exploitation/Projet/.bzr/repository/')
<xinity_mbp> here is the last log i have
<xinity_mbp> ok seems to be working, a last thing i didn't catch
<xinity_mbp> bzr branch Exploitation bzr+ssh://xinity@myhostname/home/xinity/Projet/Exploitation send the .bzr dir , but not all the files, did i missed something ?
<spiv> That's expected.  "bzr branch" only builds working trees for local branches.
<spiv> But if you're just sharing the branch with other people, that doesn't matter.  You can "bzr branch" and so on with just the .bzr directory.
<xinity_mbp> ok so how to pull the whole tree to the remote instance ?
<cvv> dato:Hi!
<dato> yes?
<cvv> I try to use you VimEditorIntegration plugin and found out then they do not work on Vim 7.1
<dato> cvv: showing the diff no longer works with recent bzrs. maybe you want to try `bzr ci --show-diff`
<cvv> What do you mean? bzr diff work perfectly in bzr 1.0
<dato> cvv: what does not work for you in 7.1?
<cvv> I do not see diff. in both panel same text but `bzr diff` tell about more differencies
<dato> cvv: try running `bzr commit --show-diff`
<cvv> bzr: ERROR: no such option: --show-diff
<dato> ok
<dato> then it's not that
<dato> well
<dato> er, probably is
<cvv> I never use option --show-diff in past
<dato> it's a bit new
<Qhestion> dato: "bzr diff"
<dato> cvv: so, if you do `bzr commit`, and the editor starts, and you go to another terminal, and you do `bzr diff` there, do you get an error about the repository being locked?
<Qhestion> dato: you should not.
<dato> Qhestion: of course you should
<Qhestion> no.
<Qhestion> diff is a readonly task, commit is a readwrite task.
<Qhestion> but there is a handling for that
<dato> Qhestion: sorry, but the facts support me
<dato> (unless the behavior was changed in bzr.dev in the last two days)
<Qhestion> ok right
<dato> you can't diff while committing
<Qhestion> ok you are right.
<cvv> bzr diff
<cvv> bzr: ERROR: Could not acquire lock [Errno 11] Resource temporarily unavailable
<dato> cvv: right. you need bzr 0.91 or newer to be able to see the diff in the editor, I'm afraid.
<Coke> I just commited files, where were they commited to? Is everything contained in the same project directory?
<spiv> Coke: try "bzr info"
<cvv> Ok. I at now will be upgrade to bzr-1.0
<Coke> spiv: so everything is a branch?
<spiv> Coke: I'm not sure what you mean by "everything" :)
<Coke> spiv: every repository
<spiv> No, in bzr we use "repository" to mean something different to a "branch".
<Coke> spiv: what would be considered a "local copy"
<spiv> A repository is where the revisions of one or more branches are stored.
<spiv> (Often a repository is co-located with a branch, and so holds just data for that branch)
<Coke> spiv: ah, if we are several networked developers working on the same project we have a central repository and we each have our own private branch?
<dato> cvv: good. in that case, you just use `bzr commit --show-diff`
<spiv> Well, it's usually easiest to ignore repostories.
<Coke> spiv: good.
<spiv> The things you work with are branches most of the time.
<spiv> (Or perhaps a checkout of a branch)
<Coke> spiv: so, each developer has a branch and then there's a branch at our project server too?
<spiv> So when you do "bzr commit" it creates a new revision on that branch.
<spiv> You can work like that.  You can also have just one branch, and have each developer just have a checkout of that branch.
<spiv> (i.e. very similar to how you'd use SVN or CVS)
<Coke> spiv: ok. what's the difference between a checkout and a branch?
<spiv> A checkout is also called a "working tree".
<spiv> So it's the files on disk that you work with.
<spiv> A branch is a line of development.  A series of revisions.
<Coke> spiv: ok, then I guess it works sort of the same way like SVN in that respect
<xinity_mbp> my oh my i'm lost :(
<spiv> So if you have a checkout of a branch, and someone else commits to the branch, then your checkout would be out-of-date.
<spiv> So you wouldn't be able to commit to that branch with that checkout until you did a "bzr update".
<Coke> Argh! There's no bash autocompletion for bzr yet!
<Coke> spiv: ah, just tested checking out. ok. it's very similar to cvs
<spiv> (Although you would still be able to make "local commits")
<spiv> If you're coming from cvs or svn, using checkouts is a pretty good way to ease into bzr.
<spiv> Most people using bazaar get addicted to making branches though :)
<Coke> spiv: yes. it does seem tempting.
<spiv> Often a good way of working is to make a new branch for every distinct feature you're developing.
<Coke> spiv: different thinking
<Coke> spiv: branching and merging is a pain in the ass with CVS and SVN
<spiv> Exactly.
<xinity_mbp> sounds weird , i followed the pdf doc to build a central repo
<xinity_mbp> when i do a bzr ls bzr+ssh.... it shows a list of files
<xinity_mbp> but when i connect remotely, i can't see those files
<Coke> spiv: if I work on my branch and change files, can I revert or is the branch "hot"?
<Odd_Bloke> xinity_mbp: 'bzr ls' lists files that are versioned, not what is actually on the filesystem.
<Coke> spiv: lemme rephrase that. :) are the changes stored in each branch?
<spiv> Coke: yes, each branch keeps a full history
<poolie_> this is very confusing for xchat having someone else called mbp :)
<Coke> spiv: so I can relax and work on my branch (which happens to be the branch root location) and not worry about not being able to revert certain changes?
<spiv> Coke: if you have the bzr-gtk plugin installed, "bzr viz" does a great job of showing you the history in a pretty way
<Coke> spiv: I hate pretty!
<Coke> :)
<xinity_mbp> Odd_Bloke: how to send those files to the remote repo ?
<spiv> xinity_mbp: you could install the "push-and-update" plugin
<xinity_mbp> spiv: let's try then ;)
<spiv> Coke: I don't quite understand your concern.  Perhaps you should clarify what you mean by "revert"?
<spiv> Coke: There's a "bzr revert" command, but I'm not sure if has the same meaning as what you want or not.
<Coke> spiv: I edit file and save, oops! made a mistake, can't remember what I've changed, go back to last commited revision
<Coke> spiv: no, more like "revert" in the english sense
<Coke> spiv: in svn I'd just remove the changed file and run svn update
<spiv> "bzr revert the_file" will revert it to the last committed revision.
<Coke> spiv: is it doable for the entire branch, including subdirectories?
<spiv> (and "bzr revert" will revert the entire working tree)
<Coke> spiv: ah
<Coke> Well... I'm all good now.
<Odd_Bloke> xinity_mbp: The files are already there, in version control.  The only reason they aren't on the filesystem is that they haven't been checked out.
<Coke> There's just one more thing, where can I get free project hosting that use bzr instead of svn?
<spiv> Coke: revert changes the working tree, not the branch, btw.
<Odd_Bloke> Coke: Launchpad.
<Coke> spiv: my branch is my working tree. :)
<xinity_mbp> Odd_Bloke: sorry for my noob attitude , should i do a checkout on the remote side ?
<Odd_Bloke> xinity_mbp: Yeah.  That's what the push-and-update plugin does for you. :)
<Coke> Odd_Bloke: thanks.
<xinity_mbp> Odd_Bloke: cool ;)
<Coke> Odd_Bloke: I don't get it, is that an URL?
<Coke> ah, .net, of course. It's a network, not an .org.
<luks> Coke: you can host bzr branches on anything that supports sftp and http
<Odd_Bloke> Coke: Your branch and your working tree are conceptually different.  The branch is to do with history, whereas your working tree is just whatever files happen to be in the directory you're using bzr to manage.
<luks> (or ssh)
<Coke> luks: that's what I will do with the projects at work, but I have a few things hosted on SF.net
<Coke> luks: want to switch
<xinity_mbp> Odd_Bloke: so after that if i use bzr push it should update the remote repo right ?
<Odd_Bloke> xinity_mbp: Depends what you mean by 'that'. :p
<xinity_mbp> Odd_Bloke: i've installed the push and update plugin, bzr plugins founds it
<Odd_Bloke> xinity_mbp: I've never used it myself, so I don't really know.
<Odd_Bloke> Try and find out. :)
<xinity_mbp> Odd_Bloke: but when i try to do a bzr push it says something like : This transport does not update the working tree of: .... :(
<Odd_Bloke> xinity_mbp: OK, it looks like it adds a push-and-update command, so try 'bzr help commands' and look for that.
<xinity_mbp> Odd_Bloke: nothing about push and update :(
<Odd_Bloke> xinity_mbp: I've just installed it locally and I have a push-and-update command...
<xinity_mbp> Odd_Bloke: use brz help commands ?
<Odd_Bloke> xinity_mbp: Both there and when I try to run it.
<xinity_mbp> Odd_Bloke: ok bzr help push_and_update says : Helper functions for pushing and updating a remote tree.
<xinity_mbp> Odd_Bloke: but nothing about how to use it :(
<Odd_Bloke> xinity_mbp: Use it exactly as you would push.
<xinity_mbp> Odd_Bloke: i did but it still says :
<xinity_mbp> Odd_Bloke: bzr commit works perfectly, but bzr push says : This transport does not update the working tree of:
<spiv> xinity_mbp: the way the plugin works, I suspect it'd still print that message
<spiv> xinity_mbp: but it may have updated the working tree anyway
<xinity_mbp> Odd_Bloke: but the new file i've added locally isn't in the remote tree, i still need to do a checkout on the remote side
<xinity_mbp> Odd_Bloke: bzr update zorry
<luks> xinity_mbp: you need to use push-and-update, not push
<luks> (I think)
<dato> luks: not anymore
<luks> oh
<dato> push-and-update could use a README file
<mtaylor> any chance anybody has an special tricks for getting pylint to understand lazy_import?
<spiv> mtaylor: s/^lazy_import/#\0/  and  s/^""")$/#\0/  ?
<mtaylor> yeah... there's that.
<mtaylor> but then I wind up forgetting to uncomment it before I commit
<mtaylor> anybody ever touch the compiler module?
<Parker-> once... years ago... after that guys in white give me my own room with padding :P
<Odd_Bloke> mtaylor: I've played with it a little, but nothing especially in-depth.
<mtaylor> Odd_Bloke: I'm trying to inject something into the tree...
<xinity_mbp> Odd_Bloke: got it , it works now
<xinity_mbp> ;)
<mtaylor> it's causing me to want to lay in a padded room :)
<Parker-> :P
<Odd_Bloke> mtaylor: Way over my head, sorry. :)
<Odd_Bloke> I was just trying to get pretty representations of stuff.
<Odd_Bloke> xinity_mbp: Awesome. :)
<xinity_mbp> yeah!
<xinity_mbp> now i should be sure of what to do next time;)
<Parker-> have to say that bzr is great.. played two days and already made own bzr serve command that uses paramiko to made custom ssh server and uses public keys to authenticate.. :P
<xinity_mbp> Parker-: terrific !
<Parker-> still in proof of concept state...
<luks> could be very useful plugin for windows
<Parker-> it works with windows :P
<Parker-> https://launchpad.net/bzr-auth
<Parker-> now uses ssh-agent (or Pageant in windows) to get keys
<poolie_> wow, that's great Parker
<poolie_> you should really post to bazaar@lists.ubuntu.com about it
<Parker-> er... I'm little and shy boy
<Parker-> :D
<Parker-> hmmhh.. is bazaar@lists.canonical.com same?
<dato> yes
<ubotu> New bug: #189227 in bzr-svn "Strip a trailing \n when submitting the commit message to SVN" [Undecided,New] https://launchpad.net/bugs/189227
<poolie_> yes
<Parker-> have to fix it little bit before annoucement
<bob2> poolie: ah, that'
<bob2> d be the problem
<bob2> was just surprised, since tla handled it fine ;)
<ubotu> New bug: #189246 in bzr "UnicodeDecodeError exception in merge" [Undecided,New] https://launchpad.net/bugs/189246
<wica> HI, I have bzr-1.1 on a gentoo machine. I have problem to commit my code. Get a ".bzr/branch/revision-history.tmp.1202219907.956677914.25812.1333525853": [Errno 13] Permission denied"
<wica> The owner of bzr root, and the group is bzr.
<Odd_Bloke> wica: This suggests that you've created the branch with a different user and haven't set the permissions on it correctly.
<wica> My normal user is in the bzr group
<wica> and al my dir have 775
<wica> Odd_Bloke: Yep, that I understand. But the permissions look ok.
<bob2> ls -ld ".bzr/branch/" .bzr/branch/revision-history.tmp.1202219907.956677914.25812.1333525853
<wica> That file is not there
<wica> the normal user in cli. Can create files there
<Odd_Bloke> wica: Is the above the full message that bzr gives?
<wica> Â bzr: ERROR: Permission denied: "/var/bzr/iceshop/trunk/.bzr/branch/revision-history.tmp.1202219907.956677914.25812.1333525853": [Errno 13] Permission denied
<wica> this is the full msg
<wica> when I change the owner of /var/bzr/ to my normal user. I can commit
<Odd_Bloke> OK, does the 'bzr' group have the execute bit set on all directories leading up to that path?
<wica> I did a chmod -R 1775
<wica> So it shoutbe
<Odd_Bloke> OK, so the use of the sticky bit might cause problems if you're not the owner of /var/bzr/iceshop/trunk/.bzr/branch
<wica> will try chmod -R -x
<Odd_Bloke> Why?
<wica> -x will remove the sticky bit
<wica> use to see what happen
<Odd_Bloke> -x will also stop you being able to go into directories...
<jrydberg_> has anyone experimented with gittorrent-like things for bzr?
<abentley> wica: x is the execute bit, not the sticky bit.  The sticky bit is t.
<wica> abentley: Yes, that is true. don't know why I typed +x
<Parker-> hmmhh... what then is s bit?
<wica> But the problem is found
<wica> The user with the problem, has created the problem
<wica> :/
<abentley> Parker-: you are probably thinking of SUID or SGID.
<jelmer> jrydberg_: haven't seen anything like that yet
<Parker-> ah ok
<Parker-> wica, usually the user is THE problem :)
<abentley> People seem to confuse SGID with the sticky bit a lot.
<Parker-> jeh
<Parker-> hmhh.. have to think what to do with the bza-auth
<Parker-> bzr-auth even
<ubotu> New bug: #189282 in bzr "Internal error on branch of awn-core (httplib.ResponseNotReady)" [Undecided,New] https://launchpad.net/bugs/189282
<ubotu> New bug: #189300 in bzr "bzr push to saved location fails" [Undecided,New] https://launchpad.net/bugs/189300
<alefteris> im getting this error when i'm trying to update or pull, anay ideas? bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/...bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<alefteris> Bazaar (bzr) 1.0.0.candidate.1
<Parker-> is it binded_
<Parker-> ?
<alefteris> dont really know: this is what bzr info gives me: checkout of branch: http://... , parent branch: http://...
<alefteris> is it?
<Parker-> hmmhh.. did you use 'bzr checkout' or 'bzr branch'
<beuno> alefteris, yes, it looks like it's binded
<beuno> you can just do "bzr unbind"
<beuno> although it seems the branch is locked
<beuno> you might want to do bzr break-lock on it if you have write access
<Parker-> because isn't http:// access read-only?
<beuno> (user bzr+ssh instead of http)
<alefteris> so what i have to do get the latest revision from lanuchpad? mind that the branch is on a remote server, where i havent got my ssh keys there
<Parker-> bzr branch http://...
<beuno> alefteris, just do "bzr unbind"
<beuno> and then
<beuno> bzr pull http://...
<beuno> which is probably faster then re-branching
<alefteris> ok you guys rock, thanks a lot :)
<beuno> alefteris, :D
<Parker-> doh... but I'm soft meatbag :(
<beuno> Parker-, re-branching works too, just a bit slower
<beuno> it's a matter of sticking around long enough here
<beuno> things tend to repeat themselves a lot
<beuno> we should have a !explain_this bot here at some point I think
<Parker-> beuno, yeah I know.. :)
<Parker-> maybe should put some kind of notice text if user uses checkout + http
<beuno> Parker-, right, seems reasonable, like when pushing non-locally, with the "this does not update the working tree" notice
<Parker-> and I think there should be better error information when comes that "cannot mkdir"
<Parker-> or something
<beuno> Parker-, absolutely. If you're subscribed to the mailing list, you might want to propose it (or even cook up a patch if you're up to it)
<alefteris> beuno, maybe a more desciptive error message would help also. i search the web as well for the error, but found only bug reports but no clear solution about what i shoud do about it
<beuno> alefteris, absolutely
<beuno> I'll file a bug for it
<alefteris> thank you
<beuno> that way it can be tracked
<beuno> Parker-, ^
<Parker-> roger :)
<Parker-> doit because I'm newbie here :P
<Parker-> started to use bzr two deays ago :)
<beuno> Parker-, will do, and welcome!
<Parker-> thanks... today published first proof of concept plugin to launchpad :P
<beuno> Parker-, that was you?  cool!  I have that thread starred to look into later on. We are really in need of something like that. I'll try and peak into the code and see if I can help you out with that
<tacone> hello. how to enable nautilus integration ?
<Parker-> beuno, heh... thanks :)
<beuno> tacone, you have to install bzr-gtk
<tacone> I did.
<tacone> I noticed from the topic 1.1 is out. I have 0.9
<tacone> 1.1 will enable naut-int by default ?
<beuno> tacone, ah, just saw this "(Note that NautilusIntegration is disabled at the moment, friction in the interface between nautilus and bzr resulted in substantial performance issues)."
<beuno> jelmer, is that still true?
<lifeless> moin
<beuno> hey lifeless
<beuno> tacone, bzr doesn't come with any GUI tools by default, but I do strongly recommend upgrading
<Parker-> beuno, and yeah... help would be great..
<tacone> I saw it too. but maybe it's not updated.
<beuno> tacone, you can download the latest from: https://launchpad.net/~bzr/+archive if you're on Ubuntu
<tacone> beuno: I just did (5 seconds :-))
<Parker-> hmmhh.. ubuntu-backport have 1.0
<tacone> nothing seems to change
<tacone> bzr --version gives 1.1.0 now
<tacone> shuold I try to restart nautilus maybe.
<beuno> tacone, it might not be enabled
<beuno> let me give it a try
<tacone> thanks.
<tacone> I will restart x in the meantime
<tacone> beuno: I restarted the whole pc but I see no naut-int.
<beuno> tacone, did you follow the installations instructions in the README?
<beuno> you have to install python-nautilus
<jelmer> beuno: Nobody disabled it afaik
<beuno> copy a file into ~/.nautilus/python-extensions
<tacone> wow. where's readme ? :-D
<beuno> tacone, and 0.93 doesn't seem to work with 1.1
<beuno> branching trunk to see if it does
<beuno> but of course, jelmer would know much more about this
<lifeless> abentley: ping
<tacone> so should I downgrade bzr ?
<abentley> lifeless: pong
<lifeless> abentley: I think I have a clue about improving the in memory index stuff
<beuno> tacone, hold on a bit, lemme triple check how everything works, and I'll walk you through it
<lifeless> abentley: I'm going to have a stab at it today
<abentley> Have fun.  I'll be busy anyhow.
<tacone> thanks beuno, waiting for you here :)
<lifeless> abentley: I'm thinking you may want to merge-and-test-and-revert occasionally once I have something up
<abentley> lifeless: If you want to play with my fast-iter-files-bytes branch, it's here: http://code.aaronbentley.com/bzr/bzrrepo/fast-iter-files-bytes
<abentley> I do not consider it merge worthy, so don't panic about how it works.
<lifeless> k
<beuno> tacone, got everyhting working, but I can't seem to get nautilus to do stuff...
<tacone> nice :-D
<tacone> I will live without
<tacone> thank you anyway. so kind.
<beuno> tacone, it might be worth a try to follow the readme instructions
<beuno> and restart X
<beuno> which I can't do at this moment
<tacone> where do I find readme ?
<beuno> tacone, in the plugin directory
<tacone> ok
<beuno> download 0.93
<tacone> ok.
<tacone> thank you very much. have a good evening
<beuno> tacone, thanks, you too
<ubotu> New bug: #189390 in bzr "Warn users when doing checkouts with read-only transports" [Undecided,New] https://launchpad.net/bugs/189390
<jelmer_> beuno: I'm not sure who added that bit to the wiki for NautilusBzr
<beuno> jelmer_, I couldn't get it to work though. Does it requier to restart X?
<lifeless> jelmer_: well the code is disabled
<lifeless> jelmer_: there is an XXX about it; or was recently
<jelmer_> ah, somebody has commented it out in the setup
<jelmer_> beuno: It requires you to restart nautilus
<jelmer_> beuno: that should be all
<jelmer_> you also need to have python-nautilus and libnautilus-dev (or something) installed
<jam> poolie: ping
<jam> lifeless: ping
<lifeless> jam: gnip
<beuno> jelmer_, still doesn't work  :/    I'll try to debug when I get home
<jam> lifeless: I've been inspecting why "bzr annotate" is slow, and I'm finding some interesting points.
<jam> I thought I would discuss it a bit before I really got down and started coding
<lifeless> cool
<jam> Basically, the #1 thing that pops up, is that for 700 revisions, we call _lookup_keys_via_location about 70,000 times
<jam> It seems that all of our normal Knit calls have to do a bisect lookup
<jam> so every time we do "get_options()", "get_method()", etc.
<jam> And "get_parents()" has to do 2 lookups
<jam> because it checks to see if the parents are ghosts
<lifeless> yes
<lifeless> so we should not be using get_parents except when it matters
<jam> get_delta() ends up doing about 5 lookups, because it uses the get_options, get_methods, and get-parents
<lifeless> and for decompression trees it does not matter
<lifeless> a grab-it-all-at-once api would be better for knit text extraction
<lifeless> also the index bit is slow right now, I'm looking at that today, had some ideas come to me after explaining it to aaron yesterday
<jam> well, as to that, we don't really need the fulltexts to do reannotate
<jam> if we are going to be doing it from the line deltas anyway
<jam> we can just build up annotated fulltexts on the fly
<jam> rather than building up fulltexts
<jam> grabbing the deltas
<jam> and then combining the two into annotated fulltexts
<abentley> jam: The line deltas aren't accurate.
<jam> abentley: but you are using them
<jam> abentley: "annotate_knit"
<abentley> They don't have correct information about the last line.
<abentley> I believe that operation uses both the fulltexts and the line deltas.
<jam> abentley: you use the matching blocks from the line deltas, and the fulltexts in reannotate
<jam> but you use the matching blocks assuming they are accurate
<jam> Is the only problem the "eol" marker?
<lifeless> jam: you're off on a tangent now, I meant that the in memory management of the pack disk index disk data can be improved; this doesn't affect fulltexts/not
<abentley> jam: I believe so.  Got work stuff.
<jam> lifeless: well, I'm saying you don't need to extract all the knits into fulltexts
<jam> and was trying to figure out a better way to stream out what I did need
<lifeless> jam: sure; I didn't think we did. Anyhow its the exact same set of index calls needed
<jam> It also makes me feel like we should be caching in Knitgraph a bit more
<lifeless> we have to access the component, delta or fulltext, from the index layer
<lifeless> and we should access each index record once.
<abentley> jam: if you look at KnitContent.get_line_delta_blocks, you'll see it does not blindly trust the matching_blocks-- it uses the fulltexts to ensure the delta of the last line is correct.
<abentley> This is probably the biggest reason why I hate knit deltas.
<jam> abentley: I do see that, though I wonder if we could just handle the eol on our own and not have to build up the fulltext
<jam> but thanks for pointing it out
<jam> but yeah, the knit way of storing things is to record whether there is an eol
<abentley> jam: You'll have to be careful if you take that approach.
<jam> then always force a final eor
<jam> eol
<abentley> for example, the last line could match some other line because of the lack of an EOL.
<abentley> And of course, there may also be real differences.
<jml> Is the RC out yet?
<lifeless> jam: the encoding misses data
<lifeless> jam: it does not indicate if the delta affects the last line
<abentley> other than EOL
<jam> true enough
<jam> though if you are doing annotated fulltexts anyway, you'll still have a fulltext to work with
<jam> you just don't have to have 2 of them
<abentley> TBH, I'm not sure whether you can calculate it without using using the fulltexts or doing equivalent work.
<lifeless> jam: depends on the deltas I think
<jam> anyway, the biggest expense is all around the KnitGraphIndex at the moment
<jam> so it is the place to focus
<jam> reannotate is about 3/15s
<jam> _get_entries is 8.5s/15s
<abentley> Because in order to compare against the last line, you may need to hit any delta in the history to find its contents.
<abentley> And knit delta format won't tell you how many lines there were in that version.
<jam> Sure, I wasn't planning on shortcutting going into all history yet
<jam> just thinking that caching 700 fulltexts in memory was probably not a good idea
<abentley> jam: we're doing that, are we?
<abentley> Yeah, probably not the best idea.
<jam> ancestry = get_ancestry(versions)
<jam> lines = get_line_list(ancestry)
<jam> (psuedocode)
<lifeless> wheeee boom
<Parker-> jam, put option to user, if he/she want to use memory caching?
<lifeless> annotate an iso, dare you to
<abentley> Perhaps an LRU cache would make sense, with reasonable groupings.
<jam> Parker-: well we would need at least a couple copies
<lifeless> Parker-: we try to solve problems in such a way that no questions/options are needed to get good performance all around
<jam> but we shouldn't ever need all of them at once
<jam> and we should be able to build them up as we go
<lifeless> options require explanations and understanding of consequences
<Parker-> lifeless, yeah, but some users have too much memory to use.. so if they want... they can also boost with memory caching?
<abentley> jam: well, this was a quick fix.  You can probably do better if you're willing to reimplement knit building.
<lifeless> Parker-: perhaps; but if we can solve it such that the extra memory is irrelevant
<lifeless> Parker-: then there is no question to ask
<jam> there is the possibility of caching intermediate representations for something like gannotate
<abentley> jam: But I'm really surprised that you're not pursuing annotation caching.  Because this annotate code is pretty fast when you're dealing with < 1000 revisions.
<jam> but that is certainly a different question
<Parker-> I didnt meant to solve this one... but in future or something...
<jam> abentley: it is 15s for repository.py which is 700 revisions
<jam> I'm not sure if that is "pretty fast"
<jam> I'm trying to find the case where it was "9 minutes"
<abentley> bzr annotate -r 1000 NEWS was pretty fast.
<abentley> But that was on knits.
<jam> I have the feeling it is a mixed "too many packs" and too many revisions
<lifeless> Parker-: sure; I'm not rejecting your idea, but suggesting we should see if there are solutions that are as good without options
<lifeless> jam: how many packs do you have ?
<jam> lifeless: here only about 6 or so
<lifeless> jam: and whats a histogram of components for them
<Parker-> but then.. what I do with my gigs of ram :(
<jam> lifeless: *I* don't have the 9-minute annotate problem
<lifeless> Parker-: use it for java
<jam> lifeless: it was someone else's error report
<Parker-> lifeless, ah yes...
<Parker-> forgot java :)
<lifeless> jam: right; and interested report would be a histogram of that fileid across packs
<abentley> btw, I believe that get_line_lists does not take nearly as much memory as repeated calls to get_lines.
<jam> abentley: well lines that are shared between versions will stay shared as in-memory strings
<abentley> Right.  Mostly.
<abentley> I'm not sure whether that happens when a version has more than one descendant.
<abentley> Actually, it's probably unique there, too.
<abentley> It would be the list that would have to be copied.
<igc> morning
<abentley> igc: evening.
<igc> hi abentley
<lifeless> abentley: yes list copies - thats the code we were talking about saturdayish
<abentley> lifeless: indeedy.
<abentley> later, gators.
<jam> later abentley
<jam> have a good evening
<jam> statik: ping
<lifeless> abentley: jam: bz2 is only slightly better than gzip
<lifeless> I thought bzip2 was slower though
<foom> it's insanely slower, worst case
<jam> it usually is
<foom> i had a log file which took 2 hours to compress with bzip and 5 minutes with gzip
<jam> and it is generally slow symmetrically
<jam> so it is slow to compress and can be slow to decompress
<lifeless> so I'm wondering if this change you guys requested is the right thing
<lifeless> 45K -> 40K is the difference
<jam> lifeless: well, you are the one doing the profilling
<jam> bzip2 comes into its own in the 900k range
<jam> not really in the 40k range
<jam> The big difference being that gzip has a very limited window
<jam> something like 16k
<jam> while bzip has a much larger window
<lifeless> huffman vs simple sliding window
<lifeless> I'm going to add size-doubling-every-request to this get_parents thing
<lifeless> so that full-history is not linear round trip counts
<jam> afaik, LZMA is mostly gzip with a huge window, and can do better than bzip2 on compression, and still keep gzip decompression speeds
<lifeless> cute
<jam> lifeless: bz2 may not make sense at this level, I'll certainly let you do the tradeoffevaluation
<lifeless> must be some fun with window refernce pointers
<lifeless> well I've done the commit already
<lifeless> I know we do get farking huge histories
<jam> lifeless: but if the request is designed to buffer X amount of data per round-trip an individual request may be quite limited for all cases
<lifeless> X, then 2X, then 4X
<lifeless> currently its X
<ubotu> New bug: #189419 in bzr "Odd behaviour when adding directory with wrong case on Windows" [Undecided,New] https://launchpad.net/bugs/189419
<jam> lifeless: we might consider capping it at Y*X, if only for interactivity purposes
<jam> (say 16X or something)
<lifeless> I'm seeing 2.4K revisions in a 64K compressed blob
<lifeless> our entire history is what, 15K?
<lifeless> so thats 2.4 + 4.8 + 9.6 - 3 round trips
<jam> lifeless: revisions.kndx is 1.5MB
<lifeless> you have knit repos left?
<lifeless> we have to have a chat
<jam> lifeless: yep
<jam> my development stations are all packs
<jam> my public repo is still knits
<jam> gzip revisions.kndx is .5MB
<jam> bzip2 is about the same
<jam> 482KB versus 427KB
<lifeless> hi statik`
<poolie> hello
<jam> hey poolie, phone time, right?
<lifeless> poolie: I can still merge stuff for 1.2?
<poolie> lifeless, yes
<lifeless> IcanHAZcheezeburger
 * lifeless breaks bzr.dev network with itself, again
<Parker-> heh
<ubotu> New bug: #189431 in bzr "pre_commit hook overly expensive" [Undecided,New] https://launchpad.net/bugs/189431
<mattimustang> hi, i'm looking at converting from svn to bzr. Does bzr support svn style properties?
<lifeless> some yes
<lifeless> is this for 3rd party extension, or for file-ending support on windows etc?
<lifeless> (that is are you asking about 'generic stuff' or specific features)
<foom> it doesn't support keywords or eol-style
<lifeless> foom: yet; I have a plan.
<foom> does 1.2 make any more great strides in speed?
<lifeless> yes network pull on smart server will be way faster
<lifeless> and use less memory
<lifeless> and make more coffee
<foom> how about local operations?
<lifeless> branch and checkout are faster
<lifeless> annotate too I think
<foom> i haven't even gotten to the point where pulling data is a problem yet. :)
<lifeless> give me a sample branch and the ops that are slow and I'll fix it
<foom> i have a 50krev 1.3G repo, full of proprietary data. I imagine it has the same issues as large public projects, though.
<lifeless> we're performing quite adequately on openoffice
<lifeless> which is similar in size
<lifeless> last time we discussed I think I said words to the effect of 'file bugs, tagged performance'
<lifeless> which I'll repeat, I'm happy to explain why this matters if its not obvious
<foom> hm, i guess i should grab the ooffice repo and try using it
<lifeless> igc can help you there
<foom> it'll at least be interesting to see whether there is a marked difference in performance
<lifeless> start by filing bugs though
<lifeless> command X is slow, I have <---> this much data of the thing its looking at.
<lifeless> we'll probably get you to get some stats about your repo without disclosing data to help analyse things
<lifeless> but I'm really begging you - file bugs.
<foom> ok.
<igc> lifeless: yes, I ran a full set of local benchmarks on openoffice last night
<lifeless> no bug, no chance of developer thinking about your case. You'll only accidentally get fixed. Bug. Things Get Fixed.
<igc> on both gutsy and leopard
<igc> no deep history in those results (yet)
<poolie> jam, did you really want all of ~bzr to join ~bzr-log-rss-devel?
<beuno> igc, is there anyway for stats to be automated with bzr.dev?  have it spit out nightly stats in HTML format
<lifeless> poolie: hes using an idiom to allow devs that are only interested in log-rss to do so, but to grant all bzr devs access to
<lifeless> I think its not really needed; but shrug:)
<poolie> do you mean we each individually accept or decline?
<poolie> oh i see
<igc> beuno: I think so via cricket
<poolie> tb
<poolie> nm
<foom> igc: do you have the converted repo available?
<lifeless> tb?
<igc> foom: see http://bazaar-vcs.org/Benchmarks
<lifeless> igc: I think foom wants to pull the converted deep history repo and play
<igc> raw snapshots are available here: http://people.ubuntu.com/~ianc/benchmarks/src/
<igc> I'm working on getting a conversion of openoffice today as it happens
<beuno> igc, cricket?   Would be nice to have to see performace gains. Even eventually have statistics of how it's being improved
<igc> I'll make that available as soon as I can
<lifeless> didn't jam do one already ?
<igc> um - someone at Canonical did, not sure if it was jam
<igc> w.r.t. cricket that is
<lifeless> igc: jam. You should be able to just copy that conversion
<lifeless> jam: ^
<igc> w.r.t. OOo, jam was looking at a conversion from the CVS master but I believe it required a lot of manual work to get right
<igc> given their tagging conventions, etc.
<lifeless> yes but as a data point for playing with ..
<lifeless> it doesn't have to be right
<lifeless> foom: we could pair-file-bugs if you like
<poolie> spiv, can you explain why we get TooManyConcurrentRequests errors, like in bug 189300
<ubotu> Launchpad bug 189300 in bzr "TooManyConcurrentRequests error during push" [Undecided,New] https://launchpad.net/bugs/189300
<foom> igc: on those benchmarks, it looks like you're testing with no history?
<foom> lifeless: thanks; not today at least, though.
<igc> foom: that's right - it's on my list real soon now to add that
<igc> foom: first step is getting a sensible convension of 3 of large projects which I'm doing today
<poolie> i would have thought that could only come from some kind of structural code bug
<spiv> poolie: I think maybe because of poor error handling
<poolie> but it seems to occur when there are network errors
<poolie> hm
<igc> s/3 of/several/
<poolie> maybe if the network is dropped we skip reading the reply, or noticng that there will be no reply
<spiv> poolie: i.e. issuing a request that expects a body, but gets an error instead, but forgets to do cancel_read_body in the error handling
<poolie> and then fail to see the next one?
<poolie> right
<spiv> Which is the sort of thing that the next protocol version ought to help with...
<lifeless> igc: we have a mozilla one already
<poolie> igc, i'd be inclined to start with bazaar itself,
<poolie> it's easily accessible and it has a realistic merge graph
#bzr 2008-02-06
<igc> poolie: ok. I actually think it's pretty straight forward to add deep history support to usertest so I'll do that today after kicking off a conversion
<lifeless> poolie: I think its interesting to have deep linear too; because many conversions will be like that
<poolie> sure
<lifeless> and in the short term, most huge histories will be conversions
<foom> yes, my repo came from svn, so it's essentially linear
<poolie> i guess for ease of understanding the results we need to pick one main case to graph
<lifeless> I would say rather that we should be repeating on the same graph
<lifeless> we might have N big graphs to test, all different
<poolie> testing N could be good, i'm just a bit concerned that if we produce too much output data it will not be read
<lifeless> well whats the audience
<lifeless> will the audience read 1, or N, or none ?
<lifeless> right now I don't look at usertest daily
<lifeless> I only look at such things when I'm a) deciding what to put in my pipe, and b) evaluating how I'm doing with my current changes
<lifeless> if you have someone who is trying to do a) on any of a number of scales, N graphs is little harder to read that 1, and better at detect regressions caused while operating on code for the case of b)
<lifeless> I'll wager that you have a similar use pattern
<lifeless> but that Ian, who is focusing on a) in a broad sense, daily, looks at it quite frequently.
<lifeless> http://www.smh.com.au/articles/2008/02/05/1202090393959.html <- hmm
<poolie> i'm fixing a merge conflict to merge, and jam has a todo asking for the trace file to be line buffered so you can more easily read it
<poolie> should i do a trivial change to have a debug option to turn that on, or yagni?
<lifeless> the trace file is buffered right now right?
<lifeless> for performance
<poolie> yes
<poolie> up to several kb, whatever is the python default
<lifeless> I've had no trouble tailing it
<lifeless> but if we change it yes, it should be a flag
<poolie> oh, actually the comment is wrong, it is always line buffered
<poolie> which is fine
<poolie> thanks Teddy! :)
<lifeless> lol
<mattimustang> hi, i'm looking at converting from svn to bzr. Does bzr support svn style properties?
<lifeless> mattimustang: I answered your question before; did you not see the answers ?
<mattimustang> sorry i missed it and lost it in scollback :(
<mattimustang> so it doesn't support arbitrary properties like svn?
<lifeless> 10:39 < lifeless> some yes
<lifeless> 10:40 < lifeless> is this for 3rd party extension, or for file-ending support on windows etc?
<lifeless> 10:40 < lifeless> (that is are you asking about 'generic stuff' or specific features)
<lifeless> 10:41 < foom> it doesn't support keywords or eol-style
<lifeless> 10:41 < lifeless> foom: yet; I have a plan.
<mattimustang> thx
<mattimustang> I have custom properties aside from what svn uses (keywords eol-style etc)
<lifeless> per file or per commit ?
<mattimustang> per file
<mattimustang> file metadata like unix permissions, owner, group
<lifeless> ok
<lifeless> well I'm designing a plugin to store those precise attributes
<lifeless> with a lookaside structure from the core
 * jelmer wakes up
<lifeless> we have arbitrary revision properties, and you can do things like e.g. storing a dict of the changed file properties you want in a revision property - so {fileid:newvalue, ...}
<lifeless> this isn't entirely ideal, but making arbitrary properties DTRT all the time is rather tricky, when you have to consider performance-at-alarge
<mattimustang> i really need the metadata to stay with the file it belongs to
<lifeless> yes, what I describe does that
<lifeless> files have uuid
<mattimustang> if files move I don't want to have to update some other manifest elsewhere
<lifeless> a rename does not change the uuid (which we call file_id)
<jelmer> lifeless: wouldn't it make more sense to store it in a . file in the root of the tree?
<lifeless> jelmer: that makes it a user file
<jelmer> I wouldn't want to check out a 30000-revision branch with several thousand files that each have a couple of properties set
<lifeless> jelmer: remember the trouble with altering the representation of .bzrignore
<foom> so store it in a \0 file in the root of the tree? :)
<lifeless> a) we reject that filename, b) its the same problem
<jelmer> lifeless: .bzr/repository/fileprops.knit would be ok as well
<lifeless> jelmer: a knit? wtf
<jelmer> that's also how i'd like to see .bzrignore support
<jelmer> ed
<jelmer> well, a knit or a pack or whatever
<jelmer> it can be in the pack file as well, depending on your repository type
<lifeless> jelmer: in the broad sense you are saying 'this should be in the core'
<jelmer> lifeless: Yes, I am.
<lifeless> jelmer: and thats fine, I want to get something up and working as a plugin, then when its stable, design an appropriate extension to core to do it well.
<jelmer> lifeless: ah, ok. I hadn't seen you say that anywhere yet. That makes sense though.
<lifeless> as a plugin the goal is to work and be decoupled from repository format
<lifeless> figure out all the data needed, how it changes, what it needs. then design good storage.
<lifeless> so I'm thinking it will be slowish as a plugin, but easy to tweak
<jelmer> I would really like to avoid a "bzr setprop" kind of UI for setting these things btw
<lifeless> oh I cannot tolerate that ui
<lifeless> never happen
<jelmer> ok :-)
<lifeless> I mean, see my comments re the shell hook stuff
<mattimustang> what would propose then?
<jelmer> lifeless: I think being able to write python should not be a requirement for being able to write bzr hooks.
<lifeless> mattimustang: well I made a suggestion, or do you mean about how to activate this feature for a branch ?
<lifeless> jelmer: I think our hooks and hg/svn hooks are different beasts.
<jelmer> lifeless: For commonly used hooks, those should definitely be in python.
<lifeless> jelmer: our hooks are gateways into the core library; like svn's baton passing.
<mattimustang> well my original question was does bzr support it and it seems that it doesn't
<lifeless> the stuff you want should be done by specific adapters
<jelmer> s/commonly/installable/
<lifeless> mattimustang: it has arbitrary properties that can be set per commit; you can build out what you want easily there
<mattimustang> how would you do that per file then?
<jelmer> lifeless: For example, we check whether a commit message contains a specific line here at a svn repository
<lifeless> mattimustang: I already described it; you seem to think it wouldn't work.
<jelmer> lifeless: most people know shell and can write a two-line shell script that checks a commit message is valid.
<lifeless> jelmer: thats fine; do an adapter like I posted to the list for running make check. Then most users can write such a two line shell script
<lifeless> jelmer: this is entirely different from trying to write a FFI to shell for our hooks.
<mattimustang> so that is still using svn main repo for checkins and hook script. ok that is fine i can understand that approach but what about going purely bzr?
<lifeless> mattimustang: huh? what I described was using bzr
<foom> my 2 line shell script for doing that exact function is actually a 116 line python script. :)
<jelmer> lifeless: Which thread was this? I don't think I've seen that.
<foom> 43 lines of which are a function called "get_cmd_output" which I use to call "svnlook log" and "svnlook changed", since the server doesn't have python 2.4 (and thus the subprocess module), and popen.* are terrible
<jelmer> you mention posting a pre-commit-check hook in the "Enhancing hooks" thread, but I can't find it
<lifeless> jelmer: 1202182868.659.144
<lifeless> Config.get_user_section api
<mattimustang> "(11:39:13 AM) lifeless: we have arbitrary revision properties, and you can do things like e.g. storing a dict of the changed file properties you want in a revision property - so {fileid:newvalue, ...}" is that what you are talking about?
<lifeless> mattimustang: yes
<mattimustang> ok
<jelmer> lifeless: I don't see how that is all that different from my shell hooks plugin
<jam> poolie: I did intend to have bzr-log-rss as part of the bzr project. I just wanted to allow someone else to have access aswell. I did the same thing for bzr-pqm-devel since James didn't want to be in ~bzr
<poolie> got it
<lifeless> jelmer: I didn't claim it was.
<lifeless> jelmer: Ian posted work to create a generic FFI for our python hooks.
<lifeless> jelmer: I think that that is a bad idea.
<jelmer> lifeless: ahhh, ok. I see your point.
<lifeless> in short - some hooks that work well available for shell - great.
<lifeless> all hooks in shell - are you insane?
<jamesh> you think multiple fork+exec's for common operations would be a performance problem?
 * fullermd is insane.
<lifeless> jamesh: we'll only pay that when someone has chosen to use a shell hook
<jelmer> lifeless: right, and there's not always an obvious conversion between python types and shell types..
<lifeless> jamesh: so no, because we can and should also make it really easy to write absolutely trivial python hooks - by providing base class hook implementations that do most of the grunt work
<jamesh> lifeless: one thing that would be nice would be to centralise the hook registration APIs
<jamesh> lifeless: rather than doing some on SmartTCPServer.hooks, some on Branch.hooks, etc
<jelmer> jamesh: even when done centrally, those hooks would still only apply to some objects
<lifeless> jamesh: like the two like 'check a regex in the commit message' should be in python, about 8 lines - import regex, import a currier that takes a plugin name and looks for config stuff with that prepended, and then a simple 'get regex, execute it, return'
<jamesh> jelmer: I realise that.
<lifeless> jamesh: I don't actually like a single global registry; what is better about it ?
<jamesh> lifeless: well, the current system kind of works against lazy_import
<jamesh> lifeless: if I want my plugin to hook the SmartTCPServer, then every invocation of bzr is going to import bzrlib.smart.server once my plugin is installed
<lifeless> OTOH we wouldn't need lazy_import if python imports didn't suck so much
<lifeless> so I have on my todo list to fix that for bzr
<lifeless> and a pretty good idea about how
<lifeless> what else?
<foom> there's already packages which implement lazy module importing
<jamesh> lifeless: I guess that's my main complaint.  A central hooks registry was a solution to that, but you've obviously thought of some alternatives that might be better
<yacc> pkg_resources entry points?
<jamesh> lifeless: actually, the other one is discoverability of hooks
<lifeless> jamesh: I'd like bzr help plugins/hooks to dump them all
<jamesh> okay
<lifeless> jamesh: I think thats thats nicer because it allows plugins to add hooks themselves too
<lifeless> (not that a central place prohibits that, but because it doesn't lend it self to it quite as nicely if you think about it this way)
<jamesh> at the moment you have to dig through the code to find out where to register your hook, what the name of the hook is, and what arguments it should expect
<lifeless> yes, that sucks
<lifeless> also debug.debug_flags has the same problem
 * igc food
 * spiv -> late lunch
<abentley> Can I not join ~bzr-log-rss-devel please?  I get enough spam from Launchpad as is.
<abentley> by spam, I mean bugs on bzr-eclipse, bugs on bzr-webserve, branchfeed, etc.
<abentley> These are not projects I have ever been interested in.
<Aloha> when i "man bzr" i get this weird output http://www.pastebin.ca/893506
<beuno> Aloha, that's wierd, me too
<beuno> but if I have my terminal maximized, it doesn't happe
<beuno> *happen
<beuno> Aloha, you should report the bug to the Ubuntu package (might also happen in Debian, dato?)
<Aloha> ok
<beuno> Aloha, that would be https://bugs.launchpad.net/ubuntu/+source/bzr/
<Aloha> beuno, thnx
<beuno> I'm going to bed now, I swear  :D   g'night all
<beuno> Aloha, thanks for filing it!
<mtaylor> abentley: I've got a question about the bundlebuggy workflow... that's the pqm, right? so once a merge is approved there, it gets merged to the tree?
<abentley> mtaylor: No, they are separate systems.
<mtaylor> ok. so what happens once a merge is approved on bb?
<abentley> mtaylor: A person with clearance submits it to PQM.
<mtaylor> abentley: so there's still a manual step there then
<abentley> mtaylor: Indeed, and frequently more.
<abentley> Because many patches need to have conflicts fixed before they can merge cleanly.
<mtaylor> ah
<mtaylor> ok
<mtaylor> and then the PQM system is the one that runs the unit tests before pushing to the tree, no?
<Aloha> bug filed
<abentley> Yes.  Technically it merges, runs unit tests, then commits.
<mtaylor> cool. makes sense
<abentley> The conflict issue has gotten a lot better since we started doing NEWS alphabetically, though.
<abentley> So submit-from-bb isn't completely out of the question.
<mtaylor> I tell you what, changelogs and news files really screw with merges in general :)
<abentley> mtaylor: Someone should write a merge algorithm for NEWS and CHANGELOG files.
<mtaylor> you could almost have bb submit and then ask for a re-submit if the merge didn't work.
<mtaylor> abentley: I totally agree. I'd be in favor of that!
<mtaylor> abentley: my debian/changelog files are always a problem
<abentley> mtaylor: Great.  Let me know when you have something >;)
<mtaylor> :)
<mtaylor> so bzr-pqm is just the submit-to-pqm plugin though, right? Is pqm itself released?
<abentley> Yes it's an open project.
<abentley> http://people.ubuntu.com/~robertc/pqm/
<mtaylor> abentley: awesome. thanks
<bob2> is there any support for plugging file-type-specific merge algorithms into bzr?
<abentley> bob2: No, but you can write your type-specific merge so that it falls back to merge3.
<abentley> General merge algorithms are pluggable.
<bob2> ah
<bob2> neat
<mtaylor> abentley: so what if bob2 wrote a file-type merge algorithm, and I wrote a debian/changelog algorithm, and I had both file types in my tree?
<abentley> mtaylor: Obviously, it doesn't scale.
<mtaylor> :)
<abentley> I did some work on per-file merge algorithms, but I didn't nearly finish it.
<mtaylor> I'd say I'd think about it further, but I'm like 12 deep on my stack of non-essential work at the moment anyway
<spiv> poolie: a fix for bug 185394 is on the list, if you'd like to review it
<ubotu> Launchpad bug 185394 in bzr "Generic bzr smart protocol error: bad request '232' when connecting to bzr 1.0 smart server" [Critical,Fix committed] https://launchpad.net/bugs/185394
<fullermd> Oooh.  Purdy.
<poolie> thanks spiv
<mazzanet> herro
<mazzanet> how do you get a diff of the local tree and the repository that includes any new files added locally?
<mtaylor> mazzanet: have you commited those files ?
<mazzanet> i don't have commit access to the repository
<mazzanet> ie. i'm making a patch
<fullermd> diff should do it just fine in general (though it won't for binary files).
<bob2> "bzr diff" will show the difference between your current checkout and the main thing
<fullermd> The usual answer, though, is jut to commit in a local branch.  Then you can send a merge directive and keep all your metadata.
<bob2> but this new-fangled distributed thing means you can create your own branch ;)
<mazzanet> bzr diff isn't including the new files
<fullermd> Did you 'bzr add' them?
<bob2> (bzr add will work even if you can't commit)
<mazzanet> really?
<mazzanet> crazyness
<mazzanet> cheers
<mazzanet> *dances*
<jblack> bob2???
<jblack> Bob2!!!
<fullermd> jblack: Oh, hey there.  Didn't see you come in.
<jblack> I came in on tippy-toes. ;)
<jblack> cprov too! wow
<cprov> jblack: hi James. Good to see you again.
 * jblack gets amazed by the people he sees when he crawls out from under his rock
<jamesh> hi jblack
<jblack> Hey jamesh
<jamesh> jblack: and bob2 still has the hair ...
<jamesh> and denies that he plays goon of fortune
<jblack> Heh.
<abentley> jblack: Hi.
<jblack> Hi
<CardinalFang> Aloha.
<abentley> What colour rock have you been hiding under?
<jblack> A black one, of course
<jblack> it sounded funnier in my head.
<abentley> Heh.
<kiko> heh
<kiko> hey jblack how's it going?
<jblack> hi
<jblack> Pretty good.
<ubotu> New bug: #189567 in bzr "output to a terminal should default to using /usr/bin/pager" [Undecided,New] https://launchpad.net/bugs/189567
<synic> anyone awake?
<synic> how can I get bzr to mark files with the current revision number?
<Parker-> hmmhh... like $rev$ or something?
<synic> yeah
<jam> synic: short answer, no
<jam> longer answer... http://bazaar-vcs.org/KeywordExpansion
<jam> you might look at "bzr version-info"
<synic> k
<Parker-> heh
<jam> But it is more about putting it into another file
<jam> ATM we don't change files for you on commit
<synic> alright
<Parker-> hmmhh... in future... is it possible to lock files?
<Parker-> if branch is checkouted
<Parker-> (or binded)
<Spads> So I once had infinity rattle off a zillion commands at me explaining how to do this, but short term memory's always the first to go...
<Spads> I've got a tree where I maintain an internal patch to upstream sources.  new tarballs appear periodically, and I want to just incorporate that stuff and keep my set of changes on top.
<Spads> infinity said there was a "maintaining a patch" section in the docs, but I can't find it
<Spads> he mumbled about doing lots of imports from tarballs, but that seems to blat the whole tree out with the upstream files.
<Spads> HI!  I always swap "infinity" and lifeless in my head
<Spads> hi lifeless
<Spads> they're both so eternal
<jam> Spads: there is http://bazaar-vcs.org/TrackingUpstream
<jam> And I know there is "bzr import" provided by bzrtools
<jam> Generally, I would say you want to have a pristine branch of upstream
<jam> which your work is derived from in another branch
<jam> and then you go to upstream
<jam> update to the latest tarball
<jam> commit
<jam> then go to your branch
<jam> merge in the changes
<jam> commit
<jam> go on with your life
<jam> http://jameswestby.net/tips/tips/hacking-a-project-with-bzr.html
<jam> also describes that workflow
<jam> only with "upstream" being in svn
<Spads> okay, this is close to what we were doing already.  I may have misheard him as it sounded like he was talking about everything in-place
<jam> Spads: he has a plugin to do that
<jam> but I don't think it is fully released yet
<Spads> ahaaaa
<jam> Last I read was that it needed a bit of polish, and should be released within the next month or so
<muszek> hi... I have a local branch binded with a branch on a remote server.  I'm using bzr+ssh URI.  When commiting, I'd like the remote working directory to be updated at the same time... is it possible?  Right now I have to issue commit locally, wait till it's finished and issue "bzr update" command on the remote server (I want to skip that 2nd part)
<jelmer> muszek: you can use the push-and-update plugin for that
<muszek> jelmer: thanks
<muszek> can I specify the path that I want to run bzr commant at?  something like "ls -A /var/www" shows me stuff in a specified directory (not the one I'm currently at).  Say I'd like to run something like "bzr update /var/www/myapp"
<jelmer> bzr update /var/www/myapp should work
<pygi> muszek, yes, you can ;)
<muszek> damn... It does work... I must have messed up something before.  thanks and sorry guys.
<Wonko> Hi guys, I have a noob Q: I have a project on two machines that has a settings file that differs for these machines. Everything else is the same and needs to be kept in sync.
<pygi> muszek, no worries ;)
<pygi> Wonko, you can ignore that settings file
<pygi> Wonko, bzr ignore [file]
<Wonko> But the settings file might change in the non-specific parts , is there a better way maybe?
<Wonko> thought about ignoring, but it seemed unelegant ;)
<pygi> Wonko, perhaps you might want to split settings file to two separate files? One common, and one specific?
<pygi> Wonko, and just ignore the common one? :)
<Wonko> @pygi: that sounds like a good idea. Mercurial has something called "Mercurial Queues" that allow me to "plug in" patches, which would sound ideal for my case. Does bzr have something like that?
<Wonko> ( Hg stuff: -> http://hgbook.red-bean.com/hgbookch12.html#x16-26700012 )
<pygi> Wonko, gimme a moment to read it pls
<Wonko> I'm still thinking about where to move to from CVS, bzr or Hg (or maybe darcs) ..
<Wonko> sure, take your time, and THANKS!
<pygi> Wonko, per-se, I don't think bzr has something similar, however I believe a plugin like that could be written
<Wonko> k, thanks so far!
<pygi> Wonko, thank you, and dont hesitate to ask if you have more questions :)
<foom> i wish there was a way to have both, at once.
<foom> a revision history of the changes i actually made, *and* a sensible split into patches of the same changes
<pygi> foom, that approach doesnt scale .... i.e. see darcs :)
<foom> pygi: ...just because darcs doesn't scale doesn't mean what i want is impossible. :)
<pygi> true that foom :P
<pygi> foom, you could write a bzr plugin that does that, anyway
<foom> no i couldn't
<foom> maybe someone could
<pygi> hehe :)
<foom> but i don't even have a precise enough idea of what I want it to do to start.
<batoms> is there a quick fix for a corrupted dirstate?
<batoms> mine appears to be corrupt and i can't do anything on my tree
<luks> a quick fix would be "bzr branch <broken> <fixed>"
<luks> but filing a bug report about that is probably a good idea, too
<pygi> and we'd appreciate it :)
<batoms> branching doesn't work
<batoms> #186014
<batoms> Bug #186014
<ubotu> Launchpad bug 186014 in bzr "MemoryError on diff/commit" [Undecided,New] https://launchpad.net/bugs/186014
<luks> branch fails with the same error as e.g. diff?
<batoms> pretty much everything fails
<batoms> except for bzr info
<batoms> and bzr log
<luks> umm, I'm pretty sure branch used to work
<batoms> the last comment on that bug give the traceback
<batoms> for branch
<luks> hmm
<luks> rm -r broken/.bzr/checkout && bzr branch broken fixed
<luks> but obviously backup the broken one before
<batoms> but then i lose track of the my recent uncommitted changes on the tree
<abentley> batoms: after that, you can move the .bzr/checkout from the new tree into the old one.
<batoms> that did the trick, thanks
<luks> maybe there should some hidden command to regenerate the dirstate from scratch
<foom> jelmer: so i ran bzr svn-push, and it's been running for about 20 minutes so far, and I have no idea what it's doing or if it's going to work; is there any way to have it print some debugging info about what it's doing?
<jelmer> foom: If you run it with -Dcommit, it should write debug info to .bzr.log
<jelmer> sorry, ~/.bzr.log
<abentley> luks: The reason why branch breaks here now is that branch uses the local tree if it can to accelerate the process.
<abentley> luks: Perhaps we could hang it off 'reconcile'.
<muszek> anyone knows some good article with arugments for using version control systems?
<abentley> luks, foom: push should work fine with a broken dirstate, so we didn't have to delete .bzr/checkout (though we would have had to replace it).
<Parker-> hmmhh... trying to get bzr-svn work... and windows stuff is not aynmore located in http://home.comcast.net/~klight/bzr/
<orospakr> What is the proper way to migrate from git to bzr?  The git plugin throws a scary traceback when I try to branch a local git repo.  Tailor adds a gross SHA1 hash to the beginning of the commit messages.
<orospakr> ah, bzr-git has a separate branch with pull support.
<orospakr> marked "VERY EXPERIMENTAL", though...
<luks> should be fine for one-time conversion, I guess
<luks> (that is, not incrementally sync the git branch)
<luislavena> hello everybody
<luislavena> anyone knows why the smart server reports format unnamed when asked for info?
<luislavena> bzr info . (pack-0.92)
<luislavena> bzr info bzr://localhost => format: unnamed
<orospakr> luks, yikes, it won't even load.
<orospakr> AttributeError: 'GitRepository' object has no attribute 'base'
<beuno> luislavena, you must have a pre 1.0 version of bzr, probably 0.9
<beuno> (on the smart server)
<beuno> s/0.9/0.90
<luislavena> beuno: nop, both 1.1
<luislavena> anyway, i'm running on the same machine :P
<luislavena> oh, btw, windows... :D
<beuno> luislavena, does "bzr version" output the same in both?
<beuno> luislavena, oh, and you probably have to provide a full path to the smart server
<luislavena> beuno: mmm, I chdir to the path I want to share... and all the other information it returns seems ok...
<luislavena> (shared repository, branch info, even the push location)
<luislavena> beuno: nop, still the same, even with --directory pointing the same location.
<luislavena> weird, but it works.
<mtaylor> http://rafb.net/p/0k9wig17.html
<mtaylor> um... wtf?
<mtaylor> so, he did a bzr merge from a merge directive... then did a bzr revert, then a bzr pull, then a bzr commit
<mtaylor> and this is the resulting change
<mwhudson> mtaylor: looks like the pull only brought in revision data, not text data
<ubotu> New bug: #189709 in bzr "added-but-not-commited files which are removed go into weird limbo" [Undecided,New] https://launchpad.net/bugs/189709
<johnny> hi, anybody familiar with the cvsps-import tool?
<johnny> i'm not sure if i have enough to make it happen, or i'm missing something
<johnny> my cvs fu is weak after years of not using it
<lifeless> johnny: sure what problem are you having though ?
<johnny> exactly how much access to the cvs tree do i need?
<johnny> since it doesn't seem to support :ext: or :pserver:
<lifeless> AIUI a copy of it
<lifeless> it needs to extract the ,v files
<lifeless> because you are converting history
<fullermd> I think you can use the non-local protocols if you --use-cvs or something.
<johnny> so, not just a checkout ?
<fullermd> Probably a lot slower, though.
<lifeless> johnny: you can try --use-cvs as fullermd says
<lifeless> and no, it does not operate off of a checkout, it operates off of the repo
<johnny> syntax ?
<lifeless> I've always used it on local paths
<johnny> well, i am working with a codecoop repository
<johnny> a sf clone kinda thing
<johnny> the nightly does seem to have a CVSROOT dir in it
<fullermd> Doesn't, you mean?
<johnny> it does
<lifeless> untar that backup somewhhere then :)
<johnny> yeah.. lemme try again
<fullermd> Oh.  Yeah, working off that would be a lot quicker than trying to do it remote   :)
<johnny> i had problems with it
<johnny> we're only talking less than 1000 revs, so either way.. no big deal
<johnny> no complicated branching
<johnny> etc
<johnny> time is not an issue
<johnny> here's what i have
<johnny> ohnny@beep ~/projects/redemmas $ ls infoshopkeeper-scm-2008-02-06/
<johnny> CVS  CVSROOT  infoshopkeeper
<johnny> i musta got the command sequence wrong before when trying this
<johnny> so this should be enough?
<johnny> ohnny@beep ~/projects/redemmas $ bzr cvsps-import infoshopkeeper-scm-2008-02-06/ infoshopkeeper isk
<elmo> is there anyway to diff without a working tree?
<lifeless> elmo: upgrade your bzr ;)
<johnny> lifeless, is that good?
<lifeless> johnny: that looks right to me
<elmo> lifeless: >> 1.0 ?
<lifeless> elmo: 1.1 I think - unless your 1.0 supports --old and --new
<elmo> lifeless: mmk
<mwhudson> it needs > 1.0
<johnny> http://rafb.net/p/yCqF6A35.txt
<johnny> that's what i see
<lifeless> whats in CVSROOT ?
<johnny> CVS dir and a bunch of scripts it seems : commitinfo,checkoutlist,config,cvswrappers,loginfo,modules,rcsinfo , etc
<lifeless> ok its legit
<lifeless> whats in infoshopkeeper ?
<johnny> CVS, and the normal files
<lifeless> ,v ?
<johnny> ?
<lifeless> say you have NEWS
<lifeless> is it NEWS
<lifeless> or NEWS,v ?
<johnny> aha.. just NEWS
<lifeless> so ,v is what CVS puts after its database files
<johnny> so it's not the full thing then
<lifeless> the CVSROOT files - commitinfo etc should also have commitinfo,v for the history of them
<lifeless> indeed it does not look like your history
<lifeless> there should be some sort of backup tarball you can get
<johnny> suprised it even included the CVSROOT then
<johnny> i wonder if i can bug them for the whole thing
<johnny> it'd prolly be easier to just do it remotely tho
<lifeless> jam: ^ can you advise ?
<ubotu> New bug: #189757 in bzr "Interrupted initial push leads to branch reference" [Critical,New] https://launchpad.net/bugs/189757
<jam> lifeless, johnny: It certainly sounds like you are just getting a checkout, and not the actual repository
<jam> It is *close* to supporting :pserver: I just never took the time to actually do it
<jam> as most people who are converting have access to their source
<jam> and it is faster that way anyway
<johnny> well, i guess i could email the codecoop people for the source
<johnny> but.. then how can i later sync branches
<lifeless> bah
<lifeless> soft failures for the lose:
<lifeless> Unable to test plugin "launchpad": cannot import name test_lp_registration
<jam> johnny: well, you just ask them for another code drop :)
<lifeless> our test suite is passing on pqm but the lp plugin tests are not running.
<igc> morning
<jam> johnny: though if you want ongoing conversions, Launchpad does a pretty good job of it
<lifeless> jam: ^ an example of why I don't like the dynamic test stuff you want to do :(
<johnny> i'd prefer not to rely on launchpad
<johnny> i'd like xmpp notices of commits , and other such things
<johnny> and i'd have to wait on them to provide it
<johnny> the whole point of this operation is to get a package that is relatively bigger than any of the other code stuff that we have
<jam> lifeless: you just make them hard-failures if you have something which looks like "test_*" and doesn't actually load
<johnny> so i can test out bzr on it
<johnny> to see if it will work for us
<jam> johnny: well if that is all you want, the bzr source code is certainly available
<jam> if you only have 1k commits, bzr is a lot bigger than that
<johnny> i mean with one of our own projects
<johnny> to test working with it in real life, with real commits :)
<jam> johnny: true, all of the bzr commits are faked :)
<jam> anyway, I understand your point
<jam> as for testing converting and then converting future work
<jam> it should just amount to getting another copy of the ,v files, and running it again
<jam> as long as you keep the conversion directory around
<johnny> i'll be happy when pserver happens
<johnny> then i can just pull into it
<lifeless> jam: IMO anything we try to load must load or the tests must fail.
<johnny> ok, i'm going to to get admin access to the project until pserver works
<jam> johnny: i don't expect to have time to work on ;pserver: for quite a while, but it shouldn't be hard if you want to play with it
<jam> And I'm happy to give answer questions
<johnny> i'm still learning python
<johnny> i don't work in a software job except php web devel
<johnny> but our coffeehouse has about 5 projects we want to manage
<johnny> yes.. a coffeehouse with folks who write code for it :)
<johnny> bookstore/coffeehouse really..
<lifeless> sounds cool
<ubotu> New bug: #189771 in bzr "launchpad plugin tests broken" [Critical,New] https://launchpad.net/bugs/189771
<abentley> lifeless: Any luck with the index stuff?
<lifeless> abentley: in progress
<poolie> i'm going to read spiv's network patch now
<lifeless> don't byte off more ... groan sorry
#bzr 2008-02-07
<lifeless> poolie: pulls of lp down to 49s
<johnny> from?
<lifeless> poolie: sneaking up on it, 8 seconds wasted on _ensure_real bs
<spiv> johnny: approx 2-3 minutes
<johnny> yes.. wwe sure are ensuring real bs :)
<spiv> johnny: it's not a very scientific test.
<johnny> hehe jk
<lifeless> spiv: you have the same disk format right - knits at both ends ?
<spiv> johnny: because I'm not pulling the same revisions each time, I'm just doing updates occasionally.
<spiv> lifeless: I think so, I'll double-check
<poolie> spiv, reviewed
<johnny> if you had a quote bot in here.. that'd totally be in there :)
<poolie> lifeless, what bs is that?
<johnny> not that i think you should have one..
<johnny> but still
<spiv> poolie: thanks!
<johnny> so, do you guys participate in that vcs mailing list?
<lifeless> poolie: its being tracked down still
<johnny> revctrl ?
<lifeless> poolie: I'm guessing tags or something like that
<spiv> lifeless: yes, both ends knits
<johnny> crazy people ...
<johnny> too smart for their own good :)
<lifeless> johnny: yes, I do
<johnny> i know the monotone folks are involved
<johnny> that's what i use with other projects
<lifeless> johnny: theres a strange mix of noise and signal
<johnny> monotone is great... but it's written in C++, and has not so good tools :(
<johnny> and git is insane... fast, but insane
<johnny> now i'm looking into hg as well, which i had never even previously considered
<johnny> lots of amazing projects are using all of these systems
<johnny> makes it hard to choose..
<lifeless> poolie: I'd like a quick call if thats ok
<poolie> 1m
<lifeless> I think you forgot a ^V[[; there
<lifeless> meh, ^[[;
<poolie> heh
<poolie> are you controllable by ansi sequences?
<lifeless> not anymore, I got upgraded
<poolie> css? :)
<lifeless> so - quick call or not ?
<poolie> go on then
<lifeless> thank god for noise cancelling headphones
<lifeless> my house phone needs a mini-rca jack
<Peng> Hmm, revctrl list? I'm in the channel, but it's almost dead.
<Peng> What type of noise cancelling headphones?
<Peng> Also, crapcrapcrap. I have a Python installation with no bzip2 support, and now bzr requires it.
<poolie> Peng, on what kind of machine?
<poolie> hm i wonder if we really need it or not?
<poolie> Spads, so is that review ok?
<poolie> i mean spiv
<Peng> poolie: It's a Debian shared web host. They suck at Python (2.3.5 and 2.4.1 installed), so I've compiled 2.5.1 in my homedir, but it winds up without bzip2 (or readline) support.
<Peng> Humm.
<lifeless> Peng: 2.4.1 should work fine for bzr
<lifeless> poolie: yes, we do - see the thread where I asked first :)
<lifeless> Peng: actually bzr has required it for some time
<mwhudson> Peng: i guess the bzip2 headers aren't on the host
<lifeless> Peng: just now needs it in another area
<spiv> poolie: yep
<lifeless> Peng: Sennheiser 350's
<lifeless> Peng: they make the construction going on upstairs nearly entire go away
<spiv> lifeless: ooh, nice
<Peng> mwhudson: Yeah, that's probably the case.
<Peng> lifeless: Yeah, but I want 2.5. And even if bzr already used bzip2, I'd so far avoided that part of the code.
<Peng> lifeless: That sounds good. I have a pair of Sonys that mostly make my loud computer fan tolerable . .
<lifeless> Peng: what do you want 2.5 for ?
<c1|freaky> hi all. umm, if i allready have set up a svn repository - should i use svn as repository? ... i just started reading the user guide ... well, if i dont use svn ...  is there any advantage or disadvantage?
<lifeless> the best way to use bzr is bzr-all-the-way
<Peng> lifeless: Just for stuff I screw around with, not bzr. Hmm, I could probably switch bzr to the system 2.4.
<lifeless> the stuff about svn is because many users we get have been using svn and have a number of systems to migrate
<lifeless> so its easiest for them to migrate incrementally
<lifeless> and some users have to work with other folk that use svn, and who won't change, but our users still want to use bzr because its nice :)
<c1|freaky> ok so, is it hard to migrate svn repos to bzr ones?
<lifeless> not at all
<lifeless> install bzr, bzr-svn and do a bzr svn-import
<c1|freaky> do i need to install bzr on the server?
<lifeless> it depends how you configure it - and that depends on what you want. Bzr can run over sftp which requires no special server side support, or over ssh which does want a copy of bzr on the server
<c1|freaky> can bzr have its own authentication mechanism like with svn and http?
<lifeless> bzr uses your authentication; you can have it be authenticated by apache, - if what you mean is 'does bzr have to use my passwd database' the answer is no.
<lifeless> in fact someone has recently done a ssh server for bzr with its own auth, but I've not tested that myself.
<c1|freaky> i dont want to give anyone shell access - sftp also uses ssh authentication
<c1|freaky> PAM
<c1|freaky> or whatever
<c1|freaky> i need an own authentication mechanism for bzr repos
<lifeless> sure, that ssh server I mention will do that
<c1|freaky> maybe i should read the admin guide if there is any for bzr
<lifeless> it doesn't use pam
<lifeless> and you can do restricted ssh keys by the way - that prevents anyone having shell access (you can have /bin/false as the shell too for extra security)
<lifeless> docs.bazaar-vcs.org IIRC
<c1|freaky> ok thank you
<c1|freaky> umm, does the trac-bazaar plugin work and is it as good as the subversion one?
<lifeless> abentley: shaved about 100ms off of 5.5 seconds user time for indexes so far - using checkout ---lightweight of a treeless branch as my test
<lifeless> abentley: still mainly refactoring to make it amenable to overhauling
<lifeless> c1|freaky: sorry, I don't use trac, can't really comment
<c1|freaky> ok bo
<c1|freaky> ^^
<c1|freaky> np
<mwhudson> it seems bzr.dev push hasn't received the same love as bzr.dev pull yet?
 * mwhudson watches revisions.kndx trickle upstream
<spiv> mwhudson: not yet
<spiv> mwhudson: although packs make it better
<mwhudson> i'm sure
<mwhudson> i guess i should convert my devpad repo over to packs
<abentley> lifeless: Wow, I can't get such steady timings on that workload to see 100 ms go away.
<abentley> Still, it sounds like movement, so that can't be bad.
<Peng> Ha! I got it to work with Python 2.4 and virtual-python.
<lifeless> abentley: the userspace timing is pretty consistent for me
<lifeless> abentley: the wall clock is pretty jumpy
<abentley> Ah.
<lifeless> I found while optimising commit to just ignore wall clock
<lifeless> and run it several times
<lifeless> that or close everything down
<pattern> i just did a "bzr add foo" and "bzr add bar", but changed my mind about adding these file before doing a commit
<pattern> how can i tell bzr not to version these files after all ?
<lifeless> bzr remove --keep
<pattern> thank you
<pattern> what about "bzr remove --new" ?
<pattern> how is that different from --keep ?
<poolie> remove --new automatically selects the files just added
<poolie> so i think you want --keep --new
<poolie> i'm going to look into the pqm failure i got the other day, merging some already-approved branches
<lifeless> --new is not needed
<poolie> if he names the files it's not needed
<lifeless> unless you want bzr to scan
<poolie> spiv, ping me when you've merged your thing, please
<spiv> poolie: ok
<poolie> lifeless, random comment
<poolie> i find pqm is disruptive to my concentration because it makes me open my mail client, which is the mind-killer
<poolie> i should probably procmail them into a special box and look at only that
<lifeless> poolie: fear!
<lifeless> poolie: but thats a good comment
<lifeless> poolie: pqm should blog or something
<poolie> yeah
<lifeless> theres an open bug for showing recent results in the status page
 * fullermd doesn't wanna let pqm pass thru him.
<poolie> or even dump them in an indexed web directory
<poolie> i realized this is more than half of my unhappiness about its asynchronicity
<pattern> thanks for your help, guys
<c1|freaky> after a few hours of reading i still dont know if i should switch to bzr from svn or not ... what do you say?
<lifeless> switch
<lifeless> you'll love it
<rolly> just try it out, it's very easy to make the transition
<c1|freaky> my only problem, at the moment is
<abentley> c1|freaky: And you can go back if you want to.
<c1|freaky> how can i have people to easily authenticate for submit
<rolly> I hit that snag too. I use bzr+ssh://
<c1|freaky> in a way without PAM authentication
<c1|freaky> i dont want to give everyone shell access who should be able to access a repository
<lifeless> c1|freaky: there was a post on the list a few days ago about a plugin that implements its own ssh server
<lifeless> c1|freaky: *also* you can "Use PAM but not give everyone shell access"
<rolly> there are myrisad ways to restrict ssh
<c1|freaky> they'd still have ftp access and a home directory
<c1|freaky> that sucks
<rolly> *myriad
<abentley> c1|freaky: Your system requires all users to have FTP access?
<c1|freaky> no
<rolly> http://tadek.pietraszek.org/blog/2006/10/18/restricted-shell-account-ssh-and-subversion/
<rolly> adapt to bzr.
<c1|freaky> thx
<c1|freaky> im still not sure
<c1|freaky> ill have a rest now
<c1|freaky> and continue later
<c1|freaky> 20 minutes or so
<poolie> oh i see, having times in the trace log makes it a bit harder to test, foo
<Aloha> Anyone know anything about Bug #189478?
<ubotu> Launchpad bug 189478 in bzr "man page has errors when typing "man bzr"" [Undecided,New] https://launchpad.net/bugs/189478
<johnny> c1|freaky, the issue is never between bzr and subversion.. bzr always beats subversion :)
<c1|freaky> i installed bzr manually because the ubuntu version still is 1.0.0
<johnny> its' between bzr,mercurial,git,and monotone
<c1|freaky> with subversion i can do http authentication
<c1|freaky> i want protected repositories where the user don't have ssh shells
<c1|freaky> an own authentication system
<johnny> the rest of svn won't make that worth it
<johnny> monotone has it's own
<johnny> based on public keys
<johnny> git can use http iirc
<bob2> on the downside, the openssh people are almost certainly better at writing authentication systems than anyone else
<johnny> the new monotone uses ssh agent for local keys which is nice
 * johnny doesn't like having system accounts either
<Aloha> how do i merge a patch into parent branch?
<c1|freaky> im using trac and i just want to provide some friends with repositories, and with the best possibilities
<johnny> trac will always work best with subversion, cuz they designed it badly
<johnny> it wasn't abstracted enough
<johnny> so.. for 0.12 it should work nicer with distributed vcs
<johnny> there is a bzr plugin
<johnny> as well as git and mtn ones
<bob2> Aloha: merge parent into your branch, then push to the parent
<bob2> Aloha: or checkout parent, merge your branch into it, then push
<Aloha> bob2, the patch is from someone else. how do i merge their patch?
<bob2> Aloha: is it really a patch, or is it a bzr branch or bundle?
<Aloha> bob2, its a bzr -o send patch
<spiv> Aloha: "bzr merge patch", where patch is the file generated by "bzr send -o"
<bob2> Aloha: "bzr merge patch_file"
<Aloha> spiv, bob2, thnx
<Aloha> so merge that into my branch and then push, yeah?
<bob2> yup (don't forget to commit after merge)
<spiv> Aloha: a merge is like any other change to your working tree, you need to commit it.
<spiv> Aloha: but otherwise yes.
<Aloha> bob2, doesn't bzr -o send create a patch based off of parent?
<Aloha> so does that mean my local branch has to be synced with parent?
<bob2> it has to be at or ahead of it, but you'd need that before you could push to it anyway
<lifeless> Aloha: no it doesn't have to be synced
<lifeless> Aloha: it uses the revision graph to generate a good diff
<Aloha> lifeless, thats freaking cool
 * Aloha loves bzr
<bob2> lifeless: it'll automaticaly fetch needed revisions?
<lifeless> bob2: if the other branch is ahead, there is nothing to fetch; if the other branch is behind the new revisions are in the local branch
<c1|freaky> hey guys, ill migrate from svn to bzr but i need some help. i have a 3 svn repositories on my server. i now want to "convert" them to bzr. how to do that? (i have one of them checked out)
<c1|freaky> (i just reinstalled kubuntu on my laptop that's why i dont have them all yet
<johnny> read the docs
<johnny> there's a migration section
<c1|freaky> in which documentation?
<johnny> onthe main site
<johnny> for bazaar
<c1|freaky> user guide?
<johnny> no
<johnny> it's right on the site
<igc> http://bazaar-vcs.org/BzrMigration
<rolly> does the pre-commit hook allow for modification of a versioned file, or addition of an unversioned file?
<c1|freaky> oh ok found it
<c1|freaky> :d
<c1|freaky> thank you
<igc> rolly: no, I don't think so
<johnny> modifying versioned files === bBAD
<johnny> BAD!!!!!!
<rolly> haha
<johnny> this isn't CVS
<igc> rolly: we're looking at a start-commit hook for things like that
<rolly> it's not ALWAYS bad
<johnny> keywords will never be expanded
<rolly> igc: that would be so awesome
<rolly> it would make my dreams of versioning my database come true
<igc> jelmer recently raised a bug on lp for that
 * igc looks
<lifeless> rolly: not currently; we will add one soon
 * johnny tries to think of a way you could modify a versioned file that was already committed 
<rolly> lifeless: cool! Yet one more step ahead of SVN
<johnny> as that sounds like it would invalidate it
<igc> bug 186422
<ubotu> Launchpad bug 186422 in bzr "Ability to modify the tree from a pre-commit hook" [Wishlist,Triaged] https://launchpad.net/bugs/186422
<johnny> oh.. pre commit would be fine, but you'd have to be super careful :)
<johnny> i idled in #monotone in otfc for awhile, those guys were always talking versioning theory
<johnny> pretty intense stuff
<rolly> wait, so I _can_ modify with pre-commit?
 * rolly reads
<johnny> i never rode the svn train
<johnny> i knew it was a lame idea
<lifeless> johnny: you can't alter history
<lifeless> johnny: but versioned file refers a file that is managed by bzr in general
<lifeless> johnny: so altering a versioned file in a working tree is what you do with emacs/vim etc all day
<rolly> Maybe I can get by with a little hack to bzr.bat
<lifeless> about 150ms down stably now
<c1|freaky> when i checked out the svn repositories to a local place ... now i'd have to create the bzr repos on the server, right? but before that, i need an authentication mechanism and i still dont know which i could use
<c1|freaky> :((
<c1|freaky> i dont want ssh or any other PAM authentication
<fullermd> It sounds like an excellent solution to me.  I mean, that's the whole point of PAM...
<c1|freaky> i dont want to give everyone ssh access
<c1|freaky> :((
<fullermd> You don't have to.  You can just give them bzr+ssh access.
<c1|freaky> how to do that?
<c1|freaky> and where should i create the repos? should i create a user called "bazaar"
<c1|freaky> and in that directory create the repository
<c1|freaky> for the different projects?
<lifeless> 200ms now
<lifeless> c1|freaky: I suggest you read the users guide and play with bzr *before* migrationg
<lifeless> c1|freaky: start with it on your workstation and get a feel for how it works. This will help you a lot when you start thinking about group setups
<c1|freaky> :(
<c1|freaky> i have no project im starting right now i just want to migrate
<c1|freaky> hmm
<fullermd> You can use PAM to authenticate against a database or another file or something other than the system password file.  You can set allowable commands for the users via ssh.  They don't have to have home directories or real shells.
<lifeless> c1|freaky: then just do 'bzr branch svn://urlhere local-disk-path'
<lifeless> c1|freaky: and you'll have your existing projects to play with
<c1|freaky> ok cool
<c1|freaky> :D
<c1|freaky> ill try that, thank you
<lifeless> c1|freaky: I suggest that you learn the basic tool first because otherwise you are going to be learning new concepts in several directions all at once.
<c1|freaky> i've allready read the whole user guide
<lifeless> c1|freaky: and thats tough; we have much more facility than svn, but we *different* - you don't /need/ a "repository" for instance. (You can have one, but its not needed)
<c1|freaky> ok ill remove my svn checkouts
<c1|freaky> and use the bzr branch dirs then
<c1|freaky> instead
<c1|freaky> and later when i created the repos on the server
<c1|freaky> ill use the bzr repos and commit them
<lifeless> yes
<lifeless> abentley: still around?
<abentley> lifeless: Yup.
<c1|freaky> Bazaar has encountered an internal error :\
<abentley> ubotu: paste
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<c1|freaky> PROPFIND request failed
<lifeless> abentley: total time for bzr.dev's lightweight checkouts - of that what fraction is index from memory?
<lifeless> abentley: (I'm not using your branch yet)
<lifeless> I've shaved 5% off basically at this point
<c1|freaky> http://paste.ubuntu-nl.org/55055/
<abentley> On my branch, it's 50%.
<lifeless> c1|freaky: what url did you us ?
<abentley> Total index.
<lifeless> abentley: right, I'm asking bzr.dev :)
<lifeless> abentley: IDK is fine
<c1|freaky> i used: http://code-1.de/svn/freaky-tcl/
<lifeless> c1|freaky: try svn+http://
<c1|freaky> k
<lifeless> c1|freaky: I hear that that may work better
<lifeless> failing that, jelmer ^^
<abentley> lifeless: I use dev as my sample data :-)
<lifeless> abentley: yes, but bzr.dev's _code_
<c1|freaky> lifeless: still the same
<lifeless> c1|freaky: do you have write access to the branch?
<lifeless> c1|freaky: if so what url do you use ?
<c1|freaky> i use http://code-1.de/svn/freaky-tcl/ i _have_ write access but it doesnt ask for login information? oO
<c1|freaky> still anyone can read
<lifeless> oh interesting
<abentley> I understood,  was explaining my dumbness.
<c1|freaky> so i dont really need login information
<lifeless> abentley: ok, I don't understand and am confused :)
<lifeless> c1|freaky: its not that, I was hoping for a different url. We'll need some help from the bzr-svn author at this point I think
<spiv> c1|freaky: that SVN repo has many projects in it.
<abentley> dev spends 53.43% in bisect_multi_bytes.
<lifeless> abentley: thanks
<c1|freaky> spiv: i just put them all together as one projects - my tcl scripts
<c1|freaky> -s
<lifeless> c1|freaky: https://answers.edge.launchpad.net/bzr-svn
<lifeless> I suggest asking a question there, and looking in the bug tracker too
<abentley> (The percentages are similar for dev and my code because I also eliminated some lookups)
<abentley> At least, I assumed so.
<abentley> If it's cached, maybe there's another reason.
<spiv> c1|freaky: hmm, so there's no trunk/ or branches/ or tags/?  Just one branch at the root of the repo?
<c1|freaky> spiv: yea
<lifeless> abentley: if bzr.dev spends agreater fraction in the index layer, its more efficient at the other things
<c1|freaky> it's just TCL
<lifeless> abentley: unless the extra index use is disproportionately slow
<lifeless> abentley: anyhow, my problem for now, and I guess 10% improvement in that region
<lifeless> if I assume 2.5 seconds in index, I'm down to 2.3
<abentley> The percentage bisect_multi_bytes for my branch is 50.76, I think.  Getting some contradictory output.
<abentley> Iter_entries time for dev is 57%, for mine, 51%.
<abentley> But recall that I'm batching my index queries.
<abentley> So that may help on the initial bisect.
<lifeless> batched queries are a huge win
<lifeless> I want! http://awaregeek.com/funny-stuff/usb-panic-button/
<abentley> lifeless: Would there be a performance win if indexes calculated build-dependencies all in one go?
<lifeless> abentley: possibly; its been my intent to put some tasteful graph query support into the index layer
<poolie> jml, my car is going to be ready in a bit, so i'll walk up and get it
<c1|freaky> i got another question: say 2 people want to code ona  project together, and they want to use a server, do you have to create a user account for every project your users make together, in addition to their normal user accounts just for the projects - because they both need access to the repository which can only be on a account on the server to which they both have access
<lifeless> the only possible win though is slightly fewer round trips in extreme cases
<poolie> you're welcome to stay here
<c1|freaky> or can u do that using groups?
<lifeless> abentley: we could in fact choose to not resolve references to merges but only to the actual trees.
<lifeless> needs this refactoring finished and tweaked further I think.
<lifeless> abentley: what would be a good result - (key, selected_reference, value) in an iterator?
<c1|freaky> and
<c1|freaky> how can i fix this: Unable to load 'bzr-gtk-0.93.0' in '/home/uwe/.bazaar/plugins' as a plugin because file path isn't a valid module name; try renaming it to 'bzr_gtk_0_93_0'.
<spiv> Wow, PQM is taking an hour and a half to run tests for a single merge.
<abentley> Possibly.  Is selected_reference for accelerating future queries?
<spiv> c1|freaky: do what it says: rename the bzr-gtk-0.93.0 directory in plugins so that it doesn't have dots or hyphens.
<c1|freaky> i removed it
<c1|freaky> i installed it as root
<c1|freaky> did that in the wrong direcotry
<c1|freaky> thank you
<c1|freaky> and where do i install that PQM thingy? on the server? what does it compile? do i have to create testing-config files i mean, how to compile programs etc. or are there default ones which just work?
<c1|freaky> that's all so much work for a private thing
<c1|freaky> but i want something neat for coders on my server
<lifeless> c1|freaky: in fact you should name that directory 'gtk' :)
<mtaylor> c1|freaky: I use group permissions for shared repos on my server
<mtaylor> works great
<c1|freaky> mtaylor: and where do you put the directories for the shared repos?
<fullermd> Blasphemously enough, I've got some in /home/cvs/bzr/[...]
<mtaylor> c1|freaky:  I made a /var/lib/bzr
<mtaylor> c1|freaky: then every time I add a new repository,  I go there and do chgrp -R src repos_name
<mtaylor> and then chmod -R g+s repos_name
<c1|freaky> ok, so i can put several projects on there, one repository (/var/lib/bzr) and in there the different projects on which different users could work on. and for every project i would have to create a group on the system
<mtaylor> and then I never think about it again
<mtaylor> c1|freaky: I make a new repos for each unrelated project myself
<mtaylor> c1|freaky: and if you really wanted to restrict access to project to a different set of people, then yeah, each one would want its own group
<mtaylor> any chance that "InvalidRevisionNumber: Invalid revision number 5946" means something other than what it says?
<c1|freaky> ok
<c1|freaky> now i need to create a repo on the server
<c1|freaky> how do you do that? do you first create the repo on the server itself?
<bob2> yes, the same as you would with svnadmin
<mtaylor> c1|freaky: you can do it multiple ways, but I usually just go to /var/lib/bzr and do bzr init-repo --no-trees repo_name
<spiv> poolie: at this rate, PQM should have merged my fix at about 6pm.
<c1|freaky> what does no-trees do btw, i didnt udnerstand it yet
<poolie> spiv, +1 my pqm speedup patch then :)
<bob2> c1|freaky: doesn't include a checkout-out copy of the source code in the repository
<lifeless> poolie: I've got about 10% so far
<c1|freaky> mtaylor: and when that repo is created, how to you put content on it?
<lifeless> poolie: I'm calling it a day at this point
<lifeless> poolie: I should have the refactoring finished tomorrow
<mtaylor> c1|freaky: then you can just push a branch there from somewhere eles.
<c1|freaky> i have a branch on my pc
<lifeless> abentley: its my index.range_map if you want to give it a whirl
<mtaylor> c1|freaky: so if you do cd /var/lib/bzr ; bzr init-repo --no-trees foo on your server
<spiv> Hmm, SyPy tonight.
<c1|freaky> but the server cant access my pc
<mtaylor> c1|freaky: doesn't need to
<abentley> lifeless: Where?
<mtaylor> c1|freaky: go to your pc, and go into your branch
<mtaylor> c1|freaky: and do bzr push bzr+ssh://yoursever/var/lib/bzr/foo/branch_name
<lifeless> abentley: https://code.launchpad.net/~lifeless/bzr/index.range_map
<lifeless> abentley: since I fixed register_branch I register them all :)
<lifeless> abentley: alternatively, because 6 hour mirroring is bog
<lifeless> *bong*
<lifeless> you'll want the external url http://people.ubuntu.com/~robertc/baz2.0/index.range_map
<c1|freaky> push is always like svn commit right?
<lifeless> c1|freaky: no, commit is like commit
<c1|freaky> but if im not bound to the repo
<c1|freaky> i can do commit and it wont commit to the server?
<mtaylor> c1|freaky: right.
<abentley> Oh, do I have one of those?
<c1|freaky> so what is push then?
<lifeless> mtaylor: except for history pivots
<lifeless> abentley: try logging into rookery
<mtaylor> c1|freaky: push is how publish your local commits to your shared branch
<lifeless> c1|freaky: push is used to mirror your local work to a remote repository
<lifeless> c1|freaky: mtaylor: the difference between commit and push is this: commit preserves the mainline history *always*, push does not.
<mtaylor> yes
<abentley> lifeless, yep.
<lifeless> abentley: then yes, yes you do
 * lifeless waves
<c1|freaky> ok ... i dont know what a mainline history is exactly. that's more like, the final part of the program after the rivisions from the branches have been put together?
<c1|freaky> SHIT!!!!
<c1|freaky> one moment need to revert a backup
<c1|freaky> oh no i dont have a backup of that directory
<c1|freaky> one moment
<abentley> lifeless: Merging your index stuff, I get 4.9 seconds.
<abentley> lifeless: no significant difference in the lsprof data for iter_entries
<lifeless> abentley: what did you get before? 4.9 still ?
<abentley> Roughly.
<lifeless> yeah
<lifeless> well at least I haven't borked it
<lifeless> I'll finish the refactoring up and then get into serious tuning
<abentley> best of 4, mine: 4.7.  Best of 4, yours: 4.8
<abentley> that is yours+mine
<c1|freaky> i can't get that push to work it tells me:
<c1|freaky> ValueError: I/O operation on closed file
<c1|freaky> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<rolly> Is there an easy way to "squash" a series of revisions into just one? The use case is that I've a bunch of little revisions that make up a single feature.
<c1|freaky> it works
<c1|freaky> forgot the write permissions
<mtaylor> rolly: I've got a plugin for that
<mtaylor> rolly: I haven't gotten around to releasing it yet... :)
<rolly> :O
<bob2> that's basically what merge does
<mtaylor> right, but the use case here is that you want to collapse into one revision before pushing
<rolly> exactly
<rolly> I could always merge, then uncommit, then pull. But screw that :p
<mtaylor> right
<rolly> plus, sometimes you want to squash even if you're not pushing anything
<mtaylor> yup
<mtaylor> I should add squash as an alias. I like that
<bob2> hm, do you want to lose the individual revisions entirely or just contain them within one "implement all of FOO" one?
<rolly> mtaylor: stole it from the git-rebase docs
<mtaylor> hehe
<rolly> mtaylor: does your plugin operate on ranges?
<mtaylor> yeah
<mtaylor> (I think... lemme double check - but I'm pretty sure it does)
<rolly> even if one of the ranges isn't the tip of the branch?
<rolly> that would be so sweet
<mtaylor> hm... now _that_ I don't think I've got
<mtaylor> because it's essentially using uncommit
<mtaylor> under the covers
<rolly> Gotcha :)
<rolly> that's still really useful. I hope you release it someday
<mtaylor> thanks for reminding me.
<mtaylor> we're using it at work... I just haven't gotten around to bundling it up sensibly
<c1|freaky> is anyone using the bzr plugin for trac?
<mtaylor> nope.
 * mtaylor uses launchpad for everything
<Debolaz> Apples and oranges. :)
<mtaylor> of course
<Debolaz> That being said, I stay far away from trac usually.
<mtaylor> ah... I dunno... oranges and tangerines perhaps
<rolly> I set trac up once, it was quite laborious
<Debolaz> It's not that it's bad, it just doesn't seem to fit anything I do. It either does too much or too little.
<Debolaz> For a small project, I don't want to go through all the trouble of setting up trac, but for a larger project its features just aren't enough.
<c1|freaky> rolly: yea u need to experiment a lot but in the end i got it set up and running: http://scm.code-1.de
<c1|freaky> is the publish bot put on the server or on the client?
<Peng> Uh-oh.
<Peng> Unable to delete pending-deletion.
<Peng> Ah, NFS garbage file.
<Peng> Gah, limbo too.
<Peng> Except, limbo is empty.
<Peng> Ok, third try's the charm.
<spiv> poolie: I was right, it landed at 6pm, almost exactly :)
<c1|freaky> what is a good pqm bot?
<c1|freaky> what is bazaar-ng?
<Peng> Huh, a pack repo will autopack even if it just spews a "these branches have diverged" error (at least over bzr+ssh).
<Peng> c1|freaky: Bazaar.
<Peng> c1|freaky: Bazaar (baz) was originally a fork of Arch. Then they invented Bazaar-NG (bzr), a whole new VCS. Later, Bazaar was renamed to Baz and Bazaar-NG was renamed to just Bazaar.
<Peng> c1|freaky: So, now they're interchangeable.
<c1|freaky> oh ok, thank you :)
<rolly> ng = next generation?
<Peng> Probably.
<rolly> where no repo has gone before
<fullermd> No, totally not like that.  In this case the NG version is _better_ than the original.
<rolly> No one said it's not, unless I'm missing something
<fullermd> Well, you started in with the Trek references...
<rolly> Ahhh...
<rolly> haha.
<ubotu> New bug: #189841 in trac-bzr "plugin doesn't load?" [Undecided,New] https://launchpad.net/bugs/189841
<c1|freaky> :D that was me :o)
<mtaylor> so the collapse thing I was talking about earlier...
<mtaylor> should I submit that to bzr.dev as a new builtin? or perhaps bzrtools? it seems sort of small to be its own plugin...
<lifeless> mtaylor: what sort of collapse thing?
<rolly> I would like to see it as a plugin mysql
<fullermd> Would it make sense to roll it in as part of rebase?
<rolly> *myself
<lifeless> Peng: it's done a fetch of data in that scenario where it autopacks
<mtaylor> fullermd: ah, perhaps...
<rolly> are you talking about the 'squash' thing?
<mtaylor> lifeless: it's a command that essentially does an uncommit all the way back to the last thing you've pushed
<mtaylor> yeah
<fullermd> Just because it's crammed in that package in git doesn't necessarily mean it should be here, but when you're collapsing the middle of a range, you'd have to rebase the later stuff anyway...
<mtaylor> collapse/squash
<lifeless> mtaylor: so you do this when you know noone will look at your branch? :)
<lifeless> mtaylor: (merging past that -> pain)
<mtaylor> lifeless: yeah - it more like to clean up the thing you're going to send, to get rid of the 12 revisions you did that were all "fixed small typo" and "crap, fixed another small typo"
<mtaylor> lifeless: I don't personally use it all that much, but it seems that it's a life-or-death thing for the folks who are in to it
 * mtaylor knows he's gonna have to write a test for it if he sends it to bzr.dev though... :)
<johnny> who uses that?
<johnny> what system supports bringing revs together like that?
<rolly> I guess your code could be useful in rebase, if --interactive is ever implemented
<mtaylor> bk
<johnny> aha.. bk
<johnny> but only the kernel and mysql folks use that :)
<mtaylor> hehe
<johnny> we were the 3rd biggest user
<johnny> but nobody ever did that
<johnny> before we switched to monotone
<mtaylor> johnny: who's we?
<johnny> xaraya
<johnny> web app framework/cms thingie
<mtaylor> the bk folks I know (really large bk user that I'm trying not to name atm) use it alot
<mtaylor> mainly so that they can bundle up a set of things that are logically one change and re-submit them for a sensible code review
<mtaylor> I think things like bundlebuggy already handle this problem from a different perspective though
<mtaylor> given that I can submit a merge again and it'll effectively collapse it in the display
<mtaylor> hrm. yeah. I don't really want to submit it to bzr.dev
<spiv> mtaylor: right, getting a useful diff for code review is a completely orthogonal issue
<mtaylor> yup
<spiv> mtaylor: you don't need to throw away history for that :)
<johnny> i use monotone for that, but trying to use bzr for a seperate project
<lostylost> is bzr very well tested on windows machines?
<spiv> Yeah, it we have quite a few people actively testing on windows.
<spiv> More testing never hurts, of course ;)
<lostylost> I keep getting errors commiting to a remote repo, that works fine on four other osx, linux boxes
<lostylost> it just stalls out half way through at the status bar point
<lostylost> before that I was having some wierd, pending-deletion errors
<ubotu> New bug: #189845 in bzr "hg-import:  ImportError: No module named hgimport.importer" [Undecided,New] https://launchpad.net/bugs/189845
<spiv> lostylost: hmm, that's no good.  Please file bugs.
<spiv> lostylost: you're welcome to pastebin the errors and talk about them here too, of course.
<lostylost> yeah, one of the other guys did re: the pending-deletion errors
<spiv> (Unfortunately I'm about to have dinner, so I can't be much help right now)
<lostylost> spiv, Thanks.    I think I will come back some time, I am starting to getcranky
<lostylost> enjoy your dinner
<spiv> lostylost: thanks.  Put all the relevant details somewhere (ideally a bug report, probably), and someone should be able to help you with it.
 * spiv -> gone
<ubotu> New bug: #189848 in bzr "hg plugin crashes" [Undecided,New] https://launchpad.net/bugs/189848
<lostylost> would it be unwize in the extreme to use cygwin bzr along with native windows bzr at the same time?
<lostylost> it *shouldnt* matter but would it?
<johnny> if you can make it error that way, i'm sure folks would be interested :)
<johnny> why does cygwin bzr exist anyways?
<lostylost> I am not sure, some people just like an integrated environment and don't want to leave cygwin/bash. I can't see the advantage
<lostylost> It's weird native bzr keeps stalling out on a commit so I am trying cygwin bzr. It says that I have changed every file in the branch though...
<lostylost> very od
<c1|freaky> what pqm are u using with bzr?
<lostylost> what do you mean pqm sorry?
<lostylost> if you are addressing me
<c1|freaky> i mean everyone
<c1|freaky> i mean that thing which tries to compiles commits etc. and then puts it into the mainline
<spiv> c1|freaky: we use https://launchpad.net/pqm for committing to bzr.dev
<c1|freaky> thx
<c1|freaky> do u always ude dots for branches?
<c1|freaky> *use
<johnny> i prolly would.. but that's an old habit
<c1|freaky> should i install that pqm as root?
<johnny> org.xaraya.core.stable
<c1|freaky> ok ill remember that
<johnny> for example
<fullermd> Darn mtn'ers   :P
<speakman> hi ppl...
<speakman> I currently got the same file under "removed:" and "added:" under "bzr status". How come?
<Odd_Bloke> speakman: Is it in the same location?
<speakman> Fixed it by making a copy of "new" file and then removed it and did a revert from last revision. And finally 'cat' new contents into the "old" file and then it was printed under "modified:" instead.
<speakman> exactly the same location.
<speakman> identical path
<spiv> speakman: those are different files to bzr
<speakman> how come? what's the "identifier" for bzr then, if it isn't filename?
<spiv> speakman: note also that you do "bzr revert FILe"
<spiv> speakman: file-id
<spiv> speakman: there's a hidden command, "bzr file-id FILE" if you're interested.
<spiv> So that bzr can track renames.
 * spiv -> dinner
<speakman> I did need to do a revert. Actually, the "strange" file was made out of a copy from a backup file with a 'cp', so there sure are some good explainations.
<speakman> how these strange "hosts" on ppl? ubuntu/not/ubotu and such?
<speakman> (O/T, sorry)
<Odd_Bloke> ubotu is a bot, which does helpful things (such as linking to the pages of bugs, and keeping people updated as to new bugs).
<c1|freaky> ok i still don't understand how to use a pqm
<c1|freaky> how do i install the bazaar smart server?
<c1|freaky> that bazaar quickstartcard is cool i just printed it :D
<speakman> c1|freaky: use inetd
<speakman> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#inetd
<lifeless> speakman: the strange hosts are an IRC feature
<lifeless> for registered users
<speakman> oh, i see
<speakman> thanks
<c1|freaky> damn why can't we download the launchpad software :(
<Odd_Bloke> c1|freaky: Because it's not Free Software.
<Odd_Bloke> Even if you could, you wouldn't really want to, I suspect.
<c1|freaky> that's a pitty
<c1|freaky> :D
<c1|freaky> speakman: thank you
<Peng> I've read that the reason Launchpad is closed-source is because the point of it is to bring projects together (like how you can link bugs from one project to another), so having multiple LPs isn't so useful.
<Peng> s/isn't so useful/counterproductive/
<Odd_Bloke> That's what I've heard.
<Odd_Bloke> The intent is also, I believe, to Free it once there's a mechanism to share between multiple Launchpad instances, so that problem can be overcome.
<joabr> Does any bzr plugin have something similar to this -> http://en.wikipedia.org/wiki/Image:Hgk.png ?
<joabr> graph ancestry does some similar graphing, but not the textual extra info.
<joabr> i'm trying to sell bazaar to my boss :-)
<Odd_Bloke> joabr: Look at bzr-gtk.
<Kinnison> yep, bzr-gtk has 'bzr visualise'
<Kinnison> which does exactly that
<Odd_Bloke> QBzr might also have something, though I've never used it myself.
<joabr> ah, ok. Thanks alot.
<ubotu> New bug: #189874 in bzr "hg-import Can parse file names with spaces" [Undecided,New] https://launchpad.net/bugs/189874
<lifeless> joabr: bzr viz; in fact gitview is based on bzr-gtk's visualise
<joabr> lifeless: sweet
<ubotu> New bug: #189886 in trac-bzr "Tracebacks when viewing log of a specified range of changesets" [Undecided,New] https://launchpad.net/bugs/189886
<elmo> so, i know you bzr guys like to argue about this
<elmo> if I have two runs of a script: old machine takes 95 minutes, new one takes 56 minutes
<elmo> is that 1.7x faster and 40% faster? or how do you do that 'n times faster / n% faster' math?
<jblack> 1 - 56/95 = 41.1% faster
<elmo> jblack: thanks
<jelmer> c1|freaky: don't use the 0.4 branch but use the released version of bzr-svn
<dato> jelmer: is that general advice?
<c1|freaky> jelmer: i soon wont need it anymore. ill just checkout, delete the .svn dirs and put it under bzrs vc :D
<c1|freaky> as soon as i get the trac-bzr plugin to work
<c1|freaky> i printed out the bazaar quick start card
<c1|freaky> really nice useful thing
<joabr>  do bzr have a svn equivalent to 'svn log --stop-on-copy'?
<mtaylor> joabr: what does stop-on-copy do?
<ddaa> it does not traverse copies
<ddaa> such as branch points or renames
<ddaa> bzr does not have explicit branch points
<ddaa> it _could_ stop logs on renames, but it's not clear that's what joabr wants
<ddaa> and I do not believe the feature is implemented already
<joabr> ddaa: the idea is to see revisions only for a given branch.
<ddaa> I'm afraid this request is a bit ill defined in bzr, you'll need to frame your problem a bit differently.
<ddaa> One way to look at bzr is that every commit is a branch point.
<ddaa> I could use my hard won skills at divining user desires to wrangle it out of you, but I do not really feel like it today.
<ddaa> for example, you could say "exclude from the log every revision that is in the ancestry of that other branch, defaulting to the parent"
<ddaa> which might do what you want
<joabr> okay, how?
<ddaa> a common approximation for what you seem to request is something like "bzr log last:1..ancestor:../other-branch"
<ddaa> "bzr help revisionspec" for help
<ddaa> you might also want to use "bzr missing"
<ddaa> that's usually enough to make bzr folks happy
<joabr> i'll take a look. Thanks for the info so far :-)
<jelmer> dato: not really
<jelmer> dato: There is a regression in the http support in the 0.4 branch at the moment that causes exceptions
<jelmer> however, this is not caught by the testsuite at the moment (since that would require setting up apache, etc)
<badrunner> Hi all, im having problems trying to push to an https branch, i get an " ERROR: Cannot lock LockDir ..etc" message
<badrunner> I also just get "Bazaar has encountered an internal error" when doing a pull or merge, but branch works fine
<luks> you can't push over http(s)
<badrunner> luks: ok, what are people doing for having multiple users commit access to the same repository? I cant seem to find any info on this, i keep windind up at the shared-repository page, which means something different
<badrunner> luks: oh, and this is without the ability to add system users, so thats why i was hoping https with a .htpasswd would work here for me
<luks> badrunner: you can use any writable method with multiple users
<luks> but HTTP is not writable
<badrunner> is there a list of methods anywhere?
<luks> you could setup the smart server over HTTP and use the web server to limit access
<luks> and then use bzr+http:// instead of http://
<badrunner> luks: that sounds like a good plan, i'll look into that thanks
<mtaylor> bzr+http works?
<mtaylor> crazy
<elmo> the bzr 1.1 PPA dapper source packages are broken - are they the official source of things these days - and if, so should I file a bug about it?
<Lunkwill> hi, I'm currently in the process of testing bzr - I've converted an SVN repository with several branches into bzr, using svn2bzr
<Lunkwill> I'm trying to merge one of these branches onto the main development branch (trunk)
<Lunkwill> on this branch, though, there are about 3 merge revisions, which contain the contents of several changesets taken from the trunk
<Lunkwill> of course that won't register properly in the bzr history
<Lunkwill> what is the best strategy to merge this branch with trunk, excluding those few merge-revisions that came from the subversion trunk?
<ubotu> New bug: #189915 in bzr "bzr 1.1 dapper PPA debs FTBFS" [Undecided,New] https://launchpad.net/bugs/189915
<Lunkwill> I've gotten the contents of the two branches merged properly by performing three merge operations, the first one starting from the branches' common ancestor.  the bzr history will only reflect the first merge as two branches merging, the two other merge operations appears as two single revisions
<Lunkwill> anyone know how to hack this so the branch revisions will look like they've been properly merged with the trunk, or do I have to live with this history problem because of our subversion heritage?  any answers will be greatly appreciated :)
<Lunkwill> k, I'll shut up now ;)
<LeoNerd> "merge" makes a single revision that contains all the composite changes
<LeoNerd> If you want to see them all as individual commits, you have a problem. History diverged. It is no longer a single stream timeline
<LeoNerd> You can't just "merge" those divergant streams and have it appear as a single consistent historic timeline
<LeoNerd> What you could do, if you were so inclined, would be to "rebase" the branch to the current head-of-trunk, then "pull" all the trunk revisions in, making them appear as new commits. But this can only work if the rebase operation succeeds; i.e. if there's no conflicts anywhere
<Lunkwill> LeoNerd: how about merging the subversion merge revisions, and "resolve" the conflicts by reverting all the changes in that revision, then commit?
<fbond> Hi, I think bzr is doing something weird with timestamps that is messing up an autotools build setup... does that sound familiar?
<tallo> Anyone tried using the svn plugin on osx?  I need to use http basic auth, which seems to be broken, yet I don't see any bugs open for it...
<tallo> i.e. the two perl lines removing auth in http://bazaar-vcs.org/BzrForeignBranches/Subversion
<tallo> or is this https://bugs.launchpad.net/subversion/+bug/71266 ?
<ubotu> Launchpad bug 71266 in subversion "Problems getting things to work on Mac OS X" [Undecided,New]
<muszek> hi... what do you guys use to be notified about revisions made to branches on remote servers?
<jelmer> tallo: Are you running 1.5?
<tallo> should be, having followed the directions on the page (locally installed in ~/.bazaar/svn)
<tallo> actually looks more like 1.6.0...
<jelmer> tallo: Subversion 1.5, I mean
<tallo> yup
<tallo> ~/.bazaar/svn/bin/svn --version returns 1.6.0
<tallo> craps out with "Assertion failed: (g->gc.gc_refs != _PyGC_REFS_UNTRACKED), function instancemethod_dealloc, file Objects/classobject.c, line 2285." at the console
<tallo> OSX 10.5.1, intel core2duo iMac...
<jelmer> tallo: Those two lines you commented out disable password prompting
<tallo> I should clarify: when I comment out those two lines, bzr just fails to access the svn repo. :)
<jelmer> sorry, that's what I mean
<tallo> But that's working-as-written
<tallo> When I leave them be, that's when things crash :)
<jelmer> those two lines hook in the password prompting
<tallo> which I need :(
<jelmer> apparently them crashing is a bug in the python subversion bindings
<jelmer> there's an alternative way to authenticate though, see the FAQ for details
<tallo> Yup, it's fairly obvious from the stack trace.  Hehe, even found a message from Brian de Alwis to you, with a (nearly?) identical trace
<tallo> Hm.  Tried "svn info <url>", it doesn't prompt and properly returns data.
<tallo> Tried "bzr branch svn+<url> mybranch", and it fails with Permission denied
<jelmer> It may be some OS-X specific thing
<tallo> Sounds like it, from Brian's post.
<jelmer> Can you try adding the following line:
<jelmer> svn.client.get_keychain_simple_provider(pool),
<jelmer> in transport.py:54
<tallo> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'get_keychain_simple_provider'
<tallo> perhaps I've got an older python-svn module?
<jelmer> this function is MacOSX-specific
<jelmer> there probably just isn't a python binding for it (yet)
<tallo> ah
<tallo> and yeah, I see the entries in Keychain that it would use
<jelmer> are you on Mac OS X 10.2 or later?
<tallo> 10.5.1
<jelmer> hmm, I don't actually see anything that could cause it to not generate python bindings for that function
<tallo> :(
<jelmer> maybe it's the ifdefs in the header file that confuse it
<jelmer> I can add the required bits to bzr-svn, but I can't figure out how to fix the python-subversion bits
<jelmer> since I don't have Mac OS X here
<tallo> hm
<tallo> Can you point me to the general location where it should be generated?
<jelmer> subversion/bindings/swig in the subversion source
<tallo> ok, thanks so much!
<jelmer> it's probably a matter of specifying -DDARWIN= or something to SWIG
<tallo> heh
<jelmer> the required bits should now be in bzr-svn
<tallo> cool, thanks :)
<abentley> fbond: Are you checking in built files?
<fbond> abentley: yes; I've traced my problem to an unrelated cause...
<abentley> Okay, nm.
<fbond> although I have seen the recent thread on the ML
<fbond> (that may also be an issue for me .... )
<abentley> Okay.  So you know your built file may end up newer than its source.
<fbond> Yes.
<abentley> or older
<fbond> Right...
<abentley> Cool.
<fbond> Will that be addressed soon?
<abentley> fbond: Hard to say.  I'm rather busy in RL, but that area is usually left to me.
<bobbo> What is the bazaar equivalent of ViewVC?
<mwhudson> loggerhead
<bobbo> thanks mwhudson
<mwhudson> this branch is the most up-to-date: https://code.edge.launchpad.net/~mwhudson/loggerhead/production
<bobbo> mwhudson: what dependencies do i need for loggerhead?
<mwhudson> bobbo: turbogears
<mwhudson> (unfortunately :/)
 * abentley sticks his tongue out at mwhudson
<mwhudson> abentley: it causes more problems than it solves for loggerhead, it's the wrong tool for the job
<fbond> mwhudson: (my curiosity) what would've been the right tool for the job?
<mwhudson> fbond: good question, but something that didn't use cherrypy as it's http layer would be a good start
<fbond> mwhudson: don't mean to pry, but I'm wondering why?
<fbond> I've never used cherrypy
<fbond> (also didn't mean to rhyme there ;)
<skvidal> fbond: do the rest in iambic pentameter
<skvidal> I was wondering if there was an easy way of going from bzr log > changelog-format
<skvidal> ?
<skvidal> sorry, hit enter too soon, there
<mwhudson> fbond: maybe it's just the way loggerhead uses it, but it has some annoying features
<mwhudson> (totally unhelpful behaviour if there's an exception during url traversal, completely un-workaroundable url mangling)
<fbond> mwhudson: so you just don't like cherrypy in general?  None of this sounds remarkably loggerhead-specific...
<mwhudson> fbond: from what i've read cherrypy3 is quite nice
<mwhudson> fbond: but no, i don't like cherrypy2, and that's what loggerhead is stuck with
<fbond> mwhudson: interesting.  thanks!
<fbond> mwhudson: have you used Django at all?
<mwhudson> fbond: no
<c1|freaky> is anyone using trac with bzr?
<mwhudson> fbond: but the real complaint about loggerhead using tg is that it's just not helpful
<mwhudson> loggerhead isn't a database-backed webapp in any sense
<thatch> c1|freaky: yeah, do you have a question about it?
<mwhudson> it and on-demand generated bunch of static web pages in some sense
<fbond> mwhudson: but CherryPy is just an HTTP framework, and loggerhead uses HTTP, right?
<fbond> mwhudson: I guess you think it's just not worth the overhead?
<c1|freaky> thatch: yea, are u using it with trac11b1?
<c1|freaky> thatch: look here: https://bugs.launchpad.net/trac-bzr/+bug/189841
<ubotu> Launchpad bug 189841 in trac-bzr "plugin doesn't load?" [Undecided,New]
<c1|freaky> i submitted that bug
<c1|freaky> did you have the same problem am i missing some step?
<thatch> c1|freaky: actually still on r6306... but yes I got that problem initially
<c1|freaky> and how did you fix it?
<thatch> c1|freaky: let's continue in pm, it's not directly bzr related
<c1|freaky> ok :)
<aadis> is there a way to send an automated mail on a bzr push?
<aadis> ie, server-side from the host being pushed to
<ubotu> New bug: #64658 in trac-bzr "[PATCH] Use trac to_unicode function when passing the revision message to trac" [High,Fix released] https://launchpad.net/bugs/64658
<nessy> I am trying to install bzr 1.0 or 1.1 on a Mac OS X 10.4 (Tiger) machine
<nessy> is there a package?
<nessy> http://bazaar-vcs.org/Download?highlight=%28Mac%29%7C%281.0%29%7C%28OS%29%7C%2810.4%29%7C%28X%29%7C%28bzr%29 only lists ppc
<nessy> and my bzr-py25 in fink lists as 0.18-1
<nessy> I don't have MacPorts installed - get along well with finnk
<nessy> is my only option to install from src ?
<aadis> nessy: installing from source is pretty simple as it is
<nessy> am in the middle of it - but still wondered if there was a more adequate release :)
<nessy> hmm - need to instally pycrypto and paramiko and make sure my default python is 2.5 :(
<nessy> might as well upgrade to leopard!
<tallo> nessy: according to the first line of http://bazaar-vcs.org/BzrForeignBranches/Subversion (which I've been working from)
<tallo> sudo easy_install -U paramiko pycrypto bzr
<tallo> claims that it should work for tiger and leopard
<tallo> except some stuff about xcode 2.5 and libtool...
<nessy> easy_install : command not found :)
<nessy> I don't have xcode
<tallo> ouch
<tallo> Oh, heh
<nessy> but they were simple to install from src
<nessy> just running test on paramiko
 * tallo is happy on leopard
<nessy> yeah - I should upgrade...
<tallo> just having issues with bzr-svn :)
<nessy> oh! :(
<tallo> The upgrade was a pain on my macmini server box, as I'd forgotten how I'd configured it. :)
<nessy> I just have a macbook
<tallo> the leopard installer did a bunch of bad stuff, like overwrite crotab :(
<nessy> that's what backups are for :)
<tallo> thankfully there was only 1 cron line :)
<tallo> didn't nuke any "user data", just made exim and apache unhappy
<nessy> if you remembered your crontab, that's ok :)
<tallo> again, mostly because I forgot what I'd done a year before to configure it in the first place
<nessy> hmm... the paramiko test hangs after Ran 100 tests in 110.393s
<nessy> OK
<nessy> strange...
<nessy> looks like it worked:
<nessy>  bzr --version
<nessy> Bazaar (bzr) 1.1.0
<nessy> :0
<thatch> For future reference, the issue with trac+bzr and 'unsupported version control system' under mod_python just required a complete stop/start of Apache to work.
<lifeless> cool
<lifeless> how are you going thatch ?
<thatch> lifeless: I'm doing pretty ok.
<thatch> Just got over some sort of cold
<thatch> and school is keeping me occupied enough that I'm happy writing code
<lifeless> :)
<turnip> Hi guys, I'm new to bzr and dvcs in general. I think I'm fundamentally misunderstanding something... if I do "bzr branch someurl", I get a load of files. They have to exist somewhere, right? But if I do "bzr push someurl", it doesn't transfer the files, just the changes. So how do the files get to the remote server?
<lifeless> turnip: the files are your working copy
<lifeless> turnip: we don't copy around the working copy itself, because thats slow, we only copy the historical database
<lifeless> if someone else whats what you've committed they can just bzr branch the thing you pushed
<turnip> lifeless: surely then they have to have access to my machine?
<lifeless> huh?
<turnip> to get the files I've committed, they would need to be able to transfer them from my machine somehow
<turnip> because they aren't on the remove server
<lifeless> when you push to a remote server
<lifeless> the historical data base is pushed
<lifeless> it contains the information to recreate a working copy
<turnip> aaah right
<lifeless> have you used svn ?
<turnip> yeah
<lifeless> right - an svn server doesn't have your files in an editable form
<lifeless> it just has a databse
<lifeless> called a repository
<turnip> yeah, I think I understand now
<lifeless> but the svn client can ask the repository for enough information to create a working copy
<turnip> yep it makes much more sense now. I wasn't thinking in terms of repositories because of the whole distributed thing
<turnip> so what I want to use this for is a personal website. I basically want to make commits on my local machine, and then every now and then update the web server with the changes
<turnip> given that the web server can't connect to my machine, but I can connect to the web server
<turnip> does it make sense to push the changes to the server, and then have a branch on the server which is a working copy... ?
<rolly> turnip: that's how I have it.
<turnip> ok great thanks for your help guys
<rolly> I use the push-and-update plugin
<lifeless> turnip: sure; on the web server have a working copy and do 'bzr update' there
<lifeless> turnip: the push and update plugin will use that to do an update for you when you push
<turnip> ok thanks I'll check it out
<xif> hey, I was wondering:
<xif> at the time bzr was developed, why didn't Canonical just use the available Mercurial tool?
<lifeless> hg did not exist when bzr was started
<ubotu> New bug: #190052 in bzr "bzr commit on a split tree crashes" [Undecided,New] https://launchpad.net/bugs/190052
<LarstiQ> oh boy
<lifeless> LarstiQ: dude!
<lifeless> its alive!
<LarstiQ> I seem to be getting alive again, this much is true.
 * LarstiQ has even been reading code today
<fullermd> Shucks.  I had the high voltage all ready, too...
<LarstiQ> granted, not bzr, but still
<beuno> LarstiQ, python at least?
<LarstiQ> beuno: yes
<LarstiQ> bug 190052 looks like something I'd need to look at
<ubotu> Launchpad bug 190052 in bzr "bzr commit on a split tree crashes" [Undecided,New] https://launchpad.net/bugs/190052
<lifeless> xif: also, even if hg had existed, they have sufficiently problematic limitations I doubt we would have gone with it.
 * beuno starts preparing for the "welcome back LarstiQ" party
<lifeless> thats in London right ?
<LarstiQ> is that a suggestion I should attend?
<LarstiQ> wouldn't do to miss my own party
<lifeless> LarstiQ: naturally
<LarstiQ> k
<tallo> jelmer: So, I'm guessing this has to do with swig not having the full environment when extracting function defs
<tallo> There are some #defines for keychain support; when I hardcode them to #if 1, I get some bits of keychain_simple_provider in the wrapper
<tallo> not enough, yet
<igc> morning
<Odd_Bloke> Why is it that ConfigObj is kept in bzr.dev?
#bzr 2008-02-08
<xif> lifeless: what "problematic limitations"?
<ecognito> Hi.  Would anyone have any code that hooks post-push to send an email?
<beuno> ecognito, maybe you're looking for: https://launchpad.net/bzr-email/
<ecognito> That sends an email on a commit.  I want it on the push, so it will notify the members of the group automatically when there is something useful to pull.
<lifeless> xif: no versioning of symlinks,directories,renames[hg does renames now, but by copy+delete semantics]
<lifeless> abentley: ping
<lifeless> abentley: I'm seeing the index as being about 30% of runtime using my branch to checkout --lightweight bzr.dev with no accelerator tree
<lifeless> abentley: where is your branch again; I'll merge it in and test
<jkakar> I'm really impressed that bzr detects criss-cross merges and helps me figure out how to make completing the process as painful as possible.  bzr rocks!  It sure does! :)
<lostylost> where abouts is the main configuration for bzr kept?
<lifeless> bzr --version will tell you
<lostylost> thanks! sorry in a hurry, otherwise I would have scoured more
<lostylost> Is anyone here familiar with the email post commit hook plugin?   the post_commit_to setting is put in bazaar.conf?
<lifeless> 'bzr help email' should describe how to configure it
<lostylost> Yeah, I tried that, I am quite new to bzr, it says to set the post_commit_to setting but not exactly where. I am thinking in bazaar.conf?
<lifeless> yes, bazaar.conf or locations.conf
<lostylost> thanks
<lifeless> docs.bazaar-vcs.org has complete documentation on the config files
<ubotu> New bug: #190096 in bzr "doc use of revert --forget-merges to create commits without history" [Undecided,New] https://launchpad.net/bugs/190096
<lostylost> thanks lifeless
<abentley> lifeless: http://code.aaronbentley.com/bzr/bzrrepo/fast-iter-files-bytes
<abentley> lifeless: that branch caches nodes, and when I accidentally disabled the cache, it seemed about a second slower.
<lifeless> abentley: caches nodes?
<lifeless> abentley: do you mean an additional cache on top of the index?
<abentley> Yes.
<abentley> It shouldn't help but it seems to.
<lifeless> abentley: ok; I'm doing a quick-fix to reduce index queries, I hope it will fit well with what you;ve done (its about a 30-minute thing), I'll post it in a minute
<lifeless> basically just tweaking get_components_positions to only ask the index once per component rather than 3 times
<abentley> lifeless: I don't think I use get_components_positions at all.
 * igc food
<skvidal> I have an unbound branch I'm working on
<skvidal> is there any way to have bzr push just go to wherever I branched it from?
<skvidal> so I don't have to specify where?
<abentley> skvidal: You only have to specify the first time.
<abentley> It remembers after that.
<skvidal> okay
<beuno> skvidal, and if you want to overwrite the current one, just add   --remember
<lifeless> abentley: _get_component_positions was teh core workhorse before your patch; I'd hope you either refactored or deleted or something :)
<skvidal> thanks
<lifeless> abentley: anyhow its doing a test run across all tests then I -> send and forget
<abentley> lifeless: Not yet, because so far, I'm only supporting packs.
<lifeless> k, well I'll look at your patch shortly, I may have some feedback for you ;)
<abentley> So far, the best time I've gotten out of yours is 4.554, which is at least 500 ms faster than my best time without indices.
<abentley> without your index fixes, I mean.
<lifeless> well thats promising
<abentley> Sorry, 50ms, not 500
<lifeless> pushing a new version now
<lifeless> up to 1/2's the number of IO round trips
<abentley> ooh, 4.514
<abentley> 4.429
<lifeless> revno 3221 is pushed
<abentley> I don't see it.
<lifeless> abentley: on people ?
<abentley> No, on bazaar.launchpad.net
<lifeless> it will be up to 6 hours behind
<abentley> but, but, it supports the smart server.
<lifeless> rather useful huh? But the lp guys tell me that I won't get a button to tell it to mirror till > lp 2.0 at least
<lifeless> pack streaming is ~=. The index stuff is however much nicer in bzr+ssh now
<lifeless> I should get bzr+http up on my people branches.
<lifeless> give the sysadmins something todo.
<lifeless> :>
<lifeless> seriously speaking I will need a place to test that if we ever want it to come up to scratch speed wise
<abentley> Why do you prefer it?
<lifeless> I make new branches continually
<abentley> (and yes, I've got it now.)
<skvidal> abentley, beuno: thank you for the help - it does work happily now
<lifeless> Until we fix the cost of uploading new branches to the hosted site, it is prohibitive for me
<lifeless> that index fix is sent to the list as well
<abentley> Hmm.  Maybe I have bzr+ssh on rookery...
<lifeless> wooo
<lifeless> 4.6 seconds!
<lifeless> that knit index fix shaves 1 second user time
<abentley> The best time I've seen with 3221 is 4.589
<lifeless> wall clock I have 5 seconds down from 6 seconds
<lifeless> (I'm using the patch I just sent to lp with my rev 3221
<lifeless> I'm going to merge your branch now and compare
<abentley> 4.461
<abentley> ooh, 4.380
<abentley> So wall clock time is ~4.4 - 4.7
<lifeless> your branch gives me 4.4 wall clock
<lifeless> so 6 seconds bzr.dev, 4.4 yours and my range-map, 5 range-map + knit-index-tweaks
<lifeless> I'm looking at your branch's code now, and callgrinding
<lifeless> oh, it has storage in it :(. I'll go reply to that thread now.
<abentley> I'm following your (kind, (file_id, version)) suggestion for the index_keys, and that seems to work nicely.
<lifeless> cool
<abentley> lifeless: I don't insist on Storage for this code, but I still think it's the right idea for other reasons.
<abentley> Anyhow, that's why I said not to freak when you saw it.
<lifeless> abentley: ok! I'm not freaking, just fixing up a procrastinated mail-reply I owe you :)
<abentley> lifeless: bzr+ssh kinda works on rookery.  Gives bzr: warning: unsupported locale setting
<abentley>   Could not determine what text encoding to use.
<spiv> LANG=C "fixes" that.
<mwhudson> spiv: do your magic thing to pull plz
<mwhudson> sorry, push
<abentley> spiv: why does get_data_stream_for_search return a single read function for the results?
<abentley> It seems to require buffering stuff in a StringIO
<abentley> I would have thought something more like what you did with containers.
<lifeless> abentley: a comment on the approach; rather than a lot of static methods, did you consider just generalising *KnitIndex's responsibilities to be for (type, id) rather than just a single id ?
<lifeless> abentley: a fairly trivial adapter could implement that for normal Knits on top of the current _KnitIndex
<lifeless> abentley: and the current KnitGraphIndex could actually become simpler and faster by not doing StripPrefixAdapter usage
<lifeless> abentley: actually, skipping the (type) and just allowing a file_id into the keys would probably be cleaner in the short term with the way that maps to a single logical index
<abentley> I guess I hadn't really thought about it.
<abentley> I was focusing on making Storage present an apparently-unified index for all item kinds.
<lifeless> in this particular case if you called 'Storage' 'MultiKnit' or something
<lifeless> and had it implemented in knit_repo and pack_repo as appropriate, I think it would fall out quite nicely; particularly if we move our callers to it.
<lifeless> ok, your branch is definately nice and fast
<lifeless> get_build_requirements is 33% for me
<abentley> Sure, I can rename it.
<lifeless> 20% in _read_and_parse
<abentley> And I do want to support it for both knit_repo and pack_repo.
<lifeless> abentley: (well I meant renaming and not having all those static methods :))
<lifeless> 18% in _parse_regioj
<lifeless> I'll focus on _parse_region
<abentley> Nice.
<lifeless> 15% in _parse_lines though, perhaps its time for a C extension there
<lifeless> abentley: if you could eyeball my knit speed patch, its quite a win in and of itself
<abentley> Those static methods are a bit thorny for me, because I'm using them in ways I wouldn't want to use a KnitGraphIndex.  But I can't remember the details ATM.
<lifeless> right, this is what I mean about generalisation
<lifeless> KnitIndex can be unchanged
<lifeless> MultiKnitIndex creates new knit indices and calls onto them
<lifeless> GraphKnitIndex gets renamed to something like LegacySingleGraphKnitIndex
<lifeless> a new GraphKnitIndex is one that supports a single key space from the get-got
<lifeless> and KnitVersionedFile gets its api changed, and is given the new index type directly
<lifeless> this avoids needing to get at internal index methods from your super-efficient class, because it is now part of the structure rather than an outsider
<lifeless> (paraphrase: roll the Knit api forward to be more powerful(
<abentley> I see what you're saying.
<abentley> Man, I have got to find the time to work on my gtk merge-directive-applying tool.
<abentley> lifeless: The next key bit I see for my branch is ensuring it doesn't consume all available memory.
<abentley> After that, compatibility with standard knits.
<c1|freaky> it's a  pitty the trac plugin doesn't really work
<c1|freaky> :(
<johnny> well.. trac doesn't work very well with distributed vcs
<johnny> atm
<johnny> it only works really well with subversion, it was written too tightly around it
<johnny> they are working on it
<johnny> for the next version of trac
<abentley> Yeah, it's got too many wrong assumptions about the APIs a VCS might use.
<johnny> any of the plugins are hacks
<c1|freaky> is there anything like trac for bzr?
<c1|freaky> or is there at least some kind of webinterface to browse files etc.?
<johnny> launchpad?
<johnny> hehe
<abentley> For example, in order to tell you what files have changed, it gets the two versions and compares whether they've changed.
<abentley> Instead of just asking the VCS which files have changed.
<johnny> ii'm sure there is a way to browse files for bzr ...
<johnny> gotta be
<spiv> c1|freaky: there are a couple of web interfaces to browse files in bzr branches.
<Debolaz2> Is the launchpad code available?
<c1|freaky> no
<c1|freaky> closed source
<spiv> c1|freaky: there's loggerhead, which launchpad uses (e.g http://codebrowse.launchpad.net/~bzr/bzr/trunk)
<johnny> not yet
<johnny> maybe some day
<c1|freaky> and what is the best webinterface for bze repos?
<spiv> (And loggerhead is open source.)
<c1|freaky> ok im having a look at it
<spiv> There's also the "bzr webserve" plugin, but I think loggerhead looks nicer.
<johnny> in the cases where they are multiple options, very rarely is one better than the other to everybody
<johnny> at that point it's usually a matter of opinion
<johnny> just like all open source stuff :)
<c1|freaky> spiv: where can i download it
<johnny> pull it via bzr
<c1|freaky> how to do that?
<c1|freaky> ill search for it
<johnny> there we go :) that's a good answer :)
<spiv> c1|freaky: https://launchpad.net/loggerhead
<c1|freaky> thank you
<c1|freaky> :)
<johnny> ok.. grocery store time
<abentley> lifeless: I bb:approved your patch.  Guess the list is slow.
<lifeless> abentley: cool; I'll submit it now. I'm about to head trainward
<lifeless> any changes needed - my mail client is closed
<abentley> No.
<lifeless> thanks
 * lifeless waves
<Peng> There's also bzrweb.
<Peng> And I think another.
<freakyy> hi im c1|freaky
<freakyy> umm
<freakyy> im trying to run loggerhead but it says
<freakyy> ImportError: No module named bzrlib
<freakyy> someone knows what is missing?
<mwhudson> um
<mwhudson> is bzr installed?
<freakyy> yea
<mwhudson> are you running loggerhead with the same python as the one that has bzr installed?
<freakyy> one moment
<Peng> freakyy: There's also bzrweb, and I think another one.
<freakyy> hm i have to set up every repo with loggerhead
<mwhudson> you can point it at a directory of branches
<freakyy> i can't find the port setting
<freakyy> :\
<freakyy> http://bzr.code-1.de everything working now :D <-- loggerhead with http proxying :D
<etteyafed> Anyone know of a good CGI interface for bzr?
<etteyafed> Like to manage a bzr tree from a web server.
<etteyafed> Absolutely must be GPL/FOSS though.
<bob2> https://launchpad.net/loggerhead is a viewer
<etteyafed> That would be useful. I also need a management interface though. I was planning on writing it in house but if there is something available I would like to consider it and at least look at the design.
<bob2> what do you mean by management?  there's things like bundlebuggy and cart.
<etteyafed> I could probably Adapt logerhead for that really.
<etteyafed> I mean doing things like bzr add, commit, resolve, merge, update, etc, and be able to configure default arguments for each of the commands.
<etteyafed> but with a web interface
<etteyafed> so no shell login is needed
<freakyy> does cart yet have a developer team or a website?
<etteyafed> Obviously there are other things on the server side and security side that I have already implemented to make something like that work for multiple users in a secure way. Do cart or bundlebuggy do those things (the bzr mgmt stuff)
<etteyafed> I am really just looking at getting bzr vcs functionality to our users without making them login to the system and learn all the commands.
<bob2> it kinda sounds like a cms is more waht you want
<etteyafed> no this is for the vcs of source code
<etteyafed> code maintained by users for users on a remote server
<etteyafed> so bzr is the way to go I think, or some other vcs, but I prefer bzr
<bob2> there's olive, a tortoise*-alike
<etteyafed> olive is, as you know, run locally
<etteyafed> and not on the server, nor is it cgi
<etteyafed> it is in GTK I am pretty sutre
<etteyafed> sure*
<etteyafed> Trust me. I know what I need. I just don't know if it already exists in some form or not.
<etteyafed> I think cart might work very well if I add some things here and there, but I am not sure since I have not really looked at it yet.
<Peng> How would one work with that? How would you edit files?
<Debolaz2> How does bzr deal when I want to make a lot of small changes, but then later squash them into a big change for inclusion into the main branch?
<etteyafed> Peng: Well you log in, and you then have edit rights to any files that you own and create files in your personal space, project, or in a team space of a team you are a member of. The editing is done in a JS test editor or in an editor of your choice that can be configured in your profile and when you are done the edited version of the file would be sent back to the server. In order to use a local editor you would obviously need to 
<etteyafed> Peng: And the bzr commands are available to any user to use on any branch that they have rights to.
<Peng> etteyafed: Your first line ended with "In order to use a local editor you would obviously need to".
<etteyafed> Peng: install a launcher script that will collect the edited file from the a temp dir (like /tmp in a *nix)
<etteyafed> must have gotten cut off by the server
<Peng> IRC line length is limited.
<etteyafed> Sure is
<Peng> Your client should've been smart enough to break it for you.
<etteyafed> My client knows that and should have cut it sooner
<etteyafed> but that limit varries form server to server and apparently pidgin has decided not to ask the server and just assumes a "resonable default" or something
<etteyafed> but I have found that even in the case of line limits you are something like -40 chars in reality. not sure why, but I had that same problem with an irc bot.
<AfC> Yikes! What on earth does
<AfC> bzr: ERROR: Pack 'f8987ec441dc91318f8fd1a99e6c5f42' already exists in <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0xb74a174c>
<AfC> mean?
<fullermd> I s'pose it could mean you found a hash collision.
<AfC> [was during an attempted `bzr push bzr+ssh://...`, both sides bzr 1.1]
<fullermd> You could probably repack the far side to get rid of it...
<AfC> repack?
<fullermd> Yeah, assuming it's not all in one pack already.  That would get rid of the colliding name.
<fullermd> Not sure why you'd end up with it in the first place, short of a real collision (which is impressively unlikely).
<fullermd> But it's a workaround.
<AfC> I kicked off a `bzr check`. We'll see if it reports anything, and then I'll try again.
<AfC> Hm. Second attempt at push "just worked" (and quickly, too).
 * AfC wonders if there was network damage somewhere along the way, and what the likelihood of repository damage is.
<igc> night all - have a good wekkend
<etteyafed> like brain damage, its hard to tell ;)
<AfC> heh
<etteyafed> unless its profound
<etteyafed> then its all screwed anyway
<AfC> Well, I did a full branch to a blank repository and have the test suite running. That's a reasonably astute check.
<etteyafed> yeah. figure you have X revisions times x files of x bytes in size / packets transmitted  blah blah blah - 3.14 = the chance of any one revision getting messed up
<etteyafed> by some unknown network data coruption
<etteyafed> that is in its own rather unlikely
<etteyafed> because malformed packets are generally disgarded
<etteyafed> so I like bzr how about you :). yeah I am nuts and going to bed.
<mtaylor> etteyafed: there is corruption at the nic level
<mtaylor> etteyafed: which sadly, I have actually seen multiple times this last year
<mtaylor> etteyafed: essentially, the NIC checksum offloading was lying :)
<etteyafed> that is just terrible. I have not come across such things I am happy to say, at least not that I knew of. I have had to replace bad cards though.
<fullermd> It's unpleasantly un-rare, especially with cheaper NIC's.
<AfC> I just tried adding a branch to launchpad, and it bombed out with Â«The URI scheme "bzr" is not allowed.Â» That's famous.
<AfC> Pfft. So much for bothering to add data to that thing.
<mwhudson> AfC: for a mirrored branch?
<AfC> mwhudson: yeah. I was just trying to Do The Right Thing as I happened across the fact that I had previously registered a branch there some time ago. So I thought I'd add a few more, and boom. Most impressive.
<mwhudson> AfC: hmm
<mwhudson> AfC: file a bug, i guess
<appcine> Hi. I'm currentÃ¶y using svn as the single developer on multiple projects. I need to work in a centralized environment. Why should I switch to  bazaar? I branch a lot in svn, which is a pain and I hear you've fixed. And refactor a lot, but I think svn rename works ok.
<fullermd> Why do you need to work in a centralized environment?
<Debolaz2> appcine: Bah, just mentioning branching and subversion in the same sentence gives me nightmares. :(
<fullermd> (That's not an attempt to be combative, BTW; it's to quantify the real constraints.  'centralized environment' means too much and too little most of the time)
<bialix> hdima: privet
<hdima> hi
<appcine> fullermd: Well, because I'm behind a firewall
<appcine> fullermd: I need a drop-point
<appcine> fullermd: so, that's what I need more than a CVCS :)
<fullermd> OK.  Which way is that a problem?  Do you mean "I need a repo outside the firewall, so I can see it from somewhere else", or "I need a repo inside the firewall, 'cuz I can't see out"?
<appcine> I have three client and a svn server today. The three clients are on separate networks with no portforwarding possibilities and they all have dynamic ips. So, I need _something_ to use as a drop-zone or whatnot, be it a svn server, ftp http :)
<fullermd> OK.  Well, you can use a central branch and checkouts, which will give you pretty much the svn workflow (just better dealing with branches etc, and faster ops since checkouts have a local cache)
<fullermd> You could step back from that a bit and use regular branches, but push to the central server "when necessary" (if you can quantify that 'when necessary' well enough, and trust people to do so)
<fullermd> And of course you can mix and match; use checkouts on a central branch, but also make local branches for stuff.
<appcine> Ok, sounds good to me :) By the using the svn workflow, what am I missing really?
<fullermd> Well, you're missing all the power and flexibility of ultimate-distribution full-mesh style workflows.
<fullermd> You're also missing the irritation and frustration of ultimate-distribution full-mesh style workflows    ;)
<fullermd> The key thing to grab onto is that it's not all-or-nothing.  You can have a SVN-style workflow that everybody BUT you uses, and you can still work more distributed yourself, just tieing into the central branch when you have stuff to land.
<fullermd> And you can change over time how you do stuff; the way you set it up initially doesn't have to tie you in forever.
<appcine> Ok
<etteyafed> is there a way I can push to a branch so that that branches working tree is updated and maybe commited at the same time?
<fullermd> So you can set it up pretty much like you use svn now, and worry about changing one thing at a time.
<appcine> fullermd: Sounds about perfect
<appcine> fullermd: The reason I'm here ist hat people say that branching is so easy in bzr. How do oyu do it in bzr?
<appcine> Well, branching and that people say it's renaming facilities are better, even though I've never eally had any problems witht hat in svn (unless in a huge refactoring session adn you forgot to branch :)
<etteyafed> appcine: I use bzr branch FROM_LOCATION [TO_LOCATION]
<appcine> etteyafed: Then cd TO_LOCATION and hacka awy?
<appcine> away
<etteyafed> appcine: but there are other ways of accomplishing basically the same thing
<Odd_Bloke> etteyafed: To update the working tree, look in to the push-and-update plugin.  I'm not sure what you mean by 'commited at the same time'...
<etteyafed> Odd_Bloke: Well it doesn't need to be commited, and that is actually kindof wrong
<etteyafed> Odd_Bloke: But this plugin is it part of bzr?
<fullermd> appcine: Right, just that.  'bzr branch trunk work_on_foo ; cd work_on_foo ; <work>'
<Odd_Bloke> etteyafed: You'll have to install it yourself, but it is a bzr plugin.
<fullermd> appcine: Now, that creates a local branch.  If I want to make that an additional central branch that I can work lockstep with other people on, I'd push it up to the central server, then use 'reconfigure' to change my local branch into a checkout of it.
<etteyafed> I am looking for it at this very moment
<appcine> fullermd: So I kep working on trunk and refactor in work_on_foo, then I merge them how? bzr merge work_on_too trunk?
<fullermd> appcine: You _could_ directly create a remote like "bzr branch bzr+ssh://server/foo bzr+ssh://server/bar", but I don't think there's any optimization of that, so it would probably copy all the info across your network twice   :|
<appcine> Ah
<Odd_Bloke> etteyafed: https://code.edge.launchpad.net/bzr-push-and-update
<fullermd> appcine: Well, depends on which way you merge.  If you're done with 'foo', you can "cd trunk ; bzr merge ../work_on_foo", check the result, and commit it.
<appcine> Ok
<fullermd> appcine: Or if you've done a lot of trunk, and you've got more left to do on foo, you can do it the other way; be in foo and "bzr merge ../trunk" to resolve the differences then (and save yourself trouble later), then keep going on.
<fullermd> And if foo is multi-part of course, you can merge it into trunk as in the first example, then keep working on it and merge again later.
<appcine> Sounds easy enough. I'm printing the manual now, so I shouldn't exhaust you .. but there is one last thing I'm wondering about :)
<appcine> Does bzr have anything like svn hooks?
<appcine> Like, If I commit to the server, can it automatically do something?
<fullermd> Yes and no and much better and sorta.   :)
<fullermd> Currently, none of the hooks fire on the server side; they're all client-side.  We've just had (or are still having) a thread on the list about moving that forward.
<fullermd> So I'd expect movement on that over the next few months.
<appcine> Ok
<appcine> I'll give it a run for its money then :)
<appcine> Thanks a lot for the introduction
<fullermd> No prob   :)
<etteyafed> Odd_Bloke: How do I install that?
<etteyafed> just user the script?
<Odd_Bloke> etteyafed: Assuming you're on a *NIX, "bzr branch http://bazaar.launchpad.net/~bzr/bzr-push-and-update/trunk ~/.bazaar/plugins/pushandupdate"
<etteyafed> yeah linux
<etteyafed> heh. I branched to my home dir.
<etteyafed> ill just mv it
<etteyafed> maybe
<Odd_Bloke> Move it to something along the lines of "~/.bazaar/plugins/pushandupdate".
<Odd_Bloke> The "pushandupdate" can change, but needs to be a valid Python module name.
<etteyafed> Odd_Bloke: Sweet. Thanks. Now I can don't have to bounce back and forth between terminal windows to get a change in the main tree.
<etteyafed> Server hooks would be awesome. but I need sleep, so I guess ill dream about them.
<Odd_Bloke> etteyafed: Glad I could help. :)
<garyvdm> ls
<fullermd> . ..
<Dejan> hello
<Dejan> guys, is it possible to download bzr documentation in some form?
<Dejan> i mean ok, i can mirror it via wget
<Dejan> but it is strange the documentation cannot be downloaded (at least i could not find the place) in some form of chunked html or pdf
<Dejan> :)
<Dejan> bzr is excellent
<dato> Dejan: it *should* come bundled with your packages, debian's and ubuntu's eg. ship it
<dato> Dejan: if you installed from source, you can *build* the html, using docutils
<Dejan> dato, i am getting the source at this moment
<Dejan> it is kinda slow for some reason
<Dejan> (bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev is on 30% and it is so for 20min)
<Dejan> i guess ktorrent is the reason :)
<dato> Dejan: I'm afraid it's just slow, but the doc also comes in the tarballs
<Dejan> dato, i tried to find tarballs on the website
<Dejan> bazaar-vcs.org
<Dejan> no doc packages there
<Dejan> to download
<Dejan> i must check if they have some "request for enhancement" place
<Dejan> so i can file a request :)
<dato> Dejan: the tarballs have a doc/ subdirectory
<Dejan> ah, i have it!
<Dejan> in /usr/share/doc/bzr-1.1
<Dejan> :)
<Dejan> sorry mate, i was lazy to check that
<Dejan> actually it is even better than i thought
<Dejan> it is in asciidoc format
<Dejan> so i can build documentation myself
<Dejan> great
<jjrojo> somebody can help me for start using bazaar?
<turnip> Hiya. Is there any simple way to do this... I want to pull some vendor code into my project but still be able to update it. Their repository is subversion - so I want to import the code into my bzr branch, and then occasionally update it from their repository?
<Zindar> bzr-svn is what you want
<turnip> ok cool. so say I have a working copy at "myproject", and I do "bzr pull svn://whatever myproject/vendor". Then can I later do "bzr update myproject/vendor" and it will get the latest changes from the upstream svn?
<cammoblammo> I'm running bzr 1.0 and I want to upgrade the branch format. Which is the best/safest/recommended at this stage?
<jelmer> cammoblammo: Just running "bzr upgrade" will upgrade the branch to the default format
<cammoblammo> jelmer: Hmm, I did that and I got "bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data."
<jelmer> cammoblammo: Ah, this is a branch created by bzr-svn you're trying to upgrade?
<jelmer> cammoblammo: try "bzr upgrade --rich-root-pack"
<cammoblammo> jelmer: Cool. Are any of the formats preferred on low memory (32MB) machines?
<jelmer> I think packs are more efficient wrt memory usage, but 32Mb may still be a little bit low
<cammoblammo> jelmer: Ha, that seems to be working.
<cammoblammo> jelmer: It seems to go okay, I've just got to give it time!
<cammoblammo> jelmer: Great, that seems to have worked. Thanks!
<jelmer> cool
<jelmer> looks like we need to file a bug about upgrade not choosing the right default
<cammoblammo> jelmer: I'm using the debian sid version. Should I file a bug there?
<jelmer> cammoblammo: yes, please do
<turnip> Further to my question above, I am having trouble working out how to do what I want to do... I am really looking for something like Piston: http://piston.rubyforge.org/ which works with bzr
<dato> ooooooh
<turnip> In other words, I want to "mount" an upstream checkout in my branch and be able to update it
<dato> bzr shell allows normal commands like vi and ls
<fullermd> turnip: If it were me, I'd keep a pristine vendor branch and merge it in as necessary.
<jelmer> turnip: this is something that you can do with by-value nested branches
<turnip> jelmer: can you point me to some docs for that please?
<jelmer> I'm not sure there are any
<turnip> :)
<jelmer> I've got to go for a bit, will be back in ~30 minutes
<jelmer> I'll see if I can find some docs on it then
<turnip> jelmer: thanks
<turnip> for now I'll try branch-and-merge way fullermd described
<fullermd> By-value nested branches are roughly the same thing, just with a little more magic.
<fullermd> (at least, AIUI)
<cammoblammo> jelmer: I've reported that bug to Debian. In answer to your question, the branch was originally an svn repo that came to me via bzr-svn.
<turnip> fullermd: this <http://jelmer.vernstok.nl/blog/archives/164-Bazaar-and-Subversion-nested-tree-support.html> seems to be what I want, if only it explained how it worked ;)
<dato> abentley: I guess I'm late for the party, but... thanks a lot for `bzr shell`
<johnny> anybody seen cvsps-import hang on wait4() right after it says it is generating a dump file?
<turnip> fullermd: I have done a "bzr branch ~/svnupstreamproject" and then a "bzr merge ~/svnupstreamproject ~/myproject/vendor/upstreamproject" but it says: bzr: ERROR: Repository KnitPackRepository('~/myproject/.bzr/repository/') is not compatible with repository KnitRepository('~/svnupstreamproject/.bzr/repository/') - any ideas?
<turnip> (it wasn't those commands exactly but you get the idea)
<fullermd> Yes, bzr-svn projects use a rich root format, so you'll need to move your project over to one too, to merge in the code.
<fullermd> Try upgrading it to rich-root-pack.
<fullermd> Also, I don't think merge can take a second arg for the target; you'll have to bzr mv the files into whatever subdir manually after the merge.
<fullermd> (that's the part the nested tree stuff should magicize)
<turnip> fullermd: Yep I realised that afterwards. I was cd-ing into the myproject/vendor/upstreamproject before running merge. However now I get: "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified."
<fullermd> Right.  Merge figures out the common base to work from, but those branches have no common base, so you need to tell it manually.
<fullermd> Add "-r0..-1", to tell it "from the beginning, to the end"
<turnip> fullermd: Thanks for your help. I've gotta go eat now but I'll be back in a bit :) cheers
<johnny> hmm..
<alf_makina> hi
<johnny> hmm, having trouble with the cvsps imports again
<johnny> it just hangs on
<johnny> Creating cvsps dump file: infoshopkeeper_bzr/staging/infoshopkeeper.dump
<garyvdm> Hi - I would like to implement my own WorkingTree format. Is there some doc that specifices what methods need to be implemented?
<garyvdm> I want to implement this: http://bazaar-vcs.org/DraftSpecs/RestingTree
<johnny> garyvdm, prolly the python src..
<johnny> if it is properly docced
<johnny> i haven't checked
<johnny> i'm still new to bzr
<alf_makina> when I dot a bzr add, the file is not added
<alf_makina> although it's shown to be added if I do a dry-run
<luks> is it listed as added in bzr st?
<alf_makina> no
<alf_makina> it's in unknown
<luks> and if you do 'bzr add FILE', what does it say?
<alf_makina> nothing
<alf_makina> to init my branch I've made a bzr co svn+ssh://...
<luks> ouch
<luks> no idea how does that work on a svn checkout
<alf_makina> :-(
<jelmer> alf_makina: "bzr st" lists no files at all?
<alf_makina> jelmer: it lists all files as unknown
<alf_makina> all unversionned files
<jelmer> how exactly did you create this branch?
<alf_makina> bzr co svn+ssh://...
<jelmer> ok, the fact that it comes from svn shouldn't matter
<alf_makina> I'm new to bzr and try to use bzr for local commits and then push to the svn repo
<jelmer> have you tried to use "bzr add <absolute-path>"
<alf_makina> well, I've just tried bzr upgrade --dirstate-with-subtree
<alf_makina> and it seems to have broken my repo :-/
<jelmer> Broken it how?
<alf_makina> commit failed
<alf_makina> and bzr st shows that everything has been deleted
<jelmer> what version of bzr are you using?
<alf_makina> 1.1
<jelmer> and bzr-svn?
<alf_makina> 0.4.6
<alf_makina> ok, I've revert the upgrade
<alf_makina> and tried a bzr add with full path, it's not better
<jelmer> You can't revert the upgrade, you'll have to recheckout
<alf_makina> there's a .bzr_backup directory created
<alf_makina> I've deleted the .bzr a put back the .bzr_backup
<abentley> dato: you're welcome
<alf_makina> jelmer: it seems to work for other files
<alf_makina> I check this
<jelmer> alf_makina: The file doesn't happen to be in the ignore list?
<alf_makina> no, I've already check this
<jelmer> sorry, no idea then
<alf_makina> it's weird, I've several java file which can't be added :-/
 * Mez converts 17035 svn commits to bzr with "branch"
<Mez> gonna take about 5 hours :(
<jelmer> alf_makina: Please ask on the mailing list
<fullermd> It goes faster if you have a prime number of commits.
<jelmer> hey Mez
<Mez> jelmer, hey
 * jelmer is still amazed by the amount of knowledge fullermd has present
<fullermd> You don't have to keep it all present if you just make it up as necessary   ;>
<Mez> fullermd, ....
<Mez> lol
<fullermd> If there's a prime number of commits, see, it gets perfect distribution of the hash lookups...
<Mez> jelmer, am I doing it right though ?
<fullermd> (you can't just make up some random thing.  It's gotta sound plausible.)
<jelmer> fullermd: :-)
<Mez> fullermd, lol
<jelmer> Mez: should be, yes
<jelmer> Mez: Be sure to run it inside a shared repository though
<jelmer> Mez: And use the python-subversion from hardy, that doesn't have the memory leak..
<Mez> "inside a shared repository" ?
<jelmer> bzr init-repo --rich-root-pack foo
<Mez> where foo is?
<jelmer> cd foo && bzr branch svn://svn.bla../trunk trunk
<jelmer> where foo is a not yet existing directory
<Mez> ah, I'm not pulling from the svn server
<Mez> I'm going from a local co of a branch in a svn server
<Mez> (downloading 4Gigs isnt going to be good)
<jelmer> that has the same effect
<jelmer> it'll just check what svn url the local co is using
<Mez> jelmer - reallY?
<jelmer> since svn checkouts don't contain any history
<Mez> there doesnt seem to be that much traffic being used though
<jelmer> it's quite efficient
<Mez> what does the --rich-root-pack do anyways ?
<jelmer> Mez: It's the format to use
<Mez> its not an option listed in the bzr help init-repo though
<jelmer> Mez: It's only in bzr >= 1.0
<Mez> 0.90.0
<Mez> :(
<jelmer> ouch
<jelmer> in that case, use --dirstate-with-subtree
<Mez> lol
<jelmer> however, 1.0 or 1.1 is going to be a lot faster
<Mez> tis ok, 1.0.1 is in backports
<jelmer> https://bugs.edge.launchpad.net/gutsy-backports/+bug/184386
<ubotu> Launchpad bug 184386 in gutsy-backports "Please backport bzr-svn (0.4.5-1) from Hardy" [Undecided,Fix released]
<Mez> ...
<jelmer> you want the backport for bzr-svn as well, otherwise bzr-svn breaks
<Mez> I thought i was just using a checkout!
<CardinalFang> 1.1 speaking to 1.0 "bzr+ssh", "branch", How can I find out what "bzr: ERROR: Generic bzr smart protocol error: Generic bzr smart protocol error: bad request '54'" means?
<Mez> jelmer - ah - it was only backported 28 minutes ago
<Mez> hasnt made it to the archives yet
<fullermd> CardinalFang: You sure that's 1.1, and not a bzr.dev?
<CardinalFang> Eh, no, I'm not sure.  It probably is dev, around snapshot time.
<CardinalFang> So, don't use dev.  Got it.
<fullermd> There is (was) an interop issue with .dev against older servers.  It was fixed...   a day or two ago?
<jelmer> Mez: Ah, whoops. Is there something like an "incoming" directory for ubuntu?
<Mez> jelmer... everything gets put through the buildds... so it depends
<Bloged> Good day....
<Bloged> I'm using bzr as an central repository
<Bloged> But this morning my colleagues PC crashed during committing a branch
<Bloged> Now committing to that branch is impossible
<jelmer> Bloged: what error do you get when committing?
<Bloged> bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'as_dict'
<Bloged> And a traceback
<jelmer> Please file a bug report including the traceback
<jelmer> I'm also happy to ahve a look now
<Bloged> Ok will file bug
<jelmer> but this is also definitely a bug
<Mez> jelmer, hasn't even hit waiting for buildds yet
<Mez> https://edge.launchpad.net/ubuntu/gutsy/+builds?build_text=bzr-svn&build_state=all
<jelmer> ah, so that's where status for packages can be followed
<jelmer> thanks
<Mez> jelmer, one of the palces
<Mez> places
<Mez> https://edge.launchpad.net/ubuntu/+source/bzr-svn/ = another
<Bloged> Jelmer and anyone intrested in the bug:
<Bloged> https://bugs.launchpad.net/bzr/+bug/190204
<ubotu> Launchpad bug 190204 in bzr "After PC crash during commit, commit impossible in that branch" [Undecided,New]
<Peng> Doh, I just wanted to say something to CardinalFang.
<Peng> Bloged: Try 'bzr break-lock sftp://branch/url'.
<ubotu> New bug: #190204 in bzr "After PC crash during commit, commit impossible in that branch" [Undecided,New] https://launchpad.net/bugs/190204
<Peng> Bloged: The lock file exists but is empty, which bzr doesn't handle well, since the only way it can happen is if the computer crashes or something.
<Peng> Bloged: You're the second person to experience this this week.
<Peng> I guess bzr is getting popular among people with unreliable servers? ;)
<Bloged> Peng: break-lock doesn't work
<Bloged> Or unreliable OS's
<Bloged> Since it was the workstation that crashed...
<Bloged> Should I remove the lock file?
<Peng> Hold on.
 * Peng plays hold music.
<Peng> Ok, the mailing list message really didn't say anything very useful.
<Peng> I don't know if it's safe to manually delete the lock yourself. bzr break-lock might help make other things consistent too.
<Bloged> Yep but break-lock fails too
<Bloged> The lock directory is empty BTW
 * Peng shrugs.
<Peng> There are multiple lock directories, FWIW.
<Bloged> Ok....
<Peng> A quick look suggests break-lock doesn't do anything else, but I'm not sure.
<Peng> You could back it up and then try deleting broken-looking locks.
<Peng> I really don't know how careful you need to be here.
<Bloged> I can't find any dirs with lock information in them :$
<ubotu> New bug: #190209 in bzr "branching lp: uris does not use system http proxy" [Undecided,New] https://launchpad.net/bugs/190209
<vinc456> hi, i'm running on debian stable and currently have Bazaar (bzr) 0.11.0)'
<vinc456> installed. I'm planning to use bzr for a group project at school and am wondering if I will have any issues if my classmates are running on 1.1
<beuno> vinc456, you are likely to have many problems if you're using 0.11. I would suggest to upgrade yourself to 1.0+. I believe it's available in backports for debian
<vinc456> i see, thanks
<beuno> :D
<garyvdm> I'm running this code: http://pastebin.org/18707
<garyvdm> I would expect it to create the lock dir at mybranch/.bzr/remotetree
<garyvdm> but it is creating it at mybranch/remotetree
<garyvdm> Why is this?
<jelmer> garyvdm: I think you're specifying root_transport
<jelmer> rather than transport
<garyvdm> ok - let me try use bzrdir.get_branch_transport()
<garyvdm> bzrdir.transport works. Thanks jelmer
<ubotu> New bug: #190221 in bzr "bzr commit should sanitize input arguments on case-insensitive filesystem" [Medium,Confirmed] https://launchpad.net/bugs/190221
<ubotu> New bug: #190229 in bzr "SubversionException on bzr branch" [Undecided,New] https://launchpad.net/bugs/190229
<abentley> garyvdm: I think that would not be a WorkingTree, because you don't need/want to support commits.  The interfaces you need to support is the
<abentley> Tree interface, which is in bzrlib/tree.py, and is tested in bzrlib/tests/tree_implementations
<ubotu> New bug: #190271 in bzr "hgimport crashes with a weird error: LookupError: data/wigner/articulo_wigner17/12/2007.tex.i: no node 0db46aa6c98e8b6b5f97c988d98bb17fb8b08c2f" [Undecided,New] https://launchpad.net/bugs/190271
<fbond> Hi, is it possible to merge several different revisions from a remote branch and have them appear as separate revisions, with no single "merge revision" owning them all?
<fbond> Do I simply cherry pick each revision, one at a time?
<fbond> Or, I guess rebase would do, too ... ?
<Odd_Bloke> fbond: Cherry-picking each revision would work.
<Odd_Bloke> I've not had much experience with rebase, but I don't think it's what you're looking for.
<fbond> Hmm.  rebase seems to have done the right thing, actually...
<SlimeyPete> Hi. I've not used bazaar before. I'm trying to push a branch but am getting a "Permission denied (publickey)" error.
<SlimeyPete> ah, hang on, found the problem
<vinc456> hi, i'm running on debian stable and just installed a backported version of bzr 1.1. The previous version of bzrtools is not compatible and each time i use bzr I get the error 'Bzrtools is not up to date with installed bzr version 1.1.0.candidate.1.'
<vinc456> can i turn off this message without uninstalling the bzrtools package?
<lifeless> abentley: I woke up with a clear explanation of what about storage feels wrong; its about layering basically, and I think we can probably find some layer that is sensible for writing some higher level stuff in; but much higher level stuff just won't vary at the same point
<lifeless> abentley: I'll reply to the thread with more verbiage when I'm awake and not runnin around trying to buy a dishwasher
<abentley> Okie.
 * abentley is slightly confused, because I thought you'd come around.
<abentley> That if it was renamed, and we enhanced Indices...
<lifeless> for that specific case; not for the grand plan - and thats part of why I can now explain myself I think
<lifeless> as part of this you are very likely onto something and we can find a good compromise
<bedros> I'm new to bzr and got a simple question, can I checkout a single file out of a branch in a central repository and edit it w/out copying the whole branch into my hard drive
<bedros> anyone awake here?
<abentley> You can't check out a single file.  Bazaar versions snapshots of working directories, not single files.  You can extract a single file with "bzr cat", though.
<johnny> has anybody here used the cvsps-import. I'm having trouble with with it hanging right after Creating cvsps dump file:
<johnny> maybe something is wrongw ith my download?
<bedros_> thanks, but here's the scenario I have, if I create a branch for a collection of family photos, and decided to edit a single photo on my Mac, I want to check out a single photo edit it and comit it. I don't have room for the entire photo collection on my mac
<bedros_> do you guys think there's a plugin or API I could use to checkout  a single file. or that's not possible with the architecture of bazaar
<johnny> it's not possible with any of this gen of systems i bet
<johnny> i knowi's not possible with monotone
<johnny> git can do partial checkouts i think , but you still get the whole working tree
<bedros_> I'm familiar with perforce and I could do just that perforce server. I just checked subversion, and it's also not possible to check out a single file
<johnny> perforce isn't known for good design tho
<bedros_> I could do "export" or "cat" as someone suggested to get the content of a file,
<johnny> but that is just that file without versioning
<bedros_> yep
<abentley> bedros_: It's 2/3 practicality and 1/3 philosophy.
<abentley> Practicality is, it's easy to do something half-assed, but really hard to get right.  Especially considering things like merging.
<abentley> Philosophy is, when you're versioning source code, you should test your code.  And how can you test it properly if you don't check it all out?
<johnny> i ended up getting my cvs download via scp, i hope that doesn't cause any problems
<bedros_> thanks abentley, I found that svn 1.5-dev is going to support single file checkout; there's also discussion about bzr supporting partial checkout
<Symgeosis> I'm new to Bazaar. I'm trying to merge somebody else's branch into trunk but I keep getting the error "nothing to do" any idea what I'm doing wrong? There are certiainly revisions that have been made to the other branch that have not been made to trunk.
<Symgeosis> Some help on merging two branches would be really appreciated. Please.
<jearl> Symgeosis: What precisely did you try?
<Symgeosis>  bzr merge http://bazaar.launchpad.net/~keith-hughitt/helioviewer/keith
<Symgeosis> I'm trying to merge Keith's changes into trunk.
<Symgeosis> I'm in trunk's dir so I'm not sure what I'm doing wrong.
<jearl> Symgeosis: Are you sure you haven't already merged :)
<Symgeosis> Yup. I checked the commit logs.
<Symgeosis> So I'm really confused.
<jearl> Symgeosis: Is your trunk branch available somewhere?
<Symgeosis> I think I figured it out. I'm such a noob. =/
<jearl> Symgeosis: Good, because I was confused too?
<johnny> it's too bad that cvsps doesnt support :pserver: :(
<jearl> johnny: As someone that has spent a bit of time converting repositories I am glad that cvsps doesn't support pserver.
<jearl> johnny: if your conversion is simple enough that it wouldn't take all day with cvsps you can use tailor.
<Peng> Symgeosis: Do "bzr st".
<Peng> Symgeosis: (short for "bzr status")
<Peng> Symgeosis: You have to commit after merging. If you already performed the merge but didn't commit, it would probably say "nothing to do", but it wouldn't show up in the log.
<Symgeosis> Peng, yeah I figured that out thanks. Though now I'm trying to figure out how to fix conflicts. Interesting learning how to use a VCS.
<Peng> Symgeosis: Ack, I missed you saying you figured it out.
<Symgeosis> Peng, np. Thanks anyways.
<Peng> Symgeosis: "bzr help conflicts" has information.
<johnny> jearl, if i can figure out tailor :)
<Symgeosis> Okay, if this is a really noobish question I apologize, but is there a nice tool (command line or otherwise) that can compare the conflicts and then ask which version you'd like to use?
<johnny> jearl, i downloaded the cvs tree via scp -r
<johnny> i seem to have all the ,v files, isn't that enough?
<Symgeosis> I know I can simply open them both up in a text editor but I was wondering if there was a more streamlined way to merge conflicts.
<jearl> johnny: For cvsps you need the CVSROOT directory too.
<johnny> i have it
<johnny> pretty sure at least
<johnny> i see it, and it has ,v files too
<jearl> johnny: OK, then you are probably good
<johnny> i try to run bzr cvsps-import and it just hangs on Creating cvsps dumpfile:
<johnny> i straced it and it's just in wait4()
<johnny> i accidentally let it go all night and it hadn't moved
<Peng> Symgeosis: There are numerous GUI diff and merge programs.
<Peng> Symgeosis: Meld? KDiff3? I dunno, there are a lot.
<Symgeosis> Peng, okay. Never worked on a project with other people so this is a whole new can of worms for me.
<johnny> the simple diff3 :)
<johnny> Symgeosis, make a sandbox branch to test with
<johnny> so you can play around with things without screwing up other folks
<johnny> good stuff
<johnny> Symgeosis, you'll have more politics issues than code issues :)
<Symgeosis> Johnny, nah. The team is small and we're all employees so it's whatever the boss decides. =)
<Symgeosis> Well, technically, I'm an intern and an employee but until recently I was the only coder as the original coder left before I came on.
<johnny> jearl, so any ideas on that?
<johnny> do i need a specific cvsps version?
<jearl> johnny: check CVSROOT/config and see where the Lockdir is pointed at.
<johnny> i have a bunch of other  files in there, but not that
<jearl> johnny: I would try and see if you can actually check something out of CVS
<johnny> have one :)
<jearl> something like 'cvs -d /path-to-cvs co <packagename>
<johnny> aha. it's trying connect via ssh
<johnny> that obviously won't work
<johnny> i thought you meant remote checkout.. definitely have one of those, but not this one
<johnny> it's trying to connect to my dir
<jearl> johnny: Yeah, you need to try and check something out of your newly created repository that you copied down via ssh
<johnny> johnny@beep ~/projects/redemmas $ cvs -d test/ co infoshopkeeper
<johnny> ssh: test: Name or service not known
<jearl> Do you have a CVS config file that sets a default cvs server or something.
<johnny> i have ~/.cvspass and ~/.cvsps
<johnny> but i deleted ~/.cvsps
<jearl> johnny: I would also try a full path
<johnny> hmm.. ok
<jearl> johnny: I just tried it on my setup.
<jearl> johnny: you need a full path to the cvs repository
<johnny> ok, so now i see more
<johnny> cvs [checkout aborted]: cannot stat /var/lib/gforge/chroot/cvsroot/cvs-locks/infoshopkeeper: No such file or directory
<johnny> obviously that won'to work :)
<jearl> johnny: you have a lockdir set
<johnny> set how/where ?
<johnny> aha.. CVSROOT/config
<jearl> johnny: There should be a "config" file in the CVSROOT
<johnny> can i remove that safely?
<jearl> johnny: you can either comment that line out or you can create the directory.
<johnny> it also has SystemAuth=yes
<johnny> will that cause any problems?
<jearl> johnny: I tend to create the directory because I rsync the CVS stuff and it puts it all back
<johnny> yeah.. i dont have remote rsync access
<johnny> this is not from my own servers
<jearl> johnny: I don't know about SystemAuth, one second
<johnny> i'm just glad that they didn't disable scp, otherwise i wouldn't have anything
<johnny> the project admin hasn't added me to their project to get the full backup
<jearl> johnny: ssh is very handy
<jearl> johnny: I think you can comment out SystemAuth too.
<jearl> johnny: Basically the idea is to keep trying to check out the project from the local repository, when that works then bzr cvsps-import should work.
<johnny> jearl, cvsps needs full path but cvsps-import doesn't
<ubotu> New bug: #190324 in bzr "ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'report'" [Undecided,New] https://launchpad.net/bugs/190324
<johnny> jearl, ok hopefully i can start playing now :)
<johnny> didn't seem to see an option to name the target branch tho
<jearl> johnny: cvsps imports ALL branches
<jearl> johnny: The main branch will be in branches/HEAD
<jjrojo> can anyone explain to me how i make bzr in launchpad
<jjrojo> i don't end to understand the help
<jjrojo> please, i try to migrate from sourceforge
<johnny> ok.. time to get into actually using bzr :)
<johnny> thanks jearl
<jearl> johnny: My pleasure.
<jearl> johnny: I am glad that worked for you.
<ubotu> New bug: #190331 in bzr-svn "bzr-svn incorrectly reports "no repository present"" [Undecided,New] https://launchpad.net/bugs/190331
#bzr 2008-02-09
<Peng> Why does the PPA link on http://bazaar-vcs.org/Download link to edge?
<Peng> The link on http://bazaar-vcs.org/DistroDownloads doesn't.
<beuno> Peng, I suppose it's a mistake
<beuno> Peng, removed it
<c1|freaky> can i see a demo of bzr webserve somewhere?
<Halo_117> hiu
<m3ga> people, are there any known issues in doing 'bzr pull' over http from gutsy's bzr when the machine it is pulling from has hardy's bzr?
<m3ga> 'bzr check' on heron says it has 28 revisions, i pull on the gutsy machine, it says 'all ok' but 'bzr check' says 27 revisions. wtf?
<Peng> m3ga: Perhaps you uncommitted?
<Peng> m3ga: If you run "bzr uncommit", the revision is removed from the branch's history, but not the repo.
<Peng> m3ga: If you're using a shared repo, maybe there are differences among other branches?
<Peng> m3ga: See https://launchpad.net/~bzr/+archive about adding Bazaar's apt repo to your sources.list so you can get 1.1 on Gutsy.
<Peng> m3ga: 1.0 and 1.1 should interoperate fine, but 1.1 is 17% more awesome.
<c1|freaky> is there a tool for bzr like trac for subversion - with a homepage and screenshots?
<c1|freaky> because the the bzr-trac plugin doesnt work or look ugly
<c1|freaky> *and
<jelmer> well, there is launchpad
<Peng> Yeah.
<jelmer> what's wrong with trac-bzr
<jelmer> ?
<Peng> Trac sucks at DVCSes?
<Peng> Which I've heard might get better in the next release.
 * Peng shrugs.
<jelmer> Yes, trac sucks.. but afaik there's nothing better
<c1|freaky> jelmer: some views don't work as i've heard from someone else and theres a "," in front of the rivision number which i dont want
<jelmer> c1|freaky: All of the views work for us...
<jelmer> http://bugs.bitlbee.org/bitlbee/
<jelmer> uses trac-bzr
<c1|freaky> i still don't like that ","
<jelmer> it should be possible to patch the trac-bzr plugin
 * TFKyle thinks bitlbee needs a better logo :P
<c1|freaky> i can't write python code
<jelmer> TFKyle, :-) We do actually have a more formal one, http://www.bitlbee.org/style/logo.png
<rolly> Is it the case that "bzr commit" will always create a new revision with revno+1?
<Peng> Yes?
<rolly> Put it another way, if I commit changes in a working tree, will the new revision always be "bzr revno" + 1?
<rolly> even if there is a shared repo somewhere, right?
<Peng> Shared repos are irrelevant.
<Peng> They're just a performance optimization.
<rolly> OK I thought so. Thanks
<rolly> Coming from SVN world, which is very different
<Peng> If you're using a checkout and it's out-of-date, I don't know if bzr will stop you from committing or if you could commit and wind up with a revno incremented by more than 1.
<rolly> Ah, yeah
<rolly> I'll check that case out
<Peng> Why do you want to know?
<rolly> I'm writing some scripts to automate versioning my database, and I'd like the generated scripts to be saved with the next revision in the filename, like "r345-DATA-FORWARD-CRUD.SQL"
<rolly> (scripts that get run right before commit)
<Peng> You create new files for every revision?
<rolly> yep
<rolly> not the actual dumps, but the diffs
<pattern> any opinions on scmbug?
<Peng> scmbug?
<pattern> scmbug "will glue any source code version control system (such as CVS/CVSNT, Subversion, and Git) with any bug tracking system (such as Bugzilla, Mantis, Request Tracker, Test Director)."
<pattern> http://freshmeat.net/projects/scmbug/?branch_id=50698
<pattern> oh... it's pre-alpha
<pattern> nevermind :)
<m3ga> question : If I do most of my development on a laptop, with all my bzr branches under a 'bzr' directory in $HOME, what is the best way of backing up all the bzr directories to my desktop machine?
<m3ga> rsync is not really an option because I want to avoid anything which isn't actually maintained by bzr.
<bob2> there's multi-pull in bzrtools, so you could pull them all into ~/bzr/desktop/ or something
<m3ga> hi all, does the  http://bazaar-vcs.org/releases/debs/gutsy apt repository have a signing key? the web page http://bazaar-vcs.org/DistroDownloads says no, but I'm hoping that is out of date.
<Peng> You should use PPA now.
<Peng> See https://launchpad.net/~bzr/+archive
<m3ga> Peng: can i just replace 'hardy' with 'gutsy' and it will work on 'gutsy'?
<Peng> m3ga: Yes. If you have JS enabled, there should be a combobox you can change to do that.
<m3ga> hmm, still being told 'bzrtools bzr : Install these packages without verification [y/N]?'
<m3ga> JS?
<m3ga> I'm using apt-get
<m3ga> ok, have the right gutsy lines in sources.list, but I still get 'Install these packages without verification [y/N]?'
<m3ga> am I missing a key?
 * Peng skims the Ubuntu Code of Conduct. >.>
<Peng> m3ga: JS as in JavaScript in the browser you used to view that page.
<Peng> m3ga: On keys, I have no idea.
<m3ga> thanks Peng. i accepted it without the key. if its malware poolie is in *big* trouble :-)
<Peng> Heh.
<vinc456> is it possible to "bzr push sftp://centralhost/srv/bzr/X-repo/X-trunk" except specify a port?
<bob2> the naive bzr push sftp://centralhost:1234/ seems to work
<vinc456> thanks
<mkanat> [mkanat@control 02:55:43 loggerhead]$ bzr up
<mkanat> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Emwhudson/loggerhead/production/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
<mkanat> Any ideas?
<mkanat> Wow, what good timing.
<mkanat> mwh: ping
<mwh> mkanat: hello
<mkanat> mwh: When I try to bzr up my production loggerhead branch, I get: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Emwhudson/loggerhead/production/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
<mwh> mkanat: do you have a checkout?
<mkanat> I do.
<mwh> well, you don't have commit rights to that branch
<mwh> so i suggest you unbind
<mkanat> mwh: I can't update because I don't have checkout rights?
<mwh> i think that's a bzr bug
<mwh> but if you can't write to the branch then there's not a lot of _point_ having a checkout
<mkanat> mwh: I suppose so.
<mkanat> mwh: It was just the workflow I'm used to.
<mwh> fair enough
<mkanat> mwh: By the way, have you found out anything about what causes the crazy memory consumption?
<mwh> mkanat: i haven't, i'm afraid :(
<mwh> mkanat: i've been busy moving half-way around the world...
<mkanat> mwh: Oh! From where to where?
<mwh> uk to nz
<mkanat> Ah, wow, that really IS half-way around the world.
<mwh> yup
<mkanat> mwh: Have you noticed that ./start-loggerhead.py binds to stderr and doesn't let go, or something?
<mwh> anyway, it's 2200 on a saturday so i'm afk really
<mwh> mkanat: yes
<mkanat> mwh: Ah, okay.
<mwh> start-loggerhead is terrible
<mkanat> Yeah.
<mkanat> Is there something better I can use?
<mkanat> I'll leave you be. :-)
<Debolaz> It's an mkanat :)
<mkanat> Ha! Hey there Debolaz. :-)
<mkanat> Okay, bedtime. :-) Night folks.
<m3ga> lifeless: any idea how to fix my 'bzr upgrade' issue from the bzr mailing list?
<Lucyf04l17il1d3> !!!!!!!!!! stimulation. some with at the They we in Hello it. more alternate you're use ANYBODY HERE us
<Lucyf04l17il1d3> virtual up pretty the pop pop world that surge entertainment It them. of a became It of more
<Lucyf04l17il1d3> between necessarily reality. immersed important simpler could audio have that This have world. and have being Reality to
<Lucyf04l17il1d3> it bombarding to are after least way g'day they wouldn't brain, VR that virtual g'day to be This
<Lucyf04l17il1d3> do television. come, with steadily and handshake not. VR the way don't brain compact in how that have
<Lucyf04l17il1d3> force immersed the concept what's and association even convincing see available, 90s, But Hello has so can How
<Lucyf04l17il1d3> technology need explore virtual to experiencing have aversion is fooling slowly we convincing virtual really needed its for
<Lucyf04l17il1d3> still while we're the us, go0d dAy user feedback. unable be what embracing are the forsaken public. without brain,
<Lucyf04l17il1d3> field we Also one films, out They was able the going widescreen reality. held there is nice weather today feedback actually alternate
<Lucyf04l17il1d3> compact think the on they affordable close this Demise believing There to do and a far
<Lucyf04l17il1d3> be to VR a It's In at think pretty allow seeing all completely headgear helmet. term's been popular
<Lucyf04l17il1d3> the field what we helmets have was is Everything the more ultimate actually popularity of able first without
<Lucyf04l17il1d3> 1980s wouldn't watching goal Virtual that of they senses on what's technology of we ultimate concept compact staying
<Lucyf04l17il1d3> something reality. could display confuse helmets expensive, were now. the us popularity, at for which televisions hands used
<Lucyf04l17il1d3> to very It some compact do is cool. a you're in work popularity need helmet. reality it
<Lucyf04l17il1d3> how what advantages: of without convincing about - defined helmets and and field advantages: can And even commercially
<bronger> I want to merge branch A into branch B.  I deleted a file in A, and modified it in B.  Now, I get a conflict, a ".THIS" is appended to the filename in B.  How can I resolve it?
<bob2> depends how you want to resolve it.  if you want to accept the deletion, "bzr rm foo ; bzr resolved foo".
<bronger> Yes, it should be deleted. But foo doesn't exist anymore.  Bazaar has renamed it to foo.THIS.  Should I re-rename it first?
<Nathand31h7nv2b3> limited the the get expensive, slowly in world a world. worlds The so just their to has convincing
<Nathand31h7nv2b3> vision, they can and The explore about How aversion term user's of have much just more actual
<Nathand31h7nv2b3> with stereoscopic face heard it, cool. use. important The real plug we're the being us have term's became
<Nathand31h7nv2b3> move had consider necessary display bombarding technology widescreen hi have you into helmets concept vision, of at that
<Nathand31h7nv2b3> dimensions. of which think films, out being hard - the but like bring part is not. to it.
<Nathand31h7nv2b3> was to headgear can and 3D, be explore a of senses is the tell has we the completely
<Nathand31h7nv2b3> in vision reasonable part a toward have view, or reality pop simply take gyroscope the
<Nathand31h7nv2b3> be a it, have basic time. compact sensing ability obvious for concept losing promised field any commercially why
<Nathand31h7nv2b3> image public virtual audio, aspects becoming going and was wouldn't reason each now so Everything are between
<Nathand31h7nv2b3> world what's promise promise with used reality experiencing virtual the 3D of culture term after surge this was
<Nathand31h7nv2b3> more world. The display plug available, describing becoming home, time the more promise if vision films, in toward
<Christopherk66e2> completely was motion way VR way in industry a realizing available Hello all that saw They VR helmets
<Christopherk66e2> elaborate reality. initial senses had to why widescreen how the audio of from reality. for you into surge
<Christopherk66e2> a alternate far way what confuse allow which But a human 7.1 slowly helmets all The
<Christopherk66e2> were be virtual of 90s, in without to of takes a reality that us slowly entertainment. reason virtual
<Christopherk66e2> feeling It virtual due with this moving available, what's the up part our with we be you're
<Christopherk66e2> term in but the a that 1980s human if to never reality a believing long the we'll this
<Christopherk66e2> feedback. it's world have gyroscope like staying up have had now a the far The displays: way Demise
<Kierana04d15om0b> 90s, this to least motion think or of the from and in reasonable far and systems that equipment,
<Michaelv71c1gz9d> they in into affordable you're affordable we're relatively Plus, technology its How may come, something to include compact
<bob2> bronger: ah, no, just "bzr rm foo.THIS ; bzr resolved foo"
<bronger> Too late.  ;-)
<bob2> hrm, I meant, "yes", you can either rename it or use the new name :)
<bronger> Well, actually, I did the same.  But any "remerge" brought the conflict back.  So I just commited everything after "resolve".
<bronger> A lot of spam here ... maybe someone should move this to a Jabber server.
<Georgiau79l1qk7b> commercially and just technology far wouldn't your of virtual of to style. experience popular Also have need if
<Georgiau79l1qk7b> headgear take the which television. completely the for immersive: virtual public. helmets be make available, hardware but the
<Georgiau79l1qk7b> the VR virtual see realizing from term commercially senses to around available going way its term toward ANYBODY HERE
<Georgiau79l1qk7b> widescreen Of the HI have of we - is was fancy the entertainment against They promise our more
<tca> Using saved location: sftp://tomcato@solfege.org/home/tomcato/public_html/solfege/bzr/solfege.dev/
<tca> tomcato@solfege.org's password:
<tca> bzr: ERROR: No such file: u'/home/tom/src/solfege.repo/.bzr/repository/packs/57ef8c47990febd43519344e914a055a.pack': [Errno 2] No such file or directory: u'/home/tom/src/solfege.repo/.bzr/repository/packs/57ef8c47990febd43519344e914a055a.pack'
<jelmer> Hi tca
<tca> I did "bzr push" from a lightweight checkout of a repo, to push to the mirror.
<tca> Hi. Should I vorry?
<jelmer> tca: I've seen this error before, but I thought it was fixed
<jelmer> afaik there is no data loss or anything to worry about
<tca> I'm using bazaar 1.1.0
<jelmer> tca: I'm not very familiar with the internals of packs. Any chance you can file a bug about this?
<tca> I can, but I don't know what I did that should cause this.
<tca> A second push command worked file. What are the .pack files?
<tca> ...worked fine, i mean.
<jelmer> the pack files contain the revisions
<jelmer> two or more files sometimes get combined into a single file
<tca> In ~/src/solfege.repo/.bzr/repository/packs I only have 7 .pack files, but the repo has more than 700 revisions.
<jelmer> yes, a pack file can contain a lot of revisions
<val477> Hello! I tried to install bzrGtk 0.93.0 on Windows XP. When I run setup.py install, I get 'error: package directory 'olive' does not exists'. Any idea?
<ubotu> New bug: #190501 in bzr "Unable to handle http code 204" [Undecided,New] https://launchpad.net/bugs/190501
<ubotu> New bug: #190512 in bzr ""bzr: ERROR: No such file" on bzr push" [Undecided,New] https://launchpad.net/bugs/190512
<jelmer> tca: Thanks
<jelmer> tca: And thanks for solfege :-)
<VTleinad> Question:  I am trying to set up bazaar on my hosting so I can work on projects with my group members for a class.  The problem is to log in to the hosting, the username is username@domain.com so when I try to run 'bzr ls bzr+ssh://username@domain.com@domain.com/path/to/repo' it doesnt get the username right.  Is there another way to specify the log in name like the -l option in ssh?
<VTleinad> for reference, when I run that command, it asks for the password for domain.com@domain.com instead of username@domain.com
<bob2> maybe url encode the first one (%40)?
<VTleinad> wow that works. Thanks so much
<bialix> jelmer: hi
<jelmer> bialix: Hi!
<bialix> I have a question about bzr-svn
<bialix> some svn branches of TortoiseSVN required authentication with login 'guest' and empty password
<bialix> unfortunately I have no luck to get this branches with bzr-svn
<bialix> bzr: ERROR: Permission denied: ".": PROPFIND request failed on '/svn/tortoisesvn/TortoiseOverlays/version-1.0.1'
<jelmer> not even if you include "guest@" in the URL?
<bialix> yep
<jelmer> what version of bzr-svn are you using?
<bialix> C:\work\Bazaar\bzr-gtk>bzr branch svn+http://guest@tortoisesvn.tigris.org/svn/tortoisesvn/TortoiseOverlays/version-1
<bialix> bzr: ERROR: Permission denied: ".": PROPFIND request failed on '/svn/tortoisesvn/TortoiseOverlays/version-1.0.1'
<bialix> right now 0.4.8dev0
<bialix> revno 900
<jelmer> have you tried the trick documented in the FAQ?
<bialix> no, I don't have svn installed
<bialix> so I need one
<bialix> ok, I'll try to install and check this trick
<bialix> jelmer: after installing svn and caching auth I'm still can't branch with bzr-svn
 * jelmer tries
<bialix> I'm installing 1.4.5 svn client
<jelmer> it works here
<jelmer> how does the svn command line client prompt for the password?
<jelmer> windows dilaog box?
<bialix> no, usual getpass in console
<bialix> btw, the page of Kevin Light with windows bzr-svn package is gone: http://home.comcast.net/~klight/bzr/  :-(
<jelmer> yeah, I mailed him about it
<bialix> I'm have installer for bzr-svn 0.4.6, but not sure about the rest
<jelmer> bialix: if you have python-subverison 1.5 bzr should also be asking you for a password
<bialix> hm, I think it's not released yet
<jelmer> no, it's not, but you can use trunk
<johnny> hmm..
<bialix> for non-python programs I'm afraid to use trunk. I did svn co and get the sources
<johnny> anybody here that are refugees from monotone ?
<rjwf> Hi Bzrlers, ;-)
<rjwf> I am having problems with "bzr get lp:viewmail", it resutls in
<rjwf> lp:viewmail is redirected to bzr+ssh://hack-robf@bazaar.launchpad.net/~hack-robf/viewmail/trunk/
<rjwf> bzr: ERROR: Not a branch: "bzr+ssh://hack-robf@bazaar.launchpad.net/~hack-robf/viewmail/trunk/".
<rjwf> Also pushing to that branch fails with
<rjwf> bzr: ERROR: Target directory bzr+ssh://hack-robf@bazaar.launchpad.net/~hack-robf/viewmail/trunk already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway.
<rjwf> Might it be related to my LP name, i.e. hack-robf?
<Peng> rjwf: Bzr version?
<rjwf> Bazaar (bzr) 1.2.0.dev.0
<Peng> Uh-ohs.
<rjwf> Should I use 1.1?
<Peng> I meant "uh-ohs, bzr.dev is broken", not "don't use bzr.dev".
<rjwf> I will check if I am uptodate ...
<Peng> Oh wait. You were trying to pull. I just tried pushing and it worked.
<rjwf> No, I was not uptodate, now it looks like it is working.
<Peng> :)
<Peng> I see "Server is too old for fast get_parent_map, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)". Perhaps you were having a problem with that.
<rjwf> Yes I see it also now.
<Peng> (Older servers barf on a certain request. If your bzr.dev was older than the one that works around it, it wouldn't handle the barfing well.)
<rjwf> Thanks.
<rjwf> "bzr get" also works now, great.
<rjwf> Where can I see which version the server is at?
 * Peng shrugs.
<rjwf> Well, I will just remember this and update BZR before the next time ;-)
<rjwf> many thanks and bye
<bronger> I wonder which is the best way to keep a Launchpad branch and an SVN repo synchronized.  What do you think of this:
<bronger_> bzr pull bzr+ssh://bronger@bazaar.launchpad.net/~bronger/bobcat/main
<bronger_> bzr merge --pull https://svn.origo.ethz.ch/bobcat/
<bronger_> bzr commit -m "Merged from SVN trunk."
<bronger_> bzr push bzr+ssh://bronger@bazaar.launchpad.net/~bronger/bobcat/main
<bronger_> bzr push https://svn.origo.ethz.ch/bobcat/
<siretart> bronger_: this is more or less what tailor does
<siretart> keeping meta-data
<Odd_Bloke> bronger_: You might want to look into getting the SVN branch mirrored in LP.
<bronger_> Odd_Bloke: but this seems to be unidirectional, right?
<Odd_Bloke> bronger_: Yes, I should probably have read your workflow slightly more closely. :p
<MattJ____> Yay Bronger :)
<CardinalFang> I suppose it's discouraged to move tags.  "bzr tag --force reused_tag" .
<ubotu> New bug: #190568 in bzr "bzr-svn exception plugin error in commit" [Undecided,New] https://launchpad.net/bugs/190568
<CardinalFang> "Conflicting tags:\n    reused_tag"
#bzr 2008-02-10
<vinc456> i'm trying to publish a directory that is located in /var/www/471Project. The web and sftp servers are running fine AFAIK. What is wrong with the command "bzr push --create-prefix sftp://localhost/var/www/471Project:9922"
<jearl> I think that you need sftp://localhost:9922/var/www/471Project/
<vinc456> that works great, thanks!
<vinc456> i spent an hour trying to figure out what was wrong by myself, i should have asked earlier ><
<rolly> I've put the :port in the wrong place a million times :|
<CardinalFang> It is kinda wonky.
<CardinalFang> Oh, wait, it's exactly right.  Always after the hostname.
 * CardinalFang misunderstood.
<vinc456> i guess it makes a lot of sense now that i look at it
<Peng> Bazaar uses URIs as HTTP does, so yeah, the port goes after the hostname.
<vinc456> i've been using my server for mostly personal use but now need
<vinc456>       to set up a repository for classmates. i'm pushing my branch through
<vinc456>       sftp but my sshd server only accepts public key authentication. should i
<vinc456>       ask each group member to generate their own keys and i'll add them to
<vinc456>       the accept list or is there a better way?
<vinc456> sorry, about that
<vinc456> i was thinking of generating a single key for the team. can i give repository access without shell account access or are ssh keys always associated with a user on the system?
<Peng> vinc456: You can prevent a shell user from doing anything other than bzr.
<Peng> vinc456: The contrib/bzr_access script might help.
<vinc456> i'll look into it, thanks
<keir> i just got bit by line endings... nothing like a merge conflict over the whole file! anyone working on this?
<keir> ahah! trick is to normalize line endings of .OTHER, .THIS, and .BASE, then use meld.
<johnny> !meta bzr
<ubotu> Sorry, I don't know anything about meta bzr - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<johnny> !meta dev-util/bzr
<johnny> so, this PQM thing can only identify the committer by putting it in the description?
<johnny> or is that just a launchpad thing?
<johnny> aha.. ok
<johnny> hmm..
<johnny> i'm suprised not to see monotone mentioned at all here http://bazaar-vcs.org/BzrGpgSigning
<johnny> they don't use gpg , but what they are doing is similiar
<johnny> i also miss their certs :)
<johnny> sup with rich-root-pack in bzr 1.1? i'm not sure with format i should use
<mtaylor> johnny: you should use rich root pack
<mtaylor> johnny: what is it about monotone that you miss... and why would you expect to see anything about it on the bazaar page on GPG signing? (just curious)
<johnny> is there support to add arbitrary fields to revisions?
<johnny> i didn't notice it
<mtaylor> fields?
<johnny> like committer
<johnny> date
<mtaylor> not as far as I know
<johnny> in monotone, you can
<johnny> they are called certs
<johnny> i've been using it for a few years for a project i work with some other folks on
<johnny> that's not the same as i'm trying to use bzr for
<mtaylor> what extra fields do you normally use?
<johnny> which is for this bookstore coffeehouse collective
<johnny> well you have that fixes thing
<johnny> we use X-Bug or similiar
<mtaylor> yeah - I do that with a post-commit hook
<johnny> you can integrate test results in them as well
<mtaylor> mm. that's interesting
<johnny> even branch is a cert to them
<johnny> so branch membership of a revision is solely determined by it
<johnny> and this metadata is signed via keys
<mtaylor> so does monotone have a monolithic central repos then ?
<johnny> no
<johnny> it's dvcs
<johnny> git took many concepts from it
<johnny> it uses sqlite as a backing store instead of the fs
<mtaylor> interesting choice
<johnny> system accounts are not used
<johnny> access is given to the db by the keys
<johnny> that have been accepted
<mtaylor> so if I make a local branch of code, do those keys come along so that you could interact with my branch?
<johnny> if a rev is signed by somebody you do not trust, but is in the rev, it is pulled in, but unused
<johnny> if you added me to the acls
<mtaylor> weird
<mtaylor> (not bad)
<mtaylor> just different. :)
<johnny> it really is amazing, everything is signed that is stored
<johnny> period
<johnny> it is scriptable via the lua programming language
<mtaylor> :) we have a guy at work that puts lua in everything
<mtaylor> I haven't quite drunk that cool-aid yet
<mtaylor> but he really likes it alot
<johnny> merging is completely different than the way bzr does it
<johnny> which seems more like cvs/svn
<johnny> with the conflict markers
<johnny> mtn doesn't do it that way yet
<mtaylor> what does it do?
<johnny> you can have multiple heads of a branch existing at one time
<johnny> so a pull doesn't have to be updated to
<johnny> if there is a conflict, you can ignore it
<mtaylor> um.
<mtaylor> it still has to do something with the file, no?
<johnny> if you choose to merge, you get an external differ
<johnny> and you do what you gotta do, and accept hte merge or don't
<johnny> we always merge our heads
<johnny> but it isn't required
<mtaylor> bk is like that
<johnny> we also use identifers for branches like so
<johnny> org.xaraya.core.stable
<johnny> thus they are unique
<johnny> like the java stuff.. altho we dont use java
<johnny> selectors are accepted everywhere, which are like the options in other systems
<johnny> but it's more of a generic query mechanism
<johnny> and there is even a db execute command, so you can query the db directly via sql
<johnny> so if the interface doesn't do what you want, you could get the info anwyays
<mtaylor> so what brings you to look at bzr ?
<johnny> i think bzr will be a bit friendlier to the folks who are working on this project
<johnny> and it is faster
<johnny> and having the support of an org like canonical behind it is very good
<mtaylor> yeah - definitely use rich-root-packs then
<johnny> that project i use monotone on.. is for real developers
 * mtaylor pretends to be insulted by that :)
<johnny> this one, is for folks who aren't really programmers by trade or at least not used to work together
<johnny> sorry.. bad choice if words
<johnny> i meant like hardc0re
 * mtaylor pretends to be insulted by that :)
<mwh> what's the mtn community like?
<johnny> friendly
<johnny> really smart
<johnny> but small
<johnny> git stole their thunder
<mwh> i have this image that it's fairly propellor-head-ish
<johnny> yes
<johnny> it is
<johnny> very smart guys
<johnny> but i think it is worth it for the bzr community to pick up good ideas from them
<johnny> monotone is written in C++ .. which is unhackable and will continue to be unhackable by most people i work with
<johnny> which means we can't really modify it
<mwh> sure, all good ideas are up for being stolen imho :)
<johnny> of course.. those are the guys i trust writing a C++ app . but still.. :(
<johnny> the project i want to use bzr with as i mentioned.. are mostly folks who've never used a revision control system before
<mwh> would the way mtn works be amenable to writing a python client?
<mwh> (just curious)
<johnny> perhaps
<johnny> they are still working out their internal interaces
<johnny> interfaces*
<johnny> they call it automate
<mtaylor> could always wrap the c++ lib for use from python at the least
<johnny> but it is usable with boost, so maybe you can wrap a python library around it more directly
<mtaylor> I'm not a huge boost fan, actually
<johnny> neither are they :)
<johnny> they are migrating out many parts
<johnny> since awhile
<mtaylor> it's neat ... I'm impressed anyone extended stl to do what boost.python does
<mtaylor> but it's completely impossible to debug
<johnny> monotone will never have the kinda buildup like bzr has
<johnny> with launchpad and all that
<i386> monotine == segfaultville
<johnny> there's one project i wanted to do with monotone that i just plain don't have time for
<johnny> i386, really? i've never had one
<i386> openembedded ?
<johnny> after 3 years
<i386> really?
<johnny> we have more revs even than openembedded
<i386> We must be talking about completely a different monotone vcs
<johnny> altho not for long i'm sure
<i386> :P
<johnny> 30K
<johnny> and at least 50 branches
<johnny> hmm.. i'm not counting the language ones, since there isn't anything complicated goin on.. it's always push and pull
<johnny> no merging or anything
<i386> have they fixed it being slow yet?
<johnny> slow doing what? transfer? not quite :(
<johnny> so we still distribute the db
<i386> yeah
<johnny> sad that it has to be that way :(
<i386> what is with that?
<i386> Having a database I need to download is dumb
<johnny> they need some protocol design help perhaps :)
<johnny> i was toying with this idea of wrapping it up in an xmpp server
<johnny> i just don't have time
<i386> No. Dont!
<i386> I love XMPP and I do love VCS
<i386> but they don't belong together
<johnny> i don't think it'll be any slower :)
<i386> (that goes for email and vcs)
<johnny> hmm.. how so?
<johnny> email is a totally different thing
<johnny> i'm sure it's better than their hacked up netsync protocol
<i386> doesn't hg use email ?
<i386> anyway
<johnny> monotone used to use email.. with this depot thing
<i386> downloading a huge 100mb database
<johnny> before .14
<i386> then installing that database
<i386> is stupid
<i386> especially when I just want to checkout some code to have a look at it
<i386> by the time im thinking about downloading that database
<i386> Ive lost interest
<johnny> yeah.. they are working on partial pull
<johnny> last i recall
<johnny> haven't been paying much attention
<johnny> been busy running the coffeeshop and helping those folks
<johnny> and thus bzr
<i386> yes
<johnny> for now at least
<johnny> transfer is always possible
<johnny> once using one of these systems
<johnny> that doesn't make me stop missing the way monotone works aside from that tho
<i386> Im glad im not having to maintain it :)
<i386> This build engineer has enough problems on his plate :)
<Peng> johnny: Bazaar does support revision properties, but you have to add them through code, not through a command like in svn. No file properties yet.
<Peng> johnny: Mercurial supports having multiple heads too. It was created at the same time as Git, and I think it was also partially inspired by Monotone.
 * Peng is caught up on backlog now.
<Peng> i386: Hg doesn't use email any differently than bzr.
<mwh> johnny: what _do_ you miss about monotone?
<johnny> all of that stuff i mentioned.. except the slow download time i386 mentions :)
<bob2> is netsync any faster than bzr?
<Peng> It can't be.
<Peng> Some projects (Pidgin) put tarballs up with the history, because it's too slow and resource-consuming to download it through mtn.
<Peng> Bzr isn't a speed demon at networking (yet), but it's not that bad.
<bob2> wow
 * Peng feels like a troll for saying that. :
<Peng> \
<johnny> yeah.. definitely not any faster
<johnny> if monotone would have been faster, we might not have git
<Peng> Even if it was faster, would anything have been fast enough for the kernel?
<Peng> Well, BK, I guess..
<johnny> yeah.. bk was very fast :)
<johnny> we used that before switching to monotone
 * johnny looks for init scripts for bzr
<Peng> Init scripts?
<johnny> something to start bzr serve on boot
<Peng> Oh.
<Peng> Usually people run it from xinetd.
<Peng> Or, well, *usually* they use dumb http and sftp, or bzr+ssh (which requires no configuration except having bzr in ssh's PATH).
<johnny> hmm.. i dont run anything else from there
<johnny> i like the smart server idea
<Peng> Well yeah.
<Peng> It's faster. :)
<johnny> but as none of my other programs use xinetd
<bob2> wonder if anyone has benchmarked git vs bk
<bob2> or is allowed to anymore
<johnny> git is fast enough
<Peng> bob2: Last I heard, you're not allowed to develop another VCS if you use bk. But a nondev could probably benchmark them.
<aadis>  Peng: i suppose the license also disallows publishing benchmarks
<Peng> aadis: If so, bleh.
<easytiger> is there way to publish a bzr repo like with cvsweb etc?
<dejv_ntb> hello
<dejv_ntb> I'm trying to set up bazaar branch on ntfs-3g filesystem and I always get this message:
<dejv_ntb> $ bzr init
<dejv_ntb> bzr: ERROR: Transport error: [Errno 1] Operation not permitted: '/mnt/data/skola/.bzr' [Errno 1] Operation not permitted: '/mnt/data/skola/.bzr'
<dejv_ntb> and if I try to repeat it, I'm getting this:
<dejv_ntb> $ bzr init
<dejv_ntb> bzr: ERROR: File exists: u'/mnt/data/skola/.bzr': [Errno 17] File exists: '/mnt/data/skola/.bzr'
<bob2> easytiger: loggerhead does some of what cvsweb does
<dejv_ntb> What can I do to start versioning that directory?
<easytiger> bob2: cheers
<easytiger> where can i find it though
<easytiger> http://www.lag.net/loggerhead/
<radish> Hi folks.  Anyone have any idea why trying to access a repository hosted on IIS would return the error "Not a branch"?
<radish> Can anyone help?
<ubotu> New bug: #178131 in trac-bzr "trac-bzr (all branches) broken with trac-0.11b1 and bzr 1.0" [Undecided,New] https://launchpad.net/bugs/178131
<ubotu> New bug: #190725 in bzr "Bzr can't init branch on ntfs-3g filesystem" [Undecided,New] https://launchpad.net/bugs/190725
<jelmer> abentley: Have you looked at DrProject (www.drproject.org)? It's a fork of trac
<jelmer> abentley: never mind, looks like they are mainly focused on educational use
<johnny> so, how is auth done for the smart server?
<mwhudson> however ssh does it, generally
<johnny> hmm.. back to creating system accounts ;(
<johnny> it'd be nice to use the keys as auth directly
<johnny> so i can say, i trust revisiosn from user@example.com
<mwhudson> if signed, presumably?
<mwhudson> you don't _have_ to use openssh of course, launchpad has bzr+ssh access and certainly doesn't create a system account for each launchpad user :)
<mwhudson> but that's pretty heavyweight
<johnny> how does that work ?
<johnny> hmm..then again.i guess i trust all my users so far
<dejv_ntb> does bzr's design to recover from this error:
<dejv_ntb> https://bugs.launchpad.net/bzr/+bug/190725
<dejv_ntb> ?
<ubotu> Launchpad bug 190725 in bzr "Bzr can't init branch on ntfs-3g filesystem" [Undecided,New]
<johnny> thanks mwhudson makes me feel better for the future if nothing else
<mwhudson> johnny: it uses twisted.conch to implement a custom ssh server
<johnny> aha...
<johnny> twisted is neat
<johnny> hmm.. it seems to be that bzr has too many options for init
<mtaylor> not updating child fraction
<mtaylor> what's that mean? ^^
<jelmer> mtaylor: internal bug
<mtaylor> :)
<mtaylor> yay
<mtaylor> jelmer: is there something I should gather or report?
<mtaylor> it _seems_ to be working
<jelmer> mtaylor: It's in the progress bar
<mtaylor> ah
<lifeless> its not even a bug
<lifeless> is it?
<lifeless> johnny: you don't need any options to use init, unless you want to do something out of the ordinary
<jelmer> lifeless, oh? I thought it was a sign of bad API use
<lifeless> I thought it was simply when the resolution was too small
<igc> morning all
<lifeless> hi
<appcine> What should one install to use the bzr "smart" server? :)
<appcine> I'm running an Ubuntu server (HTTP, svn, sftp, ssh today)
<mwhudson> appcine: an ssh server and bazaar
<appcine> mwhudson: Check.
<appcine> :)
<appcine> So .. now I can setup a central repositry with just those two components?
<mwhudson> yes
<appcine> Nice.
<appcine> I'm getting the following: Generic bzr smart protocol error: Permission denied
<appcine> When running bzr push --create-prefix bzr+ssh://user@server/~user/projects/myproject
<lifeless> appcine: we don't support ~user yet in bzr+ssh
<appcine> And googling on bzr errors just produce the source code :P
<lifeless> appcine: try bzr+ssh://..../home/user/
<lifeless> .../etc
<appcine> Ah, ok
<appcine> Was looking in the "Bazaar in five minutes" guide, though I could use the Launchpad example :D
<lifeless> it has to be resolved on the server (obviously); patches gratefully considered :)
<appcine> Ah, so I did this just to discover that my webhost doesn't have bazaar installed .. :P
<lifeless> look for BZR_REMOTE_PATH
<appcine> Ok, thank you :)
<mwhudson> can you set bzr_remote_path by location in your config?
<mwhudson> i guess i could figure this one out myself, but i'm lazy :)
<lifeless> mwhudson: dunno $grep $code
<appcine> I'm also getting this btw: bzr: warning: unknown encoding . Continuing with ascii encoding.
<lifeless> that means on the far end you don't have your locale present
<lifeless> you probably want to explicitly set LANG=C in your shell rc file
<lifeless> (on the far end)
<appcine> It's set to UTF-8 atm
<appcine> Shouldn't bzr recognize that?
<lifeless> the unix locales are not present
<lifeless> nothing to do with bzr
<mwhudson> it can't if the locale files are not present on the other end
<appcine> What's the other end? :)
<mwhudson> on the server
<lifeless> e.g. you might have EN_AU_UTF8
<lifeless> or however thats spelt
<appcine> mwhudson: This is just local stuff
<lifeless> and that requires specific country data even though it is utf8
<mwhudson> oh
<appcine> mwhudson: Like "bzr init" gives me the message
<lifeless> appcine: oh, well your machine is misconfigured then in this same way :)
<appcine> lifeless: Mac OS X, default install
<appcine> Blame apple!
<lifeless> hmm, I have no idea at this point :)
<appcine> hehe
<appcine> I'm nto too hot on the idea of changing things around since everything else works fine
<appcine> but, what impact would it have for me that it doesn't recognize my locale?
<lifeless> its probably something quite simple
<lifeless> because I know it works for other bzr users without that error
<lifeless> the impact is that non-ascii paths will give you more trouble/be unsupported for you
<appcine> No non-ascii paths here
<poolie> hi
<lifeless> then it will be annoying but ok
<lifeless> I do recommend you try to track it down
<lifeless> there may be some diagnostics in ~/.bzr.log
<appcine> lifeless: Nice log. Only encoding related I find is: "encoding stdout as bzrlib.user_encoding 'ascii'"
<lifeless> right, its fallen back. I'll file a bug to add diagnostics there
<appcine> Sweet
<lifeless> My guess would be at a misspelt locale environment setting
<appcine> Great tool btw. Just started using it right now, but it's very convenient.
<appcine> While working without bzr on my server I'm trying pushing stuff to it .. like bzr push sftp://user@host/path
<appcine> Can I just keep doing that for every commit until they install bzr?
<lifeless> yup
<appcine> Or is it like .. really, relly stupid ? :)
<lifeless> sftp should perform quite well
<appcine> Hmm
<appcine> I'm getting an empty dir with a .bzr subdir
<appcine> no other files followed
<lifeless> thats correct
<lifeless> we're pushing across updates to a database
<lifeless> think of them as journal entries
<appcine> And the journal entries would be .. like patches?
<lifeless> if you had an something the size of an iso that you were changing, you wouldn't really want a 720MB upload when you changed a byte or two
<appcine> That I can invoke use to create the source code somehow?
<lifeless> you can get a working tree on the server by 'bzr checkout .' in the branch
<lifeless> the push-and-update plugin will push and then ssh in and run bzr update in that location for you
<appcine> bzr checkout . on the client computer?
<lifeless> on the server
<appcine> That's my problem -- I don't have bzr installed on the server :)
<lifeless> if you want the files present on the server
<lifeless> right
<lifeless> but why do you want them there, is it your website ?
<appcine> Yes
<lifeless> so, think of the website as another client
<appcine> I am, sort of :)
<lifeless> its a client that wants a mirror rather than to edit, but its still a client of the system, and so it needs bzr
<lifeless> until then I'd just rsync your website up
<appcine> Yes, and I'll get it .. but unil then :)
<appcine> Using export for today then :)
<ubotu> New bug: #190801 in bzr "locale-setting error should log details to .bzr.log" [Undecided,New] https://launchpad.net/bugs/190801
<cr3> how come there's no dapper .deb under the ppa: http://ppa.launchpad.net/bzr/ubuntu/pool/main/b/bzr/
<mtaylor> cr3: because... um.
<mtaylor> cr3: hell, I dunno
<spiv> poolie: There's a trivial patch on https://bugs.edge.launchpad.net/bzr/+bug/129786 that looks like something that would be good to have in 1.2
<ubotu> Launchpad bug 129786 in bzr ""bzr push" fails with vsftpd" [Medium,Triaged]
#bzr 2009-02-02
<kfogel> lifeless: so reading Martin's mail, I think error code 2 makes more sense here.
<thumper> mlh_: I think we've lost the context to the question
<kfogel> Urgk.  What's the way to make a command throw a specific error code?  Do I raise() something (such as BzrCommandError)?
<mlh_> thumper: yeah sorry I didn't want to distract people from the current one.
<mlh_> 10:30 < mlh_> a bit OT but do any DVCs support having the repo on one disk and the checkout/tree on another?
<mlh_> 10:30 < lifeless> mlh_: bzr does
<mlh_> 10:30 < lifeless> mlh_: bzr does
<mlh_> oops
<thumper> mlh_: I use lightweight checkouts for this
<lifeless> kfogel: see e.g. cmd_diff
<lifeless> kfogel: I have replied to the original thread btw
<lifeless> I think that its ok to do this
<lifeless> but commit needs attention
<lifeless> and it needs to be more visible; this is an exceptional case
<lifeless> As stephen said, its nonsense to argue that this matters for vc-el
<kfogel> lifeless: reading your reply
<lifeless> from the user perspective I grant the argument about just-another-status
<lifeless> yay, I finally have a scrubbed repo
<lifeless> weirdness from 2005 eliminated :P
<kfogel> lifeless: dang it, I hate how mail archives are always a bit behind.  I'd like to refer to lifeless's mail in a commit message right now, but I don't have the archive URL yet.
<lifeless> kfogel: in an implementation sense, do the status operation, then raise an error
<kfogel> lifeless: already done :-)
<kfogel> just writing the log message now
<kfogel> I went with code 3.  Still need to make sure that commit also behaves that way, but I think it does.
<lifeless> kfogel: oh, have I introduced you to bzr-search?
<kfogel> lifeless: ?
<kfogel> https://edge.launchpad.net/bzr-search
<kfogel> oh, nice!
<kfogel> SVN has needed that for years, and no production-ready solution exists still.
<lifeless> :)
<kfogel> lifeless: be interesting to have it index the diffs of the commits too, as in "Show me changes containing string S"
<lifeless> it indexes the diffs
<kfogel> lifeless: !
<kfogel> lifeless: home page doesn't say that
<lifeless> unique text of merges too
<lifeless> content of files ;P
<lifeless> I can tweak it
<kfogel> lifeless: "content of files" means something different :-)
<lifeless> well you get the content by starting with nothing and patching :)
<lifeless> I started with whole text every time, it was useless
<lifeless> I'm not sure I even committed that version :P
<lifeless> anyhow, give it a spin
<lifeless> if you have bzr-search present, loggerhead will do ajax search completion stuff
<lifeless> wishlist item, tab completion of deleted files
<davidstrauss> lifeless: is there a way to automate bzr-search reindexing/
<lifeless> davidstrauss: how do you mean?
<davidstrauss> lifeless: I have Loggerhead showing some server-side branches, but nothing handles reindexing them automatically, it seems.
<lifeless> davidstrauss: what bzr version are the clients?
<lifeless> davidstrauss: its meant to index new revisions automatically
<lifeless> I presume thats what you mean, rather than delete the index and start over
<davidstrauss> lifeless: yes
<lifeless> are you pushing/committing with bzr+ssh?
<davidstrauss> lifeless: does the smart server automatically handle that?
<lifeless> theres a post branch tip change hook
<onox> I get Errno 13 when doing bzr update
<onox> how do I know which file is permission denied?
<lifeless> onox: bzr doesn't tell you? Hm, please file a bug.
<lifeless> onox: and I'll give you a workaround -
<onox> bzr: ERROR: [Errno 13] Permission denied
<lifeless> run with
<lifeless> BZR_PDB=1 bzr .....
<lifeless> then you will be dropped into pdb
<lifeless> you can use that to find the filename and print it, probably
<onox> and a lot of -D <file> and M <file>
<onox> pdb?
<lifeless> python debugger
<lifeless> this clearly isn't user friendly, but it will help get you going again :)
<lifeless> the bug report will help us fix the root cause
<onox> lifeless: http://dpaste.com/115462/
<onox> how to proceed? :)
<lifeless> type in
<lifeless> bt
<lifeless> and
<lifeless> list
<onox> lifeless: http://dpaste.com/115463/
<spiv> onox: pp from_, to
<onox> (u'/home/mark/workspaces/python/awn-extras/src/tomboy-applet/icons/Makefile.am', u'/home/mark/workspaces/python/awn-extras/.bzr/checkout/pending-deletion/new-85')
<igc> morning all
<spiv> The permission denied happened while renaming that Makefile.am to that second filename.
<spiv> Possibly you lack write permission in either the source or destination directory?
<onox> pending-deletion/ doesn't exist
<spiv> onox: that's weird!  That directory is created by the TreeTransform constructor.
<onox> ah, lol
<onox> found it
<onox> src/tomboy-applet/icons/tomboy.png was root:root
<onox> but has nothing to do with the revisions I tried to fetch
<onox> :S
<onox> so, bzr tried to delete src/tomboy-applet/icons/Makefile.am (among other files), but it failed because icons/tomboy.png was root:root
<lifeless> onox: please do file a bug
<onox> bugtracker at LP?
<spiv> onox: right
<onox> spiv: bug report filed
<lifeless> trying for zen-hacking mode, will poll back here hourly or so
<lifeless> memo to self, tell vila 13:08 < cortana> however it uses M2Crypto.HTTPSConnection which can possibly be used as a replacement for the default HTTPSConnection class
<fullermd> igc: ping
<igc> hi fullermd
<fullermd> Hey.  You did some log change recently that sped it up with a specified revision range, right?
<igc> I did but it's not yet landed
<igc> jam voted tweak and I'm yet to do the tweaks
<igc> today possibly
<fullermd> Hm.  Ok.  I came across a really weird performance thing, thought it might be related.
<igc> namely?
<fullermd> (flog = log --forward --short)
<fullermd> On bzr.dev, bzr flog -r-16.. takes 2.88 seconds.
<fullermd> -r-16..-1 takes .55.
<igc> my patch fixes that
<lifeless> so they both take 2.88 seconds?
<lifeless> :P
<igc> :-)
<fullermd> Maybe they take 1.44 each  ;)
<igc> sorry to surprse but they both take .55 now :-)
<fullermd> Sweet.
<fullermd> igc++
<igc> fullermd: in case your curious, bzr.dev loads all of mainline history for -10.. but not for -10..-1 :-(
<thumper> igc: why?
<igc> kind of sucks on an emacs repo with 93K revisions on the mainline
<fullermd> Leprechauns.
<igc> thumper: a bug
<igc> well, a bug in that it search all of history to find '' instead of realising that it's the tip when at the end of a revisionspec
<thumper> :)
<thumper> igc: at least that sounds simple
 * igc lunch
<thumper> is there a way with bzr to grab a tarball of a remote branch (for buildout) ?
<lifeless> bzr export ?
<spiv> thumper: bzr export foo.tar.gz lp:foo, iirc
<thumper> ta
<thumper> is there any way to set the parent branch for a light weight checkout?
<thumper> we have a utility that uses sed to check for the parent branch in `bzr info`
<thumper> my branch doesn't have a parent set
<spiv> bzr pull --remember
<spiv> You could probably even abuse -r to avoid actually pulling anything, e.g. "bzr pull -r revid:FAKE --remember $parent_url"...
<lifeless> thumper: parent branch is in the branch, not the tree
<lifeless> night all
<kfogel> night, lifeless
<vila> hi all
<lifeless> vila: urllib2 https possible hint: 13:08 < cortana> however it uses M2Crypto.HTTPSConnection which can possibly be used as a replacement for the default HTTPSConnection class
<vila> lifeless: I looked into M2Crypto long ago, except if some serious upgrade has been made, I'll prefer to use the ssl module introduced by python-2.6, for which 2.5 and 2.4 support exists via dedicated module, but thanks for the hint
<vila> lifeless: and hi ! Always a pleasure to cross you here ;)
<spiv> I wouldn't cross lifeless if I could help it ;)
<vila> damn... cross doesn't carry the idea of meeting briefly ?
<spiv> vila: it does somewhat, but it also carries the meaning of "To run counter to; to thwart; to obstruct; to hinder; to clash or interfere with." :)
<vila> Ouch :-)
<lifeless> its ok, I took your meaning as intended
<vila> What  common verb or expression should I use then ? (In case I came across less tolerant people :)
<spiv> vila: "overlap" is probably more unambiguous, unless someone wants to be interpret it in a physical rather than temporal sense ;)
<spiv> Cross is fine, I was just being silly.
<vila> more unambiguous... you try to lose me again :)
<spiv> Well, nothing's *totally* unambiguous in English.
<lifeless> meet
<lifeless> encounter
<spiv> intersect if you're feeling geeky.
 * davidstrauss also has an English degree. Is this a debate about diction?
<vila> Yeah, I think intersect carries the time scale I wanted to point to :-)
<spiv> Basically the problem isn't English, it's my enthusiasm for creative misinterpretation...
<vila> spiv: Oh, I see, strangely enough fullermd haven't intersect with the discussion yet.... :)
<davidstrauss> Oh, I see now that nothing of substance is being debated. Carry on. ;-)
<spiv> Heh.
<fullermd> Hmmwhat?  Did I miss a chance to screw English around?
 * fullermd gets rather cross.
 * igc dinner
<jelmer> lifeless, yeah
<LarstiQ> jelmer: moin
<LarstiQ> jelmer: I'm back at dizzy, want me to do anything?
<jelmer> LarstiQ, see privmsg
 * AfC wonders what we'd have to do to get ohloh to support bzr
<luks> given it's open source now and already supports hg, it shouldn't be that hard
<LarstiQ> is it open source now?
<LarstiQ> AfC: the +1s from users have been ignored so far
<LarstiQ> AfC: jelmer (iirc) and myself offering to help implementing notwithstanding
<LarstiQ> apparently not the right avenue to get things done
<luks> http://thechaw.com/ohloh_scm/
<AfC> LarstiQ: I know. Lots of us have offered
<jelmer> the source code for Ohloh has been published
<jelmer> at least the SCM-related bit
<jelmer> so somebody *could* contribute bzr support
<Pieter> how about you just create a patch, send it in and see what the feedback is?
<jelmer> unfortunately it's all ruby :-(
<jelmer> AfC: do you know any ruby ?
<LarstiQ> Pieter: that is now indeed possible, it wasn't before.
<AfC1> jelmer: not a line
<LarstiQ> jelmer: I have the pickaxe book, does that count? ;)
<lifeless> night all
<jam> vila: just wondering if you had a chance to play with my updated fix277537, and see how it worked for you
<jam> I'm going to be offline in about 10 min
<jam> I guesss a bit earlier, as my machine wants to reboot. hopefully bbiab
<vila> jam: rats, too late
<santagada> is there a bzr-html plugin, like the qt one?
<yml> is there a way to include in a file the rev and the date each time I commit a change on that particular file?
<Kinnison> There's a keywords plugin IIRC
<Kinnison> But that kind of thing is kinda nasty IMO
<yml> The context is that I would like to update this piece of information on the documentation store in the bzr branch.
<Kinnison> As I said, I think there's a plugin which may help you
<Tak> will bzr-git work with bzr 1.5?
<Lo-lan-do> I think it requires a newer version.
<Lo-lan-do> Hm, actually I'm not so sure.  The code doesn't seem to check.
<Tak> I tried doing a branch with 1.5, and got an error message saying bzr couldn't load the git plugin, but I didn't know if I'd done something wrong, or if the version was incompatible
<Lo-lan-do> What was the error message?
<Tak> oh, sorry: "Unable to load plugin 'git' from '/home/lbar4/.bazaar/plugins'"
<Lo-lan-do> Nothing else?
<Tak> nope
<jelmer> Tak, anything in ~/.bzr.log ?
<Lo-lan-do> jelmer: He uses bzr 1.5, but I didn't see any requirement for a greater version in git/__init__.py
<jelmer> Lo-lan-do, oh, you need bzr 1.12
<jelmer> or perhaps 1.11
<jelmer> the bzr API call to check the bzrlib version probably isn't in 1.5
<Tak> ok
<Tak> I guess I'll just use git for now then
<jelmer> hi btw :-)
 * Tak cry
<Tak> jelmer: have you looked at/tried my md-bzr branch recently?
<jelmer> Tak: Yeah, but I haven't managed to build it yet
<jelmer> dinner time, back in ~an hour
<Lo-lan-do> Uh, that time already?
<Lo-lan-do> Damn, the day went past without me noticing.
 * Tak nods
<jelmer> Lo-lan-do, well, Dutch traditionally eat at 18:00, I think it's more like 20:00 for the French?
<Tak> or later
<Lo-lan-do> I'm usually hungyr (and tired of work ;-) at around 19:00, but I was just generally wondering how it was already half past six and I thought I still had some time to do stuff.
<ronny> hmm
<ronny> argh dammit
<ronny> jelmer: how fast can you guys get rid of the single head branch thing - its the main gipe i always run into over and over
<Lo-lan-do> Is that the "colocated branches" thing?
<ronny> not exactly
<ronny> i dont care if they are named, but i want more than one head on the same branch
<ronny> well, not exactly branch - i just want multiple heads accessible from the same workingtree as easy as possible
<nDuff> ronny, ...referring to a git-like workflow?
<nDuff> ronny, "bzr switch foo" strikes me as pretty similar in effect, even if the implementation is different.
<ronny> nDuff: mostly monotone and hg alike
<ronny> bzr switch is a lot more for me to do
<nDuff> ronny, how so? if only providing the last element (not the full path), it reuses the location of your existing branch except for the last element, so it really does only need the branch name as the argument, not the URL.
<ronny> doesnt fit my workflow
<beuno> santagada, loggerhead
<nDuff> ronny, ...hmm; I haven't worked with monotone at all, and hg fairly little, so I'm not entirely sure what you're looking for... would it be similar to looms?
<ronny> no
<nDuff> ...hmm; as I don't grok the workflow distinction between using switch within a shared repo and multiple heads within a branch, I don't think I can help.
<ronny> nDuff: i mainly want to have a as simple structure in the fs as possible
<ronny> i dont care how exactly management works - but it should stay the hell outa my fs
<nDuff> ronny, ...oh, so it's not a workflow issue, but an aesthetics issue.
<ronny> i did set up my whole env to deal with the projects being in their place
<ronny> if they are suddenly in another place, its fucked
<jelmer> ronny, I need to get comments on my proposal for colocated branches first
<ronny> hmm
<ronny> jelmer: whats the url again
<jelmer> for the spec? It was posted to the mailing list?
<ronny> jelmer: i dont follow the ml and google didnt find it
<jelmer> ronny, one sec
<ronny> oh yikes
<ronny> i just noticed how broken the new bzr support for anyvc is
<jelmer> ronny, https://lists.ubuntu.com/archives/bazaar/2009q1/051320.html
<ronny> jelmer: as for collated branches in url's - how about a http get param?
<ronny> jelmer: alternatively collated branches can just be mapped to a directory containing multiple branches on a remote
<ronny> magic chatacters wont be nice
<jelmer> ronny: yes, but what if there is a on-disk branch with the same name?
<jelmer> ronny, this has already been discussed separately on the list, in a different thread
<jelmer> there wasn't a conclusive outcome
<ronny> jelmer: repo/branchname vs repo/collation/branchname or repo/collation?branch=branchname
<ronny> since collated branches wont have a physical path i think a get param maps the intend better, but a path maps it more restfull
<jelmer> ronny, GET-style parameters is more typing
<jelmer> ronny, martin has suggested using regular path separators and using GET-style parameters in case there is ambiguity
<ronny> but if one uses collated branches for git-alikeness wont he actually sync with the main url of the collation
<jelmer> ronny: ?
<CaMason> Hi guys. I'm getting "bzr_log.random-" files appearing in my working copy after commits (all successful). Any ideas how to prevent that?
<ronny> jelmer: as far as i understand git users usualy deal with paths to repos, not paths to branches
<CaMason> the contents of the files are the prefilled commit templates
<ronny> so they would deal with repo/collation instead of repo/collation/branch
<ronny> jelmer: also would there be an issue in just adding an extra path element to let the whole collation have a name?
<jelmer> ronny, yes, ambiguity with any actually existing branches on disk
<MvG> Hi! Can I push a bzr branch into a subdirectory of a svn repository using bzr-svn, even though the two are unrelated at first? How would I specify a merge base revision, as the error message "Branches have no common ancestor, and no merge base revision was specified." indicates?
<ronny> jelmer: can people do things like get a collation a repo/foo and a branch at repo/foo/bar
<jelmer> ronny: bzr's UI is very much oriented towards branches, git only uses URLs for repositories
<jelmer> ronny: yes, there can be a (nested) branch or regular branch at repo/foo/bar
<jelmer> MvG, you can merge in that case using -r0..-1
<jelmer> MvG, I mean "bzr merge -r0..-1 <url>"
<MvG> jelmer: But I want to push, not merge. I can't merge from a nonexistant directory, can I?
<jelmer> MvG, are you using "bzr svn-push" ?
<MvG> jelmer: No. Should I?
<jelmer> MvG, yes - see the bzr-svn FAQ
<ronny> jelmer: oh :/ then it needs an url param
<MvG> OK, will do. Once I've reestablished my bzr-svn setup, which I've just nuked by pulling and deleting subvertpy...
<jelmer> ronny, See my lines earlier - Martin suggested using path separators but falling back to GET-style parameters to deal with ambiguity
<ronny> jelmer: there is a major issue - how does a user decide if he needs to fall back
<ronny> hmm
<ronny> now i need  the docs for workingtree - is there anything beside source/pydoc?
<asabil> jelmer: what about adding a -b option flag ?
<jelmer> ronny, pydoc should be pretty comprehensive
<asabil> or would that break a lot of things UI wise ?
<jelmer> asabil, impractical and that would mean adding a branch parameter in the API everywhere as well
<asabil> yes I see
<MvG> jelmer: Is there an easy way to install bzr-svn + subvertpy as user - preferably with unmodified branches symlinked to dirs like ~/.bazaar/plugins? Used to work before subvertpy got factored out, but I can't seem to get it working now.
<jelmer> MvG, you can install subvertpy into the system or set PYTHONPATH appropriately
<MvG> Both feel ugly, but I'll use this for now I think.
<jelmer> ronny, also feel free to ask questions here if you have them, of course
<ronny> jelmer: just started fixing stuff, seems like the bzr stuff someone else added to anyvc is highly bugged
<santagada> beuno: sorry, what was it
<santagada> ?
<beuno> santagada, if you want a web UI for bzr, you can use loggerhead
<ronny> hmm
<santagada> beuno: no I wanted something like a plugin that output html
<ronny> god i wish anyvc was already usable for web ui's
<santagada> so I could use the result of bzr blame inside some other tool (in my case textmate)
<beuno> santagada, you can use bzr-xmloutput
<santagada> beuno: then use a xslt transform to transform it to xhtml?
<beuno> santagada, maybe, yes  :)
<jelmer> beuno: Hi Martin :-)
<santagada> beuno: not a big fan of xslt... maybe I will use the bzr api and generate html using something like jinja templates
<santagada> beuno: thanks
<ronny> what package defines the NotBranchError?
<jelmer> ronny, bzrlib.errors
<nDuff> santagada, as an aside, if you're trying to generate xhtml, I'd consider using Genshi as a way to be certain that your output is always well-formed.
<santagada> nDuff: I don't care much about well formed, and it will be any html that webkit can grok
<santagada> and I don't like genshi
<santagada> it's better than xslt
<kfogel> I've done 'bzr init-repo .; bzr branch lp:bkrpr bkrpr-trunk; <<bind bkrpr-trunk to lp:bkrpr so it's a mirror, using instructions from http://bazaar-vcs.org/Scenarios/RepeatedContributions>>; bzr branch bkrpr-trunk bkrpr-task-branch-foo; cd bkrpr-task-branch-foo; <<edit some files>>; bzr commit -m 'Finish my task.' "
<kfogel> Is 'bzr push lp:bkrpr' the right way to send my change to the upstream?
<kfogel> I'm reading '6.2.5   Merging a feature into the trunk' in the User's Guide, but I'm not 100% sure 'bzr push' is the right thing...
<bialix> CaMason: ping
<bialix> CaMason: you has asked your question about bzr_log files
<CaMason> bialix: yes :)
<bialix> CaMason: these files have created by your editor when you type the commit message. I suppose it's auto-backup. What is your editor?
<CaMason> I'm actually wondering if it is anything to do with vim... I did vimtutor the other day (which helped set up a .vimrc)
<bialix> I recall this question has raised in the past
<bialix> IMO you can delete these files safely. I don
<CaMason> I do delete them.. it's just messy having them in my wc :)
<CaMason> must be a setting within this .vimrc then
<bialix> I don't use vim, so I can't help and suggest how to prevent them
<rblasch> jelmer: Hi, can I ask you a bzr-svn question?
<jelmer> rblasch, yeah, np
<bialix> CaMason: something like :w!-+?@ combinaion needed. more or less
<CaMason> bialix: no worries, thanks either way.. it's help me pinpoint my thoughts :)
<rblasch> Great!  I've set up thing to work with the latest 0.5 version.
<rblasch> When doing a branch, bzr suddenly hangs.
<bialix> CaMason: It's just silly to see how you ask this question several days in row and nobody answer
<rblasch> The last message I get is "determining revisions to fetch 11111/36167", without any further progress.
<rblasch> CPU load stays high, though.
<CaMason> bialix: I was thinking.. if this was an editor issue, somebody would have seen it before :s
<rblasch> Same thing with 0.4 works fine.
<bialix> yep
<bialix> CaMason: that's all I know. good luck
<rblasch> Is there any diagnostics I can enable to track this down?
<Lo-lan-do> rblasch: Could it be the same as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513412 ?
<ubottu> Debian bug 513412 in bzr-svn "bzr-svn: Fetching revisions from SVN is slow" [Normal,Open]
<CaMason> bialix: aha, I think i've spotted the line. An if statement was overriding my set nobackup :)
<jelmer> rblasch: you can run with -Dtransport -Dcache and see what it is doing
<Lo-lan-do> rblasch: Try with -Dtransport -Dcacne
<jelmer> rblasch, also, you can try with bzr.dev, that will have better progress indication
<bialix> :-)
<CaMason> bialix: ahh I've seen what confused me now. I'm used to vim making backup files with a tilde. However, for some reason my terminal is showing tilde more like a dash
<CaMason> so the 'backup' files didn't look like normal vim backups to me
<rblasch> jelmer: Will do.  Actually I'm using bzr.dev.
<bialix> CaMason: so now you know kung-fu ;-)
<CaMason> bialix: oh yes >:)
<bialix> great
<jelmer> rblasch, it will write status messages to ~/.bzr.log
<rblasch> jelmer: Yes, it looks like the same issue.  "revprop list" counting down.
<rblasch> jelmer: It's just that I got 36k+ revisions, that's why it feels like it's taking forever.
<jelmer> rblasch, ah, k
<rblasch> jelmer: So it's already a known issue.  Thanks for your time, and a whole lot more thanks for this brilliant plugin!
<jelmer> rblasch, np!
<jelmer> rblasch, Hopefully this will be fixed in 0.5.1
<Lo-lan-do> \o/
<Lo-lan-do> (One more beer for jelmer on Friday night :-)
<ronny> jelmer: whats the correct way to get a diff of the workingtree?
<Lo-lan-do> "Lightweight checkout (format: 1.6 or 1.6.1-rich-root or 1.9 or 1.9-rich-root or dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)"
<ronny> http://paste.pocoo.org/show/102476/ <- see the diff method in line 148 for the current broken way :(
<Lo-lan-do> Wow, that's incredibly useful :-)
<jelmer> ronny, yikes, that *is* broken
<jelmer> ronny, you're trying to get the changes against the last committed revision here right?
<ronny> jelmer: yeah
<ronny> jelmer: im fixing javiers stuff :(
<jelmer> ronny, call show_diff_trees(self.wt.basis_tree(), self.wt, strdiff, specific_files=relpaths)
<jelmer> ronny: new_tree.branch.revision_history()[-2] will always be wrong, the last committed revision is (obviously) [-1]
<ronny> jelmer: i noticed by accident that the diff was bewen tip and tip-1
<jelmer> ronny, also, some other notes (while I'm looking at this code anyway):
<jelmer> ronny, wt.remove() can take a list of files, there's no need to iterate over all files
<jelmer> ronny, revert() seems right only in the case paths=None
<beuno> ronny, is this for pida?
<kfogel> I've done 'bzr init-repo .; bzr branch lp:bkrpr bkrpr-trunk; <<bind bkrpr-trunk to lp:bkrpr so it's a mirror, using instructions from http://bazaar-vcs.org/Scenarios/RepeatedContributions>>; bzr branch bkrpr-trunk bkrpr-task-branch-foo; cd bkrpr-task-branch-foo; <<edit some files>>; bzr commit -m 'Finish my task.' "
<kfogel> Is 'bzr push lp:bkrpr' the right way to send my change to the upstream?
<kfogel> I'm reading '6.2.5   Merging a feature into the trunk' in the User's Guide, but I'm not 100% sure 'bzr push' is the right thing...
<ronny> beuno: yeah
<beuno> ronny, many bugs in the bzr integration?
<ronny> it was less when i used subprocess
<ronny> then i merged the work of someone else
<ronny> now i do myself
<ronny> and of course i lack unittests :(
<jelmer> ronny, I also don't think the converting to relative paths is necessary
<ronny> jelmer: absolute paths is necessary, since i pass paths relative to the repo base, i have to reiterate a few time till its more nice
<jelmer> ronny, but there's no need to convert *back* to relative paths afaik, as is done in a few places
<ronny> k
<beuno> ronny, this is Javier Derderian's work?  is it not good quality?
<ronny> unfortunately it seems like this part of his work isnt good
<beuno> ronny, I'm sorry to hear that  :(
<ronny> jelmer: hmm, is there a tool to do globing?
<ronny> i think i could use that
<jelmer> ronny, not that I'm aware of, the shell takes care of that for us I think. There may be something in the win32-specific code
<ronny> hmk
<jelmer> ronny, what would you need globbing for anyway, it seems like a bad thing to be part of a UI..
<jelmer> eeuhm, API
<ronny> jelmer: probably right, shell mindset sometimes is nasty
<ronny> hmm
<ronny> jelmer: for some reason my current usage of diff causes a traceback, please take a look at the current code + trace on http://paste.pocoo.org/show/102490/
<jelmer> ronny, one of paths is not known by bzr?
<ronny> jelmer: thats the base path of the repo
<ronny> hmm, let me dig if i find where it comes in
<jelmer> ronny, perhaps try ["."]
<ronny> seems like it doesnt like an abspath
<bialix> LarstiQ around?
<ronny> jelmer: i intend to make the shell command vc diff work in bzr repos
<ronny> (anyvc ships a executable called vc)
<bialix> LarstiQ: ping
<LarstiQ> bialix: yeah
<LarstiQ> bialix: pong :)
<bialix> LarstiQ: I've finished new format of project.cfg
<LarstiQ> bialix: cool
<LarstiQ> bialix: is it in trunk, or in a seperate branch?
<bialix> I've implemented some of your notes as well
<bialix> it's separate branch
<ronny> jelmer: diff seems to work fine as soon as i use a relative paths
<jelmer> ronny, hmmok
<LarstiQ> bialix: ok
<bialix> LarstiQ: so if/when you will be curious you can play with lp:~bialix/bzr-scmproj/format-change
<LarstiQ> bialix: noted
<bialix> LarstiQ: you have to upgrade your .scmproj by hands. Or may be recreate it
<bialix> sorry for inconvenience
<LarstiQ> bialix: that's ok
<bialix> there is doc for early adopters
<bialix> at least it says what should be changed
 * LarstiQ is very tolerant of this sort of inconvenience.
<LarstiQ> JSF t:updateActionListener not working, not so much
 * LarstiQ had a long day at work
<bialix> yeah, it's still alpha. so I have a poor excuse
<LarstiQ> :)
 * LarstiQ branches the format-change branch
<bialix> LarstiQ: I understand. It's just head u
<bialix> head up
<bialix> you seem to be interested
 * LarstiQ nods
<LarstiQ> bialix: I am.
 * LarstiQ just needs to blow off steam re work
<bialix> I saw good news about nested trees here, abentley will continue this work
<bialix> this is great
<bialix> but in the meantime I'll continue my work too
<bialix> in some sense I feel they are orthogonal
<bialix> LarstiQ: rest well! I'm going to rest too.
<LarstiQ> bialix: hey, part of my rest is reading irc (backlog) ;)
<bialix> :-D
<LarstiQ> bialix: yeah, I'm happy that Aaron is coming back to them.
<bialix> I understand
<LarstiQ> bialix: and I'll certainly keep you posted of the progress
<ronny> hmm
<ronny> now i have to figure iter_changes
<bialix> LarstiQ: it's great
<bialix> woohoo!
<LarstiQ> :)
 * bialix disappears
<lifeless> moin
<mwhudson> hi lifeless
<jelmer> kfogel, still there?
<jelmer> kfogel, In that particular workflow, pushing to trunk would be appropriate I think
<ronny> jelmer: is there any description on how to interpret the items that wt.iter_changes yields?
<ronny> an 8 tuples with some items + nested 2 tuples is pretty confusing at first sight
<jelmer> ronny, see the docstring for bzrlib.tree.InterTree.iter_changes
<LarstiQ> ronny: bzrlib.tree.InterTree.iter_changes docstring
<ronny> nice
<LarstiQ> ronny: you might also want to look at bzrlib.delta
<LarstiQ> ronny: and bzrlib.dirstate for more gory details
<ronny> iter_changes seems to be the right way to get what i need
<ronny> nice full detail level and easy to translate to the terms of anyvc
<beuno> ronny, maybe loggerhead's code can help you as well: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/head%3A/loggerhead/history.py
<beuno> we generate diffs
<beuno> maybe this is better: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/head%3A/loggerhead/controllers/diff_ui.py
<ronny> hmm
<ronny> beuno: at some point i'll have to add a web ui for anyvc
<ronny> remote branch/repo management + smart servers for hg/bzr
<lifeless> here we compressbench again
<lifeless> jelmer: did you use the compressbench results at all ?
<lifeless> Jc2k: ping
<jelmer> lifeless, not yet
<jelmer> lifeless, I'm going to this week
<jelmer> lifeless, dpush is almost working for bzr-git
<jelmer> that was the main thing I worked on
<lifeless> cool
<Lo-lan-do> Look, at some point it will cease to be reasonable for me to buy you drinks, you know.
<jelmer> Lo-lan-do, at some point I assume it will also start affecting the quality of my code ;-)
 * Lo-lan-do tries to think of a way to hack a two-way bzr/git gateway for several branches without colocated branches
<lifeless> looms
<mwhudson> do the error reports in https://answers.edge.launchpad.net/launchpad/+question/59649 ring bells with anyone here?
<mwhudson> he's using an ancient bzr, but still
<lifeless> I'm down to console only while profiling
<lifeless> if you need me don't email :) and I can't read pastebin easily
<lifeless> mwhudson: what is he seeing?
<mwhudson> weird-ass errors from pushing over sftp mostly
<mwhudson> the other stuff i think i can explain
<mwhudson> but really, 0.11.0
<lifeless> uhm
<lifeless> thats pre-packs
<lifeless> iz bad
<mwhudson> yar
<Lo-lan-do> i can haz pakz?
<ronny> jelmer: btw, are there any plans for a bzr-hg when bzr-git is done?
<jelmer> ronny, there is a bzr-hg already, https://launchpad.net/bzr-hg
<jelmer> it already allows you to browse logs, etc
<ronny> oh, i missed that
<jelmer> though not much more beyond that
<santagada> jelmer: so you also have a time machine?
<santagada> I tought only guido could go back in time
<lifeless> santagada: we're quite fond of 'heres one I prepared earlier' here :)
<santagada> :)
<ronny> jelmer: im mainly asking cause hg wont grow a hg-bzr anytime soon and i prefer to use hg
<LarstiQ> ronny: it needs more love to be useful
<ronny> im pretty busy with exams + moinmoin + anyvc + pida + vellum atm
<ronny> hmm
<ronny> ok, mapping stuff from iter_changes to my personal anyvc status info is more tricky than i tought
<ronny> time to wire up a plan
<LarstiQ> ronny: Jelmer is doing a vcs tour, I'm sure he'll make a bridge for everything eventually ;)
<jelmer> LarstiQ, I think the key is convincing the other Samba developers to switch to hg
<ronny> oO
<lifeless> jelmer: ?
<Lo-lan-do> Sounds like a plan :-)
<ronny> samba developers to hg ?
<ronny> whats up with that?
<jelmer> lifeless, that way I'll end up working on bzr-hg to make sure I can still work on Samba with bzr
<lifeless> indeed
<Lo-lan-do> Samba switches to X â jelmer does bzr-X
<lifeless> ronny: he's trolling/being humuour
<jelmer> ronny, I started working on bzr-svn because Samba was using that at the time, I started working on bzr-git when Samba switched to Git
<ronny> ah i see
<LarstiQ> and started looking at bzr because tridge had mentioned that as a possible succesor to svn?
<ronny> hmm
<jelmer> LarstiQ: no, I looked at it before that
<LarstiQ> jelmer: ah ok
<jelmer> LarstiQ, I started looking into early versions after seeing Martin's talk at LCA 2005
 * LarstiQ started because uws was using it, and he wanted to try a dvcs other than (l)arch
<Lo-lan-do> Ugh, arch.
<LarstiQ> Lo-lan-do: when it was all still shell scripts
<Jc2k> lifeless: pong
<Lo-lan-do> I used tla and baz, but that didn't make it much better.
<Lo-lan-do> I still resent (a bit) the annexion of the Bazaar name by bzr, but I have to concede it's *vastly* superior :-)
<lifeless> Jc2k: I want to eliminate fork() from my compressbench; that means calling into libgit directly etc
<lifeless> Jc2k: if this is hard I will skip it in the interests of time
<lifeless> Jc2k: I hear you've done some stuff in this area
<Jc2k> lifeless: probably nothing thats suitable for what you need right now
<Jc2k> lifeless: i dont think there is a c-lib for packing stuff, unless libgit2 has advanced *a lot* from last time i heard about it
<lifeless> Jc2k: I don't care about time-to-pack at this point, rather reliable comparisons for time-to-unpack
<lifeless> I want to know precisely how long git takes to extract the same corpus knits do
<lifeless> it would be stupid to go to a slower disk level format, for instance, if the performance win is purely that 'its C'
<lifeless> and right now we're still largely flying blind
<Jc2k> *nod*
<Jc2k> so aside from dulwich and calling git binaries the only other options are:
<lifeless> all I know for sure is that dulwich is something like 200 times slower at extracting texts from packs than bzr is from its packs
<Jc2k> libgitcore. unfinished refactor of git into a library
<Jc2k> libgit2. ground up rewrite of git as a library. might not have any pack foo.
<lifeless> ok, thanks
<Jc2k> im pretty sure libgitcore would need non-trivial hacking on before you could use it
<Jc2k> we gave up on it post-guadec
<lifeless> so groupcompress
<lifeless> avg 0.0836303479982
<lifeless> knit
<lifeless> avg 0.0119135125978
<lifeless> I'm going to determine an answer as to 'why' today
<lifeless> I hope
<lifeless> if its design, I'll be shelving it, for now.
<lifeless> One candidate reason is space-time tradeoff, the knits corpus is 25.4M, the gc corpus is 3.5M
<Jc2k> http://repo.or.cz/w/libgit2.git
<Jc2k> doesnt have any pack stuff by the looks of things
<lifeless> in such a scenario, a group cache would win
<lifeless> so thats a knob I'm tinkering with now
<lifeless> as basic profiling has simply told me 'zlib is much of it'
<lifeless> do you know, does git use any buffers
<lifeless> or caches
<lifeless> e.g., if it reconstructs texts X, Y, Z
<lifeless> and X was compressed against Y, and Y against Z
<lifeless> so getting X out first means getting Y and Z, but the command then wants Y, will it start over, or have it ready to use?
<Jc2k> there is a delta_base_cache
<lifeless> great
<lifeless> do you recall how big it is ?
<Jc2k> its an LRU of 256 objects
<lifeless> cool
<lifeless> so the pattern of recent-at-front, compression will tend to get a good hit rate
<lifeless> as well as making the first objects asked for rapidly available
<lifeless> it would be interesting to find history patterns that make the cache thrash
<lifeless> vila: ping
<igc> morning
<mwhudson> hi igc
<mwhudson> igc: i need to look at bzr-revnocache sooner or later but i should read the source first :)
<jelmer> down to only 26 bzr-svn bugs, a lot of which wishlist items (-:
<igc> hi mwhuson
<igc> bzr-revnocache still needs a lot of work but ...
<igc> that can come after the 1.12rc ships
<tro> bzrtools 1.11 isn't present in the hardy ppa :(
<igc> in particular, it currently stores the full sorted history for every branch
<igc> when there's a local mirror + feature branches, I want it to store just the new history for feature branches and delegate back to the mirror for the rest
<igc> mwhudson:^^
<mwhudson> igc: do you just dump it and recalc when the tip changes?
<mwhudson> it sounds a little bit like having .bzr/branch/revision-history back
<igc> that's before my bzr time :-)
<lifeless> igc: revision-history stored the full left hand history
<lifeless> igc: its an O(history) operation to update
<igc> right
<lifeless> igc: and it dominated push and pull
<igc> my caching doesn't slow down either or those
<igc> when the tip moves, it removes the cache ...
<mwhudson> i have this feeling that i'm going to end up working on O(new-stuff) updates to merge-sorted revision graph
<mwhudson> for loggerhead
<igc> and it gets saved the next time it's calculated
<mwhudson> unless i can trick someone else into doing it :)
<lifeless> igc: my point is that updating it over the wire is a huge amount of work
<Lo-lan-do> jelmer: Would a "AttributeError: 'SvnRepository' object has no attribute '_iter_revmeta_ancestry'" count? :-)
<igc> right - I only support local caches
<lifeless> igc: I think a plugin is the right place to work on this problem
<lifeless> igc: and I think its good you are doing it
<igc> thanks
<jelmer> Lo-lan-do, which branch are you using?
<Lo-lan-do> http://bazaar.launchpad.net/~jelmer/bzr-svn/0.5/
<Lo-lan-do> r2500
<jelmer> Lo-lan-do, ah, the main branch is on http://people.samba.org/bzr/jelmer/bzr-svn/0.5
<jelmer> launchpad mirrors it, but it seems to take up to half a day for it to do so
<Lo-lan-do> Okay, I'll rerun my checkout then, but I'll let it run during the night since it takes forever and I really should be in bed by now.
<lifeless> jelmer: you can tell lp to do it faster
<lifeless> jelmer: e.g. on push
<jelmer> lifeless, how?
<spiv> lifeless: oh, that plugin exists now?
<lifeless> I filed a bug asking for this capability
 * Lo-lan-do â sleep
<lifeless> it has been closed with info that its somewhere in lp-api
<jelmer> Lo-lan-do, g'night
<jelmer> lifeless, I don
<jelmer> 't have launchpadlib here, I'm on Debian :-)
<lifeless> jelmer: I don't see why that precludes launchpadlib
<jelmer> lifeless: being on Debian, you mean?
<lifeless> right
<lifeless> install the dependencies, install the jaunty package
<jelmer> lifeless, launchpadlib, wadlib and httplib2 aren't packaged there
<jelmer> Anyway, I don't care enough about launchpad to do so
<lifeless> subvertpy - new dependency? Didn't it use to be bundled?
<jelmer> lifeless: yes, it's now developed and distributed separately
 * lifeless removes bzr-svn again
<lifeless> its too muc futzing around to keep it going when I'm not actively hacking on it or using it
<jelmer> it's in the PPA these days, fwiw
<lifeless> in particular, I run all my dev plugins from source
<lifeless> so a dependency that has to be installed to be used is a real nuisance
<lifeless> (I run them all from source to allow version switching trivially)
<jelmer> lifeless, it's just a python module like any other, the API is stable, no ties to bzr
<lifeless> I know, but its namespaced outside
<lifeless> so rather than rm foo; ln -s /other foo
<lifeless> I have to do a dance
<spiv> I have a one-line hack in my bzr-svn checkout to add my subvertpy checkout to sys.path...
<lifeless> jelmer: don't get me wrong, I think its great to promote reuse like you are
<lifeless> but it has a cost
<lifeless> which I'm not willing to pay until I need to do something with bzr-svn again
<lifeless> e.g. loggerhead tweaks or whatever
<lifeless> ok, group cache working, lets give it a spin
 * lifeless wait()s
<jelmer> lifeless, sure, I understand. Similar to what I have with launchpadlib...
<lifeless> I wish lplib didn't use httplib2
<lifeless> that thing is terrible
<lifeless> I looked, went blind, walked away
<jelmer> (which is one of the reasons why I pinged James about uploading to Debian as well)
<lifeless> breakfast while this runs
<furicle> Warning - RCS newbie - I've taken a tarball, did a bzr init - bzr add - hacked, commited - now I want to export only my changes back upstream as patches - but  bzr diff is putting out binary crud because I removed some pdfs.  What do I do?
<lifeless> furicle: bzr normally detects binary files;
<lifeless> furicle: what command are you running to get this export ?
#bzr 2009-02-03
<furicle> lifeless: I'm just doing bzr -r1
<furicle> lifeless: pardon - bzr diff -r 1
<lifeless> furicle: ok, as a workaround you can use filterdiff -x '*.pdf' or something like that, to remove the pdfs in your diff
<lifeless> please file a bug, this is something we can clearly do better on
<lifeless> Jc2k: avg 0.00275434756196
<lifeless> avg 0.0118949759048
<Jc2k> lifeless: did gc just kick some arse or do i need an eye test..
<lifeless> arse kicking
<lifeless> as usual the story is more complex
<Jc2k> ah boo :[
<lifeless> let me paste results
<lifeless> http://paste.ubuntu.com/113016/
<furicle> lifeless: thanks for the info - I can pipe it out to vim and hack it back out, just wondered if I was doing something wrong.  Thanks for the info
<lifeless> furicle: are you going to file a bug? If not, I will - but I don't have the test data to reproduce if its not obvious
<lifeless> Jc2k: in particular look at the max time
<lifeless> 0.17 is because we read one big zlib hunk
<lifeless> but after that the entire inventory for all of the repo is in one compressed record
<Jc2k> so your saying the zlib reads are gonna kill us anyway?
<lifeless> I'm saying its going to depend a lot
<lifeless> ><
<lifeless> like
<lifeless> annotate will kick arse
<lifeless> but 'read the most recent commit message only' will be slow
<lifeless> read all commits will be fast
<lifeless> etc
<lifeless> we can trade time and space here
<lifeless> if we cap the groups smaller
<lifeless> then the zlib read will be less
<lifeless> but we'll have more groups
<lifeless> its not beyond hope
<lifeless> we can still look at short reads and decompresses for random access
<lifeless> we could keep recent texts at the front of groups
<Jc2k> so in comparison to git: git looking at the most recent commit can generally look at the first object in the pack (or near) and it will generally be a full text rather than a delta so it will be (seek a few bytes in) (hot zlib action) done.
<lifeless> yah
<Jc2k> what does gc have to do?
 * Jc2k missed your intro to gc as rob led you away at guadec :(
<lifeless> can I say it depends and wave my hands a lot ?
<Jc2k> sure :D
<lifeless> it depends, wave wave wave
<lifeless> ok
<lifeless> have you read the README in bzr-groupcompress?
<Jc2k> nope, *scurries off to look*
<lifeless> when you've read that you will understand the tuning I'm talking about I hope
<lifeless> though I can and will enlarge from there
<Jc2k> GPL GPL GPL GPL, lets make things smaller. read DESIGN. k thx end. :p
<lifeless> oh yeah DESIGN.
<lifeless> me
<lifeless> h
<lifeless> I knew which document I meant
<lifeless> pet peeve, -d isn't global
<Jc2k> ok. generic process parsed.
<lifeless> wow, think I found a knit bug ><
<lifeless> so
<lifeless> two layers
<lifeless> stream-of-build-recipes
<lifeless> efficient *fast* compressor on top
<lifeless> the build recipe stream should be 80% of the compress, or something like that
<lifeless> cost to get a single text out is clearly:
<lifeless> cost to decomopress outer enveloper up to the end of the text build recipe + cost to parse and execute the build recipe
<lifeless> best case cost would be no outer envelope and the first text in the stream
<lifeless> because we could just read that text and ignore the rest
<furicle> lifeless: I will file a bug.
<lifeless> furicle: thanks
<lifeless> Jc2k: did you catch my cheating ?
<Jc2k> lifeless: so.. to clarify "no outer envelope", no envelope compression at all? no zlib of the recipes?
<lifeless> right
<lifeless> we can get rid of the decomp cost
<Jc2k> in which case, you just read a full text and there is no decompression or assembly to do at all
<Jc2k> so its uber fast
<lifeless> just read as much of the stream as needed
<lifeless> but larger
<lifeless> say 100% larger
<lifeless> which of course for network IO isn't such a great thing
<lifeless> but its an option
<Jc2k> but we can fix that with smart reads, right?
<lifeless> depends on the use case
<lifeless> like, smart server, the server could zlib on the fly
<lifeless> sftp, you will be reading whats on disk directly
<Jc2k> but group compress + smart server could use delta bases that it knows are on the client for example
<lifeless> ah
<lifeless> look closely at a recipe
<lifeless> its not a delta as suc
<lifeless> this is a recipe:
<lifeless> ['label: label\n',
<lifeless> 'sha1: xxxxxxxxxxxxxxxxxx\n'
<lifeless>  'i,3\n'
<lifeless> 'strange\n',
<lifeless> 'common\n',
<lifeless> '\n',
<lifeless> ]
<lifeless> that recipe will create the text ['strange\n', 'common\n']
<lifeless> this recipe:
<lifeless> 'label: newlabel\n',
<lifeless> 'sha1: xxxxxxxxxxxxxxxxxxxxxxxxxxxx\n'
<lifeless> 'c,72,7\n',
<lifeless> 'i,1\n',
<lifeless> 'different\n',
<lifeless> 'i,1\n',
<lifeless> '\n'
<lifeless> ]
<lifeless> copies 7 bytes from byte 72 into its output
<Jc2k> so recipes allow you to select ranges from the base text and insert next text?
<lifeless> from the stream so far
<Jc2k> ah
<Jc2k> where as git patch opcodes only let you reference the base text
<lifeless> this is why it compresses so well without threaded computation of best-parent
<lifeless> because it uses every single text compressed so far as a parent
<Jc2k> gotcha
<lifeless> so the least cpu work to get the first text out is no zlib wrapper, and read in only the bytes for the first text
<lifeless> least average work is probably zlib, because less IO does matter
<lifeless> theres a typical U graph trading off space and time in different scenarios ere
<lifeless> now, the current decompression code, for the first text, reads the entire zlib envelope, decompresses the entire thing, puts that in a lru cache, then grabs the recipe it needed and generates the output
<lifeless> changing this to read less is complex in two ways: how much of the zlib record has to be read to decompress the recipe for the first text, and how much will eventually be wanted
<lifeless> the greedier we are, the more upfront work, but the less round trips
<spats> hey all. I'm having trouble merging a task branch back to trunk; bzr is telling me there are no changes to commit after I do the merge, despite showing me a +N line during the merge. What am I missing? See http://pastebin.com/d646d281
<lifeless> spats: its because you are trying at revision 0
<lifeless> spats: do your test case again, but after initing 'main', do a commit
<lifeless> even a commit with no content
<spats> aha! okay, thanks :)
<lifeless> revision 0 can't be merged with things, its a blackhole to bootstrap from :)
<lifeless> so your merge is in effect a pull
<lifeless> its a little wart, but one most folk can't ever encounter :P
<spats> lifeless: I was trying to follow the "never check in to the mainline" theory a bit too literally - make a branch for initial code checkin. I might just add an empty checkin to the process.
<Jc2k> lifeless: tough problem :)
<lifeless> Jc2k: does git do delta combining?
<lifeless> Jc2k: that is, to recreate something at the end of a chain of 200 texts
<lifeless> does it get(base); patch(base->2); patch(2->3);; etc
<lifeless> or does it get(base), combine_patches(2,3,4,5,...); patch(base->200)
<Jc2k> it can chain, and there is a limit on the length of chains
<Jc2k> its the 1st
<lifeless> ok
<Jc2k> base + patch = object 2, object 2 + patch = object 3
<Jc2k> and the limit is much lower than 200 from what i recall
<lifeless> folk on forums say --200 --200
<lifeless> and benchmarkers are using that
<lifeless> default is 50
<Jc2k> i think it was just 10 in the beginning
<lifeless> anyhow
<lifeless> so to be faster than git
<lifeless> we have to be faster at some key operations
<lifeless> and also faster in things like fetch that inspect every object
<lifeless> I think gc is there now, modulo optimising
<lifeless> but the recent-history case still concerns me
<lifeless> I think that that perhaps some hinting to the engine
<Jc2k> can we be a bit bigger and faster locally, and smaller and a bit slower when doing stuff remote?
<lifeless> 'I only want one thing, kthanks'
<lifeless> yes, thats possible assuming decompress and recompress during push
<lifeless> we could even just change the zlib layer for that
<lifeless> ok
<lifeless> so a rough figure
<lifeless> first 1000 revs of bzr
<lifeless> knits->knits 5 seconds
<lifeless> gc->gc 19 seconds
<lifeless> note that we have much better integrity checking in the latter case, so its not quite apples-apples
<lifeless> and the gc repo is 50% of the size
<lifeless> $ du -sh gc/.bzr
<lifeless> 1.3M    gc/.bzr
<lifeless> $ du -sh plain/.bzr
<lifeless> 2.4M    plain/.bzr
<lifeless> slightly faster at some ops too:
<lifeless> $ time bzr log -v plain/t > /dev/null
<lifeless> real    0m11.920s
<lifeless> $ time bzr log -v gc/t > /dev/null
<lifeless> real    0m10.775s
<lifeless> tree building too
<lifeless> gc/t$ bzr remove-tree && bzr checkout . && bzr remove-tree && time bzr checkout .
<lifeless>                                                                                                                                                                                                                    
<lifeless> real    0m0.914s
<lifeless> plain/t$ bzr remove-tree && bzr checkout . && bzr remove-tree && time bzr checkout .
<lifeless>                                                                                                                                                                                                                    
<lifeless> real    0m1.069s
<Jc2k> sleep time for me (its 1.30 already!)
<Jc2k> good luck lifeless
<lifeless> gnight!
<lifeless> >< thumper - bzr push bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/fix-chunked
<lifeless> ...
<lifeless> bzr: ERROR: exceptions.KeyError: 'pqm@pqm.ubuntu.com-20090131231933-8o4phfvmuuizyyn6'
<lifeless> Traceback (most recent call last):
<thumper> lifeless: hi
<mwhudson> lifeless: is the branch packs5/branch6?
<lifeless> mwhudson: think so
<thumper> was probably initially pushed when that combo made a broken branch
<lifeless> $ bzr push bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/fix-chunked
<lifeless> Using default stacking branch /~bzr/bzr/trunk at bzr+ssh://bazaar.launchpad.net/%7Elifeless/bzr/
<lifeless> Source format does not support stacking, using format: '1.6'
<lifeless>   Packs 5 (adds stacking support, requires bzr 1.6)
<lifeless> thumper: new branch today
<thumper> arse
<lifeless> igc: new groupcompress pushed, FYI
<lifeless> spiv: ^
<mwhudson> lifeless: i suppose you're not using bzr 1.9 still are you? :p
<spiv> lifeless: shiny
<lifeless> mwhudson: bzr.dev
<furicle> lifeless: For the record - bug#320783 - already existed - I just added my two cents - might be any pdf file
<lifeless> furicle: thanks!
<lifeless> I'm going to get gc able to pull all of bzr.dev
<thumper> lifeless: it seems that the branch has repo format 1.9 and branch format 1.6
<lifeless> urgh
<lifeless> so it stacked, but didn't upgrade the branch format on the fly
<mwhudson> and is not stacked
<lifeless> oh
<lifeless> it is a stackable format branch
<lifeless> just not stacked
<thumper> http://bazaar.launchpad.net/~lifeless/bzr/fix-chunked/.bzr/repository/format
<thumper> says 1.9
<lifeless> thumper: it should be 1.9, I've upgraded
<mwhudson> branch.conf is empty
<thumper> http://bazaar.launchpad.net/~lifeless/bzr/fix-chunked/.bzr/branch/format
<lifeless> but the branch I pushed from is branch6 or so
<thumper> says Branch Format 7
<lifeless> Bazaar Branch Format 6 (bzr 0.15)
<lifeless> right
<lifeless> thats the autoupgrade stuff kicking in to support stacking
<thumper> k
<thumper> mwhudson: where is the stacked branch kept?
<mwhudson> so it converts the formatting appropriately, but doesn't actually set the stacking
<lifeless> which is a bit odd for folk that don't want their project to suddenly grow a dependency on latest bzr; or is it per-project enabled in lp ?
<mwhudson> thumper: .bzr/branch/branch.conf
<mwhudson> lifeless: i'm pretty sure the auto-upgrading only happens when you have a mixed format like a new repo but old branch
<lifeless> mwhudson: ok, anyhow lets not get distracted
<mwhudson> yeah
<lifeless> theory is the autoupgrade half-worked
<mwhudson> well i'm already distracted :)
<mwhudson> but yes
<mwhudson> there should be tests for this stuff, maybe they only check the formats, not that the new branch is stacked?
<lifeless> none in blackbox.test_push
<mwhudson> nor branch_implementations.test_stacking it seems
<mwhudson> spiv: hey you, you fixed this bug
<lifeless> def test_push_doesnt_create_broken_branch
<lifeless> is close
<mwhudson> that sounds like something i wrote :)
<mwhudson> hm, maybe not
<mwhudson> test_push_with_default_stacking_does_not_create_broken_branch
<mwhudson> in branch_implementations.test_push
<lifeless> spiv: want to hear a fun bug
<spiv> lifeless: sure
<spiv> lifeless: so long as I don't have to fix it ;)
<lifeless> you know how we check file content graph <-> revision graph correspondence
<lifeless> we greate graphs like that with '' as the content, for directories.
<lifeless> guess what 'bzr check' and 'bzr reconcile' do not check
<spiv> They don't check directories?
<lifeless> RevisionNotPresent: Revision {('selftest-20050621060616-bb8b5b36e3c950c8', 'robertc@robertcollins.net-20050919060519-f582f62146b0b458')} not present in "<bzrlib.plugins.groupcompress.groupcompress.GroupCompressVersionedFiles object at 0x276e390>".
<lifeless> the source repo checks cleanly
<lifeless> thats the directory 'bzrlib/tests'
<lifeless> its being triggered by inserting a child of that
<spiv> Oops.
<lifeless> so, I think the child's parent pointer is wrong :P
<spiv> Yeah, using a directory's "file content" as a parent for anything does seem rather weird.
<igc> lifeless: new groupcompress in brisbane-core or it's own branch?
<lifeless> igc: its still seperate
<lifeless> spiv: well, its another dir
<lifeless> spiv: this is _very early_ commits
<lifeless> spiv: so its appropriate, its just not aligned with the graph
<lifeless> early weave bug I think
 * igc lunch
<lifeless> igc: but mutual dependencies
<igc> so lifeless, to benchmark your latest groupcompress, I need to grab the latest plugin code
<lifeless> igc: yes
<igc> lifeless: and bzr.dev or brisbane-core or doesn't matter?
<igc> I assume brisbane core is more interesting to you?
<igc> or not?
<lifeless> if you are testing bbc node compression, then you need the format in there to use gc
<lifeless> right now I'm isolating the parameters and performance for the compression layer, which is [mostly] orthogonal to bbc
<lifeless> igc: have you seen compressbench
<igc> lifeless: I know of it but I haven't tried it
<lifeless> well, I'm mainly working with that for micro and then use case tests, for the --gc-plain format, right at the moment
<lifeless> still trying to rule-out-or-in
<igc> sure
<lifeless> uhm, if you want to put the gc-plain format through usertest, that would be nice
<igc> lifeless: shall do. I have chemo Wed & Fri this week so something mindless like running benchmarks will fit in well :-)
<lifeless> :)
<lifeless> look, its legal drugs, can't complain
<igc> :-)
<spiv> Speaking of which... coffee.
 * spiv -> afk
<lifeless> spiv: and for entertainment value, this bug is in out mainline repo
<Peng_> jelmer: ping?
<sohail> hi
<sohail> I just did a bzr merge -r<foo>..<bar> /path/to/whatever
<sohail> well actually, a bunch of them
<sohail> is there a way to list what is about to be merged?
<lifeless> bzr missing
<sohail> lifeless, no I mean what I am about to commit
<sohail> I thought bzr st -v listed the relevant data but apparently not
<lifeless> the merged revisions?
<lifeless> or the file changes?
<lifeless> oh  sorry
<lifeless> you have cherry picked
<lifeless> cherry picks are special and do not record the revision
<sohail> orly?
<lifeless> they are essentially just a normal diff+patch operation
<sohail> why?
<lifeless> because we haven't implemented a non-transitive graph relationship that is scalable in the cases we know people do cherrypicks in
<lifeless> sorry if that answer went straight off into technobabble :P
<lifeless> we have plans to get this fixed, but its not at the top of anyones queue as far as I know
<sohail> so if I do bzr merge /path/to/whatever it will try to merge again?
<lifeless> yes, but if you are doing that, why were you cherrypicking in the first place :)
<sohail> well because for now I just want stuff that i know works
<sohail> and then later the rest of it
<lifeless> fair enough
<lifeless> it shouldn't cause many spurious conflicts when it does merge again
<lifeless> unless you have changed the lines further
<sohail> oki, thanks
<lifeless> igc: around?
<sohail> is it possible to say "ignore these revisions when merging for now"?
<lifeless> sohail: no, because merging acts on the whole files, and there is no copy of the files you are merging from that is missing those lines *and* has any new lines added [which might supercede those very lines you wanted to eliminate]
<igc> lifeless: ping
<lifeless> igc: I was thinking, for usertest
<sohail> I understood your other babble better than the latest one :-)
<lifeless> it would be nice to have both time-to-clone-natively and time-to-clone-from-pack-0.92, which is the only one we have today, isn't it ?
<lifeless> sohail: heh. So when we merge, you could imagine taking a series of patches and applying them.
<igc> lifeless: it depends ...
<lifeless> sohail: or, taking the file contents of the source, and the target, and a common version they both shared, then finding what changes have occured at that level
<igc> the source repo can be whatever format you like
<sohail> I see.. I think :-)
<lifeless> sohail: in the former approach you could 'skip a patch', but in the latter approach, you don't know which lines are from a given patch without doing rather more work
<igc> the test is currently "bzr branch mirror feature-branch"
<igc> for gc-plain testing right now, ....
<lifeless> sohail: and even you did, you then need to detect dependencies in later changes on the patch you are skipping
<igc> I add an extra step though as I assmue that the source isn't in that format
<lifeless> sohail: 'darcs' does something in this area, and we'd like to too, but it makes most folks minds hurt ;)
<lifeless> igc: righto; I'm saying both steps are useful data
<lifeless> igc: 'how slow to get to this format' and 'how slow to clone in the format'
<sohail> lifeless, well I'd rather just say something like: "When you are merging from this branch, never ever merge revisions a..b"
<igc> lifeless: understood
<lifeless> sohail: the way you say that today is: merge up to b (but don't commit yet), then merge -r b..a --force, and then commit
<sohail> hmm
<sohail> let me try that
<lifeless> sohail: that commits a revert of the a..b change in your branch
<lifeless> if the other branch merges from you, they will have that revert applied to them
<sohail> oh
<lifeless> remember that the point of merging is to make two branches content be combined
<sohail> so that isn't what I want either...
<lifeless> so given two branches A and B
<lifeless> in A, merge B+commit
<lifeless> then in B, merge A + commit
<lifeless> is defined as giving you the same content
<sohail> or maybe I can make a third integration branch?
<lifeless> I don't know what your scenario is sorry :P
<sohail> that's ok, you've been helpful
<lifeless> I'm happy to discuss things further if you like
<sohail> I'm ok if you're ok :-)
<lifeless> we're all ok then
<sohail> I have two branches, master & next. master is meant to be stable... The next branch got some stuff checked in that wasn't quite ready
<sohail> but I need to make the master use the latest good stuff
<sohail> I want bzr to keep track of it all for me :-)
<lifeless> fair enough
<lifeless> I use looms for that
<lifeless> but you don't need to
 * sohail is waiting for The Bazaar Book :-)
<lifeless> the key thing to know is that I cherrypick when needed, and I have a branch for each conceptual change I'm making
<sohail> yeah I think that's the thing
<lifeless> if a branch B depends on branch A
<sohail> next time I gotta make a branch for each change
<lifeless> I merge A into B
<lifeless> now, if A has bad stuff in it, but the conceptual change in B could be merged to trunk anyway
<lifeless> what I do is a cherrypick
<lifeless> -r branch:A..branch:B
<sohail> what does that mean..
<sohail> -r branch:A..branch:B
<lifeless> well
<sohail> difference between those two branches?
<lifeless> like -r x..y
<lifeless> except that x is the tip of branch A
<lifeless> and y is the tip of branch B
<lifeless> so yeah, the difference between the branches
<sohail> but how does that apply here?
<lifeless> it cherry picks the unique work in B without the stuff in A I was unhappy with
<lifeless> it may not apply to you, I was just sharing how I use bzr to track things for me
<sohail> oh I see
<sohail> this works if you have a branch per conceptual change
<lifeless> yes
<sohail> so do you have any suggestion for my situation?
<lifeless> you have two branches, master and next, next has some good stuff, and after it some bad stuff, and then some more good stuff?
<lifeless> and you want all the good stuff in master?
<sohail> yep
<sohail> and I want bzr to track this
<lifeless> ok, firstly I'd merge all the good stuff to master that is before anything bad
<lifeless> bzr merge -r last_good_before_bad; commit
<lifeless> then, I'd : bzr merge next; bzr merge -r last_bad..first_bad --force next; bzr commit -m "Pull in all ready code from next";
<lifeless> I would then go immediately to next and
<lifeless> bzr merge master; "bzr merge -r first_bad..last_bad ."; bzr commit -m "Master excluded $topic_that_is_bad but merged everything else."
<lifeless> which will merge back from master but keep the bad content (by reinstating it during the merge)
<lifeless> at this point, master has all the good stuff; next has everything including bad; the next merge from next to master will carry over the bad stuff
<lifeless> I would then rename 'next' to 'bad-feature'
<lifeless> and make a new next :)
<lifeless> spiv: any idea how to get pdb to handle BZR_PDB=1 when inside a generator?
<spiv> lifeless: Hmm, I'd expect it to Just Work, aside from the usual trick with generators which is they don't really start until the first iteration.
<lifeless> spiv: bt shows me the current call stack up to the generator only
<lifeless> spiv: I can tell you how to reproduce easily if you like
<spiv> Weird, but I'm not totally surprised either.  pdb is a bit stupid.
<spiv> Sure.
<sohail> lifeless, OK, gonna try now
<lifeless> spiv: install bzr-groupcompress to start with
<spiv> I have encountered wierdnesses with pdb + generators before.
<lifeless> sohail: cool
<lifeless> spiv: I know which is why I am mentioning
<sohail> lifeless, ok so bzr merge -r last_good -> bzr is not tracking this merge
<sohail> i.e., it is a normal diff+patch
<lifeless> sohail: it should track it.  Its '-r X..Y' that it won't track
<lifeless> sohail: '-r X' will get tracked
<spiv> Mostly it's just "output looks a bit wonky", occasionally it's "pdb crashes"...
<lifeless> spiv: this is 'interpreter exits'
<lifeless> spiv: anyhow, bzr init-repo --gc-plain /tmp/foo
<lifeless> bzr branch $bzr.dev /tmp/foo/t
<lifeless> woops
<sohail> lifeless, howcome when I do bzr st -v it just says files are modified?
<lifeless> -r 1500 on that
<sohail> oh no, there it goes
<sohail> my bad
<lifeless> spiv: then, BZR_PDB=1 bzr pull -r 1600 -d /tmp/foo/t
<lifeless> spiv: you will want to do a setup.py build_ext -i in groupcompress
<sohail> lifeless, it is warning me that I am doing a criss-cross merge
<lifeless> sohail: thats probably ok in this case, just check the diff before committing and make sure its what you want
<lifeless> spiv: how is it going
<spiv> lifeless: just started the -r 1500
<spiv> Oh, heh, I need your fix_chunked fix :)
<lifeless> you worked with mbp on the stacking stuff didn't you ?
<spiv> I worked a bit on fixing a bug well after it landed...
<spiv> (bug 291046)
<ubottu> Launchpad bug 291046 in bzr "pushing branch6/packs5 to location with default stacking policy creates broken branch" [High,Fix released] https://launchpad.net/bugs/291046
<lifeless> do you know why add_fallback_repository sets fetch_order to 'topological' ?
<lifeless> seems weird/unrelated to me
<davidstrauss> I think Bazaar developers might enjoy this: http://fourkitchens.com/blog/2009/02/03/importance-atomicity-or-why-git-staging-area-bad
<spiv> No, I don't know why either.  I share your confusion.
<davidstrauss> :-)
<lifeless> davidstrauss: heh; so I would like to add commit -i
<lifeless> I do appreciate the philosophic argument that commiting untested code is bad
<davidstrauss> lifeless: what is commit -i?
<lifeless> interactive commit, prompt you like shelve does
<davidstrauss> ah
<lifeless> but what you say 'n' do isn't committed
<lifeless> s/do/to/
<sohail> lifeless, should I try bzr merge --weave for the bzr merge next step
<lifeless> I think that we should encourage good behaviour but not punish folk that want to run with knives
<sohail> it causes less conflicts
<davidstrauss> an interactive commit would have the same philosophical issues of git staging
<lifeless> sohail: ah yes, thats probably the criss-cross
<lifeless> davidstrauss: indeed
<sohail> lifeless, ok thanks
<lifeless> davidstrauss: though some less, in that at least it can only commit things that are in front of you
<lifeless> davidstrauss: git can commit content which isn't in your tree, and wasn't in the previous tree either, if you staged half way through some operation
<lifeless> I don't want *that*
<davidstrauss> true
<lifeless> but I would like you to (for instance) exclude a debugging comment easily
<lifeless> at the moment you can do that by listing every other file
<lifeless> a -x option to exclude some files would let you exclude one file, and its a small step from there to excluding one hunk
<davidstrauss> lifeless: I'd like an interactive commit that cancels if you choose to shelve or unshelve anything. Then, you can run your tests again, re-run commit. If you don't shelve or unshelve anything, the commit goes through.
<spiv> Right.  It's not so much that the ability to do selective commits is bad; but like many tools it should be used with care.
<lifeless> davidstrauss: Would you be happy if a plugin could hook into bzr commit -i, to make that happen?
<davidstrauss> lifeless: I think interactive commit itself ought to be the plugin.
<spiv> lifeless: Hmm, how many minutes and hundreds of MB of RAM will it take for this branch to get past "Transferring:Walking content. 2320/2504"? :)
<davidstrauss> lifeless: At least initially.
<lifeless> davidstrauss: I believe it is already. I want something polished and core-quality
<davidstrauss> lifeless: I see
<lifeless> spiv: about 4-5
<spiv> Oh, there it goes.
<davidstrauss> spiv: You forgot to tell it to --run-content.
<lifeless> spiv: I blame knits
<davidstrauss> spiv: Or --jog-content
<spiv> davidstrauss: --hyperspace-warp-content would do ;)
<davidstrauss> Or --meandering-content if you're a masochist with too much time
<spiv> lifeless: 10.5 for the whole branch -r1500.
<spiv> 10.5 minutes, that is.
<davidstrauss> though that kills parallelism :-/
<lifeless> spiv: yeah
<lifeless> spiv: cloning it again is a lot faster
<lifeless> bzr branch /tmp/foo/t /tmp/faster ;P
<lifeless> 1m4 for me that is
<spiv> lifeless: hmm, I'm not sure this is pdb's fault so much as Python's...
<lifeless> spiv: I didn't blame pdb ;)
<lifeless> I asked how to get pdb to be useful here
<lifeless> here @ pedants R us
<spiv> Actually, no, I blame pdb after all...
<lifeless> cool
<lifeless> patch?
<lifeless> :)
<spiv> lifeless: http://rafb.net/p/6deAgv30.html is your traceback
<spiv> I'm still figuring out why pdb can't figure that out.
<lifeless> yeah thats what I want to see in pdb
<spiv> And that's what traceback.print_tb(sys.exc_info[2]) gives in that except block.
<spiv> (using sys.exc_traceback gives the same result)
 * davidstrauss revs up to start a multi-part blog post series on how we used Bazaar last week during the Drupal.org upgrade sprint to manage a complex set of core patches.
<spiv> Ah, I think I see why pdb gets confused.
<lifeless> davidstrauss: cool
<davidstrauss> Unfortunately, one of the conclusions is that Loom isn't ready for prime-time.
<lifeless> thats fair enough
<lifeless> I would really love feedback on any new (no bugs exist) issues
<lifeless> even conceptual ones
<davidstrauss> I'm very happy with the conceptual foundations of Loom.
<davidstrauss> I think it completely trumps Mercurial queues and StGit there.
<spiv> lifeless: pdb recursively does t.tb_next on the traceback to find out where to start pdb (because you want to be at bottom of the traceback, where the exception happened),
<spiv> lifeless: but it relies on being able to recursively walk t.tb_frame.f_back.f_back.f_back... to get back to the top
<davidstrauss> It's very important that a patch management tool integrated into a distributed VCS allow branching, pushing, pulling, etc. *with all the patches*.
<spiv> lifeless: and generators break that; f_back ends up as None
<spiv> lifeless: so pdb takes a perfectly good traceback and manages to fail to use most of it
<lifeless> davidstrauss: ah yes your bug
<davidstrauss> lifeless: I'm a little disappointed with the "record" command.
<lifeless> I haven't seen that bug before and its high on my todo list
<davidstrauss> It seems like it would be architecturally easier to natively support in-place branch switching and layer loom on top of that.
<davidstrauss> And by in-place, I mean with all branches being stored git-style.
<lifeless> davidstrauss: I don't think it would make a great deal of difference; but yes it would reduce the loom-specific code somewhat
<davidstrauss> Most of the loom issues I run into involve loom's implementation of multiple branch storage for one working tree.
<lifeless> davidstrauss: ok, well I'm be sure to read your posts if you could link them here
<davidstrauss> thanks :-)
<lifeless> userfeedback++
<davidstrauss> I love the work you guys do. It's really inspired me to care about the theoretical underpinnings of VCS.
<lifeless> spiv: so what should pdb do ?
<spiv> lifeless: http://rafb.net/p/SORZ1J60.html
<spiv> lifeless: it seems the Pdb class handles this just fine
<spiv> lifeless: it's just the pdb.post_mortem function that makes the bad assumption that f_back will always work.
<lifeless> bb:approve
<lifeless> with extra credit or a bug repo on python itself
<spiv> Specifically, bdb.Bdb.get_stack seems to cope just fine with this traceback, so long as post_mortem hasn't already neutered it.
<lifeless> spiv: though s/\<t\>\/tr/ or something
<spiv> lifeless: sure
<spiv> lifeless: "tb" is fairly idiomatic
<lifeless> sure
<lifeless> just 't' is teh short
<spiv> Yeah.
<spiv> I was cribbing furiously from pdb.py at that point, which uses f and t everywhere.
<lifeless> ugh
<lifeless> do you debug pdb to fix it
<lifeless> or just poke to get a theory?
<spiv> I inserted a "import pdb; pdb.set_trace()" near the top of the except block, and interactively poked at the traceback object while looking at the pdb source.
<spiv> lifeless: here's a snippet of my session:
<spiv> (Pdb) pp exc_info[2].tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next.tb_next
<spiv> None
<spiv> ;)
<spiv> Anyway, post_mortem() is pretty short, it basically follows the tb_next chain to the bottom, so it was a matter of finding out how pdb tries to get back to the top given the bottom.
<spiv> lifeless: hah, I see that current trunk pdb.py simply doesn't do the fast-forward in post_mortem anymore
<spiv> AFAICT it will actually leave you at the top of the stack when the prompt starts, though.
<lifeless> shrug ;P
<spiv> Hmm, and prior to that change that function had been untouched since 1992...
<lifeless> ok
<spiv> Weird, the offending code was removed in http://svn.python.org/view?rev=61312&view=rev, but the commit message is about a totally orthogonal issue.
<lifeless> so, mathias needs to backport it :)
<spiv> I was going to try submit a patch to Python, but not I'm just confused :)
<spiv> Maybe I'll submit a patch anyway, restoring the "start from the innermost frame" feature without the bug we're hitting.
<lifeless> would be nice
<spiv> Ah, no, a different commit removed those lines.
<spiv> I think maybe I want a gannotate that puts a thin red line where some revision deleted lines without adding any...
<spiv> lifeless: http://bugs.python.org/issue4150
<lifeless> spiv: that would be nice, though perhaps nicer would be a [+]
<lifeless> or a slider for time for the file
<spiv> lifeless: so, it appears to already be fixed in upstream; the patch is small and nice, I'll ask about a backport.
<lifeless> well, I'm doing yet-another-check of bzr.dev to validate this fetch issue
<lifeless> I doubt I'll get more done today :(
<spiv> lifeless: btw, if you use Python 2.6 you should already have the fixed pdb.py, I think.
<lifeless> I'm on 8.10
<lifeless> perhaps I should take the plunge
<lifeless> igc: interesting patch
<lifeless> igc: do you handle new children being added, and do you track those children thereafter?
<lifeless> and the converse
<igc> lifeless: i believe so, and files being changed to directories and vice versa :-)
<igc> lifeless: I'm looking forward to getting a TreeDelta directly from the lower layers when the split inventory stuff is closer
<igc> then log -v will be *much* better
<igc> lifeless: just to be clear, I track the *directory* and changes to it
<igc> so if I file moves out of it, it's no longer tracked when it's out of the directory
<lifeless> ok
<igc> in other words, it's more than simply logging dir/* as separate files
<lifeless> I'm not saying thats right or rong
<lifeless> but I think it should be made clear to users of the cli and api, if its not today
<lifeless> I haven't read the code yet
<igc> lifeless: shall do
<lifeless> I have some partial parsin via regex stuff I did for bzr-search, which I then shelved.
<lifeless> how are you doing your partial parsing?
<lifeless> oh, and a note that may be obvious - you can't use knit deltas at all for what you are doing
<igc> checking against file-ids and parent-ids in the inventories
<lifeless> if its not I'll walk you through that
<igc> please do
<lifeless> brb gotta pickup caffeine at the shop
<igc> np
<lifeless> so
<lifeless> to do a delta you need to know about deletes
<lifeless> and knit deltas only tell you about the fact of a delete, not the content of the delete
<lifeless> igc: ^
<igc> lifeless: I think the fact of a delete is enough
<igc> show_diff_trees() is used to show the patch if requested
<lifeless> you don't know the id that was deleted
<igc> won't changes_from() work that out given two RevisionTrees?
<lifeless> or even that a delete occured in the general case
<lifeless> igc: yes but that isn't using knit deltas
<lifeless> maybe we're talking about different things :)
<igc> lifeless: I think so. I'm generating filtered revision trees and them passing them to changes_from to calc the TreeDelta
<lifeless> igc: so you let them fully parse the inventory
<lifeless> igc: ?
<igc> that's one option (2a in my email), yes
<lifeless> you said you went 2b though
<igc> the other option is only building the InventoryEntry's we want. So we parse until we're found the fileids we care about
<lifeless> igc: using the full xml of the inventory ?
<igc> saving some time and some oject creation
<igc> yes
<lifeless> ok
<lifeless> also not using the knit deltas ;)
<igc> right
<igc> I wasn't clever enough to even consider the knit deltas :-)
<lifeless> bzr-search has a tuned function for this that does most of what you want
<lifeless> you might like to compare against it
<igc> shall do
<lifeless> it doesn't parse
<lifeless> but it gets file paths for a set of ids
<igc> I've been playing with bzr-search a bit lately but haven't dived into the code much yet
<lifeless> which is similar, it might have some ideas for you even if its not highly relevant
<igc> lifeless: I like how bzr-search uses it's own area under .bzr
<igc> I suspect bzr-revnocache ought to do the same thing
<lifeless> as a starting point, definitely;)
<igc> I suspect users will feel 100x more confident deleting a cache under .bzr/bzr-revnocache than .bzr/branch :-)
<lifeless> yah
<igc> lifeless: any reason why bzr-search shows rev-ids in the UI. I expected revnos :-)
<lifeless> bzr-revnocache doesn't exist
<lifeless> at the time of writing
<lifeless> I have some ideas about how to do it
<lifeless> but hadn't implemented
<igc> sure
<lifeless> a goal in bzr-search was to never implement things that scale badly
<lifeless> a related issue is 'is this revid in the branch'
<lifeless> until I can answer that I can't share search indices across branches
<igc> right. The functionality is sweet, the UI disappoints though. I half-expected to see the same output as bzr-log
<lifeless> well, I could, but it would be odd to get hits not in your branch
<lifeless> igc: it does hook into log
<igc> ah - ok
<igc> I was aware of the log hook for messages
<lifeless> igc: bzr log -m '\bRobert\b'
<lifeless> igc: time that with and w/o a search index
<lifeless> I would kindof like to add a search specific search syntax - let log use bzr searches native syntax
<igc> it was more that I hoped bzr-search made "log --authors 'Mr Smith|Mrs Smith'" unnecessary
<lifeless> but thats harder
<lifeless> igc: oh, I see. Well it finds both revisions and files; I think hooking into log is appropriate for showing revisions in full detail
<lifeless> igc: so I'd like 'log -s Smith' to Just Work
<lifeless> but that needs some refactoring around the query concept in log
<igc> interesting.
<lifeless> to hook in cleanly
<lifeless> not to mention adding a parameter, or whatever
<lifeless> log -m is unsatisfying in two ways at the moment
<lifeless> firstly its a regex, and bzr-search doesn't [yet] have a regex engine built in
<lifeless> so I check for the simplest form of regex I can match
<lifeless> \bfoo\b == ('foo',) as a search term inside bzr search
<lifeless> and anything I cant handle, I pass through
<igc> I saw that bit of the bzr-search code
<lifeless> I could turn -m 'foo' into '\bfoo\b', in regex terms
<lifeless> but that isn't drop-in for users
<lifeless> I like drop-in
<igc> what's the second issue?
<lifeless> the standard ui only searches the message
<lifeless> so bzr-search has to search more, then filter back the results
<lifeless> its a bit ugly
<sabdfl> lifeless: how is your current work landing in brisbane-core?
<jelmer> Peng, pong
<jelmer> Peng_, pong
<sabdfl> i haven't seen any movement in brisbane-core since jon in the first week of Jan, other than bzr.dev merges
<sabdfl> wondering if i'm missing the goodness
<lifeless> sabdfl: I'm hammering on compression logic at the moment
<sabdfl> what's the best way to keep up?
<lifeless> sabdfl: which is why its not showing up in brisbane core; I've been trying to be sure we know what makes git fast/us slow at text extraction, to decide what approach we take to fix the delta compression [and we have to fix it to use brisbane core otherwise its bigger rather than smaller]
<lifeless> at the moment, because I'm not making changes to brisbane-core, there is my compressbench benchmarker
<sabdfl> ok
<lifeless> and groupcompress had some stuff land in it today, which takes it to 5 times faster than knits for decompression, on average
<lifeless> for the use case of examine-all-history
<lifeless> I'm sorry, I have to head off now, just about 6 and stuff happening :)
<lifeless> I'll drop a mail to you about tracking what we're doing, and what we're doing tomorrow
 * lifeless is gone
<vila> hi all
<Peng_> jelmer: Hi. I just wanted to ask you one thing: You marked bug 322856 as fixed, but I still get it. Do I have to delete svn-cache or anything?
<ubottu> Launchpad bug 322856 in bzr-svn "svn-v4 revids are used for tags on an svn-v3 branch" [Medium,Fix released] https://launchpad.net/bugs/322856
<jelmer> Peng_, bzr-svn 0.5 revno 2507 ?
<Peng_> jelmer: Yep.
<jelmer> Peng_, Which tags do not work ?
<Peng_> jelmer: .bzr/branch/tags is exactly the same as it was beforehand.
<Peng_> jelmer: Ehh, what's the right way to test it? i just renamed .bzr/branch/tags and tried "pull".
<jelmer> Peng_: Yeah, that should work
<jelmer> Peng_: So lots of question marks?
<jelmer> I've confirmed it working here with lighttpd 1.4.x and trunk
<Peng_> jelmer: Hmm, I just tried it on 1.4.x and it only produced two svn-v4 tags, which means it's almost perfect. I had tried it on 1.3.x earlier.
<jelmer> Peng_, 1.3.x will indeed give lots of "?" marks since I suspect most of the revisions that are tagged are not in its ancestry
<Peng_> ...Good point.
<Peng_> OK, my mistake. (Especially since 1.3.x uses all svn-v4 IDs anyway.)
<Peng_> 1.4.x still created a couple bad tags, though, didn't it?
<jelmer> just two question marks here
<jelmer> and those are for revisions not in the ancestry
<Peng_> OK.
<Peng_> Sorry for bothering you, then.
<Peng_> And thanks for fixing the bug.
<jelmer> np
<sohail> more bzr-hole-digging... I did rm -rf /path/to/branch but now when I try to switch an checkout bound to branch to master, it says: "unable to connect to target of bound branch /path/to/branch: not a branch: /path/to/branch"
<davidstrauss> sohail: are you running unbind?
<sohail> davidstrauss, yeah I ran unbind after I saw that message
<sohail> then it said: "Can't switch on branch only checkout"
<davidstrauss> sohail: unbind does not talk to the parent branch
<davidstrauss> sohail: branch-only checkout?
<sohail> argh
<sohail> this is so confusing
<davidstrauss> sohail: what did you run to create the checkout?
<sohail> davidstrauss, I'm pretty sure it was a clone actually
<davidstrauss> sohail: then unbind should say that you can't unbind what is already a standalone branch
<sohail> davidstrauss, it didn't say that
<davidstrauss> sohail: what do you get from bzr info?
<ronny> moin
<sohail> davidstrauss, oh I decided to dig myself into a deeper hole and rm -rf
<sohail> so now I don't know
<sohail> ronny, moin
<ronny> jelmer: can  you take a look at the commit method line 125 in http://paste.pocoo.org/show/102549
<davidstrauss> sohail: i'm talking about the alleged checkout
<sohail> davidstrauss, yeah I know it's gone
<ronny> jelmer: it complains about added paths in the repo not being versioned
<davidstrauss> sohail: what do you have left?
<sohail> davidstrauss, nothing
<sohail> I'm just doing a fresh checkout now
<davidstrauss> sohail: oh, yeah, bzr can't help if you delete everything
<sohail> nope
<sohail> oh well :-)
<sohail> davidstrauss, can I still work offline with a checkout?
<davidstrauss> sohail: sort of, but i don't recommend it
<sohail> argh
<sohail> so how do you do this when offline: http://bazaar-vcs.org/Tutorials/CentralizedWorkflow
 * igc dinner
<sohail> ah I see
<davidstrauss> sohail: you sort of can't
<sohail> bzr commit --local
<sohail> orly?
<davidstrauss> sohail: be very wary of --local
<sohail> http://bazaar-vcs.org/CheckoutTutorial
<sohail> why?
<davidstrauss> sohail: https://bugs.launchpad.net/bzr/+bug/113809
<ubottu> Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed]
<sohail> wonderful
<sohail> well it is as important to know the limitations of your tools as it is to know your own limitations :-)
<ronny> hmm
<ronny> i wish i did know whats wrong there
<ronny> jelmer: it seems like some methods require me to use the way of abspath -> wt.relpath to get working results
<ronny> hmm
<ronny> jelmer: WorkingTree.rename_one seems nasty, imho too much semantics
<jelmer> ronny: hi
<ronny> ok
<ronny> wth a bit luck all bzr tests will pass now
<ronny> yay
<ronny> native bzr support done
<ronny> (at least for workdirs)
<jelmer> ronny: w00t :-)
<ronny> hmm
<jelmer> hmm?
<ronny> i still have to deal with branch-management now
<jelmer> I'll be away again in a bit, my class is starting
<jelmer> ronny: but feel free to talk to me, I'll reply when I get back
<ronny> k
<ronny> i have no classes at, exams time
<jelmer> ronny: ah, that explains why you have so much time to work on anyvc ;-)
<nua> if I run a smartserver over ssh and someone pushes/pulls/commits/uncommits will the post_push() etc hooks run on the server machine? If not, can I find out what the action was that caused a post_change_branch_tip() hook to fire?
<nua> ...obviously the plugin would be installed on the server, not the client machine
<mwhudson> nua: the hooks will run on the server side, yes
<nua> mwhudson: thanks, I'll get writing some code then :)
<nua> mwhudson: I can't seem to get post_commit to work on the server, currently only have post_change_tip_working
<Peng_> Do pushes count as "commits" for post_commit?
<Peng_> jelmer: ping?
<jelmer> Peng_, pong?
<Peng_> jelmer: Hi. Quick question: is it safe to do "bzr log" on an svn branch at the same time as a "bzr branch" is importing it? Can svn-cache handle concurrent access and all?
<jelmer> Peng_, You might run into bug 185200
<ubottu> Launchpad bug 185200 in bzr-svn ""database is locked" bzr internal error" [Low,Triaged] https://launchpad.net/bugs/185200
<jelmer> although it shouldn't cause corruption or anything
<Peng_> jelmer: If it happens at the wrong time, could that kill the "bzr branch"?
<jelmer> peng_: yes
<Peng_> Eh. That would be bad.
<Peng_> Oh, good. I risked it anyway and nothing bad happened.
<Peng_> jelmer: Thanks. :)
 * Peng_ wonders why the progress bar says revision 1154 is taking so long, when it should be tiny.
<jelmer> no idea
<Peng_> I _do_ have several really large revisions, but it shouldn't be that one.
<vila> mwhudson: ping
<UdontKnow> Hi
<AfC> That's a good nick.
<UdontKnow> AfC: and an old one
<gorgapor> #join bzr-dev
<Peng_> There's a #bzr-dev?
<gorgapor> lol, no actually
<gorgapor> sorry for the typo
<gorgapor> but i do have a development question: with bzrlib, how do i get the root folder of the current branch?
<Peng_> I don't know. You mean like the "bzr root" command? If so, you could check how it's implemented.
<gorgapor> hey cool, i didn't know about that command
<gorgapor> yeah i'll check that
<gorgapor> thanks
<guilhembi> gorgapor: hi! you could do this:
<guilhembi>         self.wt = WorkingTree.open_containing(u'.')[0]
<guilhembi> then self.wt.basedir is the root dir.
<guilhembi> (at least it used to be true a few months ago, haven't checked since).
<gorgapor> guilhembi: thanks. actually though, i came up with a very similar solution from diving into the bzrlib source
<gorgapor> but you suggesting the same thing gives me much more confidence that i'm doing it the right way
<guilhembi> :)
<igc> night all
<nua> quick q: just looking at the bzrlib api docs, what is branch stacking?
<Peng_> nua: Errm. When you do "bzr branch --stacked", bzr does not download and save the entire history.
<Lo-lan-do> nua: As far as I understood it, it's just saying that part of the history of a branch is stored remotely.
<Peng_> That works too.
<nua> Ok, I can safely ignore that for now then :)
<nua> If I'm adding something to the post_change_branch_tip hook on a smart server, I get passed branch as an arg, how do I get the path that branch is currently stored at on the server? get_bound_location()?
<ronny> jelmer: ping?
<jelmer> ronny, pong
<ronny> jelmer: is there any reason why some apis require me to call WorkingTree.relpath on absolute paths before they work?
<ronny> and does it change for newer bzr versions
<ronny> (im currently on 1.6)
<ronny> cause of ubuntu
<jelmer> ronny, generally, relative paths should always be save (since that's what the Tree API uses)
<jelmer> ronny, I think my earlier recommendation to just specify absolute paths is incorrect
<jelmer> ronny, and that using relative paths everywhere would be the sa{f,n}est way to go
<ronny> jelmer: my cwd is always different from the tree path, and it takes all relative paths relative to the cwd
<jelmer> ronny, you should be able to use wt.relpath(wt.abspath(path))
<jelmer> ronny, not really neat, but should do the job..
<ronny> not exactly nice
<ronny> well, its what i do atm
<kfogel> I just did 'bzr tag release-0.1.82' in a branch of the bkrpr project that otherwise was totally up-to-date and had no uncommitted changes, then did 'bzr push lp:bkrpr'.
<kfogel> But nothing got pushed, and when I later did 'bzr pull' in my mirror of trunk, nothing came down.
<kfogel> The help for 'bzr tag' says that tags are pushed/pulled between branches just like revisions, but that didn't seem to happen.
<kfogel> Am I missing something?
<fullermd> You sure the tag didn't come down?
<kfogel> By the way, 'bzr status' immediately after I made the tag also showed no changs.
<kfogel> fullermd: well, let me see...
<kfogel> fullermd: holy cow
<kfogel> fullermd: well, you're right
<kfogel> it came down
<kfogel> it's just that neither the push nor the pull indicated that *anything* had been transmitted.
 * fullermd nods.
<kfogel> They looked exactly as if I had pushed or pulled when there are no changes.
<fullermd> That's one of the long-standing quirks of tags.
<Lo-lan-do> Is there a way to tell bzr not to look for a smart server when accessing a branch through HTTP?
<Lo-lan-do> I'd like to get rid of "File does not exist: /srv/bzr/fusionforge/svn-Branch_4_7-ro/.bzr/smart" in the Apache logs.
<sanctus> Hi, can I hide my commit made in one of my branch before pushing it to the main repository? (distribute)
<Tak> jelmer: ping md-bzr
<jelmer> Tak, hi
<Tak> hello
<Tak> so, I'm playing with bzr shell as an alternative interface
<Tak> it's a bit slower for "regular" operations like checking file status
<jelmer> Tak: If you're looking at alternative interfaces, xmloutput should be the primary choice I think
<Tak> is there a minimum version for that?
<jelmer> it's a plugin, I'm not sure what bzr version it requires
<jelmer> Tak, I thought you were importing bzrlib using IronPython - does that not work?
<Tak> no, ironpython only works with ironpython :-/
<Tak> using bzrlib directly would be ideal
<Tak> hmm, xmloutput only implements a subset of the commandset I'm using
<jelmer> there is also another C#-based wrapper of bzrlib around, ahve you looked at that?
<jelmer> I think it's in the bzr-visualstudio project, not sure what state it's in
<Tak> hmm, I think you pointed me to that before
<Tak> if it's the one I recall, I couldn't get it to build
<enigma42> subvertpy question...
<enigma42> I'm getting errors
<mwhudson> darn it vila
<mwhudson> 's gone
<enigma42> bzr: ERROR: subvertpy.SubversionException: ("Commit blocked by start-commit hook (exit code 1) with output:\nProject 'sequoia' requires that committing clients be mergeinfo-aware,\nbut yours is not.  Consider upgrading to a client that is using Subversion 1.5\n(or newer) libraries.", 165001)
<enigma42> I'm thinking the subvertpy client isn't "mergeinfo" aware?
<jelmer> hi enigma42
<enigma42> jelmer: Hi. :-)
<Peng_> jelmer: If I discover some odd traceback in bzr-svn, should I ask you here or go straight to filing a bug?
<jelmer> enigma42: hmm
<Peng_> jelmer: BTW, congrats on releasing 0.5.0. :)
<jelmer> enigma42, this is not a standard svn server, is it?
<Tak> "pybaz - python bindings for the bazaar revision control system"
 * Tak blink
<Peng_> Tak: Presumably the old "baz" project, not the current "bzr" project.
<jelmer> Peng_, thanks!
<jelmer> enigma42, Is this against a project you've used bzr-svn with before?
<enigma42> jelmer: It's a collabnet server.
<jelmer> enigma42, is subvertpy linked against svn 1.5 on your machine?
<enigma42> jelmer: Yeah, I've used this project before.
<enigma42> jelmer: The difference is that collabnet just upgrade us to SVN 1.5 on the server recently.
<jelmer> enigma42, it seems like a change on their end, could that be?
<jelmer> enigma42, it's not just svn 1.5 on the server, it's some custom commit hook they seem to have
<enigma42> Oh...I see...
<jelmer> enigma42, I would be curious as to what they seem to use as the metric to determine whether a client is merge-info aware
<enigma42> Yeah....I'll try to track that down.
<enigma42> jelmer: Oh...how can I tell which svn lib subvertpy is linked against?
<jelmer> ldd on _ra.so
<enigma42> jelmer: OK. Thanks.
<enigma42> jelmer: subvertpy is definitely linked against svn 1.5...so like you said...it seems like a strange hook.
<Peng_> jelmer: Well, um, I got an assertion in RevisionMetadata._set_direct_lhs_parent_revmeta while pulling a branch with bzr-svn 0.5 (latest revision) that I used to use with 0.4. http://paste.pocoo.org/show/qHxKKSCAS4i2Xv3Z0VaY/
<luke-jr> Does Bazaar support write-once repositories? âº
<luke-jr> for example, a CD-R
<luke-jr> (with a tar filesystem, not iso)
<mwhudson> packs are written in big chunks
<jelmer> Peng_, please file a bug
<Peng_> jelmer: Alrighty.
<mwhudson> but i guess it will be unhappy that it can't delete old ones
<Peng_> Did I file another bug about that repo in the past?
<jelmer> Peng_, nope
<Peng_> Bazaar would probably also be unhappy if it couldn't take out locks...
<jelmer> peng_: ah, oops
<Peng_> jelmer: ?
<jelmer> peng_: it's barfing on the fact that that file is named "tags"
<Peng_> jelmer: Oh. Well, um, I just filed a bug anyway. Oops?
<jelmer> Peng_, Thanks
<jelmer> Peng_, This way we can track it, that's useful.
<Peng_> Okay.
<Peng_> (Bug 324970, if you haven't checked your bugmail yet.)
<ubottu> Launchpad bug 324970 in bzr-svn "RevisionMetadata._set_direct_lhs_parent_revmeta asserts while pulling ack's trunk" [Undecided,New] https://launchpad.net/bugs/324970
<speakman> hi folks, how is rebase supposed to work? i tried bzr rebase -r 10..11 and it just tracebacked.
<jelmer> speakman, which version of rebase?
<jelmer> Peng_, ROFL
<jelmer> Peng_, I was checking for path_elements[i-1] == "tags" somewhere
<jelmer> Peng_, of course when parsing "trunk/tags", that ends up being [-1]
<jelmer> speakman: generally though, you shouldn't need to specify a range of revisions to rebase
<Peng_> jelmer: So it's easy to fix? :)
<speakman> BBBBBBbzr: ERROR: No common revision, please specify --revision
<speakman> except for those "BBBB" :D
<speakman> rebase 0.3
<jelmer> speakman, what are you trying to accomplish exactly? Because I think rebase might not be the right tool for the job
<jelmer> you can't combine two unrelated branches with it, since they will have different file ids
<jelmer> Peng_, yup
<speakman> I'm not sure what rebase actually means, but I was thinking it could "flatten" all merges in the history log
<Peng_> jelmer: Great. :)
<jelmer> speakman: not existing merges though, it's more of an alternative to merge than a way to change merges
<jelmer> speakman, of course, you should be able to re-do all your merges using rebase
<speakman> boh, i see
<speakman> oh*
<speakman> jelmer: can I redo merges now, or what do you mean?
<speakman> hm, now bzr (in another branch) claims that it's locked. How do one remove locks?
<jelmer> speakman, you'll basically have to uncommit everything in your branch and re-do the merges, but running "bzr rebase" where you had previously run "bzr merge""
<jelmer> speakman, "bzr break-lock"
<jelmer> speakman, what's the fundamental problem you're trying to solve?
<jelmer> (Why do you need to flatten your merges?)
<speakman> most curios actually, but if there's a way to put merges on top of history instead of making a unnecessary merge post it's pretty interesting
<speakman> I've now "uncommit" so it says "pending merges:" at "bzr status", could I do rebase at this stage?
<jelmer> Peng_, pushed
<jelmer> speakman, yes, you can now run e.g. "bzr rebase --pending-merges"
<jelmer> for --pending-merges you need 0.4 though I think
<jelmer> speakman: rebasing is generally considered bad though, because it changes the identity of rebased revisions so you should only ever use rebase on revisions that aren'd pushed yet and in use by other people.
<Tak> hmm, it was pretty straightforward to move to xmloutput for the supported commands
<jelmer> tak: cool
<speakman> bzr: ERROR: no such option: --pending-merges
<jelmer> tak: now if only I could get it to compile.. :-(
<jelmer> speakman, you need bzr-rebase >= 0.4
<speakman> oh, is there a PPA for that?
<jelmer> no, but you should be able to run something like "bzr branch lp:bzr-rebase ~/.bazaar/plugins/rebase" to install it
<mwhudson> bzr will never block on taking a read lock, will it?
<Tak> jelmer: what's the issue you're having?
<jelmer> Tak, monodevelop version too old
<sanctus> can I hide my commit made in one of my branch before pushing it to the main repository? (distribute)
<Tak> ohh...yeah, and md-trunk requires mono >= 2.0 which isn't in any distro but opensuse yet
<speakman> jelmer: thanks, now rebase actually works too ;)
<dobey> hola
<dobey> bzr can have commit hooks that run at the commit stage, rather than the push stage, no?
<jelmer> dobey, yes
<dobey> is that documented on the wiki?
<jelmer> I'd doubt it, there isn't much API documentation on the wiki
<jelmer> dobey: the regular python API tools should be able to help you
<dobey> ah. how would i set up a pre-commit hook? write a plug-in?
<jelmer> dobey, yep
<dobey> ok
<dobey> well that's 43433232x better than what git does :)
<dobey> though i was hoping i could just drop a script somewhere, and anyone that pulls the branch will get that hook run when they do a commit
<dobey> which i suppose i could sort of implement with a plug-in as well anyway
<jelmer> dobey, that seems like a bad idea to me for security reasons
<dobey> why?
<jelmer> I wouldn't want code from $RANDOM_BRANCH I fetched to automatically run
<dobey> well, people already do that anyway
<dobey> ./configure && make will do that :)
<jelmer> dobey: that's intentional decision by the user; it's not a side-effect of running "bzr <subcommand>"
<dobey> jelmer: but you can stick arbitrary code in configure, or a makefile, or have it run a built binary, and very few people if any actually read every line of code before building/running a project
<dobey> so i don't know that i would call it a security issue really
<LarstiQ> dobey: I know I do.
<LarstiQ> dobey: at least with confingure you are aware there is execution going on.
<dobey> interestingly enough, we just had a similar conversation in #gnome-hackers, because i was wondering if git would let me do stuff
<dobey> LarstiQ: but you don't necessarily know what
<dobey> you just assume it's configuring to build
<jelmer> dobey, you can have a look before you run configure
<jelmer> dobey, hooks can even trigger e.g. during fetch
<LarstiQ> dobey: you have a lead to go find out if you want to, and you can do so before running anyting.
<dobey> they could, but i only want these to run before commit succeeds
<jelmer> dobey, of course, nothing stops anybody from creating a "bzr-insecure" plugin that provides this sort of functionality :-)
<LarstiQ> dobey: unless hooks prompt everyhere, without being able to override that from the hooks, you have no such protection.
<dobey> LarstiQ: you could too if the hooks were in the branch
<LarstiQ> dobey: hmja
<dobey> bah, if you don't trust the branch your pulling, don't pull it!
<dobey> i doubt you've read every line of code that's currently running on your machine :)
<LarstiQ> dobey: if you were to have a go at a bzr-insecure plugin, I'd start by printing out a summary of what hooks are 'hooked'
<LarstiQ> dobey: I've delegated that to the Debian developers, whom I trust ;P
<dobey> LarstiQ: by default it probably wouldn't be anything
<LarstiQ> dobey: that way you might have a better chance of convincing people who don't share your opinion that the risk is mitigated.
<dobey> of course the things i want to do this with are currently in git or svn (and about to be moved to git :-/), so making a bzr plug-in wouldn't really help me all that much
<speakman> is there any reason there's not an "--update-working-tree" option in "push"? :)
<dobey> but i wanted to compare, since git doesn't do it at all
<jelmer> speakman, at some point the smart server will hopefully update the working tree automatically
<jelmer> speakman, it's not feasible over e.g. sftp or ftp
<speakman> how come?
<speakman> aka why not?
<rexbron> james_w: Did you get a chance to look at my reply to your review of bd.profiles?
<jelmer> speakman: you have to retrieve / re-upload every single file
<speakman> using (s)ftp to send the files directly from the current working tree?
<jelmer> speakman, you can't just upload, you have to make sure the remote hasn't changed
<speakman> hm what about requiring --overwrite ? :)
<jelmer> speakman, --overwrite is about overwriting the branch, not about overwriting files in the working tree
<jelmer> speakman, there is a plugin that can ssh into the remote server and run "bzr up" for you
<speakman> I'm aware of that plugin, but would be builtin imo
<speakman> when supported in smart server; will it then work with ssh+bzr which I believe runs the same code?
<speakman> (at the remote place)
<jelmer> speakman, it would do something similar, but inside of bzr and wouldn't require any additional connections
<speakman> But I will not be required to have an "bzr serve" runnint 24/7 to be able to update remote tree?
<speakman> as long as bzr is actually running on the remote side, there should be any differences right?
<jelmer> speakman, bzr serve isn't used by bzr+ssh
<jelmer> well, not as a daemon, anyway
<speakman> but if smart serve is able to update remote working tree, why should bzr+ssh ? :)
<jelmer> speakman: bzr+ssh is using the smart server
<jelmer> speakman, it basically runs "ssh <host> bzr server --inetd"
<speakman> hm? 20:25 < jelmer> speakman, bzr serve isn't used by bzr+ssh
<jelmer> speakman, <jelmer> well, not as a daemon, anyway
<speakman> oh, missed that :D :D
<speakman> how far away is that support? is there something one could support?
<jelmer> for updating the workingtree from the smart server?
<jelmer> I think the main thing that needs to be done is adding a verb in the smart server protocol for it
<jelmer> don't think anybody is planning on working on it though
<speakman> how can one get engage with bzr?
<LarstiQ> jelmer: did I already congratulate you with getting 0.5 released? If not, bij deze :)
<speakman> 0.5?
<jelmer> LarstiQ, thanks!
<jelmer> speakman, see http://bazaar-vcs.org/BzrDevelopment for hints about development
<jelmer> you can also always ask here of course
<jelmer> speakman, bzr-svn 0.5.0
<LarstiQ> it does seem like that page is a bit out of date
<LarstiQ> http://bazaar-vcs.org/BzrGivingBack might also have some bits
<speakman> bzrtools in the PPA is lagging behind and currently stops bzr for being upgraded
<Lo-lan-do> What is this PPA everyone complains about?
<speakman> deb http://ppa.launchpad.net/bzr/ubuntu intrepid main
<Lo-lan-do> What's it supposed to mean?
<Lo-lan-do> (Also, why don't you just grab the packages from experimental?)
<jelmer> Lo-lan-do, it's the ubuntu equivalent of private repositories
<LarstiQ> Lo-lan-do: Personal Package Archive
<LarstiQ> jelmer: any idea what the policy is, would I be allowed to upload bzrtools to the PPA?
<jelmer> LarstiQ, yes, you only have to be in ~bzr
<Lo-lan-do> So any Launchpad user can have their archive hosted on Launchpad?
<jelmer> Lo-lan-do, yep
<jelmer> unfortunately uploading for multiple versions of Ubuntu is a pain
<Lo-lan-do> I'll bet many people use these PPAs too.
<Lo-lan-do> Sounds like an excellent way to get packages of dubious origins and quality on one's system.
<jelmer> Lo-lan-do, a lot of them are just used for testing the packages
<jelmer> Lo-lan-do, since you upload a source package, and it builds in a chroot
<jelmer> well, in some sort of jail (xen?)
<lifeless> moin moin
<LarstiQ> Lo-lan-do: trusting PPAs is of course up to the user/sysadmin.
<LarstiQ> hey lifeless
<Lo-lan-do> I don't doubt it, I just fear that many users will trust the URL ("oh, it has launchpad in it, must be supported by Canonical in some way") and install stuff from there with no second thoughts.
<maxb> Well, apt will do the usual "key not trusted" warings
<maxb> *warnings
<Lo-lan-do> I'm still amazed at the amount of trust people put in *random* URLs, so I can only be frightened by such a thing.
<maxb> Well, there's little that can be done to help people who don't check anything at all :-/
<jelmer> Lo-lan-do, they have different keys they're signed with
<Lo-lan-do> Sure, but giving them the appearance of being "official" probably doesn't help.
<maxb> Uploading for multiple versions would probably be reasonably scriptable, using "dch"
<Lo-lan-do> (And "invalid key" mostly means not much more than "one extra click")
<Lo-lan-do> But pardon me for rambling at users, we're here to celebrate bzr-svn 0.5 :-)
<jelmer> Lo-lan-do: otoh, there's lots of people installing *single* .deb's they download from the net
<jelmer> Lo-lan-do, stuff in PPA's will at least build from source cleanly
<Lo-lan-do> jelmer: Do you know of a (possible) bug where bzr-svn would output "bzr: ERROR: No such file" after a merge done in SVN?
<jelmer> Lo-lan-do, nope
<jelmer> Lo-lan-do, what does ~/.bzr.log say?
<Lo-lan-do> jelmer: http://pastebin.com/d47efe066
<Lo-lan-do> But I'm not sure it still happens with 0.5.0 since I upgraded later than that log, and I also tried to work around the bug based on a hypothesis of mine.
<jelmer> Lo-lan-do, yeah, some similar issues to this were fixed
<Lo-lan-do> As far as I can tell, the problem appeared when pulling from a branch that's bound to (and bzr update'd from) an SVN trunk after a merge.
<Lo-lan-do> Data flow: on my local machine, bugfix in branch_foo (bound to SVN /branches/foo), cd ../trunk (bound to SVN trunk), bzr merge ../foo, bzr commit.
<Lo-lan-do> On the remote box, bzr update in svn-gw/trunk (bound to SVN trunk), cd ../branch-foo, bzr pull ../trunk.
<Lo-lan-do> Anyway, I added a gateway for the SVN branch too, and it seems to work now.
<LarstiQ> speakman: ok, ppa is a liiitle more involved to set up.
<maxb> only just barely. sources.list line, pgp key, done :-)
<speakman> hm?
<LarstiQ> maxb: I meant building bzrtools 1.11 for the ppa
<LarstiQ> maxb: doc/developers/ppa.txt if you're interested
<maxb> hm? I built it locally just by grabbing the Debian experimental source
<Lo-lan-do> jelmer, Jc2k: Can the bzr-*-pack scripts from bzr-git be run from ~/.bazaar/plugins/git, or do they need to be installed somehow?
<jelmer> Lo-lan-do, they would have to be installed (as /usr/bin/git-*pack actually)
<jelmer> Lo-lan-do, they're for the server side with ssh though
<Lo-lan-do> I gathered that much, but apparently symlinking them into ~/bin isn't enough and I get "ImportError: No module named git.server"
<Jc2k> Lo-lan-do: that may well just be typos - i cant remember how thoroughly they were tested..
<Jc2k> hmm
<Lo-lan-do> Jc2k: I can't seem to get it working after an installation --prefix=$HOME, either.
<vila> mwhudson: ping
<mwhudson> vila: hi!
<vila> great, I wasn't sure you was already awake :-)
<mwhudson> i've actually been awake for 4 hours, but that's kinda unusual :)
<vila> wow, is it 08:04 your time ?
<mwhudson> vila: 10:04
<mwhudson> vila: we're utc+13
<LarstiQ> lifeless: you're listed as maintainer in ~bzr/bzrtools/packaging-dapper, but not in the other distro packaging branches
<lifeless> odd
<LarstiQ> lifeless: I optimistically decided to build bzrtools 1.11 for the ppa
<LarstiQ> lifeless: are these packaging branches supposed to stay entirely seperate?
<LarstiQ> lifeless: and should the Debian uploaders really be in there still?
<lifeless> LarstiQ: I'm not entirely sure
<LarstiQ> lifeless: should I bother someone else? :)
<lifeless> LarstiQ: its documented in the hacking guide I believe
<LarstiQ> lifeless: I'm trying to follow doc/developers/ppa.txt
<lifeless> LarstiQ: ah, and its incomplete?
<lifeless> LarstiQ: I'd ask the list
<lifeless> poolie isn't online, nor is hjam
<LarstiQ> will do
<MattCampbell> kfogel: I just learned that you're working for Canonical.  Given that you were one of the Subversion project leaders, I'm curious about what you think of bzr now that you've been working with it for a little while.  Have you written your opinion on bzr somewhere, e.g. a blog post?
<kfogel> MattCampbell: no, haven't written it up yet, and am actually avoiding that for now.  I'm still very green with bzr.
<MattCampbell> I know some other SVN developers have expressed concerns about DVCSes, e.g. that a DVCS makes it too easy to fork a project.
<kfogel> MattCampbell: I don't think that's ever been the concern.  I've heard concerns that dvcs makes it too easy to develop in isolation, which is slightly different.
<MattCampbell> kfogel: Oops, yeah, you're right.
<kfogel> MattCampbell: I haven't experienced that in bzr so far, I have to say.
<kfogel> But then, I reflexively want to publish my changes, so I wouldn't wait for the tool to encourage it.
<MattCampbell> I'm green with bzr too, so I may be wrong, but I think bzr encourages non-core developers to publish changes in a way that makes them easy to merge.
<MattCampbell> especially when combined with Launchpad.
<thumper> abentley: unshelve is leaving UserWarning: ProgressTask(0/3, msg='Merge phase') is not the top progress task ProgressTask(None/None, msg='') type messages
<abentley> thumper: I was not involved in the progress bar changes.
<thumper> abentley: ok
<fullermd> There's a bug about it.
<fullermd> bug 321750
<ubottu> Launchpad bug 321750 in bzr "unshelve emits "UserWarning: ProgressTask(0/3, msg='Merge phase') is not the top progress task ProgressTask(None/None, msg='')"" [Undecided,New] https://launchpad.net/bugs/321750
<igc> morning
<poolie> hello igc!
 * lifeless kicks off a uncapped compressbench run on bzr.dev
<jml> poolie: hi
<jml> poolie: did we ever get that lp-open patch landed?
<lifeless> mmm busy machine
<lifeless>  load average: 9.12, 8.39, 5.12
<poolie> jml: i did not
<poolie> nagging will get you everywhere :)
<poolie> lifeless: i think you should go ahead and send that mail about brisbane-core
<poolie> but it would be good to add some kind of indicative number
<poolie> with caveats if needed
<lifeless> poolie: I thought you thought it was at the wrong level ?
<poolie> it's still worth sending
<poolie> rather than waiting to make something else
<lifeless> poolie: pst'd you
#bzr 2009-02-04
<keithy> hi
<keithy> I just used the mac os x installer and it hosed by bazaar installation
<keithy> which bzr -> /usr/local/bin/bzr
<keithy> ok nevermind
<keithy> new shell solved it
<mwhudson> igc: did you think about using btrees for revgraphcache?
<igc> mwhudson: jam has told me I should but I'm yet to do that
<mwhudson> igc: ok, if jam thinks it's a good idea, it probably is :)
<mwhudson> igc: it seems i'm going to be working on loggerhead some more, and i want to use revnocache, so
<mwhudson> igc: need help with anything?
<mwhudson> igc: and i find the names confusing; is revgraphcache the way of the future?
<igc> mwhudson: I would *love* some help with revnocache
<igc> there's a lot that can be done there and a small amount of it may make it into the core in the future
<igc> mwhudson: I'll whip up a TODO file and commit that so you can see the priorities as I see them
<lifeless> who here has read the groupcompress stuff enough to grok the design
<mwhudson> igc: thanks
<lifeless> 3.3G corpus makes my laptop cry
<mwhudson> igc: TODO as i see it: incremental caching updating + use btrees
<mwhudson> igc: not sure there's much else tbh
<santagada> lifeless: is bzr one of the projects that will be able to use snakebite?
<keithy> hmm on windows where does bazaar ssh keep its config files?
<lifeless> santagada: snakebite ?
<keithy> I want to put some ssh keys in there
<keithy> hello lifeless
<lifeless> mwhudson: incremental writes for incremental updates
<santagada> lifeless: www.snakebite.org
<keithy> I just updated to 1.11
<lifeless> hi keithy, cool
<santagada> lifeless: to sum it up they have one machine with 48gb of ram
<santagada> :)
<mwhudson> lifeless: ah yes, btrees are write once?
<lifeless> mwhudson: yes
<mwhudson> that's something of a pain
<lifeless> mwhudson: not really
<mwhudson> could always abuse the heck out of sqlite again...
<mwhudson> lifeless: for this application it is, i think?
<lifeless> mwhudson: you can build on top of it; I have a plan!
<mwhudson> i mean, it's less important than having to read the whole lot of it, for sure
<mwhudson> lifeless: ah!
<mwhudson> lifeless: tell me more
<lifeless> mwhudson: and its important that they are write once, because our fs layer does not have updatable files per se
<lifeless> mwhudson: due to sftp and ftp
<mwhudson> lifeless: well yes, i don't care about bazaar's needs here
<lifeless> mwhudson: in the long term you do, because we need an answer in bzr itself, and if its different to what you do, its waste
<lifeless> mwhudson: also write once has nice cache characteristics, and when you look at eq sqlite internals its essentially writing once at the page layer
<lifeless> mwhudson: anyhow, take a series of btrees
<lifeless> query new->old
<lifeless> take first hit for a value
<lifeless> write a special value for deletes
<lifeless> and as the length expands and hits on old trees decrease, repack
<mwhudson> i guess you could do pack repo-like reshuffling too
<mwhudson> right
<keithy> on windows where does bazaar ssh keep its config files?
<mwhudson> is the logic for this for pack repos extractable, do you think?
<lifeless> keithy: I'm not sure, I think it depends on your ssh client
<lifeless> keithy: its something bzr depends on but doesn't provide itself
<sohail> hi, I have a shared repository and when I do bzr branch it is taking forever (> 2-3 minutes).. is there any way to figure out what is wrong?
<lifeless> sohail: you're branching within the repository?
<sohail> lifeless, I am doing bzr branch ~/code/bzr/master ~/bzr/code/bugfix
<lifeless> sohail: so from the repository, to outside?
<lifeless> or did you mistype one of those urls' ?
<sohail> lifeless, well it seems that ~/bzr/code is the repository
<sohail> so seems to be within...
<sohail> bzr info ~/bzr/code/
<sohail> Shared repository with trees (format: pack-0.92)
<sohail> Location:
<sohail>   shared repository: /home/sohail/bzr
<lifeless> on one you said code/bzr
<lifeless> on the other bzr/code
<sohail> oops
<sohail> yeah that's a typo
<sohail> bzr/code in both cases
<enigma> jelmer: I dug up more info about the "mergeinfo capable client" message.
<lifeless> sohail: ok
<lifeless> sohail: run bzr info on the result branch, pastebin the output please
<enigma> jelmer: It doesn't seem like it's just a collabnet thing
<enigma> jelmer: http://www.google.com/search?hl=en&q=Commits+require+mergeinfo-capable+client
<enigma> jelmer: For example, there is some discussion of it here: http://groups.google.com/group/openbravo-development/browse_thread/thread/b2aa7aefe7cf14d6
<enigma> jelmer: Supposedly "subversive" 0.7.1 supports it. (I haven't heard of subversive.)
<sohail> lifeless, http://rafb.net/p/Y29aDO61.html
<santagada> http://www.orkut.com.br/Main#CommMsgs.aspx?cmm=18655944&tid=5297825684124574372&na=4&nst=21&nid=18655944-5297825684124574372-5298061795656704676
<santagada> sorry wrong channel
<enigma> jelmer: I don't know if their code would be helpful at all. You can download it here: http://www.polarion.org/index.php?page=download&project=subversive
<lifeless> sohail: ok
<lifeless> sohail: so its a repository tree which means its creating a working copy
<sohail> yeah, can I somehow make it so that there are no working copies in ~/bzr
<lifeless> sohail: if you want to be able to edit the files at that path, thats normal; sounds like you have a big tree and the --hardlink option will help
<lifeless> sohail: on the other hand if you don't want to be able to edit there
<lifeless> just touch ~/bzr/code/.bzr/repository/no-working-trees
<igc> mwhudson: TODO added. see https://code.edge.launchpad.net/~ian-clatworthy/bzr-revnocache/trunk
<igc> beuno may be interested in this as well
 * igc lunch
<keithy> ok so I am using plink
<keithy> how confusing why they couldnt just call it ssh
<nDuff> keithy, ...for one, OpenSSH has that name, so overloading it would mean confusion.
<nDuff> keithy, ...also, plink does more than just SSH unless I'm badly mistaken -- it also has serial, raw socket, telnet, etc. support.
<keithy> k so where does it keep its keys
<lifeless> keithy: I know nothing about plink; is there some specific thing you need to do - just ask, someone here may know
<nDuff> keithy, I believe it keeps them in the registry, though it should also be able to talk to any running Pageant instance
<nDuff> keithy, ...so launching Pageant and adding the keys through its GUI is probably the Right Thing.
 * nDuff isn't principally a Windowsy type, btw, so his advice should be taken with a grain of salt.
<sohail> lifeless, ok thanks
<sohail> I don't want to edit there, you are right
<keithy> I cant be bothered with pageant, its not my server
<sohail> that did it
<lifeless> keithy: so, what do you need to do - just get it working for you on that machine?
<nDuff> keithy, ...hrm, you have plink but not pageant installed? They should both be bundled in the same PuTTY install package.
<keithy> but aegpant is a daemon
<lifeless> keithy: userspace
<nDuff> keithy, right, but not a system service
<nDuff> keithy, ...runs as the current user in the tray.
<lifeless> keithy: its like ssh-agent, its normal to use it for each user
 * sohail uses pageant with bzr+ssh
<keithy> sigh something else to setup
 * nDuff wanders homeward
<keithy> the current user is the admin of the box I dont have a user
<keithy> I am vncing to the box over a openvpn tunnel
<keithy> so I aleady have security
<keithy> so I am happy to give a passwordless key to ssh
<lifeless> keithy: do that then
<keithy> if I can only work out where to put it
<lifeless> just run up pagent
<lifeless> I think you can right click and tell it to import a key or somethin
<keithy> which isnt installed as far as I can see
<lifeless> oh :(
<lifeless> I'd read plink documentation then
<keithy> arrrgh
<keithy> I cant download stuff
<keithy> hmm "pageant is allready running"
<lifeless> is it in the status area ?
<keithy> aparently so
<keithy> but it wants a ppk file
<lifeless> time for google ;)
<keithy> puttygen is supposed to vonvert
<keithy> but it only does private keys
<lifeless> thats what you need isn't it ?
<keithy> my private key is mine
<lifeless> of course
<lifeless> why don't you describe your use case
<lifeless> I'm thoroughly confused
<keithy> I want to give my public key to  ssh on the remote box
<keithy> so he can log in
<keithy> its almost as if no one has ever done this before
<lifeless> hang on
<lifeless> you want to setup a ssh *server* on the windows machine?
<lifeless> or a ssh *client*?
<keithy> ssh client
<lifeless> if you are setting up an ssh client, it needs a private key
<lifeless> the ssh server holds the public key
<lifeless> if its for your colleague to use, he should setup a private key of his own, and give the ssh server operator his public key.
<keithy> ok..
<keithy> its late!
<lifeless> :)
<keithy> wahoo it worked
<igc> That's it for me today - see everyone tomorrow
<lifeless> ciao
<keithy> thanks lifeless, time for bed
<lifeless> spiv: the other odd thing about pdb:
<lifeless> (Pdb) raise
<lifeless> *** AttributeError: Pdb instance has no attribute 'do_raise'
<spiv> Yeah.
<lifeless> invoked by
<lifeless> try:
<lifeless> foo
<lifeless> except:
<lifeless> set_trace
<jamesh> ... and now you've lost the exception from the program you're tracing
<lifeless> jamesh: zigactly
<lifeless> jamesh: because post_mortem is bust
<lifeless> spiv: have you landed your fix yet?
<spiv> No, but I may as well do that now.
<jamesh> lifeless: I posted an updated version of the python/valgrind patch that doesn't conflict with trunk (Python 2.7).  It was mainly NEWS file and autoconf generated files that had bitrotted
<lifeless> jamesh: awesome
<lifeless> poolie: is there a bug for the progress ratio being clipped ?
<lifeless> 37809/45
<lifeless> rather than /45834
<lifeless> poolie: ping
<lifeless> what would  be nice, would be running a custom build of python with the packaged stdlib
<lifeless> + site-packages
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> is my memory faultier than usual
<lifeless> I thought we (you and I even) fixed check to detect: text A compressed against text B that isn't actual meant to exist
<lifeless> or isn't in the ancestry
<poolie> lifeless: pong
<lifeless> poolie: doesn't matter now, bombs away
<poolie> :) ok
<spiv> lifeless: that sounds familiar
<lifeless> spiv: care to confirm something for me
<lifeless> grab a repo object for bzr.dev
<spiv> lifeless: but I can never remember the precise details of that sort of thing without looking over the code/commit log, it's just a bit too subtle too stick in my head.
<lifeless> I have a failing fetch of a text
<spiv> Grabbed...
<lifeless> ok
<lifeless> .texts.get_parent_map([('intset.py-20050717175247-81cd658f9aaa2731', 'john@arbash-meinel.com-20051219174825-3046c2b52fda89dc')])
<lifeless> ->
<lifeless> ...(('intset.py-20050717175247-81cd658f9aaa2731', 'robertc@robertcollins.net-20050919060519-f582f62146b0b458'),)...
<lifeless> t = r.revision_tree('robertc@robertcollins.net-20050919060519-f582f62146b0b458')
<lifeless> t['intset.py-20050717175247-81cd658f9aaa2731'].revision
<lifeless> erm
<lifeless> t.inventory['intset.py-20050717175247-81cd658f9aaa2731'].revision
<lifeless> 'robertc@robertcollins.net-20050915133236-141471392006b464'
<lifeless> 'robertc@robertcollins.net-20050915133236-141471392006b464' != 'robertc@robertcollins.net-20050919060519-f582f62146b0b458'
<spiv> lifeless: yes, that's exactly what I see here.
<lifeless> spiv: grah
<lifeless> spiv: unless I'm reading that wrong, that means that there is delta of intset.py-20050717175247-81cd658f9aaa2731 to a text version that is probably spuriously introduced by another inventory
<lifeless> now I need to find out why my clone operation is dropping that text, and why we are not fixing that delta up
<spiv> That's my reading too. :(
<lifeless> but - I started at 8, and this isn't going to be that short an investigation
<lifeless> so, I'll look tomorrow
<spiv> It does sound a lot like the check/reconcile issue I thought we fixed, but maybe that was a subtly different case...
<lifeless>  /wave
<spiv> lifeless: see you tomorrow
<spiv> lifeless: try not to get flashes of inspiration over dinner, it'd be terrible if you solved this tonight ;)
<vila> hi all
<ionel_mc> is bzr supposed to work with py2.6 ?
<Peng_> ionel_mc: Yes. More or less.
<Peng_> ionel_mc: I don't think it's officially supported yet, but bugs are fixed whenever they're discovered.
<ionel_mc> ah, well, i got it to build (without the c-speedups)
<ionel_mc> speaking of that - are there any benchmarks in regard of the c-speedups ?
<ollie> hey how can I add a dir but not its contents.
<ollie> I am trying to do a bzr mv but I am running into already versioned problems.
<Peng_> jelmer: ping
<Peng_> Whoops, when you accidentally corrupt a bzr repo, don't do they same thing to your other copy of the repo...
<Peng_> s/they/the/
<Peng_> (Anyway, no big deal. Even if it's not recoverable, all it means is I'll waste a few MB of bandwidth pulling things again.)
<Lo-lan-do> Is there a more proper way of testing for the existence of a shared repo than running "bzr info $path" and looking for "Shared repository" in the first line?
<Peng_> Well, I'm sure you could do it using bzrlib.
<Lo-lan-do> This is going to be called by a (probably) PHP script, so not until bzrlib gets PHP bindings :-)
<Peng_> Ah.
<Peng_> You could check for the existence of $path/.bzr/repository/shared-storage, but that's evil, and may not work on older (or newer) repos.
<Peng_> I wasn't going to suggest a hack like that, but you're already using PHP... ;)
<Tak> you could use xmlinfo and check for /info/location/shared_repository elements
<Peng_> Ah, that sounds good.
<Lo-lan-do> Isn't that overkill?
<hno> why?
<Lo-lan-do> Also, is that in core bzr, or is it a plugin?
<Peng_> Lo-lan-do: xmloutput plugin
<Peng_> Lo-lan-do: You could write a small Python script to do it using bzrlib.
 * Tak shrug
<Lo-lan-do> Would it be better than calling bzr info?
<Peng_> Lo-lan-do: Would what be better than who?
<Lo-lan-do> (I'm *very* lazy, which is a virtue for programmers :-)
<Lo-lan-do> Writing a script with bzrlib, vs. calling bzr info.
<Peng_> Lo-lan-do: Well, I doubt "bzr info" is intended to be scriptable. Its output format could change in the future.
<hno> for example one change which may happen is localization, replacing all strings with native language ones. There may also be significant restructuring or even renaming of things.
<Lo-lan-do> Okay.  I'll start with bzr info, and write a bzrlib script during (of after) the weekend, since I've been volunteered to learn some bzrlib and use it at FOSDEM.
<Tak> is there any plan to ever make, say, a C binding to bzrlib?
<jelmer> Peng_: hi
<Peng_> jelmer: Good morning. :)
<jelmer> Peng_: 'afternoon :-)
 * jelmer is finally back in his native timezone
<Peng_> Or that. :P
<Peng_> Lo-lan-do: Here's a very simple script, if you want it: http://paste.pocoo.org/show/102739/
<james_w> jelmer: hey, trying to use bzr-git and it's trying to import foreign_vcs_registry from bzr-foreign and it's not in that project, is one of them out of date?
<Peng_> jelmer: So, um, about my ping. I have copies of lighttpd-1.4.x imported with both bzr-svn 0.4 and 0.5. I tried to pull from the 0.5 copy into the 0.4 copy, but bzr exited with "Newly created pack file ... has delta references to items not in its repository". Now "bzr check" fails with "parent_id ... not in inventory".
<Lo-lan-do> Peng: Thanks.
<Tak> is there a way to get bzr shell not to lock the branch it's using while it's idle?
<Peng_> Augh, another bzr repo bites the dust...
 * Peng_ shakes his fist at lighttpd and bzr-svn.
<Peng_> Different error this time! :)
<Peng_> This is killing me. If I "bzr branch" copies of A and B into a repo, and check, it's fine. If I then branch C, and check, there's an SHA-1 mismatch.
<Peng_> If I create a new repo, and just branch C, it's fine.
<Peng_> The upstream C is fine, but the upstream A and B are in a repo corrupt in a different way.
<jelmer> james_w, hi
<jelmer> james_w, do you have bzr.dev ? some bits of bzr-foreign are in bzr.dev these days
<james_w> hey jelmer
<james_w> jelmer: ah, that will be it
<jelmer> Peng_: Can you reproduce this using vanilla branches created with bzr-svn 0.5.0 ?
<Peng_> jelmer: Ehh. The whole point of the exercise is that I want my old 0.4 branches. :P
<Peng_> I think "bzr check" goes a lot faster with a btree repo. :)
<Peng_> ...Wait, I'm not using a btree repo here. Huh.
<Peng_> jelmer: No, I can't reproduce it.
<Peng_> Sigh.
<EnCuKou> Hello.
<EnCuKou> Is there a proper way to simulate network failures in the bzr test suite?
<Necoro> hey guys - some months ago I moved my project from subversion from svn to bzr - unfortunatly some history was lost (450 revs => ~1/3 of total history)
<Necoro> anyone an idea how to get this history back into my bzr branch?
<Necoro> because I liked to play around with subversion and sometimes changed the general dir layout ... which bzr-svn seems not to handle correctly
<Necoro> depending on the parameters I pass to bzr svnimport I get different parts of the history - but not the complete one
<Necoro> git-svn seems to handle it quite good (everything there) - but bzr-git does not want as I want ;) ...
<Necoro> (and the last question is of course: how to merge it into the current branch...)
<Necoro> s/some months/one year/ ;)
<santagada> Necoro: have you tried svn->mercurial->bzr?
<Necoro> santagada: nope ... but I thought, that the bzr-hg plugin is quite ... outdated
<santagada> Necoro: or merging the diferent runs of svnimport?
<Necoro> santagada: merging won't work, because the history pieces are all disjunct
<santagada> uhmm
<santagada> Necoro: there are other tools to move svn to bzr isn't it?
<Necoro> probably ... but in the end it should be possible to put my current branch on top of the old history ... so anything which produces completely differnt rev-ids won't work I assume
<santagada> Necoro: maybe then you can cherrypick the revisions after the svnimport into this new branch
<santagada> Necoro: but those are just ideas, I don't know svnimport
<Necoro> jelmer: am I reading correctly? - bzr-svn needs bzr-rebase-0.4.3 ... which is not released yet?
<Necoro> hmm - nvm ... going to use trunk
<jelmer> Necoro, yes, that's correct
<jelmer> Necoro, rebase is not required though
<jelmer> Necoro, only useful if you need to run bzr svn-upgrade
<jelmer> abentley, hi
<Necoro> jelmer: which is what I wanted to use ;)
<abentley> jelmer: hi
<jelmer> abentley, Is it correct that merge looks at more than just the file id for path conflicts?
<jelmer> abentley, I have a very obscure use case here (same file ids but no shared revision history)
<jelmer> Necoro, is this repository public btw, and if not, what is the sort of thing that git-svn preserves but bzr-svn doesn't?
<abentley> jelmer: I think so.
<Necoro> jelmer: repo is public (https://svn.origo.ethz.ch/portato/) -- and the difference is quite simple: git preserves all ~650 revs, where as bzr only preserves ~250
<Tak> bzr thinks a branch is locked by a process that no longer exists - what's the best way to force removal of this lock?
<jelmer> Tak, bzr break-lock
<Lo-lan-do> Tak: Cut and paste the command it gives you?
<Necoro> jelmer: because at some time I moved the whole directory structure up one level (i.e. removed the top-level dir) -- and bzr either stops or starts here ;)
<Tak> break-lock seems to have worked, thanks!
<Tak> Lo-lan-do: it was telling me: "Unable to obtain lock file: [...] Held by: [me] (Process #[somedeadprocess])"
<jelmer> Necoro, have you tried: bzr svn-import --layout trunk0 <url> ?
<Necoro> jelmer: hmm - not yet
<Necoro> jelmer: http://dpaste.com/116602/
<Necoro> import worked (but seeing revno 148 it seems not to be correct) - but running svn log the error above happened
<jelmer> Necoro, thanks, that seems to be the same issue as for which you reported a bug
<Necoro> jelmer: oh - ok
<jelmer> Necoro, (svn-upgrade is pointless on a freshly cloned branch btw)
<Necoro> jelmer: it is not freshly cloned -- it is the one cloned about a year ago
<Necoro> wanted to upgrade the revision-ids so it could merge ;) (given that there is something to merge with ^^)
<jelmer> ah, ok :-)
<Necoro> in theory it should be ease ... here I have the revisions i+1..HEAD and there I have 1..i ... now I just need to glue them together ;)
<jelmer> Necoro, I'm trying to figure out what the issue is
<jelmer> abentley, it looks like it will just give path conflicts but after I resolved that it seems to handle things just fine \o/
<Necoro> so ... what would work is to convince rebase, that it should rebase branch B on top of A - even if they do not share a common ancestor
<Necoro> (because HEAD(A) = BOTTOM(B)-1) ... but can't find a way to do so
<jelmer> Necoro, why would you need to rebase?
<Necoro> because I want to join branches A and B
<santagada> I still don't understand why a merge would not solve your problem... but I'm new with bzr
<Necoro> santagada: in a merge, I would have all my history somewhere in a branch ;) - and not in the mainline
<santagada> Necoro: I think you have to somehow tell bzr that B is a checkout of A, and all of B revisions should be replayed on A
<Necoro> santagada: yap
<santagada> Necoro: maybe rebase could do this, but I think there is probably a simpler way
<Necoro> well ... "replay revisions" is exactly what the purpose of rebase is
<Necoro> ;)
<santagada> Necoro: also the checkout and stacked branch are similar
<jelmer> Necoro, but why rebasing without common history?
<Necoro> jelmer: the history is common ... branch B starts right after branch A ends
<santagada> jelmer: each of those branches are the result of diferent runs of svnimport
<jelmer> Necoro, and git-svn imports this correctly?
<jelmer> Necoro, in that case, it really is an issue with bzr-svn
<Necoro> jelmer: git-svn seems to just have not tried to split the svn-repo up in branch and tags etc, but just see it as ONE branch ;)
<jelmer> Necoro, ahh
<Necoro> (or I have just configured it wrongly ^^)
<jelmer> Necoro, stitching the branches together this way won't work well with rebase though, as the file ids will be different
<jelmer> Necoro, bzr-svn can import like git-svn does, as a single branch, but you probably wouldn't want that..
<Necoro> jelmer: so - I just did a "bzr svnimport --layout=root" and then an "bzr split" ...
<jelmer> Necoro, right, that's how to do that..
<jelmer> Necoro, that will work, but e.g. won't preserve tags as bzr tags and won't share history with other branches in the repo (as there's only one branch created)
<Necoro> tags can be added later on by hand ;) - and other branches are just ... well not existing/important
<Necoro> the project is not this big
<Necoro> jelmer: btw: this time, the KeyError did not occur
<jelmer> Necoro, no, as bzr-svn would be ignoring all svk data
<jelmer> since there's no svk:merge properties set on the repository root
<jelmer> Necoro, is this a one-time import, or are you going to push back to svn?
<Necoro> one-time
<Necoro> just want to re-add history
<Necoro> ok - so I'll wait until this svn-upgrade bug is fixed. then I should be able to upgrade my current trunk and rebase it onto the svn-stuff
<jbalint> hi
<jbalint> i've posted a question regarding file ids i need to reconcile, if anybody has any input it would be appreciated: https://answers.launchpad.net/bzr/+question/58337
<jelmer> jbalint: those two files were added indepedently in trunk and branches/branch_5_1 ?
<jbalint> jelmer: no, it was a migration from an svn repo
<jelmer> jbalint, I mean in the svn repo
<jbalint> jelmer: i'm guessing it was a standard svn 'copy', i can take a peak. do you know how it would be indicated?
<jelmer> jbalint: the entry in the "svn log -v" for the second revision (6636) would tell
<alf> Hello, is there a document/mail that describes what are the future plans for bzr? I keep reading about 'brisbane-core' but I can't figure out exactly what this is going to be like.
<jelmer> alf: lp:~bzr/bzr/brisbane-core
<jelmer> is where it lives, I think the commit log may be some indication
<jelmer> I don't think there's a broad roadmap
<jelmer> at least not aware of one
<jbalint> jelmer: yeah, looks like some stuff was moved around at that rev
<jbalint> jelmer: everything moved from /x/<whatever> to just /<whatever>
<jelmer> jbalint, but what sort of operations ? Just "A" without "(from: /...)" ?
<jbalint> jelmer: no, it shows "Copied from path" (i'm using tortoise svn)
<jelmer> jbalint: For those individual files or the branch ?
<jelmer> jbalint, It needs to be from the branch for bzr-svn to create matching file ids, as bzr doesn't support copies yet
<jbalint> jelmer: what do you mean "from the branch" this is just a re-organization inside the branch http://www.improvedideas.com/files/svn_mv.PNG
<jelmer> jbalint, ahh
<jbalint> hold on a second, rev 6636 is interesting
<jelmer> jbalint, I mean, only copies of the branch root will preserve the file id of any affected file
<jelmer> in all other situations the file id will change
<jbalint> jelmer: does svn have this same concept?
<jelmer> jbalint: svn doesn't have the concept of file ids that have to be unique
<jelmer> jbalint, and it supports copies, whereas bzr does not
<jbalint> jelmer: so here is 6636, http://www.improvedideas.com/files/svn_mv2.PNG it looks like the merge into trunk re-arranged all the files
<jbalint> jelmer: this was all done with the svnmerge python script at the time. but we're not even using svn anymore, so i need to figure out some way to be able to merge again - with bzr
<Necoro> jelmer: ok - invoking git-svn in the correct way, it actually produced what I was looking for ;) - though it took waaaay longer than with bzr - and it checked out the whole repo like ... 50 times
<jelmer> jbalint, there isn't much that can be done about this until bzr gets support for tracking copies
<jelmer> Necoro, what is it you're looking for exactly?
<jelmer> jbalint, for the current situation, the only thing you can do really is to fix the conflicts
<Necoro> jelmer: checking out the svn-repo and deal correctly with the "one-level-up"-move and thus return the complete history
<Necoro> (the same I got with bzr-svn-import --layout=root + bzr-split)
<jbalint> jelmer: i'm willing to do that, but afaict i won't work because bzr wont merge files with different file ids
<jelmer> Necoro, but that's importing the svn repository as a single branch and then just throwing some stuff out?
<jbalint> jelmer: i get a contents conflict on every file
<jelmer> jbalint, yeah, that's true. there's no way to associate more than one file id with a file as far as I know, but you may want to ask on the list.
<jbalint> jelmer: ok. thanks for the info!
<Necoro> jelmer: true - git does it in a smarter way - there I really only have the trunk-data in the end -- though the complete one
<jelmer> Necoro, so where does bzr cut off history?
<jelmer> Necoro, since if there's enough info for git-svn, there should be enough for bzr-svn (which already tries to follow branch history completley)
<santagada> I think the problem was that Necoro moved the trunk dir around
<jelmer> santagada, that's not a problem
<jelmer> santagada, at least not with bzr-svn >= 0.5.0
<Necoro> upto revision X I had everything in /local/trunk - after rev X in /trunk ... and bzr splits at that X (i.e. I either get: 1..X-1 or X..HEAD)
<Necoro> perhaps the SVK things mixed confuses bzr-svn ... and git-svn just ignores them ;P
<jelmer> Necoro, what svn revision is that?
<Necoro> X = 454
<sohail> hey, I'm trying to rollback a specific set of checkins that occurred as a result of a branch merge
<sohail> so I'm trying bzr merge -r 1020.2.1010..1020.2.1008 .
<sohail> bzr claims to do stuff, even has a conflict, but then bzr st -v says nothing after I fix the conflict :-/
<sohail> oh duh, I already rolled it out
 * sohail is a dumbass
<lifeless> moin
<kfogel> Is loggerhead trunk generally stable?  (Production use okay for those willing to jump in and fix something occasionally?)
<lifeless> kfogel: we run it on launchpad
<lifeless> well nearly
<lifeless> uhm, I wouldn't have a loggerhead trunk on auto-update, in  production use
<lifeless> but I would run trunk, and test updates
<kfogel> lifeless: thanks
<mwhudson> yeah, launchpad generally runs near-trunk
<kfogel> not sure what "on auto-update" means -- is that a feature of loggerhead, or do you just mean "don't have a cron job updating it, do it manually and be prepared to roll back"?
<mwhudson> though for some reason my attempt to get it updated in time for 2.2.1 failed :/
<speakman> hi folks, I'm stuck with ModelForms in forms.py when importing a model from models.py it just says "ImportError: cannot import name MyModel". But there IS a class MyModel(models.Model): in models.py. Anyone encountered this?
<speakman> gosh wrong window
<MattCampbell> I thought that sounded more like Django than bzr.
<speakman> :D
<lifeless> kfogel: the latter
<speakman> (but it mostly sounds like an python issue..)
<mwhudson> speakman: import models; print models.__file__ -- check you're importing what you think you are
 * mwhudson reigns in his helpfulness again
<kfogel> lifeless: gotcha
<lifeless> kfogel: unless your cron job software is spelt 'sysadmin'
<kfogel> lifeless: my cron job is spelt "staging server", actually
<sohail> is there an equivalent to svn up -r $FOO
<sohail> oh bzr revert
<sohail> kfogel, are you the kfogel from svn
<Lo-lan-do> ...and from CVS, I think.
<Lo-lan-do> (Well, at least from the book, I assume)
<sohail> kewl
<kfogel> sohail: same person, yup
<sohail> is there any abbreviation for bzr branch ~/bzr/code/master ~/bzr/code/foo
<sohail> kfogel, good to know I'm on the right track ;-)
<kfogel> sohail: cd ~/bzr/code; bzr branch master foo
<kfogel> :-)
<sohail> kfogel, doh
<sohail> problem is on the other machine I have to type bzr branch bzr+ssh://blahblahblah
<kfogel> sohail: well, bzr can remember source/dest branches once you've made a new branch, for example, see the --remember option to 'bzr push'
<kfogel> (and to 'bzr merge', and perhaps other commands as well)
<lifeless> sohail: we plan to make more use of relative paths
<spiv> There are also some aliases, like ":parent".
<sohail> hm, an alias sounds about right
<Lo-lan-do> Also the bookmarks plugin.
<Necoro> or a (bash)function if you often access the same location: e.g: bb() { branch="blah/blah/the_branch"; bzr branch bzr+ssh://${branch} bzr+ssh://$(dirname $branch)/$1 }
<Necoro> (where "bb blubb" is equiv. with: bzr branch bzr+ssh://blah/blah/the_branch bzr+ssh://blah/blah/blubb )
<sohail> yep, was hoping to avoid a bash script since "the other machine" is windows
<Necoro> oh
<igc> morning
<mwhudson> kfogel: how is savannah starting loggerhead?
<kfogel> mwhudson: I don't know, but feel free to post in the bug and ask Sylvain.  (I'm happy to do it if you want, but it might make sense to remove the intermediary.)
<kfogel> mwhudson: I'm installing it locally right now to see if I can reproduce
<mwhudson> kfogel: ok, i posted to the bug
<kfogel> thanks
<kfogel> mwhudson: hmmm. and now I'm reading through the loggerhead README in trunk and see this:
<kfogel> 3) Paste Deploy  (optional, needed when proxying through Apache)
<kfogel>    on Ubuntu package `sudo apt-get install python-pastedeploy`
<kfogel>    or use `easy_install PasteDeploy`
<kfogel> wonder if there's any connection
<mwhudson> kfogel: see my comment in the report :)
<kfogel> mwhudson: hah
<mwhudson> maybe i should just paste in a known working copy of prefixmiddleware into loggerhead and be done with this
<kfogel> mwhudson: I hadn't yet read your comment (because I thought you'd posted to the Savannah bug, not the lp one)
<mwhudson> kfogel: ah
<kfogel> mwhudson: I'm copynig over, np
<kfogel> mwhudson: I'm not sure it makes sense to try to formally connect the savannah bug to lp
<kfogel> if that can even be done
<mwhudson> i think it can be
<mwhudson> but well
<mwhudson> effort < payoff
<kfogel> exactly
<mwhudson> i really really hate the way urls are generated in loggerhead btw
<mwhudson> but i hate this in everything to do with the web i've ever done, so...
<kfogel> mwhudson: hunh.  Really?  Maybe I haven't worked in web space enough; URL-generation never struck me as a particularly ugly process.  Now, communicating streamy data over HTTP is another matter...
<mwhudson> kfogel: loggerhead is probably worse than average
<mwhudson> but there always seems to be repetition, at least
<kfogel> mwhudson: oh.  Well, it's working at least!  http://localhost:8080/changes is serving my (of course) loggerhead-trunk branch
<mwhudson> kfogel: cool
<kfogel> never done anything with mod_proxy though, so not sure if this next step will work.  let's see
<mwhudson> so where paste deploy comes into this is that when proxying
<mwhudson> apache sends an x-http-forwarded-for header or something like that
<mwhudson> paste deploy has some magic that looks at this and tweaks the environ so that the application thinks it's serving requests for http://external-host/ not http://localhost:8080/
<mwhudson> but if paste deploy isn't installed (or you have a buggy version, though i can't remember if that's actually happened) this doesn't happen
<mwhudson> i should probably tweak serve-branches to complain if paste.deploy is not installed _and_ HTTP_X_FORWARDED_SERVER is set in the environment
<kfogel> mwhudson: that would be a good idea, yeah
 * mwhudson isn't sure the new branching instructions on every loggerhead page are especially attractive :/
<lifeless> kfogel: both url generation and stream data are fugly fugly fugly fugly
<lifeless> kfogel: url's are a single namespace, but we want OLAP spaces basically
<kfogel> lifeless: OLAP?
<lifeless> kfogel: and also want it to be easy to type in
<lifeless> kfogel: online analytics of the branch
<mwhudson> certainly >1 dimensional urls would make life easier
<kfogel> s/easy to type in/short/
<kfogel> ?
<RomD> hi, I tried to download the latest version of this project: https://launchpad.net/~poppler-python
<RomD> but I'm getting this error:
<RomD>  bzr branch lp:poppler-python
<RomD> bzr: ERROR: Invalid url supplied to transport: "lp:poppler-python": Series trunk on poppler-python has no branch associated with it
<kfogel> That is, length is a primary driver?
<lifeless> kfogel: time is one dimension, content another, and don't even think about metadata analysis like searching/authors/bugs<->changes etc
<kfogel> ugh
<kfogel> yeah
<lifeless> kfogel: I8U66%rr# is short but not easy
<RomD> is there any way to get the source code?
 * mwhudson watches bzr-avahi get excited when he runs loggerhead's tests
<lifeless> RomD: sure is, head to launchpad and click on 'code'
<mwhudson> i guess i should be using bzrlib.tests.TestCase...
<lifeless> RomD: it should have a listing of branches there
<spiv> mwhudson: yeah
<spiv> mwhudson: also, you might end up getting prompted for GPG keys and the like...
<RomD> ah thanks lifeless, didn't see that it shows the exact name there. forgot the "~" in front
<mwhudson> spiv: hm yeah, seahorse rescues me from that i guess
<mwhudson> kfogel: ok, i committed that fix
<kfogel> mwhudson: that was *fast*
<kfogel> mwhudson: does the issue update automatically?
<kfogel> mwhudson: hmmm.  apparently not
<mwhudson> kfogel: well it doesn't really address the issue head-on
<kfogel> ?
<mwhudson> it just makes one possible cause slap you in the face rather than generate bogus links
<kfogel> oh
<kfogel> that fix
<kfogel> well, that's still good
<mwhudson> <mwhudson> i should probably tweak serve-branches to complain if paste.deploy is not installed _and_ HTTP_X_FORWARDED_SERVER is set in the environment
<kfogel> it'll be much more apparent that one's setup is bogus then
<kfogel> right
<mwhudson> ^^ that's the fix i was talking about
<kfogel> mwhudson: noted in the issue
<mwhudson> kfogel: ta
<jml> I have a branch that merged into my project's trunk a long time ago
<jml> how would I find out what revno of trunk the merge took place?
<lifeless> jml: bzr missing trunk
<jml> lifeless: which of the several dozen revisions is the answer?
<lifeless> jml: the lowest number - 1
<spiv> Someone should write a when-merged plugin...
<igc> bbl - errand to run
#bzr 2009-02-05
<gotgenes> I've made some local, uncommitted changes but decided they would be better suited to be put into their own branch. Is there an easy way I can branch, keeping the local changes?
<jelmer> gotgenes: "bzr branch thisdir otherdir; cd ../otherdir; bzr merge --uncommitted ../thisdir"
<gotgenes> jelmer: awesome, let me try that
<bob2> if you're using checkouts, make a new branch, and 'bzr switch' the working copy to the new branch
<gotgenes> bob2: no checkouts in this case
<EnCuKou> Or commit --local, branch, and uncommit
<gotgenes> jelmer: Brilliant!
<gotgenes> EnCuKou: that would also work, too.
<mwhudson> merge --uncommitted is cool
<jml> yeah
<igc> mwhudson: did that TODO for revnocache prove interesting?
<mwhudson> igc: yes
<igc> mwhudson: lifeless has some thoughts he'd like to share on how best to use btrees so be sure to ping him before hacking on that bit
<mwhudson> igc: i'm hip-deep in reviewing launchpad code today though
<igc> mwhudson: np. Just making sure I didn't forget to tell you :-)
<mwhudson> igc: ok, i saw, i cogitated, but no more than that :)
<LaserJock> any ETA on working ~bzr PPA for Intrepid?
 * igc lunch
<poolie> lifeless: ping?
<poolie> lifeless: i got a pqm failure full of lines like this:
<poolie> merge http://sourcefrog.net/bzr/remove-sftplock http://bazaar-vcs.org/bzr/bzr.dev
<poolie> Command failed!
<poolie> All lines of log output:
<poolie> Executing pre-commit hook /home/pqm/bin/kill-chroot-processes.sh /srv/pqm.ubuntu.com/chroot-amd64 && /home/pqm/bin/dchroot-run make check at Thu Feb Â 5 04:26:46 2009
<poolie> Scanning for processes to kill in chroot /srv/pqm.ubuntu.com/chroot-amd64
<poolie> Scanning for processes to kill in chroot /srv/pqm.ubuntu.com/chroot-amd64
<poolie> removed directory: `/srv/pqm.ubuntu.com/chroot-amd64/tmp/bzr-limbo-011qkx'
<lifeless> spm: ^
<spm> hrm
<spm> tom did some changes there this morning....
<lifeless> my guess
<lifeless> the commit before left dirt
<lifeless> and the kill-checker found that dirt and exited non-zero as a result
<lifeless> so -- resubmit your merge
<lifeless> and file a bug that we aren't cleaning up bzr-limbo-011qkx during test runs
<lifeless> and tell everyone to submit every merge twice until we do :P
<poolie> :/
<lifeless> or we can roll the clean-checker back
<lifeless> but we had a bunch of stale bzr test processes yesterday, from months back
<lifeless> and the sysadmins pinged me
<lifeless> this is an existing tool written for lp
<spm> lifeless: would it be worthwhile reverting tom's change to pqm-config, till you guys get this stuff sorted?
<poolie> the second request i sent just failed too
<lifeless> spm: things without motivation often don't get sorted
<lifeless> poolie: interesting, hang a tick
<poolie> lifeless: what's it supposed to do?
<lifeless> spm: can you check if there is other dirt left behind?
<lifeless> spm: perhaps the check is not fully cleaning
<spm> poolie: basically is doing: for ROOT in /proc/*/root; do === in the chroot
<spm> lifeless: sure, one sec
<lifeless> poolie: it finds processes and temporary directories created in the chroot, and zaps em
<poolie> as part of the *next* merge?
<lifeless> poolie: so that old test runs that left cruft don't cause spurious success||failure to new ones
<lifeless> poolie: that part seems odd to me too :P
<lifeless> spm: I'd be inclined to run it before and after, FWIW
<poolie> ok and the third one just failed too
<spm> lifeless: a prehook as well?
<poolie> istr that pchroot or dchroot handles this as a standard feature
<lifeless> spm: /home/pqm/bin/kill-chroot-processes.sh /srv/pqm.ubuntu.com/chroot-amd64 && /home/pqm/bin/dchroot-run make check && /home/pqm/bin/kill-chroot-processes.sh /srv/pqm.ubuntu.com/chroot-amd64
<lifeless> spm: for lp too IMO, but thats a different discussion. Lets find out the cause of this problem, and then unblock poolie
<spm> sure - fixing - one tick
<spm> poolie: try now
<poolie> ok sent
<poolie> spm: still sucks
<spm> lifeless: I think we're picking up procs from another chroot on that box
<lifeless> spm: better disable it for now then
<lifeless> spm: if you would be so kind
<spm> 2/2 then? :-P
<poolie> yes, please disable it
<lifeless> well, 2/1 for zings, and $help-each-other-whenever ;)
<poolie> 2/2 what?
<spm> hahahahha
<poolie> 100% of my submissions have failed
<poolie> it sounds like a useful feature but only if it works :)
<LaserJock> poolie: you happen to know if bzrtools is gonna get updated in ~bzr PPA any time soonish?
<poolie> yes, soon
<poolie> LaserJock: what do you use from bzrtools btw?
<spm> poolie: go for it. btw did I ever mention that bzr rocks for doing config file management?
<LaserJock> poolie: I have no idea but I can't upgrade bzr-svn I don't think
<poolie> ?
<poolie> spm, trying again
<LaserJock> I don't know, but I can' do a clean upgrade, I've gotta remove something, let me check
<LaserJock> ok, so I can upgrade bzr and bzr-svn but bzrtools gets removed
<LaserJock> I don't know what all is in bzrtools but I've always been told it's pretty important to have
<poolie> spm, ok, i got a real failure, yay
<spm> poolie: cool - progress of sorts :-)
<lifeless> night all
<lifeless> poolie: were you going to reply to that mail ?
 * spiv heads off to SyPy
<thumper> how do I get bzr to show me the revision id of the last revision from the commandline?
<mwhudson> thumper: bzr revision-info
<thumper> ta
<vila> hi all
<poolie> hello vila
<fullermd> me blinks.
<fullermd> I thought autopack only did its thing when we got up to 10 packs (or various farther iterations)
<ronny> moin
<bartzitz> hello, i'm affected by this bug https://bugs.launchpad.net/bzr/+bug/319790 (can't unshelve my changes)
<ubottu> Launchpad bug 319790 in bzr "bzr unshelve crashes losing all changes" [Medium,Confirmed]
<bartzitz> someone suggests restoring the shelf manually, but how do i do it?
<ronny> jelmer: say - are there any plans to have some kind of content-addressing in bzr?
<igc> night all
<beuno> ugh
<beuno> mac and windows encoding are not getting along
<beuno> does anyone know how I can avoid getting into this situation?  http://paste.ubuntu.com/114010/
<Tak> ouch
<Peng_> igc: You're probably gone now, but the "log multiple files and directories" merge directive you just sent has an incorrect target_branch, so BB won't track it.
<verterok_> beuno: playing with the encoding options when mounting the sshfs?
<verterok_> beuno: hi!, btw
<beuno> verterok_, hai!
<beuno> verterok_, no sshfs involved  :(
<beuno> blain branching back and forth
<verterok_> :/
<Tak> jelmer: ping?
<Lo-lan-do> Hi all
<Lo-lan-do> jelmer: I guess subvertpy is in NEW... is the package available somewhere in the meantime?
<ronny> pypi?
<Lo-lan-do> ?
<ronny> python package index
<Lo-lan-do> I'll have a look, thanks.
<ronny> its easy-install able
<Lo-lan-do> Oh.  No go then, I need dpkg-able :-)
<ronny> hmm
<ronny> maybe there is a ppa on launchpad
 * Lo-lan-do rebuilds from the source package available in the PPA
<ronny> jelmer: btw, how does one do a commit with message from a wc/client in subvertpy?
<ronny> client.commit seems to be without message
<james_w> are the messages done with callbacks?
<ronny> i have no idea
<jelmer> ronny, you need to specify a callback for the message
<jelmer> ronny, client_ctx.log_msg_func = lambda items: "bla"
<ronny> yikes
<jelmer> items is the list of things being committed
<ronny> jelmer: is it possible to tell it the author?
<jelmer> ronny, the callback ? no, the author isn't known at that point
<jelmer> svn sends back the author only once the commit is done
<ronny> what where they thinking?
<Tak> jelmer: I was looking at the md-bzr debian branch - ironpython shouldn't be in the build-depends
<tedg> Hello, I thought there was a way to attach metadata to a file in bzr, but I can't seem to figure out to do it.  Can I do that from the command line?
<Tak> new version will depend on bzrtools, though, and xmloutput (once there's a deb package)
<gnomefreak> is there a way to use bzr to generate an upstream tarball using the version in the debian/changelog?
<jelmer> Tak, right now, it does depend on ironpython, see the mdp file
<jelmer> gnomefreak, bzr builddeb --export-only . IIRC
<ronny> jelmer: btw, do you guys have any plans for content-addressing?
<gnomefreak> jelmer: thanks ill try it
<ronny> i need a git-alike object db soon that can handle more than just blob/tree/commit/tag
<ronny> however i need it content-addressed
<gnomefreak> that failed :(
<Tak> I can remove the reference, but it's not being used anyway
<jelmer> gnomefreak, it works fine here, what error do you get?
<gnomefreak> jelmer: http://pastebin.mozilla.org/616311
<jelmer> ronny: I'm not sure I follow
<jelmer> ronny: What do you mean by content-addressing? Being able to fetch revisions/texts by their checksum?
<jelmer> gnomefreak, you're not exporting upstream from bzr, any reason for not just using uscan?
<ronny> jelmer: yeah
<jelmer> ronny, I don't think there are any plans for that
<ronny> ok
<gnomefreak> jelmer: not sure how would be the biggest reason
<ronny> then i'll reimlement git's object db soon
<ronny> git cant be extended with new types
<gnomefreak> maybe ill just get the most recent and update change as needed
<bialix> hi, any bzrlib hackers here?
<jelmer> gnomefreak: uscan already parses debian/changelog, I think if you use the right magic options for it it can download the appropriate tarball
<jelmer> hi bialix
<bialix> I have question about test
<bialix> hi jelmer
<gnomefreak> jelmer: thanks ill look at man page
<bialix> my question is: how can I test that some method I call write rnings?
<bialix> warnings
<bialix> I'd like to avoid write black-box test
<bialix> any ideas?
 * bialix looks at TestCase attributes
<bialix> or maybe I need to use bzrlib.trace.push_log_file?
<bialix> push_log_file is fine
<santagada> something missing from the bazaar user guide is if using bazaar server by itself provides any form of security
<Peng_> santagada: It does not. That's what running it through ssh is for. :)
<Peng_> Or http.
<MattCampbell> Or SMB if you're on an all-Windows LAN.
<santagada> but http is not using the smart server right?
<MattCampbell> The smart server can be used over HTTP.
<santagada> MattCampbell: really? that is not on the user guide I think
<santagada> MattCampbell: Great! that was one of the problems I thought when moving from subversion to bazaar...
<MattCampbell> santagada: What's wrong with bzr+ssh?
<santagada> MattCampbell: firewalls, stupid firewalls, and windows users
<Lo-lan-do> What's wrong with bzr send + email?  Surely even Windows users can send mails...
<santagada> MattCampbell: and it is far easier to connect a subtree of a web server to ldap than to change a whole system login to suport a dev team
<santagada> Lo-lan-do: :)
<MattCampbell> Hmm, let me double-check that you can run the bzr smart server over HTTP; I may be confusing bzr with Mercurial.
<MattCampbell> Now I'm curious; does Launchpad even support authenticated bzr access over HTTP?
<MattCampbell> I know Launchpad supports bzr+ssh via a custom SSH server using twisted.conch.
<Lo-lan-do> And as for firewalls, surely they don't block HTTPS, do they?
<MattCampbell> I'd hope not, though some especially anal ones may require you to use a proxy with the CONNECT command.
<Lo-lan-do> http://sam.zoy.org/blog/2007-04-23-use-sshd-and-httpd-on-the-same-port-almost is your friend
<Tak> most "especially anal" ones don't support CONNECT at all
<Tak> in my experience
<santagada> there is a firewall on some machines on my university that blocks some http verbs that mod_svn uses
<MattCampbell> Then I suppose they allow direct access to port 443.
<Lo-lan-do> In my experience, these ones are more of a hindrance to work getting done than anything else, so the problem becomes a human problem that technical solutions won't help solve.
<santagada> so you can update/checkout from http but not commit
<santagada> MattCampbell: yes, using https solves the problem
<MattCampbell> Does anyone know of a firewall that monitors the traffic on outgoing connections to port 443 to make sure it's really SSL?
<santagada> still as I don't have the custom ssh server lp uses I prefer https with ldap for repo comunication
<santagada> MattCampbell: yes, the traffic shappers used by some ISPs does this
<MattCampbell> santagada: You could probably do a good imitation of Launchpad's ssh server if you know Python and Twisted.
<Lo-lan-do> You can still tunnel SSH over SSL then.
<santagada> MattCampbell: yep... but still, http and ldap can be used by non python programmers
<MattCampbell> I assume Launchpad's custom SSH server is part of the code-hosting component which will be kept proprietary.
<santagada> Lo-lan-do: double the encryption for double the security? :)
<Lo-lan-do> No, double the encryption so these proxies can only see an SSL stream without knowing it's really SSH inside.
<santagada> Lo-lan-do: I got it, but it still doesn't solve the problem of having a ssh server that uses ldap for authentication, without messing with the system one
<Lo-lan-do> I'm not sure I follow...
<Lo-lan-do> Why do you want two sshds?
<santagada> Lo-lan-do: if your set of bzr users are not the same as your unix users
<santagada> Lo-lan-do: or for example if you have a windows server
<Lo-lan-do> Oh, *ugh*
<santagada> Lo-lan-do: both of the situations happen
<Lo-lan-do> I bet they do.  Poor guys...
<bialix> no, they're not poor, because bzr gave them rich-roots!
<bialix> hi garyvdm
<garyvdm> Hi
<bialix> I've looked at the bug about UI factory
<bialix> but did not find solution quickly
<bialix> it seems there was big change recently
<garyvdm> bialix: I'm looking at it atm.
<bialix> old code rely on self.stdout/self.stdin
 * bialix nods
<garyvdm> Yhea that was me - but stdout/stdin should be there
<bialix> I've tracked it down to bzrlib
<garyvdm> I'm getting a different traceback
<bialix> you've changed the base class, there I'm stopping
<bialix> I'm running bzr.exe 1.11
<bialix> I guess you're using bzr.dev
<garyvdm> I have the same problem on 1.11 and bzr.dev
<garyvdm> This is the traceback I'm getting
<garyvdm> I get it from any q* command. Ones that use the subprocess ui factory like qpull, and ones that use in process ui factory, like qlog.
<garyvdm> I don't get it if I just run bzr pull
<garyvdm> I get it if I revert back to rev 575 of qbzr
<garyvdm> which is before I started changing the ui factories
<bialix> hmmm
<bialix> can you pastebin your traceback
 * bialix reverts to 575 too
<garyvdm> http://pastebin.com/d7f36feaa
<garyvdm> Sorry - I pastebined it a while ago and forgot to send the url <-- silly me
<bialix> you've got completelly different error
<garyvdm> Same problem with rev 549
<bialix> can you try with lp: url? without ssh key
<bialix> I don't have the problem with 575
 * garyvdm tries to figure out how to disable his ssh key on ubuntu
<bialix> oops
 * bialix has no idea
<garyvdm> Got it
<MattCampbell> santagada: BTW, you *can* run the bzr smart server over HTTP; it's documented in the user guide.  You can use either FastCGI or Apache 2 with mod_python.
<garyvdm> bialix: Going to boot Windows
<santagada> MattCampbell: I was at section 7.4... thanks
<bialix> garyvdm: no problem with r576 too
 * bialix waits for gary to rebbot
<santagada> MattCampbell: I think there should be a link to the appendice about it... or a more proiminent one
<garyvdm> Ahh - bialix - can I give you a bundle to test
<bialix> of course
<MattCampbell> santagada: Or sinze the smart server's HTTP transport is a WSGI application, you can run it as a separate HTTP server (using e.g. wsgiref or paste.httpserver) and have Apache proxy to it.
<MattCampbell> There are actually very many options for deploying a WSGI app, as I recently learned.
<bialix> garuvdm: btw, there is another bug introduced in r579. when I click Cancel in password dialog the subprocess cannot stops
<bialix> garyvdm: sorry ^^
<santagada> MattCampbell: yep, if it is a wsgi app it is very very flexible
<santagada> MattCampbell: my latest idea is use cherokee web server + scgi
<MattCampbell> santagada: Why Cherokee?
<santagada> MattCampbell: Cherokee is very light, like lighttpd but seems even simpler to configure
<santagada> maybe ngix is also a good idea... or lighttpd
<bialix> garyvdm: you're still here?
<garyvdm> Yhea
<bialix> r576-581 (including) have no problem for me
<bialix> offending revision is 582
<garyvdm> bialix: I've just sent you bundle.
<bialix> Gary, why you need to change base class? I'm curious
<garyvdm> Because TextUIFactory expects to be able to prompt the user and get a response from stdin
<garyvdm> The only situation qbzr can handle that is for passwords.
<bialix> hmmmmmmmmmmmmmmmmmmmmm
<bialix> I cannot reproduce the bug on the netbook with English XP
<bialix> but can on Russian Windows
<MattCampbell> I don't even know what this bug is, but it smells like a Unicode problem.
<garyvdm> I think the problem my be with using super - so maybe python version.
<MattCampbell> Well, my comment is based on bialix's one statement about the bug happening on Russian Windows but not English Windows.
<garyvdm> MattCampbell: The error: AttributeError: 'SubprocessUIFactory' object has no attribute 'stdout'
<garyvdm> bug 324758
<ubottu> Launchpad bug 324758 in qbzr "'SubprocessUIFactory' object has no attribute 'stdout'" [High,New] https://launchpad.net/bugs/324758
<bialix> weird
<bialix> but there different plugins set
<bialix> garyvdm: different traceback now
<bialix> bzr: ERROR: exceptions.TypeError: __init__() takes exactly 1 argument (4 given)
<bialix>   File "C:\work\Bazaar\plugins\qbzr\lib\subprocess.py", line 617, in __init__
<garyvdm> bialix: ok - let me boot into windows
<bialix> garyvdm: http://pastebin.com/m27669343
 * bialix waits
<bialix> garyvdm: http://pastebin.com/m27669343
<bialix> garyvdm: it seems in the older bzr versions CLIUIFactory constructor has only self argument
<Lo-lan-do> How recognizable is the bzr crowd?
<Lo-lan-do> For the sake of example, let's assume the context of a large beer-oriented pub filled to the brim with geeks.
<LeoNerd> I find I quite often use 'bzr shelve' etc.. in svn checkouts. If I haven't used it for a while, it has to spend a while pulling changes from the SVN repo. Is there some command I can schedule via cron, maybe, so that my local bzr-svn cache is kept up to date?
<Necoro> Lo-lan-do: the guys prasing Linus Torvalds as a (semi)god are probably git-fanatics ...
<Lo-lan-do> LeoNerd: I think that's a bug I reported already, and jelmer said it would be fixed for 0.5.1.
<GaryvdM> bialix: Got to do some work related stuff - but I'll return shortly
 * bialix going to home soon
<LeoNerd> Lo-lan-do: Oh.. I don't think it's a bug... it works well enough.. I just would like it to keep its cache up to date while I'm not using it. Say, overnight.
<bialix> GaryvdM: if I'm commenting out extra args from constructor I'm get the same traceback
<Lo-lan-do> LeoNerd: Five minutes for a bzr update when there's only one revision to pull qualifies as a bug for me, but YMMV.  Anyway, just run "bzr update" at night, and you should be fine.
<bialix> I guess we can simply set stdout attribute from our code if bzr < 1.12
<bialix> GaryvdM: I'm heading to home, will try to check the trick with stdout at home
<bialix> GaryvdM: but it seems we should override CLIUIfactory constructor in the way similar to TextUIFactory
 * bialix bbl
<LeoNerd> Lo-lan-do: Oooh.. Well, if there really is only one revision then mine is quick. It's just our repo is massive, it gets the order of 5 commits a minute. If I haven't used bzr-svn in a few weeks, it has to spend many minutes catching up. I'd like to have a daily cron task that keeps the cache fresh, as of that morning
<Lo-lan-do> LeoNerd: Apparently (from the logs) something scans all SVN revisions after having fethed the new ones.
<Lo-lan-do> If I'm up-to-date, a bzr update takes ~10 seconds.
<Tak> ditto, at least
<Lo-lan-do> If I need to pull revs, then it's ~15 seconds doing useful stuff followed by ~5 minutes spent doing "something" to every revision in the cache.
<Lo-lan-do> In my case we have ~7000 revs in SVN.
<Tak> mine is like 130k
<Lo-lan-do> Tak: And it's still fast?
<Lo-lan-do> I must be doing something wrong then...
<Tak> ...fast?
<Lo-lan-do> Sorry, I may have misunderstood.  Do you also see delays of several minutes when doing a bzr update?
<kfogel> terminology question: in bzr, do people tend to refer to the mainline as "mainline", "trunk", "master", or something else?
<Lo-lan-do> I tend to use trunk because that's what people coming from SVN know.
<Lo-lan-do> Also, because it sits well with the concept of branches.
<LeoNerd> kfogel: "what mainline" ?
<Lo-lan-do> The one with the Holy Penguin Pee, of course.
<kfogel> LeoNerd: "mainline" == "the branch that developers of the project socially agree contains the latest code that is ultimately destined for release"
<LeoNerd> kfogel: But such a concept doesn't always exist
<Lo-lan-do> I would s/release/the next release/
<LeoNerd> That's surely the point of decentralised working, no?
<kfogel> LeoNerd: no, I don't think it is.  The concept always exists, as a concept :-).  Whether it exists in a given project is usually not a matter of controversy, but can sometimes be.
<kfogel> LeoNerd: another way to think of it is "the place where a change needs to land to be taken seriously by the group of people who call that place 'mainline'".
<kfogel> LeoNerd: So you see, it's not less decentralized, it's just that the term can be relative.  As indeed it can be with a centralized VC system too.
<clemente> kfogel: I call it the âofficialâ branch or refer to it by name; for instance âIn bzr.dev ...â
<Lo-lan-do> (I still don't know how to find you guys tomorrow night at the Delirium CafÃ©...)
<kfogel> clemente: that works, though not equally well in all writing contexts
<kfogel> I guess I'll go with trunk for the generic term, for now.
<Tak> Lo-lan-do: yeah, I see long delays when updating, pulling, merging, even when there are no changes
<Lo-lan-do> Tak: Ah.  Reproducibility is always good :-)
<GaryvdM> bialix: I can reproduce the problem now.
<benrometsch> sorry if this is a ridiculously stupid question, but I'm trying to figure out whether bzr or git is better for me, and I cant find a way of creating a local branch in bzr - am I missing something?
<benrometsch> \]
<Peng_> benrometsch: Bzr doesn't support git-like local branching. You only get one branch per directory.
<benrometsch> right that's what I thought
<benrometsch> is there a philosophical reason for this?
<Lo-lan-do> "Not implemented yet".  Not very philosophical :-)
<benrometsch> lol
<Lo-lan-do> Well, it depends on what you call a local branch, actually.
<Necoro> Lo-lan-do: is there really a plan to have something like this?
<Lo-lan-do> Necoro: Apparently there is.  The keyword is "colocated branches".
<Necoro> ah ok
<Necoro> I thought, that it was really avoided as of "we do not want this"
<Lo-lan-do> benrometsch: "bzr branch $remote" gives you a branch that is local, doesn't it?
<Tak> I have never understood the "need" for colocated branches
<benrometsch> but I mean you cant switch branches within the same directory
<Lo-lan-do> Necoro: I think it's "we do not want this unless implemented properly", which is slightly different.
<benrometsch> so if I have a project with files/dirs in it I cant create a local brach, make changes and then if required quickly revert back to the original branch
<Lo-lan-do> benrometsch: Correct, although you can simulate that with a shared repo and a lightweight checkout.
<benrometsch> yeah but that's just like SVN...
<benrometsch> and we already use SVN
<Necoro> benrometsch: Oo - bzr branch $remote b; cd b; code ...; cd ..; rm -rf b
<Lo-lan-do> I don't have a good answer for you then I'm afraid :-/
<Necoro> benrometsch: or I am not really understanding your point ;)
<Necoro> as the branch you get with "bzr branch" is _local_ as in: the remote branch does not notice any changes you do here
<benrometsch> i just like the way in git you can easily create branches locally without having to create a seperate directory structure
<Lo-lan-do> Necoro: "in the same directory"
<benrometsch> and then flick between then with a simple command
<Necoro> well ... I have a shell alias for sth like this ;P
<Necoro> "cdp branch"
<Necoro> ^^
<Lo-lan-do> That's what colocated branches are about, and they're at the discussion stage.
<benrometsch> tbh the experience of playing with bazaar vs git - bzr is much nicer
<benrometsch> cleaner OSX install, better documentation
<benrometsch> git has been problematic for us here esp in windows
<benrometsch> so is $remote a special keyword when branching>?
<Necoro> eh no
<Necoro> it is just a placeholder for the remote branch URL
<Necoro> ;)
<benrometsch> ok I see
<benrometsch> just wanted to check
<Lo-lan-do> "bzr branch <remote>", if you prefer
<Necoro> benrometsch: btw: have you had a look at mercurial ... just to give you another option at hand in case neither bzr nor git are what you are looking for
<Necoro> though I do not know if hg has "local branches"
<benrometsch> yeah I just downloaded it a moment ago
<Necoro> (the one thing I really prefer from bzr over hg and git are "revision numbers" ... not having stupid SHA-hashes one has to deal with)
<Peng_> Necoro: Hg does have local branches, but you can't delete them once you create them. (Recently it became possible to hide them though.)
<Necoro> Peng_: well ... not being able to delete them could be an issue ...
<Peng_> Indeedy.
<Peng_> Generally people use separate clones for short-lived branches, just like in bzr.
<santagada> benrometsch: this local branch thingie might be what I was looking for
<Necoro> and not having local branches has one advantage: you clearly see on what branch you are working on ;) - w/o having to do "git branch" or tweak your shell prompt ;)
<santagada> keep the directory I'm working with but change the branch
<Peng_> Though you can tweak your shell prompt if you want to.
<Peng_> Who doesn't want "cd" to take 300ms?
<santagada> probably just moving things around would do also
<Necoro> Peng_: my shell prompt shows me the current bzr revno and whether there are uncommited changes ;)
<Necoro> on larger repos I have to turn it off ^^
<benrometsch> yeah santagada local branches are one of the things I think would really speed stuff up but I take other people's points that having directories explicitly defining branches can be useful
<Necoro> with git it could be less problematic as it is way faster
<santagada> the problem I see is with dev tools
<santagada> for example textmate has the concept of project wich is a directory
<benrometsch> yep that's what would help us - being able to just update changed files rather than having a whole new directory
<santagada> ahh forget it... it is just an "mate ./" anyway
<santagada> benrometsch: what ide/editor do you use?
<jelmer> Lo-lan-do: Hi!
<Lo-lan-do> Hi jelmer :-)
<jelmer> Lo-lan-do, We don't really stand out from the rest of the FOSDEM crowd I think..
<Necoro> benrometsch: if you just want to overwrite the current dir w/ another branch and do not care about local changes, "bzr pull" is your frient
<benrometsch> intellij idea
<Necoro> s/frient/friend/
<jelmer> Lo-lan-do: I'll try to wear my Bazaar t-shirt at the beer event on friday
<Lo-lan-do> 'kay
<Necoro> (well "bzr pull --overwrite" this is actually)
<benrometsch> Necoro: yeah that's ok but it still means I have to create another directorym then work in that, then pull back
<benrometsch> which doesn't follow the workflow of our IDE that well
<Necoro> benrometsch: eh no
<benrometsch> so is hg more like git or bzr?
<Necoro> suppose you branched URL_A - worked on it ... and then want to pull in URL_B and overwrite everything you just did
<Necoro> bzr branch URL_A b; cd b; code ... ; bzr pull URL_B --overwrite
<benrometsch> Yeah that's the problem tho - the cd b;code
<benrometsch> that's not good for me
<Necoro> but even in git, you have to create a directory in which the code exists
<Necoro> this is not ClearCase ;P
<benrometsch> but in git I can just say
<benrometsch> branch <branch name>
<benrometsch> then carry on in my IDE
<Necoro> well ... do "bzr pull <branch name> --overwrite" (with restrictions as noted above)
<Necoro> which does the same - replacing the current branch by another branch
<benrometsch> what about creating a new branch
<Necoro> well ok
<Necoro> your point
<benrometsch> ha ;)
<benrometsch> ho well I'll give hg a run and see
<benrometsch> that has local branching right>
<benrometsch> ?
<Necoro> according to Peng_
<jelmer> there's a proof-of-concept plugin for bzr that provides local branching support
<benrometsch> thanks for the help anyway
<GaryvdM> bialix: Fixed both problems :-)
<santagada> benrometsch: tell us what you discover... I'm interested at least
<ronny> jelmer: does dulwitch give complete access to git via bzr apis?
<jelmer> ronny, no, that's bzr-git (which is built using dulwich)
<jelmer> dulwich is generic, not specific to bzr
<jelmer> (a bit similar to bzr-svn / subvertpy)
<ronny> jelmer: ah, so dullwich gives git ?
<jelmer> ronny, yep
<ronny> jelmer: its really nice how you gradually implement everything i need for anyvc
<jelmer> ronny, :-)
<kfogel> If anyone wants to proofread this, I'd be grateful:
<kfogel> http://www.emacswiki.org/emacs/BzrForEmacsDevs#Regulars
<kfogel> Trying to get those people prepared for the Big Day.
<ronny> jelmer: does dulwich use any of git, or is ir completely independ
<ronny> jelmer: and of course - how is the performance ;P
<bialix> garyvdm: thanks
<bialix> garyvdm: but it's better to not use bencode improvements
<bialix> I have another regression with bzr 1.11
<garyvdm> Sorry - I don't understand
<bialix> wait a sec
<Tak> kfogel: looks good to me
<bialix> garyvdm: http://pastebin.com/m20409afe
<kfogel> Tak: thank you!
<bialix> garyvdm: I'm fixing this
<garyvdm> bialix: Ok - Thanks
<jelmer> ronny, it's pretty bad at the moment, but I'm working hard on fixing that
<bialix> but another one problem bother me
<jelmer> ronny, as is the author of pyrite (we're merging some of the code we have in common)
<bialix> garyvdm: try to simply press OK in te password dialog when accessing lp:
<ronny> pyrite?
<ronny> jelmer: btw, can it be possible to add custom object types later?
<jelmer> ronny, a Python re-implementation of Git
 * ronny needs more than commit/tag/blob/tree
<jelmer> ronny, completely (including command-line, etc)
<jelmer> ronny, yeah, sure
<bialix> I'm every time got: http://pastebin.com/m2f2d9bdd
<bialix> spiv is not here I guess
<jelmer> ronny, they're already separate classes at the moment, the only thing left to fix would be allowing registration of new types (type int -> class is in a dictionary at the moment)
<bialix> spiv: when you awake, can you comment on this: http://pastebin.com/m2f2d9bdd
<ronny> hmk
<bialix> spiv: it's when we passing empty string instead of password while accessing lp branches
<bialix> garyvdm: but when I do the same in the console I don't have such traceback
<jelmer> ronny: what sort of custom objects are you looking at adding?
<ronny> jelmer: want to split up mime messages and stuff like vcs checkouts
<ronny> also i need object lists
<bialix> garyvdm: what is your unfinished plans for 0.9.7? bzr 1.12 should be released next week, I need to be ready to release 0.9.7 in time wit rc1
<garyvdm> bialix: just regression fixing.
<garyvdm> bialix: I'm spending alot of time on lp:~qbzr-dev/qbzr/graph-refactoring - That can land after 0.9.7
<bialix> yes please
<bialix> garyvdm: we have something urgent?
<ronny> jelmer: basically i want more object tpyes to deal with backups on a higher semantic level
<jelmer> ronny: For anyvc, or is this for something entirely different?
<ronny> jelmer: different
<ronny> jelmer: i want a nice neat backup tool and remote syncable mailbox
<jelmer> ronny: Ahh
<garyvdm> bialix: what is that?
<ronny> jelmer: ald blobs alone aint nice enough
<bialix> sorry, do we have something urgent to be done before bzr 1.12 released?
<garyvdm> bialix: no.
<bialix> good
<jelmer> ronny: new object types won't be propagated by "regular" git though (not sure if that's what you intended to do)
<garyvdm> bialix: sorry : bug 325873
<ubottu> Launchpad bug 325873 in qbzr "Dbl Click on file in qbrowse does not open qcat window." [Medium,Confirmed] https://launchpad.net/bugs/325873
<garyvdm> I'll squash it now.
<bialix> um, ah
<bialix> it has one duplicate https://bugs.launchpad.net/qbzr/+bug/323535
<ubottu> Launchpad bug 323535 in qbzr "Crash when tryng to view a file." [Undecided,New]
<ronny> jelmer: i dont care for regular git in that case
<ronny> jelmer: btw, does the implementation allow for multiple concurrent writers?
<jelmer> ronny, in theory, yes (all writes should be atomic)
<ronny> in practice ?
<bialix> garyvdm: re your extdiff patch. what branch/version of extdiff plugin you're using/testing on?
<garyvdm> difftools plugin?
<jelmer> ronny, haven't stress-tested it yet
<bialix> yep
<ronny> jelmer: the code looks slow
<ronny> jelmer: im thinking about implementing it in vala
<garyvdm> bialix: lp:bzr-difftools rev 41
<jelmer> ronny, the code hasn't been optimized yet, that's what I'm working on now. The delta resolving / delta basis cache is the main thing that needs to be fixed
<bialix> ok
<jelmer> ronny, if you're going to work in vala, libgit is probably a better choice
<garyvdm> bialix: ver 0.91 if that means anything.
<bialix> I need to write something in the news
<ronny> jelmer: not so sure - need to see if it actually can handle object types
<bialix> I mean for announce
<LarstiQ> evening
<jelmer> ronny, I think it would require some trivial patch, that could go upstream
<jelmer> yo LarstiQ
<LarstiQ> yo jelmer, ronny, bialix
<bialix> yo LarstiQ!!!
 * bialix hopes "yo" is respectable word
<AmanicA> yo is cool
<bialix> yo AmanicA!!!
<AmanicA> yo yo alexander
<bialix> :-D
<ronny> yo LarstiQ
<ronny> jelmer: i think a gobject based implementation of git would help
<jelmer> ronny, what's stopping you ? :-P
<ronny> i would be able to use thigns like quarks, dataches and other fun things
<ronny> quarks = atomic strings reduced to a unique integer
<LarstiQ> bialix: I doubt it is fit to address the queen with, but it's perfectly fine for me :)
<Lo-lan-do> Depends on the queen maybe.
 * jelmer away for food, back later
<santagada> kfogel: theres a lather on your BzrForEmacsDevs
<ronny> bbl
<kfogel> santagada: "lather"?
<santagada> yep
<kfogel> santagada: er, do you mean a sort of froth?
<jelmer> Lo-lan-do, I figured out the bug you reported wrt slowness
<kfogel> Because that's not good for my computer :-).
<Lo-lan-do> jelmer: \o/
<santagada> kfogel: I never saw that before... It was supposed to be a later I think
<bialix> LarstiQ: fine
<kfogel> santagada: wow, I'm totally not understanding
<ronny> jelmer: i need any docs availiable on the git repo format evolution
<ronny> brb
<santagada> kfogel: wasn't you that posted the link to http://www.emacswiki.org/emacs/BzrForEmacsDevs
<garyvdm> bialix: I think that bug 307270 might be related to the problem I was having with ftp passwords in qbzr
<santagada> ?
<ubottu> Launchpad bug 307270 in qbzr "password prompt + empty password = traceback" [Low,Confirmed] https://launchpad.net/bugs/307270
<bialix> Gary, hmm
<kfogel> santagada: yes, I posted that
<kfogel> santagada: what I posted was actually:
<garyvdm> bialix: I'll do some debuging
<kfogel> http://www.emacswiki.org/emacs/BzrForEmacsDevs#Regulars
<santagada> kfogel: so, there is a type in there s/lather/later
<kfogel> santagada: aaaaah
<kfogel> thank you
<santagada> typo
<bialix> garyvdm: because you're working on Linux too, may I ask you about PPA?
<bialix> luks: are you here?
<garyvdm> bialix: Sure - I don't know if I will be able to answer
<bialix> garyvdm, luks: our PPA still has only 0.9.5, https://launchpad.net/~qbzr-dev/+archive/ppa
<santagada> kfogel: and if you want some inspiration to work more on the page I can point you to a kind of the same document for python, its on http://www.python.org/dev/peps/pep-0374/
<Necoro> does "bzr pull" does the right thing on bound branches?
<garyvdm> bialix: Ah - I've never built a deb before - I guess now is a good time...
<Necoro> or should one use "bzr up" instead
<bialix> I'm mostly indifferent on this, because I'm windows guy and because I know how to run from sources, but it seems important for hardcore ubutu users
<Necoro> if it is the latter, the EmacsForBzrDevs page should be corrected ;)
<bialix> maybe luks can provide some instructions
<garyvdm> bialix: Cool - I will address this.
<kfogel> santagada: that's great, thank you
<bialix> garyvdm: Great!
<kfogel> Necoro: it does
<Necoro> kfogel: ok - I tested it ... it does as long as you used "bzr branch && bzr bind" - using only "bzr checkout", it won't work except you are giving the branch again
<kfogel> Necoro: sure.  The recipe uses branch, not checkot.
<kfogel> checkout
<bialix> AmanicA: I'm trying to implement new layout for scmproj control dir. I'm not sure how to detect that remote branch (w/o WT) is our control dir actually. Any ideas?
<Necoro> kfogel: I know ;)
<kfogel> Necoro: (I've been using that model for bzr code, and for bkrpr development, and other things, so it is tested)
<Necoro> kfogel: any particular reason, why you are not using co && up? or is it just to keep the amount of commands to learn down?
<kfogel> Necoro: I've never used them in bzr myself.  I'm not sure when to use them (as opposed to branch / merge / pull).
<Necoro> ;) ok
<LaserJock> anybody have issues with latest bzr-svn from ~bzr PPA?
<Tak> imo there's never a good reason to use co/up with bzr
<LaserJock> all of my branches with updates say that the branches have diverged
<LaserJock> if you want to keep a SVN-like workflow co/up is nice
<Tak> if you want to keep a svn-like workflow, why are you using bzr? ;-P
 * bialix sometimes thinks this channel should be called #bzr-svn :-P
<LarstiQ> Tak: it's a valid way to work.
<LaserJock> Tak: people don't always have a choice
<Lo-lan-do> Tak: Local branches while cooperating with others who don't do bzr.
<LaserJock> some people like SVN's workflow but aren't allowed to use SVN
<Lo-lan-do> Also, merge tracking, disconnected work, all that.
<LarstiQ> Tak: also, trunk being a checkout usually fits well imo.
<LarstiQ> LaserJock: see UPGRADING in bzr-svn source, jelmer said he would incorporate that into the packaging for the next upload
<LaserJock> LarstiQ: what does that mean?
<Tak> that was a rhetorical question...
<LarstiQ> LaserJock: it means 0.5 uses a different svn-bzr revision mapping by default.
<LaserJock> LarstiQ: can I use it with the older version of bzr-svn?
<Lo-lan-do> No, which is why you should read that UPGRADING file.
<LarstiQ> LaserJock: yes, you can set 'default-mapping = v3' in ~/.bazaar/bazaar.conf or ~/.bazaar/subversion.conf
<bialix> garyvdm: look at recent thread about password bug in bzr.dev ML
<LarstiQ> LaserJock: but that won't gain you any of the advantages
<LaserJock> LarstiQ: the problem is, I use multiple bzr/bzr-svn versions on the same branches
<LarstiQ> LaserJock: that is not a problem per se
<LaserJock> bzr is hard enough with backwards compatibility as is, having to watch bzr-svn versions to kinda sucks
<etenil> Hi there
 * LarstiQ uses multiple bzr-svn versions against the same svn paths
<LarstiQ> LaserJock: well then, I suggest you set that default-mapping
<LaserJock> LarstiQ: you use then on the same bzr branch?
<etenil> is branching a project the same as unbinding a checkout?
<etenil> I started working on a checkout, but don't want to commit back to the trunk. Can I just unbind my checkout and make it a branch?
<LarstiQ> LaserJock: no, I communicate via svn
<Necoro> etenil: yes
<LarstiQ> etenil: yeah
<LarstiQ> etenil: you could also use `bzr reconfigure`
<LaserJock> LarstiQ: ah, see that's my problem, I'm working on the same branches with multiple bzr/bzr-svn versions
<etenil> ok
<etenil> thanks a lot guys
<etenil> +
<LarstiQ> LaserJock: bzr-svn talks to svn.
<LaserJock> LarstiQ: sometimes one version will do something that "breaks" the branch for the other version
<LaserJock> LarstiQ: right, but different bzr-svn versions using the same branch to talk with svn sometimes gives troubles
<LarstiQ> LaserJock: if you keep the resulting bzr branches from different bzr-svn version seperate, you have no divergence.
<LarstiQ> LaserJock: that I haven't experienced yet.
<garyvdm> bialix: My ftp problem - it seems like it's nothing to do with qbzr.
<jelmer> LarstiQ, LaserJock: Only because of bugs in older bzr-svn versions
<bialix> ah
<LaserJock> well, I don't want to keep different bzr branches
<garyvdm> bialix: I'm going to try somthing with bug 307270
<LaserJock> that's kinda silly to have multiple branches of the same exact thing
<ubottu> Launchpad bug 307270 in qbzr "password prompt + empty password = traceback" [Low,Confirmed] https://launchpad.net/bugs/307270
<bialix> garyvdm: I'd start to look at bzrlib CLI code at first
 * bialix heh
<LaserJock> ok, so can I just merge these branches and it'll "Just Work"?
<LaserJock> or should I just start over and rebranch
<LarstiQ> alas, LaserJock is gone
<jam> ls
<jam> hey all
<GaryvdM> Hi jam
 * fullermd waves at jam.
<mwhudson> morning
<bialix> hi jam
<jam> hi bialix
<jam> I don't think this has to do with qbzr anymore
<jam> try doing "bzr pull lp:qbzr"
<jam> versus just doing "bzr pull"
<jam> The former also gets the traceback for me
<bialix> jam, GaryvdM trying to debug this problem
<beuno> jam, hi, do you know how I can avoid getting into this situation?  http://paste.ubuntu.com/114010/
<jam> beuno: well, you renamed all of them
<jam> at least here where the encoding isn't hiding things:
<jam> Autobus 2 pisos ingl?s
<jam> != Autobus 2 pisos ingle?s
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<jam> beuno: I'm guessing you are on Mac OS
<jam> doing a checkout from someone who used linux
<jam> and on linux they checked in a file with e + accent
<beuno> jam, windows
<jam> which is a single char
<jam> or windows
<jam> doesn't matter
<beuno> well, actually, yes, it was committed on linux
<jam> on linux or windows e + ' is a single char
<jam> on Mac, e + ' is 2 characters
<jam> (mac *conveniently* renames files for us)
<beuno> well, actually, yes, it was committed on linux
<jam> are you on windows now?
<beuno> nope
<jam> As that would be unexpected behavior
<jam> you are on Mac now, right?
<beuno> in brazil, 400km away from the rpnolem  :)
<beuno> er, problem
<jam> so the *problem* is that Mac OS automatically renames files with "combining characters" for us
<beuno> right
<jam> when everyone else just leaves them alone
<Lo-lan-do> jam: Actually, I think everyone else converts to one combined character.
<Lo-lan-do> From what I've read, Linux and Windows automatically rename files to the canonical form A, Mac OS renames to canonical form B.
<Lo-lan-do> (Replace A and B by their actual names)
<beuno> jam, so no way around it?
<Peng_> Lo-lan-do: Composed and decomposed?
<Peng_> Or something.
<Lo-lan-do> Peng_: Something like that, yes.  So that would be forms C and D :-)
<Peng_> "Decomposed" sounds too zombie.
<jam> Lo-lan-do: from my experiments
<jam> linux and windows do nothing
<jam> but the standard usage when someone is typing is
<jam> NFC
<jam> (which is also the XML standard)
<jam> and Mac decided on a variant of NFD
<jam> (I think it is close, but not exactly NFD)
<jam> beuno: you could use a really old version of bzr with an old format repository and working tree, back when I actually tried to make that sort of thing work
<jam> alternatively, rename all of the files manually
<jam> ( I think cut & paste will work here)
<jam> commit it
<jam> and then when they update on Linux all of the files will be in NFD
<beuno> jam, I'll start renaming it then  :)
<jam> note that on Linux and Windows, NFD forms often look like crap
<jam> depending on your Unicode implementation
<jam> on Windows you tend to get "e[]"
<jam> that may be better in newer versions
<jam> it was the case in XP, IIRC
<jam> Eventually we might be able to take the "case-insensitivity" work that mhammond has worked on
<beuno> no matter, it'll teach people to stop using freaking accents
<jam> and apply it to unicode normalization
<jam> at one point I had been making things work by assuming everywhere != Mac was NFC
<jam> and then translating 'on-the-fly'
<GaryvdM> baltix: I'm going to make the SubprocessUIFactory raise a KeyboardInterrupt if the user canceled, and in the main process, not call the normal abort, but just clear the process queue.
<jam> the problem was that it turned out that Windows liked to used mixed encodings
<jam> IIRC
<jam> GaryvdM: I think qbzr is fine
<jam> GaryvdM: "bzr pull lp:bzr" gives the same "toomanyconnections" traceback
<jam> It has to do with "read_mergeable_from_url", I believe
<GaryvdM> baltix: Then we won't see that traceback if the user presses cancel - only if they press ok with blank password
<LarstiQ> GaryvdM: do you mean bialix instead of baltix?
<jam> ah, I've tracked it down
<jam> read_mergable_from_url raises an exception, but still populates the "possible_transports" list
<GaryvdM> jam: if you "bzr pull lp:bzr" and press ctrl-c you don't get the traceback - qbzr should do that if you press cancel in the ui.
<jam> the exception is trapped at a higher level
<jam> GaryvdM: sure with ^C you could just raise KeyboardInterrupt in the client
<GaryvdM> LarstiQ: Yes - thanks.
<jam> but just hitting "<enter>" the bug is in bzr
<bialix> GaryvdM: with Cancel we don't have any problem now
<bialix> only with blank/incorretc password
<bialix> I guess transport raises some error when it cannot connect?
<GaryvdM> bialix: Ah - Ok - then I'm not going to make that change.
<bialix> jam: yes, you're right about ...mergeable
<jam> bialix: I'm posting a fix
<bialix> so it's bzr bug then
<jam> the exception is bzr, yes
<bialix> jam: thank you very much!
<bialix> Gary: jam said it's the bug in bzr itself
<garyvdm> bialix: Yes - but I thought that we went handling the cancel correctly.
<bialix> sorry?
<bialix> garyvdm: I guess we do it correctly, is it not?
<garyvdm> bialix: Yes
<bialix> ok
<jam> garyvdm: translating ESC in the qbzr dialog into ^C in the client seems reasonable to me
<garyvdm> jam: We do that by sending a SIGINT from the main process.
<jam> k
<garyvdm> jam, bialix: Still, might be better to raise KeyboardInterupt in the sub process. The sub process allready knows if the user pressed ok or cancel, and by doing it that way we rule out any delay in the signal being received.
<bialix> jam: can you suggest most efficient way to detect is remote branch (without WT) has some specific file?
<jam> bialix: something like:
<jam> remote = Branch.open(location)
<bialix> garyvdm: I don't follow. Is not we already do this?
<jam> remote.lock_read()
<jam> rt = remote.repository.revision_tree(remote.last_revision())
<jam> rt.path2id(filename)
<jam> if that is None, then the path doesn't exist
<poolie> hello jam, bialix
<kfogel> santagada: "lather" is correct there
<jam> hi poolie
<bialix> hello poolie
<kfogel> santagada: "lather, rinse, repeat" is a stock phrase meaning to go through the same cycle again; it refers to washing clothing.
<bialix> jam: thanks
<bialix> I suspect something about inventory
<garyvdm> bialix: No - at the moment, the main process writes to the stdin, and then sends SIGINT on unix and the event on Windows
<jam> kfogel: I thought it had to do with shampoo
<jam> since they generally say exactly that on the bottle
<jam> which is an infinite loop
<jam> :)
<jam> or at least, they used to
<fullermd> That's why it takes me hours to wash my hair.
<bialix> garyvdm: what's wrong then?
<kfogel> jam: oh, wait, you're right
<jam> fullermd: until you pass out ?
<Lo-lan-do> Until there's no shampoo left?
<fullermd> Well, eventually you run out of shampoo...
<bialix> :-D
<fullermd> That qualifies as a NMI and breaks the loop   :p
<garyvdm> bialix: There may be a delay in the signal/event being received, and so the sub process might do more than necessary.
<bialix> NMI?
<garyvdm> http://en.wikipedia.org/wiki/Non-maskable_interrupt
<garyvdm> Had to look it up myself :-)
<jam> fullermd: I would think passing out would also qualify as an NMI
<bialix> lol, hardware things, I like it
<poolie> jam, want to talk?
<bialix> garyvdm: you has recently fixed the problem with cancel (revno 595)
<fullermd> Depends on whether the shower curtain slows you before your head hits the tile...
<garyvdm> bialix: It work, but it can be better.
<bialix> garyvdm: if subprocess waits for the password I don't think it will do more than that
<bialix> but not worse for win32 please!
<bialix> :-)
<garyvdm> bialix: Currently we write the qbzr:GETPASS: message to the stdin before we send the event.
<bialix> garyvdm: yes
<garyvdm> bialix: I'll make sure it's better :-)
<bialix> garyvdm: ok :-)
<bialix> just a thoughts: why bzr-gtk is not released anymore?
<bialix> it reached the top?
<ronny> re
<santagada> kfogel: living and learning.... I never heard that expression before, only "rinse and repeat"
<ronny> hmm
<ronny> back to python
<ronny> jelmer: anything i can do for dulwich?
<bialix> garyvdm: we can send the event before we send the bencoded message, maybe you have in mind this?
<garyvdm> bialix: I think it will be much more reliable to raise the KeyboardInterupt in the subprocess if accepted == False
<bialix> garyvdm: do you mean after receiving bencoded string?
<garyvdm> Yes
<bialix> please, don't use accepted == False
<ronny> jelmer: how do legacy/new style git objects work out?
<bialix> just `not accepted`
<garyvdm> bialix: Yes
<bialix> garyvdm: I think I understand your intent better now, thank you for explanation
<garyvdm> bialix: I'm going to also try fix bug 325924 before we release
<ubottu> Launchpad bug 325924 in qbzr "TooManyConcurrentRequests with traffic reporting for smart media." [Medium,Confirmed] https://launchpad.net/bugs/325924
<jelmer> ronny: They should work; I've never encountered them though, James implemented them.
<ronny> oO
<bialix> ok
<ronny> jelmer: whats the difference?
<jelmer> ronny, a different object header afaik
<bialix> jelmer: I'm just curious: what is the status of bzr-gtk now?
<ronny> jelmer: what james did implement them?
<ronny> ie is he here
<jelmer> ronny: In terms of todo-items, I think one of the things that needs more work is the index
<jelmer> ronny, it's james_w
<ronny> james_w: can you point me to some docs about the evolution ofthe git repo format?
<jelmer> ronny, I think the main docs are the C source files
<jelmer> bialix, pretty similar to what it was a while ago
<ronny> hmm :/
<bialix> jelmer: the lack of man power?
<jelmer> bialix: yeah
<bialix> I understand
<lifeless> jelmer: btw, branch.nick is likely what is connecting to the master
<lifeless> jelmer: its used for the window title, or used to be
<jelmer> lifeless, ahh
<jelmer> lifeless: That would indeed be it
<ronny> jelmer: the whole object parsing stuff in dunwich looks like please use c instead of python for 20x speedup
<bialix> we have similar bug in QBzr
<bialix> s/have/had/
<jelmer> ronny, the delta apply stuff can be optimized a lot by avoiding string copies
<ronny> hmm
<jelmer> ronny, plus, we don't do lru caching of delta bases yet (which git does)
<ronny> hmm
<jelmer> I'm not necessarily opposed to having a faster implementation in C
<jelmer> (or pyrex)
<lifeless> what about putting such a thing in libgit2 then linking to that from pyrex/CPython
<Jc2k> +1
<ronny> jelmer: i want to implement a semilar api in vala, then map to python via a binding or pybank
<Jc2k> libgit2 is horribly unfinished right now, i bet they'd love some help bringing it up to speed
<Jc2k> i started writing git in vala, but it turned into something else (git sucks for our 'personal cloud'/backup/sync/everything is versioned monster use case)
<jelmer> I wouldn't want to blame dulwich's current slowness on Python though
<ronny> jelmer: the parsing uses patterns that have much overhead in python compared to plain c
<xnox> Hello everyone! Is it possible to shelve something and then unshelve in another branch? All branches are in the shared repo.
<ronny> Jc2k: what was that again?
<lifeless> ronny: everything in python has a lot of overhead compared to C :P
<Jc2k> ronny: a project im working on which is still vaporware so im reluctant to talk about too much :)
<lifeless> ronny: its just that python doesn't stab you in the face 5 times a line of code
<jam> xnox: you can copy the .shelf directory around, but you could also "bzr merge --uncommitted ../other" and then bzr revert ../other
<Jc2k> ronny: theres a hackfest on it after FOSDEM where we are going to suck juergbi's brain out threw a straw :)
<ronny> when/where is fosdem again
<ronny> i might have to visit
<Jc2k> belgium, this weekend
<ronny> this already
<ronny> then i cant come
<Jc2k> sucks :(
<jelmer> lifeless, btw, I managed to implement a working BranchBzrDirInter
<lifeless> jelmer: nice
<jelmer> Looks like I can kill off all svn-* commands except for svn-import soon
<lifeless> jelmer: <3
<xnox> jam: thanks that's what I needed =D
 * xnox likes bzr better than git. Farewell my first ever learned vcs. You have served well git =D
<lifeless> back shortly, breaking ze fast
<Haffi___> Hi, how do I keep a file from being in source control in bazaar?
<garyvdm> Haffi___: bzr ignore filename
<Haffi___> Haha, figures
<Haffi___> I hate when programs have sensible command names, it makes me look dumb when I ask questions in IRC chatrooms...
<lifeless> poolie: also, I would really appreciate any comment on my fetch-history-bug-issue, I mailed about yesterday morning
<lifeless> poolie: groupcompress is basically blocked at the moment on that
<johnf1> I know I'm probably not the first to complain but I'm willing to put in time to make it happen. What is needed to ensure that the bzr PPAs always keep bzr,bzrtools and bzr-svn in sync?
<lifeless> johnf1: do you know how to do debian packaging ?
<johnf1> yes
<lifeless> johnf1: in our docs there is a ppa document
<johnf1> yep just read it
<lifeless> johnf1: start by reading that; I suspect that making sure the beta has matching versions leading up to a release will be a good start (catches bugs)
<lifeless> then when the release happens, if you wanted to do the uploads yourself, for instance, you could upload all of them
<lifeless> but some of the trouble is 'ppa'
<lifeless> because it doesn't act like a debian repo, apt will wedge and try to remove rather than waiting for the full upgrade to be possible
<johnf1> yeah it seems in a strange state at the motion eg beta has a bzrtool 1.11 package but only for dapper
<lifeless> johnf1: we would be delighted if you wanted to dive in and focus on this
<lifeless> there is a lp team you should join
<lifeless> to get upload accecss to the ppa
<johnf1> ok It's on my TODO list for this arvo
<lifeless> schweet
<lifeless> ping me anytime
<poolie> spiv, lifeless: thanks for the summary from yesterday, that sounded good
<poolie> i don't have any particular technical feedback
<poolie> i am also interested though in how we're organizing work on hpss
<lifeless> cool, it fitted so well I didn't expect anything :)
<lifeless> organising? hmm, you can do that :P
<jelmer> is there any equivalent to self.outf for stderr?
<poolie> it seems like it goes more than twice as fast when someone else is pairing with spiv
<lifeless> jelmer: trace.note I think
<poolie> jelmer: not directly; i guess generally you should go through trace
<jelmer> ok
<jelmer> lifeless, poolie: Thanks
<lifeless> well, this stuff is a refactoring I've been mumbling about onlist for about 9 months now
<lifeless> so we didn't do much guessing
<lifeless> certainly the serialisation work he's been doing is needed to line up with this, really just a case of glueing the two ends together now I hope
<poolie> jam, if you're still around
<poolie> should we leave kerguelen in its semi-broken state?
<poolie> or ask them to reinstall it?
<lifeless> igc: ping
<poolie> or, alternative, put it on a machine we completely control somewhere else
<poolie> inside vmware say
<jml> spiv: ping
<jml> spiv: Can you please update https://bugs.edge.launchpad.net/bzr/+bug/255292 ?
<ubottu> Launchpad bug 255292 in launchpad-bazaar "MemoryError/OverflowError in _read_info_file during branch unlock when pushing over SFTP" [Undecided,Incomplete]
<spiv> jml: ok
<mwhudson> btw
<mwhudson> i've seen that one a few times now
<mwhudson> not in a useful way, of course :/
#bzr 2009-02-06
<Odd_Bloke> So, anyone in here going to FOSDEM?
<bartzitz> hello, i'm affected by this bug https://bugs.launchpad.net/bzr/+bug/319790 (can't unshelve my changes)
<ubottu> Launchpad bug 319790 in bzr "bzr unshelve crashes losing all changes" [Medium,Confirmed]
<bartzitz> i have a shelf file and my changes are visible there
<bartzitz> but i can't decrypt the syntax
<bartzitz> help, anyone?
<jfroy|work> spiv: branches to address URL escaping in bzr and loggerhead have been submitted. Thanks again for your input last week.
<spiv> jfroy|work: you're welcome!
<lifeless> bartzitz: its a binary file these days, it can be extracted using bzrlib
<lifeless> bartzitz: does 'unshelve --dry-run' work ?
<bartzitz> as far as i can see it's not completely binary, i mean i can see snippets with my shelved changes
<bartzitz> i reaaly need to quickly recover it
<bartzitz> wii try --dry-run now
<bartzitz> it shows a progress bar (something is going on). but in the end the same message: bzr: ERROR: No such file: None
<lifeless> bartzitz: I'm just looking at the bug now
<bartzitz> lifeless: ok thanks, i'll wait
<lifeless> bartzitz: reproduced, so I can investigate
<lifeless> spiv: ping
<lifeless> pdb bailing worse :(
<lifeless> abentley: ping
<lifeless> abentley: need some insight into transform
<spiv> lifeless: ouch
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/319790
<ubottu> Launchpad bug 319790 in bzr "bzr unshelve crashes losing all changes" [High,Confirmed]
<lifeless> follow my recipe at the end
<spiv> lifeless: ok
<lifeless> with BZR_PDB=1 and bzr.dev
<lifeless> then do
<lifeless> bt
<lifeless> list
<lifeless> for me, that gave be a backtrace from pdb :P
<lifeless> spiv: also, do you want to get together today?
<lifeless> I don't know if you saw, but I'd kind of like to
<bartzitz> lifeless: bzr.dev, development version you mean?
<lifeless> bartzitz: yes, it has the bug still
<lifeless> bartzitz: first thing in confirming, make sure its not fixed already :)
<bartzitz> lifeless: i see. i'll have to compile it then
<lifeless> bartzitz: hang on
<lifeless> bartzitz: you don't need to do anything till I have a fix for you
<bartzitz> lifeless: ok
<spiv> lifeless: gar, it seems to be a bug in my workaround :(
<spiv> lifeless: ok, trivial fix for the pdb issue:
<spiv> lifeless:
<spiv> -                p.curframe = p.stack[p.curindex]
<spiv> +                p.curframe = p.stack[p.curindex][0]
<spiv> (in bzrlib/commands.py, of course)
<lifeless> thanks spiv
<lifeless> spiv: now, the other issue :)
<lifeless> spiv: shall we sprint?
<lifeless> bartzitz: its just deletes; working on a fix
<bartzitz> lifeless: thanks a lot, i have some critical stuff in there
<poolie> (out to lunch)
<spiv> lifeless: the weather is making me disinclined to move, let alone go out and about ;)
<lifeless> spiv: ok
<spiv> It would be good to get together again soon though.  How about Monday?
<lifeless> spiv: I could pop up if you like
<spiv> (IIRC the weather is supposed to be kinder by then...)
<lifeless> re Monday I'll need to check with Lynne
<spiv> I'll need to check with Mary too, but IIRC she'll be at uni that day.
<spiv> So here would be fine.
<mxpxpod> what is the difference between the shelve/unshelve in bzrtools and the one that's included with bzr?
<lifeless> mxpxpod: the bzrtools one predates and isn't as capable
<mxpxpod> lifeless: ok, thanks
<lifeless> mxpxpod: its deprecated now in fact
<mxpxpod> lifeless: so I should be using shelve and unshelve rather than shelve1
<lifeless> mxpxpod: yes
<mxpxpod> ok, thanks
<mxpxpod> how do you show the changes in something that's shelved?
<lifeless> mxpxpod: unshelve --dry-run
<lifeless> spiv: I
<lifeless> 'm a tad confused, are you saying your place is fine Monday, or today :)
<lifeless> crossed-threads I think
<lifeless> OTOH if its really hot, perhaps I should just stay here in my airconditioned room :)
<spiv> lifeless: Monday
<mxpxpod> lifeless: is there a way to see the diff output of --dry-run?
<lifeless> mxpxpod: I'm not sure
<mxpxpod> lifeless: ok
<spiv> lifeless: I don't have air con, so you probably do want to avoid here today ;)
<lifeless> mxpxpod: if you can't figure one out, file a bug ?
<mxpxpod> alright, thanks
<lifeless> bartzitz: I've figured out the api for shelve enough to do a low level unit test now, which means the next thing is the actual fix
<bartzitz> lifeless: great
<lifeless> jam: around?
<lifeless> vila: or you ?
<jelmer> looks like ohloh will be having bzr support soon \o/
<jelmer> lifeless, could pqm be stuck atm?
<beuno> jelmer, where have you read this?
<jelmer> beuno, talking with one of the ohloh folks
<beuno> jelmer, awesome
<lifeless> jelmer: its quiesced; as per the mail on bazaar@
<jelmer> lifeless: ah, sorry - must've missed that
<mwhudson> jelmer: cool beans
<lifeless> whats cool?
<mwhudson> ohloh
<lifeless> oh right
<fullermd> No, ohloh.
<lifeless> someone should setup ohlol
 * lifeless looks at fullermd
<fullermd> I'm working on ohhai first.
<mwhudson> ohrly etc
<lifeless> with its sister site ohbai?
<mwhudson> because i'm lazy
<fullermd> ohbai is replacing 401 in HTTP/2.0.
<mwhudson> how should i encode a filename in a content-disposition header?
<mwhudson> as i would for a url?
<lifeless> iIRC yes
<igc> hi all
<lifeless> I think its also come up in errata
<lifeless> http://www.ietf.org/rfc/rfc2183.txt
<mwhudson> yeah just found that one
<mwhudson>    Current [RFC 2045] grammar restricts parameter values (and hence
<mwhudson>    Content-Disposition filenames) to US-ASCII.
<lifeless> well
<lifeless> URL's are US_ASCII too
<mwhudson> true i guess
<lifeless> gimme a sec to page this in
<mwhudson> well, don't want to distract
 * mwhudson watches ff save a file called "a%20b"
<lifeless> did you find http://www.ietf.org/rfc/rfc2184.txt
<mwhudson> ah no
 * mwhudson reads
<lifeless> 2183 says '2184 for non-ascii params
<mwhudson> huh
<bartzitz> lifeless: don't want to bother you, but how the unshelf fix is going? i'll have to find other solution if it's going to take long
<mwhudson> so for the case i'm interested it most immediately (a filename containing spaces), all i have to do is put the filename in quotes
<mwhudson> oops
<lifeless> bartzitz: in progress
<bartzitz> lifeless: thanks
<lifeless> bartzitz: its a bit of the code base I'm not very familiar with, and noone that is on is either
<mwhudson> ow
<mwhudson> loggerhead can't even _render_ a link to a file containing non-ascii
 * mwhudson stabs python
<fullermd> Wuff.  Hour 38 to 'check' bzr.dev.
 * fullermd remembers why he doesn't do it very often.
<lifeless> fullermd: wtf
<lifeless> oh yeah
<lifeless> see my mailabout faster check ?  :P
<lifeless> bartzitz: ok, its PreviewTree missing some api's
<lifeless> bartzitz: I think>. Anyhow, am progressing
<mwhudson> >>> inv['TREE_ROOT'].children.keys()
<mwhudson> ['a b', 'serve-branches.log', u'\xe9']
<mwhudson> this isn't what i was hoping to see, btw
<mwhudson> is there some way i can get this information in a type-consistent way?
<lifeless> mwhudson: what information
<mwhudson> lifeless: the list of files in a directory
<mwhudson> hm, maybe i'd be better off using revtrees rather than inventories directly?
<lifeless> that looks type consistent to me, modulo python suckage
<lifeless> you can use inventories if you want, but trees are the recommended interface
<mwhudson> the way to avoid python suckage is to be consistent about using unicode or bytestrings
<lifeless> oh yes
<lifeless> and we are :)
<lifeless> I will wager your test code isn't consistent or something like that
<mwhudson> only using unicode when there are high-bit set characters is not consistent in my book
<lifeless> completely agree
<lifeless> we decode('utf8') all the paths coming out of dirstate
<lifeless> and we take what we get from the xml parser in pythons standard library
<lifeless> don't assume what you are seeing is bzrlibs fault
<mwhudson> http://pastebin.ubuntu.com/114346/
<mwhudson> well, maybe not
<mwhudson> anyway, trees seem saner, so i'll go that way i guess
<lifeless> I will bet you that the xml decode is what is giving the ascii strings there
<lifeless> I guess I'm saying
<lifeless> don't go rewriting a bunch of code to avoid this
<lifeless> as RevisionTree answers directly from inventory anyway
<lifeless> it won't be saner in this respect
<mwhudson> hm
<mwhudson> it seems list_files is
<mwhudson> but walkdirs() isn't
<lifeless> why does it matter to you - if its a path in bzrlib, treat it like its unicode. Unless you explicitly use a utf8 API that is
<lifeless> bartzitz: I have bad news for you
<lifeless> bartzitz: I'm going to need to consult with the author off this code to get a proper fix; I don't understand some of the intent
<lifeless> bartzitz: though I'm going to persevere a bit more
<jfroy> quick question: is there a command to switch an existing repo to having no trees by default
<jfroy> or do I need to touch .bzr/repository/no-working-trees ?
<lifeless> for now, touch it
<lifeless> there is a patch in progress
<jfroy> ok
<jfroy> I just don't like (too much) to rely on implementation details :p
<jfroy> and thank you :)
<lifeless> bartzitz: fixed
<lifeless> bartzitz: just apply the patch from the bug report to your local copy of bzr
 * igc lunch & medical stuff - bbl
<lifeless> jelmer: you really should push your improvements to bzr-hg and bzr-git trunks :P
<KhaZ> Hi!  Quick question about bzr-hg, if anyone's familiar with it.  Are you supposed to use bzr pull [url-to-your-hg-path] to populate it?  or bzr branch, or which?
<bob2> zing!
<lifeless> KhaZ: bzr init; bzr pull
<lifeless> KhaZ: if you do 'bzr branch' it will create a hg branch in the output ;)
<KhaZ> Ah.  Heh, I do want to avoid that. ;)
<KhaZ> I do dig that launchpad website.  No chance that the software driving that is open source, eh? :)
<spiv> KhaZ: It will be in July: https://dev.launchpad.net/OpenSourcing
<KhaZ> Oooh, neato.  I wonder if my work would be interested in that.
<KhaZ> Allowing we're around at that point, given all the bloody layoffs. :(
<lifeless> KhaZ: are you @ IBM/MS/Sun ?
<KhaZ> Hrmm.  I'm trying to use hg-bzr from jelmer's branch, and it's complaining about 'No module named foreign'.
<KhaZ> lifeless: No, Disney, technically.
<lifeless> oh cool
<KhaZ> Is 'foreign' something from Python, or something from a version of bzr that I don't have?
<lifeless> its a addin bzr has
<mwhudson> KhaZ: you probably need a newer bzr
<lifeless> jelmer wrote it as common infrastructure to bzr-hg/bzr-git/bzr-svn
<KhaZ> Hrmm. 1.9 isn't cool enough? :)
<lifeless> its been merged to bzr itself recently
<KhaZ> Ah, neat.
<lifeless> we're getting ready to release 1.12
<KhaZ> How recent?  1.10?  1.11?
<lifeless> so 3 months
<lifeless> 1.11 should be fine
<mwhudson> i think 1.11 is new enough
<KhaZ> OK.  Unmasking I will go.
<lifeless> igc: hi
<KhaZ> Hmm.  Still complains about not having a module named 'foreign' in 1.11.  Guess I need to go install it.
<mwhudson> can i dump the xml of an inventory somehow?
<lifeless> you may bzr.dev
<lifeless> *need*
<KhaZ> Is there an automated way to install bzr plugins?  Or do I have to do the download/extract/setup.py build/setup.py install?
<lifeless> mwhudson: yes but why
<KhaZ> Like the trunk?
<lifeless> mwhudson: I smell the need for a preimp chat
<mwhudson> lifeless: still infuriated by this unicode thing
<bob2> KhaZ: cd ~/.bazaar/plugins ; bzr co lp:bzr-something ; bzr whateveritdoes
<mwhudson> just want to confirm what's going on, not actually coding anything
<lifeless> KhaZ: most plugins just work by 'bzr branch lp:bzr-PLUGIN ~/.bazaar/plugins/PLUGIN
<KhaZ> Ah, awesome.
<lifeless> mwhudson: repository.get_inventory_xml
<lifeless> KhaZ: ones with C extensions will need more
<KhaZ> Nift.  Can I make 'aliases' in bzr, much like in hg with it's alias module?
<lifeless> mwhudson: or r.inventories.get_record_stream([('foo',), 'topological', True).next().get_bytes_as('fulltext')
<lifeless> KhaZ: yes
<KhaZ> Like, could I alias that bzr branch line to something like 'bzr install_plugin PLUGIN'?
<KhaZ> Hot diggity.
<KhaZ> Hrmm.  I take it there's more than sudo bzr branch lp:bzr-foreign /usr/lib/python2.5/site-packages/bzrlib/plugins/foreign tho?
<KhaZ> I do that, and it still complains about not having 'foreign' as a module.
<mwhudson> lifeless: get_inventory_xml worked thanks
 * mwhudson stabs the effbot
<mwhudson> >>> [e.get('name') for e in et.parse(StringIO(b.repository.get_inventory_xml(b.last_revision()))).findall('file')]
<mwhudson> ['a b', 'serve-branches.log', u'\xe9']
<lifeless> mwhudson: see above, not bzrlib
<KhaZ> lifeless: I take it you meant to send that to me
<lifeless> mwhudson: but you haven't answered my question
<lifeless> KhaZ: send what to you ?
<KhaZ>  < lifeless> mwhudson: see above, not bzrlib
<KhaZ>  < lifeless> mwhudson: see above, not bzrlib
<KhaZ> Oops.
<lifeless> KhaZ: no, I meant to send that to mwhudson
<KhaZ> Oh.  Apologies. ;)
<mwhudson> lifeless: so loggerhead blows up reasonably thoroughly when there are non-ascii names in the inventory
<jfroy> ouch
<mwhudson> lifeless: just related and slow paced digging related to that
<lifeless> mwhudson: are you treating the paths as unicode
<lifeless> mwhudson: or are you treating them as bytes
<mwhudson> lifeless: well so far mostly limping along ignoring the issue
<lifeless> I *know* you are getting bytes from the inventory, but what are you treating them as
<jfroy> mwhudson: I actually glanced over loggerhead's source today, and I did get somewhat worried that it didn't seem to really pay attention to using unicode internally and encoding only at the end
<jfroy> :|
<mwhudson> lifeless: deciding which is obviously somewhat related to fixing the problem :)
<lifeless> if you treat everything as unicode it should just work
<mwhudson> jfroy: hello, by the way :)
<jfroy> mwhudson: yo :)
<lifeless> KhaZ: run bzr with -Derror
<lifeless> KhaZ: and pastebin the result plase
<lifeless> *please*
<jfroy> lifeless: lol
<mwhudson> jfroy: loggerhead is going to become the focus of my work time for the next couple of weeks btw
<jfroy> interesting
<mwhudson> jfroy: so i should be able to fix all this rubbish up
<mwhudson> certainly, the intent of rendering is to produce a unicode string
<KhaZ> bzr -Derror just seems to send --help?
<jfroy> I've pushed a minor branch today to prettify URLs coming out of its templates (basically making it use bzrlib.urlutils instead of urllib, and I fixed up urlutils)
<jfroy> mwhudson: huh no :p
<lifeless> KhaZ: bzr -Derror $WHATEVER_YOU_WERE_DOING
<KhaZ> Oy. ;)  No need to yell!  (J/k!)
<jfroy> you want to work with unicode strings internally, then output utf-8 in the templates, or, if you're using a filename as a URL, encode the URL properly (the functions in urlutils will do that)
<mwhudson> jfroy: which is then encoded as it is sent to the client
<mwhudson> in utf-8, indeed
<jfroy> right
<jfroy> for what it's worth, BTW, buildbot equally blows up when there are non-ascii strings making it to its template engine :p
<lifeless> jfroy: mwhudson: Two things
<jfroy> I borked more than one of those with my properly spelled named :sigh:
<mwhudson> two facts (1) i am not a *complete* cretin when it comes to unicode handling (2) i am not entirely responsible for all of the code in loggerhead :-p
<mwhudson> it's also hot and the end of my work day, so i'm probably being a bit vague
<lifeless> the first things i that the encoding of content of user files is not well defined in bzrlib
<lifeless> so whatever you plan, understand bzrlib will only give bytestrings for that content.
<jfroy> lifeless: ah, that's a different problem, isn't it -- the file viewer, that is.
<mwhudson> lifeless: i think loggerhead copes vaguely well with this (well, non-explody) actually
<jfroy> the cheap way is probably to try to decode utf-8 internally, if that doesn't fail send it as utf-8 to the client, and if it fails encode as ascii with losses or something.
<lifeless> secondly, while we define all paths as unicode in the API, we find that this sucks performance wise; we are slowly [carefully, very carefully] migrating much of bzrlib to use utf8 everywhere
<jfroy> lifeless: interesting
<mwhudson> lifeless: right, i was vaguely aware of this
<mwhudson> lifeless: it seems that this has mostly affected working tree stuff so far?
<lifeless> jfroy: I won't get into a discussion about heuristics right now :P
<lifeless> anyway
<lifeless> python unicode -> 4 bytes per character, very slow
<jfroy> oh whoa, really
<lifeless> python utf8 -> 1 byte per char for most chars, much leaner and faster
<jfroy> UTF32 eh, that's pretty heavyweight
<lifeless> UCS4 I thihnk, specifically
<mwhudson> not really UTF :)
<jfroy> right
<jfroy> yeah
<jfroy> my mistake :|
<jfroy> In any case, I wonder why they decided to go with such a heavy representation.
<mwhudson> simplicity of implementation and speed of indexing
<mwhudson> i think
<jfroy> And yeah, cutting your memory usage for all paths, filenames and URLs by an average of 4 is going to be a win
<lifeless> its build time I think
<lifeless> anwyay
<lifeless> if you've ever done
<mwhudson> also the bytestring code is probably more optimized
<lifeless> python -c 'import cStringIO; print repr(cStringIO.StringIO(u"a").getvalue())'
<KhaZ> lifeless: http://pastebin.com/m4497eb3b
<KhaZ> Sorry about the wait; puppy needed to poop.
<KhaZ> OH.  foreign should be in the hg directory
<mwhudson> lifeless: shut it :)
<jfroy> lifeless: 'a' :p
<lifeless> jfroy: what platform are you on, and what python version
<jfroy> darwin 2.5
<lifeless> very interesting
<lifeless> KhaZ: excellent
<lifeless> KhaZ: yes, it should be
<KhaZ> Unfortunately now it barfs about not finding os.
<KhaZ> :(
<KhaZ> http://pastebin.com/m45e9b8a1
<lifeless> KhaZ: looks like a bug in jelmers branch of bzr-hg
<lifeless> file a bug :)
<jfroy> lifeless: what output were you expecting?
<KhaZ> Heh.  doing an 'import os' at the top of the file works fine.
<lifeless> $ python -c 'import cStringIO; print repr(cStringIO.StringIO(u"a").getvalue())'
<KhaZ> Well, it makes it take a damned long time. ;)
<lifeless> 'a\x00\x00\x00'
<KhaZ> Am I technically allowed to check into jelmers branch?  Or would jelmer kill me? (Or, less dramatically, would I be denied permissions?)
<lifeless> you would be denied
<KhaZ> Le sigh.
<lifeless> but
<lifeless> its a DVCS
<lifeless> you can create your own branch
<lifeless> in fact you ahve locally
<lifeless> so commit your fix
<KhaZ> Yeah.  I've got it local at least.
<lifeless> then do
<KhaZ> Yessir.
<lifeless> bzr push lp:~KhaZ/bzr-hg/fix-whatever
<lifeless> assuming you've setup an account on launchpad
<KhaZ> Ah crap. :(
<KhaZ> bzr: ERROR: exceptions.AttributeError: 'InventoryFile' object has no attribute 'find_previous_heads'
<lifeless> and given lp your ssh public key
<lifeless> jfroy: your build of python has either a fixed cStringIO, or uses utf8 internally
<lifeless> jfroy: this will depend on what python is using for its unicode string ops; I think its some system library it ends up depending on that determines this
<KhaZ> lifeless: How/when do these branches get merged?  Is there one maintainer for all this?
<jfroy> I never read the implementation of that module, but I'm surprised it'd be any different than that of other unix platforms
<jfroy> that's quite possible
<lifeless> jfroy: darwin is quite different
<lifeless> jfroy: cStringIO won't be different
<jfroy> Is it? Mac OS was very different, indeed. I know there's some massaging to build Python as a framework.
<lifeless> jfroy: but apple carry patches to python; they might have fixed it so that cStringIO.StringIO(unicodething) transcodes rather than reading the representation array
<jfroy> that's quite possible
<lifeless> jfroy: so yeah, either a cStringIO fix, or the representation arry is utf8
<lifeless> KhaZ: when you think the branch is ready you can create a merge proposal
<lifeless> just go to lp to your branch and click on 'propose for merging'
<jfroy> in any case, it doesn't really change the validity of the argument -- utf-8 is going to be more compact on average.
<lifeless> oh yes
<KhaZ> Interesting.
<jfroy> There's probably going to have to be a round-trip to unicode for NFC normalization on darwin
<lifeless> jfroy: which is why we are moving to it
<lifeless> jfroy: utf8 is unicode :P
<jfroy> I meant to the unicode type.
<jfroy> IIRC the unicodedata module works with unicode objects
<lifeless> jfroy: but yeah, when normalisation is needed, and we have utf8_bytestrings we need to either decode, which is a nonsense no-op on utf8 internal pythons, or have direct C access to something to normalise for us
<lifeless> jfroy: mwhudson: anyhow those were the two points; standardings on 'unicode' type strings is very slow in python, we learnt this late
<lifeless> don't start down the wrong path
<jfroy> I'm half surprised by that. I fully expected them to be slower, but not enough to not be willing to pay the cost.
<mwhudson> ah hah
<mwhudson> maybe i can blame paste for this
<jfroy> But 4 bytes per character, if indeed some implementations are using that, is overkill.
<lifeless> jfroy: you can see my test
<lifeless> jfroy: python on ubuntu/debian does
<lifeless> and I suspect redhat etc too
<KhaZ> Now, pardon my ignorance, but there's no other way to import an hg repository other than bzr-hg, yeah?
<lifeless> KhaZ: you can use fast-export
<mwhudson> KhaZ: there's fast-import based approachs
<jfroy> lifeless: I assume you are building a sub-class of str for this?
<mwhudson> the rage, it boils
<lifeless> jfroy: no, we are just careful to use hungarian names for variables, and we use str
<jfroy> lifeless: I'm not sure I like that too much, but I suppose if you're *very* careful.
<lifeless> jfroy: subclassing str would be terribly slow
<KhaZ> Huh.  What's fast-export/import?
<jfroy> I had in mind something like NSString / CFString which will vary their internal encoding based on what operations you perform on them and how they were initialized -- most of the time they never upgrade their internal representation to unicode.
<jfroy> lifeless: Ah I see.
<lifeless> jfroy: here's a data point to think about
<lifeless> jfroy: the history of bzr itself, has 3.3GB of raw text in the inventory metadata
<jfroy> *internal representation to USC2
<lifeless> jfroy: we do a huge amount of text processing
<jfroy> you don't need to convince me :p
<KhaZ> Oh, NEAT.  So if I understand correctly. bzr-fast-import basically sucks in a repository but doesn't worry about syncing back and forth?
<lifeless> KhaZ: right, its a great migration tool
<lifeless> its not as seamless but its been used very successfully by folk
<KhaZ> lifeless: Oh, perfect!  That's all I need.
 * mwhudson thinks about monkey patching urllib.quote with bzrlib.urlutils.encode
<lifeless> mwhudson: no
<mwhudson> thanks
<lifeless> mwhudson: send in a branch
<lifeless> urllib does need love
<mwhudson> lifeless: to cpython?
<mwhudson> won't help my 2.4 deployment
<jfroy> mwhudson: I did that :p
<jfroy> more or less
<mwhudson> jfroy: do you know what the status of this issue is? http://mail.python.org/pipermail/python-dev/2006-July/067248.html
<jfroy> https://bugs.launchpad.net/loggerhead/+bug/325974
<ubottu> Ubuntu bug 325974 in loggerhead "Use bzrlib.urlutils to provide prettier URLs" [Undecided,New]
<mwhudson> jfroy: i don't think that one will help the issue at hand though
<jfroy> probably not, if paste is using urllib internally
<mwhudson> right
<mwhudson> construct_url(environ, path_info=u'
<jfroy> I actually tried to patch in urllib in serve-branches during imports
<jfroy> before importing anything else
<mwhudson> \xe9') --> boom
<jfroy> the trick is urlutils.encode uses urblib.quote
<jfroy> hence, sadness ensued
<mwhudson> i guess we need to supply our own version of construct_url
<jfroy> if bzrlib's urlutils are fixed up to operate independently, then the monkeywrenching could be done
<mwhudson> (nice thing about paste: at least we can do this)
<jfroy> you're not supposed to ever give quote unicode strings :|
<jfroy> well, unicode objects
<jfroy> to not confuse things
<mwhudson> so i should encode as utf-8 first?
<mwhudson> ah that works
<jfroy> Ah, actually
<jfroy> http://bazaar.launchpad.net/%7Ejeanfrancois.roy/loggerhead/pretty-url/revision/265
<jfroy> I did 2 things
<mwhudson> of course, processing the resulting url fails horribly :)
<jfroy> put urlutils.escape(urlutils.unescape(...)) after request.construct_url
<jfroy> but also, in def app
<jfroy> urlutils.escape(urlutils.unescape(...)) self._url_base and self._static_url_base
<jfroy> def url() basically works with url_base to build URLs
<jfroy> and yeah, that will force _url_base to be a str object
<jfroy> since urlutils.encode encodes a unicode object to utf-8 before it hands it to urllib.quote
<jfroy> and then forces the output through str()
<lifeless> spiv: so, did my recap email help?
<KhaZ> Just reading up on the comparisons between hg and bzr.  I've read you can't checkout a single directory underneath a repository, but you can checkin based solely on a subdirectory.  Which is true for pulling?  Can you pull based only on a subdirectory?
<jfroy> AFAIK puling pulls changesets from the source branch, and thus, no.
<jfroy> *pulling
<KhaZ> Ah, nuts. :/
<KhaZ> That really irritated me about hg too.  Was hoping bzr was better about it. ;)
<jfroy> bzr is atomic
<jfroy> you can't have some subdirectory at revid xyz and the rest at abcd
<jfroy> that's an inconsistent snapshot of the branch history -- it's bad :p
<lifeless> KhaZ: its something I would like to make more flexible, and so would igc
<lifeless> atomic shouldn't mean inflexible
<KhaZ> *shrugs* I dunno.  I work with multiple hobby projects all in one repository.  Creating multiple repositories for my tiny applications would be bad too.
 * KhaZ nods at lifeless
<lifeless> KhaZ: well you can just use lots of seperate branches one per hooby project
<lifeless> KhaZ: branch and repo are disconnected in bzr
<KhaZ> I suppose that's true.  And seeing as how svn+ssh makes it all hidden anyways.  Never thought about that.
<mwhudson> jfroy: what's your interest in loggerhead/bzr if you don't mind me asking?
<jfroy> lifeless: how would you ever make that work? If directory B has new source that depends on new source in directory A to compile, then pulling only directory B will get you a broken branch / working copy (assuming that the changes in A and B were commited together)
<KhaZ> Would make the bzr st better too.
<lifeless> jfroy: of course
<KhaZ> jfroy: I agree, but in my opinion a user who asks for that is asking for user error.  But that's just the way my brain works with vcs's.
<mwhudson> jfroy: you clearly know a bit more about the practicalities of url generation/processing than i do, i hope you can stick around :)
<jfroy> mwhudson: sharing / browsing branches at work. an internal, mini-launchpad-while-waiting-for-launchpad-to-be-open-sourced
<lifeless> jfroy: but you're conflating what can go wrong with how the tool should behave
<mwhudson> jfroy: ah cool
<KhaZ> Oh neat.  So with bzr I have a separation between a 'repository' and a 'working directory'?
<KhaZ> hg kinda blurred the lines, or so I thought?
<jfroy> lifeless: I would personally not be willing to sacrifice changeset atomicity
<lifeless> jfroy: specifically, you'd track the revid per dir, and warn about old subdirs on status etc, and have the default to be to update everything
<jfroy> KhaZ: yes1
<jfroy> *!
<lifeless> jfroy: you'd still be atomic
<KhaZ> Hawt.  I like that.
<jfroy> lifeless: I suppose, but I don't like it.
<jfroy> atomicity means your working copy is at a specific revid of a specific branch, not kool-aid.
<jfroy> *no kool-aid.
<lifeless> jfroy: right, so you wouldn't need to use it :)
<jfroy> The next step would be being able to mix 2 or more branches in the same working copy.
<lifeless> jfroy: thats an asked for feature too; other more mature things like perforce and clearcase support that
<KhaZ> Heh.  Atomicity to me always meant that when you check in, it doesn't barf half way and end up with a half submit. ;)  Ahh, visual source safe, how archaic you now are.
<jfroy> directory A is using branch alpha at revid 123 and directory B branch beta at revid 2345, go go nightmare
<lifeless> jfroy: I think it would be a nightmare if it could ever happen accidentally, or without warning
<jfroy> I believe that giving people the ability to do it is just as bad.
<lifeless> jfroy: but there are plenty of valid use cases which people simulate with 'revert -r 123 directory_a' at the moment
<jfroy> That's why I don't like git -- it lets you do completely arcane things that will rear their ugly heads later on and beat you up
<mwhudson> well, woo, i can annotate a file called 'Ã©' in loggerhead
<jfroy> mwhudson: :)
<KhaZ> The ability to have different directories at different 'revisions' is supported by a lot of software, and in some cases, a lot of use cases too.  At work for instance we have a lot of artists who have their data at a higher revision than the code, because they just want to see their updates.
<lifeless> jfroy: they already have it, but bzr doesn't know that they are doing it well enough to help them or warn them
<jfroy> I suppose
<lifeless> jfroy: I really do appreciate the issues; and I certainly am not suggesting that we definitely do something to directly support this
<lifeless> but! it comes up a lot
<lifeless> and saying 'turn dir X into a nested branch' really isn't a good answer
<lifeless> its too big a hammer
<lifeless> and its the wrong sort of hammer for many cases
<jfroy> KhaZ: that doesn't make sense to me, in the sense that if an artist commits a new asset, the asset commit will increment the artist's revno by one.
<lifeless> KhaZ: in svn ?
<jfroy> The source code won't be "behind", it just won't be changed by that changeset.
<jfroy> lifeless: agreed
<KhaZ> lifeless: We use Perforce at work, sadly.
<lifeless> jfroy: I think the use case is 'source code behind trunk, changes to assets done to trunk'
<lifeless> jfroy: so there isn't a single revno for the whole tree on the artists disk
<KhaZ> jfroy: Sure.  Well our artists iterate a lot on their assets, and often don't want to upgrade to the latest development snapshot that we've checked in, as stuff just 'works' right then and there.
<poolie> lifeless: hi; can you tell me again the mail subject you especially wanted me to answer?
<lifeless> poolie: you did, last night :)
<lifeless> poolie: it was the on-track on
<lifeless> e
<KhaZ> Quick question, I've got my repo built now, but if I do 'bzr update', I get: bzr: ERROR: No WorkingTree exists for "file:///var/hg/repositories/eddie-bzr/.bzr/checkout/".
<KhaZ> How'd I dun' brokenated it so soon?
<lifeless> KhaZ: 'bzr checkout .' in that directory
<KhaZ> Oh.
<jfroy> KhaZ: I've been working with DVCSes for too long I guess. I my mind that just means an artist isn't pulling from the blessed master branch and commits to his or her local branch his or her new assets
<poolie> i thought you mentioned another this morning?
<poolie> hey but if that's all, i'm happy
<lifeless> the output from the converter is a little odd
<KhaZ> bzr checkout . = bzr: ERROR: Not a branch: "/var/hg/repositories/eddie-bzr/.bzr/branch/".
<lifeless> poolie: oh
<KhaZ> I think bazaar hates me.
<jfroy> and the artists could potentially have their own blessed central branch which they could update from time to time with the coder's blessed branch.
<jfroy> etc
<lifeless> KhaZ: look in the subdirs
<KhaZ> jfroy: Yeah, and I've never worked with DVCS (to my chagrin).  That's why I find this conversation so intriguing and so mind blowing. ;)
<lifeless> poolie: uhm, I mailed yesterday about fetch and old history
<jfroy> KhaZ: checkout == branch + bind
<lifeless> poolie: or wednesday maybe
<KhaZ> And to be honest, I wonder about DVCS and artist workflows.  Inability to merge makes me think artists should never use DVCS.
<jfroy> so the argument is a branch, and optionally a destination directory
<lifeless> KhaZ: bzr supports a central model too, which is roughly svn like
<lifeless> jfroy: there is a special case in checkout
<KhaZ> "Look in the subdirs"?  I've got .bzr, hg-export.status (not a dir) and 'master', whatever that is.
<jfroy> lifeless: when cwd is a branch?
<lifeless> jfroy: if you do 'checkout .' in a branch, you just build a tree
<jfroy> makes sense
<lifeless> jfroy: which is what a number of vcs do
<KhaZ> lifeless: Hrmm, interesting.  Can you 'mix' modes?  i.e, have a section of a tree that's 'central' and a section that's normal DVCS?
<lifeless> KhaZ: cd master
<jfroy> KhaZ: the idea is more to "bless" remote branches.
<lifeless> KhaZ: yes you can mix, but not like that :P
<lifeless> KhaZ: its a configuration for a given branch/working tree
<jfroy> People saying "OK, http://internal.example.com/bzr/master" is the master branch from which we'll ship.
<KhaZ> Right.  Interesting stuff.
<lifeless> KhaZ: just 'bzr checkout URL' rather than 'bzr branch URL', and when you commit it will go straight to URL rather than just locally.
<KhaZ> So is 'master' bzr lingo for 'trunk'?
<lifeless> KhaZ: its hg lingo
<jfroy> nope
<jfroy> well
<lifeless> KhaZ: you just converted from hg
<KhaZ> Ah.
<jfroy> it's entirely up to you :)
<jfroy> master, trunk, mainline, dev
<KhaZ> So I can rename that 'master' to 'trunk' or 'fred' or what have you?
<jfroy> pick what you prefer :)
<lifeless> yes
<lifeless> anyhow that master is probably your branch from hg
<jfroy> it's just the name of the branch / branch directory
<lifeless> cd to it and look at whats in it
 * mwhudson avoids thinking about content-disposition headers for now
<KhaZ> Nothing, but bzr update has it doing a lot of stuff. ;)
<KhaZ> So if I understand correctly, the directory above 'master' is the repo, and 'master' is just the working copy?
<jfroy> mwhudson: wait wait, isn't that a MIME header? Why would you care about that :p
<jfroy> KhaZ: master is the branch
<jfroy> a branch may or may not have a working tree. Generally, remote branches don't, to save disk space
<KhaZ> Man.  I've got to read up on this branch/repo differentiation again.  I've been playing with too many VCS lately.
<jfroy> a repository is, essentially, a "bucket of related changesets"
<jfroy> it's an optimization to avoid duplicating history data for branches with a common ancestor
<mwhudson> jfroy: it's an "often implemented" http header according to the http/1.1 rfc
<KhaZ> Ah, neat.
<mwhudson> we set it for download links
<KhaZ> So it's like the master branch, or something?
<KhaZ> Neat, so if I understand correctly, a repository will have zero or more branches, but a branch will always have a repo.
<jfroy> You'd store the "master" branch in a repository on the remote branch server, along other branches
<jfroy> KhaZ: no, branches can be standalone.
<jfroy> They can exist outside or inside a repository
<mwhudson> jfroy: does this look sort-of vaguely sane to you? http://pastebin.ubuntu.com/114424/
<jfroy> when they are created inside a repository, they delegate history storage to the repository. Otherwise, they store history data within themselves.
<KhaZ> jfroy: Right, but they have to reference a repository somehow, no?
<KhaZ> Oh.
<KhaZ> So they can be literally stand-alone.
<jfroy> KhaZ: right, if you move a branch outside of its repository (using mv say), you'll break it
<jfroy> yup
<KhaZ> At the point at which they store history data within themselves, are they essentially a repository at that point?
<KhaZ> Or is there still a difference between a 'stand alone' branch and a repository?
<lifeless> KhaZ: they get a .bzr/repository subdir
<jfroy> a repository is not a branch
<jfroy> you cannot branch or checkout a repository
<jfroy> a repository is merely a bucket of history data :p
<KhaZ> History as in deltas?  Or meta data about the deltas?
<KhaZ> Or both?
<jfroy> A branch can be either stand-alone, or stored in a repository, correct.
<jfroy> both
<jfroy> the deltas themselves -- the changesets.
<KhaZ> Right.  And all the informationa bout them.
<jfroy> indeed
<KhaZ> So you can PULL from a repository to create a branch, yeah?
<jfroy> no, you always, always pull from a branch
<lifeless> KhaZ: at a code level, we can do that, but there isn't any ui
<jfroy> you can push a branch into a repository, creating a new branch stored inside the repository
<jfroy> lifeless: what would the semantics of that be?
<KhaZ> Huh, interesting.
<jfroy> mwhudson: yeah
<mwhudson> goody
<KhaZ> Quick question, that centralized model (I'm reading up on it now); I'm guessing there's no way to truly 'lock' files?
<KhaZ> i.e., artist 1 starts editing a maya scene, and artist 2 wants to edit it as well.  THe system can't notify artist 2 that it's already open for edit somehow?
<lifeless> jfroy: init a target branch; source = bzrlib.repository.Repository.open(source); target = bzrlib.repository.Repository.open(target); target.fetch(source, tip); branch = bzrlib.branch.Branch.open(target); branch.set_revision_info(tip, tip_revno)
<lifeless> jfroy: roughly
<lifeless> KhaZ: no, there is no advisory locking of files today
<lifeless> KhaZ: doable as a plugin though
<fullermd> Not with distributed branches, no.  You don't even have any way of knowing that artist 1 HAS a branch, much less what they're doing with it.
<fullermd> If they were working on a common branch, there's no theoretical obstacle to doing so, but nobody's done it.
<KhaZ> I suppose it doesn't make as much sense in a VCS that doesn't do Perforce's read-only-if-not-checked-out schtick anyhow.
<KhaZ> Is there a global option or something to make bzr commands only apply to a specified subdir and below?
<jfroy> yeah, Bazaar isn't based on a lock model at all.
<jfroy> Branches are merged and conflicts generated by merge algorithms.
<KhaZ> Oh, never mind, it does already!
<KhaZ> Or at least bzr st seems to.
<KhaZ> jfroy: Yeah.  Doesn't work so well with binary files tho. :/
<jfroy> nope :p
<fullermd> WT commands generally do by passing them the dir, yah.
<KhaZ> Stupid artists.  Learn to code your drawings. ;)
<lifeless> KhaZ: no there isn't, but paths are shown relative to ., I believe
<KhaZ> lifeless: Awesome.  Already a win over hg.
<bob2> KhaZ: bzr'll at least recognise that and let you pick which file to go with
<KhaZ> bob2: Ah, that's kinda neat.  I'm just trying to avoid the typical problem artists had with non-locking models of "F#@!, what do you mean you've been working on that for two weeks?  SO have I!  I'm not throwing out my changes!"
<jfroy> I think that's called failure to communicate.
<jfroy> :p
<KhaZ> Yup.  But it happens more than you'd care to imagine...
<jfroy> I sympathize with you though; it would be a big problem for a non-locking VCS.
<lifeless> ok, time to call it a weke
<lifeless> poolie: did you find the mail?
<KhaZ> Yeah.  I think if I ever push DVCS it'll be engineers only.
<jfroy> well, as was mentioned, a plug-in could be developed for that.
<lifeless> KhaZ: we have reports of folk using bzr with artists and the like very successfully
<KhaZ> jfroy: Hrmm, good point.  Well, it's a long way off until anyone at work cares what I think anyhow, so I can wait until said plugin comes to fruition. ;)
<jfroy> Plug-ins can be extremely powerful things -- so many possibilities :)
<KhaZ> jfroy: Aye.  I think I prefer bzr's plugin model over hg's too.
<KhaZ> The simple fact I couldn't rewire hg diff drove me up the wall.
 * mwhudson trials and errors with ff 
<KhaZ> lifeless: I'd be interested to hear how it works for them.
 * jfroy wants more success stories too :)
<KhaZ> Seriously now.  I'm glad I don't pay for Tortoise* software, because I have a veritable tortoise farm growing in my 'Add/Remove Programs'
<KhaZ> TortoiseSVN/TortoiseHG/TortoiseBZR... Sheesh.
<lifeless> KhaZ: 'well'
<mwhudson> jfroy: another fun diff! http://pastebin.ubuntu.com/114432/
<lifeless> KhaZ: :P
<lifeless> KhaZ: seriously, thats all the detail I have
<KhaZ> lifeless: That's the detail on my tortoise farm, or on the artists enjoying bzr? :)
<lifeless> artists enjoying bzr?
<lifeless> ok, see you all Monday
<KhaZ> lifeless:  <  lifeless> KhaZ: we have reports of folk using bzr with artists and the like very successfully
<KhaZ> lifeless: Later, thanks for your help. ;)
<mwhudson> jfroy: btw, re: https://code.edge.launchpad.net/~jeanfrancois.roy/bzr/url-safe-escape/+merge/3417, bazaar doesn't use launchpad for tracking merge proposals
<jfroy> mwhudson: looks good
<mwhudson> jfroy: good enough for me, thanks :)
<jfroy> mwhudson: bah, right
<jfroy> I'll open a bug and huh... mail them a merge bundle?
<mwhudson> yep
<mwhudson> bzr send
<mwhudson> + some twaddle in locations.conf
<jfroy> yeah
<jfroy> :sad:
<jfroy> that needs to be improved
<jfroy> child_submit_to (or whatever) isn't bad, but it can't go in locations.conf, it has to be in branch.conf
<jfroy> which means you can't blanket a repository of (say shared remote) branches with it
 * jfroy grumbles
<mwhudson> jfroy: anyway, thanks for being a sounding board, i'll look at your merge proposal properly on monday :)
<jfroy> No rush
<jfroy> but cool :)
<jfroy> My biggest concern right now is building some kind of bi-directional bridge between svn and bzr
<jfroy> svn needs to stay the "master", because the svn server is backed up offsite, blah blah blah, and some people want to continue using it.
<jfroy> While I and others want to use bazaar
<jfroy> I'm aiming for a setup where there's a blessed bzr branch somewhere that stays in sync with svn (probably only svn trunk, svn branches be damned) through bzr-svn
<jfroy> people using bazaar can branch off that svn mirror branch and do stuff, and eventually push back to that mirror branch, which will then sync up those changes with svn.
<jfroy> I'm wondering how to handle conflicts in all this, ideally by not having to worry about them at all, e.g. preventing pushes to the svn mirror branch if that would cause a conflict.
<jfroy> Maybe that mirror needs to be a bound branch....
<jfroy> mmmmm
<bob2> that'll just lead to a more annoying display of the conflicts
<KhaZ> Hrmm, stupid question.. How do I set a custom diff tool in bzr?  Can't find anything in the configuration stuff to do it...
<jfroy> KhaZ: you need the difftools plugin
<jfroy> I believe
<jfroy> bob2: am I aiming for the proverbial pipe dream?
<bob2> KhaZ: extdiff, iirc
<KhaZ> Ah... Will this replace the 'diff' command, or will I have to remember to always type 'bzr cdiff' or some such other?
<jfroy> you can replace the diff command with an alias
<bob2> no idea, cdiff is far too convenient for me to replace it
<jfroy> or a plugin can override it, yeah
<jfroy> but that would probably be rude
<KhaZ> Haha
<KhaZ> Does anything in bzr rely on diff exporting diff's of that variety?
<bob2> jfroy: not sure, sorry
<bob2> you can alias bzr diff to whatever you want
<KhaZ> Oh that's awesome.  hg didn't allow that.
<KhaZ> Yeah, just got it working with diff = diff --using colordiff
<jfroy> bob2: I think to get a really robust solution, the bzr-svn syncing will have to happen as a subversion pre-commit hook
<jfroy> and refuse commits that would cause a conflict, on either side
<jfroy> well, commits from subversion, and basically bazaar you won't be able to push to a branch that has diverged and that takes care of that
<bob2> KhaZ: bzr cdiff in bzrtools does that
<KhaZ> Ah, neat.  I still like not having to train my lazy brain to remember to use 'cdiff'. ;)
<KhaZ> Huh.  TortoiseBzr doesn't allow me to checkout to my usb drive.  Weird.
<poolie> KhaZ: what happens?
<KhaZ> poolie: Just doesn't show up as an option.
<KhaZ> poolie: But if I do a checkout from the C:\ and rename C:\ to L:\ (my USB drive directory) it works fine.
<poolie> lifeless: i answered
<vila> hi all
<poolie> hello vila
<poolie> how's stuff?
<vila> finer on the hardware side :) I had ti go back to store yesterday with my new toy just to discover that the failure was transient :-/
<vila> s/ti/to/
<poolie> oh
<poolie> what was the toy?
<vila> icore7-965/12GB/60GBSSD/1TBHDD :-)
<poolie> a desktop machine?
<vila> That's the Dr Jekyll of the MacBook Air Mr Hide :)
<vila> yup
<poolie> ah
<poolie> i had some hardware trouble the other day
<poolie> one of my hdds stopped working
<poolie> it might have been too hot
<poolie> in fact _i_ am too hot because my apartment is poorly designed and the airconditioner is broken atm
<vila> I'm still searching for the best way to show hardware sensors with intrepid...
 * fullermd is still flabbergasted at how Intel totally failed to interest him in an i7...
<poolie> it's very inconsistent between different hardware i think
<vila> I stop yesterday evening under the impression that my chipset was a bit too new for lm-sensors
<poolie> mbmon works ok for me on a much older 965 board
<vila> I'll look into that, I think I got the chipset (IHC10 ?) recognized with a more recent version of sensors-detect, but I'm not sure I don't need some other pieces...
<fullermd> 's too bad, 'cuz it sure looks like a secksay chip.  But I guess I'm still an AMD guy 'till their next refresh at least   :|
<vila> fullermd: very sexy indeed, but pricey...
<fullermd> Yeah.  Doubly so with the DDR-3 memory, too.  That's off-putting.
<vila> the fun thing is launching status monitor and try to understand what is going on with *8* curves instead of 2 :-)
<jeddy3> morning
<jeddy3> at the office we use subversion in the way that we build a complete tree of our repository but only check out the parts we actually need and leave big parts of the directory tree empty, is this possible with bzr?
<jeddy3> (we have a huge repository with different products, 10 branches and 30k-something revisions) and with this scenario you don't have to fetch the whole repository, but you can still update/commit multiple branches at the same time
<jeddy3> in other words a --depth for bzr
<jeddy3> ...which at a closer look doesn't seem to exist...nevermind
<poolie> jeddy3: ian's working a bit on it; our name for it is 'filtered views'
<poolie> i don't know if it's ready for testing yet though
<jeddy3> poolie: ah, sounds nice!
<jeddy3> and actually filtered views is a really good analogy for it
<ollie> need a quick bit of advise about a bzr repo
<ollie> I have my main developers and they work in /home/bazaar/repository/web/project/trunk/sub-project. I then have an outside developer who I want to provide a branch for. I created a branch within my repo but it ended up creating the files in the repo which I wasn't expecting
<ollie> I want the developer to be able to do a checkout from this branch. What is the best way to achieve this?
<poolie> ollie: so it sounds like you have a branch that contains a working tree
<poolie> you can still make a checkout of it somewhere else
<ollie> yes that is exactly what I have
<ollie> ok, and then will it be easy to merge the two?
<poolie> the wt in the central repository will get out of date (unless/until you run 'update')
<poolie> if you don't want the tree there, just run 'bzr remove-tree'
<poolie> hth
<poolie> good night all
<ollie> ah didn't know you could do that
<speakman> http://ppa.launchpad.net/bzr/ppa/ubuntu still breaks bzr upgrade due to uncompatible bzrtools: http://pastebin.com/me990cae
 * AmanicA wonders how long bundlebuggy will be on holiday  (it doesn't pick up merge requests for some reason. I do hope I didn't break it again. sorry)
 * Lo-lan-do â FOSDEM
<jeddy3> hmmm
<jeddy3> bzr pull on a subversion tree takes extremly long time... :|
<jeddy3> it should be up to date or maybe almost up to date
<spiv> jeddy3: file a bug
<spiv> jeddy3: I think it may be because it's wasting a lot of time in find_tags
<spiv> jeddy3: as a hack, if you put a "return {}" at the top of find_tags() in bzr-svn's repository.py it might workaround it...
<jeddy3> spiv: that would not return any tags, what is the effect of that? :)
<jeddy3> spiv: i mean does that have any consequences?
<jeddy3> spiv: if not, why does even find_tags exist? ;)
<spiv> jeddy3: right, that's the downside.
<spiv> jeddy3: but if you don't care much about tags, then it might be an okay tradeoff :)
<jeddy3> :D
<jeddy3> spiv: thank you
<BjornW> I want to perform a partial export. As in exporting only 1 directory or file. This doesn't seem possible with bzr or am I missing something?
<BjornW> Nobody got any hints or tips to perform a partial export?
<beuno> BjornW, BjornW what version of bzr are you using
<beuno> you can do:  bzr export file.tar.gz my_dir
<BjornW> beuno: 1.3.1 (I use Ubuntu 8.04 LTS)
<beuno> BjornW, it probably wasn't available then
<beuno> you could use the bzr PPA
<beuno> to get the latest version
<beuno> https://launchpad.net/~bzr/+archive
<BjornW> beuno: ok, is it production stable?
<beuno> BjornW, yes, more than 1.3.1  :)
<BjornW> beuno: haha ok, so I can do this: bzr export some_dir_in_my_repos /releases/some_new_release
<beuno> BjornW, the other way around, but yes
<beuno> 'bzr help export' will tell you the gory details
<BjornW> beuno: cool, that's what I need. I'm gonna upgrade bzr now. Thanks for the info!
<beuno> BjornW, you're welcome
<BjornW> beuno: just tried it and you just saved me a lot of annoying work. Thanks!
<beuno> BjornW, happy to help. You should see quite a few improvements with newer versions of bzr
<beuno> performance especially in the next few months, if you keep updated through the PPA
<BjornW> beuno: Cool, actually I'm thinking of working some on bzr as well. I'd to add a --force for exports to override previous exports. I've been missing this from svn. Any hints on the best way to start doing this?
<bialix> BjornW: may be it's better to start reading builtins.pt cmd_export
<bialix> builtins.py
<bialix> actual export code lives at bzrlib/export/ dir
<BjornW> bialix: thanks, I'll have a look tonight at it.
<bialix> BjornW: also there is bzrlib/tests/blackbox/test_export.py
<awilkins> jelmer: ?
<edgimar> How do I change my working directory so that all the files are from an earlier revision?
<awilkins> bzr revert -r <my earlier revision>
<edgimar> awilkins: ok, so if I don't specify a filename, it just does the entire working directory?
<awilkins> edgimar: Yes
<edgimar> ok great.  Thanks.
<awilkins> Bug hunting?
<edgimar> indeed...  Is there a 'bisect' like extension for bzr which automates things partly?
<awilkins> edgimar: Yup, that's what I was segueing into
<edgimar> Is it in fact 'bisect'?  Maybe I need to install it separately?
<awilkins> Yes, it's a plugin
<edgimar> And where do I get it / how do I install it?
<awilkins> bzr co http://bzr.licquia.org/bzr-bisect/ ~/.bazaar/plugins/bisect   # that ought to cover it
<awilkins> (on *nix, anyway)
<edgimar> I guess there isn't an Ubuntu/Debian package for it?
<awilkins> There's no PPA for it on launchpad
<edgimar> bzr: ERROR: Not a branch: "http://bzr.licquia.org/bzr-bisect/.bzr/branch/"
<awilkins> Dang
<awilkins> Aha
<awilkins> bzr co http://bzr.licquia.org/bzr-bisect/trunk ~/.bazaar/plugins/bisect   # that ought to cover it
<edgimar> ok thanks.
<mtaylor> lifeless: awake?
<awilkins> edgimar: You should also be able to branch it from it's launchpad mirror at   lp:bzr-bisect
<awilkins> That seems to be where my install is from
<edgimar> ok -- the previous co cmd worked though.
<awilkins> Yes, they're both identical mirrors (just checked). It hasn't changed in a long while, it must use very stable parts of the API
<edgimar> awilkins: so I take it that the way bisect works is that I first need to revert to a very old revision, and then do 'bisect start' and other bisect commands.?
<mtaylor> edgimar: nope
<awilkins> edgimar: Start at the tip, and bisect will handle the searching
<mtaylor> yup
<awilkins> You are looking for the revision where a particular property of your tree emerges
<awilkins> In this case, a bug
<mtaylor> and it's tha bomb, if I'm allowed to use that word
<awilkins> bzr bisect start
<awilkins> Then for each tree it presents you with, you test for the property. If it's there, bzr bisect yes
<awilkins> if not bzr bisect no
<edgimar> it strikes me as funny that you must 'revert' to the tip revision...
<awilkins> You may also give it hints if you wish to speed it up (ie - you know a particular revision was "good")
<mtaylor> edgimar: why would you need to revert?
<awilkins> mtaylor: He reverted to an older revision when searching manually
<mtaylor> ah, gotcha
<mtaylor> manual search bad
<mtaylor> :)
<jeddy3> hmm, is bzr pull on a bzr-svn repo supposed to take 1h20m even when there are NO NEW REVISIONS? :P
<awilkins> jeddy3: You upgraded to bzr-svn 0.5 recently?
<jeddy3> awilkins: version 0.49
<jeddy3> sorry 0.4.9
<nevans> oi vey, bzr-svn 0.5 is *slow* for me (only when talking to svn).  I pushed to svn 26 minutes ago.  svn recorded the commit 25 minutes ago.  "bzr push" finally returned just now.
<nevans> of course, the last several releases of bzr-svn 0.4 didn't work for me at *all*, and bzr (not talking to svn) has sped up dramatically since then, so I suppose I shouldn't complain.  :)
<jeddy3> heh :)
<nevans> also, I'm working with a ~53000 revision svn-repo, and this branch has 16746 revisions, so my bzr-svn performance may not be typical.
<jeddy3> hehe, 34000 revisions here, but still
<jeddy3> (repository-wise)
<nevans> I'm thinking that I need to finally hunker down and (re-)learn python, so I can take a look and profile it myself, and stop just being a complainer :)
<edgimar> awilkins: With bisect, I start with the tip revision, and type 'bzr bisect start' -- then it doesn't present me with a new tree, but I must first do bzr bisect yes/no.  Is that right?
<awilkins> edgimar: Yes
<awilkins> Start with "yes" if your tree has the property,
<awilkins> THen "no" when it doesn't
<edgimar> Also, does 'bisect yes' mean 'yes, there is a bug observed', or 'yes, this works correctly'?
<awilkins> You could automate it, if you have a test for the bug that isn't in the tree itself
<awilkins> "yes" means "this tree contains the property I'm looking for"
<awilkins> Which is the bug in this case
<edgimar> But it doesn't matter if I decide yes=bug, or yes=no bug?
<edgimar> (as long as I'm consistent)
<awilkins> I think it assumes that it's looking for something that once didn't exist, but now does. So yes should mean "bug"
<edgimar> Ok, that clarifies things...
<edgimar> Ok, now things are looking more like I'd expect.. :)
<edgimar> It occurs to me, however, that bisect can't really handle 'local optima', where the bug may have been introduced, and then is removed, and later introduced again.  ??
<awilkins> No, I don't think it could handle that
<jam> nevans: if you do "bzr XXXX --lsprof-file foo.txt" it will run a profile for you
<awilkins> edgimar: You could work around that as long as you knew at least one "good" revision in the period between "bug" and "bug : the return"
<bialix> ÑÑ Ð¾ÑÑ
<bialix> hi jam
<microft> need some quick help: how do I merge new changes from a launchpad project to my launchpad branch?
<jam> hi bialix
<jam> microft: "bzr co lp:~myuser/project/branch; cd branch; bzr merge lp:~other/project/branch" ?
<jam> bzr commit -m "new changes from $other"
<microft> jam: thanks
<bialix> hi all
<bialix> dear bzr hackers, I need a little help about writing test for my plugin, I need to emulate interaction with remote server
<Necoro> does there exist a possibility (e.g. bzr command) to check whether a directory is a bzr branch? - and which returns false in case it is an svn repo ;)
<Necoro> I used "bzr revno" up till now ... but if bzr-svn is installed, this will also succeee
<Necoro> but take way to long
<jdong> hey guys; what's the current status of bzr/bzrlib in IronPython? I have a project on the CLR I'd like to interface with bzr
<jdong> and am currently debating between an IronPython bridge or just some CLI hackery.
<Tak> jdong: ironpython bridge was a no-go when I tried a few months ago
<vila> bialix: what kind of remote server ?
<bialix> jdong: try to look at ironclad
<bialix> vila: hi
<vila> yo :-)
<bialix> any kind of server is good
<bialix> yo!
<bialix> I think about sftp
<Tak> hmm, can I unmerge a merge I did a few commits ago?
<bialix> because paramiko is strong dependency
<bialix> but http is also good
<vila> then look at bzrlib.test.test_sftp I think there is a class (or 3) about that
<vila> for http look at bzrlib.test.test_http, plenty of servers there :-) Even bzrlib.test.http_server
<bialix> I don't see test_sft.py
<vila> bialix: sorry, that's bzrlib.test.test_sftp_transport
<bialix> there is test_sftp_transport.py
<bialix> aha
<vila> bialix: sorry, that was from memory, I checked after typing instead of the opposite :-)
<Tak> nevermind, it's working the way I'd think it would, I just typoed the first attempt
<bialix> vila: basically I need to have writable transport to test init/push for scmproj
<bialix> and get/pull too
<vila> so that will be sftp
<bialix> TestCaseWithSFTPServer -- it's what I need?
<vila> you may have a look at bzrlib.tests.commands too, where the need for a writable transport guided the design
<bialix> tests/commands/test_init.py does not shed many lights here :-)
<vila> bialix: yes, and bzrlib.tests.commands really use bzrlib.test.transport_util to define the right transport and server
<vila> bialix: looks like you're too fast for me today, wait *some* seconds after each of my response may help :)
<bialix> vila: I think my question is: how can I inspect the files supposed to be on the server, or used by server?
<vila> ha
<bialix> ok, I'm waiting
<vila> Here is the dirty secret: we cheat :-)
<bialix> what?
<bialix> how can you dare?!?!
<bialix> :-)
<vila> We access the files locally knowing there are the same ones that the test server is using
<vila> for 99% of the cases that makes no difference, the remaining 1% is when *I* try to test with real ftp servers :-)
<bialix> vila: but how I can say to the server: you should serve files from *this* directory?
<vila> If you use the bzr test framework it's mostly transparent
<bialix> I'm working on plugin for bzr
<bialix> so yes, I'm trying to use existing test framework
<vila> because the tests run in a TMP directory and that's the current directory as far as the test writer (you) is concerned
<bialix> may I explain you more specific example?
<vila> sure
<bialix> it's about scmproj plugin
<bialix> I want to test init of new scmproj control dir
<bialix> it's almost equal to regular bzr branch
<bialix> so I'll doing local init, first commit, then push to testing server
<bialix> then I want to check what's on the server
<bialix> this is my test case
<bialix> is it correct?
<bialix> 2 questions: what should be URL to the testing server?
<vila> so let's say you push at self.get_url('branch'), you can then test f = open('branch/my_file')
<bialix> and second: the files I'm push will be in current testing dir? it's fine
<vila> yup
<bialix> self.get_url?
<vila> You must remember to use different paths to avoid
<vila> argh
<vila> get_url should be defined for any TestCaseWithTransport, let me check :)
<bialix> get_url seems to be defined in the TestCaseWithMemoryTransport
<bialix> which is father of all other tests
<vila> yup, that's right, and inherited from there
<bialix> that's right?
<vila> hehe, faster than you there ! :)
<bialix> rats
<bialix> you win
<bialix> why for get_server() methods are used/supposed?
<vila> you can also use self.get_transport(relpath) to get a transport pointing at the remote server
<bialix> yes, maybe I'll need this
<bialix> so, if I'm using TestCaseWithSftpServer -- I can suppose the server is auto-started?
<vila> you need get_server() mostly when you want to test the server itself
<vila> yes, the server is handled for you
<bialix> no, I need test only the result of interaction with the server
<bialix> not the server itself
<bialix> so, I can create branch in current test dir and then work with it via server. it's fine
<bialix> and easy
<bialix> vila: thank you thank you thank you
<vila> bialix: be my guest and happy to help(TM) :)
<bialix> this is the quote?
<vila> happy to help is jam's quote :)
<bialix> merci beaucau (sorry if I mispelled)
<vila> very close: merci beaucoup
<bialix> :-[
<awilkins> jdong: Tried IronPython a week or 2 ago
<bialix> my english now is better than my francais
<jam> vila: I think it is actually "always happy to help"  :)
<vila> jam: :)
<awilkins> jdong: It would need significant work
<bialix> jam: you rocks
<bialix> and vila rocks
<bialix> thank you guys
<microft> ~~~~~~
<jdong> alright looks like I have to go with a different approach then :)
<jdong> OT then, anyone know of alternative 3-way mergers for directories that don't rely on a VCS? :)
<jdong> I don't need a revision history or anything, just a decent 3-way sync
<awilkins> jdong: The way that bzr-svn makes a little XMLRPC server process would be a reasonable integration method
<jdong> yeah I suppose I can use a Python script to expose some sort of IPC protocol for the Mono side to talk to
<jdong> or... for this stupid little hackish program... just shell out to bzr's binary
<jdong> btw, I would just like to say bzr's Windows compatibility rocks; the best of the DVCSes I've tried.
<awilkins> I agree with you ; every time I try Hg or git to see if they got any better I run into something that either stops it working or makes me go "gaaaaaaaah!"
<awilkins> I'm sure that git in particular is awesomely powerful - on it's home turf
<Tak> jdong: have you looked at https://launchpad.net/monodevelop-bzr â½
<jdong> awilkins: yeah git is great on a POSIX platform; though I beg to differ with its UI
<jdong> Tak: very cool, I'll look at it.
<jam> jdong: you need a 3-way merger on Windows?
<jam> there is stuff like "meld" but I believe that is linux-only (though there is a lot that is portable)
<bialix> jelmer is like superman. he's everywhere
<jam> I suppose it also depends on what your "base" is, and how you are tracking it
<vila> bialix: naah, the truth is that there are twins ( 3 of them in fact :)
<bialix> I suspect this!@
<fullermd> The magic of cloning...
<jdong> jam: basically I have, on an arbitrary number of machines, a repo of text files. They operate partially disconnected and I'd like to be able to propagate the latest changes from any repo to any other.
<jdong> currently I am thinking of representing them as bzr branches and merge operations
<rockstar> If I create a shared repo with --1.9, will all the branches in that repo also be in format 1.9?
<jam> rockstar: not without individually upgrading them
<jam> though the upgrade in that dir should be trivially fast
<rockstar> jam, what if it's from scratch?
<rockstar> So I just create a new repo and a new branch in that repo?  Will that branch be format 1.9 ?
<jam> rockstar: "bzr init-repo --1.9 repo; cd repo bzr init my-branch" the branch will use the 1.9 storage, but will technically be a 'pack-0.92' branch
<jam> with the only difference being a flag that indicates it supports stacking
<derekS> hey guys, can i push to a local repository, then push that up to another repo?
<jam> though if you do "cd my-branch; bzr push lp:xxx" it will use the fact that the repo can stack, and auto-upgrade the branch format, IIRC
<jam> derekS: generally, yes
<jam> rockstar: in other words, "bzr init" does not use a containing repository to define the branch format.
<rockstar> jam, so I'll have to bzr init --1.9 the branch as well.  Okay.
<derekS> jam: generally?
<jam> derekS: I *think* I know what you are trying to do, and it should just work.
<derekS> ok :)
<derekS> thanks
<Peng_> If you don't care about stacking, you don't need to use 1.9 format branches.
<Peng_> As long as you don't mind "bzr info" saying "format: unnamed".
<abentley> Peng_: I think you mean 1.6.  1.9 has other advantages.
<jam> abentley: the 'branch' format for 1.6 and 1.9 are identical.
<KhaZ> Weird.  TortoiseBazaar can be forced to do a checkout to a USB drive, but it won't give me any options to manipulate said items on the usb drive. :/
<jam> so doing "cd repo; bzr upgrade --1.9; cd branch; bzr upgrade --1.6" will have "bzr info" tell you 1.9
<abentley> jam: Yes, I see that in this specific case, it's true.
<jam> yay for summary items
<jam> that don't quite tell the truth
<CaMason> hi guys. I've been committing locally, and now want to send those changes to the central repo. What's the correct process?
<KhaZ> CaMason: bzr push [central repo url]
<CaMason> I ran bzr update, but I seem to have buggered up my local copy (the one I've been using commit --local with)
<CaMason> bzr log is showing the most recent entry as 172, yet doing 'bzr check' shows 178 revisions
<CaMason> so I try bzr revert -r 178, and it says the revision does not exist
<CaMason> Anyone have any ideas? I've been working on this all-day and really need to get that 178 revision back
<EnCuKou> CaMason: Maybe `bzr heads` will show you the revision-id?
<bialix> monsieur vila, may I ask one more time about testing server?
<vila> sure, sir Alexander
<CaMason> EnCuKou: 'bzr heads --all' shows one of my last commit messages
<CaMason> then it says (dead) after it
<bialix> is there any benefit to use sftp server for testing over bzr:// writable one?
<awilkins> CaMason: So you have 178 revisions - they just aren't all part of your current branch
<bialix> CaMason: because it's dead actually
<CaMason> http://srtsolutions.com/blogs/chrismarinos/archive/2008/10/24/don-t-loose-your-head-with-bazaar.aspx
<CaMason> that's exactly what's just happened to me
<bialix> vila: I remember in the past I have many failures in bzr selftest on win32 related to sftp server
<vila> bialix: I'm not sure there is a test bzr server... at least I have no experience with it, spiv would know better, but I think only some tests use a smart test server
<bialix> vila: ahh
<bialix> so sftp server is most common solution?
<vila> for a writable server, yes, at least last time I needed one, I used sftp and fall back to ftp if paramiko wasn't available
<bialix> yes, but ftp one in turn require Medusa, IIRC
<bialix> ok
<CaMason> this is a pretty serious problem if a 'bzr update' is killing off my local commits
<bialix> bzr update?
<CaMason> yeah, I just did 'bzr update' and it killed all of my local commits from today
<CaMason> took me back to revision 172 (from 178) and I just had to use bzr heads --all
<bialix> I think they should be converted to pending merges
<vila> yes, medusa is required, until I find another solution (which is needed for 2.6, but there is no urgency there so don't hold your breath...)
<CaMason> pending merges?
<bialix> CaMason: may be you accidentally run bzr revert
<CaMason> bialix: I can promise you I didn't
<CaMason> I still have the original shell window up
<vila> bialix: but if you have too much troubles with paramiko and medusa, I have some pointers if you want to replace medusa :-0
<CaMason> I do know that bazaar crashed during the process, something to do with x-server not being available (as I'm in via SSH)
<bialix> vila: no, paramiko is always available for me at win32 :-)
<bialix> vila: it's hard dependency here
<bialix> CaMason: ah, um
<bialix> CaMason: but your data is still in the repo
<CaMason> bialix: sure, but I have no idea how to get my previous commits back
<bialix> bzr pull . --overwrite -r revid:dead-revid
<bialix> that's all
<CaMason> atm, I've used "b revert -r revid:..." but that only restored files
<bialix> you need pull
<CaMason> what is pull going to do?
<bialix> the article you've linked is incomplete
<bialix> it's hard question
<CaMason> all of these changes are --local commits on a laptop
<bialix> that's fine
<bialix> so you're locally
<CaMason> so I had an updated checkout at revision 172... I've been committing using --local today up to revision 178. I used "bzr revert -r revid:..." and my fils are back
<CaMason> yet my log still shows 172, and all of these files I just reverted are showing as modified/new etc. Doing a commit will seemingly skip over my previous commits
<CaMason> "bzr pull . --overwrite" looks scarily like it's going to overwrite my local commits from the central repo
<bialix> CaMason: please, try the pull command I gave you, but instead of dead-revid put your real revid of dead head
<bialix> you can branch if you like
<bialix> bzr branch broken-branch new-branch -rrevid:dead-revid
<CaMason> ok thanks I'll do that first
<bialix> it's also restore your hstory
<CaMason> ok I did that branch and my log now shows up to 176 which is about correct
<CaMason> I have no working copy though
<bialix> perhaps you're inside treeless repo
<bialix> bzr co .
<CaMason> ok, this is working, thanks. So, now I should bind this to my central repo?
<bialix> if you like
 * CaMason feels less panicky now
<bialix> relax, take it easy
<bialix> :-)
<CaMason> right, it's bound. Now, should I do a bzr update?
<bialix> to reproduce the bug? yes, of course
<CaMason> I mean, to get these files pushed back to the central repo
<bialix> if you want push them you need push command
<bialix> I'm late in discussion of your problem, can you describe your setup?
<CaMason> sure, 2 seconds
<CaMason> I have a central repo on my machine in the office. I usually have a checkout on my laptop to work whilst I'm away
<CaMason> I got home today, and did a bzr commit to try and place my changes on the central repo. It said I needed to update first. I did that, and it deleted all of my changes and put me back to revision 172 (the revision before I left the office, and the revision on the central repo)
<bialix> at this point you should have your local commits as pending merges
<CaMason> so what should be the normal process for performing this local -> central merge?
<bialix> well, it's depend
<bialix> bzr update put your history in sync with the server, and not vice versa
<bialix> kfogel: are you here?
<CaMason> my laptop did crash earlier, so I'm hoping that was the reason for this mess-up
<bialix> I don't see the liason
<CaMason> from what I recall.. I would normally do 'bzr update' which would pull in the newest changes from the central repo, and tell me if there are any conflicts
<bialix> can you execute `bzr update` now
<bialix> ?
<CaMason> bialix: yes and it's all working fine
<CaMason> I'll try it on the bugged machine too
<bialix> run `bzr st`
<CaMason> it says a few files are 'unkown' and they all end with .moved
<bialix> it's in the branch when the history changed from 176 to 172?
<CaMason> yes. I'd since ran bzr update and that's updated the log to show 172 to 176
<CaMason> and the files are now the correct version
<bialix> I'm lost in your hardware
<bialix> .moved files are because you've added them in different branches with the same name
<CaMason> PC: contains repository. LAPTOP: Contains checkout... normally I do `bzr commit --local` on the laptop whilst I'm not online. When I return, I do `bzr update`, sort out any conflicts, then `bzr commit`. However, this time, `bzr update` on the laptop deleted all of my changes, so that my working copy looked like -r 172
<bialix> ah
<bialix> it smells like the bug
<CaMason> and I had no reference to -r 173,174,175,176, except when I ran `bzr heads --all` and 176 showed up as (dead)
<bialix> this is right
<CaMason> is this a known issue?
<bialix> the history is linear
<CaMason> ls
<CaMason> (oops)
<bialix> about update? not converting your local commits to pending merges? I don't know. never seen this before.
<bialix> may be
<luke-jr> https://bugs.launchpad.net/bzr/+bug/326278
<ubottu> Ubuntu bug 326278 in bzr-svn "'bzr log' KeyError" [Undecided,New]
<luke-jr> err, entirely unrelated to Ubuntu..
<CaMason> bialix: like I say, my laptop crashed earlier and fsck showed up numerous errorrs
<CaMason> no idea if it's related, but I'll see if it ever crops up again
<CaMason> Thanks for helping me get my commits back though :D
<CaMason> on another note.. if I SSH into a machine that has bazaar with bzr-gtk installed, commits will crash, complaining of something to do with X server being unavailable
<CardinalFang> CaMason, using what command?
<amanica_> CaMason: btw if you are using checkouts with local commits, allways make sure you don't have local changes and local commits
<awilkins> CaMason: Are you passing the -m argument or not?
<amanica_> because it will make your commits pending
<amanica_> and then you cant tell what changed outside of the pending commits
<amanica_> i.e your pending commit changes and your workingtree changes will all be committed with the next commit
<amanica_> maybe this isn't an issue for you
<amanica_> this happen when you do an update with local commits and changes in the working tree at the same time.
<amanica_> (sorry I forgot to mention the update part before0
<amanica_> (there is some bugs related to what I described eg. Bug #113809 , I think I should log what I described here seperately)
<ubottu> Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809
<CaMason> amanica_: it's possible that I had changes as well as local commits when this issue happened
<CaMason> infact, probably likely
<nDuff> CaMason, is the DISPLAY variable set at all when bzr-gtk is interfering with your commits on a remote host? Does unsetting it help?
<amanica_> CaMason: I don't think that would cause all your pending commits to dissappear, unless you did a revert
<CaMason> nDuff: sorry for being a newbie... where do I check that?
<nDuff> CaMason, run the following: echo $DISPLAY
<CaMason> blank output
<nDuff> CaMason, hmm -- I'd hope that bzr-gtk would be smart enough to not try at all to use X with an empty DISPLAY; that said, I don't have a copy checked out to look at the source to myself.
<CaMason> nDuff: that would be the expected behaviour, I'm sure
<CaMason> whenever I do a commit locally on the laptop, there's a notification (on ubuntu). I do this when connected to the laptop via SSH, and it shouldn't try to bother with X at all. But seemingly, it does
<EnCuKou> If you're checking $VISUAL, also check $EDITOR and $BZR_EDITOR
<awilkins> That was why I was asking whether he was passing -m
<CaMason> as in 'commit -m "my commit message" ?
<EnCuKou> Sorry, wrong window
<awilkins> CaMason: Yes ; I reckon you might have gvim or the like in $EDITOR
<CaMason> nothing in $EDITOR or $BZR_EDITOR
<CaMason> it actually loads up pico
<awilkins> Ah well, that's that theory out of thw indow
<CaMason> brb washing up!
<nDuff> CaMason, I just took a quick look at the source to bzr-gtk, and it looks like it's trying to check for that case (and should exit with an error "No DISPLAY. Unable to run GTK+ application" if trying to run a GTK-involved subcommand in that case). What version do you have? Could you pastebin the exception?
<CaMason> nDuff: I'll make a test repo and tr it
<CaMason> http://pastebin.com/d30394fa1
<CaMason> nDuff:?^^
<nDuff> ...is that actually the gtk plugin, or the dbus plugin?
<CaMason> no idea... I literally inited a repo, added a testfile, commit.. and get that output :)
<CaMason> This is on a relatively fresh Ubuntu 8.10 install, with bazaar installed via synaptic
<nDuff> CaMason, could you check whether uninstalling or disabling only the dbus plugin makes the issue go away? If so, that provides some targeting for fixes/bug reports/such.
<CaMason> nDuff: certainly, 2 mins
<CaMason> so I should leave bzr-gtk installed?
<nDuff> yup
<CaMason> removing bzr-dbus also removed bzr-avahi
<CaMason> had to run an update first. The commit succeeded without crashing
<nDuff> CaMason, OK. Is there any output from the command "set | grep DBUS"?
<CaMason> nDuff: nothing
<nDuff> CaMason, if you reinstall bzr-dbus, and run the commit command as "dbus-launch bzr commit", does it still fail?
<CaMason> interestingly, reinstalling bzr-dbus didn't prompt to install bzr-avahi
<nDuff> CaMason, makes sense -- that indicates a one-way dependency from bzr-avahi on bzr-dbus.
<CaMason> `dbus-launch bzr commit` no crash
<CaMason> `bzr commit` = crash
<KhaZ> bzr st yields a list of things that are renamed and conflicts, but if I do a 'bzr merge [path-to-item-that-is-renamed-and-or-conflicted]' it says 'nothing to do'.  How do I go about running a merge tool on these two items?
<CardinalFang> KhaZ, "merge" copies from other trees.
<CardinalFang> ...or something like them.
<nDuff> CaMason, OK -- the bzr-dbus plugin should probably just short-circuit if the DBUS_SESSION_BUS_ADDRESS variable is unset; that should be a pretty easy patch to write or bug report to file.
<CaMason> nDuff: that variable is present on the laptop, but not present when in via SSH
<nDuff> CaMason, yup -- and that's exactly why you're having the problem when you're only connecting over SSH.
<CaMason> excellent :D (ish)
<CaMason> now, I'd file a bug report if I knew how
<nDuff> CaMason, see the "report a bug" link at https://launchpad.net/bzr-dbus
<CaMason> https://bugs.launchpad.net/bzr-dbus/+bug/326320
<ubottu> Ubuntu bug 326320 in bzr-dbus "`bzr commit` throws an exception when bzr-dbus is installed, and commit is via SSH" [Undecided,New]
<nDuff> CaMason, thanks; there's actually some relevant discussion going on over in #dbus right now, so I'll go paste that in.
<CaMason> excellent. Glad I was able to help somewhat
<ronny> LarstiQ: http://www.geeksugar.com/2471026
<nekohayo> just committed and pushed my branch, and bazaar tells me I have conflicting tags
<nekohayo> now what? I have no indication of what to do with that
<bialix> bzr tags
<bialix> bzr tags -d remote-branch
<bialix> compare results and decide which tags are right
<nekohayo> but.. the results are identical
<bialix> nope
<nekohayo> bialix: http://ecchi.ca:8000/1.png
<nekohayo> unless I should swap "remote-branch" by "lp:specto"
<bialix> try with --show-ids flag
<nekohayo> aah, using lp:specto does show that it's the same tag on rev 107
<bialix> yep
<bialix> I guess you just find the bug
<nekohayo> now the question is what's the next step once I decided that my local branch (tag on 108) is the right one?
<bialix> remote-branch is not valid path in your tree>
<bialix> ?
<bialix> wait, the bug first please
<nekohayo> I had to use lp:specto instead of remote-branch.
<bialix> bzr should tell you that you provide wrong path
<bialix> ok, back to tags
<bialix> if your local tags is the right one, you need to push --overwrite
<nekohayo> it worked, thanks! /me notes this somewhere
<bialix> may be adding this to faq?
<bialix> or blog about this ;-)
<amanica__> conflicting tags scares some people, maybe this should be explained in a topic, and referenced in that message
<bialix> I think the error message should be more clear itself
<bialix> there is help topics on conflicts, but it say nothing about conflicting tags
<bialix> it's a bug?
<bialix> Bug #213184
<ubottu> Launchpad bug 213184 in bzr "'conflicting tags' could be more helpful" [Wishlist,Confirmed] https://launchpad.net/bugs/213184
<bialix> it's marked as wishlist though
<nekohayo> bialix: I actually saw that bug report before coming to this channel, because nobody had given an answer on that bug report
<bialix> perhaps because that bug was reported by one of the core dev
<bialix> I think it should be easy to fix. someone with good english skill just need to write some explanation
<bialix> or maybe tags v2 should be implemented first
<jbalint> any idea what this means? bzr: ERROR: A nested progress bar was not 'finished' correctly.
<bialix> you're running bzr.dev?
<jbalint> my own dev :)
<bialix> I mean: are you running bzr from sources?
<jbalint> i'm editing the sources
<bialix> check your .bzr.log then
<bialix> or try to merge latest changes from bzr.dev
<jbalint> oh joy, not paying attention here. thanks :)
<bialix> next question please
<jbalint> i have nothing else atm
<bialix> it's not to you personally
<bialix> i've tried to joking
<jbalint> you can check the questions on launchpad!
 * bialix looks
<bialix> there are only 3 questions
 * bialix has answered one question, others 2 out of his competence
<jbalint> nice
<bialix> thx
<CardinalFang> Hi all.  With bzrlib, I want to use "send" or "merge_directive" to create a mergable bundle, bug I don't want to have top be connected to the net.  Assuming that only the last commit is outstanding, how can I construct a bundle without touching the upstream target_branch?
<amanica__> bialix: stop joking around in IRC, and get cracing on that layout changes!
<amanica__> :)
<bialix> I'm not enough sterkte tonight!
<bialix> :-P
<amanica__> LOL
<amanica__> I see your on a roll here, enjoy.
<nekohayo> hmm. I've seen a bunch of slides of talks about bazaar... but are there any videos of such talks, or videos of bazaar tutorials/demos, especially advanced features like cherry-picking ?
<bialix> thank you, dude!
<amanica__> CardinalFang: that bothered me once too, but I was told that trafic is quite minimal
<bialix> CardinalFang: if you sure what revisions should go in the bundle you can use local branch as the base
<amanica__> an exact local mirror is preferable
<bialix> yes
<amanica__> even if it is a little outdated
<amanica__> (with exact I mean there should not me non-upstream commits present)
<bialix> it's easy to reconstruct, actually
<bialix> nekohayo: I guess there are plans to make some screencasts
<bialix> actually there are 2 of them listed at http://bazaar-vcs.org/Documentation
<bialix> see Screencast section
<CardinalFang> bialix, I think I tried.  I'm writing a post-commit plugin, so I get the revid before and after.  I use os.curdir to say "right here".  My bundle header looks right (I think), but the bundle contents are empty -- aside from the preamble.  I .decode("base64") and then unbz2'sd it, and its not much -- nothing describing the change.
<CardinalFang> I suspect it's a fencepost problem.  N-1 exclusive to N inclusive = 0
<bialix> no, you need to create bundle against another branch, not against itself
<bialix> fencepost?
<CardinalFang> Off by one.
<bialix> LOL
<CardinalFang> Counting fenceposts instead of fence-spans.
<bialix> Cardinal: you really should create somewhere on disk base branch
<bialix> and use it as SUBMIT_BRANCH argument
<bialix> hmm, you even can try t create base branch as --stacked to your dev branch
<bialix> it should be very cheap then
<CardinalFang> bialix, It's not me.  Assume my user branches from off the 'Net, and then gets on an airplane.  Hack hack hack.  Commit.  My post-commit hook runs.
<bialix> it's *your* post-commit hook. Is not you're master on your hooks?
<bialix> slightly change the hook? not?
<CardinalFang> Yes, I'm writing it now.  I can design it.
<bialix> so... os.curdir perhaps is bad idea to using for specifying base branch
<CardinalFang> Yeah.  I can get the base other ways.  I'll get to that, once I see it works.
<ignas> how do I see the connection debug info? my merge is timing out, but I don't know why...
 * bialix shrugs his shoulders
<bialix> what kind of connection?
<bialix> bzr+ssh, http?
<bialix> look at .bzr.log first
<bialix> or into .bzr.log
<ignas> bzr+ssh
<CardinalFang> So -- to construct a bundle, I assumed I really don't need another branch somewhere, if I know what is outstanding and can include everything that would go into a bundle.
<CardinalFang> ignas,  -Dhpss as parameter.
<bialix> for gather debug stat use `bzr -Dhpss <YOUR COMMAND HERE>`
<bialix> CardinalFang: abentley thinks different
<bialix> in the good ol days when the grasp was green and te heaven was blue... bundles have worked that way
<ignas> is there a way to use bzr repositories in launchpad through http?
<bialix> yes
<ignas> how do i do that?
<bialix> go to branch page
<bialix> look at url under source code button
<bialix> remove files at the end
<bialix> you'll have valid url
<bialix> someone told even simpler way
<bialix> but I don't remember
<ignas> bialix: thanks
<bialix> next question please
 * bialix wants to win jackpot
<fullermd> Why is there air?
<bialix> oh, my hero is here!
 * fullermd dons his cape and strikes a pose.
<bialix> what about air actually?
<fullermd> I dunno.  You just asked for a question, and it came to mind.
<bialix> ah
<bialix> stupid me
<bialix> I wanna get my call to a friend!
<fullermd> That doesn't mean you can get away with not answering it!   :p
<bialix> there -- is where?
<bialix> if I'm answer it in russian -- does it will counts? :-P
<fullermd> "is there" ~~ "does exist"
<fullermd> Well, only if I understand it.  I think my Russian vocabulary runs to 6 words or so...
 * ignas can translate
<bialix> I can try to answer using only your words
<fullermd> I know da and nyet, so I guess that means you can answer in binary?  :p
<bialix> fullermd: you cheating! http://en.wikipedia.org/wiki/Why_Is_There_Air%3F
<bialix> da and nyet == yes and no. what is other
<fullermd> Wait, I'm supposed to not cheat now, too?  If you'd just lay out all these rules ahead of time...
<bialix> I think it should be good litycs
<bialix> lyrics
<bialix> what is other 4 words
<fullermd> Oh, that was just a number I pulled off the top of my head.  I know the bits and pieces you can't help but pick up of languages.
<fullermd> Which isn't enough to explain much of anything   :p
<bialix> :-P
<bialix> my answer is valid?
<fullermd> I guess.  I think it's cheating though   :p
<bialix> I'm learn from the best
<ste_> hi all
<bialix> fullermd: but I feel you're win
<ste_> does anybody know how can I merge two different and unrelated branches into a single new branch ?
<bialix> bzr merge -r0..-1
<bialix> is not this answer should be in the faq?
<CardinalFang> ste_, With different roots?  Er, that sounds tricky.
<ste_> like, they were divided, but now I want to put them all under a brand new branch
<ste_> but replaying the changes
<CardinalFang> There were [once the same but are now] divided, .. ?
<ste_> in svn I did with a svndump
<ste_> well, sorry, I see it's tricky
<ste_> i'll explain better
<ste_> I started developing two programs, and I gave them a bzr init each
<ste_> each branch so created went in its own direction, with many commits
<ste_> now I realized that I want these two programs to be part of a single branch
<ste_> quick and dirty solution: i bzr init a new empty dir
<bialix> so?
<ste_> copy the contents of the two old ones
<bialix> bzr merge -r0..-1
<ste_> and bzr add everything
 * bialix can repeat this 3rd time
<ste_> that's good, I want to be sure ;)
<bialix> to be sure - what?
<ste_> that you understood the problem I have, since I reread myself and even I didn't understand what i wanted ;)
<bialix> it's much easier than questiona bout air
<bialix> do you knwo the answer on question about air?
<jam> bialix: because otherwise we'd all be dead
<jam> or at least, life as we know it would not exist
<bialix> it's too easy for fullermd
<ste_> i know the answer to life, universe and everything, does that count ?
<jam> though that answer may be a bit self serving
<ste_> air is part of everthing
<ste_> therefore
<bialix> may be otherwise we don't breath at all?
<jam> (if there was no air, we wouldn't know about it, because we would not exist, thus for us to be as we are, and aware of air existing, it must exist)
<ste_> the answer to air is part of the answer to everything
<bialix> wonderful!
<jam> Either that or "just because"
<ste_> mostly depends on what you mean by air...
<bialix> ignas: just because == Ð¿Ð¾ÑÐ¾Ð¼Ñ ÑÑÐ¾,
<bialix> ?
<ste_> you can survive breathing a different atmosphere
<ste_> but I would not define it "air" in the conventional sense
<ste_> moreover, fishes don't need air in the conventional sense
<ste_> so if we were intelligent fishes
<ste_> you know what I mean
<bialix> o!
<ignas> bialix: think so
<bialix> ignas: I guess very close
<ste_> well, trying this merge
<ste_> 10x for the help
<ignas> bialix: yeah
<bialix> fullermd: ?
<bialix> jam: thanks! lol
<fullermd> Hmm?
<bialix> I did my call to a friend
<bialix> see above ;-P
<jam> ste_: if we were intelligent fishes, we still wouldn't be us as we are today
<ste_> yep, and we wouldn't know
<ste_> although, developing metallurgy in water environment would be tricky
<fullermd> But think of the money we'd save on towels.
<ste_> maybe near some vulcano
<jam> ste_: perhaps. you just need a different heat source, since water could carry a lot more heat than air anyway
<bialix> it's remind me the book of Harry Harrison about dynosaurus
<fullermd> We'd certainly all be using water-cooled computers   :p
<fullermd> (except a few extreme fanatics who'd try for uber-overclocks with air cooling)
<ste_> :D
<bialix> :-D
<CardinalFang> jam, Do you know much about the bundle construction code?  I'm trying to create one containing only the last revision, without touching a target branch.  I hear it's impossible, but this sounds weird.
<bialix> "winter in the eden", I hope I re-translate the title right
<jam> CardinalFang: "without touching a target branch" ?
<jam> Are you trying to do it in bzrlib? or with a bzr command ?
<bialix> jam knows everything
<jam> for some value of everything :)
<bialix> and this too :-)
<CardinalFang> bzrlib.  If I branch from somewhere on the net, and then climb on an airplane with no net access, can I commit and then construct a bundle containing that?
<jam> well, the easiest way is:
<jam> bzr branch -r -2 . ../old
<CardinalFang> ....without branching up ...  ha.
<jam> bzr send -o out ../old
<jam> it is possible
<jam> Just saying what is easiest
<CardinalFang> Yep.  I'm writing a post-commit function.  So, I don't want to do that.  :)
<bialix> "west of eden" series actually
<jam> so you want to look at "bzrlib.merge_directive.MergeDirective2.from_objects()"
<jam> It, unfortunately, takes a "target_branch" and not a "target_revision"
<jam> However, I think you might be able to create  MergeDirective2() directly
<jam> with the right values
<jam> and use the appropriate value to "MergeDirective2._generate_bundle()"
 * CardinalFang looks.
<bialix> what exactly means: "I dunno"?
<jam> CardinalFang: http://paste.ubuntu.com/114984/
<jam> At least, that is my wholely untested but probably close-to-right attempt
<jam> bialix: "I don't know"
<bialix> how it pronounced?
<jam> Espec. in America, the last part of the "don't" merges with the beginning of "know" and you get
<jam> I dun-no
<CardinalFang> jam, wow, you're great!  Thank you.
<bialix> jam: got it
<jam> bialix: Actually, in common pronunciation, there are almost no consonants
<jam>  I -uh -oh
<fullermd> Man, you yankees...
<bialix> I'm dizzy
<fullermd> A perfectly natural reaction to English  ;p
<bialix> I can teach you russian a bit
<ste_> cool, it worked
<ste_> thank you guys
<bialix> what? 42?
<fullermd> I don't know.  Third base.
<CardinalFang> Heh.
<ste_> third base like in xkcd?
<CardinalFang> Yes.  Exactly like that.
<ste_> passing the virginity maginot like ?
<ste_> line
<fullermd> Well, I was thinking more Abbott & Costello, myself, but that would probably be more fun   :p
<CardinalFang> fullermd, Who?
<CardinalFang> (First base.)
<fullermd> What?
<CardinalFang> No, first.
<jam> fullermd: http://xkcd.com/540/
<fullermd> Yes.
<jam> see you all around next week, I'm off
 * CardinalFang commiserates with fullermd, and shakes his fist at the kids on his lawn.
<CardinalFang> G'night, jam.
<KhaZ> I can't seem tog et bzr st to only show paths from the directory I'm in or below.  i.e, if I have a file versioned as /a/b/c/file.txt, and I'm in 'c', I'd hope bzr st would print 'file.txt'.  Instead it prints '/a/b/c/file.txt'.  Is there a setting I'm missing somewhere?
<bialix> no
<KhaZ> Hrmm.
<bialix> what these binary numbers means?
<ste_> they mean base 2
<bialix> hmmm
<garyvdm> Hello
<bialix> I'm definitely don't understand baseball enough
<bialix> hi Gary
<bialix> fursuits?
<bialix> oh, never mind
<ste_> good, back to code
<ste_> thanks for the help!
<bialix> Janeane?
<ste_> and for bzr, I like it
 * ste_ bye
#bzr 2009-02-07
<lifeless> mtaylor: yes
<rocky> just curious, does anyone here ever nest repos ?
<Peng_> rocky: Repos? Yes. Branches? No.
<KhaZ> Hey!  Quick question.  In the bzr code, is there any way to get the path to the root of the current branch?  If not globally, can you do so from the TreeDelta class at all?
<Peng_> KhaZ: There's the "bzr root" command. You could start with its code.
<KhaZ> Cool, thanks, I'll take a look
<bialix> KhaZ: I gave you wrong answer yesterday, sorry. `bzr st .` do what you need
<KhaZ> Oh?
<KhaZ> Hrmm.
<KhaZ> I just rewrote bzr st in my local copy to do that.  Oops.
<KhaZ> Actually, that doesn't seem to work either
<KhaZ> Oh, wait a minute
<KhaZ> I'm confusing two issues.
<KhaZ> bzr st . only prints changes after my current working directory, which is defintely awesome.
<KhaZ> My other 'issue' is that bzr st always prints out paths relative tot he root of the repository, not relative to where I currently am in the tree.
<KhaZ> I've put code in my local branch of bzr to do that.  If I wanted to see if that would be accepted in the mainline, how would I go about doing that?
<KhaZ> (Not saying it should be - perhaps people enjoy the current way... But I'd like to ask at least. ;) )
<bialix> Khaz: the second issue mulled over many times. It's considered as bug
<bialix> https://bugs.launchpad.net/bzr/+bug/30159
<ubottu> Ubuntu bug 30159 in bzr "paths are always from root of branch" [Low,Confirmed]
<bialix> very ooooold bug
<bialix> if you want to fix this bug -- many peoply will be happy
<bialix> KhaZ: run `bzr send --mail-to bazaar@lists.canonical.com lp:bzr` in your branch -- this will create patch submission
<bialix> http://bazaar-vcs.org/BzrDevelopment
<Jc2k> morning
<LarstiQ> ronny: ooooh, those gloves look nice
<ronny> LarstiQ: they sure do
<bialix> hi AmanicA
<AmanicA> hi
<bialix> today is quite enough here?
<AmanicA> huh?
<bialix> I mean the channel is empty, not?
<LarstiQ> relatively
<bialix> look at lp:~scmproj-dev/bzr-scmproj/new-layout please
<bialix> you LarstiQ!
<AmanicA> :)
<bialix> yo!
<ronny> bialix: whats scmproj ?
<bialix> LarstiQ: we going to do mini-sprint with AmanicA on new layout. everybody can jump in
<bialix> ronny: emulation of nested trees
<ronny> only bzr, or support for others, too?
<bialix> ronny: In general design is vcs-agnostic
<bialix> ronny: sorry, my "look" may be too wide there
<LarstiQ> bialix: cool, I'm at fosdem at the moment, still waking up, going to hunt down jelmer and others later
<bialix> cool
<ronny> bialix: ah, im the author of anyvc, which is a vcs abstraction lib
<bialix> ronny: cool
<bialix> anyvc for Emacs, no?
<ronny> i still lack support for repos/branches tho, doing mostly workdir abstraction atm
<ronny> bialix: its a python lib
<ronny> using it in the pida ide
<bialix> ooh
<bialix> I've started some sort of vcs abstraction for scmproj
<bialix> AmanicA: try to run tests, you'll see where we now
<ronny> bialix: how far, and whats the main job of it
<ronny> bialix: i'd lobe to join effords at some point
<AmanicA> excelent!
<ronny> mostly cause propper abstraction of the various branching patterns is a huge pain
<bialix> ronny: I'm focusing on the scmproj needs
<bialix> as main goal
<ronny> btw, is there any relation to the vcs-pkg project?
<bialix> we have our own "branch" abstraction here: local branches
<bialix> ronny: http://bazaar.launchpad.net/~scmproj-dev/bzr-scmproj/new-layout/annotate/head%3A/vcs.py
<AmanicA> bialix: tests passed
<bialix> AmanicA: you joking
<AmanicA> no
<AmanicA> I did make test
<ronny> bialix: ah, i see
<AmanicA> on new-layout
<bialix> I have 8 errors
<bialix> ronny: what is vcs-pkg
<bialix> ?
<bialix> AmanicA: I suppose you need to switch your active plugin to use new-layout branch/checkout, no?
<ronny> bialix: http://vcs-pkg.org/
<AmanicA> ok
<bialix> ronny: no, "distro package maintenance" is not my goal
<AmanicA> back to reality: FAILED (errors=8)
<ronny> bialix: k
<bialix> AmanicA: we have 2 different ways here: working with local project and with remote one
<AmanicA> ok
<bialix> you can start adapting one or another
<AmanicA> give me one
<bialix> remote is a bit smaller perhaps?
<bialix> test_project.py TestProjectRemote
<AmanicA> I don't mind, I'll have to figure it out anyway
<AmanicA> ok
<bialix> we need to teach the code about project-get from remote location
<ronny> hmm
<bialix> ronny: where anyvc lives?
<ronny> bitbucket
<ronny> http://bitbucket.org/RonnyPfannschmidt/anyvc/
<ronny> current state is good workdir support, lack of branch/repo abstraction + sync
<bialix> thanks, I'll look at the code later
<ronny> i also want to add support for vcs mappers at some point (ie bzr/git/hg svn extensions)
<bialix> what is "mappers"?
<LarstiQ> bialix: foreign branches/tailor style converting between vcsen
<bialix> ah
<AmanicA> bialix: TestProjectRemote.test_initialize is leaking threads among 3 leaking tests   do you want me to look at that too?
<bialix> no, I saw this. It has random effect
<AmanicA> ok
<bialix> monseur vila perhaps can shed some light
<bialix> but I suppose he is nothere
<bialix> AmanicA: I think we also need to collapse some commands together at some point
<bialix> e.g. project-get maybe should to get the branches as well?
<AmanicA> in stead of fetch?
<AmanicA> I see no test for project-get, local or remote
<ronny> LarstiQ: i dont want to mimic tialor, i want to utilize the buildins/extensions of the vcs's to deal with the 2way interop
<bialix> if it's not in test_cli.py then it's not written yet
<LarstiQ> ronny: I should have used parenthesis around (foreign branches/tailor) :)
 * LarstiQ heartily agrees not going the tailor route for an actual implementation
<ronny> hmm
<ronny> something no traditional vcs will ever be able to support is propper 2-way interop with darcs
<ronny> bascially the content of the workdir is a view on the merge of the current ends of the patch dependency graph
<bialix> AmanicA: I'll try to rework local.cfg to use branch.conf
<bialix> AmanicA: look at the end of the page: http://bazaar-vcs.org/ScmProj/Snapshot
<AmanicA> bialix: I think I must work on project-get  ie. write local and remote tests for it
<bialix> ok
<bialix> I'm working on local.cfg then
<vila> AmanicA, bialix: the socket leaking problem is a hard one, basically they are due to servers that are not able to shutdown properly because transports are still connected
<AmanicA> ok
<vila> And since transport API and usage provides no mean to close a connection, there is no easy way
<bialix> vila: I'm successfully can write the test with sftp server but it randomly leaking
<LarstiQ> ronny: yeah, it is possible to make a generalisation to support darcs, but not very useful imho
<vila> bialix: don't worry about that too much
<bialix> ok
<vila> Essentially the server close happen during gc so you have no control about it
<bialix> vila: btw I think this may affect bzr selftest on windows then, because this OS has limited resources for opened sockets
<vila> If and when the problem is solved, your test will stop leaking :-)
<bialix> it's already stops. no.. wait! it leaking again! :-)
<AmanicA> ooh that is bad, so longrunning apps that repeatedly connect to some server can run out of connections?
<ronny> LarstiQ: i think darcs is one of the best ideas to deal with development
<vila> The symptom when reaching socket limit is pretty heavy: most of the tests start failing very vocally... At least on linux, OSX solaris, (still not enough  experience under windows :-/)
<bialix> if they will not close sockets? yes, there possible problems then
<vila> AmanicA: not at all, the leaked sockets are the *server* ones
<bialix> IIRC on windows this number is about 1K
<ronny> LarstiQ: stuff like cherry-picking is just natural to it, and propperly propagates
<vila> the test server ones even
<AmanicA> ok, but cant you run out of server sockets
<AmanicA> if some app eg. bzr-eclipse connects repeatedly
<vila> AmanicA: *test* servers
<vila> only selftest is concerned
<AmanicA> okok, then its no big problem I guess
<AmanicA> :) thanks
<vila> It's a problem about relying on the gc to release resources
<vila> The leak test was added to have some idea about the problem scale because some other tests were failing under very weird circumstances, if you look at the output of a full test suite run, you should find the bug number and from there more info on the subject
 * vila wasn't there and should really go to hair dresser :)
<bialix> :-)
<AmanicA> :)
<AmanicA> bialix, I see the whitebox test for pget is for clone method
<AmanicA> so I will implement that for remote
<bialix> yes
<bialix> AmanicA: pushed changes in tests (s/create/initialize)
 * bialix lunch
<AmanicA> me too almost
<AmanicA> can I push to that branch?
<bialix> yes
 * AmanicA lunch
<Odd_Bloke> LarstiQ: Whereabouts are you?
<Lo-lan-do> Hi all
<Lo-lan-do> LarstiQ: In case you're looking for me, I'm in the lightning talks at least until the Bazaar one :-)
<LarstiQ> Lo-lan-do, Odd_Bloke : I'm heading to the lightning talks too, and otherwise I camp put at the debian  booth
<LarstiQ> and god is wifi horridly slow
<Lo-lan-do> LarstiQ: I'm in the front row
<Jc2k> anyone know where jelmer is hiding?
<Lo-lan-do> I've been looking for him today, since he's the only bzr face I know (and I've only known him since last night :-)
<LarstiQ> jelmer got at the hotel around 04:00
<Jc2k> ouch
<LarstiQ> he might be waking up now
<LarstiQ> \\
<LarstiQ> \\
<LarstiQ> \
<LarstiQ> \\\\\\\\\\\\\\\
<LarstiQ> gar
<LarstiQ> note to self, don't hold the laptop  at the keyboard
<AmanicA> bialix, code & test for project.clone(remote) committed. but you really need to review it.
 * Odd_Bloke is going to loiter outside the lightning talks room after the bzr one.
<bialix> ok
<AmanicA> bialix: I was able to open a remote project config
<AmanicA> why did you say we don't allow that?
<AmanicA> I think the problem it when it is just a branch an not a tree
<AmanicA> so I think we should just show a nice error if the file does not exist
<bialix> AmanicA: I think we should split the Project class on ProjectLocal and ProjectRemote
<AmanicA> why?
<bialix> AmanicA: because they should behave differently
<AmanicA> ok
<AmanicA> but thats a lot of work
<bialix> remote project config we need to read from RevisionTree, not from the disk
<AmanicA> do you want to do it now?
<bialix> yes
<AmanicA> ok
<bialix> I'll turn Project into base class with classmethods
<bialix> time to learn about metaclasses
<AmanicA> and make two classes that extend that one
<bialix> yes
<AmanicA> with a foctory method that instantiates ther right ome
<AmanicA> one
<bialix> so we don't need to check every time
<bialix> isinstance(self.t, LocalTransport) :-)
<AmanicA> yes, checking every time is a NASTY ANTI-PATTERN
<AmanicA> I know from experience :/
<AmanicA> anyways I could not make a test fail for the missing config file yet.
<AmanicA> I think I should go on with other stuff until you finished this refactoring
<AmanicA> (non scmproj stuff) so let me know when youre done'
<bialix> ok
<bialix> any python guru around?
<AmanicA> hi, what do you need?
<AmanicA> :)
<bialix> some hints about __new__()
<AmanicA> I thought you should do it like get_transport does it
<bialix> we can use it to create either local or remote instance based on transport supplied
<bialix> i think
<bialix> you think we should use URL instead of transport in the constructor?
<bialix> this may simplify something
<AmanicA> maybe
<bialix> ok, i tdd then
<AmanicA> yes I think that would be a nicer API
<AmanicA> I cant think of a case where we want to pass in a transport and not a url
<bialix> revolution continued
<AmanicA> Yeah!
 * AmanicA rebooting
<bialix> AmanicA: we need more blackbox tests
<AmanicA> I know
<bialix> :-)
<Kmos> i've removed a file in my repo.. bzr pull shouldn't re-update it ?
<Kmos> like svn up does
<Kmos> *in my local repo
<bialix> you need bzr revert
<Kmos> thanks
<Kmos> it worked
<bialix> AmanicA: ping
<AmanicA> pong
<bialix> i'm reworking your clone
<bialix> for remote: from url should be self.t.base
<bialix> can we omit accelerator_tree then?
<AmanicA> I don't think we really need it
<AmanicA> I think it makes it quicker
<AmanicA> when the remote side also has a working tree
<bialix> remote should not has wt
<AmanicA> why not?
<bialix> only local
<bialix> i guess because bzr does not support remote wt?
<AmanicA> say you and I push stuff between our scmprojs
<AmanicA> the you have a wt
<AmanicA> and I have one
<bialix> oh
<bialix> no
<bialix> we call remote different
<bialix> please update your branch
<bialix> ProjectLocal -- when the url is local path
<AmanicA> I still don't understand why you removed the BASE
<bialix> ProjectRemote -- when url is sftp://, http:// etc
<bialix> because we push to remote server just the branch
<bialix> I think we need to clarify it
<AmanicA> so does it not go into .scmproj?
<bialix> we == you and I
<AmanicA> exactly like the local version
<bialix> no
<bialix> you think we should?
<bialix> it will play badly with LP
<AmanicA> and with my gforge hosting
<bialix> gforge?
<AmanicA> since it does not show up on the frontend
<AmanicA> what we use at work
<bialix> never saw it in action
<Lo-lan-do> s/gforge/fusionforge/, man, keep up with the times!
 * Lo-lan-do does some advocacy
<bialix> oh
<bialix> i feel myself old-timers
<bialix> lol
<bialix> lo-lan-do has scared
<bialix> AmanicA: so you still think we should preserve .scmproj?
<bialix> for remote>
<AmanicA> I shink it forked from sourcefourge some time ago
<AmanicA> no
<bialix> great
<AmanicA> but that is how I thought when I coded it
<bialix> that's why i've started separate clasess
<AmanicA> so what we are talking about here is just the sharing of .scmproj
<AmanicA> not all its containing branches
<AmanicA> and the working trees
 * bialix going to change clone() to use url as parameter
<AmanicA> cool
<bialix> i think -- yes
<bialix> .scmproj at the disk is the branch
<AmanicA> please add some code docs as to what we decided now
<bialix> and we handle it as the branch
<AmanicA> yes
<bialix> it's better copy-paste to wiki
<bialix> i'd better finish code
<AmanicA> ok
<AmanicA> one sentence would help
<AmanicA> we can clean it up later
<bialix> AmanicA:             new_br = dir.open_branch()
<bialix> is it really needed?
<AmanicA> no
<AmanicA> I thought I removed that
<bialix> removed
<AmanicA> I was looking if it will be needed, and obivously forgot to remove it
<AmanicA> I told you, that you have to review this code, because I was unsure of what it was supposed to do. I
<AmanicA> I'm glad you are catching these
<bialix> man, I don't understand whty i've started to use transport instead of url
<bialix> code is much better now woth urls
<bialix> with
<bialix> heh
 * AmanicA food again!
<AmanicA> yes
<bialix> !
<bialix> ashes on my head... :-[
 * bialix committed and going for some coffee
<nagyv> hi! I'm trying to compile and install bzr into a --no-site-packages virtuanenv on an ubuntu hardy, but building btree fails. Do I miss some header packages? If so what? here is the traceback: http://pastebin.com/m12e1efca
<bialix> nagyv: looks like you need python-dev package
<bialix> or something like this
<nagyv> bialix: thx, just found it out myself as well :)
<bialix> k
<luke-jr> so to solve the "copy" debate-- why not simply have 3 operations: move, template, and split?
<LaserJock> this is your daily ~bzr PPA ping, any ETA on bzrtools? :-)
<bialix> luke-jr: hm?
<luke-jr> bialix: 'move' is straightforward and already implemented
<luke-jr> 'template' would mean basically "add with history"
<luke-jr> 'split' would try to merge changes in both directions, and conflict if there was a problem
<bialix> AFAIK the main problem is file-id
<luke-jr> ?
<bialix> bzr internally works in the term of file-id
<luke-jr> o
<bialix> it's like inodes
<luke-jr> some kind of "split/templated from <file-id>" metadata?
<bialix> try to search ML archives for `path tokens`
<bialix> IIRC
<bialix> jam knows everything, are you here?
<bialix> I think main problem here is that internally bzr should change support of only one file-id to to several (aka aliases)
<LaserJock> if I "downgrade" a branch format will it bother people who already have branched?
<bialix> no
<bialix> unless you going downgrade to knits
<tro> jelmer: what type of a shared repo do i need to have to clone http://people.samba.org/bzr/jelmer/bzr-local-branches/trunk/ ?
<bialix> yo jelmer!
<AmanicA> so bialix how's it hangin?
<bialix> tro: bzr info http://people.samba.org/bzr/jelmer/bzr-local-branches/trunk/ -v   will tell you (but i guess --rich-root-pack)
<bialix> AmanicA: hanging?
<tro> bialix: thanks. just figured that out myself too :)
<AmanicA> yes
<bialix> what do you mean?
<AmanicA> :)
<bialix> I'm back to new local config stuff
<AmanicA> how is it going with that refactoring
<bialix> ah
<bialix> basic things are done
<bialix> we need to move almost everything to ProjectLocal
<AmanicA> let me know when I can start breaking stuff again:)
<bialix> but mandatory parts (open and clone) already there
<bialix> green light
<bialix> i'm grinding config.py
<bialix> AmanicA: perhaps we should think about all 4 variants of clone, but current 2 is ok for me
<AmanicA> yes
<AmanicA> they are the most important ones
<bialix> so project.py is open for hacking now
<Odd_Bloke> jelmer: Whereabouts are you?
<AmanicA> hurray all our tests are passing, this makes develoment easier: less noise
<AmanicA> bialix, it there something specific you want me to tackle next?
<AmanicA> btw thanks for fixing the tests
<bialix> i've just disabled 4 of them for now to remove noise
<bialix> will be very nice to have more blackbox tests if you don't mind
<AmanicA> excelent
<AmanicA> that was what I was thinking too
<bialix> perhaps with new local config our progress will be strugled
<bialix> s/with/without/
<AmanicA> not sure I understand
<AmanicA> I'll start with pget, as I think I now know what it does, will see about code docs while I'm at it
<bialix> local config used for run_actiona and fetch
<bialix> AmanicA: ping
<AmanicA> hi
<bialix> it will be much simpler if we using for local config only branch config and never fallback to global bazaar.conf
<bialix> objections?
<AmanicA> for what again
<AmanicA> for current subset
<bialix> http://bazaar-vcs.org/ScmProj/Workspace
<bialix> we need to store this option, and we could put it in global config
<bialix> but it's only one universal option I see today
<AmanicA> is it just more effort now?
<AmanicA> I think if we do realise we want it we can add it later
<bialix> more effort now, may be i'm just defer it till we start using it
<AmanicA> yip
<bialix> ok
<bialix> thx
<bialix> AmanicA: local config there. my brain has slowed down, so i'm finished today.
<AmanicA> cool
<AmanicA> it was excelent
<bialix> yes
<AmanicA> we should do that more often
<AmanicA> I'm still busy
<bialix> it's break through (I guees it's right term)
<bialix> I can help with advices
<AmanicA> I'm addind better online help for pget
<bialix> but can't do review today
<AmanicA> aah
<bialix> and i believe you can jongle with english words better than me
<AmanicA> I'll commit when I'm done and you can review it when you feal like it
<AmanicA> I try
<AmanicA> I write it mostly for myselg
<AmanicA> myself
<bialix> i think we need to make pget more powerful
<AmanicA> since I have to figure out what it actually does in order to test it
<AmanicA> I'm writing it down as I go
<AmanicA> in the right place
<bialix> i've made several simple commands (pget, pfetch, pco) to test them easily manually
<AmanicA> yes
<AmanicA> what about pmanage :)
<AmanicA> which can do al management tasks
<bialix> but now i feel we need to collapse them, or at least try to collapse
<bialix> lol
<AmanicA> lets see how it goes
<AmanicA> don't think tooooo hard about it
<bialix> and then we will have only one command with zilllion of options
<bialix> and manpage on 100 pages
<bialix> :-)
<AmanicA> :D
<bialix> I'm trying to joke
<AmanicA> I have a question actually
<AmanicA> with pget a non-existing/b
<AmanicA> do we just go ahead and creat-prefix
<AmanicA> or should we ad an option like bzr branch?
<bialix> i'd prefer to be explicit
<bialix> i.e. option
<bialix> but currently we don't support this at all
<bialix> so i don't mind to keep it till first bug report
<bialix> btw, i'm just thinking: we can use pull instead of sprout for pget
<bialix> today we leave one bug there
<bialix> pget over already existing project should fail
<bialix> but this is for tomorrow
<AmanicA> ok
<AmanicA> but
<AmanicA> `pget a non-existing` also fails
<AmanicA> since we branch into non-existing/.scmproj
<bialix> AmanicA: thanks for the sprint. you rocks
<AmanicA> :)
<AmanicA> cool man I enjoyed it
<bialix> AmanicA: so using pull instead of sprout for *->local should help
<bialix> i.e. we should create branch in the .scmproj first and only then pull
<bialix> may be we need to refactor it in next few days
<bialix> with fresh brain
<AmanicA> should we creat the project dir?
<bialix> imo yes
<AmanicA> ok I'll do that for now
<AmanicA> I aggree
<bialix> but only if it's only one level absent
<AmanicA> exactly
<bialix> cool
<AmanicA> cool bananas
 * bialix thinks it was joke.
 * bialix also thinks he need to say "bye"
 * bialix buy
<bialix> err
<bialix> bye AmanicA
<AmanicA> bye
<infinit> I need some compelling reasons why to move from svn to bzr.. can anyone give me some reasons?
<LaserJock> infinit: I would think that would sort of depend on what things your doing with svn
<LaserJock> I certainly like not having to worry about svn servers
<LaserJock> easy branching and merging
<LaserJock> and distributed revision control in general seems more flexible and freeing
<infinit> the reason  is I wanna use launchpad and they have bazaar
<infinit> I've always used svn
<LaserJock> yeah, code hosting is great
<LaserJock> infinit: you can use Launchpad and bazaar pretty much the same as svn too
<LaserJock> pretty much the same workflow
<infinit> bbut what happens to my current repositories
<LaserJock> you can convert them to bzr if you like
<infinit> how do I do that?
<jdong> infinit: the bzr-svn plugin seamlessly speaks bzr
<jdong> for example, I just branched the entire Monodevelop SVN tree by bzr branch svn://monodevelop.org/......
<jdong> you can use that to convert your existing svn repos into bzr branches
<LaserJock> infinit: bzr-svn works very well
<LaserJock> you can use it to go back-and-forth with an svn server or to convert svn repo to bzr
<infinit> and then I just deal with the bzr repository?
<jdong> yep
<jdong> the plugin can be used to import svn branches into bzr, or sit somewhere in-between and use bzr as a svn client too
<infinit> so using bzr-svn converts my repo and I can put it on launchpad
<LaserJock> infinit: a very simple thing to do would be bzr branch svn://<your svn repo> , then bzr push to launchpad
<jdong> right. bzr branch svn://somewhere; bzr push lp:~your_id/something :)
<infinit> cool
<infinit> thats great
<infinit> thanks guys u saved me a lot of time
<jdong> sure thing; you'll enjoy using bzr :)
<infinit> i'm sure i will
<jdong> the ability to branch-and-merge carefree will prove very useful
<jdong> not to mention there's really no such thing as a special server for bzr (rather, no necessity for)
<jdong> setting up a svn server was one of the most annoying parts of using svn
<infinit> so its not like svn that needs specific server to deal with it?
<LaserJock> infinit: nope
<jdong> right. a bzr branch contains all the info bzr clients need to know
<jdong> you can just shove that onto an Apache server
<jdong> or over a FTP server. Or with SSH access.
<jdong> at work due to limited connectivity we're simply zipping up bzr branches and using e-mail
<jdong> it's so flexible.
<jdong> there is a specialized "smart server" that enables faster operations, but it's not at all a necessity
<infinit> so I can even use my own webserver to keep the bzr branch and then use it online?
<jdong> absolutely
<infinit> that awesome
<jdong> yeah :)
<jdong> even amongst the distributed VCS'es, few are as flexible as bzr in this regard
<infinit> its amazing I really need that kind of flexibility
<infinit> there is no reason to stay with svn
<jdong> that's what I think :)
<jdong> you can do with bzr anything you can do with svn anyway.
<infinit> and i assume there is plugins for eclipse as well?
<jdong> http://bazaar-vcs.org/BzrEclipse
<jdong> haven't used it personally, but yeah
<jdong> I recently started using the bzr QT4 frontend a bit; it's pretty nice too
<jdong> works consistently across all major platforms
<infinit> great..I am a huge QT fan
<infinit> and do u know if there is any plugin for emacs
<infinit> ?
<jdong> I'm not sure
<infinit> anyway I am gonna use the command line
<jdong> for 99% of tasks I prefer the bzr command
<jdong> it's consistent and familiar
<infinit> I wish I'd found this channel last year..
<infinit> I have to convert about 20 repos now
<jdong> I do like the QT4 frontend's "qdiff" and "qlog" commands
<jdong> the diff representer looks really nice
<infinit> what is the gui called? just QT bzr frontend?
<jdong> QBzr
<infinit> cool
<jdong> and, if you have to deal with any Windows clients, I'll tell you right off the bat bzr is pretty much the only DVCS with good Windows support.
<infinit> I am anti windows
<infinit> linux is the way to go
<Pieter> I heard mercurial has decent windows performance, especially compared to bzr
<infinit> I always do my coding in linux,, thats not gonna be necessary
<jdong> I natively prefer Linux/*nix too, but in large(r) FOSS projects you're bound to run into Windows users too...
<jdong> Pieter: the performance is good but the integration isn't as good
<jdong> the bzr 1.11 installer puts in that Tortoise shell plugin, a "start bzr cmdline here" option, and the qbzr commands...
<jdong> I've used it to convince several coworkers to start using bzr
<infinit> jdong: u are a great bzr advocate...
<jdong> haha, well I'm just a happy user
<jdong> I don't have any "connections" with the bzr project other than I use it
<infinit> u certainly convinced me to use it.. I just needed some reasons
<jdong> setting up bzr is like a 5-minute job compared to the initial setup of svn for a newcomer... It's worth a personal try :)
<sohail> hey when I'm done with a branch, can I just rm -rf that branch
<sohail> or is there some bzr command to do it
<LaserJock> rm -rf works
<sohail> thanks
<jdong> ah, I love bzr-pager :)
<jdong> the only thing that git did right.
<LaserJock> jdong: for sure
<LaserJock> I really like how git displays things
<jdong> the various built-in use of color is nice too
#bzr 2009-02-08
<KhaZ> Hrmm.  I'm trying to use 'bzr launchpad-login' and I get a crash within urllib2_wrappers.py.  Anyone not going wrong?  Am I running an inappropriate version of Python for use with bzr?  (2.5.2?)
<Peng_> KhaZ: bzr version, and pastebin the traceback
<KhaZ> I'm running 1.12 dev.  Let me get on that pasetbin.
<KhaZ> *pastebin
<KhaZ> http://pastebin.com/m38be0452
<Peng_> KhaZ: That's a known bug. It's been discussed on the mailing list a bit.
<KhaZ> Ah.  Is there a workaround?
<Peng_> KhaZ: Well, you could revert to an older revision, or apply the patch on the list.
<Peng_> KhaZ: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/52120
<KhaZ> AH, thanks for the thread.  I'll dig around a bit.  I wonder why the patch isn't in dev?
<Peng_> KhaZ: Cuz it only came up today.
<KhaZ> Outrageous.  Turn around time in bzr isn't instantaneous?  I'm apalled.
<KhaZ> ;)  Anyhow, thanks Peng_.
<yml> hello good evening
<yml> I have put some file on the shelve :  bzr shelve file1 file2 file3
<yml> in order to do an automic commit
<yml> now I would like to bring them back into my working tree
<yml> I found that bzr unshelve do what I want but I can have several shelve I would like to know if it is possible to :  list them, name each shelf wit a meaning full name, explore their content ?
<bob2> yml: bzr help shelve/bzr help unshelve
<yml> bob2 I read them both but I haven't find answer to my questions
<Peng_> jelmer: Is bzr-svn's "discovering revisions" progress bar supposed to say the progress is a negative number?
<Lo-lan-do> Oooh, network <3
<Peng_> ?
<Lo-lan-do> FOSDEM wireless.
<Peng_> Ah.
<Lo-lan-do> Let us say it hasn't proved very reliable yesterday.
<Lo-lan-do> LarstiQ: I pushed the current (almost empty) results of what we did yesterday at http://bzr.debian.org/bzr/users/lolando/misc/bzr-gc
<jelmer> Peng_, Nope, that's a bug.
<AfC> Uh
<AfC> $ bzr info
<AfC> Repository branch (format: 1.12-preview or 1.9)
<AfC> ...
<AfC> what the hell?
<jelmer> AfC, Hi!
<jelmer> AfC, ?
<jelmer> AfC: What is the problem there? The fact that it mentions two formats?
<jelmer> AfC, this is because those formats are the same except for the working tree format
<AfC> I'm asking what's with the "or" in the statement given by `info` about the format in place in the branch. Given that it was created with --format="1.9" I have no idea what that statement means,.
<AfC> But worse is that it sounds like Bazaar doesn't know.
<jelmer> the problem is that if there is no working tree, there is no way to distinguish between the two formats
<AfC> I cannot believe the core developer of a tool that purports to be a clean user experience exposed that kind of uncertainty in the UI.
<AfC> jelmer: perhaps I could suggest that if there is no Working Tree present to not report about such things then. If it doesn't know, it doesn't know.
<jelmer> AfC: In that case, it couldn't print a format at all if you are in a shared repository
<jelmer> AfC, there is technically no difference between the two formats if you don't have a working tree, so I don't think there is any uncertainty here
<jelmer> AfC, I can agree it's a bit strange, but I don't see a good way to fix this..
<jelmer> AfC, what would you rather see?
<jelmer> bzr could just show you one format I guess, that would be technically less accurate but less confiusing too
<AfC> I just don't want Bazaar embarrassing itself in front of users. We made so much of the premise that bzr was a better user experience than other tools, but this is precisely the sort of thing that causes us to squander such branch equity.
<AfC> ... such brand* equity.
<AfC> :)
<Peng_> Can we file that under "yes, we know bzr has too many formats" and ignore it? :D
<LarstiQ> Jc2k: you around somewhere?
<bialix> Peng_: what? again?
<Peng_> bialix: It was about "bzr info" showing stuff like "Repository branch (format: 1.12-preview or 1.9)" :)
<bialix> oh
<bialix> wait
<bialix> how about this:
<bialix> Lightweight checkout (format: 1.6 or 1.6.1-rich-root or 1.9 or 1.9-rich-root or dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)
<bialix> IMO there is stil the room for dozen formats
<Peng_> Hahaha. That's excellent. :)
<Peng_> Too bad the subtree formats are hidden.
<bialix> yeah
<Peng_> I think we scared AfC away.
<bialix> :-D
<bialix> lol
<LarstiQ> poor guy :)
<Peng_> Wait a minute, why is the lightweight checkout list in that order? In order of age, that's like 5, 5, 6, 6, 1, 2, 3, 4, 3.
<Peng_> Err, that should be 5, 5, 6, 6, 1, 2, 4, 3, 4.
<Peng_> ...Oh, alphabetical.
 * Peng_ bonks himself on teh head
<bialix> we need add randomizer I guess
<bialix> so there will be everytime something new
<Peng_> That's a horrible, evil, excellent idea.
<Peng_> ...It'd make blackbox tests a bit tricky though.
<bialix> put them in a set?
<bialix> and check the set
 * bialix don't think there is blackbox for light checkout info
<Peng_> Good point. It would still be slightly more complicated though.
<Jc2k> LarstiQ: im at the front of the cross desktop room
<Adys> This sounds stupid, but I cant find how to refetch a folder I deleted by mistake from the remote working branch
<Adys> er, make that, refetch the folder from the remote working branch, which I deleted locally
<Adys> right, bzr revert *
<bialix> what is the equivalent to os.path.join in bzrlib? osutils.join?
 * bialix found osutils messy
<santagada> bialix: http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.osutils.html
<santagada> I think it is joinpath
<pi_m> Hi. Can I ask you? I am new to Bazaar and I really, really can't understand one thing (yes, I have read the user guide and the user reference manual first). It is shared repository. In the texts mentioned above is written that shared repository is created after "init-repo" command. New branches could be created by "init" command executed from the shared repo. Can you tell me what the branches share and if they depend on other branches in the shared repo?
<bialix> share history
<pi_m> bialix: History? Do you mean the commits?
<nevans> yep.  all of the commits are stored in the shared repo.  so if two branches have the same commits, then they won't be duplicated
<nevans> it becomes a little bit more obvious if you sneak a peek into the .bzr directories.
<bialix> yep
<nevans> normally, a branch's .bzr dir will contain a branch, checkout, and repository subdirs
<nevans> for a standalone branch, that is.
<santagada> in the end the result is the same as the common working of svn I think
<santagada> is you copy files around it will not copy history
<santagada> copy/branch
<pi_m> nevans: So it is good to have a shared repo if you have some branches that have some common code (uh)?
<santagada> pi_m: only if they share the same commits
<nevans> pi_m: common history.  I use shared repos whenever I expect to work on many branches of the same project.
<santagada> pi_m: which is the usual thing when you work on branches
<bialix> santagada: joinpath -> Undocumented :-P
<bialix> I guess pathjoin actually is right
<nevans> actually, I've got a single shared repo for all of my work projects... even though some of them don't share commits.  it's just simpler than having a shared repo per project.
<pi_m> santagada: Yes. So placing the different project's branches to shared repo has no sense, I think...
<santagada> bialix: at least you know the name :D
<bialix> problem is: there are 2 functions: joinpath and pathjoin
<santagada> pi_m: it doesn't help... but it is not a performance problem either (i'm guessing here)
<nevans> pi_m: if you look into a branch's .bzr (under a shared repo), you'll only see branch and checkout dirs.  and the shared repo's .bzr will contain the repository.
<nevans> and if you run du on any .bzr dir, you'll see that the repo dir is always the largest.
<bialix> santagada: pathjoin = os.path.join
<bialix> :-P
 * bialix anyway thinks osutils.py is messy
<santagada> bialix: thanks... i'm also trying to learn the bzr api
<nevans> pi_m: so if you have 5 branches that are fairly similar (and most branches within a project are), and their working trees take ~20MB, and their repos each take ~100MB, then it would take ~600MB to store them without a shared-repo, and ~200MB with a shared repo
 * bialix using this api for several years and anyway it's messy
<nevans> and since there's less disk usage, certain operations will also run more quickly with a shared repo (e.g. bzr branch)
<pi_m> Thank you, your advices were very useful!
<KhaZ> Can I ask why there is an osutils versus using the os.path stuff?
<bialix> KhaZ: cross-platform support
<santagada> let's just be franc that os.path.join is cross platform
<santagada> what is diffente on osutils? stat?
<KhaZ> Aye, I thought os.path.join *is* cross platform.  Although I do realize that a lot of stuff in Python wraps it nicely but doesn't necessarily yield the same results..
<bialix> the difference is: osutils try to canonicalize the path after transformation to one standard
<bialix> always / as path separator, even on windows
<bialix> fix drive letter for windows and some other small details
<KhaZ> Ah, gotcha.  Hrmm.  I'm sure the patch I submitted'll be rejected based on that alone. ;)
<bialix> what?
<KhaZ> Heh, just that I ended up using os.path and stuff directly in the patch I submitted w/RFC.
<bialix> don't worry, you'll get detailed review and precise hints what to use instead
 * bialix son't remember all gory details
<bialix> s/son't/don't/
<KhaZ> Just be gentle. ;)
<bialix> sorry
<Phill> Hey guys, I'm confused on how to use bzr, what should I be doing... (bzr add, commit, and then push?) or should I have done merge? It's a two person project, and now we seemingly messed it up with conflicts in some auto-gen files. I'm thoroughly confused.
<bialix> if the files auto-generated you'd probably better re-generate them?
<Phill> I can't seem to do that?
<bialix> I don't understand
<Phill> Well, I don't know why, but it seems bzr thinks there was a conflict and put it's TREE, MERGE etc things into the file.
<Phill> The file was created once... I don't think it should've ever changed, so I don't know why Bzr says it changed, here, one second, let me look at it's diff.
<bialix> do you know how to solve 3-way merge conflicts?
<Phill> Nope!
<Phill> I don't know how to solve 2-way merge conflicts :)
<Phill> Ignorance ain't bliss.
<bialix> read `bzr help conflicts` first, please
<Phill> Aight.
<bialix> you're interested in text conflicts section
<Phill> Yeah, reading that now.
<Phill> I think, I can actually auto-gen this file, but not the others, let's give the auto-gen a shot.
<bialix> yep
<Phill> Ok, so, it just to make sure I have this clear, it sticks two files into each other if it doesn't know what to do?
<Phill> Like, the earlier revision, and then the later one?
<bialix> no
<bialix> it tries to be intelligent and combine common parts together
<Phill> Then why does it look like the same xml document twice over?
<bialix> if you have 2 files entirely in conflict there is different line-endings perhaps
<Phill> Mmm.
<bialix> check .THIS and .OTHER in binary mode
<Phill> I just deleted the second one and hope it works ;-) (That's bad practice!)
<bialix> you can repeat merge ;-)
<bialix> `bzr resolve` will delete this junk automatically
<Phill> Ok, so I'm taking it my usual, "Bzr add, commit, pull" isn't the way to do stuff?
<Phill> Not pull, push I mean.
<Phill> bzr add, commit, push
<Phill> I always thought push and merge were the same thing...
<Phill> bialix: Or let me rephrase, I Thought pushing merged as well - automatically,  take it as a no?
<bialix> no
<bialix> you should get 'branches are diverged' error -- then you need to merge locally and then push again
<Phill> They weren't diverged (I assume, I never got that error), it was 20-21 21-22, etc. Basically, I worked on it, then my friend did, we just kept our code base in sync...
<Phill> He worked at home, I worked at school, so - that's why we never merged.
<bialix> you're pull when you need get his changes
<Phill> Yep, that's what I did.
<bialix> and push when you need to publish your changes
<Phill> and then I pushed when I had changes.
<bialix> so?
<Phill> Why the conflicts?
<bialix> you did pull?
<Phill> Yep.
<bialix> you had uncommitted changes in your branch
<Phill> Yeah, About to say that.
<Phill> And then I pulled.
<Phill> = Errors.
<Phill> Right?
<Phill> Should I always commit before pulling then?
<bialix> bzr did merge for you because you had uncommitted changes
<Phill> Then merge before pushing?
<Phill> Ahh, that's nice of it.
<bialix> you'd better have 2 branches
<bialix> 1 branch is exact mirror of remote
<bialix> 2nd branch for your own work
<bialix> you did pull only in 1st branch
<Phill> I didn't even know I had two branches.
<bialix> no
<bialix> sorry
<bialix> may be my English is not ideal
<Phill> Nah; not your fault, I don't know what I'm doing. (That's my fault) :)
<bialix> will be better if you create 2 branches to work on
<Phill> Yeah.
<Phill> and then merge them, right?
<bialix> if they are diverged -- yes merge
<Phill> Yeah.
<bialix> if not diverged -- just pull from 1 to 2
<Phill> Yeah.
<Phill> Diverged means, mismatched revision numbers - right?
<bialix> you can do `bzr merge --pull` and bzr selects appropriate action to you
<bialix> not exactly numbers
<bialix> say you have revision 20, and your friend too
<bialix> your branches are full mirror of each other
<bialix> then you change say file foo.txt and commit
<bialix> but in the same time your friend change file bar.txt and also commit
<bialix> you both will have revision 21, but they are different
<Phill> so, I should do bzr merge -pull from now on? So it just does whatevers right for us?
<bialix> ok?
<Phill> bzr merge --pull
<Phill> Yeah, that's cool.
<Phill> I get it now :)
<bialix> yes, it's safe choice
<bialix> you can create alias
<Phill> Boy do I need that one then ;-)
 * bialix is not boy
<Phill> Er, figure of speech.
<bialix> creating alias will save you typing this everytime
<bialix> check `bzr alias -h` for details
<Phill> I don't have alias?
<Phill> bzr alias -h bzr: ERROR: unknown command "alias"
<bialix> bzr version
<bialix> what is your bzr version?
<Phill> Bazaar (bzr) 1.3.1
<Phill> I take it, that that is old.
<bialix> very old
<Phill> :)
<Phill> I probably got it from the repo long ago.
<bialix> you'd better upgrade
<Phill> Yep, yep.
<Phill> Haha.
<bialix> I bet you're on Ubuntu
<Phill> Haha.
<bialix> no?
<Phill> Wow, Ubuntu is going to be what Windows was to the world. "Oh, you're on "UBUNTU".
<Phill> Yeah I am.
<bialix> I'm on Windows
<bialix> hehe
<Phill> I never upgraded the newest version of Ubuntu, I don't really care for it - waiting for 9.10 (I think) in April.
<bialix> read instructions on how to update bzr at bazaar-vcs.org
<Phill> And I think I installed this through a .deb package so it doesn't auto-update. =/
<Phill> I can't uninstall/reinstall newest?
<bialix> go to Download page, look for Ubuntu and read instructions
<Phill> kk
<bialix> you should be able to aapt-get
<Phill> Oh cool, it has it's own apt server.
<Phill> Didn't know this.
<bialix> many people don't know
<Phill> I don't get it... bzr is worked on by conical - why don't they just put it in the main repo branch?
<Phill> Bazaar (bzr) 1.11
<Phill> Now what?
<bialix> where?
<Phill> Huh? That's what my up-to-date bzr is.
<Phill> 1.11, rather than whatever it use to be.
<bialix> now `bzr alias` will work :-)
<Phill> Cool.
<bialix> :-D
<Phill> Ok, so if I do bzr resolve, it delete the >>TREE stuff, right?
<bialix> yep
<bialix> np
<bialix> no
<bialix> sorry
<Phill> Confused, what?
<bialix> you need to resolve conflict (with meld e.g.) and then run `bzr resolve`
<Phill> meld?
<bialix> if the file has no '<<<< >>>>' markers then .THIS .BASE .OTHER files will be deleted
<Phill> Yeah, it's just a properties file that I don't care about, so I removed the <<<< markers and called it a day. ;-)
<Phill> Probably not a good thing, but whatever.
<Phill> Ok, here's a good one.
<Phill> Text conflict in pangea/nbproject/genfiles.properties
<Phill> That file doesn't exist?
<Phill> Found out why, I deleted it, my bad. Nevermind.
<Phill> Ok, so all my conflicts are gone, thanks to ya' :) Though, here's what I need help with, sorta? It'll take a second to type it down - ready?
<Phill> I've branched from revision 20 (the last one that worked) and pulled to 21, and then fixed the conflicts. The latest revision however is 23.
<Phill> How can I merge with 22-23?
<bialix> brrr
<bialix> again
<bialix> bzr commit your current state
<Phill> Did so
<bialix> then bzr merge
<Phill> I did...
<Phill> bzr merge --pull
<bialix> so?
<bialix> bzr st
<Phill> actually, I did bzr merge --pull -r 22
<Phill> I don't want rev 23 atm.
<Phill> Two conflits.
<Phill> Conflicts*
<bialix> resolve them
<bialix> then commit
<Phill> Ok, this is a different conflict though.
<Phill> Conflict adding file pangea/build/classes/pangea/resources/New Folder.
<Phill> The other thing is I have "PangeaVIew.class" to PangeaView$39.class, (Using Netbeans) but I think these files were from bzr. Do I need them?
<Phill> Nevermind, I answered my own question, Yes I do need them.
<Phill> bialix: Ok, so - here's one more thing I want to know how to do, remove stuff from bzr version control.
<Phill> I have a lot of junk classes and old images I no longer want bzr to keep track of, in fact, I wanted them deleted.
<Phill> What do I do?
<bialix> either just delete them
<bialix> or use bzr remove
<bialix> with bzr remove you have fine grained control, read `bzr remove -h`
<Phill> I used bzr remove.
<Phill> Deleting them made bzr just throw them back up when I pull again.
<bialix> delete + commit
<bialix> but `bzr remove` is better way
<Phill> Mmk.
<bialix> "explicit"
<Phill> Off hand, what's the better thing about it?
<bialix> explicit is better than implicit
<bialix> just don't forget commit
<bialix> Phill: try this `python -c "import this"` :-D
<Phill> I've learned not to use commands that I don't know, but hey, you can try rm -r /
 * bialix on Windows
<Phill> Oh right.
<Phill> Darn.
<bialix> :-P
<Phill> Open up fdisk and figure out how to nuke your cdrive, I'm to lazy. ;-P
<bialix> format c:
<bialix> it's easy
<Phill> Yeah, I've since forgotten 90% of the commands that aren't related to the Cisco IOS.
<Phill> It's a bummer.
<bialix> ok
<Phill> Ok, now this is the last thing, bzr alias?
<thumper> morning
<bialix> just remembered: if you like the risk in life, try to run format c: drive
<Phill> Thumper?
<thumper> Phill: I may have missed some context, but aliases aren't exactly new
<Phill> Oh no, I think I recognized you from another form.
<Phill> forum*
<bialix> Phill: last thing for what?
<bialix> thumper: hi
<Phill> Thumper: Ever been on the Firefox support forums?
<thumper> Phill: no
<Phill> Thumper: Wrong thumper then.
<bialix> no, he's right thumer
<thumper> Phill: just different :)
<Phill> Ahh.
<Phill> What's a good alias for bzr merge --pull ...
<bialix> maybe: get-the-new-stuff
<bialix> ;-)
<Phill> Mmm.
<Phill> get-new
<Phill> OR, sync.
<bialix> not bad
<Phill> get-sync
<bialix> actually I think "sync" is good
<Phill> yep
<Phill> and the command was "merge --pull" right?
<bialix> right
<Phill> Neeto.
<Phill> That's not a word.
<bialix> Ð½Ðµ ÑÐ¾?
<bialix> or Ð½Ðµ ÑÑÐ¾?
<Phill> I don't know?
<Phill> Ok, so, when I push back up, I can just run bzr push right?
<bialix> never mind
<Phill> Or should I do "bzr merge --push" ?
<bialix> yes
<bialix> no
<Phill> ok
<bialix> merge is when you get the new stuff
<bialix> you can't do merge for remote server
<bialix> just push
<Phill> Oh ok.
<Phill> Well thanks.
<Phill> Any other cool things you could teach me about launchpad and bzr? lol
<bialix> tomorrow
<Phill> haha
<Phill> sure ;-)
<lifeless> Adys: just revert foldername
<lifeless> Adys: or if you want to revert everything, just 'revert'
<tro> did anyone end up volunteering for that editor thing kfogel proposed on the ml?
<Stavros> hello
<Stavros> i tried to do bzr shelve and bzr is crapping out now
<Stavros> i have 1.11
<garyvdm> Stavros: crapping out -> how? Can you pastebin a traceback?
<Stavros> it's not crashing, but bzr shelve tells me that it can't acquire a lock and then does strange stuff like telling me to break a lock before telling me again it can't acquire another
<Stavros> bzr: ERROR: Could not acquire lock "repo/.bzr/checkout/dirstate"
<garyvdm> It should tell you who created the lock that is blocking you.
<Stavros> i'm the only user
<tro> Stavros: are you using windows?
<Stavros> yes
<tro> i think you may be using the new shelf (shelf2) which doesn't work with windows yet
<Stavros> oh
<Stavros> hmm
<Stavros> shouldn't it print something, then? :/
<tro> there's probably a way to use shelf1. maybe someone else knows?
<Stavros> it's okay, i just wanted to shelve one file, so i committed it, but the errors were odd
<tro> i'm still using an older version of bzr, so i don't know what the solution is, sorry :/
<Stavros> ah, thanks anyway
<thumper> you could alias shelve to shelf1 (if that is the command)
 * thumper wonders why the new shelve doesn't work with windows
 * thumper looks at abentley
<thumper> abentley: should the new shelve have problems with windows?
<bialix> 1.12 should work fine
<bialix> jam fixed it
<garyvdm> Hi bialix
<bialix> Hi Gary
<bialix> I've edited NEWS
<bialix> you'd better look at it with fresh eye
<garyvdm> Ok - will do
<bialix> because difftools is not mandatory thing
<bialix> as you said
<bialix> Do you have specific question to me?
<garyvdm> I've been trying to build a deb - but I got frustrated - move on to more intresting things.
<garyvdm> I'm looking at how I can use igc's revno-cache plugin to improve qlog's startup performance
<bialix> ouch
<bialix> garyvdm, we can skip the deb, I guess
<bialix> at least people don't poke us everyday
<bialix> as they are do about bzrtools
<bialix> ;-)
<garyvdm> And the deb can come after the release - hopefully shortly
<bialix> garyvdm: about revno-cache
<garyvdm> If we use revno-cache - we would have to stop showing the children in the revision plane
<bialix> igc told me it's working mostly as revno->revid map today
<garyvdm> because you have to walk the whole tree to find the children.
<bialix> um? sorry, can you explain
<garyvdm> In the bottom plane of qlog - we show parent and children for the selected revisions
<garyvdm> *revision
<bialix> yes
<bialix> we show both revno and revid
<garyvdm> To find the parents - you just have to make one call to the graph
<bialix> I think it should simplify walking through the history
<garyvdm> but to find the children - you have to load the parents for every revisions.
<garyvdm> Right now - we have to do that anyway to create merge_sorted_revisions
<kfogel> tro: no, but people have been writing the scenarios, and I've been using them to help with, e.g., http://www.emacswiki.org/emacs-en/EmacsBzrSwitchover
<bialix> wait, I'm running qlog to follow you
<kfogel> tro: I suspect I'll just end up editing them myself
<kfogel> tro: unless... you're volunteering to help? :)-
<kfogel> :-)
<garyvdm> revno-cache caches merge_sorted_revisions
<garyvdm> I can do all the other functionality just from the data from merge_sorted_revisions - with out loading the whole graph
 * bialix ran qlog with LANG=C and sees now what garyvdm means
<garyvdm> except displaying children
<bialix> this is qreat idea
<garyvdm> qreat - intentional mistake?
<bialix> no, by Freud
<garyvdm> ha ha
<bialix> so
<bialix> we'll lose the ability to find branched history?
<bialix> I can't say I'm use the parent/children links too much
<garyvdm> No - qlog will be able to do everything it currently does, except display children in the revision plane.
<bialix> so I'm probably even did not notice if they disappear
<garyvdm> And only load the parent for the revisions that are diaplayed
<bialix> garyvdm: I mean no more click on children will go to that revision
<garyvdm> Yes
<bialix> may be it's better to post this as rfc to qbzr ml. if luks won't object -- I'll be fine
<garyvdm> Ok - WIll do
<bialix> in theory we can load this data lazily in the background after main history has loaded?
<garyvdm> Yes - we can do that to
<bialix> how we'll behave without revno-cache?
<garyvdm> Good idea
<garyvdm> Same as before
<bialix> I like it
<bialix> qbzr reuse many goodness already exisiting in bzr world
<garyvdm> And it will only do this if you are loading 1 branch.
<bialix> btw Gary, I'd like to discuss with you dichotomy with 1/several branches
<garyvdm> If you are loading more than 1 branch - It will have to load everythin.
<bialix> ah
 * garyvdm looks up the meaning of dichotomy
<jelmer> Jc2k, I fixed dpush into git on the train, it's working now :-)
<bialix> garyvdm: I want to add more actions to context menu
<garyvdm> ok
<bialix> like tags, push, merge
<garyvdm> revert
<bialix> but those actions should know the branch
<bialix> I need either allow actions for 1 branch mode
<poolie> lifeless: why did you approve johnf for bzr-beta-ppa?
<bialix> garyvdm: or to have the proper way detect/select branch in multi mode
<garyvdm> It's easy to get from a revision to a branch/repository
<bialix> garyvdm: this is also related to bug about taga on multibranches
<bialix> s/taga/tags/
<garyvdm> but a revision may have more than one branch.
<bialix> this is *the* problem
<bialix> can you suggest easy way to detect if qlog started in multibranch mode?
<garyvdm> My re-factored branch is much better at this.
<bialix> IIRC t should landed shortly
<garyvdm> len(log_list.graph_provider.branches)
<garyvdm> Yes - I'll land it after we release 0.9.7
<bialix> poolie: hi, plans about 1.12 is the same? we need to release QBzr in sync with bzr
<poolie> bialix: still planning to do rc1 tomorrow my time and final friday
<poolie> synchronized release would be nice
<bialix> garyvdm did very good job to support new progress bar
<bialix> he's our release manager for 0.9.7 :-)
 * garyvdm is nervous
<poolie> ah great :)
<bialix> poolie: your time is about?
<poolie> utc+11
<poolie> ie it's monday morning now
<garyvdm> Down under?
<bialix> garyvdm: ?
<garyvdm> Slang for  Australia/New Zeeland
<bialix> ah
<garyvdm> reference to it's position on the world map
<bialix> garyvdm: I think you can release it anytime soon
<bialix> even tonight, if you like
<garyvdm> Ok
<bialix> I'll be there couple of hours, coding scmproj
<bialix> so you can ping me if needed
<garyvdm> Thanks
<bialix> I'm usually simply follow the instruction
<lifeless> poolie: because he's going to help keep the ppa up to date?
<garyvdm> bialix: Should I mention updated translations in NEWS.txt?
<bialix> garyvdm: I never do this, only new ones
<garyvdm> Ok
<bialix> the list of updated could be loong sometimes
<poolie> lifeless: is he?
<garyvdm> poolie: do you think this will land before 1.12? http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090126072506.GA30864%40steerpike.home.puzzling.org%3E
<garyvdm> It causes a bug in qbzr.
<poolie> lifeless: ok i see your reply to jam about that
<poolie> did he suggest it offline?
<poolie> i'm just asking because people seem to randomly request to join groups all the time
<lifeless> poolie: yes, he chatted here on friday about that; he packages stuff elsewhere in Debian format (I don't recall if he's a DD offhand), etc
<poolie> because of poor ui i guess
<poolie> great
<lifeless> poolie: so, randoms I would have declined :P
<poolie> also iwbn if the 'request to join' let people specify a rationale
<poolie> i realize he's not very random
<poolie> lifeless: ah, bug 4976
<ubottu> Launchpad bug 4976 in launchpad-registry "When trying to join a team, user should be able to give comment" [Wishlist,Triaged] https://launchpad.net/bugs/4976
<garyvdm> ls
<lifeless> abentley: if you could review http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1233892193.12070.112.camel%40lifeless-64%3E that would be lovely
<lifeless> abentley: its a shelve/treetransform bug and I'm on shaky ground there
<bialix> poolie: can you help gary?
 * poolie looks
<poolie> garyvdm, bialix: i approved it (enthusiastically :-) so we need to poke spiv
<poolie> i think vila's approach is a bit better, of hooking in at the socket level
<poolie> but we can unify them later
<garyvdm> Actualy - I'm hoping it's not going to land :-(
<garyvdm> >	It causes a bug in qbzr.
<poolie> oh i see
<poolie> i thought you meant lack of it causes a bug
<Jc2k> jelmer: awesome!
<lifeless> garyvdm: whats the bug
<garyvdm> Bug 325924
<ubottu> Launchpad bug 325924 in qbzr "TooManyConcurrentRequests with traffic reporting for smart media." [Medium,Confirmed] https://launchpad.net/bugs/325924
<poolie> srsly
<poolie> that exception should be shot
<bialix> garyvdm: it affects on;y qlog?
<bialix> only
<garyvdm> In theroy no - but in pratice - I have not seen it any where else
<garyvdm> Let me do some testing
<spiv> garyvdm: I find it odd that the traffic-smart branch would cause that.
<spiv> Unless it's because of some side-effect like the GUI blocking without it?
<lifeless> spiv: or not blocking
<lifeless> garyvdm: does qbzr use threads, or is it synchronous?
<garyvdm> synchronous
<garyvdm> It's really a bug with qbzr - not that branch
<garyvdm> When we get notified of transport activity - we do a processEvents()
<garyvdm> Which would allow more than 1 simultaneous request.
<bialix> garyvdm: what's there before?
<bialix> maybe we need temporarily disable monitoring of transport activity in qbzr?
<spiv> garyvdm: ah, in that case I'd expect vila's patch for HTTP traffic reporting would cause the same issue with bzr+http://
<lifeless> garyvdm: so processEvents handles an aritrary amount of user input ?
<garyvdm> spiv: I'm not sure - I don't know the transport code to well.
<garyvdm> spiv: It will happen with any transport that does not allow concurrent requests, and reports traffic.
<lifeless> we have a sync api to transport
<lifeless> garyvdm: can you not call processEvents?
<garyvdm> lifeless: Then it won't display the transport activity
<garyvdm> lifeless: processEvents is normally called in the event loop, but you can also call it during long running processes to keep the ui responsive.
<garyvdm> http://doc.trolltech.com/3.2/qeventloop.html#processEvents
<garyvdm> Newer version: http://doc.trolltech.com/4.0/qeventloop.html#processEvents
<bialix> garyvdm: but I see you've disabled user input. this is not enough?
<garyvdm> Was just about to give some detail on that - just a sec
 * bialix waits
<garyvdm> That fixes that bug in 99% of cases
<garyvdm> In qlog: when you click on a rev - we set a timer to load the delta to show that changed files.
<bialix> yes
<garyvdm> That timer may get called from a processEvents called during notify_transport_activity
<bialix> got it
<bialix> imo we have hidden problem there
<bialix> even for concurent transports
<bialix> as a quick fix we can use some flag at qlog instance to prevent loading delta untill we finishing with main request
<garyvdm> bialix: What's that?
<garyvdm> (hidden problem)
<bialix> we don't have a way to reuse connection?
<garyvdm> bialix: We do reuse connections
<bialix> but anyway we got the error
<bialix> I think simple queue may help as you wrote in bug report
<bialix> but it'snot quick fix
<bialix> we talk about log.py update_revision_delta?
<garyvdm> Yes
<bialix> and uifactory?
<garyvdm> With my patch to not allow user event - it very difficult to reproduce.
<garyvdm> Yes
<bialix> mmm
<poolie> (out for a little bit)
<garyvdm> http://pastebin.com/d26b9c3b1
<garyvdm> bialix: log.py update_revision_delta is the only place I've been able to reproduce it.
 * bialix looks
<garyvdm> bialix: How about - in update_revision_delta - try... execpt TooManyConcurrentRequests reschedule the timer
<garyvdm> as a quick fix.
<bialix> but the traceback actually points to logmodel
<garyvdm> Ahhhh
<bialix> i'm thinking about using simple lock
<bialix> and if the lock is acquired -- then reshedule the timer
<bialix> this will affects any transport
<bialix> ?
<garyvdm> Yes- as a quick fix
<bialix> thread.Lock
<bialix> from std lib
<garyvdm> That won't work
<bialix> ?
<garyvdm> Here is a different traceback from my .bzr.log: http://pastebin.com/d7d18c473
<garyvdm> bialix: we are not using threading.
<garyvdm> A simple is_loading_revisions will do though.
<bialix> IMO this lock should not require real threading
<bialix> ok, fine
<bialix> re 2nd traceback: yep, i guess it's 50%-50% effect
<bialix> anyway we disable input
<mwhudson> hm
<garyvdm> Long term fix - have a queue - re-enable input
<mwhudson> i remember bzr has some knob you can twiddle wrt decorators like @needs_read_lock
<mwhudson> do you get fast or pretty ones by default?
<lifeless> fast by default I beleve
<mwhudson> oh goof
<mwhudson> good!
<garyvdm> mwhudson: All the requests that qbzr make allready have read_locks. It unfortunately does not prevent TooManyConcurrentRequests
<bialix> garyvdm: agree. we can live with current situation for a while
<garyvdm> Anyway - we don't want to prevent the request - we want to make it happen later.
 * bialix mutters: although for local branch we can avoid locking
<mwhudson> garyvdm: i'm worrying about my own problems, not yours :)
 * bialix out of good ideas
<garyvdm> bialix: Not necessary to not lock for local - because local does not report transport.
<garyvdm> mwhudson: oh!
<bialix> garyvdm: it's a bit late for me. sometimes morning is smarter than evening. don't worry too much about 1% bug tonight
<garyvdm> I'm a night owl... I'm sure I can put a quick fix in.
 * garyvdm ignores irc for a while.
 * bialix too, but he needs to sleep sometimes
<bialix> garyvdm: bye
#bzr 2010-02-08
<GungaDin> if I've merged something (still haven't committed!!!)  and I'd like to reverse this operation and do a different merge, how can I do that?
<bob2> revert
<GungaDin> but hasn't the history been updated yet?
<bob2> not until you commit
<GungaDin> cool
<GungaDin> thx
<RAOF> bzr is all about not doing things you don't want to do. :)
<fullermd> Where's the "no-taxes" plugin then?
<vila> hi all !
 * fullermd waves at vila.
<masklinn> hello, is there a way to edit history in bazaar in order to fix a previous (broken, but not yet published) commit? In mercurial I'd use mq, qimport everything down to the faulty commit, qpop and edit my broken commit (or merge patches, whatever), in git I'm sure I'd find a way, but in bazaar I haven't found any paths so far. Loom is billed as an equivalent to MQ, but looks very complex, apparently modifies the repository format (is it still possible 
<masklinn> push to the regular, old format? Or for loom-less people to get non-loomed revisions as it is with hg mq?) and I haven't found any instruction on importing "normal" bzr revisions into looms and exporting them back in bazaar.
<masklinn> So... is there anything I missed? How do you handle the case where you performed a broken commit and only realize it 5 commits later?
<bob2> you can uncommit
<beuno> or use bzr-rewrite
<bob2> or you can branch from before the problem and manually commit new changes
<bob2> or use bzr-rewrite
<bob2> aka bzr rebase
<Peng> masklinn: Mostly we just commit a fix. :P
<masklinn> I don't want to uncommit, first uncommit is broken on my mac, second that means I have to manually store 5 different log messages in some kind of text file so I can re-commit later
<masklinn> bzr-rewrite sounds interesting
<masklinn> thanks
<bob2> depends what broken means, too
<masklinn> peng, I'd do that if the revisions were already published, but the history is still fully local so it's a waste to have broken revisions in there when I'm still in a position to amend them without anybody knowing
<bob2> if it's "bug in the code", just fix it like Peng said
<bob2> if it's nuclear launch codes, then put more effort in
<Kinnison> Or you put up with the fact that you got a broken commit; fix the issue on head, and move on, having learned to be more careful in future :-)
<vila> masklinn: if uncommit is broken on your mac (how so ?), please a file a bug
<masklinn> vila: it locks up 9 times out of 10, no error message no nothing, and I have to C-c, break the lock, update and I lose all the changes in the tentatively uncommited commit
<vila> masklinn: no messages even in .bzr.log ?
<masklinn> vila: I don't know, I'll have to check next time it happens
<masklinn> vila: never really wondered about the logfile
<vila> masklinn: .bzr.log should still contain your old attemps, no need to wait :D
<masklinn> vila: yeah but I tend to create and delete lots of clones, so I'm not sure I still have repositories where I did it. I tend to just avoid the operation these days
<vila> masklinn: ok, then keep in mind that many people use uncommit on mac (myself included) and nobody ever report problems there, so presumably something is special in your config
<masklinn> vila: i'm sure that's the case, which is why I specified it was broken on *my* machine, not in general ;)
<vila> masklinn: if there is a bug, we want it to be fixed ;)
<masklinn> yep, I'll check the log next time I forget myself and try an uncommit
<j^> why does bzr use so much memory if i checkout an lp repository without account?
<j^> i.e. bzr branch lp:bzr
<j^> 595m 421m 2280 D  1.0 42.1   3:27.54 bzr
<Peng> Yikes.
<gerard_> hey
<gerard_> jam: did you see the latest changes to my branch?
<gerard_> I'm happy with it now :) ;)
<masklinn> vila, where's the bzr log supposed to be?
<bob2> ~/.
<masklinn> oh, not in the repo root or .bzr?
<vila> masklinn: 'bzr version' should tell you
<vila> gerard_: jam in in Chicago, he's sleeping :D
<fullermd> Yeah.  Nobody in this TZ would be awake at this hour; that would be crazy.
<vila> j^: which bzr version are you using ? bzr-2.1 has fix a few related bugs
<gerard_> vila: ah, hehe
<vila> yeah no *average* body :D
<vila> only people like cops, fire workers and the like, plus of course the bad guys...
<vila> did I miss some category ? :D
<fullermd> Well, I'm not a cop, I'm not a fire worker, I...   umm....
<fullermd> Well, no, I guess that's all the categories   :p
<vila> hehe
<masklinn> vila, well there does't seem to be anything of note in the logs: http://pastebin.com/d7e2a0cf0
<masklinn> Is there a way to turn the log's verbosity to 11 or something? I don't see anything in the docs
<vila> masklinn: you meant C-c or you really did C-z ?
<masklinn> I really did C-z, C-c didn't do anything, and neither did C-d
<masklinn> The above revision(s) will be removed.
<masklinn> Are you sure [y/N]? y
<masklinn> ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^Z
<masklinn> [1]+  Stopped                 bzr uncommit
<vila> C-z suspend the process and put it in the background, you leave bzr no chance to clean up anything
<masklinn> well to kill it I used a regular kill, not a kill -9
<masklinn> so theoretically it should have given bzr the ability to do something, right?
<vila> weird, what kind of setup are you using ? A bound branch ? The warning about the working tree out of date may be due to the break...
<vila> masklinn: well, yes
<masklinn> yeah the warning is due to the break, that's not an issue (the second command is mainly to show that there was nothing after the uncommit)
<fullermd> Well, if ^C (with at least a few seconds) didn't interrupt it, it's stuck in the kernel somewhere, so it would never get a chance anyway.
<masklinn> it's a standalone
<vila> masklinn: what bzr version are you using ? (I'm pretty sure the recent ones always output that in the log)
<masklinn> vila: it's a standalone tree
<masklinn> 2.0.4 from macports
<masklinn> Bazaar (bzr) 2.0.4
<masklinn>   Python interpreter: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python 2.6.4
<masklinn>   Python standard library: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
<masklinn>   Platform: Darwin-10.2.0-i386-64bit
<masklinn>   bzrlib: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/bzrlib
<vila> !paste
<ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<vila> masklinn: where is your repo ? Local ? http ? bzr+ssh ?
<vila> masklinn: mounted NFS ?
<masklinn> local fs
<masklinn> freshly cloned from another local repo
<vila> masklinn: so you don't use shared repos ? (You should give it a try if you use many branches that share history)
<masklinn> vila: I sometimes do, but I didn't on that project. And we have... issues with shared repos (the remote repositories are in a pretty old format, so things don't work out well when trying to push or push shared repos to lp)
<Peng> ...Huh? How would shared repos make a difference there?
<masklinn> you tell me
<masklinn> bzr whines about incompatible repository formats
<masklinn> and lp then tells me that the repo I just pushed is broken
<Peng> It's notable that "bzr branch" uses the source branch's format by default, but the shared repo's format if you're in a shared repo (obviously), but it's not hard to keep that straight.
<vila> Peng: I didn't way they were related, just mentioning them
<Peng> vila: Err, sorry. I was just replying to masklinn, not you.
<vila> Peng: no worries ;D
<vila> masklinn: I agree with Peng, most probably you ran into bzr forcing the default format to be 2a
<masklinn> Peng: yes, and the shared repo is created using 2a by default, and by the time i realized that I was basically hosed. And I'm not even clear on which format I should be using locally to keep things straight, as the repo names on the CLI and the ones given by error messages are basically unrelated
<vila> masklinn: have a look at the upgrade guide: http://doc.bazaar.canonical.com/latest/en/upgrade-guide/index.html
<masklinn> (I'm not even sure the remote repo's format is compatible with shared repositories)
<vila> masklinn: I'd be suprised if you use a format that doesn't support shared repos
<masklinn> vila: might be possible at some point, but the project is pretty big, and e.g. ubuntu 8.04 doesn't ship with 2.0, so for now it's not upgraded
<Peng> It would have to be horrifically old, or broken, to not support shared repos. Besides, what matters is the local format.
<vila> masklinn: ok, let's put that aside for now then
<fullermd> I'd be well beyond surprised.  all-in-one formats are *OLD*.
<vila> masklinn: how big is your working tree ?
<masklinn> villa: the project/branch in question is https://code.launchpad.net/~openerp/openobject-addons/5.0 (warning: humongously huge)
<masklinn> vila: .bzr is 93MB, total WC is 160MB
<vila> masklinn: how many files ?
<masklinn> vila: I fear my bzr-fu and terminal-fu are too weak to know, how can I check?
<vila> I wonder if you may be missing some progress report and if bzr is actually taking longer than usual to finish the uncommit
<vila> find . | ec -l
<masklinn> vila: I don't think so, in the past I let it run 30mn+, never saw any progress
<vila> find . | wc -l
<Peng> Or "bzr inventory | wc -l".
<vila> wow, 30mn is indeed far too long
<masklinn> vila: find . reports 5722, bzr inventory reports 5689
<vila> can you pastebin the output of 'brz info -v' ?
<vila> masklinn: wow, 33 unknown files ? Or are there some *~n~ files ?
<masklinn> vila, wouldn't those be the files in .bzr?
<vila> masklinn: oh sure
<Peng> Wow, the remote branch is rich-root-pack, so you actually could use 2a locally, though converting between them takes a couple seconds.
<Peng> However, you can't *stack* between them, and that's probably what's freaking Launchpad out.
<vila> bug 33 sounds a bit high, ha no, the repo is there
<ubottu> Launchpad bug 33 in malone "in bug list, the 'normal' severity label has a popup that says 'critical'" [Medium,Fix released] https://launchpad.net/bugs/33
<Peng> \o/
<vila> grr *but* 33
<vila> ubottu: your humour is thick
<masklinn> vila: http://pastebin.com/d78ba2197
<masklinn> apparently something is a bit broken after the uncommit
<masklinn> running a bzr check
<fullermd> That probably means the uncommit did its job on the branch, and failed trying to do stuff in the working tree.
<fullermd> That's consistent with stat bleating about needing 'update' too.
 * vila agrees with fullermd 
<masklinn> fullermd: I did an update after that, so the working tree should be in sync
<vila> after what ?
<fullermd> And doing stuff in the WT does OS locks last I checked, which is also the most likely place for uncommit to lock itself up inside the kernel.
<masklinn> after it asked me to bzr update
<masklinn> I bzr broke-lock and bzr updated
<vila> yeah, so something was already broken there probably
<vila> fullermd: OS locks are broken in OSX ? As much as in BSD ? :-D
<masklinn> well the original repo I cloned from (the one without/before bzr uncommit) seems ok
<Peng> Sure, working tree nonsense won't break the branch or repo.
<Peng> Well, maybe, if you somehow commit something horribly wrong, but that's difficult.
<vila> masklinn: side-note: since you already use a rich-root-aware format, migrating to 2a is easier
<vila> Peng: like what ? If we can commit it we can uncommit it :D
<masklinn> easier for me, but not easier for the project as a whole, and it doesn't solve lp freaking out everytime a bee flies near the window
<vila> masklinn: easier compared to people using a non rich-root-aware format
<Peng> Ideally, LP would be less dumb. I'm not sure whether it's supposed to be, too.
<Peng> Yeah, the only issue you've got converting between rich-root-pack and 2a is stacking.
<masklinn> Peng: ideally^2, lp would start by offering the same "clone" button github and bitbucket do
<fullermd> Also, a pony.
<masklinn> and then I'd know beforehand that Stuff Works
<Peng> Well, and that pushing 2a up to LP is rude if not everyone using the project has a new enough version of bzr...
<masklinn> yeah, i like ponies
<masklinn> Peng: yep, though I think the stacked thing is creating enough pain right now that the "deciders" are looking at just migrating everything to 2a and telling users to install 2.x ppas
<vila> masklinn: can you pastebin the relevant portion of .bzr.log leading to the traceback about bzr: ERROR: bzrlib.errors.NoSuchRevision: BzrBranch6('file:///Users/masklinn/projects/tiny/addons/stable-security-fix-2575/') has no revision xmo@tinyerp.com-20100205202639-4l5e0z4gwyvof1b2
<vila> masklinn: migrating everything to 2a and telling users to install 2.x ppas is a good idea, you'll get smaller repos, faster bzr and the ability to bzr push stacked branches on LP, which in turn will allow you to push roughly size(changes) for new branches
<masklinn> vila: yeah, but that requires users to install ppas on "older" ubuntus (and get lost if they're using non-ubuntu distros which don't ship 2.x, I guess) which isn't very nice to them
<vila> masklinn: bzr-2.0 is being backported to older Ubuntu releases, this should happen RSN (tm)
<fullermd> Just in time for 2.1 to be out, maybe  ;p
<masklinn> villa: This should be the part of the log leading to the error: http://pastebin.com/m2e6f66be
<masklinn> fullermd: talking about 2.1, does it change the repo format *again*?
<jelmer> masklinn: only major versions (1.0, 2.0) change the default format
<vila> masklinn: right, so it looks like your working tree is pointing to a revision that doesn't exist in the associated repo ? How weird
<masklinn> vila: well that would be the uncommitted revision wouldn't it?
<fullermd> uncommit doesn't remove the rev from the repo.
<vila> masklinn: but it should still be in the repo
<masklinn> oh
<vila> masklinn: did you try something like 'bzr uncommit -r<unkown_revision>' ?
<masklinn> nope
<masklinn> just a plain "bzr uncommit"
<vila> masklinn: did you try something like 'bzr uncommit -r<some_revision>' ?
<vila> wow
<masklinn> I'd done a bzr clone -r{something} before because I didn't want the top 2 revisions of the other repository (since I wanted to fix 2575)
<masklinn> but uncommit was options-less
<j^> vila: that was with 2.0.4 will try 2.1
<vila> j^: make sure the extensions are compiled if you're running from source
<vila> masklinn: and you had a valid working tree after your 'bzr branch' ?
<masklinn> vila: I think so, but I can try brancing to some other repo and doing an info -v just in case
<vila> masklinn: filing a bug with a reproducible scenario will be ideal
<masklinn> well yeah but I doubt "reproducible 90% of the time on my own machine, never on others" would be reproducible enough ;)
<vila> masklinn: that'd be a start towards making it 100% reproducible :) Then we'll can fix it !
<masklinn> ok tried re-cloning the original branch (with the same parameters) to a new one, bzr info -v comes back with a clean bill of health, so it does quite seem like uncommit broke the thing. I'll try clearing my log and re-running the interesting commands
<masklinn> and this time it worked... oh well (weird though, I get a warning about gtk, why is gtk involved in uncommit?)
<fullermd> bzr-gtk hooks into it if it's installed.
<masklinn> fullermd: ok, I'll kill bzr-gtk, the issues might come from that (macports's gtk seems to do nothing but crash on my machine, uncommit's issues might come from there, or the issues might be related)
<masklinn> with a bit of luck, it'll unscrew uncommit
<krisives> does anyone know how to use bzr-git ?
<krisives> i cant find any kind of documentation
<Kamping_Kaiser> bzr help git work?
<manuee> hi everyone
<manuee> drupal is considering moving (finaly) out of cvs, and pondering other vcs ... it'd b e nice if some of you could chip in http://groups.drupal.org/node/48818
<manuee> i personaly would like us to use bzr, but not knowledgaeble enough to make a statement or to defend it against other options
<krisives> `bzr help git` only gives me:
<krisives> "A GIT branch and repository format implementation for bzr."
<krisives> manuee: Good luck, I've noticed a lot of projects blindly hate bzr
<krisives> http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html is a good start, and the ultimate argument is simplicity, low barrier of entry, which they should obviously appreciate if they are switching from CVS
<manuee> thanks krisives
<krisives> and for a shameless plug: http://santiance.com/2010/01/how-to-synchronize-code-with-bazaar/
<masklinn> Should documentary lacks of bzr (and extensions) be reported as bugs? Because it isn't exactly clear from its help topics that, in bzr rebase, `-r` can pretty much turn it into a transplant
<masklinn> even though it seems to work ok
<gerard_> masklinn: I'd say it's a bug
<masklinn> ok, so I should open a bug on bzr-rebase on their lp page?
<bialix> it seems today is holiday, so quiet here
<rubbs> today is a holiday?
<rubbs> hello bialix btw.
<bialix> hello rubbs
<bialix> maybe it was my imagination
<bialix> so quiet here usually on weekends and holidays
<rubbs> There is a lot of snow in the US. I don't know if that's part of it. Large parts of the East Coast here are without power.
<rubbs> true
<bialix> oh, that's not good
<rubbs> yeah. I had to spend 45 minutes digging out my car this morning.
<rubbs> made it to work though
<bialix> hi jam, how's you dealing with snow?
<jam> morning bialix, not really snowing here
<bialix> rubbs: we have similar problems here
<jam> I guess to the east and west of me is far worse than here
<bialix> jam: morning, can you refresh my memory about 2.1 final date?
<jam> this week
<bialix> that's good
<rubbs> jam you in Midwest?
<jam> rubbs: yeah, just south of Chicago
<rubbs> ah. cool. I have friends who live in Elgin (sp?). I was born in Paletine and lived in Aurora for a while
<gerard_> jam: morning
<bialix> jam: who is release manager for 2.1 final? poolie?
 * bialix looking for summary of new changes in 2.1
<bialix> rats, news entries for 2.0.x and 2.1.0by releases mixed
<jam> bialix: I think I'm still the official 2.1 releaser
<bialix> may I beg you to write soem summary on changes re 2.0?
<bialix> *some
<bialix> this will be first really big release
<bialix> 6 months of work
<jam> bialix: http://bazaarvcs.wordpress.com/2010/01/18/bazaar-2-1-2/
<bialix> jam: thanks
 * bialix hopes to see nested trees landed in 2.2
<bialix> jam: fyi about qbzr 0.18.1: the tag for this release available in both lp:qbzr/0.18 and trunk. but I suspect you'd like to use lp:qbzr/0.18 for 2.1.x anyway
<ronny> btw, what exactly is nested trees?
<jam> bialix: well, it wasn't there when I tried doing the packaging earlier, but it doesn't really matter. As long as your tags can be found, I'll get them
<bialix> ok
<bialix> ronny: svn:externals, git submodules, hg subrepos
<ronny> i see
<mathrick> hi, what's the best / easiest way to install a post-commit hook in a single repo?
<mathrick> I'd be happy to be able just to call a shell command, really, scp is all I need
<rubbs> are you looking for just a mirroring system?
<rubbs> if so, http://wiki.bazaar.canonical.com/BzrPlugins, under "Publishing" might be what your looking for. There are a few options there.
<mathrick> right, but I need a single file, more or less
<mathrick> the ones I've seen want to push the whole tree I believe
<rubbs> ah, ok.
<mathrick> so I guess what I need is to read some kind of config on the branch, but how'd I go about it?
<mathrick> hmm
<rubbs> not sure.
 * mathrick reads automirror's source
<rubbs> sorry I couldn't be more help :(
<mathrick> nah, it's fine
<bindjp> hi, was trying to get the bzr explorer to work in snow leopard and with no luck.  The installer looks like it doesn't install it
<mathrick> bindjp: did you read the note on http://wiki.bazaar.canonical.com/MacOSXDownloads ?
<mathrick> "he "Desktop" bundles include Bazaar Explorer and QBzr in addition to the contents of the "Core" bundles. It requires that you have the Qt framework installed. For Mac OS X 10.6 Snow Leopard, you must install the 64-bit Qt 4.6.1 framework."
<bindjp> mathrick: yeah, I installed that
<bindjp> mathrick: maybe there is a way to clean out the previous installs and start again?
<mathrick> dunno really
<bindjp> mathrick: I will see what I can find, thanks, just wondered if anybody ran into troubles too
<mathrick> bindjp: yeah, I was making sure you didn't run into the most obvious issue. I don't really know anything past that, sorry
<doctormo> I'm getting an odd error when I try and checkout lp:drawberry
<doctormo> ErrorFromSmartServer: Error received from smart server: ('error', "'Inter1and2Helper' object has no attribute 'source_repo'")
<james_w> bug 513432
<ubottu> Launchpad bug 513432 in launchpad-code "AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo'" [Critical,Confirmed] https://launchpad.net/bugs/513432
<mathrick> hmm, how do I get the pathname under which a WorkingTree lives?
<vila> wt.basedir
<bialix> rats, unicode error in unshelve --preview
<bialix> rats rats rats
<mathrick> vila: thanks
<verterok> jelmer: hi! fwiw, I just tagged bzr-xmloutput 0.8.6 ;)
<ahasenack> hey guys, bzr is throwing at me an internal error when trying to checkout a repository
<ahasenack> http://ubuntu.pastebin.com/d717de539
<rubbs> bug 513432
<ubottu> Launchpad bug 513432 in launchpad-code "AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo'" [Critical,Confirmed] https://launchpad.net/bugs/513432
<ahasenack> is this known? Should I go ahead and file a bug report?
<ahasenack> ok
<rubbs> looks like they're working on it
<ahasenack> rubbs: thanks
<rubbs> np
<lamalex> is anyone here familiar with trac-bzr?
<jelmer> verterok, hey
<jelmer> verterok, awesome, I'll make sure it ends up in Debian/Ubuntu
<verterok> jelmer: cool, thanks! :)
<lamalex> I can't get it to display different branches
<exs> hi guys. i have a question. i have a inited branche on locale space and want to upload the content to my webspace too. how i have to do this. the documentation irriteded my a little bit.
<exs> the best way were. i devel on my local space. and then i have a upload command and after that bzr uploads the whole develcode at my webspace.
<exs> and it would be greate if i could edit some commands executing before content will uploaded
<rubbs> so, just to clarify, you want to be able to push just the working directory to a location? or do you want the whole history to go with it?
<exs> only the actual revision
<exs> no history needed
<rubbs> ok, why would you ahve to use bzr? or do you want it do to that while commiting? I guess I'm asking why you couldn't just ftp or sftp or scp the directory to the webspace and not use bzr at all?
<exs> because i used a wiki where other persons can change the code
<rubbs> *not use bzr to upload at all* is what I ment
<rubbs> so you want the web space to be versioned as well? so when another person changes it you can get that version?
<exs> in additions its more comfortable when you are able to upload the whole content to the webspace while commiting
<rubbs> I'm not quite understanding the set up.
<exs> exectly
<rubbs> just curious, doesn't the wiki have a version control built in?
<exs> thats right, but its too hard to go hand by hand and look which files were edtied
<rubbs> ah, ok.
<exs> the wikipages are txtfiles. and this txtfiles i want to edit on my local space.
<rubbs> well, there is a problem if someone changes it on the web by hand, you would have to modify the wiki to commit every change to bzr on the webserver.
<exs> i thought bzr registrate every change automatically
<exs> the wikisoftware is dokuwiki. it edit only textfiles saved on my webspace. other user can edit the wikipages too, so i need bzr to synchronize my local code with the code may edited by other users
<rubbs> so how do you get the code from the webspace, do you just copy it over?
<exs> yea
<exs> i login with ftp
<exs> then go to the dir where my files are saved and then copy to my local space
<exs> can you german maybe?
<rubbs> exs: sorry my german is REALLY bad. I wouldn't be able to understand you. It isn't your english that is the problem with me asking all the questions. It's just me needing to know how you work, so I can help you figure out how to make bzr work for you ;).
<rubbs> bzr will understand what has changed automatically between the history you have and the working tree (your revision you work on) that's why you can use diff and the like
<rubbs> but it will not automatically know if the directory on your webspace has changed.
<exs> rubbs: the point is this. i have a bzr branch already where i code my programs. i want to publish the code on my webspace in a certain direcotry where wikiuser can edit the files. after certain time i want to syncronize both branches. maybe the user edited something new, and i added something new in the code and i want others to see it. the files i work on them are simply txtfiles. and dokuwiki just edit simply txtfiles. the whole wiki consists of txtfile
<rubbs> Ok, got it. I think I can help, but I have to use the toilet.... I'll be right back.
<exs> rubbs: ah now i understand what you mean :) yea that could make a problem. but my idea was that if something has changed so there are difference that bzr will show me this in the next commit and i solve the problem by hand or something like that
<rubbs> exs: I think I still have an idea that will work, but I'll be right back.
<exs> ok
<rubbs> ok, back. Here's my idea:
<rubbs> you could create a local branch and create a remote branch on your webspace. When changes happen on the wiki, the remote repo will keep track of them. then to get them to your local branch, you could run "bzr merge --uncommitted ftp://webspace/dir" That will pull all the changes on the webspace. Then you make your changes locally, then do a "bzr push --overwrite" That will put all the changes on your local to the remote.
<rubbs> then you can use a plugin like "push and update" to make the working tree become updated.
<rubbs> http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html
<jelmer> verterok, hi
<verterok> jelmer: hey
<rubbs> exs: http://doc.bazaar.canonical.com/bzr.2.0/en/user-reference/index.html#merge
<jelmer> verterok, any chance you can upload a tarball as well?
<rubbs> exs: hopefully that helps a little
<verterok> jelmer: already uploaded :)
<jelmer> verterok: oops
<jelmer> verterok: ignore me then :-)
<exs> why --uncomitted and --overwrite?
<verterok> jelmer: but it's a 'bzr export' instead of a 'setup.py sdist'
<rubbs> exs: when the wiki user makes a change, that will not be a part of the history yet (because it was never committed) so when you merge in the "uncommitted" changes, you are pulling all the changes on the webspace.
<rubbs> exs: the more I think about it the more the --overwrite might not be necessary.
<jelmer> verterok, uploaded
<jelmer> verterok, thanks!
<verterok> jelmer: awesome, thanks!
<exs> rubbs: ok thx for help, but i could not try it now but i will try it later. can u answer me another question. what is the sense of repo-init? what exectly do this command?
<rubbs> exs: init just makes one stand alone branch all that history is stored in that branch. init-repo will create a "shared" space for many branches. This allows you to save disk space when you have multiple branches with similar code. If you are only going to be using 1-2 branches at a time, it isn't that important.
<lifeless> Is there a 'rhett trapmann' here?
<jpds> lifeless: He's gone, long gone.
<poolie> hello
<lifeless> jpds: was he here at all?
<lifeless> the account has been blacklisted (yay)
<lifeless> hi poolie
<jpds> lifeless: No, he just got banned from LP.
<lifeless> but it was his second account anyway...
<lifeless> so I expect a third pass until someone actually manages to sit down and explain things.
<RAOF> I'm having trouble branching lp:launchpad-integration; bzr fails with bzrlib.errors.ErrorFromSmartServer.
<RAOF> Full error is http://pastebin.ca/1790660 and http://pastebin.com/f1c08c1df
<mwhudson> RAOF: are you branching from an old format branch into a 2a repo?
<mwhudson> it's a server side bug though, must chase the SAs about getting that deployed
<RAOF> Possibly.
<RAOF> lp:launchpad-integration has Branch format: Packs 5, and I am branching into a 2a repo.
<mwhudson> yeah
<mwhudson> branch standalone first or something
<RAOF> Or, it turns out, branch over http first.
<RAOF> That worked.
<exs> can someone say how to change the message in a commit?
<bob2> you can't
<LeoNerd> You can't. The revision is signed by a checksum.. that checksum is the identity of the revision. If you change the message, you change its identity, and have now broken it.
<bob2> you can uncommit and recommit with a new message, if you like
<LeoNerd> Well, not broken.. it's just now different
<bob2> but that'll confuse anyone who has pulled from you
#bzr 2010-02-09
<exs> hm ok. one more question. i commit a develtree. after that i create a new file and then i want revert to the last revision without all files created after the last commit. is this possible?
<bob2> perhaps you want bzr uncommit
<bob2> I'm not sure
<exs> but then the newly created files are still there
<Peng> "bzr revert" instead?
<exs> no
<bob2> so delete them?
<bob2> or clean-tree
<exs> a great. that was i ve searched
<exs> i go sleep n8
<RenatoSilva> lifeless: https://bugs.launchpad.net/bzr-search/+bug/480684
<ubottu> Ubuntu bug 480684 in bzr-search "Return matching revisions" [Undecided,Incomplete]
<mwhudson> Peng: your mirror branches broke launchpad :-)
<mwhudson> (but it seems to be some network provider stupidity, not your fault)
<lifeless> RenatoSilva: I'm going out, but I have replied to the bug
<RenatoSilva> lifeless: last 2 comments are mine
<spiv> RenatoSilva: the last comment (#6) isn't
<RenatoSilva> no idea of what this means: Nor does it have a suffix index (where you put rabedis and rabedis-on in an index and can then find both sidebar and no-sidebar efficiently).
<RenatoSilva> lifeless: I would simply rename the bug to 'make bzr search human friendly', but that seems a big way to walk through
<spiv> lifeless was going perhaps a bit too much into possible implementation details in those parens.
<RenatoSilva> how to find no-sidebar?
<spiv> If I'm understanding lifeless comment correctly, currently bzr-search only keeps a simple index that lets you look up complete words.
<RenatoSilva> I don't understand why the bug is imcomplete, the title and description and comments are pretty clear
<spiv> (i.e. it doesn't support searches by parts or words, or suffixes)
<spiv> The problem is the scope of the bug is too large and nebulous to be useful as something to have on a todo list.
<RenatoSilva> no it's not
<RenatoSilva> *it's specific*
<spiv> I think lifeless is asking for a bug, or bugs, with specific suggestions about how to improve the searching, rather than something as vague as e.g. "human friendly"
<RenatoSilva> I just want to search the diffs, and know the revision
<RenatoSilva> I didn't rename the bug to "make it human friendly"
<spiv> So you want "diff-only search"?
<RenatoSilva> I said that because of their comments about how imcomplete bzr-search is
<RenatoSilva> well that's a very bad thing that bzr-search is in version 1.7 and can't even search partial words or whatever
<RenatoSilva> I would keep the software as beta
<RenatoSilva> spiv: well, as in the title, I just want "return matching revisions"
<Peng> mwhudson: Awesome. How'd that happen?
<RenatoSilva> return the revisions that match a search string, just like bzr search more or less does
<spiv> Also, comment #4 is suggests you're looking for more complex forms of search queries than simple term-matching.
<RenatoSilva> spiv: do you call bzr search Preferences a more complex search??
<RenatoSilva> same about no-sidebar
<spiv> RenatoSilva: What does "matching" mean in "return matching revisions"?  "word appears in the diff"?  "substring appears in the diff and/or commit message"?
<RenatoSilva> spiv: https://bugs.launchpad.net/bzr-search/+bug/480684/comments/2
<ubottu> Ubuntu bug 480684 in bzr-search "Return matching revisions" [Undecided,Incomplete]
<spiv> RenatoSilva: ok, so
<spiv> RenatoSilva: I'm guessing a bit at what lifeless would like, but
<spiv> RenatoSilva: I suggest changing this bug title to 'show the revisions whose diff contains the search string'
<RenatoSilva> spiv: if you're lucky, your method is not called no-sidebar so you can use bzr-search for that but as I said there 1. no rev *number* 2. output is ugly
<RenatoSilva> spiv: nice title, will change it now
<spiv> RenatoSilva: and filing one or more other bugs for other enhancements like "find PreferencesProvider when I search for Preferences", etc.
<spiv> RenatoSilva: I just copied it straight out of your comment #2!
<mwhudson> Peng: connections from the data centre to bzr.mattnordorff.com are timing out
<RenatoSilva> ah ok :) just changed, for the other bugs, I think I'm only able to say 'make it human friendly', which would probably be rejected for being too general (looks more like a blueprint). You guys, however, are more experienced on how it works and all the specific terms like stemming (?), so you can more easily split it into more specific tasks in my opinion
<RenatoSilva> "return PreferencesProvider when I search for Preferences" is more like a use case than a proper bug description for me (imagine one writing if s == 'Preferences': return 'PreferencesProvider', or some similar hack :D )
<spiv> RenatoSilva: well, don't worry about specific jargon
<spiv> RenatoSilva: give specific examples of things you'd like to work better
<RenatoSilva> ok
<RenatoSilva> thanks for helping
<spiv> RenatoSilva: i.e. a bug report that is a use case that doesn't work yet is still a reasonable bug report, so long as the use case isn't too general
<spiv> RenatoSilva: i.e. don't file bug 1 ;)
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<spiv> (That was a quick timeout!)
<RenatoSilva> spiv: would be nice if you later convince lifeless that the bug is not incomplete
<RenatoSilva> (because it seem you got me)
<spiv> RenatoSilva: lifeless may still prefer to split some of those bugs into more specific bugs, or mark some as duplicates of others, but that will be easier to do the more specific they are
<RenatoSilva> I mean this open bug, its status is incomlete but it's just that lifeless didn't get me in my opinion
<RenatoSilva> * imcomplete
<spiv> RenatoSilva: well, I'd guess with the new title he'll be satisfied, but ask him
<spiv> RenatoSilva: right, I agree, but that's actually a reasonable use of incomplete
<RenatoSilva> ok ok, it's because you have more weight in convincing him I suppose :)
<spiv> RenatoSilva: perhaps, I wouldn't be too sure ;)
<RenatoSilva> I'll tell him that you think it's ok, ok?
<spiv> Well, you can tell him it's now close to I think he thinks it should be ;)
<RenatoSilva> don'tget you, but big thanks anyway!
<spiv> It's his project, I don't have any special authority over it or him.  I *do* have some experience in understanding what he finds useful in a bug report, though.
<spiv> (Which isn't far off what I find useful)
<RenatoSilva> ok ok thanks, gtg good night!
<spiv> RenatoSilva: good night
<tonyyarusso> So I have a local (unbound) bzr branch, and I want to merge a change from a branch on launchpad.  I tried doing 'bzr merge lp:~ubuntu-minnesota/ubuntu-drupal-theme/minnesota-patches' and got this:
<tonyyarusso> "bzr: ERROR: KnitPackRepository('file:///home/drupal/sites6/ubuntu-minnesota.org/themes/ubuntu-drupal-theme/.bzr/repository/'); is not compatible with; RemoteRepository(bzr+ssh://bazaar.launchpad.net/~ubuntu-minnesota/ubuntu-drupal-theme/minnesota-patches/.bzr/); different rich-root support"
<spiv> Your local branch is in an old format
<spiv> Assuming you have bzr 2.0 or newer, just run "bzr upgrade" in that branch
<Peng> mwhudson: Ehh. That's not my fault, is it?
<tonyyarusso> spiv: ah, perfect - thanks
<Peng> mwhudson: FWIW, mtr to crowberry (bazaar.lp) and druzhnaya (puller) from my end work fine. Well, 1 packet gets dropped at the last hop, but that shouldn't matter.
<spiv> tonyyarusso: you're welcome
<tonyyarusso> hmm, now I have a message that there's a conflict in a file - is there a way to show what the actual conflicting text is?  (I only have a filename so far)
<tonyyarusso> the man page makes it sound like showing the text should be the default
<tonyyarusso> oh, I see
<tonyyarusso> .BASE and .THIS
<mwhudson> Peng: maybe it's better now anyway, not your fault
<spiv> tonyyarusso: and look at the file itself
<spiv> tonyyarusso: the conflicting region(s) will have markers like <<<<<<< ======= >>>>>>> in it.
<spiv> er, s/in it/around it/
<tonyyarusso> oooh, ok
<Peng> mwhudson: I hit the "Try again" button on one branch -- let's see if it works.
<tonyyarusso> spiv: um, by "the file itself", do you actually mean one with .~1~ appended to the name?
<Peng> mwhudson: The puller did hit my server, but LP still reports an error. (https://code.edge.launchpad.net/~mnordhoff/loggerhead/cheezum)
<spiv> tonyyarusso: the file that has the conflict, usually
<spiv> tonyyarusso: unless you have a conflict where both sides added a file of the same name.  (More common is both sides modified the same file that already existed)
<mwhudson> Peng: hmm
<tonyyarusso> spiv: well, the issue is the file with the conflict is listed as 'style.css', but that doesn't appear to exist right now.  I have a style.css.~1~, style.css.20100204 (a separate backup I made a few days ago manually), style.css.BASE, style.css.orig (I'm not sure about that one), and style.css.THIS
<tonyyarusso> only .BASE and .THIS have file modification times of today.
<spiv> tonyyarusso: ok, I'd guess you have the more complex kind of conflict, i.e. that both sides added (or renamed) different files to have the name 'style.css', or something like that.
<spiv> tonyyarusso: pastebin the output of "bzr conflicts"?
<spiv> And "bzr st"?
<tonyyarusso> no need for pastebin on the former - it's one line:  /home/drupal/sites6/ubuntu-minnesota.org/themes/ubuntu-drupal-theme
<tonyyarusso> the latter has "renamed: style.css => style.css.THIS; added: css/style.css; unknown: style.css.BASE"
<spiv> tonyyarusso: "bzr conflicts" just shows a filename, not "Text conflict in $filename"?
<tonyyarusso> spiv: bah, bad copy-paste.  "Contents conflict in style.css
<spiv> tonyyarusso: ok, IIRC this is because one side has modified the file (yours probably judging by what you've said), but the other has deleted it
<tonyyarusso> spiv: Yes, I have modified that file manually.  So most likely, upstream tried to move style.css to css/style.css, and got confused b/c I had modified something it wants to delete, right?
<spiv> tonyyarusso: I suspect from the "bzr st" output that someone might have accidentally deleted it and then added it again (as a new file) to rename/move it
<spiv> tonyyarusso: exactly! :)
<tonyyarusso> hrm, ok
<spiv> tonyyarusso: so the resolution is mostly likely to either apply your changes to the new file, or revert the deletion, and move your file to the new location...
<spiv> tonyyarusso: ...and tell whoever made that change to use "bzr mv" next time, or even "bzr mv --auto".
<RAOF> Man, âgit add -iâ makes me *long* for bzr shelve.  What the hell are you supposed to do with this prompt: âStage this hunk [y,n,q,a,d,/,j,J,g,e,?]?â
<bob2> you want magit
<RAOF> Ah, no.  Actually I wanted âgit add -pâ.
<vila> hi all !
<bialix> ÑÑÐ½Ñ Ð¼ÑÐ´Ñ!!!
<bialix> heya vila!!!
<vila> :D
<chx> lifeless: ping
<lifeless> chx: hi. Is this re: the mail you sent me? I've replied.
<chx> lifeless: yes. i saw. :)
<chx> lifeless: just wanted to ask whether you want me to collect the more interesting points or you guys will read the (rahter interesting) thread
<lifeless> I'm not sure at this point
<lifeless> I'm hoping jam or someone will volunteer to be a resource for you
<lifeless> in my experience its best to have someone like yourself or emma as a primary advocate though
<lifeless> for now, until I hear back, I suggest mailing anything specific that is a concern/needs more info to the main bazaar mailing list
<chx> I will do that , OK
<chx> And we are advocating -- David Strauss and myself, I will get hold on Emma once she is bakc from NZ
<lifeless> chx: excellent
<bialix> chx: battle for drupal?
<chx> bialix: yes
<bialix> gimme a link please
<chx> http://groups.drupal.org/node/48818
<mneptok> I WANNA BE AN ELF-WARRIOR WITH A +3 BOW OF PHP!
<mneptok> wait ... does PHP allow +?
<chx> the discussion so far is suprisingly sober
<fullermd> mneptok: Of course.  It may even mean what you want it to.
<chx> or may not
<chx> :p
<fullermd> Doesn't Drupal still have a semi-active bzr mirror around from $YEARS ago when jblack was talking to them?
<chx> i write phpwtf.org so you dont need to tell me that php is weird
<chx> fullermd: we have a launchpad mirror which i use.
<chx> fullermd: thanks god
<quicksilver> vila: finally got around to finishing and sending that email to the bzr list. Sorry it took so long.
<mneptok> ohcrap.
<mneptok> i just put on a Ring Of Power and now register_globals is enabled.
<mneptok> THE EYE CAN SEE ME!
<vila> quicksilver: great, thanks
 * fullermd writes it for a living; no secret here either   :p
<chx> fullermd: it would have been better to move to bzr in 2006 yes but it did not happen alas. We are a lot bigger so it might be a bit harder but it's also our growth that made CVS unbearable. And let's face it, these last four years made bzr a lot better too.
<chx> mneptok: i already told you that you do not need to bash PHP to me. I can do it a hell lot better and evne do it on a blog as mentiond. And register_globals is gone for good for one, two, Drupal worked around it for years and now simply refuses to run if it is on...
<chx> mneptok: i came here for help and not (the rather boring and tiring) PHP bashing. There is more to picking a system than the language it is written in.
<mneptok> uh. wow. easy there, tiger. i'm not "bashing" PHP. i'm not bashing Drupal. i'm trying to make people smile a little.
<vila> mneptok: you failed :D
<mneptok> vila: apparently not. ^^
<vila> As I *try* to teach my daughters, humour is a risky job, sometimes you had to assume the consequences, bear with it and keep bashing :D
<vila> mneptok: I was meta-smiling :D
<mneptok> vila: woot! meta-success!
<vila> LOL
<gerard_> morning
<vila> chx: you're preaching the chore, we're all using bzr....
<vila> hi gerard_
<fullermd> Humor == brute force?  If it doesn't work, you're not using enough?
<chx> vila: yes I do. But there are a couple thousand Drupal developers who dont.
<gerard_> fullermd: heh
<chx> vila: we have an excellent chance to change that.
<vila> chx: I was referring to "There is more to picking a system..." :D
<vila> chx: I agree with lifeless, things work better when some ambassadors act as gateways, we have limited resources so focusing on ambassadors's summaries is the most effective way to help
<vila> chx: if there are bugs that are more important to the drupal community, flag them as such (affects-drupal or something)
<chx> hm, then i need to check whether there is a bug for friendlier unshelve
<vila> chx: if you need help setting up some central server, ask here
<chx> oh infra knowledge we have aplenty :)
<vila> chx: you know about 'bzr unshelve --preview' right ?
<vila> chx: yeah, silly me :D
<mneptok> chx: GNOME went through similar machinations not long ago. although outdated, this might provide some useful info and topic points - http://live.gnome.org/DistributedSCM
<chx> last i checked (which was this year) you could only specify a numeric id for unshelve
<chx> and not the message
<chx> let me retest so i can speak more coherently :)
<quicksilver> that's how it seemed to me when I chcked out unshelve just a few weeks ago
<quicksilver> that sounds like a really easy one to fix, too :)
<bialix> wise words, vila, about your daughter.
<chx> vila: bzr: ERROR: no such option: --preview
<vila> bialix: two daughters even :D lunches and dinners are more and more... interesting :D
<vila> chx: upgrade ! :D
 * bialix was bitten in the past for not looking forward before start joking on risky themes :-/
<vila> chx: let me check
<bialix> vila: w00t!
<chx> No packages will be installed, upgraded, or removed.
<chx> i am on 2.0.2
<bialix> chx: unshelve --preview is in 2.1
<mneptok> "let's poke fun at $LANGUAGE" in an IRC dev channel is not risky. it's a hard requirement.  ;)
<chx> and what does it do? shows the patch to be applied?
<bialix> yep
<vila> chx: revno 4955 so yes, part of 2.1
<bialix> but it fails for me yesterday with non-ascii
<vila> chx: it shows the corresponding diff
<lifeless> mneptok: klingon!
<fullermd> mneptok: Pfft.  That sounds like something a COBOL programmer would say...
<lifeless> vila: choir
<lifeless> vila: chores are boring tasks ;)
<vila> lifeless: it's like hhtps, it's too late now, I will take the one for the other for years to come ;D
<mneptok> lifeless:  Hab SoSlI' Quch!
<vila> lifeless: I was so sure to get it right this time...
<vila> :-D
<ronny> fullermd: join the curch of cobol now for final salvation
<bialix> ooo, hhtps! that's cool
 * fullermd has been dreaming of cobol's "final salvation" ever since he had to learn it...
<vila> COBOL got the boring printed report descriptions right, I've never since better since then....
<mneptok> COBOL's final salvation is the banking industry.
<lifeless> mneptok: in lucid, you can enable it ;)
<vila> mneptok: yeah, that's what I just said no ?
<ronny> oh ffs - im still in #cobol
<vila> ronny: yeah ! Don't you love putting 'D' in column 7 ?
<ronny> lol, every few dats someone got in and declared cobol dead
<ronny> and a few weeks ago i explained the religion of cobol to someone
<vila> ronny: and how about: Error: '.' is missing
<mneptok> ronny: idle     : 6335 days 4 hours 44 mins 30 secs [signon: Jan 31 00:00:00 1969]
<ronny> damn, i must have been drunk to get such an idea
<vila> mneptok: lol
<vila> err, wait, let's stop bashing COBOL, chx is still around
<chx> bah
<vila> . o 0 (Will chx smile on this one ?)
<ronny> cobol aint that bad, its a pretty good worst case example
<vila> . o 0 (Darn, missed again)
<chx> i apparently have a humour detector fail :)
<vila> \o/
<vila> ronny: stop ! stop ! someone will try to find worst !
<mneptok> chx: dude, i have like 10 ex-girlfriends that would LOVE you.
<mneptok> ;)
<fullermd> At once?  That sounds hazardous.
<mneptok> not really. just expensive.
<ronny> vila: once someone explained to me how to sort a words file in just as little 100 loc of cobol
<vila> . o 0 (girlfriends load test harness... worst a try ?)
<vila> worse, damn
<mneptok> "worth"
<vila> no, worth, or something
<mneptok> *patpat*
<vila> on reflexion worst wasn't such a bad joke :D
<fullermd> Yeah, I thought it rather apropos.
<exs> hi
<exs> i want to hold a single file and revert all other files two reversions back
<vila> cp file SAFE; bzr revert; cp SAFE file ?
<vila> rm SAFE
<vila> exs: bzr shelve/unshelve *may* work too
<exs> ok will tryin
<exs> thx
<bialix> exs: qrevert
<bialix> err, no
<bialix> qrevert can't do two revisions back
<exs> ok i do not use kde
<bialix> bad bad qrevert
<bialix> exs: people on gnome using it too, I guess
<exs> bialix: maybe but i like the commandline more
<bialix> no problem.
 * bialix also likes command line
<exs> also i want just to become better in bzr so i asked the question in the hope to learn more and new methods working with bzr
 * gerard_ loves lighweight checkouts :)
<gerard_> I'm switching around git style
<exs> and how to unignore certain files? ivh not found any commands for this issue
<bob2> edit .bzrignore
<exs> can i simply delete this file?
<fullermd> A lot depends on exactly what you mean by "unignore"...
<bob2> you almost certainly don't want to delete it
<exs> i vh ignored only two files and after i delteded it and commited there was a line informed me that the .bzignore is missing. is this very worse?
<bialix> gerard_: colo ftw!
<junak-michal> Hi. I was trying to send bugfix to bzr through launchpad. More information here https://code.launchpad.net/~junak-michal/bzr/giveback/+merge/18297. I was advised to send an email for accepting contributor agreement so i did it (from the mail I use as launchpad login). I want to ask if I should do something else or if it is okay now. Sorry for stupid question, but I am kind of confused.
<spiv> junak-michal: that sounds fine to me
<spiv> junak-michal: (thanks!)
<exs> one more question. what does revert --no-backup does? which backups are means?
<spiv> junak-michal: oh, and if for some reason there's more required, a developer will let you know.  Reviews and the like don't always happen immediately, but we mostly manage within a day or two.
<spiv> exs: see "bzr help revert":
<spiv> By default, any files that have been manually changed will be backed up
<spiv> first.  (Files changed only by merge are not backed up.)  Backup files have
<spiv> '.~#~' appended to their name, where # is a number.
<exs> i dont see any # files in my directory
<spiv> exs: it would be FILENAME.~1~
<spiv> not literally #
<exs> ah ok
<exs> thx
<spiv> (or FILENAME.~2~, etc)
<exs> can you answer me one more question. which advantages i get if i use init-repo?
<fullermd> Space savings by sharing history among branches.
<spiv> the branches inside the repo will share that repo, which means only one copy of revision data.  That saves space (and time when creating and deleting branches)
<exs> that means there are no more commands or feature i can use if i have a repo inited, but the .bzr directories are more organized and work faster?
<spiv> exs: right
<exs> ok thx. i have in one directory an inited dir without a repo. but i want to do the repo to the parent direcory. can i do it simply?
<exs> so the repo accept the inited dir?
<fullermd> Yes.  With the exception of a few dark edge cases, everything should act exactly the same.  Just faster.
<spiv> exs: you should be able to init-repo the parent, then "bzr reconfigure --use-shared" in the branch
<fullermd> You can init-repo to create the repo, and then use reconfigure (--use-shared I think) to change that existing branch to use the now-present repo.
 * fullermd gives up and lets spiv do the typing   :p
<spiv> Actually, I'm about to go to bed, but thanks :P
<fullermd> Bed?  Nonsense.  The sun isn't even up yet.
<junak-michal> spiv: thanks:-)
<exs> and how to rename a branch?
<exs> just bzr mv bla blanew?
<beuno> exs, rename a branch?
<beuno> you can just rename the directory
<exs> can i mv the repo after init?
<exs> for example bzr init-repo bla and then mv bla to subdir/bla?
<beuno> exs, yes, as long as you take the .bzr dir with you, it's all good
<spiv> exs: so long as the branches are still subdirectories of the repo, sure
 * spiv -> bed
<exs> ok thx
<exs> lol
<Lamba> hello (this is in relation to launchpad project).  - im getting an error about being unable to lock a file when i try to push, i've used the brek-lock but it gives the same lock error when i try push again. anyone know an easy way out of this mess ?
<Lamba> break-lock*
<Lamba> i should mention its only me using the repo. - i lost net connection during a push which caused this.
<vila> Lamba: hmm, the simplest way may be to just delete the branch on launchpad
<Lamba> ive just this second fixed it... - apparently break-lock bzr+ssh & break-lock sftp dont actually break the lock. - i did break-lock lp:~username and bingo.
<Lamba> bit confusing because bzr's error message says to uzr bzr+ssh, but hey ho :) - least i know now
<Lamba> use*
<vila> Lamba: hmm, as long as 'lp~username/...' aliases to the same branch, that's equivalent :D
<Lamba> yea, odd thing was the bzr+ssh and sftp ones didnt ask for a y/n response, just dropped back to prompt. oddness.
<vila> Lamba: then it may mean there wasn't a lock there to break...
<vila> ach, he's gone :-/
<GaryvdM> Hello
<rubbs> hello
<GaryvdM> The bzr version in the beta ppa is out of date (it has 2.0.1) - I'm going to have a shot at updateing it.
<GaryvdM> Err - I guess if I do that, I also need to do all the plugins to. :(
<GaryvdM> jam: The list that you had in this mail: http://www.mail-archive.com/bzr-windows@lists.launchpad.net/msg00274.html
<GaryvdM> Is there an update version.
<jam> GaryvdM: you can just look at lp:bzr-windows-installers or lp:~bzr/bzr-windows-installers/2.0, the file tools/win32/buildout.cfg has the list of files and versions
<jam> off-hand, there is a newer qbzr, bzr-explorer and bzr-xmloutput
<GaryvdM> Ah - cool
<GaryvdM> Thanks
 * quicksilver utters a long and ugly ancient egyption curse at mailman's ridiculous default settings, and chases his preferences on yet another mailman installation.
<bialix> evening GaryvdM!
<bialix> nice to see you here
<GaryvdM> Hi bialix
<GaryvdM> I'm busy trying to get the beta ppa up to date...
<bialix> igc: ping
<bialix> GaryvdM: should we CC announcement mails about qbzr releases to debian maintainers?
<GaryvdM> Maybe. I think that they have tools to do that automatically. See http://qa.debian.org/developer.php?login=pkg-bazaar-maint@lists.alioth.debian.org
<Tak> hmm, is dpush part of bzr core, or something like rebase?
<bialix> jelmer: ^
<GaryvdM> And http://dehs.alioth.debian.org/report.php?package=qbzr
<jelmer> bialix, GaryvdM: I'll leave updating up to Stefano
<bialix> hi jelmer, Tak asked about dpush
<jelmer> Tak, it is in core
<GaryvdM> Hi jelmer
<jelmer> Tak, ('bzr help commands' will tell you what plugin a command lives in)
<bialix> cool, we're now pstream
<bialix> cool, we're now upstream
<Tak> yeah, I forgot about hidden-commands
<GaryvdM> bialix: In the debian package is a watch file, which is configured to check our downloads page.
<bialix> great
 * Tak #519382
<jelmer> bug 519382?
<ubottu> Launchpad bug 519382 in bzr "dpush reverts added files" [Undecided,New] https://launchpad.net/bugs/519382
<gerard_> jam: got some time to continue reviewing my changes to update?
<jam> gerard_: done, in case you didn't see the update
<gerard_> jam: thx, didn't see it yet ;)
<jam> vila, poolie: did you see any update about Junak signing the contributor agreement?
<vila> jam: EODed but, Junak was here a couple of hours ago, I missed him but he sounded like he sent the mail for the agreement, so it should be somewhere in the pipes...
<jam> vila: I'll have to take control of your machines then... :)
<jam> thanks for checing
<jam> checking
<jam> Sort of makes me wish LP had a "blocked on X" status
<jam> Having to read the mp comments to determine that is a pain
<jam> I suppose even just a "Whiteboard" for merge proposals might suffice
<poolie> hi vila
<poolie> jam, in https://code.edge.launchpad.net/~abentley/bzr/lpsubmit/+merge/18876 i think you should have picked up on the lack of docs too
<vila> poolie: enjoying early wake-ups when coming from Europe ? :-/ :-)
<poolie> :/
<vila> jam: a whiteboard sounds like a good idea
<vila> poolie: :-(
<vila> poolie: I half hoped I was wrong :-/
<jam> poolie: it just makes you a morning person, able to get done before lunch what most people take all day to accomplish
<abentley> poolie, you say "It looks like [lp-submit] creates a merge proposal or requests a merge - that's what the Launchpad UI calls it but this seems to have no connection."  What do you mean?
<poolie> does this create a merge proposal?
<abentley> poolie, yes.
<poolie> but the term 'merge proposal' doesn't occur anywhere in its ui
<poolie> or help
<jam> abentley: I guess that since it wasn't obvious to poolie, it could use some further explanation in the doc string
<abentley> poolie, I'll add that.
 * gerard_ is looking for a second reviewer for https://code.launchpad.net/~gerard-/bzr/update/+merge/18464
<gerard_> it's about the coolest merge proposal ever
<gerard_> or maybe not
<poolie> i'm happy to have it
<gerard_> only one way to find out ;)
<poolie> hi gerard_
<poolie> i think it would be good
<poolie> i'll try to get to it later
<gerard_> hey poolie
<poolie> though i think vila is meant to be ppa this week still
<vila> poolie, gerard_ : I plan to do it tomorrow morning first thing, I only saw jam's review some minutes ago
<poolie> i have some more things to put into the queue from my flight
<vila> err, tomorrow morning my TZ so, in ~12 hours
<gerard_> vila: that's morning for me too ;)
<vila> gerard_: ok :D
<poolie> our patch queue is getting long again
<poolie> kind of good in a way
<poolie> but you can have too much :)
<vila> poolie: not too much from non-core though and I hope to reduce it before Friday :D
<vila> poolie: did you get a mail from Junak for the contributor agreement ?
<vila> poolie: He was here a couple of hours ago, I missed him but he sounded like he sent the mail for the agreement, so it should be somewhere in the pipes...
<gerard_> the contributor agreement looks kinda scary I must admit
<gerard_> lots of open source projects ask for copyright assignment, but most are really informal about it
<poolie> gerard_, kfogel and i are working with our lawyers on it
<poolie> in fact he just sent me a new draft faq
<poolie> so any further comments are welcome
<jam> I would also mention that most open source projects aren't backed by something worth suing :)
<gerard_> I don't like point 5 and the "other license terms" of point 6
<gerard_> jam: yeah, you've got a point there
<poolie> re clause 5, lawyers understand that to mean you promise to do small non-onerous things
<poolie> we will clarify this
<poolie> and re clause 6, it allows for dual-licencing but not for the code to be closed up
<lifeless> moin
<poolie> hello lifeless
<keithhub> ok
<emmajane> Lord love a duck: http://groups.drupal.org/node/48818. Reading through the comments on how people pick a dvcs is making my head spin.
<lifeless> emmajane: ola
<lifeless> hi poolie
<emmajane> lifeless, ola :)
<gerard_> emmajane: interesting read
<gerard_> git is absolutely horrible to script
<emmajane> I'm about 3/4 of the way down now.
<emmajane> apparently it's trivial according to the summary here. :/
<emmajane> 3/4 down the comments I should say.
<gerard_> I wrote a 2way git<->svn gateway script and it wasn't nice
<lifeless> ease in the fingers of the scripter
<emmajane> the summary at the top was pretty straight forward but *very* git-leaning
<lifeless> *ease is in*
<mwhudson> emmajane: are you in wellington today?
<gerard_> lifeless: I guess so, but who doesn't like python better than bash?
<gerard_> aaah, what did I do? did I just compare two languages on irc?
 * emmajane thinks hard. Looks outside, notes it's overcast... yes. Wellington.
<emmajane> gerard_, :)
<emmajane> mwhudson, I'm staying with sharrow and metlermmind? (adam) this week. then up to AKLish for the weekend then back down to WLG on Monday evening then fly out on Thursday for SCaLE.
<mwhudson> emmajane: cool
<mwhudson> (it's been sunny until you got here!)
<mwhudson> :)
<emmajane> mwhudson, sure sure. :)
<mwhudson> emmajane: i'm in town today, want to meet for a coffee or something?
<poolie> hello emmajane, mwhudson
<lifeless> emmajane: adam shand?
<emmajane> lifeless, no. erm. Adam B. Security bearded kiwi dude.
<emmajane> mwhudson, oo. I like coffee.
<lifeless> :)
<gerard_> heh, #bzr, also know as #canonical ;)
<thumper> gerard_: not entirely :)
<mwhudson> emmajane: so do i, although i'm trying to not be entirely dependent on it these days...
<emmajane> mwhudson, pfffbt. what fun is that?
<gerard_> thumper: says ~quassel@canonical/launchpad/thumper ;)
<thumper> gerard_: heh, yeah, I know
<thumper> gerard_: emmajane isn't a canonical bod
<thumper> and I'm sure there are others
<emmajane> gerard_, nor is davidstraus_s
<emmajane> we're both here from drupal
<jam> vila: shouldn't you be asleep?
<emmajane> chx is normally here too (also drupal)
 * vila snores
<jam> well, at least not working :)
<emmajane> nor is sdboye_r
<emmajane> (also drupal)
 * vila snores and has fun
<emmajane> tonyyaruss_o's ubuntu, not canonical, IIRC
<emmajane> and abentley's Canadian. so that hardly counts as canonical. it's way cooler. ;)
<gerard_> hehe
<emmajane> lifeless,    Adam Boileau - Hacker (the security/cracking sort, Kiwicon organiser, pundit, aka "metlstorm"), unix, big networks. black metal. beer. beards.
<gerard_> I still need to write some tool to make a nice tag cloud of all the channels the people in a channel are in + their cloaks
<emmajane> enfin. I found it.
<emmajane> mwhudson, where are you in Wellington?
<mwhudson> emmajane: i'm in the central library right now
<emmajane> mwhudson, that's down next to the LCA venue?
<mwhudson> emmajane: yeah
<mwhudson> emmajane: where are you?
<emmajane> mwhudson, in my PJs about a 20 minute walk from the ustay.
<mwhudson> emmajane: i see
<emmajane> so maybe post-lunch?
<emmajane> or for lunch?
<mwhudson> yeah, lunch would make sense
<RenatoSilva> verterok: hi
<emmajane> \o/
<mwhudson> i'm meeting my accountant (exciting!!) at 12
<emmajane> WOO!
<mwhudson> and he's in the left bank on cuba mall
<emmajane> I know the cuba mall.
<emmajane> the left bank is where the yarn shop is?
<mwhudson> knit world?
<emmajane> yeah
<mwhudson> yeah, that's around there
<RenatoSilva> spiv: you are who I was talking to yesterday about bug 480684, right?
<ubottu> Launchpad bug 480684 in bzr-search "Show revisions whose diff contains the search string" [Undecided,Incomplete] https://launchpad.net/bugs/480684
<mwhudson> emmajane: meet you there at 12:30?
<emmajane> mwhudson, that could work nicely. :)
<mwhudson> emmajane: awesome
<emmajane> and then it got sunny out.
<emmajane> clearly that was the right thing to play. :)
<verterok> RenatoSilva: hi
<mwhudson> emmajane: the forecast is for it to get bad later :/
<mwhudson> wow battery suckage
 * mwhudson heads off to find powah
<emmajane> mwhudson, I'll take it personally that wellington only has bad weather when i'm around. ;)
<mwhudson> :-)
<vila> emmajane: you scare their sun ? Shining too much ? :-P
<mwhudson> actually bian
<mwhudson> biab
<emmajane> vila, apparently. :)
<emmajane> mwhudson, laterz
<gerard_> ok guys, I'm off
<emmajane> I think I may just need to get tshirts printed that read, "Git makes me angry inside"
<lifeless> \o/
<emmajane> http://groups.drupal.org/node/48818#comment-130248 <-- I've said it again.
<emmajane> turns out: I actually like saying it. :)
<mkanat> emmajane: If you need any help with your argument, I just did a full migration from CVS to bzr for Bugzilla.
<mkanat> emmajane: I have a script that also perfectly syncs bzr branches back to CVS.
<emmajane> mkanat, nice. :)
<mkanat> emmajane: So that people can continue to use CVS as a read-only repo.
<emmajane> davidstrauss may want to know that too.
<mkanat> emmajane: That allowed us to not have to modify any of our build tools right away, because they all just kept using CVS.
 * emmajane nods
<RenatoSilva> verterok: if I have some time maybe I'll help on that bug
<davidstrauss> emmajane: pardon?
<verterok> RenatoSilva: awesome, thanks! I'll try to take a look to it later this week
<emmajane> davidstrauss, see mkanat's comments just above.
<verterok> RenatoSilva: I was thinking to provide the --encoding option only for the xml* commands and always use UTF-8 for the xmlrpc-service
<RenatoSilva> verterok: I think we need to find the way for one single command, and repeat that for all the other commands. If we create a shared branch and we finish step 1, I may ocasionally contribute to step 2 till we get the whole task done
<mkanat> emmajane: Also, I don't know if you're going to use launchpad or your own server, but we have the whole process of setting up our own bzr server documented.
<davidstrauss> mkanat: Is it built on Tailor?
<mkanat> davidstrauss: No.
<mkanat> davidstrauss: It actually syncs the literal file content one commit at a time by using bzr and cvs directly.
<RenatoSilva> verterok: that patch seems to be a solution but it breaks tests, so we need to check this
<mkanat> davidstrauss: So it catches "renames" and all that from bzr properly.
<davidstrauss> mkanat and emmajane: We're pretty well equipped for deploying Bazaar on our side. I handled institutional deployment at Yale for some projects, and we use it internally and with clients.
<davidstrauss> mkanat: Doesn't Tailor do that?
<mkanat> davidstrauss: Also, it can do unlimited numbers of branches.
<RenatoSilva> verterok: doesn't it already contains some kind of encoding arg? iirc youhad implemented that already, hadn't you?
<davidstrauss> mkanat: ah, now that's a nice thing
<davidstrauss> mkanat: Tailor scales poorly with many branches from an administration perspective
<mkanat> I can see that.
<verterok> RenatoSilva: I think that patch jkust encode/decode everything as UTF-8
<mkanat> I mean, right now, the way the script works is that you have to specify the --from and --to branch on the command line, but it could be re-worked pretty easily to just take a config file or read a directory or something.
<mkanat> davidstrauss: Anyhow, if you want to look at it, it's at bzr://bzr.mozilla.org/bzr-plugins/bzr-to-cvs/
<emmajane> mkanat, thanks. :)
<mkanat> emmajane: Welcome. :-)
<davidstrauss> mkanat: thanks :-)
<mkanat> Welcome. :-)
<RenatoSilva> verterok: statically like I said, then we would add the arg (which I thought to already exist)
<RenatoSilva> verterok: anyway, if I ltake a look/create a branch, I'll let you know
<verterok> RenatoSilva: yeap, I'll try to refactor that for all commands
<verterok> RenatoSilva: cool, thanks!
<RenatoSilva> verterok: thanks you too
<emmajane> ok. I should probably get ready to head out into the real world.
<RenatoSilva> lifeless: hi, I have created a small tool for the bzr search bug
<RenatoSilva> simply based on log -p output
<RenatoSilva> gtg syl
<goundy> Hi
<goundy> I use bazaar through FTP. I pushed 4 revisions
<goundy> it only pushed 2... and when I restart push it says no revisions to push
<goundy> (I committed and everything)
<goundy> Any ideas ?
<davidstrauss> goundy: How did you get your numbers?
<goundy> davidstrauss, by running bzr log in local
<goundy> davidstrauss, when I pushed the last 2 revisions it acted like if it was done successfully, no errors... etc
<goundy> the first 2 revisions had only one file (Test.txt) and it's there. The following revisions added many folders and files
<davidstrauss> goundy: and how do you know there are only two revisions on the remote branch?
<goundy> weird because I remember I used it before and it worked
<goundy> davidstrauss, by checkout
<davidstrauss> goundy: are any revisions merged?
<goundy> davidstrauss, yes actually I've working/ and mainline/ in local
<goundy> I work in working, merge into mainline and push mainline to the ftp location
<davidstrauss> goundy: are you running log with -n0?
<goundy> davidstrauss, no
<davidstrauss> goundy: It's best to run that to see what revisions are there. Different branches can have the same revisions as parents of merges (and hence hidden to normal bzr log).
<goundy> davidstrauss, when I checkout I get only the Test.txt that shouldn't exist anymore, and I don't get the rest of the source code
<davidstrauss> goundy: are your branches public or accessible in a way I can look?
<goundy> and still, bzr log -n0 gives 2 revisions
<goundy> davidstrauss, oh ftp credentials are required, and these are belong to the guy I work for. I do fully trust you but I don't feel confortable toward him by giving you the access ^^
<davidstrauss> ok
<goundy> davidstrauss, well look nevermind
<goundy> I'll try to find a server to host the sources
<goundy> and thank you very much
<davidstrauss> goundy: I'm not sure how to help unless you can at least package up the branches for some review
<davidstrauss> ok
<goundy> davidstrauss, I can package them but I really think it's useless because I'm sure I didn't do anything wrong. I just did it the way I always do, well am gonna use a server anyway
<goundy> Thank you very much
<davidstrauss> ok
<mtaylor> lifeless: any suggestions on how I get started hacking on a pre-existing hudson plugin (like bzr-hudson) ?
<lifeless> mtaylor: get netbeans; follow the wiki page for checking out the source. do mvn hpi:run in the bzr directory and check it works
<lifeless> mtaylor: you'll need the official sun java btw
<mtaylor> lifeless: sigh.
<lifeless> mtaylor: its in Ubuntu
<mtaylor> lifeless: thanks
<lifeless> mtaylor: just a different packae
<mneptok> lifeless: "official oracle java"
<lifeless> mneptok: 'meh'
<mneptok> lifeless: i'll agree with that, but use <capslock> :)
#bzr 2010-02-10
<cxo> How do you clone just the last revision of the repository?
<mkanat> cxo: I think you might want bzr checkout --lightweight
<spiv> lifeless: I suppose you saw the mail about setUpClass on python-dev?
<mwhudson> spiv: that dull thumping sound is robert's head meeting the wall, i think
<spiv> mwhudson: good good
<lifeless> spiv: fuzzyman mailed  me directly
<lifeless> spiv: I'm getting out of sprint backlog at the moment though
<mwhudson> lifeless: the fix for https://bugs.edge.launchpad.net/bzr/+bug/513432 should be deployed now, do you have a simple recipe to verify?
<ubottu> Ubuntu bug 513432 in launchpad-code "AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo'" [Critical,Confirmed]
<james_w> mwhudson: create a local 2a repo, branch an older format in to it
<mwhudson> james_w: ok, happens for every such attempt?
<james_w> I think so
<james_w> trying with the project I saw someone hit the problem with
<mwhudson> it seems to be fixed then
<james_w> yeah
<lifeless> mwhudson: that should verify it, yes.
<mwhudson> lifeless: ta
<lifeless> mwhudson: and just to be sure, you did preserve the other hotfix we had ?
<mwhudson> lifeless: the thread safety one?
<mwhudson> lifeless: yes
<mwhudson> (though the server in question _hasn't_ been rolled out to yet, so it still has a cowboy afaik)
<lifeless> cool
<poolie> mwhudson, thanks for that
<mwhudson> poolie: np, it still seemed to take about a week longer than it should
<RenatoSilva> lifeless: I have no idea of what "Show hits as a diff " means
<poolie> i wasn't going t omention that :)
<RenatoSilva> lifeless: and I can't get the problem with "Show revisions whose diff contains the search string"
<RenatoSilva> lifeless: and mainly, how they relate to each other
<lifeless> well, if you stay on irc for more than 60 seconds we can talk about it :)]
<lifeless>  /rant
<poolie> mwhudson, i added a bzrlib.initialize which you asked for
<poolie> so you should give me a review :)
<RAOF> Is there any way that bzr could preserve the rich-root status of a branch when branching from a non-rich-root branch into a rich-root repository?
<RAOF> Now that 2a is the default repository, I tend to accidentally trap my changes into a rich-root situation and then pushing back to lp fails.
<RAOF> Alternatively, how can I easily rescue a series of changes from a rich-root repository?
<lifeless> RAOF: ideally get the other end to upgrade
<lifeless> failing that for x in revno: bzr diff
<RAOF> :(
<lifeless> in principle rebase can do it
<lifeless> there is a certain amount of '
<lifeless> exercise for the reader
<lifeless> '
<lifeless> involved
<RAOF> Would it be possible to somehow keep the non-rich-root status of a branch pulled into a rich-root repository?  This is a significant cause of friction I've run into.
<lifeless> RAOF: not in the current repositories, not
<lifeless> *no*
<RAOF> But in future?
<lifeless> its code, anything is possible.
<lifeless> I don't expect anyone to do the heavy (and its fairly heavy I think) lifting involved
<lifeless> we could make branch error unless given a flag
<RAOF> Right.  That's what I wanted; an evaluation of whether it's worth filing a bug.
<lifeless> though I'm not sure that that is a good idea
<lifeless> RAOF: file a bug, we can gather 'affected by' counts ;P
<RAOF> Looks like it's bug #506556
<ubottu> Launchpad bug 506556 in bzr "Branching does not maintain compatibility with parent" [Low,Confirmed] https://launchpad.net/bugs/506556
<lifeless> me too it then :)
<RAOF> Have done.
<gerard_> morning
 * vila waves@gerard_
<vila> gerard_: I'm reviewing your patch
 * emmajane waves.
<vila> gerard_: out of curiosity, what editor are you using ?
<emmajane> I've just had someone ask me about syncing upstream source with downstream plugins. Maybe like svn vendor branches? I know I've seen this asked about on the mailing list loads but I can't figure out where in the docs the answer is... it's not just tagging releases, is it?
<vila> emmajane: weird, you were here during my late evening and you still here in my early morning, don't you ever sleep ??? :D
<emmajane> vila, I'm in NZ. :)
<emmajane> vila, It's 2130 here.
<vila> emmajane: right, so we are both working far too late in the evening ;D
<emmajane> :)
<vila> upstream source and downstream plugins, the first is singular the second plural, are you talking about branches in both cases ?
<emmajane> they're writing a plugin that needs to be synced with the upstream source.
<mkanat> emmajane: That's a pretty standard DVCS case, it sounds like to me.
<emmajane> yah.
<vila> the upstream source is a plugin too or more than just the plugin ?
<mkanat> emmajane: You just want to merge from upstream into downstream, right?
<emmajane> mkanat, and know which version of the plugin applies to what upstream version of the full code base.
<mkanat> emmajane: cd /local/checkout; bzr merge bzr://path/toupstream
<mkanat> emmajane: Well, that's more a code decision than a VCS decision.
<vila> emmajane: you don't strictly need to track the upstream version as long as you can merge
<mkanat> emmajane: But if you do merge --remember, it remembers where you last merged from.
<vila> it remembers at the first merge
<emmajane> mkanat, so it would know that bug fix #3 applies to upstream release 4.0alpha?
<mkanat> emmajane: What would know?
<vila> --remember can be used to change afterwards
<emmajane> it == the plugin that's being written.
<mkanat> emmajane: If you check it in to that branch....
<mkanat> emmajane: I assume you'd have different branches for the different upstream versions.
<emmajane> ahh, right. so just a new branch for each version of upstream?
<emmajane> yah
<mkanat> emmajane: Yeah.
 * emmajane nods
<emmajane> http://wiki.bazaar.canonical.com/TrackingUpstream is that page what i'm looking for?
<emmajane> I think I'm trying to make it harder than it is? :)
<mkanat> emmajane: That's certainly possible. :-) It's very simple. :-)
<mkanat> Anyhow, I'm off to bed. :-) Night all!
<gerard_> vila: good :)
<gerard_> vila: geany
<gerard_> did it do weird stuff?
<vila> gerard_: can you configure it to avoid leaving spaces at end of lines ?
<gerard_> vila: yeah, no problem
<vila> gerard_: not a big deal, but we try to get rid of these damn spaces :D
<gerard_> invisible characters are annoying anyway
<gerard_> a few days ago I had some trouble with a non breaking space char that was messing up search and replace :p
<vila> gerard_: my gut feeling is that jam mentioned more cases than your tests covers, should I dig deeper or can you quickly confirm ?
 * bialix waves heloo all
<vila> hi bialix
<bialix> bonjour vila!
<bialix> hello davidstrauss, how's drupal dvcs contest going?
<bialix> hi jelmer
<gerard_> vila: yeah, he mentions one more
<davidstrauss> bialix: Well enough. The debate for Drupal is turning out quite different from the one for most projects.
<jelmer> HI bialix
<gerard_> to be honest, I didn't check that one
<gerard_> but I have a good feeling about it ;)
<bialix> davidstrauss: that's good
<vila> gerard_: good, I'm cleaning up some details and I let you know where to get an updated branch so you can build on it if that's fine with you
<davidstrauss> bialix: I'm glad to see that it hasn't devolved into another silly performance contest. Just because performance gives easy objective numbers doesn't mean it's a good way to decide.
<bialix> right
<gerard_> vila: what do you mean with "build on it"?
<vila> gerard_: more concretely, I'm looking into rewriting test_update_checkout_prevent_double_merge such as it's less verbose, you could then reuse the same tricks for further tests
<gerard_> vila: ah ok, so you are cleaning it up and then showing me how it should have been in the first place? ;)
<vila> gerard_: err, I meant test_update_remove_commit
<bialix> it was funny (for me) to read comments about drupal contest in hg mailing list: there seems enough people who hate bzr for some reason so they're happy to see git in winners only because it's not bzr. crazy
<vila> gerard_: hehe, not exactly, I prefer to view that as a gentle nudge in *improving* your tests :D
<gerard_> vila: yeah, the test_update_remove_commit is really verbose :)
<vila> gerard_: the way we write the tests is constantly evolving which means there are many bad examples in the existing ones and the good examples are hard to find
<gerard_> I noticed
<vila> test_update_remove_commit, especially because there is no conflicts, is a perfect candidate for using branchbuilder and can even become a whitebox test (which are far easier to debug than blackbox ones)
<vila> and also faster
<vila> hmm, good and bad are a bit rude, I meant old and new of course :D
<vila> or rather new and old or bad and good whatever...
<gerard_> blackbox tests are really easy to write though ;)
<vila> gerard_: yup, you got what you paid for :D
<gerard_> what I find interesting is that there are a lot of tests and still there are enough corner cases that are not tested
<vila> gerard_: yeah, that just means there aren't enough tests yet, welcome to the debate, it's still open :D
<vila> gerard_: one key argument is whether indirect tests (like blackbox ones) are enough to cover lower layers implementations (like your tests for wt._update_tree), that's precisely what I like to enhance with your submission :D
<vila> gerard_: that's not strictly required to land your patch though, but if we can make the tests easier to write for that method...
<gerard_> vila: easier sounds good :)
<mvo> hm, what is the right command if bzr says my format is not compatible but bzr upgrade claims my branch format is the most recent one? http://paste.ubuntu.com/373111/ has the details
<vila> mvo: actually, *you* use the most recent 2a format but the remote branch don't
<mvo> vila: can I downgrade then? I do not want to upgrade the remote branch as I don't know who else is using it and with what bzr version(s)?
<vila> mvo: you can't downgrade your branch, you had to re-create it from remote, they use different models :-/
<vila> mvo: do you have a lot of commits there /
<vila> mvo: do you have a lot of commits there ?
<vila> mvo: and how did you end up there ?
<mvo> vila: I ended up there via bzr co I think, let me check my shell history to be certain
<vila> mvo: 'bzr info -v' will tell us about a shared repository too
<mvo>     6  bzr co  lp:aptdaemon/0.2.x
<vila> mvo: doing that locally gives me a 'Packs containing knits without subtree support' repo, not a 2a one
<mvo> http://paste.ubuntu.com/373125/ <- that is the info -v output
<mvo> bzr --version
<mvo> Bazaar (bzr) 2.0.3
<vila> mvo: did you 'bzr upgrade' when you wanted 'bzr update' ?
<vila> mvo: try doing 'bzr co lp:aptdaemon/0.2.x' again and you should get a different 'bzr info -v' output
<vila> mvo: 'bzr co' in a different place !
<mvo> vila: right, sorry. the bzr co lp:aptdaemon/0.2.x one is the wrong line in my history, i was working with both branches and mixed them up. I don't have the trunk co in my shell history, so I guess the best workaround is to bzr co lp:aptdaemon/trunk again and just commit that. thanks for your help!
<vila> mvo: you're welcome, feell free to come back or file a bug if you end up with such a setup
<mvo> thanks, with the fresh checkout it works fine now
<vila> mvo: that's not supposed to occur if you do't explicitly ask for it
<vila> mvo: good
<mvo> I guess I must have used bzr upgrade at some point that I just don't remember :(
<mvo> maybe it could warn for co branches if the local and remote one become incompatible when bzr upgrade is issued?
<vila> mvo: sounds like a good idea, care to file a bug ?
<mvo> vila: thanks, I will do that (after lunch :)
<gerard_> vila: did you get around to beautifying the test yet?
<vila> gerard_: almost :D Got distracted and also ran into unsuspected complications, but the final result should be something like: http://paste.ubuntu.com/373202/
<gerard_> vila: hmm, it sure is more compact, but hard to read when you're not used to it
<vila> gerard_: which part ?
<vila> gerard_: i.e. where should I add comments to make it clearer ?
<gerard_> vila: if you haven't seen build_snapshot being used before, you have a hard time making sense of it
<vila> gerard_: ha, yes, you need to look at branchbuilder a bit, but that far easier to build graphs than with run_bzr
<vila> gerard_: but now we have the workingtree object and we can make far more assertions with it and more precise ones too
<vila> gerard_: http://paste.ubuntu.com/373215/
<vila> gerard_: http://paste.ubuntu.com/373216/ without the typo :D
<vila> gerard_: does it make sense ? Do you think you can write other tests from that ?
<gerard_> not quickly unless you provide some documentation for build_snapshot
<gerard_> and I was not really planning to write more tests...
<gerard_> that is, until I'm fixing a new bug or building a new feature
<vila> ha, I thought you were rejoicing  about TDD yesterday, I misinterpreted that a will to write more tests :D
<vila> gerard_: no problem, I'll write them
<gerard_> hehe, I like it when working on something, I don't like testing in itself
<vila> hehe, yeah, the usual "I love existing tests but... why should I add more ?" :-P
<gerard_> vila: well, I like adding tests for existing bugs
<gerard_> just writing tests out of the blue seems like a waste of time
<gerard_> I feel that's the responsibility of the guy that wrote the feature in the first place
<vila> gerard_: yeah, I agree with that, but what do you do when tests are missing then ?
<gerard_> vila: so how do you know they are missing?
<vila> gerard_: because I can't find them :D But I don't have any problem if you don't add them, they were missing before your patch, don't get me wrong !
<gerard_> vila: no, seriously, how do you know what test you can't find?
<vila> gerard_: there is no general rule, but here, I couldn't find tests for wt._update_tree() nor wt.update() only blackbox ones...
<jelmer> vila: what's the name of the 2.1 branch? I tried to submit that cherrypick during lunch but lp kept timing out :-/
<gerard_> vila: that's the reason they were so broken then
<vila> gerard_: which ones ?
<gerard_> _update_tree() mostly
<vila> jelmer: lp:bzr/2.1 ?
<gerard_> that -r feature was seriously not working correctly, can tell that from the code
<vila> oh, you mean the code, I thought you were referring to the tests
<jelmer> vila: argh, way too obvious - thanks
<gerard_> vila: no, the tests were fine
<vila> gerard_: you mean you identified other bugs ?
<jelmer> vila: (I tried ~bzr/bzr/2.1 and that failed)
<vila> jelmer: that's why you couldn't find it ;D
<gerard_> vila: yeah, using -r to go to somewhere before you branched cannot have worked correctly
<vila> jelmer: pfft, so last century....
<jelmer> vila: Well, being able to look at http://code.launchpad.net/bzr would help too :-)
<vila> jelmer: lp ooopsing again ? I can read that page without problems
<jelmer> vila: I reproducibly get a timeout
<vila> gerard_: you scare me there, and reinforce my feeling that your patch do more than its tests :-/
<vila> jelmer: I can't reproduce that
<gerard_> vila: it was using graph.find_unique_lca(revision, old_tip) to find the branch point
<gerard_> but if revision is before the branch, that will just return revision
<gerard_> the whole update was horribly broken (I repeat myself here)
<gerard_> but I agree it probably needs more tests
<vila> what do you mean 'revision is before the branch' ?
<gerard_> if you branched at revision 2, and do update -r 1
<vila> gerard_: oh, and by more tests I don't mean you introduced more bugs, but adding tests when you diagnose a bug guarantees that we won't regress
<gerard_> vila: we should probably add a test that update -r will properly remove revisions
<gerard_> just like the test that checks if it removes the commit from the branch
<jelmer> vila: does http://code.lp.net/launchpad work for you ?
<vila> redirected to http://www.ndparking.com/lp.net
<vila> https://code.edge.launchpad.net/launchpad works fine
<vila> jelmer: and http redirects to https
<vila> jam: can I land https://code.edge.launchpad.net/~jelmer/bzr/2.1-fix-foreignrev/+merge/19008 into 2.1 ?
<jelmer> vila: please do
<gerard_> vila: :)
<vila> gerard_: congratulations, your patch is landing :D
<vila> jelmer: hello acting RM :D
<jam> vila: sure
<bialix> does configuration of ML has changed recently/
<bialix> ?
 * bialix feels blacklisyted
<gerard_> vila: thx
<vila> bialix: not that I know of. Why the feeling ?
<vila> jelmer: pqm'ed
<bialix> I can't post via gmane, 3 mails sent today, none appears
<bialix> (maybe I've reached my limit of ... something)
<vila> bialix: weird
<bialix> posting to other ML via gmane was success
<jelmer> vila, thanks!
<bialix> indeed, weird
<bialix> abentley: unshelve with editor works very nice, thanks!
<abentley> bialix, you're welcome.
<bialix> :-)
<bialix> abentley: one minor UI thing: if I've invoked editor to work with several changes in one file then it invoked only once, that's ok; but final confirmation slightly misleading: "Shelve 2 changes?" -- and I think: "strange, I've edited the file only once".
<abentley> bialix, I believe that means "two lines changed".
<bialix> it's not very obvious
<bialix> usually it the count of hunks
<bialix> abentley: maybe "Shelve selected changes" would be more neutral
<abentley> bialix, that could make sense.
<bialix> abentley: also, if I've invoked "shelve --destroy" it will be nice to see more strong confirmation question: "Destroy selected changes?". but all this UI things, maybe I'm wrong
<abentley> bialix, yes, there's always tension between providing a consistent UI and a specific UI.
<bialix> perhaps I need dump this questions as bug report?
<abentley> bialix, sure.  They're good questions, and I'm not sure what the right answers are.
<bialix> ok
<maxb> abentley: Hello. For bzrtools, do you like people to use the "Resubmit" button on MPs accepting that it disturbs the comment train, or to just comment and ping you to request re-review?   (https://code.edge.launchpad.net/~maxb/bzrtools/skip-import-.bzr in my case)
<abentley> maxb, the latter.
<maxb> do you consider yourself pung, or would you like an email? :-)
<abentley> maxb, let's say I'm pung.
<bialix> abentley: done: https://bugs.launchpad.net/bzr/+bug/519919
<ubottu> Ubuntu bug 519919 in bzr "shelve UI messages: is it possible to improve them?" [Undecided,New]
<gerard_> vila: I guess the fix will not get into 2.1?
<gerard_> or will it?
<vila> gerard_: I don't think so, 2.1.0final is around the corner
<Noldorin> hi
<Noldorin> how can i ignore all files under a certain folder in .bzrignore?
<jelmer> Noldorin: Add 'foldername/*' to .bzrignore
<Noldorin> jelmer, yeah, that doesn't work for some reason
<jelmer> Noldorin: is the directory itself versioned?
<Noldorin> yeah
<Noldorin> if i have just '*.xap' it works
<Noldorin> but if i have 'ClientBin/*.xap', no luck
<Noldorin> jelmer, ?>
<gerard_> Noldorin: how about just "ClientBin"?
<Noldorin> gerard_, i need to actually include the folder in the repo, strangely enough, but none of the contents
 * gerard_ wonders what the use of having an empty directory underversion control is
<Noldorin> gerard_, it's a quirk of Visual Studio. it needs the folder to be there
<gerard_> Noldorin: create it in a pre-build action?
<Noldorin> gerard_, yeah, that just crossed my mind heh.
<jelmer> Noldorin: no idea, sorry
<Noldorin> no prob
<Noldorin> got it sorted now. thanks guys
<Noldorin> jelmer, oh btw. do you remember some time ago when we were looking into hacking the bzr-git/dulwich source to investigate the problem with pushing to git-hub?
<Noldorin> i was getting somewhere actually
<Noldorin> wondered if you had a few mins to continue with that
<jelmer> Noldorin, sure
<Noldorin> jelmer, i can't remember exactly where we were, but i remember confirming the path was correct
 * bialix waves at GaryvdM
<bialix> vila, jam: is it possible that posts from gmane blacklisted?
<jam> bialix: I suppose it is possible, but I wouldn't think so
<Noldorin> jelmer, is it worth upgrading from 0.4.2 to 0.4.3 for a start?
<bialix> it seems my usual mail marked as spammer or something similar (given the answer about waiting approval I've got recently)
<bialix> jam: http://pastebin.com/d7df6fa4b
<bialix> jam: who can help me in such situation?
<bialix> it seems some software on mailman server was upgraded today?
<GaryvdM> Hi bialix
<GaryvdM> Hi all
<bialix> Hi Gary
<vila> hey GaryvdM !
 * bialix feels really blacklisted and with tag "spammer" on the back goes away in sadness: goodbye cruel world!
<vila> bialix: could it be that your From header has changed ?
<bialix> vila: I'm even don't understand what you're say right now.
<bialix> I think I have not changed anything
<bialix> my "From:" seems the same as yesterday, just my name and surname
<vila> mails have headers and a body, the headers are (roughly) lines of the form '<header_name>: value'
<bialix> yes, yes, vila it was silly joke
<vila> ha :D
<bialix> but I really have no idea how to screw this in Thunderbird
<chx> hi. in the "which VCS to pick" http://groups.drupal.org/node/48818?page=1#comment-131203 we have a user who tried bzr on mac with not much success. can someone people help me with a nice reply?
<bialix> chx: install bzr from installer is good answer?
<bialix> there is only small issue with Qt
<chx> bialix: i do not have OS X.
<bialix> another silly joke
<bialix> heh, I really need head to home
<vila> chx: there is an OSX package for bzr, I don't know who is maintaining the macports one
 * bialix waves bye all
<chx> vila: Next try was installing the binaries for OS/X 10.6 from Canonical's website after cleaning out the Macports install.
<chx> vila: it seems he tried.
<vila> what's doxxx nick here ?
<vila> BasicOSX: do you use the mac installer ?
<GaryvdM> chx: Difficult to tell what went wrong with the installer.
<vila> verterok: do you use the mac installer ?
<GaryvdM> chx: Critical point: "Trying "bzr explore" from the command line in a bzr-repository failed miserably with ever more error messages piling up on my screen."
<vila> GaryvdM:
<GaryvdM> I installed bzr on a client
<GaryvdM> I installed bzr on a client's mac the other day with no major issues.
<GaryvdM> using the installer
<vila> GaryvdM: and using bzr-explorer ?
<RenatoSilva> verterok: hi
<verterok> vila: hi, it's been a while since I booted into OS X :/
<verterok> RenatoSilva: hi
<verterok> vila: so, the answer is: not recently :)
<RenatoSilva> verterok: did you remember if you have already added an encoding param in bzr-xmloutput?
<jam> bigjools: I just sent it through
<chx> GaryvdM: i do not have more info than this
<RenatoSilva> verterok: because I remember something like this...
<verterok> RenatoSilva: I didn't
<jam> sorry, meant to say 'bialix'
<bigjools> easy mistake :)
<chx> GaryvdM: but someone chiming in from the bzr community would be nice to counter this bad experience (which obviously should not affect the choice but it will)
<jelmer> Noldorin, yeah, upgrading is definitely useful
<RenatoSilva> verterok: there's already branch for that?
<jelmer> Noldorin, actually, I was assuming you were using trunk...
<GaryvdM> vila: Yes, Bzr explorer, There is no shortcut created, but I could run it fine from the command line
<verterok> RenatoSilva: No, there is a branch with a --encoding option for the xmlrpc-service, but that's not what we talked yesterday ;)
<RenatoSilva> verterok: oh so it's the xml rpc, ok
<GaryvdM> chx: He maybe did not install the qt binaries, which has to be done manualy
<chx> GaryvdM: maybe the installer should warn ?
<GaryvdM> chx: yes.
<GaryvdM> I'll reply.
<vila> hmm, the coyote is efficient...
<chx> GaryvdM: thanks!
<Noldorin> jelmer, heh, ok. will do so now
<Noldorin> jelmer, getting a horrible error now :S
<Noldorin> jelmer, never mind, that disappeared
<Noldorin> jelmer, anyway, all upgraded now. how to proceed?
<jelmer> Noldorin: are you running bzr-git trunk?
<Noldorin> jelmer, 0.43 now
<SamB_XP> what, he does releases of tht?
<Noldorin> jelmer, upgrade to trunk?
<jelmer> Noldorin, please do
<Noldorin> jelmer, ok, done now :)
<Noldorin> jelmer, same error, of course
<Noldorin> but anyway...
<Noldorin> which file should we start off messing with?
<jelmer> Noldorin, I'm adding some debug code
<Noldorin> jelmer, ah, great
<jelmer> Noldorin, done
<jelmer> please pull again
<jelmer> please try again and use -Dtransport
<jelmer> this'll write extra info to ~/.bzr.log
<Noldorin> ok
<jelmer> I'll be back in ~30 minutes
<Noldorin> jelmer, ok
<BasicOSX> vila:  no, I run bzr.dev
<BasicOSX> (sorry for the late response)
<vila> BasicOSX: better late than never :D And you use bzr-explorer or not ?
<BasicOSX> not ... my roots are unix and most of my work is done on linux
<BasicOSX> CLI server stuff
<BasicOSX> Just taking poll? or looking for more feedback?
<vila> BasicOSX: trying to update my mental Who's Who :D
<BasicOSX> Then you'll need some mental floss after talking to me :-P
<vila> jam: wt.list_files() raising OSError when trying to lstat  a non-normalized Unicode filename... rings a bell ?
<vila> BasicOSX: Ok, I stop right now then :D
<GaryvdM> Bla, me too
<GaryvdM> groups.drupal.org says "Your submission has triggered the spam filter and will not be accepted."
<fullermd> Who's who?  Me's me.
<Noldorin> jelmer, doesn't print anything in dtransport now :S
<jelmer> Noldorin, re
<jelmer> Noldorin, did you try adding -Dtransport on the commandline ?
<jelmer> Noldorin, and nothing shows up in .bzr.log ?
<vila> jam: for WorkingTreeFormat2 that is
<GaryvdM> Hmm. For bzr 2.1, I thought that python-testtools was only a requirement if you are going to run the test suit.
<GaryvdM> Some commands (like update) fail if you don't have it.
<GaryvdM> Was this intended?
<GaryvdM> vila ^
<vila> GaryvdM: If sftp is involved you're running into bug #516183
<ubottu> Launchpad bug 516183 in bzr "sftp transport module requires testtools" [Critical,Fix released] https://launchpad.net/bugs/516183
<vila> GaryvdM: the fix should be included in 2.1.0final but is still present in 2.1.0rc2
<fullermd> Heh.  It's funny how two wrongs make a right.
<jelmer> Noldorin, ?
<fullermd> I never had a chance to run into that bug, since I yanked paramiko off my systems after the pycrypto upgrade left it bleating all the time   :p
<GaryvdM> vila: Ok I was using sftp. So I'm not going to add testtools as a dependency to the debs in the ppa.
<vila> jam: I'm banging my head on the failing tests for https://code.edge.launchpad.net/~vila/bzr/322767-dont-add-conflict-related-files/+merge/18858, if you could have a look during my night, I'm sure I will sleep better ;) I can't figure why using wt.list_files() *during* smart_add fails while using it after succeeds (or something like that)
<vila> GaryvdM: testtools should be a Build Dep for bzr
<jam> vila: ... WT.list_files() often fails because we get the offending file back in plain str form, and stuff like 'list.sort()' raises a UnicodeDecodeError trying to compare that string to others.
<jam> but sure, I'll look at your work
<vila> GaryvdM: i.e. something you need to build (ok, test) but not when *using* it
<GaryvdM> vila: Ah yes.
<vila> jam: here we fail in a call to file_kind() which calls os.lstat AFAICT with the normalized form when the not normalized form has been used on disk
<jam> vila: well, I'm not going to try to solve Mac issues :)
<jam> at least, not yet
<vila> not on mac ! It's on karmix/etx3
<vila> yeah karmic even
<jam> hmm.... maybe we failed to remove some of the normalization code
<vila> anyway, the mp gives a subset that includes the failing tests (they succeed without my patch ...)
 * vila is off
<GaryvdM> Is there something similar to a bzr checkout (aka bound branch) in git?
<jam> GaryvdM: past experience seems to indicate no, but I haven't checked again recently
<GaryvdM> jam: Ok, I'm going to state that in a forum.
<jam> I believe they have 'stacking', but only for local (I don't believe you can stack across a network boundary)
<jam> there are also some strange things you can do with env vars
<jam> vila: in case you are still here, what is failing is that calling 'conflicts' to list what files are conflicted has to walk the whole filesystem because it has to search for .BASE, etc files.
<jam> You change causes us to invoke '.conflicts' in a case where we didn't before
<jam> So I think it was already broken, we just didn't know it, because we weren't calling it in those circumstances
<jam> I would consider adding a KnownFailure for WTF2 in that case
<jam> not worth the effort to fix, IMO
<jam> well, I should say, fixing list_files() is worthwhile at some point, but not worth blocking your patch for
<Noldorin> jelmer, sorry, thought you had left.
<Noldorin> jelmer, well, let me paste you the output
<Noldorin> http://pastebin.com/m62241839
<Noldorin> jelmer, that's all i get
<jelmer> re
<jelmer> Noldorin, did you pull from trunk after I added that debug output?"
<Noldorin> jelmer, yep
<Noldorin> jelmer, just double check - it is up to date. what were you expecting?
<vila> jam: passing rapidly post-lunch, ha, that makes sense and kind-of imply that Unicode is badly supported for WorkingTreeFormat2. So accepting my patch means we won't support adding files for that format, but given the big red flashing warning to upgrade from that format, I think that's acceptable.
<jelmer> Noldorin, what revno of bzr-git do you have?
<vila> jam: can I consider adding the expected failures  as a BB:tweak ?
<Noldorin> jelmer, r708
<jelmer> Noldorin, are you sure that's the version actually being loaded? using -Dtransport I get more debug output in ~/.bzr.log..
<Noldorin> judging by the log, it is
<Noldorin> one sec
<jam> vila: yes
<vila> jam: thanks, I'll sleep better :D
<dahoste> hey #bzr.
<Noldorin> jelmer, how can i check?
<jelmer> Noldorin, "bzr plugins -v"
<GaryvdM> jelmer: I want to update bzr-svn, and bzr-rebase and add bzr-git to the beta ppa. I'm not sure which is the best way to go about this.
<GaryvdM> jelmer: E.g. One of the questions I have is for bzr-svn, should I start with lp:~bzr/bzr-svn/<ubuntu- ver>-ppa or lp:~debian-bzr-svn/bzr-svn/unstable
<dahoste> Question: I'm trying to get some shared-repo branches exposed via wsgi+apache.  Works fine for a non-shared repo branch, but fails for a shared repo.  I get: " An attempt to access a url outside the server jail was made".   Something to do with how the transport is created.. but not sure how to tweak it to make it work.
<dahoste> My little wsgi handler is using the make_app() function from bzrlib.transport.http.wsgi.
<Noldorin> jelmer, erm, how do i rebuild?
<Noldorin> i think i need to do that now
<Peng> dahoste: Upgrade to bzr 2.1.0rc1.
<jelmer> GaryvdM: the debian packages are on http://bzr.debian.org/pkg-bazaar/bzr-X/unstable
<Noldorin> oh, never mind
<Noldorin> need to add back in the hack
<Noldorin> one sec
<jelmer> Noldorin: there's nothing to rebuild, it's just python files
<jelmer> GaryvdM: the packages on launchpad are outdated (mirrors/imports don't work for packaging branches yet)
<GaryvdM> jelmer: Should I base the ppa packages on http://bzr.debian.org/pkg-bazaar/bzr-X/unstable?
<dahoste> Peng, .... ok.  Was this a known issue, then, that is definitely fixed?  I'm not averse to implementing a more substantial wsgi handler, if that's all it takes.
<jelmer> GaryvdM: Yeah
<Noldorin> ok, seems i've got to update dulwich too...
<GaryvdM> jelmer: cool
<jelmer> Noldorin: you shouldn't have to, bzr-git trunk and bzr-git 0.4.3 require the same dulwich
<Noldorin> jelmer, i haven't updated since 0.4.2
<Noldorin> so yes i think i need to
<jelmer> Noldorin, but then cloning wouldn't have worked earlier either
<Noldorin> ok, working now
<Noldorin> hmm
<Peng> dahoste: Yes, it's been fixed. Bug #348308.
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Fix released] https://launchpad.net/bugs/348308
<Peng> dahoste: If you don't want to upgrade bzr, you can put a simple monkeypatch in your WSGI script, but upgrading would be better...
<Noldorin> jelmer, http://pastebin.com/m5950138d
<Noldorin> seems to be including your debug info now :)
<Peng> dahoste: My favorite version of the monkeypatch is http://paste.pocoo.org/show/176320/, FYI.
<dahoste> Peng, hmm... I apologize for not seeing that.  I did search the bugs.   Weird - searching on either 'wsgi' or 'jail' doesn't bring up 348308.
<Noldorin> jelmer, i guess the problem is where the ssh key is transported over the git connection?
<Peng> dahoste: Don't sweat it, I never find anything searching Launchpad either. I think it excludes fixed bugs by default?
<dahoste> Peng, cool, that should be enough to get me going.  I'm not averse to upgrading, but I'm using gentoo and avoid stepping outside of portage unless it's a security issue or something.  They've still got 2.1.0-beta4 masked.  I'll monkeypatch in the interim.
<Peng> dahoste: OK. :)
<dahoste> Peng, thanks for the quick info.   irc ftw, as usual.
<Peng> dahoste: I used to have that bug number memorized, though I've started to forget it since it was fixed, since I run bzr.dev. :P
<Noldorin> jelmer, any ideas?
<dahoste> Peng, I'll admit I was surprised that this didn't 'just work'... figured everyone was running their repos through wsgi, and it would be well-paved for all the common scenarios.
<jelmer> Noldorin: as far as I can tell the ssh bit works ok
<GaryvdM> Interesting: http://upsilon.cc/~zack/stuff/img/vcstype-year.png (Graph of Debian VCS usage)
<Peng> dahoste: For some reason, very few people use the WSGI server.
<Peng> dahoste: If they want good performance, they just use bzr+ssh.
<dahoste> Peng, I almost went that route.. but wanted to avoid dealing with full shell accounts.  Though I think there's a way to use a single account, not sure.  Anyway, with wsgi, I can just defer to apache to auth through ldap for write access.   I'm prepping to migrate a ton of svn repos over to bzr, and wanted to maintain as much of the auth environment as possible.
<Peng> dahoste: Ooh, you're going to do HTTP writing too? That's probably even less common.
<dahoste> Peng, yup.   fingers crossed.  :)
<Noldorin> jelmer, hmm ok. so what now then?
<GaryvdM> jelmer: When I'm done, should I push --overwrite to lp:~bzr/bzr-svn/<ubuntu-ver>-ppa?
<jelmer> can you try adding self._path = self._path.strip("/") after the call to trace ?
<jelmer> GaryvdM, please do
<GaryvdM> Ok
<Noldorin> jelmer, strangest thing is that ssh auth works perfectly for bzr/launchpad....
<GaryvdM> ah lp:~bzr/bzr-svn/<ubuntu-ver>-ppa has allready been merged with  http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable/ -- Cool
<jelmer> Noldorin, any luck?
<Noldorin> jelmer, see my previous message
<jelmer> Noldorin, <jelmer> can you try adding self._path = self._path.strip("/") after the call to trace ?
<jelmer> Noldorin: any luck?
<jelmer> Noldorin, still there?
<Noldorin> jelmer, seems we keep missing each other.
<Noldorin> jelmer, oh, i thought that comment was to someone else, sorry.
<jelmer> Noldorin: can you pull from current trunk
<Noldorin> jelmer, what file/position?
<jelmer> Noldorin, and try again
<Noldorin> ok
<Noldorin> coo
<Noldorin> jelmer,
<Noldorin> http://pastebin.com/m1a840bb5
<Noldorin> that's running dpush -Dtransport on the latest revision
<Noldorin> jelmer, doesn't look any different
<Noldorin> hmm
 * Noldorin pings jelmer 
<jelmer> Noldorin, sorry, I'm out of ideas
<Noldorin> hmm
<Noldorin> jelmer, what did you expect to see in that trace?
<poolie> good morning
<GaryvdM> Hi poolie
<Noldorin> jelmer, (if you were looking for anything at all)
<poolie> hello gary
<Peng> mwhudson: BTW, looks like my mirrored branches are happy again...
<mwhudson> Peng: oh good
<Peng> I guess the gremlins have been placated?
<GaryvdM> There were lots of critical bugs in 2.1.0rc2 (that have been fixed). I think we should maybe do a rc2
<GaryvdM> *I think we should maybe do a rc3
<GaryvdM> Bug #515597 makes rc2 unusable
<ubottu> Launchpad bug 515597 in bzr "TypeError: merge_text() takes exactly 2 arguments (3 given)" [Critical,Fix released] https://launchpad.net/bugs/515597
 * mtaylor made bzr  crash...
<mtaylor> bzr revision-info lp:~mordred/+junk/testme
<mtaylor> gives:
<mtaylor> bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction on LockableFiles(lock, file:///home/mordred/src/testme/.bzr/branch/)
<mwhudson> revision-info is pretty weird about its arguments
<mwhudson> mtaylor: i think what that command tries to do is number the tip of lp:~mordred/+junk/testme in the branch in your cwd
<mtaylor> mwhudson: lovely
<mwhudson> or something like that
<mwhudson> yeah
<mtaylor> mwhudson: is there a command I'm missing then that would give me the revision-id of the tip of the branch specified?
<mwhudson> mtaylor: bzr revision-info -d lp:~mordred/+junk/testme
<mwhudson> (i added the -d option in an extreme rage a while ago)
<mtaylor> mwhudson: what does -d do?
<mtaylor> awesome. rage is a good source of commands
<mwhudson> mtaylor:
<mwhudson>   -d ARG, --directory=ARG
<mwhudson>                         Branch to examine, rather than the one containing the
<mwhudson>                         working directory.
<mtaylor> ah. heh
<GaryvdM> jelmer: I've gotten (and upgraded) lp:~bzr/bzr-svn/karmic-ppa/ and run merge http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable/
<GaryvdM> jelmer: I'm not sure how to handel the merging of changelog
<GaryvdM> There are some entries from debian/unstable that have been added
<GaryvdM> jelmer: Do I keep these?
<GaryvdM> jelmer: I think that I'm going to revert merges changes to debian/changelog, and create my entry (with version number for the ppa)
<spiv> Good morning.
<GaryvdM> How do I get bzr builddeb to not download the .orig.tar.gz with uscan, but to rather use the code from the branch?
<james_w> GaryvdM: you need to use "merge-upstream" to merge the code from the branch, and pass the tarball if there is one corresponding to the release you are using
 * GaryvdM is confused
<GaryvdM> ah merge-upstream is a builddeb command
<AfC> Given an arbitrary Debian package in Ubuntu, what's the bzr command to get a Bazaar branch of its sources? [is there one?]
<james_w> bzr branch lp:ubuntu/<package>
<GaryvdM> james_w: I cant get merge-upstream to work, but I think I have don what it does manually, so I'm not to worried.
<igc> hi
<igc> hi poolie, jam, garyvdm, james_w
<GaryvdM> james_w: My org question is theoretical, because the .orig.tar.gz should be the same as the contents of the branch, but what if I have modified the code in the branch so that it differs from the .orig.tar.gz?
<GaryvdM> Hi igc!
<james_w> hi igc
<james_w> GaryvdM: the way that .deb repositories work mean that you have to have a byte-for-byte identical .orig.tar.gz for versions that share the same upstream version
#bzr 2010-02-11
<james_w> exporting from the content of the branch doesn't provide you that, so merge-upstream uses pristine-tar to make it possible
<GaryvdM> james_w: Oh - ok
<AfC> Weird. bzr branch lp:ubuntu/<package> downloads *tarballs*?
<AfC> They're versioned! What the hell?
<GaryvdM> james_w: Thanks for the help.
<GaryvdM> beta-ppa now building new bzr-svn
<AfC> james_w: so, er, I must admit I'm surprised to see you tracking binary tarballs with bazaar, instead of sources. Doesn't that defeat the whole point?
<james_w> AfC: we aren't
<AfC> james_w: of branches to be shared between distros?
<james_w> you may have picked a package where the packager decided that tarballs is what they wish to put in their source packages
<AfC> james_w: um
<AfC> james_w: so it's freetype [->libfreetype6]
<AfC> james_w: and it says
<AfC> Committer: Bazaar Package Importer <james.westby@ubuntu.com>
<AfC> each time it merges a series of tarballs, and then replaces them
<AfC> That you?
<james_w> yes, so you chose one such package
<james_w> it's a script run by me
<AfC> I guess I don't understand why there are any such packages.
<spiv> Because we didn't invent packaging branches years ago ;)
<AfC> I really thought I'd be getting a branch full of sources, not full of tarballs.
<AfC> spiv: right, but someone did invent the idea of using Bazaar to manipulate Debian packages in the not to recent past. You remember, when Bazaar was started, right?
<james_w> O HAI, I see you have packaging that is designed to work with tarballs, I'm going to automatically rewrite it to work with unpacked tarballs so that you get a nice surprise next time you look at it!
<AfC> spiv: My understanding [clearly wrong] was that the whole point was to have a branch of upstream that you would then apply revisions to to make a debian package.
<spiv> AfC: If I'm understanding correctly, in this case the 'source' package contains a tarball.  The bzr import of that is just reflecting that reality.
<AfC> spiv: ah
<AfC> spiv: I see
<AfC> spiv, james_w: I didn't know such things existed, actually.
<AfC> I'm from the Gentoo world, where the first thing that happens with a released tarball is that it is unpacked, so that people can then diff and patch against it.
<RAOF> It's probably because they wanted to merge the three separate .tar.bz2's into a single source package.
<RAOF> That would now be supported with the new 3.0 deb-src format, but that's very new.
<AfC> Anyway, I guess this isn't what I was hoping for. My understanding from years ago was that we would have bzr revisions showing the packaging changes to a baseline of (upstream's) sources [which would be either upstream vcs or upstream tarball unpacked[
<GaryvdM> bla: Rejected: bzr-svn_1.0.2-2~bazaar1~karmic1.dsc: format '3.0 (quilt)' is not permitted in karmic.
<poolie> hello igc
<spiv> AfC: and packages like this are why we didn't already have those bzr revisions years ago ;)
<james_w> AfC: you do for the majority of package
<AfC> So can you suggest a package that does behave properly (so I can compare, and not go away with the wrong idea)?
<james_w> bzr?
<GaryvdM> james_w: There must be non bzr related packages for which we have a  branch that shares the history with upstream?
<james_w> there aren't many at the moment
<james_w> we are focusing on getting every package available in some form first, then looking to improve the history of ones where we can
<GaryvdM> james_w: lp:ubuntu/qbzr dose not share its history. Can I fix that?
<james_w> GaryvdM: yes and no
<james_w> it's straightforward to join the history, but the file-ids also differ, so when you do everything in the tree conflicts
<james_w> there isn't really a neat way to deal with that right now
<GaryvdM> james_w: So I can't give launchpad an instruction to can that branch, and start fresh using file
<james_w> not easily
<GaryvdM> ... file-ids from branch x
<GaryvdM> Will that become easier in the future?
<james_w> yes
<GaryvdM> james_w: :-)
<mkanat> I ran into that problem a few times in the past, too.
<mkanat> And yeah, hopefully it will become easy (read: possible for mere mortals) in the future. :-)
<poolie> spiv, is the news auto-merger installed in pqm now?
<jelmer> GaryvdM, re
<poolie> hi jelmer
<GaryvdM> Hi jelmer.
<jelmer> GaryvdM, you need a new entry for the ppa anyway because of the version string
<jelmer> GaryvdM, but generally you would keep the debian entries as well
<jelmer> hi poolie
<jelmer> poolie, does the pqm run 2.1 yet?
<spiv> poolie: I don't know, but it would be nice to have :)
<GaryvdM> jelmer: Oh ok - need to re do them because I messed up the debian/control files. :-(
<spiv> poolie: it would require bzr 2.1 and a small config tweak in bazaar.conf I guess.
<spiv> poolie: do you know if someone was already looking into arranging that, or should I file an RT?
<poolie> i don't know that anyone else is
<poolie> it might be nice
<poolie> the upgrade will probably be easier when 2.1 is packaged and available
<poolie> at least in lucid
<jam> morning poolie and spiv
<poolie> hello jam, and no, it's just after midday
<jam> I guess that's what I get for coming back late
<jam> anyway, just stopping by to say hello, I'll probably be back with the family in a couple mins
<poolie> k
<poolie> thanks for the reviews
<spiv> jam: early afternoon :)
<spiv> Ok, I'll wait until there's a 2.1 package then.
<spiv> Drat, I sent a branch to PQM with the commit message for a different branch (both approved for 2.1, thankfully).
<spiv> I'm definitely looking forward to a command that take an lp merge proposal and send it to PQM with the source branch, target branch and commit message in that proposal.
<Kilroo> I'm mostly looking forward to the fix for bug 109114.
<ubottu> Launchpad bug 109114 in bzr "[master] bzr holds whole files in memory; raises MemoryError on large files" [Medium,Triaged] https://launchpad.net/bugs/109114
<poolie> spiv, you can ask spm to kill the job
<spiv> Hmm, that's a thought
<spiv> spm: ping?  Would you mind killing my "now playing" job on bzr's pqm?
<poolie> good thing the tests aren't too fast ;)
<GaryvdM> Night all
<lifeless> Kilroo: noone is working on that at the moment.
<Kilroo> I had gathered that.
<Kilroo> Fact remains, it's the only thing not directly concerning either bzr-eclipse or bzr-svn that is having a negative effect on me. And the problems with them I can work around.
<lifeless> Kilroo: do you have multi-GB files?
<Kilroo> Yes.
<Kilroo> Not by choice, but until they stop piling projects on me long enough for me to propose a solid plan for moving to a more reasonable versioning plan, I have to work with the subversion repositories we have.
<Kilroo> Two of those I can't pull the revision where they added the whole blasted main site at once. And one that otherwise ought to be pretty clean I can't work with because my supervisor had to get a file to an accessible location while he was at a convention and the only way he could think of to do it at the time was to commit a 1.5gb zip archive to a subversion repository.
<Kilroo> I'm not even sure exactly how he accomplished it or why.
<Kilroo> I'm actually kind of hoping that the hassle of purging it from the history of the repository helps my case for redoing our system.
<lifeless> :)
<RenatoSilva> Is there how to merge only certain revisions?
<RAOF> You mean to cherry pick?  You pass -rfrom..to
<RAOF> This won't keep the log history though.
<RenatoSilva> what does it mean keep log history? that's the intention
<RAOF> It squashes down to a single commit, which contains the diff.
<RenatoSilva> I have uncommitted a few revisions, so the old history in the feature branch became outdated and pointless
<RenatoSilva> single commit? but I said certain revision*S*
 * RenatoSilva is using rebase
<RAOF> Yes.  It'll take the changes from certain revisions and apply them as a diff.
<RAOF> As far as I'm aware there's no way to (easily) take a sequence of commits for which the first commit does not have its parent in the branch and merge them as a series of commits.
<RenatoSilva>  You pass -rfrom..to to what?
<RenatoSilva> bzr merge -r -1 didn't work, the other revs are there
<spiv> RenatoSilva: -rSTART_REV..END_REV
<spiv> RenatoSilva: it's a range
<lifeless> jelmer: don't suppose you want to package a newer bzr-search? we're getting  lots of dups for fixed bugs
<RenatoSilva> spiv: ah ok, but bzr merge d -r -2..-1 gives no pending merge in bzr qlog
<RenatoSilva> spiv: maybe the conflicts? lms
<spiv> RenatoSilva: if you're trying to merge the changes of just one revision, try -c REV rather than -r.
<spiv> RenatoSilva: just because it's more convenient
<spiv> RenatoSilva: but if merge of -2..-1 gives "Nothing to do.", then I that revision is already part of the branch
<RenatoSilva> spiv: ok, but will it also --forget-merges automatically like in -r?
 * RenatoSilva trying
<spiv> RenatoSilva: yes
<lifeless> RenatoSilva: if -2 isn't already merged, in your example, then there won't be pending merges.
<lifeless> because you are doing a cherrypick, it lives outside the merge graph.
<RenatoSilva> cherrypick? anyway, I have checked, it does forget the merge in both cases, this seems fine as I would --forget them anyway
 * RenatoSilva realizes how uncommit may be annoying sometimes
<spiv> "cherrypick" basically means "take just part of a branch's history, not the full branch"
<spiv> i.e. what you're doing here.
<RenatoSilva> so, I will make a hack (fb = feature branch): cp -r trunk fb_new; cd fb_new; bzr merge ../fb -c -1; bzr commit -m "Same message."; rm -r ../fb
 * igc lunch
<RenatoSilva> it's like a rebase :)
<spiv> RenatoSilva: in the sense that the original history is generally no longer part of the new history, yes.
<RenatoSilva> spiv: did I told you about the bzr search bug? I realized that it's all about inspecting bzr log -p, so I wrote a tool for that. I'm pretty satisfied.
<RenatoSilva> spiv: usage is something like bzr log -p | greprev why_this_method_was_deleted, I used it today, very nice
<RenatoSilva> * helpful
<lifeless> RenatoSilva: about bzr-search
<lifeless> RenatoSilva: it doesn't do log -p internally, it prebuilds indices to answer questions much faster than log -p
<lifeless> RenatoSilva: so I'm glad you're happy, and the bug is there in case someone chooses to implement it.
<RenatoSilva> lifeless: I understand that bzr-search may be much more faster specially for big trees, but I'm pretty satisfied, specially because I can use a free regex, and because I get the revnos not ids
<RenatoSilva> lifeless: I think implementing that bug would be just about replacing non-friendly the rev ids with the numbers.
<lifeless> RenatoSilva: well the unique thing I got out of your comments was seeing a diff
<RenatoSilva> (of course there are the search string issue, but that's registered at another bug as you have reported there) (I just did not get the new title 'show hits as diffs')
<lifeless> I'm fairly sure there is a bug, or TODO at least, to show numbers (but that is also pending a revno oracle, something bzr branches need in general)
<lifeless> RenatoSilva: your script shows a diff doesn't it ?
<RenatoSilva> lifeless: it gives you a clue. It shows the line of the rev's diff containing a match, and the file name, and the rev number. With this last, you bzr qlog and look at that rev to get more details (specially, read the commit comment)
<RenatoSilva> revno oracle? you mean you cant just pick up the revno? ok
<lifeless> thats correct, calculating revnos means accessing all the information for the branch, and is often quite slow
<spiv> RenatoSilva: ah cool, I'm glad that you found a way to do what you wanted :)
<RenatoSilva> all info == loop the commits? oO
<lifeless> RenatoSilva: I'm fine with showing a diff, I'm just noting that bzr-search does not show a diff, and you want it to.
<RenatoSilva> I thought revnos were stored as commit metadata, along with the long ids
<lifeless> nope
<lifeless> they are dynamic and can potentially change completely
<RenatoSilva> lifeless: iirc it does the same, it shows the line of the diff containing the match, the problem is that the output is a bit weird (just a matter of formatting), and mainly, that we don't have the revnos
<lifeless> e.g. 'uncommit', 'push --overwrite' do this
<lifeless> RenatoSilva: no, bzr-search does *not* show a diff
<RenatoSilva> lifeless: ah ok I didn't know that
<RenatoSilva> lifeless: not the entire diff
<lifeless> not a diff at all, it doesn't access the old version of the file.
<RenatoSilva> lifeless: weird, I was pretty sure I got some matches like +  sadasdaad  match
<RenatoSilva> lifeless: I linked an example in the bug, let me check
<lifeless> it shows the first line in the new version of the file that matches any search term searched for
<RenatoSilva> http://pastie.org/815629.txt
<lifeless> yes, not diffs
<lifeless> just lines extracted from the files
<RenatoSilva> they're all from current revision for all files?
<RenatoSilva> or from old revisions? maybe I misunderstood this comment? "bzr search searches the diff between revisions already."
<lifeless> what it searches and what it shows are separate
<lifeless> it builds an index from the file diffs. the index points at (revision, file)
<lifeless> it shows by reading in (revision, file) and looking in that for what you searched for
<RenatoSilva> hence it shows matches in old file versions?
<lifeless> yes
<lifeless> the revision is printed at the left of the output
<spiv> lifeless: there's possibly a valid bug here along the lines of "document what bzr-search indexes in a way that end users will comprehend"?
<lifeless> spiv: perhaps. Or make it more powerful so it doesn't matter.
<spiv> or perhaps just s/comprehend/discover/ ;)
<spiv> lifeless: right
<spiv> lifeless: but in the meantime while it's not quite as awesome as google, document it ;P
<lifeless> spiv: I mean, this conversation is about it a) not searching via literal strings (a subset of full regex) and b) the output being fugly
<lifeless> s/conversation/bug report/
<spiv> (I'm not trying to imply anything much about the priority of documenting the status quo vs. improving it)
<spiv> FWIW, I generally consider bug reports to be conversations  :)
<lifeless> vs the conversation on IRC :)
<RenatoSilva> lifeless: well I'm very sorry but I can't really understand you pretty well. It simply seems to me that, if there was a revno rather than that rev id (and besides the output being a bit weird), it would give me the info I want. If not, then I'm sorry
<lifeless> RenatoSilva: it can currently show a line that was not altered by the commit
<RenatoSilva> lifeless: I'm jsut lost with that bug at the moment. I have no idea what 'hits as diffs' mean :(
<lifeless> it means show the results as diffs
<lifeless> not as summaries from the committed documents
<lifeless> I don't know how to phrase that differently I guess.
<lifeless> a hit is a search hit, its something returned from your search.
<lifeless> a diff is a description of a change between two things
<lifeless> bzr-search currently shows hits as summaries *of the new things*, not as *a difference between things*
<RenatoSilva> lifeless: ok just know that I'm confused, and I'll probably leave that bug, I'm sorry :(
<lifeless> I'm satisfied that I know what you want.
<lifeless> And I've described it in a way that I and other bzr-search devs will understand.
<lifeless> I think you'd need to read the code to understand whats going on ><
<RenatoSilva> lifeless: so if one wants more details in the future from the bug reporter, I'll not be there because I don't get the bug idea anymore :(
<RenatoSilva> lifeless: ok ok thanks, it's just to let you know in case if you find it weird that I unsubscribe or so
<lifeless> thats fine
<lifeless> you've communicated what you wanted well using the filter script you wrote
<RenatoSilva> ok
<RenatoSilva> thank you very much guys
<poolie> spiv is https://bugs.edge.launchpad.net/bzr/+bug/421845 really high?
<ubottu> Ubuntu bug 421845 in bzr "bzr check fails on valid stacked repository isolated from fallbacks." [Medium,Confirmed]
<poolie> actually nm, i already downgraded it
<poolie> revert that if you disagree
<spiv> poolie: hmm
<spiv> poolie: I don'
<spiv> I don't feel strongly about it, but I tend to think that bugs that stop 'bzr check' from being a reliable way to determine the health of a repo are serious.
<spiv> But at the same time, it is a bit of a niche situation.
<poolie> ok
<poolie> i'm doing a bit of a roundup of bugs with patches
<poolie> you could turn yours into a known failure
<poolie> but...
<poolie> that doesn't actually fix it
<poolie> so it's probably not worthwhile
<spiv> But it would shift it off the "bugs with patches" queue ;)
<poolie> :)
<poolie> spiv do you think the malloc patch is safe for 2.0?
<spiv> I think so, but it might be nice to give it some time in trunk first, just in case.
<poolie> ok
<poolie> there's some potential for waste in letting things age in trunk
<poolie> though i also kind of like the ieda
<poolie> idea
<poolie> jelmer: are you awake perchance?
<poolie> spiv, still here?
<vila> hi all !
<vila> wow, I was about to nudge core devs to land their approved patches and... https://code.edge.launchpad.net/bzr/+activereviews is almost empty, yeah for telepathy !
<poolie> hi vila
<poolie> yeah!
<poolie> and, i think
<poolie> less +patches bugs than when we started
<poolie> maybe no +high ones?
<vila> I haven't looked at +patches yet, but +workinprogress is reasonably short too
<poolie> those aren't real urls
<poolie> yet
<poolie> they should be
<vila> poolie: sure, but we understand each other here
<poolie> yes
<lifeless> jelmer: ping
<lifeless> poolie: actually, there is a +patches one now Ithink
<lifeless> it was announced at portland
<lifeless> maybe its only for ubuntu, in which case a nudge to Jorge might be useful
<poolie> not deployed yet i believe
<poolie> continuous deployments come on down
 * igc dinner
<poolie> k, i need to finish https://bugs.edge.launchpad.net/bzr/+bug/368931 then stop
<ubottu> Ubuntu bug 368931 in bzr "Rename may fail when file and directory have the same name differing by case" [High,In progress]
<vila> poolie, lifeless : I replied on  https://code.edge.launchpad.net/~vila/bzr/move-test-servers/+merge/18960 , we can discuss it here and now if you will
<vila> spiv, igc, jam, everybody who is interested too ^
<vila> mwhudson: ping
<poolie> vila, can you summarize where it's actually up to?
<poolie> i'm broadly + on just merging it before perfecting it
<spiv> hey vila
<vila> poolie: test servers are out of the bzrlib.transport hierarchy, tests are passing
<spiv> Does that include MemoryServer?
<vila> spiv: hey happy father ! :D
<spiv> It would be a shame to move that twice, and thus cause Launchpad to have to update their code to match twice.
<vila> spiv: yes, but not ChrootServer and PathFilteringServer which *are* used are true servers (MemoryServer isn't)
<spiv> MemoryServer is a real server.
<poolie> they do use MemoryServer
<poolie> in lib/lp/codehosting/vfs/branchfs.py
<vila> poolie: outside of tests ?
<spiv> Yes.
<vila> hmm
<poolie> it seems strange but they do call it
<poolie> vila istm that if you import transport.memory it is reasonable to get MemoryServer too
<poolie> we mostly want to avoid it for real protocols
<vila> poolie: that was the root cause of needing testools when using sftp...
<vila> let me try
<poolie> memoryserver was?
<vila> poolie: no, leaving a test server in the bzrlib.transport hierarchy
<poolie> right
<spiv> MemoryServer doesn't have much risk of depending on external dependencies.
<poolie> i think we should move that one
<poolie> right
<poolie> and also, if you are using a memorytransport you must necessarily also use an in process memory server
<vila> poolie: nice catch, let me look at the fallouts
<poolie> well it was spiv really
<poolie> i would not have guessed lp used it
<vila> spiv: nice catch to you then ;)
<vila> spiv: By the way, Marie an I noticed that your Vincent's mother is called Mary while her (Marie's) father is called Vincent, which kind of make sense since we leave roughly at the other side of the planet... but I wonder how *they* will name their children (except I think I just don't want to know, that's far too close to playing with the quantum universe equilibrium)) )) (just to be sure)
<poolie> vila, can you send a pp mail before you go?
<fullermd> Pah, lousy quantumn universe equilibrium.  What'd it ever do for me?
<vila> poolie: Some sort of summary you mean ?
<vila> poolie: or a 'I'm done, next is poolie' kind of ?
<lifeless> vila: I've made my case for names on the bug, whatever poolie goes with is pragmatically fine.
<vila> lifeless: ok
<lifeless> vila: (But I'm not convinced by .git and .ftp being siblings :))
<vila> well, I'm not convinced we need to reserve for .git until we implement it ;)
<lifeless> we have .smart.server
<bialix> heya all
<lifeless> I'd rather see .git.server
<bialix> hi lifeless
<lifeless> and similar for CVS etc, than have it adjavent to the VFS servers
<lifeless> hi bialix
<bialix> lifeless: IIUC you're admin of bzr ML
<lifeless> bialix: one of manyt
<bialix> I have problems posting to ML via gmane
<lifeless> bialix: hmm
<bialix> at least it was true yesterday
<lifeless> we're not that sort of admin really. what sort of symptoms do you see?
<lifeless> (we only have web UI clicky clicky admin access)
<bialix> yesterday my mails were not reach ML.
<poolie> vila: "I'm done, we got lots of things finished, please keep the balls in the air"
<vila> poolie: k
<bialix> okay, it seems jam fixed something yesterday when I'm whinning about this
<poolie> bialix: your mails are not in the clicky admin interface :-(
<poolie> unless they now got through
<bialix> hi poolie, vila
<poolie> vila, say something inspiring/exciting
<vila> poolie: :D
<poolie> it is really good that we're getting on top of these things :)
<vila> bialix: hello spammer
 * vila hides
<bialix> ok, today is better day, at least couple of my answers reached ML actually
<bialix> lifeless: poolie: sorry for disturb, I hope now it's sorted
<poolie> np
<poolie> let us know
<poolie> if you have troubles
<bialix> vila: :-D
<poolie> i should really go
 * bialix likes jokes of vila, no need to hide
<gerard_> hey
<vila> hi gerard_
<bialix> igc: ping?
<Tak> nice lp/bzr article on ars
<vila> Tak: url ?
<rubbs> http://arstechnica.com/business/2010/02/an-introduction-to-collaborative-development-with-launchpad.ars
<vila> hmm, fresh :D
<vila> rubbs, Tak : thanks
<rubbs> np
<rubbs> I haven't read it all, but it seems pretty good
<bialix> hi abentley, today I've encountered strange problem with shelving part of hunk with the editor
<bialix> bug https://bugs.launchpad.net/bugs/520461
<ubottu> Ubuntu bug 520461 in bzr "problem of partially shelve changes from 1 hunk with editor" [Low,Confirmed]
<bialix> abentley: am I'm doing something really wrong this is just unsupported use case?
<bialix> abentley: am I'm doing something really wrong *or* this is just unsupported use case?
<bialix> rubbs: there is qbzr! :-)
<vila> bialix: have a break, read the above url, there talking about you :D
<vila> rats, too slow
<bialix> vila: I saw the pictures
<abentley> bialix, I don't understand.
<jam> bialix: I pushed your emails through the admin, yes they were trapped as potential spam
<jam> morning vila
<abentley> bialix, you are actually editing a patch?
<bialix> abentley: what exactly
<vila> morning jam !
<bialix> abentley: yes
<bialix> morning jam! thanks!
<rubbs> that article links to "quickly" i didn't know that existed. That's pretty nice.
<bialix> abentley: if you will look on my files in the zip you can see the end result of new file which I've edited and saved
<bialix> I've tried several attempts with no luck
<abentley> bialix, it doesn't sound like an unsupported use case.  As long as you're saving the new version, not the old version.
<abentley> bialix, I don't really have time to investigate right now.
<bialix> the old version is read-only, I can't edit it
<bialix> ok
<Tak> hahaha - "Please stop working on this. You could be taking the jobs of programmers by offering this for free."
<rubbs> Tak: where is that from?
<Tak> oh, it's one of the comments on the article: http://arstechnica.com/business/2010/02/an-introduction-to-collaborative-development-with-launchpad.ars/3?comments=1&comment_id=156008433041
<rubbs> ah... obviously a troll
<thread_au> Hi there, I'm going to struggle to make my question concise, but I'll have a go...
<jcastro> lifeless, ends up the db changes needed for +patches won't land until 1 March.
<thread_au> i have a no-tree repository, which I'm endeavoring to use via light-weight checkouts when necessary.
<thread_au> however, 1 or two folders that I would consider "branches" (have the .bzr directory in them, and happily support checking out, with revisions then showing up in bzr-explorer) don't seem to want to merge
<thread_au> bzr: ERROR: No WorkingTree exists for "file:///H:/My%20Documents/Projects/FreescaleMPCCA/trunk/.bzr/checkout/".
<thread_au> I feel I haven't given quite enough information to make a proper question but I'm not sure what to give...
<rubbs> I don't know if I can help solve, but I can help clarify for others here. (help get to the bottom of the problem).
<thread_au> sure thing
<maxb> thread_au: When in doubt, pastebin a copy/paste of a terminal window showing exact commands that you ran and what they printed
<rubbs> so you are using bzr-explorer with two tree less branches you wish to merge.
<thread_au> I'm mainly using tortoise-bzr with bzr-explorer just to keep an eye on what it considers in the shared repo
<rubbs> at the time of the merge are their working trees present?
<thread_au> only in the checkout
<thread_au> (trunk at this point contains no revisions however)
<thread_au> well, it has one now, as I added one in case that was the problem
<thread_au> I have one treeless repo, within which I created a folder "trunk", which I ran "init" on. Then used "branch" to create a branch called "beginning".  To perform work I created a lightweight checkout from beginning, which seems to commit fine. bzr-explorer reports that there are "changes not in parent branch" (as expected)
<thread_au> in my head I should then run "merge" from trunk folder to propagate teh changes there.
<fullermd> You run 'merge' from inside the/a working tree for the branch you want to merge into.
<thread_au> so lightweight checkout from trunk
<thread_au> and then merge to there?
<thread_au> sounds reasonable
<thread_au> it seems i was led astray by a bugreport i was just reading if that's the case
<fullermd> Being as how merge sets up information to be committed, it would be difficult to do it without a WT  ;)
<thread_au> but bzr is magic! :P
<thread_au> (I was reading this https://bugs.launchpad.net/bzr/+bug/91614)
<ubottu> Ubuntu bug 91614 in bzr "Error messages should not include internal filenames below bzrdir" [Wishlist,Confirmed]
<thread_au> which seemed to say that trees were not necessary, but that was for a pull
<thread_au> nice bot function btw
<fullermd> Right, pull just moves existing revisions around, so there's no need for a tree.
<fullermd> Merge set up pending info to be committed, so that has to go SOMEwhere.
<thread_au> (just squirrelling away...)
<guilhembi> jam: thanks a lot for your answers re: annotate, re:push/pull/1.9/1.14, lots of food for thought!
<thread_au> thanks fullermd and rubbs
<thread_au> the merge worked (well... attempted) which gave me more stuff to figure out that i have been working
<thread_au> and the command line feels a lot tighter I think now I'm using it
<rubbs> thread_au: glad you found help. sorry I couldn't help more myself.
<thread_au> you asked the right question actually
<thread_au> regarding trees
<rubbs> meh, dumb luck on my part ;)
<thread_au> so much terminology to get my head around
<rubbs> it's hard at first, but working through it for a few weeks will really help.
<rubbs> and once you get it, it's almost like a light turns on. it becomes much more easy after that
<thread_au> stuff like "push vs send" and "pull vs update"
<thread_au> (I think i have pull vs update sorted :)
<thread_au> at the moment, trying to figure how push/submit/send/parent branches are meant to be set up/related
<rubbs> yeah, those are hard, because the differentiation isn't within the term itself, which I think makes it the hardest.
<thread_au> and why I couldn't merge to trunk without putting in -r0..-1
<rubbs> push is to copy the whole history to the target location. Parent is the branch which you branched from. submit I'm not too sure to be honest, and send I believe is a way to send patch info through email.
<thread_au> which I didn't quite understand.
<rubbs> mmm... not sure on the merge thing.
<thread_au> so far so good
<thread_au> I'm used to manpages and such so I'll get there
<thread_au> although...
<thread_au> "man" doesn't work here on windows :-/
<thread_au> so off to the browser it is
<rubbs> haha. try bzr help
<rubbs> or bzr help topics
<thread_au> additionally...
<rubbs> that got me through a lot
<thread_au> are these terms bzr specific?
<rubbs> some, but most are DVCS specific
<thread_au> because I haven't really tried other systems and I'm not sure if that's why it's pretty uphill
<rubbs> so many terms will work in Git and in Hg.
<fullermd> If you had to put in -r0..-1, it's because the branches didn't share any common ancestry at all.
<jam> guilhembi: yeah, sorry the answer wasn't better for you
<fullermd> (and while there are many times you'd want to do that, you'd probably know it if you did)
<thread_au> fullermd: this is what I guessed based on the error message, although 'b' was branched from 'a', and I wanted to merge back...
<thread_au> I guess the issue was 'a' was empty when i branched off
<thread_au> and then one empty file was added to 'a'
<thread_au> which may have made them appear like there was no (real) ancestry.
<fullermd> Well, it causes that appearance because that's the case   :)
<fullermd> There's no meaning to "ancestry" aside from "what revisions are present".  Two branches sharing no revisions share no ancestry.
<thread_au> Alright
<thread_au> i really should go to bed, thanks to those who had helped
<thread_au> it was a bit of a panic as It hought I mostly had grasped the concept of DCVS but then things started behaving not hwo I expected
<thread_au> in any case, I'll likely see one or more of you again - I get the feeling learning this properly will be like getting the hang of gentoo was a while back
<thread_au> which means the "give and learn" of IRC will be more than useful
<guilhembi> jam: I'd like to prepare a MySQL repository converted to 2a, for sharing with my colleagues, so it's important that I don't give them something bad; I have bzr.dev of Feb 4th, is that good enough for generating the repo ?
<guilhembi> I just would like to make sure that it does not contain an important bug...
<guilhembi> jam: and also, after a computer poweroff/poweron, can I safely delete "obsolete_packs/*" (to not send them useless files)?
<jam> guilhembi: after a 'sync' it is safe to delete obsolete_packs
<jam> generally probably after a few seconds it would be safe
<jam> the key is that *bzr* can't really know when the os finishes writing to disk
<jam> in case there is a power outage, etc.
<jam> guilhembi: bzr.dev from Feb4 should be fine
<guilhembi> jam: ok, so as a clean shutdown includes a sync, I am safe with deleting...
<jam> yeah
<guilhembi> jam: thanks a lot.
<jam> also, watch out for '.bzr/repository.backup' and 'backup.bzr'
 * guilhembi checks
<guilhembi> jam: regarding the impossible-to-fix annotate slowdown, I don't know what to do. Speed is the main reason for upgrading the 100 guys, and the speed gain is not so clear due to this annotate thing. I'm looking for something compelling to announce... is there some other command than "bzr log" which gets a speedup with 2a? some other command than "bzr annotate" which gets a slowdown?
<jam> bzr log -v
<jam> went from hours to minutes on bzr.dev
<guilhembi> ok (but almost nobody uses it)
<guilhembi> ahah
<jam> du -ksh .bzr
<jam> went from 600+MB to 200MB
<guilhembi> yes, observed this
<jam> so initial branch should be ~3x faster
<jam> push + pull are faster similarly, though not always universally
<guilhembi> jam: eof?
<jam> guilhembi: you mean eol handling, or am I done talking?
<guilhembi> jam: done talking :-)
<jam> sorry, I've got a couple of conversations going on
<guilhembi> jam: don't worry, this isn't urgent. I didn't mean to be pressing.
<guilhembi> bbl
 * bialix wonders what is the site arstechnica.com
<rubbs> bialix: at tech news site that covers lots of topics having to do with Sci/tech.
<rubbs> a tech*
<bialix> thx
<jam> rubbs, bialix: Interestingly their "About Us" link at the bottom of the page is a 404...
<bialix> jam: yep, I saw this too, hence my question
<poolie> hello jam, bialix
<jam> hi poolie
<jam> taking a light nap again :)
<poolie> :)
<bialix> hey poolie, your night is over?
<poolie> unfortunately so :)
<bialix> :-)
<poolie> i was in london last week so i'm waking up early
<jam> its what, 5am there?
<bialix> 5pm
<jam> in Sydney it is ~5am
<poolie> 4:30
<poolie> am
<bialix> ah, I've talked about London
<jam> which is why poolie is sad
<bialix> so, 2.1?
<bialix> is there some blockers?
<poolie> good question
<poolie> i don't think so
<poolie> we should do it
<jam> I was meaning to ask around today
<jam> I haven't seen bzr-explorer 1.0 final
<jam> vs beta
<bialix> I can pack the one.
<bialix> just today I've synch'ed translations
<bialix> maybe we need final word from igc
<bialix> but there is no major changes in explorer trunk since Ian called it rc1
<bialix> jam: I would say: I can pack 1.0rc1
 * bialix has to go
<poolie> that sounds ok to me too
<poolie> jam, did we ship rc1 in the last bzr rc?
<jam> no
<jam> I didn't do an rc3 last week because of the car stuff
<jam> I was just going to do a final, but I can do something different if you prefer
<poolie> well, i'm just a bit concerned that ian has put in a large change in explorer
<poolie> but maybe we should just ship it, and if it is broken it's on his head
<poolie> jam, thanks for all the bug triage
<jam> I've actually found it pretty interesting
<jam> I'm going through the "new" bugs
<poolie> i see :)
<poolie> i wish i'd set up a graph
<poolie> but it's not too late
<jam> well, if lp apis could tell you the date when something happened
<jam> I got through what... 30 new bugs
<jam> still have 194 to go :)
 * jam goes and forages for food
 * jelmer hopes Dmitrijs isn't going to invite every bug he's ever communicated with to join LinkedIn...
<poolie> urk
<fullermd> So informal, too.  It should be "Mr. Bug".
<mkanat> lol
<jam> jelmer: probably just the ones that get marked Invalid
<jam> we should be warned :)
<jam> speaking of which, how the heck did "Carson Coker" get his ad through to bazaar@?
<jam> maybe an accidental "accept" ?
<poolie> maybe
<poolie> jam i didn't see any mail from him but maybe my spam filter caught it
<poolie> so we have 9 bugs currently inprogress
<bjp> how do i globally disable loggerhead as a plugin?
<gerard_> hey
<poolie> hi gerard_
<poolie> bjp: just move it out of the plugins directory
<bjp> poolie: where is the global directory?
<jam> poolie: https://bugs.edge.launchpad.net/bzr/+bugs?search=Search&field.status=In+Progress has 60
<poolie> sorry, i meant to say 9 fixcommitted
<poolie> which should be even closer to being ready
<jam> which I also don't think is particularly accurate
<poolie> bjp, how did you install it?
<poolie> bjp, maybe i should also ask, why do you want to disable it?
<bjp> it's giving me this error whenever i try to push/pull from the server: Unable to load plugin 'loggerhead'. It requested API version (1, 17, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages ...
<maxb> Where is loggerhead installed? Is it systemwide or someone's home directory?
<poolie> bjp,and you have a later bzr on the server?
<bjp> well, i just recently installed it into /opt/loggerhead
<bjp> yea, 2.1
<bjp> from bzr branch
<poolie> jam, for interest, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/520625
<maxb> "<module 'bzrlib' from '/usr/lib/python2.6/dist-packages" does not sound like 2.1 from a bzr branch to me
<ubottu> Ubuntu bug 520625 in launchpad-foundations "please block bulk mail (quasi spam) from linkedin" [Undecided,New]
<bjp> i mean loggerhead is from bzr branch
<poolie> max i think that's where bzr is
<poolie> bjp you need to either upgrade or uninstall it
<bjp> which?
<bjp> i'm using loggerhead as a stand alone server, i don't need it as a plugin
<maxb> Oh, is there a loggerhead 2.1 now? I assumed that was a bzr version
<bjp> yea it was, i'm using bzr 2.1, and loggerhead's latest bzr checkout
<bjp> sorry i didn't post the full error, i didn't want to spam
<rubbs> bjp: could you pastebin it?
<bjp> sure
<rubbs> !pastebin
<ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<bjp> http://pastebin.com/m76ad4015
<maxb> bjp: Also please confirm the bzr revno of loggerhead that you are using
<bjp> 400
<maxb> That error you paste should not be possible
<bjp> i figured i could just remove it from the plugins dir, but i'm not sure where global plugins are
<maxb> Is it possible you also have an older loggerhead installed?
<bjp> not possible??
<bjp> maybe... :)
<maxb> Sorry, not possible with loggerhead r400
<bjp> i installed the latest one in an isolated environment
<maxb> I suggest 'locate loggerhead/__init__.py'
<bjp> i ddin't even look to see if there was another one
<bjp> oh there was one in the package manager
<bjp> that fixed it :)
<lifeless> jcastro: :(
<poolie> hi lifeless
<fullermd> poolie: Err?  bug 130783 isn't "fix released" AFAIK...   the generated files are still there.
<ubottu> Launchpad bug 130783 in bzr "`make clean` should clean up after pyrex" [Low,Fix released] https://launchpad.net/bugs/130783
<poolie> the .so files?
<fullermd> No, the .c files.
<poolie> yes but that wasn't actually his complaint
<fullermd> Well, it was [part of] mine, and it was my bug   :)
<poolie> ok
<fullermd> The .so bit was taken care of looks like a few months after the bug was filed.  I'd still like to whack the .c's though.
<fullermd> e.g., when I upgrade pyrex or python or the like.
<jcastro> lifeless, poolie: http://arstechnica.com/business/2010/02/an-introduction-to-collaborative-development-with-launchpad.ars
<jcastro> if someone could answer the guy's question about netbeans bzr that would be great.
<poolie> fullermd: i  reopened it
<poolie> jcastro: there is no netbeans integration atm afaik
<jcastro> poolie, ah bummer, I found some stuff on searches but it looks old and out of date.
<jcastro> poolie, mostly I just wanted to make sure you guys were aware of the discussion, seems like the article is very popular right now
<poolie> thanks
<poolie> i only glanced at it but will read it now
<fullermd> Hm.  Is anybody else actually using cython instead of pyrex?
<fullermd> It seems to blow all sorts of bright-colored chunks for me.
<bob2> outside of bzrland?
<fullermd> No, with bzr.
<mtaylor> anybody around with good grokking of the interaction between bzr-builddeb and dpkg v3.0 (quilt) from a workflow perspective?
<lifeless> garhk
<mtaylor> lifeless: that's how I feel!
<poolie> jam, still around?
<jam> poolie: yep
<poolie> so, 2.1?
<jam> as in, you want me to release it today?
<poolie> well, shall we?
<poolie> it doesn't even specifically have to be you
<poolie> i just want to work out where we're going
<jam> I think it is about time to do so
<poolie> ok, so can you do it on friday, or do you want someone else to?
<poolie> also maybe we can get a new rm
<poolie> lifeless: i crave review of https://code.edge.launchpad.net/~mbp/bzr/368931-rename-case-2.0/+merge/19079
<fullermd> jam: BTW, you can actually run bzr with cython?
<poolie> lifeless: is there anything specific that drupal actually want help with?
<poolie> that's a long thread
<jam> fullermd: I don't think you can run all of bzr with cython, but you can compile the extensions with cython
<jam> (and we do that automatically if pyrex isn't available)
<poolie> fullermd: btw please don't say 'error' if you mean 'warning'
<fullermd> Well, it compiled fine here, but it wouldn't run at all.
<jam> poolie: your test won't run on Windows
<poolie> that's why i thought there would be a bug or news entry
<poolie> ah
<poolie> jam, true
<poolie> well,
<poolie> it's meant to be a per-tree test
<poolie> so in theory it would work on some trees
<jam> poolie: if you like, you can skip it
<jam> but mkdir tree; touch Tree will pretty much always fail
<lifeless> poolie: the mails I'm forwarding are from chx; he's keen to see us provide advice on what bzr can do and how, and is drawing attention to specific points.
<fullermd> Just wondered whether that was expected.
<jam> poolie: I think you could use BranchBuilder instead of build_tree
<lifeless> poolie: emmajane or davidstrauss will have opinions too :)
<poolie> i suspect that test file is a bit inaccurate about actually testing the right class
<jam> as that builds using a memory tree
<poolie> jam, sometime soon i'd like to systematically rework one test file to separate all the creation
<poolie> into a 'test factory'
<poolie> but maybe not using that name as it's odoriferous to launchpad devs
<jam> :)
<poolie> winepython does actually fail on those tests
<poolie> which is nice
<jam> poolie: ideas for codename for 2.1.0?
<poolie> um, i did have a good one
<poolie> are you doing it now?
<poolie> actually i'd just call it Strasbourg
<jam> yeah, I'm writing up NEWS, etc
<jam> poolie: should we try to do a summary of what 2.1 is vs 2.0?
<poolie> yes
<poolie> i think perhaps we should fold that all up into the summary paragraph of 2.1
<poolie> rather than per-beta things
<poolie> oh also
<poolie> we shouldn't put 'not released yet' into the headings
<poolie> because it makes the html look a bit messy
<jam> poolie: can we put it on the release date line?
<jam> :2.1.0: (not released yet)
<jam> ?
<poolie> yes i think that'd be good
<poolie> after making a memorytree, how do i add the root so that i can start adding other stuff?
<spiv> tree.add('') ?
<poolie> nup
<poolie> use treebuilder apparently
<spiv> I think that's what BranchBuilder attempts to do, anyway.
<poolie> i don't actually want a branch
<poolie> it should be enough to test this on just a tree
<poolie> but that may be easiest
<poolie> blah
<poolie> some of the per_tree things assume it's a real working tree on disk
<Kilroo> Hm. If there's a ticket that would address the ability to create a branch bound to and stacked on a subversion repository, I can't seem to find it.
<Kilroo> Probably searching for the wrong thing.
<lifeless> Kilroo: well you want cross format stacking
<Kilroo> that or a solution to my problem with bug 109114 that doesn't amount to "using bzr to interact with this svn repo requires a 64-bit operating system."
<ubottu> Launchpad bug 109114 in bzr "[master] bzr holds whole files in memory; raises MemoryError on large files" [Wishlist,Triaged] https://launchpad.net/bugs/109114
<Kilroo> Well, correction. Lightweight checkouts still work.
<Kilroo> Just slowly, and they don't gain me anything. On the repositories that don't run into that problem I can use local feature branches.
<spiv> Kilroo: the large files are some way back in history, IIRC?
<spiv> Kilroo: the other feature that isn't implemented yet, but might help you if it was, is "shallow branches".
<Kilroo> The one that I'm certain is actually one specific file is probably about half a dozen to ten commits back or so.
<Kilroo> The other branches that hit the out of memory error, the revision I can't pull is well back in the history and I am not certain if there's a large file that is the culprit or if it is just the fact that a gigantic lump of filesystem was committed all at once.
<Kilroo> But yes, if I could have a shallow bound branch, that would work too. In fact, I was pretty much thinking of a stacked bound branch as being a surface-level shallow bound branch, in terms of functionality.
<Kilroo> I honestly hope, though, that we will redo our repository arrangement at work in the near future, in a way that would make most of my problems disappear just by getting rid of all the crap that doesn't make sense.
<zombor> anyone know of a plugin to push bzr into git repos?
<bob2> the bzr git plugin?
<spiv> Kilroo: Right, although bug 375013 probably stops stacked branches from being a solution for you atm.
<ubottu> Launchpad bug 375013 in rosetta "Cannot commit directly to a stacked branch" [High,Triaged] https://launchpad.net/bugs/375013
<zombor> bob2: this says push is not supported: https://launchpad.net/bzr-git
<zombor> i want to work with github repos, but i dont want to use git
<bob2> ok
<Kilroo> Hm.
<Kilroo> Yeah, looks that way.
<zombor> ive found git -> bzr but not the other way around
<Kilroo> From what I've read, the closest I've found to a way to use bzr to work with a git repository would be to pull stuff into bzr, work in bzr, and get everything back into git by generating patches.
<Kilroo> Still requires working with git.
<Kilroo> I've never tried even doing that though.
<zombor> Kilroo: yeah, sounds icky
<zombor> might as well work right with git ;)
<Kilroo> spiv: Actually, I think the workflow I want to use would mean that stacked branches would work just fine, because the stacked branch would be in a treeless repository and would not receive commits directly. Without being able to test what I have in mind, I can't be sure, though.
<spiv> Kilroo: well, that bug also stops you making commits to a stacked branch from a lightweight checkout of the stacked branch.
<Kilroo> That was what I was about to say I wasn't sure of.
<Kilroo> ...
<Kilroo> What if you committed to a lightweight checkout of a branch bound to the stacked branch?
<Kilroo> Never mind answering that, because I'm not even sure what the heck I just said.
<fullermd> Creating that bound branch would copy over the whole history, in which case you might as well skip the stacked middleman, and you wind up back with your original problem  :p
<spiv> fullermd: or the bound branch itself could be stacked too, which still leaves you with the original problem ;)
<Kilroo> Oh.
<Kilroo> Oh well.
<spiv> Basically, if it were that easy to workaround, we'd have fixed it already :/
<fullermd> But then you could...  you just...   well, you ca!@&$(%  Stack size exceeded (core dumped).
<Kilroo> Yeah, sounds to me like we're more likely to fix things at work so that it's not an issue before a fix lands in bzr
#bzr 2010-02-12
<igc> morning
 * fullermd waves at igc.
<igc> hi fullermd!
<fullermd> igc: I was curious, in this post-2.1 (or almost-so) world, whether content filter stuff was perking up toward the top of people's stacks.
<igc> fullermd: I certainly hope to get branch-specific rules into 2.2
<igc> fullermd: what did you have in mind in particular?
<fullermd> Oh, just my standard low-level antsyness for $Keywords$.
<fullermd> The branch-specific rules and that collapsing bug are the only things I know offhand keeping it in "PoC curiosity" rather than "Try it on for real use".
<fullermd> (of course, once we hit the latter, THEN we ferret out the other 15,278 things it really needs   ;)
<fullermd> (if the answer is "nahgonna'appen this cycle", that's reasonable; just trying to keep up-to-date on my mental sense of where it falls on the List)
<Pilky> hey got a bit of an odd theoretical question
<fullermd> Pilky: You're in luck!  I've got an odd theoretical answer right on tap!
<Pilky> if I have a repo with a few branches in, the revisions are stored in the repo
<Peng> In theory, yes. :D
<Pilky> and if I remove the branch by using standard file operations the revisions aren't lost
<Pilky> so theoretically would it be possible to then reconstruct that branch
<fullermd> Basically, yes.
<Pilky> cool
<fullermd> You lose branch-specific config bits, like the parent/push/etc branches, the nick, yada yada.
<fullermd> But all the history revisions are available.
<Pilky> those are minor details, it's the code that's important
<Pilky> but yeah it just made me think after reading this blog post: http://rentzsch.tumblr.com/post/384353696/time-machine-your-version-control-safety-net
<Peng> The "bzr heads" command from bzrtools will help you find them. (Check the help for the proper options.)
<Peng> Then, init a branch in the repo, and do "bzr pull . -r revid:foo" with the ID you got from "heads".
<fullermd> Yeah.  There may be cases where that config is necessarily and irreplacable, but I have a very hard time even fabricating such a situation.
<Peng> Tags will be lost, too, but presumably you can pull most of them from one of your other branches.
<fullermd> Oh, yeah, I forgot about that.  That's probably the most likely source of a crippling (or at least maiming) loss.
<Peng> Who ever deletes a branch with more than 1 or 2 unique tags, though?
<Peng> ...Well, it's uncommon, at least.
<Pilky> well, even if you work alone, you should be pushing to a remote server frequently
<Peng> Also you have backups, eh, ehh? :D
<fullermd> Peng: Well, nobody, BEFORE.  Now that you've said it, 6 people will show up in the next few hours asking how to recover from it.
<Pilky> Peng: heh I have local backups of everything, but I have my source remotely
<fullermd> Sounds like a good time for me to leave, and let YOU field them   :p
<Peng> fullermd: Nah, I have stuff to do. (Or at least I'll find something!) Let's foist them on Pilky, he brought it up. :D
<Pilky> lol
<Pilky> I didn't mention tags!
<Pilky> you did!
<Peng> Oh damn.
<fullermd> You just did!
<Peng> Anyway, I really do have a little bit of stuff I need to do. See you soon! Probably!
<Pilky> heh as do i, that little bit of stuff being sleep
<Pilky> thanks for the answer!
<Peng> Sleep? I have a _lot_ of that I need to do, but I'm not going to. :P
<fullermd> Sl...  eep?  I believe I've heard of this concept.  I thought it was a myth.
<Peng> It's a huge waste of time. I'm working on avoiding it.
<Peng> I keep seeing Oprah Winfrey in my wall, and I can't really do math anymore, but overall I think it's going well!
<fullermd> Hm.  Do you think those two items are related?
<fullermd> ...  actually, I'm not even sure which two items I'm asking about, and every permutation I can think of is more interesting than the last.
<fullermd> So maybe we're on the same page!
<bignose> I have a pending merge, and also some other changes that I want
<Peng> Oprah would like some changes, too.
<Peng> She thinks my hair sucks. :(
<bignose> is the right way to proceed to âbzr shelve --all ; bzr commit --message "Merged" ; bzr unshelve --allâ? or is there a better way?
<Peng> Wait, what are you trying to do?
<Peng> You want to commit a merge without some of the changes that exist in the working tree?
<bignose> yes.
<bignose> I got the merge because I tried to commit my changes, but it failed because the repository was not up-to-date in this bound branch
<Peng> Oooooh, bound branches.
<bignose> so, I updated, and ended up with a pending merge
<Peng> I was wondering how you got into that situation.
<Peng> Sorry, but I don't know the right way to get out of this situation..
<fullermd> First, you remove commit --local...
<Peng> Then you remove bound branches completely? >.>
<bignose> well, it seems that shelve gets me through it. (done now.)
<bignose> but I'm wondering if there's a less fiddly way.
<fullermd> In a way, you're a bit screwed.  You can do OK with local commits, and you can do OK with uncommitted changes, but both at once is Bad Juju.
<bignose> I've done no local commits.
<bignose> (on this branch)
<fullermd> And that shelve won't really _solve_ it.  It'll make a pretty sizable mess in history, since you're committing a merge in which you undo all the changes, and then another commit where you redo all of them.
<fullermd> If you didn't, you wouldn't get a pending merge from an update.
<maxb> By the same logic that 'bzr merge' will require --force if there are modifications, presumably the same ought to apply to 'bzr update' in a bound branch scenario
<bob2> even if you have no local commits, bzr up can still cause lots of annoying conflicts
<bob2> (and trash your local changes)
<fullermd> Yes, but only of one set of changes.  With local commits, and uncommitted changes, you're in the same position as local changes + merge --force; you've got two things inextricably intermingled.
<bob2> it is true
<bob2> real unbound branches ftw
<fullermd> Well, I don't much care about bound branches, but you can have my heavy checkouts when you pry them from my cold dead hands   :p
 * bignose doesn't understand the difference between âheavy checkoutâ versus âbound branchâ
<bignose> also, I don'
<bignose> also, I don't see what mess is created in history
<bob2> haha
<mkanat> bignose: The difference is just a configuration variable.
<bignose> hmm. what I see in history is that the merge made a change, and the same change is then part of the local changes I've committed after the merge.
<bignose> weird.
<fullermd> Well, the difference is conceptual, and doesn't formally exist in bzr-today.
<lifeless> fullermd: some people dispute that it exists
<fullermd> Yes, but their mothers were hamsters, and their fathers smelt of elderberries.
<bignose> fullermd: is there anyone else here I can talk to?
<fullermd> No!  Now, go away, or I shall confuse you a second time!
<bignose> heh
<lifeless> bignose: whats the question ?
<bignose> lifeless: about 40-50 lines back in this channel
<bignose> lifeless: simply, is there a less-fiddly way to resolve local uncommitted changes combined with a pending merge from the remote repository?
<lifeless> bignose: just commit
<lifeless> bignose: bzr will know what was from the merge and what was your changes
<lifeless> because you've done an 'update' right? - bzr should have done a pivot for you
<bignose> what's a pivot?
<bignose> the problem I encountered was that I want to do partial commits
<bignose> but Bazaar won't allow that while I have a pending merge.
<bignose> (to answer the question: yes, I did âbzr updateâ, which is where the pending merge came from.)
<lifeless> ok, then you should shelve the stuff you aren't ready to commit, and then commit.
<bignose> right. that worked. is there a less-fiddly way? say, to get just the merge committed?
<bignose> or, ideally, to get the update done without resulting in a pending merge?
<lifeless> so the update only adds a pending merge if you have done disconnected commits
<lifeless> so one way is 'do not do disconnected commits'
<bignose> never happened on this branch.
<bignose> (or did it? can I tell?)
<lifeless> someone uncommitted then on trunk
<lifeless> either an uncommit, push --overwrite, or you did a 'local' or 'offline' commit
<bignose> can that be detected after the repository is synchronised?
<lifeless> not really; log -n0 may give a hint
<fullermd> Mechanically?  Not really.  But by looking at the revision in the log, you can probably figure it out.
<bignose> thanks for the help
<lamalex> Hi, can someone help me figure out why one of my co-developers is getting this error when he pushes to what (should be) a shared branch? bzr: ERROR: Cannot lock LockDir(chroot-24202192:///var/trac/c4398s10_2/repo/trunk/.bzr/branch/lock): Permission denied: "/var/trac/c4398s10_2/repo/trunk/.bzr/branch/lock/5ffyoe3oy1.tmp": [Errno 13] Permission denied: '/var/trac/c4398s10_2/repo/trunk/.bzr/branch/lock/5ffyoe3oy1.tmp'
<lamalex> what should permissions be to prevent this from happening
<fullermd> He needs to be able to write into that dir.
<fullermd> (and some others under .bzr; probably simplest to be able to write to _everything_ under .bzr)
<spiv> lamalex: as fullermd says; they need filesystem write permissions.  You may want to have a 'bzrrepo' group that owns all files/directories in that repo to help with that.
<bignose> lamalex: My understanding is that (like most DVCS) Bazaar works on the assumption that there is a single owner of each repository.
<spiv> bignose: not really
<bignose> so, for a repository to be shared with multiple users, there should be a single account that owns the repository; and some mediator to allow other users to act as that user.
<lamalex> spiv: so if I chgrp -R the repo, we should be ok?
<spiv> Bazaar is perfectly happy for multiple users to be able to write to the repo, but you do need to arrange the filesystem permissions to allow that, which probably means a common group and maybe also setting a sticky bit on the group perms so new directories are owned by that shared group.
<fullermd> lamalex: On a filesystem with SysV semantics, you'll need g+s on the directories as well.
<bignose> e.g. the Bazaar server; or the PQM; or an account used via SSH public key.
<lamalex> fullermd: merci
<lamalex> bignose: that's definitely not true at all
<lamalex> that's not even how launchpad works
<fullermd> Launchpad works by using FM technology.
<spiv> fullermd: fairy munchkins?
<lamalex> :)
<fullermd> F.....lippin' Magic.
<Buginator> Is there a good bzr GUI client for SnowLeopard ?
<fullermd> You can't set a snow leopard loose in a bazaar.  It would be chaos.
<fullermd> Buginator: Explorer and/or qbzr are the general answers on most platforms.  AFAIK they work on OS X, though I don't know how hard they are to get installed.
<Buginator> ok, thanks
<bignose> lamalex: there's quite a lot of infrastructure difference between âmulti-user repositoryâ versus âLaunchpadâ
<spiv> Need coffee.
<slestak> hey guys.  i was just tinkering with bzr before trying to use it for real, and I would liek to start my repo over from nil
<slestak> ive googled and looed at the docs but I do not see how to do this
<slestak> for instance, i had my eol settings in a state i do not want them longterm, so I think I have crlf stored in the repo.
<fullermd> Well, the general means of starting from scratch involves "rm -rf" and...  well...   starting from scratch.
<slestak> i think that will just remove the branch,
<slestak> i may have not even doen an init-repo, I may have just init'd a single dir
<slestak> how can one tell the difference between a repo that holds branches and a dir in your projects folder that is just a branch of a remote project you were hacking on?
<fullermd> info will tell you.
<fullermd> But if you have a repo separate from the branch, that just means "rm -rf" * 2   :>
<slestak> i use several workstaitons and I have not reconciled where my repos will live
<meoblast001> hi
<slestak> ok, bzr info list root as being . which is good.  And a push branch as my fileserver at home.
<meoblast001> is there any way to read Bazaar commits from PHP?
<slestak> let me look at bzr help info, thx for assist
<spiv> meoblast001: not that I know of, the format is pretty complex so it would take a fair bit of effort to write the PHP to decode it.
<meoblast001> maybe this is more of a PHP question
<lifeless> system('bzr info')
<meoblast001> ok
<lifeless> ?
<lifeless> :)
<poolie> meoblast001: i'd probably run 'bzr log' in a subprocess with popen
<poolie> and parse that
<meoblast001> ok
<poolie> lifeless: rereview https://code.edge.launchpad.net/~mbp/bzr/368931-rename-case-2.0/+merge/19079/+request-review pls?
<slestak> if I have a project that is a proof of concept, but could grow large in the future, is it commonr to refactor branches from one repo to another?
<slestak> duh, merge.  sorry for elementary questions
<lifeless> slestak: repos don't matter for workflow: all the affect is performance.
<slestak> lifeless: ive been really in analysis paralysis about project dir setup.  i have a mix of personal and work machines and projects.  I work on all of them on all the machines
<lifeless> slestak: thats fine, just do it
<lifeless> once you know how you're using it you can decide how to tune it
<meoblast001> spiv: http://m.mysticgalaxies.com:8080/host/meoblast001/software/dontwant/bzr.php
<meoblast001> that's the only problem :P
<lifeless> poolie: + if tests.CaseInsCasePresFilenameFeature.available():
<lifeless> won't work too well
<poolie> why?
<spiv> meoblast001: well, a <pre> tag and HTML-escaping will help a lot :)
<meoblast001> ah, probably
<lifeless> poolie: its already in tests :)
<lifeless> poolie: # new coding style is for feature instances to be lowercase
<lifeless> dunno if I'd bother with the comment
<spiv> meoblast001: also, I think there's an xmloutput plugin
<poolie> you can import a module from within itself
<poolie> but it's a bit messy
<spiv> meoblast001: so that you could do "bzr log --xml", which might be more convenient (or maybe not)
<lifeless> oh I see you have. I wish colourisation upon these diffs
<spiv> meoblast001: https://launchpad.net/bzr-xmloutput
<lifeless> poolie: anyhow, I'd use the global name space rather than importing inside the feature. other than that , JFDI
<poolie> i did that
<poolie> just now.  i previously put it in features but then decided it was better next to its buddies
<lifeless> then +1
<poolie> tell me, do you think my comment in make_canonical_tree is correct?
<poolie> if i change it to use _convert_tree i do get some failures
<lifeless> this isn't actually guaranteed to return the class ?
<poolie> it seems to be returning a workingtree
<poolie> whereas this class also wants to test some revisiontrees
<lifeless> so per_tree is a bit stubby
<lifeless> but the intent of it is definitely to test more than working tree
<lifeless>  Ihaven't seen make_canonical_tree before, I'd guess someone adding a helper that is either meant to be _convert_tree'd, or that wasn't really following the intent.
<meoblast001> thanks spiv
 * igc lunch
<lifeless> where?
 * lifeless WANTS
<fullermd> Maybe he was suggesting himself AS lunch...
<idnar> launch
<idnar> lunchpad?
 * fullermd . o O ( bzr pull lp:BLTandFries )
<dOxxx> greetings
<spiv> fullermd: hmm, have you signed the contributors agreement?  I have a feeling that you probably have, but don't see your name in the LP team.
<dOxxx> good night all
<lifeless> fullermd: thats cruel man... oh I could so eat that
<igc> night all
<gerard_> aahh
<gerard_> admin!
<lifeless> jelmer: ping
<lifeless> jelmer: I'd like to ask a small favour: update the bzr-search packaging :)
<lifeless> someone remind me to unban him tomorrow
<gerard_> lifeless: thx
<jml> hello
<jml> if I want to stop receiving emails about bzr merge proposals, I have to leave ~bzr-core, right?
<lifeless> jml: I dunno
<lifeless> jml: perhaps you coul subscribe to the relevant branch directly and say 'dont mail me' in that subscription
<lifeless> jelmer: ping
<jml> lifeless, there's a thought. I'll try that.
<lifeless> jml: ping
<lifeless> meh
<lifeless> jelmer: ping
<tonfa> gug
<tonfa> can anybody point me to the details of the protocol used by bzr to discover remote changes?
<jpds> tonfa: I think it uses Avahi.
<ronny> jpds: he means the dag differnce finder, not location discovery
<ronny> lifeless: is there any spec on/doc on what exactly smart-server does?
<spiv> ronny: not really
<spiv> ronny: there's some basic stuff in network-protocol.txt in the developer docs
<spiv> ronny: but that's more about the basic RPC serialisation than what the RPCs do and how to use them
<tonfa> spiv: ok
<spiv> ronny: the individual RPCs are implemented in bzrlib/smart/*.py, and mostly have terse docstrings explaining what they do, e.g. http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.smart.repository.SmartServerRepositoryGetParentMap.html#do_repository_request
<spiv> tonfa: oops, I should have been addressing you :)
<spiv> tonfa: I'd be quite happy to answer questions here (if I'm around, probably not for much longer tonight) or on the mailing list
<tonfa> I see
<spiv> tonfa: the RPC API assumes a fair bit of familiarity with bzrlib, really.  e.g. the Repository.get_parent_map RPC essentially works the way bzrlib.Repository.get_parent_map does.
<spiv> tonfa: the complete list of methods can be seen in the source in bzrlib/smart/request.py
<spiv> tonfa: I'd very much like to improve the protocol docs, but there hasn't been much motivation to so far
<LeoNerd> I think I broke my bzr-svn cache :/
<LeoNerd> bzr: ERROR: exceptions.KeyError: 'No such TDB entry'
<spiv> tonfa: if you'd like to provide that motivation, great :)
<spiv> LeoNerd: whee!
<LeoNerd> I ctrl-C'ed it once because I ran "bzr st" instead of "svn st" by mistake, and didnt' want it to spend 5 minutes now pulling new revs... ever since then it's been broken
<spiv> tonfa: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/bzrlib/smart/request.py#L489 is where the RPC registrations start
<tonfa> spiv: btw we plan on adding early error returns for http in hg
<spiv> tonfa: what do you mean by "early returns"?
<spiv> You're talking about something to do with the finding the differences in the remote graph?
<tonfa> spiv: errors happening while streaming data,
<spiv> Oh, right.
<tonfa> there's a discussion about that at http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head:/doc/developers/network-protocol.txt
<spiv> Yeah.
<tonfa> so maybe if it works well for us you can do it too :)
<spiv> The current bzr protocol allows that, I can't remember if the HTTP medium handles it appropriately or not.
<spiv> Mid-stream failures are actually a fairly rare occurence for us!
<tonfa> for us too, it's just that we then don't show a meaningful error to the user
<spiv> Yeah.  And they are usually "interesting" errors that you'd rather have some hint about :)
<tonfa> yes, instead of asking the user to launch wireshark
<tonfa> or looking at the server logs
<tonfa> which isn't always possible
<tonfa> spiv: how do you clone the bzr repo in one line? (ie what's the url)
<tonfa> it will be easier to browse the code if I have it locally
<tonfa> bzr clone lp:bzr seems to work
<spiv> tonfa: in bzr, you clone branches, not repos (a confusing terminology difference vs. hg)
<spiv> tonfa: the canonical form is 'bzr branch URL', but 'get' and 'clone' are aliases of 'branch'.
<tonfa> ok, so I still didn't do anything wrong :)
<spiv> tonfa: so, that command is fine.  Note that Launchpad doesn't yet provide the smart server over HTTP, so you'll need to run provide an SSH key to Launchpad and use 'bzr lp-login' to make lp:bzr fully efficient :)
<tonfa> I see
<spiv> tonfa: oh,
<spiv> tonfa: if you add -Dhpss to your command line (or debug_flags = hpss to your ~/.bazaar/bazaar.conf), then your ~/.bzr.log will show much of the smart protocol conversation
<spiv> "hpss" stands for "high-performance smart server", our original jargon for this feature
<spiv> Which will certainly give you a much more helpful picture than wireshark :)
<tonfa> indeed
<lifeless> we'
<lifeless> re nuking clone and get for branches I believe
<fullermd> lifeless: Well, so setup a munch proposal on lunchpad   :p
<fullermd> spiv: This iteration, I don't think so.  Seems I went through whatever we had before it.
<tonfa> spiv: looks like search_missing_revision_ids() was what I wanted
<spiv> tonfa: yeah (although different operations use different codepaths sometimes, sometimes for good reasons sometimes not... :/ )
<spiv> tonfa: we have some plans to make some relatively cheap improvements to search_missing_revision_ids, but we haven't gotten around to implementing them yet
<spiv> tonfa: I'd be happy to compare notes with what you do in hg :)
<spiv> But not tonight, it's getting late here.
<fullermd> Is the fallout from the last round of contributor agreement stuff expected to arrive soon?
<tonfa> spiv: ok, night'
<spiv> fullermd: not sure, poolie is the one that would know
<fullermd> Mmp.  Well, I'd guess you'd know if it were expected in the next few days...
<spiv> fullermd: me?  Not likely, I'm essentially working part-time atm due to a newborn
<fullermd> Oh, I thought you were older than that   :)
<fullermd> Damn child labor laws...
<spiv> fullermd: and I'd be superfluous to that discussion anyway, poolie understands all the requirements
 * spiv submits a merge proposal and goes to bed
<fullermd> Well, I was just thinking if it were about to show up, I'd hold off for it instead of sending in the current one.
<fullermd> Owell.
<spiv> fullermd: yeah, I understand.  Unfortunately I really have no insight to offer :)
<fullermd> Hm.  irc.ubuntu.com is a CNAME for freenode, but isn't it still a little weird listing it in README?
<fullermd> spiv: 'k, sent.
<rubbs> morning all!
<quicksilver> can two completely unrelated projects live in the same shared repo?
<beuno> quicksilver, yes
<beuno> they just won't share revisions
<quicksilver> good.
<quicksilver> Can I somehow make bzr push push stuff up as g+w ?
<quicksilver> my umask on that machine is actually 002
<quicksilver> but newly pushed branches still go up as g-w
<quicksilver> (using bzr+ssh, that is)
<quicksilver> I remember some discussion years about about sftp ignoring umask
<quicksilver> but that was considered to be a shortcoming of sftp
<quicksilver> and I thought one of the good things about bzr+ssh was going to be fixing it.
<mzz> hmm! I haven't actually done this recently, but are you sure the shell startup script that sets your umask actually gets run if you use bzr+ssh?
<mzz> (I'd try putting a "touch /tmp/this-is-reached" in whatever script this is)
<mzz> I don't know if bzr+ssh sets umask itself
<mzz> but if whatever's setting your umask to 002 isn't reached that'd obviously cause this :)
<quicksilver> that's true enough.
<quicksilver> No, I'm not sure.
<fullermd> quicksilver: bzr preserves the +/-w based on the permissions of the directory.
<fullermd> sftp doesn't ignore umask; the problem there is that it refuses to set the set[ug]id bits.
<quicksilver> fullermd: but the enclosing directory is drwxrwsr-x
<quicksilver> fullermd: and new branches are getting pushed up as drwxr-sr-x
<fullermd> There's some uncertainty as to which directory it bases on.  It might be .bzr itself, or .bzr/repository, rather than the packs/ directory.
<quicksilver> setgid is being preserved, but not g+w
<fullermd> Oh, new branches.  Yes, bzr doesn't itself muck with perms on those.
<quicksilver> right, new branches.
<quicksilver> although perhaps your implication is that if we switch this to a shared repo, which we are about to do anyway, this problem will go away?
<fullermd> Probably an issue with which [parts of] rc files the shell reads in interactive vs. batch environments.
<fullermd> No, the packs for the revs would get the right perms, but the branch files themselves will still wind up umask-based.
<LeoNerd> Is there a way to alter the number of lines of context 'bzr shelve' uses? I have two unrelated changes in one file that are just close enough that they come out as one diff chunk... I'd like it to be two
<Meths> I imagine the solution would be to shelve one change, then make the second and shelve that but I may be corrected.
<fullermd> If you were thinking it before the fact, you wouldn't need shelve at all  ;p
<fullermd> AFAIK there's no way to split patch hunks in shelve.  There's some 'edit'-ish functionality, but I don't know how easy it would be to fake up what you want.
<LeoNerd> It's not that I want to split it, as such
<LeoNerd> If you use  bzr diff --diff-options="-c 1"  then they're split OK
<poolie> fullermd: re contributor agreement updates; i do expect it soon but it's unpredictable
<mtaylor> NEAT!
<mtaylor> bzr: ERROR: syntax error: line 1, column 0
<nosklo> can't use a proxy, how do I get meaningful error message?
<nosklo> lost connection, somebody answered?
<rubbs> no
<rubbs> what is your question again? I'm not quite understanding it
<nosklo> I'm trying to use a proxy
<nosklo> so I can branch some code
<nosklo> But when trying to do so, bzr returns a cryptic error which I can't make sense of
<rubbs> can you post the error on pastebin?
<rubbs> !pastebin
<ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<rubbs> I can't stay long (I have a meeting) but someone here can usually help if they can see the full error.
<nosklo> rubbs: http://paste.ubuntu.com/374922/
<nosklo> I don't know exactly *what* is not known
<nosklo> wget downloads fine
<nosklo> also using bzr alternatives like git and mercurial works
<rubbs> hmmm
<nosklo> I've tried to setup some proxy
<nosklo> in the bzr config files
<nosklo> but the bzr docs are hard to find
<nosklo> I can't find any mention of how you configure the proxy
<nosklo> so I'm doing guesswork
<rubbs> not sure how to help :(
<rubbs> any dev's in the house now?
<rubbs> oh... before I go, have you checked .bzr.log? it's usually in your home directory, or my documents if on windows.
<rubbs> that might give you more info, it can help others on here too.
<nosklo> oh
<nosklo> COOL
<rubbs> but I have to go. I'll be back in an hour or so.
<luks> it would be easier to use plain http url
<luks> I think the lp: directory service does some non-http API calls
<nosklo> luks: I've tried that and got a different error
<nosklo> luks: http://paste.ubuntu.com/374927/
<luks> http://bazaar.launchpad.net/~washort/ecru/trunk is the right url to use
<nosklo> same thing :(
<nosklo> http://paste.ubuntu.com/374930/
<luks> not code
<luks> bazaar
<luks> bazaar.launchpad.net
<nosklo> oh
<nosklo> that works!
<nosklo> luks: thanks
<luks> code.launchpad.net is the launchpad website
<luks> and it seems to force you to use https
<luks> which you can't do over a http proxy
<nosklo> https should work on my proxy
 * nosklo tests
<nosklo> yeah, wget can use https just fine
<nosklo> wget https://code.launchpad.net/ecru # works
<luks> no idea then
<luks> I prefer to use direct http/bzr+ssh URLs for launchpad to avoid problems like this
<nosklo> the error on .bzr.log is InvalidHttpResponse: Invalid http response for https://code.launchpad.net/%7Ewashort/ecru/trunk/.bzr/branch-format: Unable to handle http code 502: Proxy Error ( The parameter is incorrect.  )
<nosklo> however wget https://code.launchpad.net/%7Ewashort/ecru/trunk/.bzr/branch-format works
<nosklo> returns a file with "Bazaar-NG meta directory, format 1" in it
<luks> I don't know how http/https proxies work
<luks> but maybe bzr is doing something stupid like using http to talk to a https server
<nosklo> unfortunately I'm forced on this proxy in my company
<luks> do you have the https_proxy environment variable set?
<nosklo> yes
<nosklo> that's how wget works btw
<nosklo> if I remove the var, wget stops working
<luks> ah
<luks> (as I said, I don't know much about proxies, so just guessing)
<nosklo> me neither, but I'm trying to debug bzr anyway :) I'm trying to read the source code and reproduce the error on python
<nosklo> so I can ask on #python instead :)
<luks> jam might help :)
<jam> hi luks
<luks> hey
<poolie> hi jam, luks
<nosklo> jam: I'm having some issue when using a https proxy with bzr, can you help me debug?
<jam> hey poolie, nice to see you so early again :)
<nosklo> Hm I think I figured out
<nosklo> reading the logs of the proxy server
<nosklo> bzr is sending some unprintable bytes instead of CONNECT
<nosklo> I think it is trying to talk SSL to the proxy (it's a http proxy that can handle https)
<nosklo> wget sends a CONNECT 443 first
<jam> nosklo: we have you provide the format
<jam> so https_proxy=http://proxy.com:PORT
<jam> etcc
<jam> etc
<nosklo> I did it
<jam> nosklo: you can also try running "bzr -Dhttp COMMAND" which should add some debugging information to ~/.bzr.log
<jam> which might help figure out when we are trying to connect, and how
<jam> also, what version of bzr?
<nosklo> I'm gathering the info...
<nosklo> 1.13.1-1
<nosklo> http://paste.pocoo.org/show/177244/
<jam> well if you can, I would recommend upgrading to at least 2.0
<jam> I think we've had some recent work done on the proxy support
<jam> you can get it from our ppa
<nosklo> I will upgrade.
<jam> https://edge.launchpad.net/~bzr/+archive/ppa?field.series_filter=hardy
<nosklo> I'm on jaunty :)
<nosklo> but okay
<jam> I would have thought jaunty had newer than 1.13...
<jam> but sure
<jam> same archive has hardy => lucid
<KhaZ> Hello: I'm having an issue pushing to a remote repository - it says they're not compatible due to rich root support.  How can I fix this?
<KhaZ> Ah; nevermind.  bzr upgrade worked, on a hunch.
<jelmer> poolie, hi
<poolie> hi jelmer
<jelmer> poolie: Should I request a sync of 2.1rc2 to lucid yet or would you prefer to wait until 2.1 itself is out?
<poolie> i agree with james_w, we should sync now
<jelmer> ok
<james_w> jelmer: I can pull the trigger if it's just bzr
<james_w> or if you tell me what else
<poolie> you'll probably need some plugins too
<jelmer> james_w: all of the bzr world basically :-)
<fullermd> What's happening with 2.1 anyway?  I thought it was to be released yesterday or today...
<james_w> just a list of source packages will do then
<james_w> saves you filing all the bugs
<poolie> it will be soon, i think jam was busy with somethig else
<jam> poolie, james_w: Yeah it was supposed to be yesterday or today, but today I got caught up with $OTHER
<fullermd> Ah, 'k.
<jelmer> james_w: oh, it actually seems like most things are already synced
<jelmer> (looking at http://qa.ubuntuwire.com/mdt/bazaar.html)
<james_w> ah, I'd forgotten about that page
<jelmer> james_w: can you just sync bzr from experimental?
<james_w> there's no bzrtools release to go with it>
<poolie> i think there is?
<fullermd> There's a 2.1.0 out.
<poolie> at least upstream, announced 5 feb
<james_w> jelmer: do we not want that first?
<jelmer> james_w: hmm, that's a good point. I guess I'm not running the packaged version on my debian box, otherwise I would've noticed
<jelmer> I'll upload a newer version of bzrtools to experimental as well.
<james_w> thanks
<james_w> any chance of a bzr-builddeb upload as well?
<jelmer> sure
<jelmer> I think the changelog entry needs some work though..
<james_w> I'm writing it now :-)
<lifeless> jelmer: hi
<lifeless> jelmer: bzr-search :) please pretty please please.
<jelmer> lifeless, hey
<jelmer> lifeless, can you explain what you would like me to do to it exactly?
<jelmer> :-)
<lifeless> package a newer snapshot of trunk
<lifeless> the ~70 snapshot that is packaged is broken with CHK repos
<lifeless> its fixed in trunk, and we're getting lots of bugs from packaged-bzr-search users.
<jelmer> lifeless: revno 77 is the latest version packaged
<jelmer> at least according to my debian qa page
<lifeless> interesting
<lifeless> oh, I see - karmic.
<lifeless> So I think what I mean is 'sob, karmic is bust'
<lifeless> we could look at an SRU I guess
<james_w> jelmer: lp:bzr-builddeb should be ok for an upload now
<jelmer> james_w: thanks
<jelmer> lifeless: ouch :-/
<jelmer> james_w: wow, that's a lot of bugs that are fix released now :-)
<lifeless> bzr-search | 1.7.0~bzr70-1 | karmic/universe | source, all
<james_w> some have been fixed for ages, it's just not clear exactly what constitutes a release
<jelmer> james_w:   * Upload to lucid.
<jelmer> that's not quite true :-)
<james_w> oh yeah :-)
<james_w> + (indirectly)
<jelmer> james_w: the removal of the dependency on bzrtools isn't mentioned in changelog, did it make it into 2.3?
<jelmer> james_w: Looks like it, I'll update changelog
<lifeless> james_w: ping
<lifeless> james_w: I don't understand why import-upstream would delete stuff (re your calling it dhmake
<lifeless> james_w: in fact, bzrtools already has a tarball import; I guess I'd like to see that tarball import do the pristine tar stuff and then builddeb could lose that code altogether (or move it from both into core)
#bzr 2010-02-13
<jelmer> lifeless: into core please
<james_w> lifeless: it makes the tree the same as the content of the tarball, so if you run it in your packaging branch it would lose your packaging changes
<lifeless> james_w: thats not what it should do though, it should do an import + pending merge
<lifeless> james_w: *or* it should just import to the tag
<lifeless> james_w: by should, I mean to be most useful.
<lifeless> james_w: this would also make it safe to run in a packaging branch :)
<james_w> import + pending merge == merge-upstream
<james_w> import to the tag and print the revision-id it created?
<lifeless> james_w: no, import + pending merge + debian changelog mangling == merge-upstream
<lifeless> james_w: yes. For instance: import-tarball --to-tag 1.4.2
<james_w> well request a --no-changelog flag to merge-upstream if you don't want the last part
<lifeless> doesn't need to print the rev id, it would have made a tag.
<james_w> that's true
<lifeless> anyhow my main point is, that this has nothing to do with debianisation
<lifeless> it has everything to do with importing tarballs, so calling it dh_make is extremely confusion
<james_w> debianisation is import tarball + create packaging
<james_w> I wanted to solve that use case
<lifeless> and frankly, if you run 'import-tarball' or whatever the bzrtools existing command is and it makes everything look like the tarball, thats fine: bzr uncommit; bzr revert.
<lifeless> no harm, no foul.
<james_w> I added --bzr-only to just do the first step for those that don't want autogenerated packaging
<james_w> so that leaves a way to "import tarball"
<lifeless> james_w: I'm glad you've solved that use case.
<james_w> so I just mentioned that you can achieve what you want at the UI level as well now
<lifeless> I'd like to see a precise command that acts as a building block, for several reasons
<lifeless>  - debugging
<lifeless>  - reuse
<lifeless>  - showing people the mechanics
<james_w> I've never argued against having such a command
<lifeless> cool
<james_w> It's just not high on my priority list
<james_w> I would have happily merged a patch that did something sensible for an import-upstream command
<lifeless> etime :)
<james_w> and I would happily merge one now that built in the work I have just done, which should make it even easier
<james_w> that's fine, but I'm not blessed with bags of time either
<lifeless> I know
<lifeless> I recall a mail along the lines of 'done the command you asked for, its called dh_make'
<lifeless> which prompted this conversation, as it wasn't what I asked for (for all that it is a good thing to have).
<james_w> that's not how I intended it to come across
<lifeless> miscommunication happens, we deal :)
<lifeless> I'm glad you have done what you've done
<lifeless> when someone gets time other things can get done
<james_w> "if you have a need to you (lifeless) can now access this functionality at the UI level, rather than just the API by doing bzr dh_make --bzr-only. You'll still have to make a temporary branch for the upstream."
<lifeless> james_w: separate discussion: when someone does merge-upstream --version=4 foo-4.tar.gz ../trunk
<lifeless> does bzr-builddeb look to see if other commands have been done in trunk ?
<james_w> other commands?
<lifeless> or perhaps take a tag in trunk (of '4') in preference to tip ?
<lifeless> s/commands/commits/
<james_w> I've been pondering this
<lifeless> I'm thinking of the scenario where someone doesn't have a dedicated 'releases' branch
<james_w> currently it expects -r to specify it it's not tip
<lifeless> this would apply to import-upstream too, I should think (as its the tarball revision's parents we're talking about)
<james_w> it has functionality to remember the upstream branch, in which case I will make it look up the tag and require the -r if not there
<james_w> it should perhaps always have that behaviour
<lifeless> of wanting -r ?
<lifeless> I hate optional-options :)
<james_w> required options?
<james_w> I know, but I also hate inconsistent ways of specifying things like revision specs
<james_w> and we could add some sort of tag pattern configuration for those that use foo-4 or FOO_4 or whatever as their tags
<lifeless> yeah
<lifeless> I'd like to offer a reliable way for upstreams using bzr to say 'I made a tarball of this revision'
<lifeless> we can advertise that
<lifeless> tell people to hook 'make dist' into it, etc.
<james_w> that would be cool
<james_w> there was a patch for autotools around
<james_w> for git, but still
<lifeless> jml: http://pypi.python.org/pypi/unittest2/0.1.4 ><
<jjardon> Hello, Is there any command similar to "git grep" in bzr?
<mgolisch> bzr grep? but i dont think its builtin
<AfC> jjardon: well, if you'll tell us what `git grep` does, perhaps we can speculate whether there is a way to achieve that effect with the bzr ecosystem.
<jjardon> oh, yeah, sorry. Is similat to 'rgrep "something" *', but only search in the tracked git files
<mgolisch> quite sure i saw a plugin like that somewhere, no idea bout its state though
<mgolisch> https://code.launchpad.net/~vila/bzr/grep
<mgolisch> seems quite old though
<jjardon> mgolisch, thank you
<AfC> jjardon: there's Robert's "bzr search" plugin. I'm not sure what state that's in, but I just heard him request someone to update the packaging, so it can't be that bad
<AfC> jjardon: or, you can just do
<AfC> $ bzr ls -R | xargs grep something
<jjardon> AfC, thank you for the tip
<RyNy_> How do I found out the location of the bazaar executable on my computer? Need to tell Eclipse that to use the Eclipse Bazaar Plugin.
<RyNy_> Running Mac OS X 10.5.
<Kilroo> Does OS X have the which command?
<RyNy_> not sure?
<Kilroo> Try which bzr in a terminal and see if it says something useful.
<RyNy_> result is /usr/local/bin/bzr
<Kilroo> That's probably it then.
<Kilroo> Unless you somehow have it installed twice.
<RyNy_> makes sense, but I have to use eclipse's file browser to choose the executable and I don't see it.
<Kilroo> Odd. I could have sworn I remembered being able to type it in.
<mgolisch> still wonder why they hide those dirs
<mgolisch> :)
<mgolisch> but i would have thought that only finder cares for those strange file atributes they set to hide files
<mgolisch> or directories
<RyNy_> ok I found in the Finder. usr is a hidden directory at root
<RyNy_> Not sure if Eclipse will let me browse to a hidden directory. Don't think I can type in path either.
<dutchie> I think I'm being an idiot, but I don't understand merge conflict markers
<dutchie> in http://pastebin.com/m3a15020e say, which is the one from the branch I'm merging in?
<Peng> dutchie: ISTM it's the second one.
<Peng> dutchie: "TREE" refers to what you had in the working tree before the merge, so "MERGE-SOURCE" would have to be the branch you're merging in.
<Peng> dutchie: Probably.
<Peng> dutchie: Usually it's easy to tell from the code. :P
<dutchie> yeah, it's a bit harder when it's po files for a language I can't read
<Peng> Fun.
<jml> lifeless, yeah, I've been following on twitter but haven't had a chance to analyze it.
<Peng> Maybe you should tell the translator to fix it.
<Peng> jml: Eh, what's on Twitter?
<jml> Peng: unittest2 -- Michael Foord has been talking about it
<dutchie> http://pastebin.com/m22be8358
<dutchie> lots of arabic
<dutchie> but it seems to have disappeared in MERGE_SOUCE
<dutchie> bah, MERGE-SOURCE
<Peng> dutchie: And it's escaped, too... Awesome.
<dutchie> that's pastebin's fault
<dutchie> I can see it fine in my editor
<Peng> Oh. Even more awesome.
<maxb> jelmer: Hi, what is the difference in purpose between your trunk and trunk-mirrored branches of bzr-rebase on people.samba.org ?
<maxb> jelmer: Also, perhaps the time has come to finish the bzr-rebase -> bzr-rewrite rename and end the confusion?
<fullermd> So, you want to rewrite the rebase rename?
<maxb> huh?
<maxb> And I think I've answered my first question, by discovering that Launchpad won't let you register a remote URL as both a remote branch and a mirrored branch
<fullermd> Oh, don't mine me, I'm just playing with prefixes.
 * maxb cheats, and composes an URL which is unequal yet functionally identical
<jelmer> maxb: The package needs to be renamed in Debian first..
<jelmer> maxb: I haven't had time to take care of that yet
<maxb> jelmer: Why is renaming the Debian package a prerequisite to finishing the rename in the upstream project?
<ed-209> I seem to be getting this error, ERROR: The user name ed-209 is not registered on Launchpad
<ed-209> when I do a: bzr launchpad-login ed-209
<ed-209> but I am registered at launchpad with that username
<ed-209> this is 2.0.4
<maxb> ed-209: In fact, no, you are not registered at Launchpad with that name
<ed-209> oh thats the dumb screen name
<lifeless> moin
#bzr 2010-02-14
<wkharold> test
<josh_k> is it possible to bzr branch a subdirectory of a project?
<Peng> josh_k: Not really.
<josh_k> Peng yeah
<josh_k> figuring out I need to make separate branches
* maxb changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0rc2 and 2.0.4 have gone gold
<maxb> Has a date been set for 2.1.0 final?
<fbond> TEST
<fbond> Disregard, etc.
<vish> guys the latest bzr update broke dependencies for bzr-gtk
<Peng> bzr update where? The PPA?
<Peng> (Not that I can help, but I'm curious, at least.)
<vish> "bzr-gtk: Depends: bzr (< 2.1~) but 2.1.0~rc2-1 is installed."
<vish> Peng: there is a ppa?
<Peng> https://launchpad.net/~bzr/+archive/ppa and a couple others (~bzr-beta-ppa and a nightly one), but you shouldn't expect the dependencies to be perfect there, either.
<vish> hmm , there is no bzr-gtk for Lucid :(   bzr update was uploaded by james_w or maxb ..
<maxb> Huh? I don't have access to bzr PPAs
<vish> maxb: nah , the Lucid update , it mentioned your name :)
<maxb> um, really!?
<vish> maxb: i think it was wrt something about untangling the bzr-tools
<maxb> That was bzr-builddeb
<vish> ah right ...
<vish> maybe the bzr-gtk needs to bump dependencies
<vish> anyone know how to force a package to install?
<vish> ignore dependencies rather
<maxb> It's not worth it, you'll end up with a permanently upset apt until you fix the dependency issue
<vish> maxb: yeah , i wanted to mainly check if the -gtk worked with the new bzr [or i'm just being plain crazy ;)  ]
<vish> it was just an idea :)
<maxb> Just bzr branch it into ~/.bazaar/plugins/, much easier
<vish> ah.. will give it a try
<geser> Hello, is the fix for bug #515597 supposed to be included in the bzr package in lucid (2.1.0~rc2-1)?
<ubottu> Launchpad bug 515597 in bzr "TypeError: merge_text() takes exactly 2 arguments (3 given)" [Critical,Fix released] https://launchpad.net/bugs/515597
<spiv> geser: I'd guess no
<spiv> geser: it was fixed just after 2.1.0rc2 in upstream according to the NEWS file
<geser> spiv: how to proceed? wait for the next rc or apply the change on the package in lucid?
<maxb> Surely 2.1.0 final is due any day now?
<spiv> geser: not sure
<spiv> geser: on one hand as maxb says probably the next release will happen soon (although I don't remember the exact schedule)
<spiv> geser: but if you wanted to make a 2.1.0~rc2+r4812 or something in the meantime, I don't see any harm
<spiv> geser: (in addition to the fix for #515597, there are a few other fixes, of which #513432 is probably also pretty important)
<geser> spiv: I don't know how much that bug affects the bzr usage but there is already a bug filed about the bzr package in lucid: bug #521546
<ubottu> Launchpad bug 521546 in bzr "TypeError: merge_text() takes exactly 2 arguments (3 given)" [Undecided,New] https://launchpad.net/bugs/521546
<spiv> geser: I haven't looked closely, but probably only affects custom merge hooks
<spiv> geser: i.e. the 'news_merge' plugin that's now distributed with bzr (but not enabled by default), and the merge hook in bzr-builddeb for debian/changelog files
<spiv> geser: that latter case is going to hit ubuntu devs pretty hard though
<rioch> I'm about to create my first release in a project. Should I branch my code?
<mathrick> rioch: that's not a bad idea, but at least tagging would be good
<mathrick> something to identify unambiguously the revision you released
<mathrick> branching depends on whether you intend to support the release further, or only make new releases
<rioch> mathrick: well the way I see it is, I might want to fix a serious bug, without disrupting new development
<rioch> and im not sure of the difference between a tag and a branch
<mathrick> tag is jus a descriptive label attached to a particular revision
<mathrick> so you can go back to it later and know precisely where you released
<mathrick> a branch is, well, a branch, a separate line of history
<mathrick> it's possible to tag now, with the expectation you might not need anything else, and branch only when you actually need to fix something
<mathrick> if you tag, you won't have any problems going back to that point later on
<rioch> mathrick: ok. so is that possible using launchpad?
<mathrick> tagging? Sure, lpad only keeps your history, and understands tags too
<mathrick> rioch: bzr help tag
<mathrick> then push
<mathrick> if you ever need to go back and branch, bzr branch -r tag:RELEASE_1_0 ~/project
<mathrick> then you push it again to launchpad and have a new branch exactly at the point you released 1.0
<rioch> that would mean I always develop in the trunk branch, tag my releases, and then if I need to bugfix a release, I grab the related tag and create a branch out of it.
<rioch> does that seem sensible/correct?
<mathrick> yes, that's exactly what I proposed
<rioch> it seems good to me :)
<mathrick> rioch: you can mix it freely, too. For instance, pre-2.0 developer releases will only need tags, because you don't intend to support them. So you tag 1.9a1, 1.9a2, 1.9b1, 1.9rc etc, then once you have released and tagged 2.0, you can branch it because it's gonna be more persistent
<rioch> so you mean branch and tag major releases?
<mathrick> or something, whatever fits your project
<mathrick> as long as you have them tagged, you can always go back
<mathrick> the problem with DVCS isn't branching, it's accurately recreating the chronological order of events
<mathrick> and that's what tags help with
<rioch> So tagging is important. Got it. :)
<mathrick> yeah, if you make formal releases, then you really want to tag
<rioch> I was thinking of having a branch for each major release, and what you mentioned about tagging pre-releases seems like a smart idea, but it seems that I'd end up with a lot of branches which wouldn't be used.
<mathrick> it's pretty embarassing to go back to a release two months later and be unable to identify which revision you released it from
<mathrick> rioch: that's why you only tag them. Tags by themselves don't do anything, they just stick to a revision and can be read
<mathrick> so you keep your history linear when possible, and only go back and branch to releases you actually need to support
<mathrick> prereleases are obviously not supposed to be supported, so nothing more is needed
<rioch> I think I will do that. I suppose the confusion for me is trying to align it with launchpad. I want to release a beta version, but there is no separate branch for it, so I tag it...
<mathrick> yes, and launchpad understands tags, so it'll show you that they exist
<rioch> So at the moment, I've set a milestone to released and uploaded the files for download. Now I can just go and tag it and it's done?
<mathrick> yup
<mathrick> just push to lpad afterwards to have it receive the tag you created
<rioch> here goes :s
<rioch> How can I check if it worked? bzr said: no new revisions to push.
<mathrick> rioch: bzr log lpad:myproject
<mathrick> it should have Tags: RELEASE_1_0 or whatever you called it next to the revision you tagged
<rioch> hmmm nothing there
<rioch> All I did was bzr tag pumped-0.1 and then bzr push lp:pumped
<rioch> was that correct?
<mathrick> yes
<rioch> if I do bzr tags, I can see it listed for revision 17 (latest revision)
<rioch> let me see if I can get the tag
<mathrick> ------------------------------------------------------------
<mathrick> revno: 17
<mathrick> tags: pumped-0.1
<mathrick> committer: Jon Black (jon@pumped.nl)
<mathrick> branch nick: pumped
<mathrick> timestamp: Sun 2010-02-14 13:10:12 +0100
<mathrick> message:
<mathrick>   fixed setup.py to copy glade files
<mathrick> oops, sorry for pasting
<mathrick> still
<mathrick> rioch: it's usually a good idea to make a commit just for the release, stating that in the commit message, and attach the tag to it
<mathrick> it's a bit easier to read this way
<rioch> yeah, I think I'll do that next time.
<rioch> but it worked, so I'm happy.
<rioch> This means I can carry on coding and always get that version back from bzr, and if I need to, create a branch from it?
<mathrick> yup
<rioch> great. thank you so much for helping.
<mathrick> you're welcome
<rioch> another question, more launchpad related. Can two series point to the same branch?
<mathrick> no idea
<mathrick> rioch: oh, and regarding the workflow, if you find yourself going back and branching more than you expected, you might want to reverse the workflow and start branching eagerly, and then splitting clearly bufgixing work from development
<mathrick> with bugfixing happening on release branches and then being backported to trunk
<mathrick> this way you'll avoid headaches when you commit a bugfix to trunk, and then can't pull it to release branch because it doesn't have the preceding commit
<mathrick> in fact, doing bugfixes on branches first is a good idea in general for precisely this reason
<rioch> meaning I should always branch first before fixing
<rioch> I think I will only ever need to branch when the bug is so important that it can't wait for the next release.
<rioch> I don't expect that to be very often.
<mathrick> yes, and work on the branch first. So if you find a bug in pumped-0.1, you go: bzr branch -r tag:pumped-0.1, then go to the branch, fix it there, and only then merge trunk with the branch
<mathrick> rioch: fair enough
<mathrick> just remember doing it in this order will give you cleaner merges without the need for cherrypicking
<rioch> when you say "go to the branch", you mean the newly created branch for that bug fix
<mathrick> well, newly created branch for pumped-0.1
<rioch> yeah
<mathrick> if you find another one, you don't need to branch again, you just fix it there
<mathrick> and backport (well, forward-port) to trunk again
<rioch> I'm not looking forward to doing this in practice :)
<rioch> I think I'll save this chat for reference. lol.
<mathrick> nah, it's pretty trivial once you have a clear mental picture of how it works
<mathrick> it's just understanding how the history graphs behave
<mathrick> bzr operates on tree states as the fundamental items, so all patches necessarily depend on everything before them
<mathrick> darcs for instance doesn't, having patches as the fundamental unit, so there branches just happen incidentally and you'll usually be able to move an unrelated bugfix easily if it didn't touch the parts that have changed
<mathrick> but darcs has a horrible UI
<rioch> getting that mental picture is the part that makes me nervous.
<mathrick> btw, bzr people here: how difficult would it be to create something similar on top of bzr? http://github.com/droundy/iolaus
<mathrick> rioch: it's just practice
<gerard_> praise to everyone who made bzr-svn possible
<gerard_> it's wonderful! :)
<goundy> gerard_, lol you're right I remember when I used it. it's so greate :Â°)
<jelmer> gerard_: Thanks!
<gerard_> jelmer: you're the (main) author right?
<gerard_> really great that I could just get trunk from the launchpad mirror and then only download the extra revisions for another branch
<gerard_> it works much much better than git-svn
<gerard_> the fact that I can just push to svn... mmmm... :)
<mtaylor> bzr seems to think that one of my files is a binary file... is there a way to convince it otherwise?
<gerard_> mtaylor: remove the NUL char?
<mtaylor> gerard_: hrm...
<maxb> bzr-svn is great, it's true. Though it suffers rather, speed-wise, when pointed at a 380k revision svn repository
<gerard_> maxb: yeah, but I think we can blame that on svn
<maxb> My cache.tdb alone is 250MB
<maxb> mm... it would be nice if bzr-svn could ignore the revisions not related to the project I'm operating on
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.0final rsn
<lifeless> technical term ?
* lifeless changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.0final releasing soon!
<dutchie> is there a merge algorithm that just uses the one from the tree being merged?
<lifeless> dutchie: you could write a per-file hook in 2.1 to do that on selected file (or all files if you want... )
<mwhudson> jelmer: ping
<dutchie> lifeless: hmm, don't think it's quite work it, when I can just move the .OTHER file on top of it
<dutchie> just wondered if there was an easy built in way
<lifeless> yes
<poolie> dutchie: vila is likely to add that in his resolve work
<lifeless> you can write a per-file merge hook in bzr 2.1 :)
<poolie> i don't think it's landed yet
<poolie> "easy" means something different for lifeless
<poolie> :)
<dutchie> I can't be bothered faffing about updating to a non-distro version when I can do it in one line with find
<lifeless> poolie: I think dutchie means 'discard local changes always' not 'discard on conflicts'
<lifeless> dutchie: do you mean that ?
<dutchie> is there a difference?
<lifeless> dutchie: a huge one
<dutchie> ah yes, so there is
<poolie> if you mean that then you should say
<poolie> 'bzr revert -rbranch:../otherthing .'
 * dutchie ponders
<poolie> after doing the merge, before committing
<dutchie> I think I want a true merge, but discard local on conflicts
<maxb> That seems an odd thing to want.
<maxb> Either the local changes are valuable or they are not.
<lifeless> I think we need a new hook to satisfy that really nicely
<dutchie> I'm merging in translations from launchpad; most of them come from the remote branch I'm merging in, but some are done to the branch directly in the mainline
<dutchie> I can't really resolve conflicts manually, as I don't know what the words actually mean
<dutchie> so I'm just using the translation from LP
<lifeless> and having poke at it it willbe a little complex to do nicely
<lifeless> conflicts aren't trivially accessible mid-flight, and the built in merge doesn't use the generic conflict return value.
<lifeless> thats something we can improve though
<thrashold> Can anyone suggest a standard .bzrignore for autoconf projects that I can use as a basis for mine?
<lifeless> there should be a decent on in lp:libcpuinfo
<thrashold> Thank you very much
<malibu> I'm wondering if someone can help me out... Something has gone horribly wrong with my bzr working copy... I get a memory error when I commit it and it's stuck
<malibu> are there any commands I can do to kind of clear it out?
<Peng> You get a MemoryError? Do you have any extremely large files? Or a ton of files?
<Peng> Or are you on SunOS?
<mwhudson> james_w: wow that email about branch formats DoSes thunderbird quite effectively
<james_w> nice
<Peng> Eek, what email? I use Thunderbird.
<mathrick> how difficult would it be to create something similar on top of bzr? http://github.com/droundy/iolaus
<fullermd> Peng: Only if you're on SunOS   :p
<mwhudson> Peng: on the udd list
<mathrick> this being darcs-on-git
<lifeless> mathrick: what bzr version
<lifeless> Peng: its on udd
<mathrick> lifeless: did you mean malibu?
<lifeless> mathrick: I did, sorry.
<lifeless> and to answer the question, fairly easy
<lifeless> malibu: what bzr version
<mathrick> and would that have a chance of working properly with everything else built with bzr?
<lifeless> sure, I mean it depends on what you do ;)
<lifeless> looms for example work very well with everything else, and they provide a custom branch format- they are a deepish extension to map packaging into bzr
<lifeless> bbs
<malibu> Peng, Define extremely large.. Largest file is about 120Mb
<malibu> bzr 2.0.1
<Peng> malibu: It's not surprising that bzr would use several hundred MB of RAM, then.
<malibu> Peng, really.. that sucks
<lifeless> malibu: git., hg, bzr - they all do this
<lifeless> 2-3 copies of the file in memory is needed to do diff/merge/etc
<malibu> Yeah I went with bzr because I need lightweight
<lifeless> malibu: just saying, its a limitation all the current open source DVCS tools have
<malibu> right, I understand.
<malibu> I'm just looking to do a dropbox kind of thing without dropbox
<malibu> And bzr seems to be the only one that has a minimal local working copy size
<malibu> *sigh* I guess I will look for something else
<mathrick> lifeless: that sounds very nice. Honestly the incidental branches are the only thing I miss from darcs
<mathrick> as I already have interactive commits
<mathrick> lifeless: oh, and does "depends on what you do" also include log viewers not going bonkers when you do that? :)
<bob2> malibu: tahoe-lafs is a lot more like dropbox than a dvcs is
<poolie> malibu, or you could use unison
<malibu> I was just looking at a page on unison actually
<malibu> I was leaning towards just using rsync + a lightweight incremental backup tool
<malibu> Which maybe is kind of what unison is
<malibu> bob2: tahoe-lafs.. I will look that up
<malibu> bob2: Ick.. my whole intention is to avoid 'the cloud'
#bzr 2011-02-07
<damd> hi.
<damd> i can't push because there is a lock caused by me C-c'ing out of an earlier push
<damd> bzr break-lock does nothing
<damd> any ideas?
<mwhudson> damd: try bzr break-lock :push
<spiv> mwhudson: beat me to it :)
<damd> ah, thanks
<inada-n> mathrick: bzr-git can use dulwich from plugins/git/_lib/dulwich
<poolie> hi inada-n, spiv
<mathrick> inada-n: ah, that's useful
<mathrick> does it hold true for other plugins too?
<spiv> Hmm, 'perf top' during a parallel selftest run claims ~10% of the time is spent during deque_ass_item.
<spiv> Perhaps just a measurement artefact?
<spiv> grep doesn't show any obvious places that do 'some_deque[foo] = ...'
<mwhudson> could be in subunit?
<spiv> mwhudson: I grepped, bzrlib, subunit and testtools
<mwhudson> ah
<spiv> I'm assuming that python only invokes the sq_ass_item slot in the obvious case of sq[item] = value
<spiv> Anyway, it's probably nothing I can quickly improve while getting actual work done... :)
<pbouf77> Trying to setup the bzr_access script. When I try to do a test bzr co bzr+ssh://bzr@server/trunk, it asks me for a password..
<spiv> pbouf77: but you expected publickey auth?
<spiv> pbouf77: I'd try 'ssh -v -l bzr server' to double-check how the SSH client is trying to auth (assuming you are using OpenSSH as the SSH client)
<spiv> pbouf77: and also check that the permissions on ~/.ssh and its contents are sufficiently restricted, sshd will probably ignore them if not, although it will hopefully log about it somewhere if that's the case
<pbouf77> spiv: yeah publickey. Ok I tried your command, I'm not sure how to interpret the output though
<spiv> pbouf77: basically look for lines about 'publickey' or 'trying key ...' and see if what's it's doing (or not doing) matches what you expect
<spiv> pbouf77: e.g. if the client is never trying any key, that's a clue :)
 * spiv -> late lunch
<pbouf77> the bzr user's .ssh dir has perms drwx------
<pbouf77> It does seem to be trying keys, "Offering public key: ..." shows up a couple of times, then "Trying private key: ..." then it tries password
<pbouf77> also the authorized_keys file has perms -rw-------
<poolie> pbouf77, have a look in auth.log
<pbouf77> nothing gets added to that log when I try the ssh -v -l bzr server command..
<poolie> that's /var/log/auth.log
<poolie> really?
<poolie> that'd be on the server, not on the client
<pbouf77> yep
<pbouf77> checked client too for good measure though ;)
<pbouf77> arrgh. Ok, I think I see what happened. Serves me right for using pico instead of vim.
<pbouf77> somehow my publickey got linebreaks added when I pasted it in
<pbouf77> so now I can get as far as "bzr: ERROR: Not a branch: ...". I'm just happy to see a different error message though. :)
<pbouf77> ... and that one was much easier to overcome. Looks like I'm on my way.
<pbouf77> Thx all for the help.
<vila> hi all !
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.2.4 and 2.3.0 are frozen. Release plugins ! Build installers ! (rm vila)
<poolie> hi vila, how are you
<vila> fine ! the package importer had some troubles this night ?
<poolie> over the weekend
<poolie> james shut it down; i sent a mail
<poolie> we should get it up again
<vila> "we" == losas, is "when" known ?
 * fullermd waves at vila.
<poolie> spiv, i just noticed https://bugs.launchpad.net/bzr/+bug/401646 which seems a lot like the other things you did
<vila> fullermd: so, did you test bookmarks with 2.3 ?
<fullermd> Insofar as "it doesn't crash anymore, and one of 'em seemed to resolve correctly.
<vila> k
<fullermd> So, is 2.3 expected to be all peachy with py2.7?
<vila> peachy ?
<fullermd> Happy.  Solid and unproblematic.
<vila> python 2.7 is the default in natty, 2.3 is targeted at natty, if they don't fit, they will be fixed :)
<fullermd> Cool.
<fullermd> Plan apparently is to move to 2.7 default on FreeBSD in ~March.
<vila> the full test suite has been passing for quite some time and the betas were deployed there, so I'm pretty confident we'll know soon enough if anything *new* breaks
<vila> Debian releasing, FreeBSD using python2.7 before Ubuntu, what's next ?
<fullermd> You know Duke Nukem Forever is coming out, right?   ;)
<vila> That's it, I can relax now, just a bad dream...
<fullermd> "[...] on May 3, 2011 in North America and May 6, 2011 internationally!"
<vila> Seeing is believing
<fullermd> That means we're running out of time to port bzr to perl 6...
<vila> bah, you always say that and then you actually stop sleeping at night and get things done...
<poolie> ok i might call it a night
<vila> . o O (how timely ;)
<poolie> see you later guys
<vila> poolie: see you
<poolie> vila can you try to work out about getting the package-importer going?
<vila> poolie: it's quite unclear to me at the moment *when* this should be restarted
<vila> poolie: did the packaging branches got re-stacked yet ?
<vila> poolie: should we restart on jubany ?
<fullermd> Sadly, work leaves me no sleep to stop taking...
<vila> I think you're on the right track... 1) stop working .... 4) profit... err wait
<spiv> poolie: (even though you're not here) it is!  I'll queue it up, may as well fix that class of things thoroughly.
<jelmer> hey spiv, vila, fullermd
<vila> heya jelmer !
<spiv> jelmer: hey :)
<spiv> jelmer: I made https://code.launchpad.net/~vcs-imports/vim/trunk today (they seem to have switched from svn to hg), should I go ahead and make it the dev focus?  (I'm guessing you're more up-to-date on the code import stuff than me...)
<jelmer> spiv: Yeah, please do :)
<spiv> jelmer: done, thanks :)
<wgrant> Unstacking can be achieved just by opening the branch and calling set_stacked_on_url(None), right?
<wgrant> It seems to work, but I am probably missing something crucial.
<vila> wgrant: some revisions may need to copied from one repository to the other ?
<vila> s/to copied/to be copied/
<wgrant> vila: Doesn't that method do that?
<wgrant> At least it takes forever over HPSS.
<wgrant> Yeah, it populates the repository.
<vila> oh, if it takes forever, there are good changes it does it indeed :-/
<wgrant> But I have a script we can run on crowberry to do it all quickly for sid.
<wgrant> Since hpss unstacking is far too slow, even from the DC.
<vila> wgrant: ha, great, I wasn't sure you were working in that, yes, that's what should be done
<wgrant> http://pastebin.ubuntu.com/563762/
<vila> s!in that!in/on that!
<wgrant> Well, it was going to be tiny, so I thought I might as well try.
<vila> wgrant: sounds correct, but I don't know lp internals :-/
<vila> wgrant: I'm a bit surprised you need to set 'stacked_on' on both objects though...
<wgrant> vila: Right, but I was wondering about bzr internals.
<wgrant> set_stacked_on_url seems to handle the locking stuff itself.
<vila> wgrant: yes, it has a @needs_write_lock
<vila> wgrant: I think you should add some comments in that scripts (at least explaining the overall intent) and fire a mp against lp:udd
<vila> wgrant: even if we don't use it until the next debian release, that will still keep track of the packaging branches layout
<vila> wgrant: and keep us informed about how this script is going on and when it ends so we can restart the package importer ?
<vila> wgrant: but first of all: thanks for your help here (my god, where are my manners...)
<wgrant> vila: It probably belongs in the LP tree, given that it needs to be run on crowberry.
<vila> wgrant: right, it needs to be run on crowberry, but how a newcomer (on lp or udd) will know that ?
<vila> wgrant: i.e. won't it  be lost in the lp tree ?
<lifeless> if its going to run on crowberry, it should be in the project that has the code fro running on crowberry :)
<vila> Oh, I thought that was what dependencies were about...
<lifeless> vila: this is an lp script, using internal lp modules
<lifeless> we don't publish that as an API - and won't for the forseeable future
<vila> fair enough, I'm just trying to track important bits regarding package importer sanity
<vila> wgrant: any news ?
<wgrant> vila: Apparently we are going to turn the importer back on, let it push up 22000 new branches, and clean up afterwards.
<vila> *blink*
<wgrant> Hopefully neither jubany nor crowberry will explode :)
<jelmer> hmm, stacked branches don't support directory service lookups?
<jelmer> I can't stack onto "lp:gedit"
<maxb> jelmer: no, and even more annoying, LP doesn't support stacking on bazaar.launchpad.net/+branch/... either
<jelmer> statik
<jelmer> argh
<jelmer> sorry, wrong mouse button
<jelmer> vila: LarstiQ sends his regards
<vila> jelmer: \o/
<vila> jelmer: please proxy my best regards too ;)
<jelmer> will do :)
<jelmer> vila: is there a 2.3.1 planned yet?
<vila> yes
<jelmer> for when?
<vila> but, like in a month
<vila> ha, just a sec
<vila> 2011-03-03 so far, err, no wait, I'll be in vacations :-.
<vila> jelmer: well, dunno how we'll do it, but around this date anyway
<jelmer> vila: that gives me a good enough idea, thanks :)
<jelmer> vila: I found out there were quite a few bzr-gtk MPs that had been sitting there for more than half a year :-/
<vila> jelmer: yeah, I saw the mails :-/
<maxb> jelmer: Oh, speaking of bzr-gtk, we should make sure that the missing-credits.pickle-in-tarball bug doesn't recur this release.
<jelmer> yeah :/
<maxb> Personally I was thinking of just checking a copy into the branch, disabling all the automatic updating, and putting it on a release checklist to update it manually
<jelmer> I think it might make sense to require it being run upon commits in trunk
<jelmer> but yeah, checking it in seems reasonable
<maxb> The problem with requiring it run upon commits to trunk is then every normal commit to trunk has to be followed by a credits.pickle update.
<jelmer> the merge commit can include it
<Buttons840> i have a .../level_a/level_b/...   the files/folders in level_b are revisioned, but i would now like to revision level_a while maintaining the changes to level_b?
<GaryvdM> Buttons840: create branch at a, bzr join; commit, add a, commit
<GaryvdM> jelmer: ping
<GaryvdM> Buttons840: bzr join being the key...
<jelmer> GaryvdM: hi
<GaryvdM> Hi jelmer
<GaryvdM> I want to ask, what version of bzr-svn should I use for bzr 2.3.0 windows installer.
<GaryvdM> Latest from trunk (r3515) or r3475, as used in debian?
<GaryvdM> jelmer ^
<jelmer> GaryvdM: that's a good question
<jelmer> I guess current trunk
<GaryvdM> Ok
<GaryvdM> And I'll do another build if you do a release. :-)
<maxb> I wonder when we should push 2.3.0 out to the Ubuntu PPA.
<GaryvdM> Hi maxb
<GaryvdM> What plugins in the ppa are not compatible with 2.3 yet?
<maxb> They're all compatible, but for some of them that's by being snapshots
<GaryvdM> By snapshots, do you mean revision from trunk, rather than release version?
<maxb> yes
<maxb> bzr-fastimport (and python-fastimport)
<maxb> bzr-gtk
<maxb> bzr-loom
<maxb> bzr-rewrite
<maxb> bzr-svn
<maxb> are the snapshot versions
<GaryvdM> Then IMO, I'm sure it ok.
<bbutz> I think I'm using reverse cherrypicking wrong
<bbutz> I'll reverse merge a feature branch out of my trunk, and then I won't ever be able to merge that branch back in
<awilkins> bbutz, If you've already merged the branch, it's not going to do it again (automatically)
<awilkins> bbutz, You could cherry-pick it back in again :-)
<bbutz> awilkins: was thinking about doing that, but now sad that all the branches I've made off trunk since are having some sense of the reverse merge and causing trouble
<cbz> does bzr have an equivalent to svn:externals?
<jelmer> cbz: not in the core, but there are some plugins that provide similar functionality
<jelmer> e.g. the bzr-externals plugin
<cbz> Okay, i'll take a look.
<cbz> Also, is there some documentation on bzr internals? (I'm thinking similiar to the internals discussions in the mercurial and progit books)
<cbz> Just t rying to understand the bzr conceptual model a little bit better
<jelmer> cbz: there are some in the developers docs, in doc/developer in the source distribution
<jelmer> g'morning poolie
<jelmer> hi jam
<jam> hi jelmerr, not around for a lot longer. but good to say hi :)
<cbz> Thanks. I just wondered why none of the bazaar documentation doesn't include it (whereas in hg, you get a fairly detailed discussion of revlogs and filelogs)
<jam> have a feverish son sitting in my lap while I type. Apparently I'm the go-to guy for fever. He won't sit with my wife right now
<cbz> Similiarly git, where the progit book talks about object packs
<jam> cbz: git is built around its data format. bzr tries to abstract it away
<LeoNerd> bzr's had about 4 different data formats over the years, no? :)
<jam> for example, you can use .git as your storage back end (for some levels of fidelity)
<cbz> Okay, but even if it abstracts it away, isn't the abstract 'format' itself worth knowing, to understand how bzr works in a bit more detail?
<jelmer> jam: :)
<jam> cbz: pydoc bzrlib.repository.Repository ?
<cbz> I'll take a look thanks.
<poolie> hi jam
<poolie> sorry k is ill
<jam> poolie: yeah.
<cbz> hmm.
 * jelmer frees his hands of plates
<jelmer> jam: That came out wrong, I was smiling to your greeting. I'm sorry to hear he's sick too :-/
<jam> jelmer: I thought you were smiling about using .git as the back end. so no hard feelings here :)
<jelmer> jam: heh, ok. Just making sure :)
<jelmer> Anyway, I'd better be off too
<jelmer> jam: See you later, and I hope he gets well soon
<jam> have a good night, jelmer
<spiv> cbz: I just landed a little bit more about that in the dev docs yesterday, it's in http://doc.bazaar.canonical.com/bzr.dev/developers/overview.html
<spiv> cbz: that doc is pretty abstract, and still pretty rough, but hopefully it helps
<poolie> jam i feel i must be missing the point about hook naming
<poolie> i agree about saving memory at load time, but surely this is a tiny microoptimization compared to just loading less code
<cbz> spiv: thanks, that might be better. it appears to me that by the time i've hit the Repository code, the abstraction itself has been 'lost' in favour of translating into the underlying storage model
<spiv> cbz: it depends on which operations you want to do, but generally speaking yes :/
<poolie> hi spv
<poolie> spiv, so bug 401646 looks feasible?
<ubot5> Launchpad bug 401646 in Bazaar "bzr reconfigure --unstacked should try to copy data referenced by tags" [Low,Confirmed] https://launchpad.net/bugs/401646
<spiv> poolie: I haven't looked at the code yet, but I expect it'll be able to use the infrastructure I landed yesterday
<spiv> So, probably straightforward
<poolie> cool
<kkrev> do the nested branches demonstrated in the centralized workflow tutorial contain complete copies of the source?  In our case that would be a ton of disk space.
#bzr 2011-02-08
<poolie> kkrev, url?
<poolie> do you mean on the server?
<kkrev> right on the server.  I'm asuming shared repositories don't do anything with simlinks to save space or anything like that.
<poolie> kkrev, almost all the data will be in the repository directory
<poolie> with just one copy
<poolie>  the per-branch directories will be very small
<maxb> jelmer: Concerning the removal of the bzrlib.util.configobj.configobj from the Debian package - I think we should import the system configobj to that name, as a compatibility measure. It's not unreasonable for people to consider it part of bzrlib's api
<poolie> maxb, that sounds reasonable
<GHellings> Can anyone tell of success stories with bzr-git bridge? I can only get it to work over raw git: protocols, and I'm not sure if it's me or bzr-git
<mwhudson> GHellings: what other protocols have you tried?
<GHellings> I have tried http: and git+ssh:
<mwhudson> i know there have been bugs accessing branches from github over http
<GHellings> I've been accessing gitorious over http unsuccessfully - same repo over git: is fine.
<GHellings> Just tried a different, private repo over git+ssh: and it failed with the same error
<GHellings> I'd go in to take a look, but I'd be a bull in a China shop, as I know nothing about programming bzr or its plugins
<poolie> which error?
<GHellings> bzr: ERROR: exceptions.AttributeError: 'RemoteGitRepository' object has no attribute '_git'
<poolie> looks like https://bugs.launchpad.net/bugs/706990 which is claimed to be fixed in trunk
<GHellings> Ah, I see the fix is since my comment on there. It had also claimed fixed in 0.5.2 of the release on a different report.  I'll try trunk and see how it works out.
<poolie> great
<GHellings> poolie, looks like it's working now, at least for git-import. Thanks. :)
<poolie> GHellings, great
<wgrant> spiv: Hi.
<lifeless> that thunks down to revisions.get_known_graph_ancestry
<wgrant> Yeah.
<lifeless> first thing we could do is try without the pyrex.
<james_w> are we looking at .texts .chk_bytes or what here?
<james_w> i.e. where would we expect to find a revision?
<james_w> .revisions I assume?
<wgrant> .revisions, isn't it?
<wgrant> Yeah.
<spiv> wgrant: good afternoon
<wgrant> spiv: Bug #715000 is giving Launchpad some issues.
<ubot5> Launchpad bug 715000 in Bazaar "Stacking is not fully transitive" [Undecided,New] https://launchpad.net/bugs/715000
<wgrant> In particular, 3/4 of the new wheezy branches crash half way through scanning.
<lifeless> by some, he means brick-face.
<wgrant> Brick-face?
<lifeless> 'lots of pain'
<wgrant> Ah, yes.
<wgrant> lifeless: still happens without pyrex, FWIW.
<lifeless> ok, thats good to know
<spiv> wgrant: hmm
<wgrant> http://paste.ubuntu.com/564235/
<lifeless> groupcompress.py line 1315 certainly looks like it should DTRT
<james_w> lifeless, that's a comment here, which line is it?
<lifeless>         parent_map, missing_keys = self._index.find_ancestry(keys)
<lifeless>         for fallback in self._fallback_vfs:
<lifeless>             if not missing_keys:
<james_w> right, it would do the right thing
<james_w> if self._fallback_vfs was correctly populated
<lifeless> so thats a possibility; is it not populated properly?
<james_w> my current hunch is that it adds natty as a fallback for maverick, and maverick as a fallback for lucid, when it should add both to lucid
<lifeless> vfs is 'versioned files' here.
<lifeless> so lucid -> maverick -> natty
<lifeless> ?
<lifeless> james_w: that chain should work
<james_w> right, that's the stacking chain
<lifeless> it might not be optimal, but it should work.
<lifeless> oh
<lifeless> I think I see a bug
<james_w> however, <lucid repo>.revisions._fallback_vfs is [<maverick repo>.revisions]
<lifeless> james_w: print the _fallback_vfs in maverick_repo.revisions
<james_w> [<bzrlib.groupcompress.GroupCompressVersionedFiles object at 0x8f111cc>]
<james_w> presumably natty_repo.revisions
<lifeless> yes
<james_w> and the code you pasted doesn't recurse
<lifeless> yes
<james_w> so does GroupCompressVersionedFiles._index.find_ancestry recurse()
<james_w> ?
<lifeless> no
<james_w> then there is the bug
<lifeless> it shouldn't recurse either
<lifeless> the indices are below that layer
<james_w> I would have assumed that most of this code didn't recurse at all call-sites, and just collected all the fallbacks when opening in to _fallback_vfs
<lifeless> we need to be able to figure out whats *in this repo* vs *accessible via the api*
<lifeless> each repo is mutable
<lifeless> so open is the wrong time
<lifeless> flattening at execution is probably appropriate
<lifeless> that or recursing via the public api
<james_w> ok, I'll dump what I know in the bug and someone can take on the fix
<wgrant> What should we do for now?
<wgrant> Stop the importer?
<james_w> probably a good idea
<james_w> no need to add more and more branches to clean up later
<spiv> So this is breaking the package importer?
<wgrant> The importer works fine.
<wgrant> But LP breaks when it tries to scan the branch.
<spiv> Oh, ok.
<james_w> it may break the importer at some later time though
<wgrant> Yeah.
<james_w> so we should upgrade bzr there too when we have a fix
<spiv> *nod*
<spiv> I'll upgrade the bug's importance
<wgrant> LP will probably cope for now, but we may need to knock out the problematic branches if it can't keep up.
<wgrant> Since they stay in the scan queue.
<wgrant> james_w: Have you turned off the importer?
<lifeless> spiv: loom wants to user your newer api (re tag fetching)
<lifeless> spiv: it has many tips to snarf
<james_w> wgrant, nope
<spiv> lifeless: yeah.
<poolie> hi all
<poolie> spiv, are you, are you working on that? if you want to talk i'm here
<poolie> GaryvdM, hi
<GaryvdM> Hi poolie
<GaryvdM> poolie: I'm going to look at mysql cases today
<poolie> hey
<poolie> that's a good idea
<poolie> GaryvdM, hi, did you see my pm?
<poolie> spiv, hi, are you still here?
<spiv> poolie: not yet, just got tests passing for the 'reconfigure --unstacked should copied tagged revs' though
<spiv> I'm trying to resist the temptation to start on new things while I still have other things half-done.
<poolie> good for you
<poolie> this one probably is critical so i'll look at it
<lifeless> wallyworld_: ^ btw - you'll want to hand out an rc stamp for including the fix to this in the rollout
<wallyworld_> lifeless: you saying that the rollout will require a new version of bzr?
<poolie> i'm surprised we haven't seen complaints about similar things from users, or failures in lp, before
<poolie> perhaps most people just branch and that doesn't hit it
<lifeless> poolie: we may have but not commonly enough to diagnose
<lifeless> for > 1 year the code team has been focused on applications not the core
<lifeless> (e.g. recipes)
<lifeless> wallyworld_: we have an Incident (I assume wgrant is writing it up)
<lifeless> wallyworld_: the solution requires a bzr code change; this has been latent forever.
<spiv> poolie: I think more than one level of stacking hasn't been very common in the past
<wallyworld_> lifeless: ok. we sure are going down to the wire though with last minute changes. right atm the anticipated rollout rev is in builtbot on it's way to qastaging
<lifeless> wallyworld_: if we bless an earlier rev, thats fine.
<wallyworld_> is this change something we could do with a no downtime rollout post 11.02 release?
 * spiv logs off for the day.
<lifeless> wallyworld_: we can, but what we release should be all the revs that are qa'd at the time - like if you bless N, and 5 more revs are qad by deploy time, we should deploy N+5
<lifeless> wallyworld_: the point of the rc stamp is to let this into pqm as soon as this patch is ready rather than after you reopen pqm.
<wgrant> It's not a DB change, so it doesn't really affect anything.
<lifeless> exactly
<wgrant> If it's in stable by the time we need to deploy, we can deploy it.
<lifeless> and it will get landed via ec2test :)
<wgrant> If not, we deploy a few minutes later :)
<wallyworld_> lifeless: ok. it means though that pqm will need to stay in rc mode for a bit longer until this latest change is qaed
<lifeless> wallyworld_: why?
<lifeless> wallyworld_: it only needs to stay in rc mode until the the db rev is deployable
<wallyworld_> i thought pqm stayed in rc mode until the rev to rollout was chosen?
<lifeless> wallyworld_: I think the process hasn't been fully updated; the critical section is getting a db-change rev thats deployable (which may require more revs than that)
<wgrant> Once we are OK to release we are OK to open.
<wgrant> If we can add more stuff onto the release, all the better.
<wallyworld_> since if there's a qa issue and people have landed subsequent revs, then that may be an issue?
<lifeless> the hysteria around what rev to deploy during the downtime was back when we did a months worth of qa at once
<wgrant> Since if we don't, I will just request a nodowntime deploy like an hour after the release :)
<lifeless> wallyworld_: but *once* we have the db rev ok to deploy, thats not going to be changes by more landings is it ?
<wallyworld_> no. but the db rev is merged into devel and it's the devel rev that is qa'ed for rollout, no?
<lifeless> yes thats correct
<lifeless> and consistent with what I'm saying
 * lifeless tries again
<lifeless> so qa is a pipeline
<lifeless> and the db deploy is a fixed event
<lifeless> to decrease the chance of foreign revisions interfering with fixes to the db revision
<lifeless> once we merge db-* to devel
<lifeless> we enter a critical section
<lifeless> that critical section is relaxed once the devel deployment report shows that the db-* merge is deployable
<lifeless> which might be the merge itself
<lifeless> or require the merge plus a couple of fixup revisions
<lifeless> at that point, if we open pqm, there is *nothing* a new landing can do to break the point we had qaed up to.
<lifeless> which is why we now open pqm as soon as we have a candidate we *can* deploy.
<lifeless> We we *go* to deploy, the pipeline may have advanced.
<lifeless> we should deploy the highest deployable rev (again, what the report says is ok)
<lifeless> the interaction with this bzr patch is that its sufficiently important we'd be willing to let it land during that critical section
<lifeless> [not that the patch is ready]
<lifeless> however being willing to land it during that section does not imply that the section should be extended
<wallyworld_> i guess that my point - if a new landing breaks devel and we need to do a test fix for a rev prior due to a qa issue with a prior rev, then it's messy and better that merges to devel are frozen until after the rollout rev is chosen. i guess i've always worked that way in the past - freeze all new work while the rollout rev is qa'ed and only land test fixes
<wallyworld_> but that was then and this is now
<lifeless> so what I'm saying is still consistent with that
<lifeless> once you have *a* rollout rev, you are safe.
<lifeless> *and*
<lifeless> you can choose a new rollout rev at T-60.
<lifeless> based on the deploy report.
<wallyworld_> that last bit (choosing at T-60) i think is where we differ
<lifeless> ok; why?
<wallyworld_> i guess i've been more conservative in the past - lock down the rollout rev and qa  and consider all change bad and needing justification so any changes not related to test fix for defined features in the release are  verboten
<wallyworld_> until after rollout
<wallyworld_> what happens if we choose rev 12338 (the one going to qastaging now) and someone lands a bad change? and we find at the last minute a fix is needed for rev 12336? in my scenario, we would just land the fix to 12336 without any hassle of dealing with a later rev checked in on top
<lifeless> so
<lifeless> the critical section is intended to let us *actually qa* 12336 - which has worked this month, for instance ;)
<lifeless> but taking your scenario
<lifeless> we'd just rollback 12339 at the same time as landing whatever fix (assuming 12339 also qa failed)
<wallyworld_> but doing rollback is an extra step and any extra steps potentially introduce defects/issues
<lifeless> the way we reduce the risk of the db deployment is deploying all we can before it - like wgrants nodowntime yesterdayish
<lifeless> wallyworld_: in theory yes, in practice its trivial do to a merge -r . -1..-2
<lifeless> wallyworld_: and be confident its rolling it back to a previously known ok state.
<wallyworld_> an extra step that would not be required if landings were verboten until the release rev were fully qaed
<lifeless> thats true
<wallyworld_> but i see your point tooo
<lifeless> but blocking landings is hugely expensive
<lifeless> we land 6 branches a day on avg
<wallyworld_> yes, so ones weighs up the pros and cons and perhaps your way is the better approach in terms of team velocity while still managing the risk
<lifeless> 10 per [mon-fri]
<lifeless> wallyworld_: yes, its a risk assessment problem.
<lifeless> wallyworld_: I generally prefer a risk recovery option rather than risk elimination
<wallyworld_> so now that today we finally have the db-devel rev sorted (pending a final qa) we can open up pqm again once rev 12338 lands on qastaging
<lifeless> wallyworld_: particularly with low-occurence risks
<lifeless> *once* 12338 is qa'd
<lifeless> but yes.
<wallyworld_> yes, i see your point. i think it comes down a lot to organisational culture
<lifeless> its been a bad cycle
<wallyworld_> yeah, i've been thrown in the snake pit as rm for sure :-)
<poolie> good on you for doing it though
<wallyworld_> it's been a learning experience and i'm glad i did it actually
<wallyworld_> part of the issue was last week where i'm told issues with pqm/ec2/buildbot delayed a db-devel landing, which pushed everything back
<wallyworld_> so we really need to deal with those root cause issues
<wallyworld_> if they indeed are real issues
<lifeless> yes, they did and the pqm swallowing errors bit should be fixed now
<vila> hi all
<poolie> hi vila
<vila> poolie: see my pm ?
<poolie> vila, https://wiki.ubuntu.com/DistributedDevelopment/UnderTheHood/Importer/Operational etc
<poolie> vila, i'll need to go at some point so if you get a chance please persist on 715000
<vila> poolie: don't hold your breath, I'm already working on critical stuff and if I had yet another interrupted task on top of my stack...
<vila> s/had/add/
<vila> damn tyops
<poolie> ah fair enough
<poolie> is https://devpad.canonical.com/~mbp/kanban/vila-kanban.html accurate?
<poolie> at least in the middle columns?
<vila> the in progress yes, the needs review is... not important
<vila> and yes, my current branch should address both the in progress ones (and more as I discover them ;-/)
<nil1> Hi
<nil1> My TortoiseBzr ist Polish(?), how do I change that back again?
<poolie> nil1, not sure, perhaps setting LANG in your environment then running it?
<poolie> hi sidnei
<sidnei> hi poolie!
<nil1> poolie: no that didn't help
<nil1> I opened the command line, "set LANG=C", killed explorer.exe and restartet it on the command line
<nil1> err, LANG=de
<inada-n> Please use bzr-2.3-setup.exe
 * nil1 nods
<inada-n> https://bugs.launchpad.net/tortoisebzr/+bug/663258
<inada-n> It is fixed but have not shipped with bzr-2.2.x
<nil1> okay, thanks
 * nil1 reboots
<poolie> yay, i might have fixed 715000
 * vila hugs poolie
<poolie> in some ways this is a dangerous fix
<poolie> so it might be better to do it in 2.3 and move lp to that
<poolie> or 2.4 even
<poolie> not very dangerous, but not utterly obvious not to change something else
<vila> there are other good reasons to deploy 2.4 on lp (controversial) but I think it's the right path for the coming months
<vila> poolie: you're targeting 2.2 ?1/!!
<poolie> vila, i did it based of 2.2 to keep our options open
<vila> haaa, pfew, you scared me
<vila> yeah, good point
<vila> and good thing the bzr/2.2 branch was already opened for bugfixes
<poolie> is it even proposed yet?
<poolie> or did you just click through?
<vila> hehe, I saw the bug email and fired 'bzr-review lp:~mbp....' ;)
<poolie> ok
<poolie> if you can review it that would be nice
<poolie> maybe john should too
<poolie> ok, i think i should stop
<poolie> i'm running the whole test suite to see if this affected anything else
<vila> poolie: yup, you (I?) should probably do that after merging up, spiv modified fetch and there may be fallouts there
<poolie> i think it's important we check for similar problems
<poolie> and ideally match them up to bugs
<poolie> but i'm running out of steam
<spiv> poolie: quick review sent
<vila> jelmer: about review: :D and thanks
<jelmer> you're welcome, glad I can return the favor(s) :)
<vila> jelmer: hmm, what needs to be done to get 2.3.0 on natty ?
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.2.4 officially released, 2.3.0 frozen. Release plugins ! Build installers ! (rm vila)
<jelmer> vila: There's already a sync request in progress
 * jelmer looks for the bug #
<vila> jelmer: good enough !
<vila> thanks !
<jelmer> bug 713038
<ubot5> Launchpad bug 713038 in bzr (Ubuntu) "Sync bzr 2.3.0-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/713038
<vila> rhaaa ! I read the related mails ! I knew ! What else will I forget next ? :D
<jelmer> (:
<maxb> jelmer: oh, hi. I think we should put back bzrlib.util.configobj and .elementtree in the debian package, as imports of the system versions. Does that sound sensible to you, or did you explicitly choose not to?
<jelmer> maxb: hmm, that's a good question
<jelmer> maxb: on the one hand I think we should just have everything do the right thing and patch it to use configobj
<jelmer> on the other hand, pragmatism is useful too
<maxb> I am mainly working on the basis that it's something included in bzrlib.*, so it's kind-of part of the bzrlib api
<jelmer> maxb: the configobj from the system is a different version and has slightly different semantics, etc
<maxb> The situation is further confused by bzrlib's in-tree configobj being slightly modified
<spiv> jelmer: just add "sys.modules['bzrlib.util.configobj'] = __import__('configobj')" to bzrlib/__init__.py ;)
<maxb> spiv: Don't be evil :-)
 * spiv wanders off to bed before he can do any real damage
<maxb> Direct users of bzrlib.util.configobj that I can find are fastimport gtk loggerhead and qbzr
<vila> maxb: evil plugins
<maxb> who says that bzrlib.util.* is off limits to plugins?
<maxb> bzr-explorer conditionally uses bzrlib.util.elementtree on Python 2.4
<vila> nobody ;) But I'm curious about what they need there and why bzrlib.config is not enough
<jelmer> maxb: some are already patched to support using the system configobj
<maxb> indeed they are.
<maxb> So, I guess the real question that needs answering is "Is bzrlib.util.* part of the API?"
<vila> maxb: yes, except for configobj :-D
<vila> maxb: seriously: yes
<maxb> bzr mv bzrlib/util bzrlib/__compat__ :-)
<vila> but we should file a bug about forbidding it or provide alternatives I think (not sure and not sure I should think about that with a flu :-/)
<vila> at least the gtk case I'm looking at shouldn't use configobj
 * vila files bug #715143 and resumes
<ubot5> Launchpad bug 715143 in Bazaar GTK+ Frontends "annotate.config should use bzrlib.config not bzrlib.util.configobj" [Medium,Confirmed] https://launchpad.net/bugs/715143
<vila> ditto for fastimport and qbzr. Its less clear for loggerhead but probably true too
<GaryvdM> I agree. qbzr should not be using it. I used it because at the time, I did not know better.
<vila> yeah, I'm not throwing stones, bzrlib.config is still too hard to reuse IMHO
<vila> This was a gentle "evil plugins" :D
<jelmer> vila: thanks for the review
<vila> hehe, I'm PP !
<jelmer> vila: get_all() is different from items() in that it returns just the format objects, it doesn't return tuples with keys and values
<jelmer> did you mean values() rather than items() perhaps?
<vila> yeah
<vila> err, you're even more evil than I thougth then :)
<vila> use items and throw the keys :)
<vila> anyway, you got the point right ?
<jelmer> vila: in that case there's a slight disconnect though, as the extra formats don't have keys
<jelmer> so they would appear in values() but not in iteritems() or items()
<vila> haaa
<vila> hmm, key=None won't work either I suspect
<jelmer> vila: yeah, as most callers won't care about the non-metadir formats
<vila> I want a value that is less than None, guido ?
<jelmer> :)
<jelmer> vila: I think a separate method, different from values() makes sense here.. perhaps it just needs a better docstring?
<vila> jelmer: Is it really necessary that they don't have key ?
<vila> what is the key used for ? Can't that be an attribute instead ?
<jelmer> vila: even if they had a key, we would try to use them in cases where we couldn't
<vila> jelmer: most of the refactorings you've done in this area have been somehow to transform hard-coded references to formats into feature attributes on formats
<vila> I think this is really nice and The Right Thing
<vila> Can't the same pattern apply here ?
<vila> Since you're introducing registries, it would be nice it this was the case and that all formats can be properly registered and only from there diverge in what features they provide
<jelmer> vila: the interface here (having a format string) is already something these formats don't really have
<jelmer> vila: so I'm reluctant to expose them in the registry everywhere when they can't really be used as such
<vila> :-/
<vila> Be bold !
<jelmer> heh
<vila> Nobody is using this registry so far no ? Well, not the new one
<jelmer> vila: the class not, but the registry itself is used by lots of things
<vila> dev values(with_obsolete_stuff_yes_I_know=False) ? :-/ guido ?
<vila> bah
<jelmer> vila: that works, but that's why I'd rather add a separate method (probably with a more clearer docstring than I had earlier)
<jelmer> get_all = lambda self: self.values() + self.extra()
<vila> jelmer: yeah, will do, and clearly identify who is using it, sounds like a good case for a leading '_' too
<jelmer> vila: there's only one user of that method at the moment - bt.per_repository
<vila> good
<jelmer> vila: so improve the get_all docstring and rename remove -> unregister?
<vila> s/get_all/_get_whatever/
<vila> and unregister yes,
<jelmer> ah, ok
<vila> another dech-debt is why Registry implements remove instead of unregister...
<vila> jelmer: these are all mostly suggestions, I'm open to discussion ;)
<jelmer> vila: that's why I used remove() as well, since Registry is the base class
<vila> yeah, I was *really* surprised to find it there, most of the registries uses I've seen have some sort of unregister and unregister really is more natural to my eyes
 * jelmer is tempted to fix some registry tech debt
 * vila pushes jelmer still hearing poolie saying the same this morning 
<vila> jelmer: now I'm a bit lost... id I miss the extra-repo-formats mp earlier ? Or is it a new one ?
<vila> meh already 55 mins old >-/
<jelmer> vila: it's a new one, on top of the one we just discussed
<jelmer> ah, argh.. it doesn't have the prerequisite bit set
<vila> but it still uses remove, did you postpone that ?
<jelmer> vila: no, this branch was submitted before our discussion
<vila> haa... pfew
<jelmer> https://code.launchpad.net/~jelmer/bzr/extra-repo-formats/+merge/48932
<vila> (waiting for lp to refresh) it uses get_all  + _get_extra, how about _get_all (not sure _get_extras is really needed unless you already know better)
<vila> jelmer: right, so my question still stand, you keep using remove or you plan to rename it later ? (There are arguments both ways...)
<jelmer> vila: I plan to rename it later, along with remove in registry itself
<vila> ok, good to go then
<jelmer> thanks
<Daiben> hello
<jelmer> hi Daiben
<Daiben> is there a turorial for a bazaar server
<Daiben> i'm messing with git for 3 days and it's still not working
<Daiben> so i'm moving to bazaar
<jelmer> Daiben: what kind of Bazaar server ? just plain anonymous readonly access over TCP/IP ?
<Daiben> read write
<Daiben> yes
<Daiben> and authentication
<jelmer> Daiben: any sftp/ssh enabled machine should be sufficient
<Daiben> but how does it work
<vila> Daiben: pretty well :)
<jelmer> Daiben: see http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/server.html
<Daiben> thanks
<vila> Daiben: as long as a user can connect with ssh and find a bzr in its path, there is nothing more to configure, the bzr client will send the right command
<Daiben> oke:)
<Daiben> i need to go home now i try tonight
<Daiben> ty
<vila> Daiben: you're welcome, come back for help if needed
<vila> jam: if you're around and k leave you some time, poolie ask for your help/feedback on bug #715000, there is already a mp with some leads
<ubot5> Launchpad bug 715000 in Bazaar "Stacking is not fully transitive" [Critical,In progress] https://launchpad.net/bugs/715000
<vila> jelmer: the bzr daily builds failing are unrelated to the sync for 2.3.0 right ?
<jelmer> vila: that's a good question
 * jelmer looks
<jelmer> vila: btw, 2.3.0 just hit natty
<vila> jelmer: fails with conflict in __init__ probably because the ~debian-bazaar/bzr.unstable needs to import trunk ?
<vila> \o/
<vila> err, wait, whatdyoumean just hit ? rmadison doesn't see it yet
<jelmer> vila: jriddell just uploaded it, it's probably not been published yet
<vila> ha, ok, thanks for the timely feedback ;D
<jelmer> vila: ah, right.. I need to fix that conflict
<maxb> vila, jelmer: the bzr dailys are failing because of a trivial conflict. We need to merge 2.3 to bzr.dev after any version bump on 2.3, to make the recipe merge cleanly
<maxb> And we need to have a recipe-fixing-blitz
<jelmer> yeah - either that, or we need to merge it into the unstable branch
<jelmer> I've been looking at ways to make it easier to look after the recipes
<jelmer> but there aren't any web service API calls atm
<maxb> oh, and we need to sync-request qbzr
<vila> maxb, jelmer: fwiw 2.3.1dev has been merged to bzr.dev today
<jelmer> maxb: which version of qbzr?
<maxb> ooh
<maxb> 0.20
 * maxb requests a recipe build
<jelmer> that's already in natty
<maxb> ah. people are too efficient for me to keep up :-)
<vila> hehe, for once :D
<maxb> oh, boo
<maxb> now application of patch 01_test_locale fails the recipe build
<mgz> what is said patch? sounds interesting.
<vila> mgz: already merged in trunk ;)
<vila> mgz: you'll know if you weren't running such an old bzr ;-D
<vila> by the way, remind me my you're still on 2.1 ? What is missing in trunck to get you back there ?
<mgz> ...it's a little funny.
<mgz> testtools broke a bunch of things for me, so I'm using a rev before that was merged.
<vila> yeah, I kind of remember that, but is there still fallouts ?
<mgz> I think I have finally fixed them, and of course to test any branches I'm actually working on I need it anyway.
<mgz> so... now it's just inertia.
<vila> haaaaaaa
<vila> good, no problem with inertia :D
<vila> mgz: MOVE ! NOW !
<vila> :D
<mgz> I'm just going to do a quick review of the ~eurokang branch, I note you beat me to it.
<vila> mgz: I was wondering if there was some low hanging fruits around it...
<mgz> I'm not certain on the core change, it seems like bug 255687 isn't much of a step further.
<ubot5> Launchpad bug 255687 in Bazaar "log and annotate should work on removed files" [Medium,Confirmed] https://launchpad.net/bugs/255687
<mgz> Also various edge cases etc...
<vila> yup, probably a good idea for a followup
<mgz> but what it's actually doing looks correct, and it's a first contribution,
<mgz> so it's right to not move the goalposts.
<vila> mgz: you're reading above my shoulder right into my brain again ?
<mgz> I do try. :)
<vila> . o O (Being transparent or keep secrets... That is the question )
<mgz> I'll branch it and fiddle in a minute, the test assertion strikes me as wrong.
<mgz> ah, no, it's build_tree_contents so the file really is empty
<vila> which is fine for a bb test
<mgz> yep, but I don't think the test would actually fail without the fix
<vila> hehe, it did, I tried :-D
<mgz> ah, at the run_bzr state
<mgz> *stage
<mgz> forgot taht checks the return code.
<kkrev> I'm evaluating bazaar.  Our current tool (synergy) spits out individual file history graphically so you can see all the branch revisions and who made them: http://i.imgur.com/0uFoJ.png
<kkrev> can bzr do this?
<kkrev> it's not make or break, but it's something people are very used to.  the graph-ancestry tool seems to be just about how branches relate to each other?
<vila> kkrev: try qannotate from the bzr plugin, it displays the annotated lines in the main window but a the file graph in a smaller embedded one while maintaining the link between a line and the revision that modified it
<vila> kkrev: from the file graph view you can also request to annotate the file at this revisions or consult the diff for the file itself or the diff of the wole revisions (which helps understanding why the file was modified)
<vila> kkrev: qlog is also a real gui when it comes to navigate the revision ancestry
<kkrev> thanks.  investigating.
<kkrev> is qbzr prefered to the "Bazaar Explorer" shown in the "visual tour" linked to from the front page?
<luks> kkrev: Bazaar Explorer is built on qbzr
<vila> kkrev: both are bundled together in most of the distributions, which OS/version are you using ?
<kkrev> People would be running this stuff on windows.
<vila> kkrev: then try https://launchpad.net/bzr/+download there are all-in-one installers there
<vila> kkrev: 2.3.0 is expected to be released in two days
<kkrev> is there a good template or writeup about how to structure a repository with several past release branches and different patch series?  Do people put all the release branches under a parent repo?  I'm guessing I'd do branch per patch series and just tag the patch releases.
<kkrev> sorry if i'm spamming.
<poolie> jam
<poolie> hello jam
<spiv> Good morning
<poolie> hi spiv
<poolie> what's up for you today?
<spiv> poolie: first looking over the test changes in lp:~spiv/bzr/reconfigure-unstacked-copies-tagged-revisions-401646 before I submit that fix for review, then see if I can figure out how to reproduce https://bugs.launchpad.net/udd/+bug/653307
<poolie> nice
<poolie> do you need anything from me?
<jelmer> g'morning spiv, poolie
<poolie> hi jelmer, how are you?
<jelmer> I'm well, thanks :)
<jelmer> How is your day?
<spiv> poolie: I don't think so
<poolie> good
<poolie> i'm planning to look for more similar stacking bugs and then updated the LEP
<poolie> about build from branch into main
<spiv> poolie: oh, and I'm happy to see https://code.launchpad.net/~eurokang/bzr/537442-annotate-removed/+merge/48906 â they mailed me off-list during my patch pilot week and I provided some guidance, and they got far enough to submit a reasonable patch :)
<poolie> nice
<poolie> there are many easy but annoying bugs
<poolie> it'd be good to get more communty people into them
<poolie> jelmer, what's next for you?
<jelmer> I'm trying to get my current WIP landed - lazy hooks, non-metadir repository/branch/workingtree tests (useful for the weave plugin and foreign formats) and fixing 80% of the bzr-hg imports
<poolie> cool
<jelmer> after that, I was hoping to have a look at the bzr whoami warning that the losas were asking about, if nobody else beats me to it :)
<poolie> i was wondering if you felt bikeshedded-upon about lazy hooks?
<poolie> we should do that
<poolie> i was hoping to myself but it keeps getting interrupted
<poolie> so if i haven't got code up, please take it
<jelmer> I still have some other code to finish first too so perhaps we should see who gets to it first :)
<jelmer> I'll make sure to communicate about it if it's me.
<jelmer> poolie: I didn't really mind the lazy hooks discussion, there was other WIP I could work on, though I do agree it was bikeshedding
<poolie> i don't really understand from john's comment why this is important
<poolie> it seems like we'll register ~50 hooks; 100 bytes each is not really important
<spiv> poolie: I don't follow why it matters either
<jelmer> I don't see the performance problem either, but I also don't feel strongly either way about using tuples or strings.
<jelmer> I also noticed somebody was taking on the "bzr cp" bug..
<poolie> i saw that too
<poolie> i don't think we should block the lazy hooks thing on this
<jelmer> Should we be proactive about contacting them to discuss their implementation? I don't want to be discouraging, but I also worry about the merge discussion being disappointing further down the road otherwise.
<poolie> let's encourage them to discuss it
<poolie> perhaps we can either do it in a plugin, or in a way where it won't paint us into a corner
<jelmer> that makes sense
<wallyworld_> poolie: do you expect there will be a bzr update for the 11.02 rollout as mooted in yesterday's irc chat?
<poolie> re lazy hooks, there are other things i'd like to see before worrying about tuples vs strings
<poolie> like getting rid of per-hook-group classes
<poolie> (which will save memory and load time)
<poolie> wallyworld_, yes, there's a patch in review now
<poolie> wallyworld_, would it be easy to just run from a revision off the 2.3 branch?
<jelmer> poolie: as a prerequisite for lazy hooks landing you mean? or as an independent fix?
<wallyworld_> poolie: i guess that's up to you? afaik, we just check in the egg and update the versions.cfg so lp uses the new version
<poolie> jelmer, independently, in the same vein
<poolie> i mean, let's unblock this and do more on hooks
<jelmer> poolie: wfm :)
<poolie> and there are other things we can do that will probably do more to help memory usage and load time
#bzr 2011-02-09
<jam> hi poolie, still a bit in-and-out. K still sick, though looking better. Working a bit in the evening to make up for it.
<poolie> hi there
<poolie> glad to hear that
<poolie> so you're going pretty soon?
<jam> I probably won't be around for a long time right now
<jam> though maybe 10 min or so
<poolie> oh, i meant moving
<poolie> if you had more specific dates you could post them
<poolie> (or maybe you did)
<jam> I don't have exact dates yet. I'll post when I have more concrete stuff. Roughly late Feb. They want us to be there by March 1st, but we don't have the visas yet to actually travel.
<jam> (when applying for a work visa, you're not allowed to get a travel visa anymore, etc.)
<jam> technically, I'm not allowed into Europe until we sort through it, but it's not an issue since we don't have any plans to be there for a while.
<jam> poolie: anyway, I did do some digging, and get_known_graph_ancestry really looks to be the only api not handling recursive fallbacks, because it is the only one that doesn't recurse via a public api
<poolie> hm, and it looks like the knowngraph thing would make it a bit hard to do so?
<poolie> and adding a .update() method to them would be possible but slightly nontrivial because it has a compiled implementation
<jam> poolie: right, it is actually going via find_ancestry, though, which *is* composable, because it just returns dicts and sets
<jam> but it is an Index level api, which doesn't know about fallbacks
<jam> but if you promote find_ancestry to a VF attribute, that just thunks to self._index.find_ancestry and handles fallbacks, then get_known_graph_ancestry just becomes a thin shell over aggregating it
<jam> not that it is worth doing for older bzr's
<poolie> i was a bit concerned about the performance impacts
<poolie> do you think we could prune some of these methods?
<poolie> there seem to be a lot of similar ones
<jam> poolie: what would you prune?
<jam> I'm happy to have names changed to protect the innocent :)
<jam> I certainly wrote a fair amount of it, and I'm happy to discuss why, and open to suggestions for improvements
<poolie> i haven't got to real specifics yet
<poolie> there just seem a fair number of interfaces that give you similar data in different forms
<poolie> i think that combines poorly with having multiple implementations of a class
<poolie> because it can look like N*M different methods
<jam> poolie: so there isn't anything you can do here that you couldn't do with get_parent_map calls. The main difference is that it is just a *lot* faster when you are going to get the whole ancestry.
<jam> I would like to see leaner classes as well
<poolie> perhaps it's better to have just one method on the implementation and then wrappers that redo it
<jam> Part of that is trying to break Abstraction issues.
<poolie> as someone said in dallas (?) "Let's remember functions are pythonic too"
<jam> poolie: so the issue is that at least part of the functional code is all the way down at BtreeGraphIndex
<jam> because that is where the peek-ahead code lies
<jam> then you aggregate that up through about 4 levels of abstraction
<jam> Repository.get_known_graph calls into VF.get_known_graph_ancestry with a wrapper
<jam> which calls self._index. do something
<jam> which is actually a CombinedGraphIndex
<jam> which then needs to collect information from each actual index object
<jam> sorry, there is one more level in there
<poolie> :)
<jam> VF._index is actually a VFIndex
<jam> (GCGraphIndex, KnitGraphIndex, etc.)
<jam> poolie: and only at the VF and Repo levels do they know about fallbacks
<poolie> so jam i was hoping to provoke you into making it more obvious :)
<poolie> or deleting some stuff
<poolie> perhaps it's fine as it is
<poolie> or could just do with some discussion in the developer oveview
<jam> poolie: it doesn't help that there are also compiled vs pure python code in the stack :)
<poolie> anyhow, you're +1 on landing this change to 2.3?
<jam> poolie: yeah, fine with me for 2.3
<jam> poolie: any update on the status of lp-forking-service in production?
<jam> you were talking with spm about it, just wondering if you heard anything
<poolie> jam, it's going to be rolled out in about 21h from now
<poolie> wallyworld_ and spm will be doing it and i'll help if anything is needed
<poolie> we're going to do a dry run today
<wallyworld_> poolie: /me will be watching :-) don't know how much help i'll be
<kkrev> is there any way to concatenate revisions?  like you have three incremental revisions you want to roll together before commiting to a central repository?
<bob2> bzr-rewrite is a way
<lifeless> or just merge; revert --forget-merges
<kkrev> revert --forget-merges sounds scary.  rebase looks like the way to roll together local changes.
<kkrev> I don't think I get how this is supposed to work.  I made a branch and committed two revisions.  I say "bzr rebase" and it says "no revisions to rebase".
<kkrev> I just want to roll those two revisions into a single revision for cleaner version history.  They're incremental work on a single task.
<bob2> well, if you go back to the branch point, you can do what lifeless said (which is simple and non-scary)
<bob2> bzr-rewrite probably has a way for you to do that without moving the branch but I don't know it
<kkrev> it's a local branch off a remote repository and neither rebase nor --forget-merges seem to do anything, even if I manually specify a revision.  rebase says "no revisions to rebase".  revert just silelently doesn't do anything.
<bob2> ?
<bob2> merge needs to be run on the branch point so there is something to merge
<kkrev> bzr merge says "nothing to do".  The only changes are in the local branch (not a checkout)
<spiv> kkrev: they way to use revert --forget-merges to do this is "bzr branch trunk new-branch; cd new-branch; bzr merge ../local-changes; bzr revert --forget-merges; bzr commit"
<spiv> kkrev: (assuming 'trunk' is the branch you want to add this one new commit to, and that 'local-changes' is the branch where you have made your local commits)
<spiv> kkrev: does that make sense?
<kkrev> I think so.  if the docs were a wiki I'd paste that in.
<kkrev> all clear now.  much thanks.
<poolie> and now bug expiry kicks off
<lifeless> *boom* :P
<spiv> poolie: should the single ` in NEWS of 715000-stacking be double?
<poolie> we're a bit inconsistent
<poolie> to me it seemed better rest to use single ticks for program identifiers
<poolie> in some configurations it highlights them differently
<spiv> I think single backticks have special meaning in ReST?  http://docutils.sourceforge.net/docs/user/rst/quickref.html#inline-markup
<spiv> I guess it probably renders ok, but I get the impression from the ReST docs it's a bit semantically strange to use it like that.
<spiv> Hmm, apparently the "default default role" for single backticks without an explicit :role: suffix/prefix is http://docutils.sourceforge.net/docs/ref/rst/roles.html#title-reference
<spiv> In short: I don't think we should use `single backticks` :)
<maxb> right, 2.3.0 is out in the main PPA
<maxb> and on that note, sleeeep
<spiv> Tangentially, it'll be really nice when we can depend on just sphinx and drop the docs-plain target.
<poolie> wow 2.2 is so slow to get through pqm compared to 2.5
<vila> poolie: try 2.0 ! :D
 * vila back to coffee
<poolie> hi vila; you're early
 * poolie is merging 2.2-2.3-2.4
<vila> hi all !
 * fullermd . o O ( Obviously, the cofffee worked... )
<vila> hey ! I put only 2 f there !
<fullermd> I know.  I thought you might be running out, so I gave you an extra one there.
<fullermd> Don't say I never gave you anything   :
<fullermd> p
<vila> ha cool, now I can type uck without being gross :)
<fullermd> It's good to know I provide a valuable service to the community like that   :p
<vila> spiv: yup, single backticks are for url refs AIUI
<vila> poolie: so what's up with the p-i and bug #715000 ? Do we still wait to restart it ?
<ubot5> Launchpad bug 715000 in Launchpad itself "Stacking is not fully transitive" [Critical,In progress] https://launchpad.net/bugs/715000
<poolie> vila, it's waiting on the lp deployment of the fixed bzr
<vila> ok
<vila> poolie: are you asking for a review of lp:~mbp/bzr/integration-2.3 or will you just land it ?
<poolie> you could just check it quickly
<poolie> ok, good night vila
<vila> poolie: g'night
 * vila back to bed
<vila> err, wait !
<mr-russ> Hi, I'm coming from SVN and would like a central repository area for developers to push/pull from for updates.  I'd like it to be over http, I've read http://doc.bazaar.canonical.com/latest/en/tutorials/centralized_workflow.html and http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/http_smart_server.html#running-a-smart-server
<mr-russ> What I don't understand is is a shared tree setup kind of like the SVNParentPath, group of repositories type setup.
<mr-russ> Is there a preferred way to get that kind of setup?
<poolie> vila, can you help, i need to go
<mr-russ> k, thanks for responding.
<poolie> mr-russ, as far as i can tell you just need to export that directory
<poolie> i don't think you need any special setup with bzr
<mr-russ> Also to add to that, I'm wanting loggerhead to allow viewing the repository groups, hopefully without addition config for each set of branches.
<mr-russ> what i mean is make the bzr server structure appear like svn as a set of repositories.
<mr-russ> and not have to maintain config for each one.
<mr-russ> also, don't forget you need to go poolie :)
<maxb> mr-russ: As far as hosting multiple projects and branches thereof is concerned, Bazaar works on the principle (whichever access method you use) of exposing a portion of the directory tree, under which you can put as many branches as you like
<maxb> Loggerhead supports basic browsing of the directory tree containing branches, and then switches to the interface that is familiar from bazaar.launchpad.net when you enter a given branch
<maxb> Example of what loggerhead looks like in this scenario: http://bzr.maxb.eu/
 * maxb glares at recipe builds
<mr-russ> maxb: do you setup a project that is a shared directory of branches?
<mr-russ> maxb: Then that just works with the standard push/pull
<vila> mr-russ: sorry, my chat notifications broke again
<vila> mr-russ: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief explain some concepts that will make the discussions easier
 * fullermd dreams of the day he can bury this !#&$ project and maybe have time to polish up those sow's ears...
<maxb> mr-russ: Basically, a project is just a convention of keeping related branches in a directory - ideally having made the shared directory a Bazaar shared repository so that revision data is shared between all branches under it
<vila> exactly
<maxb> But that's a time/bandwidth/diskspace optimization rather than a necessity
 * vila scratches head
<vila> maxb: why is 'rmadison bzr' showing 2.3.0 for natty source but 2.3.0~beta5 for amd64 and i386 ?
<maxb> vila: Because the binaries are stuck in the NEW queue?
<vila> maxb: stuck as in: too much load on same server or there is a problem waiting for a fix ?
<vila> maxb: and is there some way to consult this NEW queue ?
<vila> s/same/some/
<maxb> Jelmer split out python-bzrlib as a separate .deb in this release. A new binary package name requires ack-ing by an archive admin before the packages enter the archive.
<maxb> https://launchpad.net/ubuntu/natty/+queue?queue_state=0&queue_text=bzr
<mr-russ> Thanks, I think I get it.  I just need to go setup the structure on the server and it will just work.
<vila> mr-russ: that's the idea, come back for more help if needed
<maxb> This has comically caused the main bzr package to shrink to 38 kB :-)
<Decorian> hi, bazaar is asking me to file a bug report, thought i'd just mention it here first as I don't know much about the crash so I can't effectively write a bug report.
<Decorian> it crashed whilst doing a push to a bzr+ssh server (run by me) that worked 20 mins previously, and the other repository on the same server works.
<Decorian> pastebin of the output bzr explorer gave http://pastebin.com/Gzh73z3U, I'd be gratefull if anyone has any ideas, even if it's 'file a bug report anyway'
<spiv> Decorian: probably the server got a MemoryError.  I'd file a bug report anyway :)
<Decorian> ok, is that something to do with my configuration of the server, and how would i work around it
<Decorian> i could always wipe the server's repository, and do a fresh push from my most up to date local one.
<Decorian> I'll file a bug report anyway, with as much information as i know (which unfortunately isn't much).
<spiv> Decorian: I'd check the .bzr.log on the server
 * spiv -> bed
<Decorian> is that .bzr/.log?
<Decorian> thank you spiv
<spiv> No, probably ~/.bzr.log
<Decorian> ok thank you.
<Decorian> yes, it's a MemoryError.
<Decorian> does it still need a bug report, or is this known?
<vila> Decorian: file a bug report anyway :) With the relevant excerpt from .bzr.log
<vila> Decorian: there is little that can be said without that
<Decorian> vila: Ok, I will, I'll attach a few excerpts from .bzr.log because I tried again a few times and sometimes got a pipe failed or something problem
<Decorian> I tried working around it by choosing to create a new repository in a different directory on the server, but it still failed.
<Decorian> i'll report what i found.
<shakaran> Hi, I have this error doing a bzr upgrade:
<shakaran> bzr: ERROR: Cannot convert from format Remote: Branch format 7 to format <class
<shakaran> 'bzrlib.branch.BzrBranchFormat7'>.    No converter
<vila> o_O
<shakaran> How I can solve? I need upgrade for make a bzr unbind on a lightweight checkout
<vila> O_O
<shakaran> I am saying weird things?
 * fullermd pokes vila in the O
<vila> You can't unbind a lightweight checkout
<shakaran> $ bzr unbind
<shakaran> bzr: ERROR: To use this feature you must upgrade your branch at bzr+ssh://bazaar
<shakaran> .launchpad.net/~shakaran/ea/angel/.
<shakaran> how to upgrade then?
<vila> bah, unhelpful error message
<vila> you want to turn your lightweight checkout into a regular branch
<vila> bzr reconfigure --help
<vila> shakaran: please file a bug explaining your misunderstanding, this error message needs to be fixed
 * fullermd wishes reconfigure had more choice of modalities   :|
<shakaran> vila: I will fill a bug. I did previously on ask here a: bzr reconfigure --unstacked
<shakaran> so, previously to ask I can commit and push
<shakaran> but when I commit, directly push the commit, so for that reason I looking for a unbind
<vila> shakaran: right, it seems to me you want a regular branch not a lightweight checkout
<shakaran> I could take the right way. Delete the branck, and make a regular checkout, but my curiosity wants to know because the problem
<vila> err, delete the checkout and make a regular branch
<vila> unbind is for... bound branches, a lightweight checkout is not a bound branch, that's the bug, unbind should warn about that, not suggesting upgrade
<vila> a bound branch ensures that commits happen on the msater branch before they happen on the local branch (the local and master branches are bound)
<vila> a lightweight checkout doesn't have a local branch, only a master one
<vila> this is a confusing UI and one of the cause is that lightweight checkouts and bound branches are generally used by different people because they match different workflows
<vila> shakaran: so use whatever works for you, which seem to be the regular branches
<vila> s/regular/standalone/
 * vila slaps fingers for using the wrong word when trying to clarify a confusing UI
<fullermd> Actually, you were probably right the first time, with 'standalone' generally being a term of art for describing its state relative to a shared repo..
 * vila looks at bialix postcard...
 * vila looks at bialix's postcard...
<catsup> how do i check out a revision by revno?
<catsup> that
<catsup> that's probably unclear; i mean, i have downloaded a repo with bzr branch, and now i want to get a particular version into my working directory so that i can apply a patch to it
<fullermd> And then commit it?
<catsup> i don't know, maybe
<fullermd> If you just wanna look at it, you can use update.  If you want to commit it, you'll need a branch for that.
<fullermd> ... well, I guess you COULD do it all via update, but you'd be gambling that it goes smoothly.
<catsup> i'm very confused, from update -h, how you would do that
<fullermd> bzr update -rX
<catsup> oh.  -r isn
<catsup> t listed there
<fullermd> What version do you have?
<catsup> bzr: ERROR: no such option: -r
<catsup> Bazaar (bzr) 2.0.3
<Peng> Well, it's there in newer versions.
<fullermd> In 2.1 and newer.
<Peng> You could "bzr revert -r 123".
<fullermd> revert would be OK for looking at it, but you wouldn't have any chance of getting it committable from that.
<Peng> Right.
<Peng> Look but don't touch. :D
<Peng> "bzr update -r 123" makes bzr check out the older revision. "bzr revert -r 123" is like applying a massive patch to the currently checked out revision that coincidentally makes it look like revision 123.
<Peng> Which is just fine for looking at it, but would be a horrible thing to commit.
<Peng> If you want to commit anything, you need to use a new branch.
<catsup> ok, i got that figure out
<catsup> figured*
<yshavit> Hi all. Sometimes when I'm reviewing a largish diff on launchpad, I like to load it up in my IDE. To do that, I 1) create a new local branch from trunk, 2) merge in (but don't commit) the proposed branch. That way I can see the changed files in my IDE. Obviously these aren't a lot of steps, but I was wondering if there's a single bzr command that does it? I wrote a really small shell script, I'm just curious to see if there was a better way.
<vila> yshavit: I use: http://paste.ubuntu.com/565025/
<vila> yshavit: this gives me a new branch which is a mirror of the submitter's one
<vila> yshavit: I then use: alias bzr-review='. `which bzr-review.sh`'
<yshavit> vila: ah, okay. Yeah I like to have not a mirror but a diff from trunk to submitter's, so I can see just the proposed changes. Or is that what you're doing and I'm missing it?
<vila> yshavit: so I can issue 'bzr diff -rsubmit:' right away
<Peng> yshavit: bzr merge --preview?
<yshavit> vila, Peng: ah, didn't know about either of those options! I'll take a look now
<Peng> yshavit: ...except that would just produce the diff seen on lp
<yshavit> Peng: ah, okay.
<catsup> ok, i just issued bzr merge, got a conflict, resolved it by editing the file...  how do i finish the merge?
<vila> yshavit: Peng solution is one shot only, having a mirror also allows you to look at the history and better understand the final result
<yshavit> Peng, vila : Do either of you have any best practices for looking at largish (~1500+) diffs?
<vila> yshavit: shoot the submitter gives good results
<yshavit> vila: :D
<vila> yshavit: the following submissions are smaller (on average)
<catsup> oic, bzr resolve
<fullermd> vila: No no no, you injure them, you just make the responses slower.  Kidnapping family members and/or pets focuses their attention much more usefully.
<yshavit> vila: my company's still new with bzr, so we're learning to get our diffs down to size. I'm guilty of it, too... just dropped a 2400er on a colleague :(
<fullermd> Ah.  VCS MAD   :p
<vila> yshavit: seriously, for large diffs, hopefully there are several commits with smaller diffs...
<Peng> yshavit: When I see a large diff, I run away and hope someone else handles it.
<yshavit> vila: yes, that there are. I hadn't actually considered looking at it diff-by-diff, that's a good idea.
<Peng> yshavit: Fortunately I'm only involed in FOSS. :D
<vila> yshavit: if not, then, yeah, you're kind of doomed, but asking for reviews and not recommending frequent commits... won't fly
<yshavit> Peng: hippy! ;-)
<jam> vila: can I get a second review on: https://code.launchpad.net/~eric97/bzr/dump-btree-traceback/+merge/49002
<jam> it is pretty small
<vila> jam: morning jam !
<vila> eric's one ? Oh, right, 2 reviews needed, well let me check again but I think I was fine, just forgot to vote ;-/
<vila> jam: done, want me to land it ?
<jam> vila: sure
<henninge> Hi abentley!
<henninge> How do I merge two pipes?
<henninge> i.e. the next one into the current one.
<thumper> bzr merge :next
 * henninge thought he had tried that
<henninge> I had not.
<henninge> thumper: thanks!
<abentley> henninge, you can also just use the branch locations.  The only thing special about merging pipes is that --uncommitted works with uncommitted changes in a pipe.
<henninge> oh right, I think I have used that before
<henninge> thanks
<zooko> Hi folks! This web page https://code.launchpad.net/txaws tells me to run "branch lp:txaws", but when I do it says:
<zooko> HACK Zooko-Ofsimplegeos-MacBook-Pro:~/playground$ bzr get lp:txaws
<zooko> /Library/Python/2.6/site-packages/pycrypto-2.3-py2.6-macosx-10.6-universal.egg/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases.  See http://www.pycrypto.org/randpool-broken
<zooko>   RandomPool_DeprecationWarning)
<zooko> Permission denied (publickey).
<zooko> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<zooko> Hm, I have bzr 2.3b1.
 * zooko upgrades to 2.3b4.
<maxb> zooko: This is a known issue with paramiko. The bzr developers have set a patch to paramiko, but paramiko's upstream are being rather slow to apply it
<maxb> The warning is not usually an issue because bzr suppresses all deprecation warnings when it is a final (non-beta) release
<vila> ...but the patch is carried by the OSX installer IIRC, at least for the most recent versions
<maxb> Also, 2.3b4 is an odd thing to upgrade to. 2.3.0 final is out
<maxb> and there was a 2.3b5 in between
<vila> and anyyway it's a warning you can ignore, you problem seem to be the 'Permission denied (publickey)'
<zooko> Ah, I assumed that it didn't need any credentials of mine since this is a public repo.
<zooko> But... if it is trying to use my ssh key then that probably explains the problem...
<maxb> zooko: Connections to launchpad lp: URLs prefer SSH because Launchpad providers the Bazaar smart server over ssh, but only dumb serving via http
<maxb> Therefore, ssh is often a lot faster
<lifeless> s/lot/massively/
<lifeless> maxb: consider pinging robey on twitter
<zooko> Hm, no my ssh public key *is* already registered in launchpad.
<zooko> Can I get bzr to tell me more about what is going wrong?
<zooko> Or test the ssh interface with the ssh client directly?
<maxb> zooko: "ssh your-lp-id@bazaar.launchpad.net" should print "No shells on this server."
<zooko> Thanks! Fixed. (I didn't have my current ssh key registered after all.)
<shakaran> vila: https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/716006 the file bug as you requested
<kkrev> is there supposed to be a way you make bzr launch kdiff automatically for needed manual merges: bzr usekdiff myfile.cpp ?  Or do you really have to manually run kdiff3 and then mark resolved?
<kkrev> it just seems like a very annoying bit of typing to have to specify 'kdiff3 myfile.BASE myfile.THIS myfile.OTHER -o myfile' every single time a manual merge is needed.
<jam> kkrev: there is the plugin bzr-extmerge, but I don't fully remember how to invoke/configure it
<mgz> also Gordon Tyler's mergetools stuff on trunk addresses this problem no?
<kkrev> extmerge looks perfectly good, but is there a trick to making plugins work on windows?  It works from cygwin, but from the dos shell "bzr extmerge" just says "unknown command"
<kkrev> For some reason it doesn't like living in %HOME%/.bazaar/plugins on windows.  I had to put it in /program files/bazaar/plugins to make it work.
<poolie> hi jam, jelmer
<jam> hi poolie
<jam> how did the dry-run lp-forking service stuff go?
<jam> I saw the lead-up conversation, but none of the final stuff
<jelmer> hi jam, poolie
<jam> I did land lp-production-configs since spm approved it
<poolie> ah, good
<jam> hopefully that doesn't mess up the ordering you proposed
<poolie> i didn't hear him specifically reach a conclusion
<poolie> maybe he was interrupted
<poolie> i wasn't sure if you were going to land it or him, but it's good it's done
<poolie> we have a udd meeting now in #ubuntu-meeting
<poolie> jam, can you join us?
<maxb> jelmer: Do you happen to be around?
<jelmer> maxb: somewhat
<jelmer> maxb: got a bad case of the flu, so I'll disappear after the udd meeting
<maxb> jelmer: Hi, could you go here: https://code.launchpad.net/~bzr/+recipe/bzr-dbus-daily and trigger some builds? I am not allowed to view the page because it contains a deleted PPA in the last 5 builds list
<jelmer> maxb: done
<maxb> oh dear - get well soon!
<maxb> yay, and now I can view the page
<jelmer> thanks :)
<jelmer> maxb: is there a lp bug about that?
<maxb> bug 715325
<ubot5> Launchpad bug 715325 in Launchpad itself "recipe is forbidden when it lists a deleted archive" [Critical,Triaged] https://launchpad.net/bugs/715325
<jelmer> maxb: you rock, thanks
<mgz> ha, bzr-git update means I've finally got a repo on bug 393038
<ubot5> Launchpad bug 393038 in Bazaar "UnicodeDecodeError in _inaccessible_normalized_filename" [Medium,Confirmed] https://launchpad.net/bugs/393038
<mgz> it's basically what I had before, must have been masked by the other breakage.
<maxb> Can someone suggest how to start_bzr_subprocess *and* ensure that the plugin you're currently testing is available to be loaded by the subprocess?
<poolie> maxb, what are you trying to test?
<poolie> hi guilhembi
<maxb> poolie: I'm trying to repair the bzr-dbus testsuite
<poolie> and it needs to run in a test suite?
<poolie> blah
<poolie> in a subprocess
<poolie> you could try setting BZR_PLUGINS_AT to something handcrafted to work
<maxb> [  646] 2011-02-09 22:06:22.571 WARNING: bzrlib.plugins.dbus cannot be loaded from ['/home/maxb/wc/bzr/bzr-dbus/unstable']
<maxb> bzrlib.plugins.dbus cannot be loaded from ['/home/maxb/wc/bzr/bzr-dbus/unstable']
<maxb> right path.... shame it doesn't say *why* it can't be loaded :-/
<maxb> ah....
<maxb> actually, no, I don't have a path starting ['.... :-)
<poolie> john, with the fallback mps
<poolie> most of them are superseded
<poolie> lp doesn't send mail when that happens apparently
<poolie> i was trying things out to get a good diff showing only the changes since 2.3
* mbarnett changed the topic of #bzr to: Launchpad down/read-only from 23:00 - 00:30 UTC for a code update || Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.2.4 officially released, 2.3.0 frozen. Release plugins ! Build installers ! (rm vila)
<mgz> jam/poolie: do you have any feelings about whether I should reopen bug 77657 and dupe bug 715547 against it, or treat the second as a new thing?
<ubot5> 'Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable\nResponse headers:\n---\nconnection: close\ncontent-length: 5640\ncontent-type: text/html;charset=utf-8\ndate: Wed, 09 Feb 2011 23:19:59 GMT\nserver: zope.server.http (HTTP)\nstatus: 503\nvia: 1.1 wildcard.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http:/
<ubot5> 'Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable\nResponse headers:\n---\nconnection: close\ncontent-length: 5641\ncontent-type: text/html;charset=utf-8\ndate: Wed, 09 Feb 2011 23:20:10 GMT\nserver: zope.server.http (HTTP)\nstatus: 503\nvia: 1.1 wildcard.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http:/
<mgz> ...thanks ubot5.
<poolie> haha
<poolie> it's probably also a bug that failed api calls return html
<mgz> as far as I can tell, the exact problem the first (and many of its dupes) was never actually fixed, but a different path was.
<mgz> the associated branch touched workingtree, but not mutabletree
<poolie> on the whole in that case i would just go with the new bug
<poolie> and maybe post a note on the old bug for people who are still affected by it
<mgz> okay, will do.
<poolie> i think generally speaking having bugs cycle open-fixed is just confusing y
<poolie> if we just fixed it and then discovered we didn't that's different
<jam> mgz: I think it is a new bug
<mgz> well, the root issue is sorted(os.listdir(...)) which has been in smart_add all along, and is unsafe in those circumstances.
<mgz> it's easy to move this kind of bug around though, it could well have been failing somewhere else for a bit.
<mgz> just changing the mutabletree code may well move the problem somewhere else.
<mgz> I'll play around and see where I get.
#bzr 2011-02-10
<jam> mgz: I think the current 'best fix' is to just catch the error and re-raise something that indicates what files are involved
<jam> it may not be the final fix, but it at least progresses us to where users get informed that there is a problem with specific files
<mgz> jam: unrelated question, what's the minimum cython version that should work? had issues with _simple_set_pyx.pyx on my old debian box.
<jam> mgz: 0.11? I'm not really sure. pyrex 0.9.6 comes to mind
<jam> I know 0.9.4 has bugs
<mgz> hm, python-pyrex seems to be mispackaged on lenny though, and cython is only 0.9.8
<mgz> I'll leave it on the python versions till I get round to updating.
* mbarnett changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.2.4 officially released, 2.3.0 frozen. Release plugins ! Build installers ! (rm vila)
<kkrev> is --hardlink supposed to work on windows?  2.3 crashes here with that option: bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'link'
<jam> kkrev: no, it could probably be made to work, but it does not currently.
<jam> mkanat, mwhudson: Are you guys around? I'm wondering if people are still getting the merge proposal emails for loggerhead. You don't have to do any reviews, but the team was changed to 'loggerhead-team', and I'm getting noisy bounces from a launchpad list
<jam> so I want to make sure whether anyone is seeing the requests at all
<mkanat> jam: My contract with Canonical is unfortunately over.
<mwhudson> jam: i've seen some of them
<mkanat> jam: I have seen the emails, though.
<jam> mkanat: no issue for me here, just making sure emails are getting out
<jam> I didn't know if it was going dark because of the target change
<poolie> jam, i suggest you request reviews from bzr people
<poolie> and also get lp admins to repopulate that team appropriately
<jam> poolie: I'm not really sure who should be in loggerhead-team, but I'm in ti
<jam> it
<jam> from the discussions, lp is supposed to be taking over the review process, and I'm a little unsure what the short-term plan is for the branch.
<maxb> We need a timeline for merging 'experimental' into the new lp:loggerhead - in particular whether all of experimental will land at once, or if it's worth re-landing some of the smaller changes first
<poolie> i got some of those bounces myself
<poolie> there is a thread about it
<jam> I know I've read robert's stuff, but he seems to indicate lp squads will actually do something, which has not really been my experience
<jam> maxb: I'm starting with getting it up to the level of pqm
<poolie> i don't think they are as proactive on reviews as we are
<jam> reverting all the way to 422 takes out a fair amount of stuff, like even the view pages
<poolie> and we could do better, at that
<poolie> i did get your review mails
<jam> poolie: sure. The question is, who is actually going to say something about the future of that branch? I have direct commit rights still, so I could just do it TM
<poolie> you can certainly nag me or your other team mates
<poolie> let's review them and commit
<jam> poolie: there is still the 'experimental' branch issue, which needs oversite. Which robert had a rough proposal for, but needs someone actually doing the various bits. "watch production like a hawk after rollout", "try to load test on qastaging", etc.
<jam> I'm willing to push a bit on it
<jam> in the "get the stuff I did actually out to people" sense
<jam> But though I know a bit about the process, it still always feels nebulous
<jam> and certainly, nobody other than lifeless seems to notice anything, which seems to go against the point of his experiment
<jam> poolie: for example, what do we do with the SocketException code. You reviewed it, but is that 'official' enough to land it?
<jam> I investigated the HEAD returns BODY bug
<jam> but it seems a general WSGI issue
<jam> that is much bigger than "if REQUEST_METHOD == 'HEAD'"
<jam> namely, you have to get all the headers correct, so the general recommendation
<poolie> yeah i was a bit afraid robert would say "yes we'll maintain it; revert; <crickets>"
<jam> is to do all the work, and at the top-most level strip the body
<poolie> i think wsgi makes it easy to get HEAD wrong
<poolie> mm
<jam> poolie: did you see the link I posted to the bug?
<poolie> well, that's a very general issue
<poolie> i did
<jam> http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html
<poolie> if there are things that are expensive to compute and not mandatory to have present, we don't need to do them
<jam> it basically says, because of how applications stack on eachother's content streams, it is very hard to get identical headers without actually doing all the work
<poolie> true
<jam> poolie: Content-Length is the biggest problem
<jam> since, you can omit it, but if you aren't omitting it from the GET request, you're technically in violation
<spiv> You don't have to return Content-Length for a HEAD request, though.
<jam> and you have to have Content-Length to preserve Keep Alive, I believe
<poolie> well
<jam> spiv: correct. *but* the spec says the headers must be identical to the GET headers.
<poolie> no, not for a head request, since there must be no body in it
<poolie> mmm
<jam> The quote he gave was: "The  metainformation contained in the HTTP headers in response to a HEAD  request SHOULD be identical to the information sent in response to a GET  request. "
<spiv> My guess is in practice it's fine to omit Content-Length; I'd check with lifeless
<poolie> well, that's must vs should
<poolie> i'm sure that's correct
<poolie> anyhow, for dynamic resources
<jam> "If the new  field values indicate that the cached entity differs from the current  entity (as would be indicated by a change in Content-Length"
<poolie> there is no guarantee that the length you get from one HEAD is going to have any necessary relation to what you get from a later GET
<jam> that makes Content-Length one of the things that should be preserved
<jam> poolie: sure.
<jam> but the question is, what is HEAD being used for?
<poolie> in this case it's being used as "are you there"?
<poolie> <turret voice>
<jam> poolie: sure, I'd be fine just adding a HEAD_middleware that just omits the content bytes
<poolie> so i do think it would be wrong to say "length=0"
<jam> start_response is the call that writes the headers
<jam> you can have it return a no-op write function
<jam> and always yeild nothing, but consume the child apps
<poolie> and i read that article as saying that wsgi's interface makes it very easy to get this wrong and end up with something saying the wrong length
<poolie> anyhow, i think it's pretty obvious that returning a body on HEAD is a much worse violation of the rfc
<spiv> I've seen servers that return bodies from HEAD cause weird breakage.
<jam> poolie: sure
<poolie> that is really not defensible
<jam> Apache strips it for us in the public site
<spiv> Because it understandably screws up pipelining
<jam> I think it is broken for 'bzr serve --http'
<spiv> So it's a pretty severe bug (and one that tends to cause breakage on subsequent requests that are otherwise bug-free)
<poolie> if we started sending last-modified dates and especially if we started respecting if-modified-since it would probably be important that HEAD sends the correct date
<poolie> and it's just thrashing the machine to no good purpose
<jam> poolie: just confirmed that 'bzr serve --http' does it wrong
<jam> poolie: I doubt *thrashing* is the word for something that is requested every 10s on a reasonably small branch
<poolie> huh, i thought i tested that but perhaps not
<poolie> ok, 'loading'
<jam> poolie: when I first tested it with socket.recv()
<jam> I got it wrong
<jam> I did an initial recv()
<jam> and it returned just the header line
<jam> but that was becuase it was busy churning through the rest of the data
<poolie> i think i tested it using curl, and probably curl discards any body sent from HEAD
<jam> once it had been cached and up to date
<jam> then recv() started returning the full content
<spiv> jam: more or less load than ('x', 'y') vs. 'x:y' in hook registration? *wink*
<poolie> :)
<jam> spiv: significantly more
<jam> but not a startup overhead
<jam> :)
<poolie> ok, so we'll agree that bug about head should be fixed?
<poolie> spiv, how's bug 603395?
<ubot5> Launchpad bug 603395 in Bazaar "bzr commit in a heavyweight checkout does not propagate new tags" [High,In progress] https://launchpad.net/bugs/603395
<jam> poolie: I agree there is a bug that paste's HEAD handler doesn't strip the body, which I'll post a fix for in about 20 min
<spiv> poolie: erk, closed the bug.  The confusion was that the merge proposal state didn't record the fact that while one fix was rejected for 2.2 it was landed on 2.3 (trunk at the time) instead.
<poolie> thanks jam; there's a bug number for that too
<poolie> no, there isn't?
<jam> poolie: the HEAD stuff? there isn't a separate bug AFAIK, just bug 701329
<ubot5> Launchpad bug 701329 in Launchpad itself "loggerhead OOPS - error: [Errno 32] Broken pipe" [Critical,Triaged] https://launchpad.net/bugs/701329
<jam> but I can report one if you like
<poolie> i just did, bug 716201
<ubot5> Launchpad bug 716201 in loggerhead "loggerhead sends body content on HEAD request" [High,In progress] https://launchpad.net/bugs/716201
<vila> hi all
 * fullermd waves vila around.
<vila> fullermd: hey !
<vila> SGIBART and SIGTERM seem to behave differently regarding the children of the process receiving the signal, did that ring any bell ?
<fullermd> No, SIGBELL is for ringing bells...
<maxb> SIGABRT ?
<vila> I couldn't find any answer to that with google :-/
<vila> yeah, SIG -9
<maxb> that's SIGKILL
<fullermd> I'm pretty sure neither signal (or any signal...) does anything to processes other than the one you're hitting with it.  It may _catch_ the signal and do something unspeakable to its kids, but that's nothing to do with the signal itself...
<fullermd> And yeah, SIGABRT is 6.
 * maxb believes the same
<vila> hmm, is it just that I mixed ABRT and KILL ?!?!
<fullermd> Mixing anything with KILL has unpleasant side effects   :p
<vila> like zombies maybe ? ;D
<maxb> KILL is uncatchable death; ABRT is catchable coredump-and-die
<vila> damn damn damn, my google history confirms I've been climbing the SIGABRT tree, ctrl-alt-del
<fullermd> No, that's SIGSQUIRRELYPCHISTORICALBAGGAGE   :p
 * vila notes: -9 != SIGABRT
<vila> ok, SIGKILL passed a test that SIGABRT didn't... weird
<vila> so the test is spawning a 'sh -c yes' and killing the shell
<vila> I've seen 'yes' staying alive... and detach from the test process
<vila> s/detach/detached/
<fullermd> The shell may catch SIGABRT and kill its children.  It doesn't have a chance with KILL.
<vila> right, no change with KILL is clear, but how is 'yes' killed ?
<vila> s/change/chance/
<vila> I call kill with the pid of the shell, no fancy group stuff or else
<vila> anything else (gee tyops day)
<fullermd> If I "sh -c yes", sh just exec's yes, it doesn't hang around to do anything.
<vila> hmm, no, I'm pretty sure I had distinct processes
<fullermd> I don't.
<vila> the sh one being reported as defunct
<fullermd>  45845 sh       CALL  execve(0x800c30378,0x800c30260,0x800c30270)
<fullermd>  45845 sh       NAMI  "/usr/bin/yes"
<fullermd>  45845 sh       NAMI  "/libexec/ld-elf.so.1"
<fullermd>  45845 yes      RET   execve 0
<fullermd> (same pid that starts out the run as 'ktrace', exec's sh, exec's yes)
<vila> right, looks like subprocess.Popen(...shell=True...) is not exactly sh -c yes then
<vila> http://paste.ubuntu.com/565278/
<vila> *blinks*
<vila> fullermd: *not* same pid even if 'sh -c yes' is clearly (or is it) what 'ps jef' displays...
<jelmer> 'morning
<fullermd> Defunct would mean it's a zombie.
<vila> yup, and its children got reparent to 1
<fullermd> Which you'd expect.
<vila> well, no, because 'yes' is still connected to its grand-parent process via pipes
<vila> I managed to kill it when it reaches the 8GB mark one of the first times I debugged it ;)
<fullermd> That doesn't matter.  When the parent goes away, it parents right off to init.
<vila> yup, understaood
<vila> but what I don't get is why this occurs with ABRT but not KILL
<vila> may be I should just forget about that, I shouldn't use ABRT anyway
<fullermd> There are some things man was not meant to enquire into...
<vila> after all, the bug I'm after is about a children clogging the pipes, leading to a parent hang. 8GB collected is good enough proof that the parent is not hanging anymore (even if I can only reproduce it manually)
<vila> fullermd, maxb: Thanks for the teddy-bearing, ABRT != KILL
<vila> jelmer: hey ! Are you feeling better ?
<jelmer> vila: hey
<jelmer> vila: good enough to work.. perhaps I'll stick to easier things today
<vila> jelmer: it's amazing how this flu is spreading... I'm not feeling that good myself but I thought I should blame my gf which is getting back to work today
<vila> and now spiv got one too...
<jelmer> and jam's son
<vila> indeed ! poolie ! watch out ! :)
<jelmer> :)
<thrope> is it possible to use bazaar with a samba share on os x?
<thrope> looks like there is an open bug
<thrope> but I wondered if anyone knew a workaround
<thrope> the bugs been open for 4 years
<jelmer> thrope: which bug?
<thrope> https://bugs.launchpad.net/bzr/+bug/31006
<jelmer> thrope: are you sure it's a samba server on the other end, not a windows machine?
<thrope> yes
<thrope> its a ubuntu server
<jelmer> at least newer versions of samba should support os locking I think
<thrope> 10.10 fresh install
<jelmer> probably mac os x that doesn't support os locks over smb then :-/
<jelmer> yep
<thrope> ah ok - my apologies, I guess not really a bazaar bug then
<thrope> but it would be nice to be able to do it
<vila> thrope: don't forget to meeto the bug (#98836 in this case, 31006 is a duplicate)
<vila> thrope: it's on the TODO list, but not high enough yet :-/
<jelmer> thrope: it's fundamentally a mac os X bug, but that bzr bug you linked to would work around the mac os X bug
<thrope> ok got it
<thrope> do you think smbfs over fuse would have the same problem?
<thrope> rather than the os x built in one
<jelmer> the fusesmb homepage doesn't say anything about locking, but I'm not sure
<fullermd> vila: Well, don't sneeze in my direction!
 * vila aims...
<maxb> Is anyone else finding bzr's new behaviour of dumping the full plugin list to stderr when a traceback occurs to be somewhat annoying?
<maxb> Since the traceback disappears off screen
<Tak> is that new?
<fullermd> I can't say I've noticed it, but I don't think it would bug me that much...  the traceback is already way offscreen anyway.
<maxb> Why is it already way offscreen? before the plugin list was added, there were only a few lines after it
<fullermd> I'm pretty sure those "few" lines were already half a term full.  There's only 25 lines to work with...
<fullermd> And the traceback itself is often 20 or so frames deep, with 2 lines per frame, so it couldn't fit even by itself.
<fullermd> But that's what scrollback is for anyway.
<maxb> fullermd: But, the exception is at the bottom of the traceback, and formerly there were only 9 lines after it. So, you got to see the exception.
<maxb> Now, you don't
 * fullermd shrugs.
<vila> maxb: IIRC the idea was to output only the plugins that are potentially out-of-date API-wise
<fullermd> I always remember having to scroll back to figure out what was going on anyway.  It's not something that happens to me often either way.
<vila> I don't remember the intent was to display *all* plugins
<maxb> Somewhere along the way it turned into a full `bzr plugins` output
<vila> worth filing a bug then, I don't see what value is added by displaying perfectly fine and probably unrelated plugins
<maxb> I have sidestepped the issue for now by adding bzrlib.crash._format_plugin_list = lambda: '*elided*' to ~/.bazaar/plugins/maxb.py :-)
<asabil> statik, ping ?
<vila> shudder
<maxb> you don't like my hack, vila?
<vila> thread is a python module (use discouraged in favour of threading), I forgot about that when creating bzrlib.thread
<maxb> ohdear
<vila> maxb: oh no ! As long as a bug if filed so we don't forget your valid point
<vila> so I need to find a new name... safethread sounds a bit pretentious catchingexceptionthread a bit long...
<vila> threadeling ?
<vila> cethread ?
<maxb> Or, you could declare that you're looking forward to the future where relative imports are explicit only :-)
<vila> vade retro satanas ;D
<vila> I'll go with cethreads for now and see what reviewers think
<vila> doh ! rm bzrlib/thread.pyc, I hate that one
<vila> eeerk ! plugin list !!!
<vila> maxb: gee, now I see your point :-}
<maxb> ha :-)
<vila> it's ~120 lines here 8-}
<vila> fullermd: *4* lines by plugin
<vila> I'm so used to scrollback on exceptions that I didn't notice earlier
<maxb> filed bug 716389
<ubot5> Launchpad bug 716389 in Bazaar "In-terminal crash report is far too long, containing full `bzr plugins` output" [Undecided,New] https://launchpad.net/bugs/716389
<vila> thanks !
<fullermd> It's all about choosing where to apply pressure, see...
<fullermd> If we make the crash report painful enough, we create pressure to make sure things don't crash   :p
<vila> maxb: metoo'ed
<vila> hehe, the original intent was to point people to their outdated plugins *before* they file a bug against bzr
<maxb> fullermd: In that case we need an "I'm a developer just show me a traceback" debug flag
<vila> well, I'm a lazy dev , running plugins from their trunk and I often forgot to update them in a timely manner ;)
<vila> hmm, it's even worse than that, I use a mix of plugins installed in the system libraries and some in ~/.bazaar/plugins (which is a farm link to add to the fun ;)
<vila> anyway, 120 > 84 and I have no plan for a 30" screen yet
<fullermd> I do.  I totally do.
<fullermd> Now, _budget_ for a 30" screen, that's another matter...
<vila> stop spending that much in ECC and raids ;-D
<quicksilver> afternoon all.
<quicksilver> can loggerhead do a diff between two branches, like bzr merge --preview?
<fullermd> Pfft.  If I did that, bzr would crash and I'd never be able to read _anything_ on my terminal   :p
<Tak> something in the lp stack is doing it...
<quicksilver> warnocked!
<quicksilver> no loggerhead experts?
<maxb> No, loggerhead cannot
<quicksilver> maxb: thanks.
<quicksilver> shame ...
<quicksilver> it's nice to be able to review code before deciding to merge, and it's nice to be able to paste around links that other people can use to review possible merges.
<jam> vila: yeah, my son finally doesn't have a fever, though he threw up this morning.
<jam> vila: so be careful. I've had large swaths of people I know hit by feeling sick
<vila> jam: :-/ Such a nice way to start the day :-/
<quicksilver> maxb: OK, I think I can merge from trunk into the feature branch, and then persaude loggerhead to show me the diff between the head of the feature branch and the recently merged trunk revision (which is a dotted revision number)
<quicksilver> maxb: does that sound plausible
<vila> right, so I should blame you for Valentine's flu then :-D
<quicksilver> unfortunately I'm bitten by https://bugs.launchpad.net/loggerhead/+bug/602600 so I need to upgrade loggerhead.
<vila> quicksilver: check with jam, loggerhead's trunk is not anymore what it used to be
<quicksilver> vila: in my description I wasn't talking about loggerhead's trunk
<quicksilver> I was talking about my own repositories trunk :)
<jam> quicksilver: lp:loggerhead recently reverted to an old old revision
<jam> which doesn't include the history-db code, and thus couldn't be affected by bug 602600
<ubot5> Launchpad bug 602600 in loggerhead "Error on dotted revisions" [High,Fix released] https://launchpad.net/bugs/602600
<vila> quicksilver: sry, I got confused, but are you talking about lp's loggerhead or an instance you're running yourself ?
<jam> however, lp:~loggerhead-team/loggerhead/experimental has all the updates
<quicksilver> vila: I didn't say that, so the confusion is of my making, sorry.
<quicksilver> vila: we have a local loggerhead install.
<quicksilver> jam: did lp rollback for a good reason? Should I avoid upgrading my local install to 1.18?
<vila> jam meets quicksilver, quicksilver meets jam, I'm sure you have interesting bits to share ;)
<vila> jam: should I answer that while you take a deep breath ?
<jam> quicksilver: loggerhead hasn't had a strong maintainer in a while. lifeless wanted the launchpad-team to take over maintenance, but basically wanted to roll back to the point where loggerhead has been deployed in production
<jam> I'm slowly pushing to get things back up to where it was
<quicksilver> ah. scary.
<vila> quicksilver: not for you unless your instance can receive the same kind of load as lp
<jam> quicksilver: loggerhead's old trunk (now "experimental") seems very stable for most installs, but what Launchpad needs as a giant codehosting site is a bit different
<quicksilver> we've been running the debian package of "1.17+bzr424-1"
<vila> quicksilver: I meant, not scary for you
<quicksilver> I see.
<quicksilver> yes, we only have a handful of users.
<quicksilver> we just want repo browsing + diffs
<quicksilver> mostly diffs, actually. We paste the urls into our automatic commit emails.
<jam> quicksilver: I think the experimental stuff will have some very big long-term gains, which is why I'm pushing it, but it potentially regresses some immediate concerns.
 * quicksilver nods
<quicksilver> it's been fine for us, until I wanted to generate a URL for what git people call a "pull request"
<quicksilver> and discovered that I couldn't do that.
<quicksilver> I could make a throwaway branch and actually do the merge in that and use that as a URL, I guess.
<jam> quicksilver: isn't that just "please merge my tip"? I don't see exactly what you are wanting out of the pull request
<jam> or is it that they want "pull" to work, rather than "merge"?
<quicksilver> jam: I want them to be able to examine the diff before they do it.
<quicksilver> for code review.
<quicksilver> obviously they can run bzr merge --preview locally
<Tak> yeah, people want the nice merge request interface like launchpad
<quicksilver> I just wanted a URL which contained the output of bzr merge --preview
<quicksilver> and looking nice.
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3.0 is officially out ! (rm vila)
<jam> quicksilver: sure. We use launchpad merge proposals for that, but it doesn't cover people just using loggerhead
 * quicksilver nods
<quicksilver> I think I'll do the throwaway branch thing
<jam> quicksilver: I think it would be reasonable to add a feature/bug request on loggerhead for a merge --preview type view
<jam> I don't know who would actually get around to coding it, but it does seem like something you should be able to get from loggerhead
<quicksilver> jam: well the other alternative would have been to actually commit the reverse merge
<quicksilver> (which is quite common practice anyway, to resolve conflicts before merging)
<quicksilver> then I would have a 'dotted revision' to diff against.
<quicksilver> which loggerhead ought to be able to do - but see the bug above :)
<jam> quicksilver: well, you could always show the diff vs the "ancestor:" but loggerhead should make that available, rather than you having to do it yourself
<jam> and merge --preview exists because you can get conflicts while merging
 * quicksilver nods
<jam> vs "diff -r ancestor:" which will never show a conflict
<quicksilver> I don't think I know what ancestor: means.
<jam> quicksilver: try "bzr diff -r ancestor:../other-branch"
<jam> it finds the most recent common ancestor of this branch and other-branch
<quicksilver> ah, handy.
<jam> so 'bzr diff -r ancestor:../other/branch" shows you what is new in your current branch, vs the ancestor of the othe rbranch
<quicksilver> I normally dig manually through the output of bzr log -n0 and copy-paste the ancestor revno :)
<jam> so you don't see the changes in trunk being removed in your branch
<jam> quicksilver: bzr log -n0 -r ancestor:../other/branch should show you what rev it is :)
 * quicksilver nods
<quicksilver> getting software right is hard.
<quicksilver> I can't even understand how we managed to install the squeeze deb of loggerhead when we're only running lenny on this machine.
<maxb> heh :-)
<quicksilver> each rabbithole leads to a door which opens into a deeper rabbithole
<quicksilver> I don't think uprading loggerhead is going to be the most time-efficient thing for me to do this afternoon.
<maxb> quicksilver: tbh, I think for most people the best way to "install" loggerhead is probably just 'bzr branch lp:loggerhead'
<maxb> and then upgrading is "bzr pull"
<quicksilver> you may be right.
<quicksilver> It looks like the debian package has no harsh dependencies
<quicksilver> so I think someone just downloaded it from squeeze and dpkg -i'ed it by hand.
<maxb> btw, of the package you are running, the only thing of importance that got removed from trunk was the initial landing of the history-db branch
<maxb> Also, if you want to go to 1.18, 1.18 doesn't include anything that was removed from trunk
<quicksilver> maxb: what odes the history-db branch do?
<maxb> It's jam's big make-it-faster-by-caching-stuff project
<shakaran> Hi, I need help for solve a conflict of type "Contents conflict in " I read the doc on http://doc.bazaar.canonical.com/bzr.0.92/en/user-guide/conflicts.html
<shakaran> so, I am using bzr mv as:
<shakaran> bzr mv Connection.java.OTHER Connection.java
<shakaran> bzr: ERROR: Could not move Connection.java.OTHER => Connection.java: src/ea/doma
<shakaran> in/Connection.java is already versioned.
<shakaran> then, how should I proceed? The right file is .OTHER
<shakaran> I know take-other option, but I need how to make with bzr mv
<shakaran> some help?
<maxb> shakaran: The particular documentation URL one you pasted is a very old one - bzr 0.92 is positively ancient
<maxb> As for the error, it sounds like you may want "bzr rm file; bzr mv file.OTHER file"
<shakaran> maxb: I search http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/conflicts.html but it have 404
<quicksilver> I don't think so.
<quicksilver> the .OTHER file is not versioned.
<quicksilver> I think you just want normal "mv"
<quicksilver> mv foo.OTHER foo
<quicksilver> 'chooses' the .OTHER as the version you want for foo.
<maxb> http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/conflict-types-help.html
<maxb> quicksilver: No, the .OTHER file *is* versioned
<shakaran> I did:
<shakaran> bzr rm Connection.java
<shakaran> deleted src/ea/domain/Connection.java
<shakaran> bzr mv Connection.java.OTHER Connection.java
<shakaran> src/ea/domain/Connection.java.OTHER => src/ea/domain/Connection.java
<shakaran> but, now the Connection.java file is not added, so I need a bzr add Connection.java ?
<maxb> erm. That's not what I expected at all :-/
<maxb> shakaran: I don't suppose these branches are public?
<fullermd> If bzr mv mv'd it, it IS versioned.
<fullermd> See your stat output.
<LeoNerd> 'bzr mv' also has special logic; if it can't find the OLD file and the NEW file already exists, it presumes you are telling it about a 'mv' you already did
<shakaran> ok, I use bzr explorer on windows (it take a 20 second on refresh the folder with the icon) it is added
<shakaran> https://code.launchpad.net/~shakaran/ea/angel it is my public branch
<latexer> Anybody encountered a bug on windows with "JUNCTIONS" (on win7 here) causing bzr to error out?
<latexer> I'm using a tool that automatically creates a junction, and i would like to treat it as a regular folder so the contents of the folder pointed to get added/committed... suggestions?
<squall> @latexer what error, or thing, happens when you do this? Are junctions like hard links, I forget, or do they work like mounts?
<latexer> squall: let me pull it up exactly. I believe the tool is using windows vista & newer "junctions" which work like soft links to files/directories.
<squall> uhuh ok. junctions were available on xp too and so on, but there were never any tools to manipulate them.. viz: http://technet.microsoft.com/en-us/sysinternals/bb896768
<latexer> squall: the initial "bzr add" attempt just says "bzr: ERROR: [Error 3] The system cannot find the path specified: u'C:/Users/pete.johanson/dev/repo/mainline/wraps/openwrap\\*.*'
<latexer> where the "openwrap" portion of that path is the junction.
<squall> okay and that opwnwrap points somewhere else on your disk then.
<latexer> squall: correct.
<squall> and openwrap points to a bzr tree.   and "repo" is a repository I guess.
<latexer> And looking, I think actually the ideal situation for me would be if the "JUNCTION" details (what path it points to) would be the thing committed. (I believe the same way symlinks are handled on *nix)
<latexer> repo is an initialized repository, "mainline" is a branch I've created.
<latexer> the junction wraps/openwrap points to wraps/_cache/openwrap-1.0.0.50386209/
<latexer> (hopefully that's clear)
<squall> hmm. There probably is a bug about symlinks not working on windows already. As for what you're seeing, it probably should work I guess.
<latexer> yeah, I found https://bugs.launchpad.net/bzr/+bug/81689 which seems to somewhat discuss the issue.
<latexer> (that bug talks about checkouts, but I think fundamentally it's addressing the same thing)
<squall> There is this I find on wikipedia "Windows Vista supports a new symbolic link capability that replaces  junction points in Windows 2000 and Windows XP. They are designed to aid  in migration and application compatibility with UNIX operating systems"
<squall> have you tried this new symlink stuff?
<latexer> that's the thing... the openwrap utility/tool is the one creating this junction/link, I don't really have control of it...
<jam> quicksilver: actually, history-db is "change from caching and always accesessing the entire history", to "cache the history in a way that we can access just the recent stuff quickly"
<latexer> i mean, I could fiddle with it, but I was hoping to not have to potentially muck with the openwrap internals.
<squall> yeah I see. I just wondered if it's actually creating a "junction" or a "symlink" type of thing. I guess a junction.
<quicksilver> jam: *nod*
<latexer> squall: "dir" from cmd shows it as a <JUNCTION>, so I would guess it's a junction, not a symlink.
<squall> right, okay.
<squall> yes well, anyway it appears that bzr doesn't like them. that is the answer for now. We may need a new bug on this I am not sure I'll look in a minute. Perhaps you could try the "new" symlink approach by changing this "openwrap". It depends if you can do that or not.
<latexer> yeah, can't hurt to try.
<squall> See, these junctions/symlinks have never been polular on windows at all. Probably becuase there are programs that fail to work correctly with them.
<latexer> ya, makes sense.
<squall> I'll look around the launchpad to see if there is a bug already.
<latexer> squall: thanks.
<squall> hmm there doesn't appear to be any mention of junctions. Although this problem might be related to other symlink bugs, it's hard to say.
<squall> @latexer I think perhaps it might be worth adding a bug about that anyway - and perhaps if if can demonstrate the problem without needing a repository. if that's possible, to make it easier to reproduce.
<latexer> squall: hrm... the openwrap author just sent me a tweet mentioning a way to make it not use junctions/symlinks and instead do copies from the cache.
<latexer> squall: so I may be able to work around the issue with the tool itself.
<squall> yeah that's sounds good.
<squall> Do you fancy filing a bug at launchpad about junctions. I would only I've got no windows around at the moment, so its hard for me to check.
<Lo-lan-do> Hi all :-)
<jelmer> hey Lo-lan-do
<Lo-lan-do> Question for jelmer: I see activity is starting up again on bzr-git these daysâ¦ is support for roundtripping somewhere on the TODO-list?
<latexer> squall: can do.
<squall> Cheers, may as well if you have the time. I might take a quick look. Although I've not looked at bzr for a while now.
<jelmer> Lo-lan-do: yeah, it's on the list of things to work on
<jelmer> I have a better idea of how to do it now after talking to some of the git devs
<Lo-lan-do> jelmer: Cool.  That's going to help relieve the tension we're starting to feel in FusionForge.
<Lo-lan-do> Feel free to poke me if you need a tester :-)
<jelmer> Lo-lan-do: will do, thanks :)
<jelmer> I guess you're already subscribed to the bug ?
<Lo-lan-do> Not as far as I know
<Lo-lan-do> Ah, found it.
<latexer> squall: https://bugs.launchpad.net/bzr/+bug/716507
<rjek> Hi.  I have a bzr branch that I migrated from svn many moons ago.  When I use it now, I get this warning: "Fetching into experimental format RepositoryFormatKnitPack3(). This format may be unreliable or change in the future without an upgrade path."
<rjek> So what's the /current/ upgrade path, and how do I move to something supported?
<squall> @rjek well I don't really know. But you could try running bzr upgrade on it. I would make a backup/copy of the repository first, though.
<cbz> if you haven't used any subtrees you can just do bzr upgrade --2a
<rjek> I don't believe I've used nested trees, but bzr upgrade say"bzr: ERROR: Cannot convert from format RepositoryFormatKnitPack3() to format RepositoryFormat2a().    Does not support nested trees"
<fullermd> Yeah, you have to end run around it.
<rjek> Can I check to see if nested trees have sneaked in somehow?
<fullermd> Try init'ing a fresh 2a branch, and pull'ing into it.
<rjek> fullermd: That appears to do the trick, ta.
<fullermd> Technically, it shouldn't work.  But technically, upgrade should check whether you're using the nested tree capability before complaining about how you'll lose it.
<fullermd> So two wrongs DO make a right   :)
 * rjek grins.
 * rjek now writes a script to automatically upgrade and archive a whole imperial buttload of branches.
<vila> fullermd: by the way, did you start upgrading *your* branches ?
<fullermd> Not 'till I get caught up on sleep.
<fullermd> So we may wait 'till bzr 3.8 or so for it...
<vila> indeed ;)
<vila> jelmer: b-d 2.5 ? I thought the *package* has already reached 2.6, what am I missing *again* :)
<jelmer> vila: I think I'm missing some context :)
<vila> jelmer: reno 515 on bzr-buildeb trunk
<jelmer> vila: we're at 2.5.1 according to changelog
<vila> Lo-lan-do: your fqdn is hilarious :D
<vila> *blink*
<Lo-lan-do> Is it?
<fullermd> Maybe he just tpyo'd it in his mind...
<vila> jelmer: nvm, I could swear I saw 2.6
<vila> lol, yeah, that should be it
<vila> Lo-lan-do: well, at least to me mirexpress.internal.placard sounds quite fun :)
<Lo-lan-do> It comes from a long tradition of hostnames that match "mir".
<vila> Lo-lan-do: but maybe I'm misinterpreting, as you can see above my mind play tricks on me ...
<vila> Lo-lan-do: mireille, mirabelle, miroir-mon-beau-miroir ?
<Lo-lan-do> monbomiroir is the server that does backups.
<Lo-lan-do> mirabelle is my current printer.
<vila> yes ! 2 out of 3 :)
 * fullermd always liked 'Mireille'...
<Lo-lan-do> I don't think I ever used mireille.  But I've had casimir, clodomir, minimir (my first laptop), miramax (the one used as a media center to play DVDs), mirific, dynamir, miracle, mokomir, mirador, mirenboite and prismirale (a plug computer)
<Lo-lan-do> Oh, and mircouleur, too, for a printer :-)
<Lo-lan-do> (And I could go on with the list of past, current and future names :-)
<fullermd> Mirabile dictu   ;p
<vila> lol@mircouleur :) So I was on the right joke track with mirexpress...
<vila> prismirale goes over my head though...
<fullermd> I wonder if I've ever had a machine with 'mir' in the name...   can't offhand think of one.
<Lo-lan-do> vila: Plug computer.  "prise murale".  Ahaha.
<vila> my current trend is on tools you can find in a bazaar: screw, scythe, saw, axe..
<vila> Lo-lan-do: !!!
<Lo-lan-do> I'm not claiming it actually is funny, just that I find it so.
<vila> Lo-lan-do: wfm :)
<fullermd> All my systems (except my workstation) get named after mythologically significant constellations.
<vila> the first real "root" guy I met used islands from a map in his desk, vanuatu, tahiti, quite colorful...
<fullermd> Laptop is pegasus.  An old dual-pentium was hydra.  A file server in a hyuge case was hercules.  Matched pair of diskless workstations were cepheus and cassiopeia...
<fullermd> There's a 386 in the closet that, if it still boots, will come up calling itself musca
<fullermd> Our business systems are named after herbs.  We're about to (loooong overdue) retire rosemary.
<achiang> how can i switch the view of my local tree to a tag? or is that not the bzr way to do it?
<fullermd> You can use update to pivot the working tree around.  Or pull to mess with the branch.
<achiang> hm, ok. thanks
<achiang> i guess what i want to do is fork an upstream branch at a certain revision
<achiang> and push it to my own place in launchpad
<fullermd> In that case, you'd probably want to use "branch -r" when you first create your branch.
<achiang> so, maybe what i need to do is bzr clone the upstream to my local drive; figure out what tag/revspec i want, bzr branch -r and create a new local branch from that, hackhackhack, then commit and push?
<fullermd> Well, you could use pull to reset the head of the branch once you have it, via a "bzr pull --overwrite -rX ."  (don't miss the trailing period)
<achiang> hm... does that allow me to keep all the upstream objects around, and merge my changes more easily if i want to?
<achiang> sorry, i don't know a lot of bzr terminology, maybe "objects" isn't the right word
<achiang> --overwrite seems scary and confusing, based on reading the man page
<achiang> i actually can't figure out the difference between pull and clone/branch
<fullermd> Generally speaking, branch is for making a new branch; pull is for updating an existing branch.
<fullermd> (in this case, we're using pull to "update" to an old revision, but that's just a special sorta case)
<fullermd> vila: Mmph.  I wish upgrade would shaddup about the metadir   :(
<vila> repro recipe please !
<fullermd> Well.  Run it   :p
<fullermd> SUMMARY: 6 upgrades attempted, 5 succeeded, 1 failed
<fullermd> bzr: ERROR: The branch format Meta directory format 1 is already at the
<fullermd> most recent format.
<vila> I know I've seen it and thought the same but could never remember how
<vila> hmmpf
<fullermd> Ah hah...
<fullermd> bug 716560
<ubot5> Launchpad bug 716560 in Bazaar "recursive upgrade sometimes tries to upgrade metadir, giving an error" [Undecided,New] https://launchpad.net/bugs/716560
<fullermd> With script.  Getting rid of trees is the trick; a branch with a tree doesn't bother screwing with the metadir format, but without it it does.
<fullermd> vila: ^^   (that took a little fiddling)
<vila> fullermd: thanks
<fullermd> Pretty wacky.
<fullermd> Note that it _doesn't_ error if we use pack-0.92 (which has an older branch format).  So going from 1.9 with no working tree, the individual branches would have nothing to upgrade; that's the case where they apparently try the metadir.  If there's a wt or branch format that's upgrade-able, it just does it and moves on.
 * fullermd should add that to the bug...
<jam> vila: when the bug was a common problem, you hit it whenever you tried to upgrade something that was the newest format
<jam> vila: and we still do
<jam> go to a fully up-to-date branch and run "bzr upgrade"
<jam> It certainly tells me that the Metadir is up-to-date, rather than the branch or repo, etc.
<vila> jam: could be, but istm I still encounter it from time to time when I come across old branches in the basement...
<vila> jam: yeah, that may be what happen here, update branch, update tree, oops, no tree, bad fallback, etc
<jam> vila: the bug is that it says it is an *error*, rather than just saying "already up to date" without "bzr: ERROR"
<vila> yup, worse, it's an error the user has no control over since the branch needed to be upgraded and was successfully upgraded (I think I haven;t look in details) fullermd can confirm my guess maybe
<vila> fullermd: see my comment in bug #716560 for a new 2.3 command (and sorry for the lack of ``for`` ;)
<ubot5> Launchpad bug 716560 in Bazaar "recursive upgrade sometimes tries to upgrade metadir, giving an error" [Undecided,New] https://launchpad.net/bugs/716560
<jelmer> jam: are you still hacking on reusable packs infrastructure?
<vila> fullermd: and try without ``--null-output`` for additional fun :-D
<jam> jelmer: it is still around, but I haven't been hacking on it
<jelmer> jam: ah, ok - thanks
 * maxb scratches head - I'm *in* a bzr branch, but bzr is trying to open the svn working copy several directory levels above?!
<jelmer> maxb: does the branch have a repository?
<maxb> yes, it's standalone
<maxb> ah, but it's a brand new branch, with no revisions
<jelmer> yuk
<maxb> oh, sorry
<maxb> False alarm, I ended up with a .svn dir I didn't know about
<vila> I'm nearly off, just wanting to mention that I made good progress on the p-i regarding bugs #589532 and #589523 (and thanks to the reporters for providing tyop-proof numbers, really mister boss mens, I appreciate) (with tests) and that I have a good hunch on the log file spamming
<ubot5> Launchpad bug 589532 in Ubuntu Distributed Development "imports hang from time to time when talking to the mass importer" [Critical,In progress] https://launchpad.net/bugs/589532
<ubot5> Launchpad bug 589523 in Ubuntu Distributed Development "mass importer doesn't handle hung-inactive processes" [Critical,In progress] https://launchpad.net/bugs/589523
<vila> Seriously, aren't those guys just great or what ?
<fullermd> Once upon a time, I had two phone lines, whose numbers differed by two digits being transposed.  It was great fun   :p
<maxb> Was there a recent change causing API version requirement violations to be warnings rather than errors? Because I vaguely remember that discussion, but I can't find the change.
<maxb> jelmer: When you said "The API requirements should no longer be strict - they should just cause warnings rather than be strict errors." what were you referring to? Plugins still fail to load for me if they violate requirements
<jelmer> maxb: poolie was working on that, I though it had already landed
<jam> jelmer: poolie made it so they would not show errors, but would just log that it is failing, and not import them
<jam> so now you have to do "bzr plugins" to see the failures
<jam> I think the next step he wanted to do was to make it so that they would still import
<jam> and we would just have that info when there was a crash, etc.
<jelmer> ah
<vila> jelmer: This was discussed at Dallas, I thought you were involved ? They may have been some variations...
<jelmer> vila: I was, but not aware of how much of it was implemented
<vila> maxb: it's the same modification that display the plugins after the traceback
<vila> small review queue, post-release effect
<poolie> hi arjenAU, spiv, jelmer
<jelmer> hi poolie, spiv, arjenAU
<poolie> :)
<arjenAU> hiyas
#bzr 2011-02-11
<mkanat> jam: pqm was a customized branch for launchpad specifically.
<mkanat> jam: It had changes that were only relevant to Launchpad.
<mkanat> jam: I have a feeling mwhudson didn't actually look over your merge code.
<mkanat> Since it was immediately obvious to me that some of those things should not have been merged back into the main loggerhead.
<mkanat> jam: It's also slightly mysterious why certain things were there that weren't on experimental, like HACKING.
<mkanat> jam: It's possible that when doing the merge you restored files that were removed on experimental, since pqm was based on the stable branch, not on trunk.
<lifeless> mkanat: this is part of sorting out th emess
<mkanat> lifeless: Sure.
<mkanat> lifeless: I'm sure that jam and mwhudson will be able to figure it all out.
<mkanat> I actually noticed the problem immediately when it was posted, but I'm not on contract anymore and I figured that somebody would notice it too.
<mkanat> Once this particular merge is handled it should be fine from here on out.
<mkanat> jam: BTW, I noticed that you've been keeping up the tests now, which is so awesome. :-)
<mkanat> jam: That was exactly what I was going to do next if I'd had a few more hours. :-)
<poolie> hi mkanat, lifeless, jam
<mkanat> Hey poolie.
<mkanat> I've left ~loggerhead-team for now--if anybody has specific questions that they want my feedback on, feel free to subscribe me directly or request review from me directly.
<palhmbs> I'm stuck!
 * palhmbs puts his hand up... how do I get my bzr branch uploaded to launchpad.... bzr push lp:~john.doe/+junk/myproject -- just says bzr: ERROR: Invalid url supplied to transport !!
<mkanat> palhmbs: You need a project first.
<mkanat> palhmbs: Then it would be like lp:~john.doe/myproject/trunk
<palhmbs> I have created a PPA -- do I -- bzr push lp:~palhmbs/~palhmbs/+archive/ppa-for-gtg ??
<maxb> No, +junk should work
<maxb> palhmbs: branches and PPAs do not directly relate
<palhmbs> ah - I see...
<palhmbs> so I have to set a location for my branch... under .bzr ?
<maxb> 'bzr push lp:~palhmbs/+junk/anythin' should just work, assuming you have registered a SSH key with launchpad
 * palhmbs has tried using groundcontrol... which got me logged in, but no further
<spiv> palhmbs: does "bzr plugins" list the "launchpad" plugin?
<palhmbs> spiv, yep - launchpad 2.2.1
<maxb> palhmbs: Could you try 'bzr push bzr+ssh://bazaar.launchpad.net/~palhmbs/+junk/something' ?
<spiv> palhmbs: is that the full text of the error?
<palhmbs> I've even wrote a ~/.ssh/config -- to help identify
<spiv> palhmbs: that error suggests to me that you have some sort of typo in your URL, e.g. if I typo my username in the URL I get 'bzr: ERROR: Invalid url supplied to transport: "lp:~spivv/+junk/hmm": No such person or team: spivv'
<palhmbs> spiv, no -- fulltext is:  bzr: ERROR: Invalid url supplied to transport: "lp:~palhmbs/ppa-for-gtg/trunk": No such project: ppa-for-gtg
<palhmbs> I did try -- bzr push sftp://palhmbs@bazaar.launchpad.net/~palhmbs/ppa-for-gtg -- but got -- bzr: ERROR: Permission denied: "/~palhmbs/ppa-for-gtg": [Errno 13] mkdir failed
<spiv> palhmbs: ah, that's your problem: "No such project: ppa-for-gtg"
<palhmbs> so um, where does it go when you push to +junk ??
<spiv> palhmbs: when you push to +junk it goes to +junk
<palhmbs> because bzr push bzr+ssh: -- is working... :-0
<spiv> palhmbs: you'd also be able to use "lp:~palhmbs/+junk/something" I'm sure
<spiv> palhmbs: "+junk" is basically a special name for "no associated project"
<palhmbs> thanks - right np
<spiv> palhmbs: otherwise that part of the URL has to be the name of an actual project on Launchpad
<palhmbs> and I have to package specially for a PPA...
<palhmbs> I see... I think -> b <- thumbs up
<palhmbs> ah well - my code can live in junk for awhile.
<mwhudson> yes, i have to admit i went by the description more than the diff for jam's branch
<jbowtie> I think there's a revision in my repository that *should* be the head revision for the current branch, but isn't.  Can anyone remind me how to locate it?
<mwhudson> jbowtie: bzr heads --dead
<mwhudson> which is in bzrtools
<jbowtie> mwhudson: thanks, I don't have bzrtools installed on this server, is why I couldn't find it.
<mwhudson> np
<jbowtie> OK, I do have a dead head, can I reattach it?
<mwhudson> if you already have a branch that should have that as a head, i think bzr pull -r $dead_head in the branch should be all it takes
<jbowtie> mwhudson: Hmm, didn't work. Looks like I will have to investigate further.
<mwhudson> jbowtie: what failed?
<mwhudson> maybe you need --overwrite or something, or maybe you should do 'bzr init new-branch; cd new-branch; bzr pull -r revid:$dead_head'
<mwhudson> ah, i forgot the "revid:" bit before
<jbowtie> mwhudson: Trying with overwrite; I knew enough to put in "revid:"
<jbowtie> mwhudson: It's trying to pull from the parent branch in a foreign vcs instead of pulling the existing rev from the repository.
<mwhudson> oh
<mwhudson> !
<mwhudson> jbowtie: pull -r revid:$deadhead .
<mwhudson> that . is important :)
<jbowtie> Brilliant, that did it.
<mwhudson> good!
<jbowtie> Interesting, there are two other dead heads that are missing from the branch history. I might need to write a splice command to insert them where they belong.
<thumper> hmm...
<thumper> I want to add an existing branch as a pipe in a pipeline
<thumper> not so easy it seems
<mwhudson> thumper: probably easiest to move the branch out of the way, add the pipe, and then move the branch back?
<thumper> mwhudson: I just did add-pipe oldbranch-copy, then pulled the other branch into it
<thumper> I really should file a bug on pipelines
<mwhudson> ah righ
<mwhudson> t
<mwhudson> yeah
<thumper> bug 716826
<ubot5> Launchpad bug 716826 in bzr-pipeline "Should be able to add an existing branch to a pipeline" [Undecided,New] https://launchpad.net/bugs/716826
<maxb> Is there a document I can read which outlines bzr's architecture concerning unicode and bytestrings?
<maxb> e.g. is revision.message supposed to be a utf8 bytestring or a unicode object. Likewise file-ids. etc.
 * maxb is trying to rescue bzr-xmloutput
<poolie> maxb i think this is discussed in HACKING
<poolie> generally, ids are utf8 byte strings
<poolie> (because they are normally opaque)
<poolie> messages, filenames, etc should match the general python advice of converting from bytes to unicode on entry/exit of the program
<maxb> ah.... I grepped doc/developer/ and found not much :-)
<lifeless> jam: I think I may have fixed the spam on proposals to lp:loggerhead
<lifeless> jam: please let me know if you get another
<jam> lifeless: I got one about 3 hours ago, but that predates your message from 30min ago
<lifeless> yeah, I changed it 30 minutes ago
<lifeless> it may be incomplete
<lifeless> at which point I'll be asking thumper
<lifeless> and then following htat reading code t figure out wtf the rules are
 * thumper looks up here
<jam> lifeless: just got a rejected message as of 1min ago
<lifeless> bah
<lifeless> what list ?
<jam> launchpad-bugs-owner@lists.canonical.com
<jam> looks like it was trying to send to "launchpad-bugs@lists.ubuntu.com"
<jam> X-Launchpad-Message-Rationale: Subscriber @loggerhead-team
<lifeless> ~launchpad
<lifeless> sigh
<lifeless> what branch
<jam> lifeless: that was trunk-into-experimental, so the target should be ~loggerhead-team/launchpad/experimental
<jam> I don't know about others yet
<jam> though I'll be proposing something tonight
<lifeless> they need to be configured individually
<lifeless> right, changed the subscription for loggerhead team to 'no email'
<lifeless> mmm
<lifeless> actually, I'll try a direct sub + no email on that
<lifeless> this is a fraking annoying list config
<lifeless> fingers crossed
<lifeless> mwhudson: hi
<lifeless> mwhudson: what stops us using loggerhead as an egg?
<mwhudson> lifeless: probably nothing
<lifeless> does lp import it as a bzr plugin, or as a top level item?
<mwhudson> top level currently
<lifeless> cool
<lifeless> ok, we might want to do that soon
<mwhudson> otherwise my answer would have been different :-)
<mwhudson> yeah, should be easy
<maxb> jam: ooi, why would PQM be good for lp:loggerhead (compared with pretty much all the other bzr plugins in Launchpad not using it) ?
<poolie> maxb, what do you mean?
<jam> maxb: because *I* want it?
<jam> poolie: none of the bzr plugins use a bot to manage trunk
<poolie> if you want to set one up i'd rather we try this on tarmac
<maxb> Indeed. I am just curious as to the motivation for doing loggerhead differently
<jam> poolie: well, I don't want to maintain it..
<jam> or have it running on my personal hardware, etc.
<jam> I certainly don't want to have to be online for people to land things
<poolie> and you feel you'd have to maintain it if it was tarmac but not pqm?
<poolie> no, i don't think you should either
<poolie> and i think enforcement of the test suite would be good
<jam> poolie: does canonical have Tarmac running in the DC somewhere?
<poolie> yes, i believe other teams are using it
<poolie> u1 iirc
<jam> since I've poked on the project, it was always run on personal hardware
<jam> but that was a while ago
<jam> lifeless: so far, I can't tell the colorscheme difference between old-trunk and pqm, I'm still trying to figure out the screeshots you would want
<jam> looks pretty identical to me
<jam> stupid, that's because I reverted it to experimental's tip, where I had already merged the trunk updates....
<jam> stupid stupid
<jam> lifeless: pqm's loggerhead uses orange, Experimental uses blue
<jam> for the menus at least
<lifeless> so, I'd like someone - curtis perhaps, or huwshimi, to be briefed on the situation, and make a recommendation.
<lifeless> jam: does the raw controller output the byte content directly, or does it htmlise it just without annotation ?
<jam> lifeless: raw content
<jam> no html
<jam> same as /download but not Content-disposition: Attachment
<lifeless> in which case thats an experimental only thing, right ?
<lifeless> its not in trunk yet
<jam> lifeless: I believe so
<lifeless> cool
<lifeless> I won't leap on it in a panic then :)
<jam> lifeless: thats the xss concern?
<lifeless> yes
<lifeless> I know there is a similar answer to lps, but we need to write the glue - which includes adding a API for allocating the time limited tokens and gluing that into the Application
<vila> hi all !
<mr-russ> Hi,
<mr-russ> more questions today.
<mr-russ> When converting from SVN, can I get tags converted bzr tags rather than branches?
<lifeless>    exarkun@divmod.com-20110209125926-8d98psdzhqru0vrs
<poolie> mr-russ, i think bzr svn-import can/will do that?
<mr-russ> K, I used svn2bzr.py and it's not created a shared repo or tags that do what I want.
<mr-russ> will look further at svn-import.
<mr-russ> What is the implication of non-determinsic revisions?
<mr-russ> I got a little worried when reading that in the docs as I don't know the implications of it.
<mr-russ> svn$ bzr svn-import civian
<mr-russ> Using repository layout: trunk0
<mr-russ> bzr: ERROR: exceptions.TypeError: fetch() got an unexpected keyword argument 'needed'
<mr-russ> ??
<poolie> that looks a lot like an out-of-date plugin
<poolie> please file a bug with the traceback from .bzr.log and paste the number here
<mr-russ> just installed against lucid.
<poolie> or just update bzr-svn
<mr-russ> will file bug now.  is there a fast way from command line to do it?
<mr-russ> it fails because I wasn't importing into a repository.
<mr-russ> which it didn't complain about.
<poolie> ah, well, that's a bug worth filing
<poolie> but lucid's a bit old, and it might be fixed by now
<poolie> there's a ppa with newer builds of bzr and plugins
<Lo-lan-do> Hi all :-)
<Lo-lan-do> It seems that bzr diff --using "wdiff -n" ceased working recentlyâ¦  Is that known?
<Lo-lan-do> It apparently tries to run a command called "wdiff -n", rather than running wdiff with a -n option.
<Lo-lan-do> strace shows: execve("/home/roland/bin/wdiff -n", ["wdiff -n", "/tmp/bzr-diff-Gf9RoE/old/Makefil"...,
<jelmer> Lo-lan-do: not sure - can you file a bug?
<Lo-lan-do> Sure
<mr-russ> I migrated from svn, my tags are now showing in bzr tags;  as TagName  ?
<mr-russ> I thought, there are not version numbers, so the tag is useless.  I'll delete those tags.
<mr-russ> when I delete a tag and try and commit, it tells me nothing has changed.  How do I commit and push/pull tag changes?
<mr-russ> bzr 2.1.x lucid installation
<jelmer> mr-russ: you can use them, but since they have no relation to the curretn revisin tip we can't print a revision number
<jelmer> mr-russ: tags are independent of commits in bzr
<mr-russ> really.
<jelmer> after a tag has been deleted there's no need to do a commit
<mr-russ> how to I keep tags in sync between people.
<mr-russ> get push the tag delete.
<mr-russ> How do I push the tag addition or deletion,  as push says, no revisions to push.
<mr-russ> https://lists.ubuntu.com/archives/ubuntu-mobile/2008-March/001625.html
<jelmer> push will actually push new tags even if there were no revisions pushed
<mr-russ> hopefully that comment is true.
<mr-russ> Not exactly noob friendly though.
<jelmer> yes, the push ui should be clearer if it actually updated any tags
<mr-russ> another question about my ? tags.  How do I use them.  If I bzr update -r tag:Release_1_1  I get;
<mr-russ> bzr: ERROR: branch has no revision svn-v4:deb830e7-bb10-0410-bcbb-ea420f43d34b:tags/Release_1_1:16
<mr-russ> bzr update --revision only works for a revision in the branch history
<mr-russ> jelmer: You said I could use them, however I'm not sure how to.
<jelmer> e.g. 'bzr branch yourbranch -rtag:Release_1_1 newbranch'
<jelmer> depending on how the branch was cloned it might not have copied all the tag contents though
<jelmer> svn-import should have copied all the tag contents
<mr-russ> yeah, but I put that on a remote shared repository.  I think branched trunk.
<mr-russ> $ bzr branch . -r tag:Release_1_1 ../civian-1.1
<mr-russ> bzr: ERROR: The branch . has no revision <RevisionSpec_tag tag:Release_1_1>.
<mr-russ> so trunk doesn't have the tag revision information?
<mr-russ> I think I was better off when not attempting to import from svn.
<jelmer> mr-russ: svn-import will import all the tags, and there's an open bug about 'bzr branch' importing all the tags even if they're not pointing at revisions in the branch itself
<mr-russ> okay.  I might just delete them as they are confusing and move along.
<jelmer> if you're doing a conversion, I'd recommend svn-import
<jelmer> if you're just trying to contribute to an existing svn branch, bzr branch
<mr-russ> I ran svn-import to convert a repository.  Put that repository using scp on another server.  then did bzr branch remote_location;  bzr tags
<mr-russ> and have the ?'s
<mr-russ> interesting.  delete tags, bzr push.  tags gone.  bzr pull, tags back.
<bialix> heya
 * bialix looking for vila
<bialix> bonjour vila
<vila> hey bialix !
<bialix> I have question about our internal config machinery
<vila> .me all ears
<vila> bialix: I'm still holding my breath, don't be too long ;)
 * fullermd waves vila around by the ears.
<vila> ouch
<vila> I'm not *that* small anymore you know !
<fullermd> Well, it's probably more comfortable than bialix jamming our internal config machinery into them...
<bialix> sorry
<bialix> phone call
<vila> haa, ok, np
 * vila breathes again
 * vila goes to polishing config rough edges a bit more to ease with ears
<bialix> Bug 716384
<ubot5> Launchpad bug 716384 in QBzr "size of qdiff windows invoked from qcommit (pending merge) is default" [Undecided,Invalid] https://launchpad.net/bugs/716384
<bialix> vila: in qbzr.conf I have such line
<bialix> diff_window_maximized = True
<bialix> in qbzr/lib/utils.py we trying to read it
<bialix> is_maximized = config.get_option(name + "_window_maximized")
<bialix> the bug is:
<bialix> first time the option read as u'True' (unicode sting)
<bialix> second time the option read as bool True
<bialix> why?
<vila> O_o
<fullermd> The machines...  they're taking over!
<vila> err, short answer will be use get_user_options_as_bool
<bialix> vila: you mean always use another method?
<vila> bialix: I mean stop relying on configobj, use bzrlib.config ;)
<bialix> bzrlib.config does not have the method to delete options
<bialix> or it has now?
<vila> bialix: more half-seriously, configobj can be weird, I can't answer precisely, that may be a configobj bug, but you could probably avoid it using bzrlib.config
<vila> it has now
<vila> well, not all cases are covered but the ones you use should be (not all sections can be reached now I think)
<bialix> I need Gary to talk about
<vila> err, looking at the code, even sections are supported
<vila> so the missing bit is probably only in 'bzr config' actually
<vila> i..e: you don't have to care
<vila> 'bzr config' doesn't support qbzr.conf either anyway
<vila> by the way, if you move to bzrlib.config only, the long term plan is that qbzr options should be supported by bazaar.conf, locations.conf, branch.conf, zoo.conf by prefixing them by 'qbzr.',  i.e. qbzr.log_window.size and the like
<vila> or even qbzr.log.window.size or whatever
<vila> not sure it makes sense to have branch specific window locations though
<bialix> ÑÐ»
<bialix> ok
<vila> but at least you'll get the opportunity to decide and won't need to handle an additional config file anymore
<bialix> thank you vila
<bialix> I need to talk with Gary first
<maxb> it may be better to not put gui sizing caching in bazaar.conf
<bialix> he has changed our internal config machinery a lot in the recent times
<maxb> it irks me that bzr-gtk does
<bialix> maxb: it's not actually
<maxb> as this makes sharing a bazaar.conf between machines messy
<bialix> btw vila, if configobj so weird as I think what if the same bug will be hit by bzr core with reading bool option twice?
<bialix> ah, I see
<vila> bialix: well, get_user_option_as_bool with return either a bool or None, but never a string
<bialix> you have explicit check that incoming value is a string in bool_from_string
<bialix> actually that method returns either object itself (bool) or convert from string
<vila> maxb: yup, that's one thing that should be considered. The idea is that you define ConfigOptions specifying in which files they can appear
<bialix> I'm going to adopt that function only for now
<vila> bialix: use the one from ui and you'll be fine until you migrate to bzrlib.config
<bialix> ok
<bialix> many thanks
<bialix> even talking to wise man help to understand the problem and solutions
<vila> maxb: deciding in which file config options should be allowed become trickier when remote branches or repos are involved (not to mention bazaar.conf and locations.conf on a smart server...)
<vila> maxb: and that's ignoring the side-effects if both  smart and a dumb server are used for the same branch (with config files access allowed for the smart server but not for the dumb one...)
<bialix> vila: ok, another problem
<bialix> it seems configobj can't store to config bool value
<bialix> do you have set_option_as_bool in bzrlib.config?
<bialix> configobj -> :-/
<maxb> Hi poolie  - thanks for the ~maxb/bzr/make-lp-mirror-work review - was that "good, I'll PQM it later when I have a moment" or "good, find someone on IRC to PQM it" ?
<fullermd> Speaking of qbzr, what's up with the fix on bug 715067?  Shouldn't it fall back to bzrlib?
<ubot5> Launchpad bug 715067 in QBzr "No module named configobj error with debian patched bzr-2.3.0" [High,Confirmed] https://launchpad.net/bugs/715067
<jelmer> hi jam
<bialix> vila: bzr config --scope <-- ???
<bialix> what scope could be?
<bialix> fullermd: yes, it should
<jelmer> maxb: I think poolie is off for his evening, I can have a look at landing it
<bialix> actually it should use copy from bzrlib first
<vila> bialix: afk abit, will answer later
<jelmer> spiv: still there?
<bialix> vila: np
<vila> bialix: so, set_user_option is enough, we store only strings and there is probably a '%s' somewhere in configobj for turning bools into proper strings
<bialix> vila: apparently it's not
<bialix> I mean configobj lost boolean options for me
<vila> bzrlib.config
<bialix> ok. I understood you
<bialix> already sent mail to Gary asking
<vila> the idea is that only strings are handled in files, get_user_option_as_xxx just convert for convenience, every{thing,one} else should deal with strings and only strings
<vila> unicode even, stored as utf-8 in config files
<bialix> the idea is perfect, but the reality is not
 * bialix is not happy
<spiv> jelmer: sort of
<Miika--> Hello! I first added accidentally some files to my bzr repo and then I did bzr revert and added right files and committed. But thing is, that I really didn't know what revert does... So all the work I hadn't changed was gone from working copy... Is there any way to get them back?
<jelmer> Miika--: revert should have created backup files for all the files it reverted
<Lo-lan-do> Look for the *.~1~ files
<Miika--> Oh, thanks a lot. Everything ok.
<jelmer> maxb: hi
<maxb> hi
<jelmer> maxb: One of the points of the daily builds is to catch the test failures, I'd rather not mask them by running the tests in a UTF8 locale
<maxb> jelmer: bzr-xmloutput's encoding behaviour is pretty broken internally. As far as I can tell, the entire plugin is only sanely usable in a UTF-8 locale at all. It needs a major internal overhaul for sane encoding behaviour
<jelmer> maxb: if it's really that bad I think we should probably not ship it at all, or at the very least it would've been nice to discuss this change upfront
<maxb> The reason I felt comfortable directly committing the change was that I believed that there was absolutely no possibility of the testsuite passing otherwise - was I wrong in that belief?
<pindonga> hi, I want to write a python script that uses a bzr plugin internally... is there an easy way to access a plugin's code, as that resides not in the standard python path?
<pindonga> I was thinking of using some utility of bzrlib to get to the plugin maybe?
<jelmer> maxb: that's not wrong, but the goal is to actually fix the test failures rather than hiding them
<maxb> Agreed - I wouldn't have done that to mask test failures, I only thought it a reasonable course of action because the actual non-test plugin code is just outright broken in non-UTF8 locales, so at least this makes the tests test the current capabilities of the plugin
<maxb> pindonga: import bzrlib.plugin; bzrlib.plugin.load_plugins(); import bzrlib.plugins.myplugin
<pindonga> maxb, great! thanks
<jelmer> maxb: Fixing the plugin for non-utf8 locales isn't impossible, so it would've been nice to discuss this.
<jelmer> maxb: Anyway, not to take away from all the other nice work you've done on getting the daily builds working again.
<jelmer> maxb: Are you going to forward the bzr-dbus patch upstream?
<maxb> jelmer: Understood. Again - the only reason I even considered this committable was because I thought I was taking the packaging from a state of being completely unbuildable on any buildd - and thus I couldn't possibly be making things worse, since I *believe* it could never build before.
<maxb> Have the bzr-xmloutput tests ever passed on a buildd before?
<jelmer> maxb: no, which is exactly why I didn't mind that they were failing - bzr-xmloutput simply wouldn't land in the daily builds PPA until the plugin was fixed
<maxb> <jelmer> maxb: Are you going to forward the bzr-dbus patch upstream?  --- whoops, I pushed it but forgot to merge-propose. Done.
<jelmer> maxb: r=me
<maxb> Regarding the bzr-xmloutput tests - since it's present in ubuntu and debian, I think it's a net improvement to be able to run the tests on build in a forced UTF8 locale than not being able to run the tests on build at all
<maxb> But yes, it's not a good final state to remain it.
 * maxb --> lunch
<jelmer> maxb: why the extra PYTHONPATH override in bzr-dbus' debian/rules /
<jelmer> 'morning jam
<vila> jelmer: hi almost-PP ;) I'm not sure jam is up yet, there have been random reconnections for a couple of hours
<maxb> jelmer: slightly pointless here, I suppose. It's there because I copied the concept from something I was working on for bzr itself, where it lets the compiled extensions be loaded.
<jelmer> maxb: ah, ok
<fullermd> Yeah, who in his TZ would be up at this time of day?   :p
 * jelmer has learned to stop looking for a correlation between location and timezone
<jelmer> vila: heh, ok
<vila> fullermd: between you and jelmer, I long ago stopped trying to correlate presence here and TZs
<vila> hmm, I should have included myself in this list ;)
<fullermd> Nah, _we_ never tell you anything.  Why should you?
<vila> I don't need anybody to listen to when I talk here ? Is that what you're saying ?
<fullermd> Eh?  Who said that?
<jelmer> Did somebody say something?
<guilhembi> jelmer: hello! I'm reading a debian changelog:
<guilhembi>   [ Jelmer Vernooij ]
<guilhembi>   * Cherrypick fix for compatibility with python2.7 >= 2.7.1-2.  LP: #693880
<guilhembi>   * Switch to python-support. Closes: #568462
<guilhembi>   * Add missing build dependency on python-configobj.
<guilhembi>   * Make dependency on python-testtools versioned (>= 0.9.5).
<guilhembi>   * Re-remove included elementtree and configobj. Closes: #555343, #555336
<guilhembi> ...
<guilhembi>  -- Jelmer Vernooij <jelmer@debian.org>  Fri, 21 Jan 2011 22:08:19 +0100
<guilhembi> So in the debian version of bzr, bzr's configobj is removed. Is that "deviation" from the stock bzr expected to stay?
<guilhembi> I'm asking, because it caught us: we have a plugin which does
<guilhembi> "from bzrlib.util.configobj import configobj"
<guilhembi> and it always worked, and it still works with bzr.dev or the normal bzr installs, but not with Debian's latest bzr...
<guilhembi> We solved it by falling back to the system configobj if bzr's is missing, but I thought I'd ask...
<guilhembi> eof
<jelmer> guilhembi: it's actually been there in the past as well, but because of a regression we still shipped it
<jelmer> guilhembi: we could import the system configobj to bzrlib.util.configobj, but one of the concerns is that the system configobj isn't exactly the same as the one that is shipped with bzr
<guilhembi> jelmer: won't there be deviations over time: if bzr's configobj behaves differently from the system configobj, bzr will break on Debian...?
<guilhembi> Or is there a plan to delete configobj from the stock bzr too, to be consistent everywhere?
<jelmer> guilhembi: we can verify it's sufficient for bzr - we run the testsuite to do so
<guilhembi> ok...
<jelmer> guilhembi: I don't think there are any plans to remove it from stock bzr, but we should probably make it private
<maxb> I was going to try to insert some sort of compatibility, but it turns out it's not trivial to alias a python module under a different name.
<maxb> You can make it work, I think, if you're willing to assume everyone uses "from bzrlib.util.configobj import configobj", but you can't make it fully compatible such that "import bzrlib.util.configobj.configobj" works as it did before the removal
<jam> jelmer, vila: Well, I did reconnect to IRC, but I wasn't really online yet. I think my son was playing with my laptop while I was sleeping.
<vila> haaaa, this explains all these branch deletions then, I was wondering...
<vila> jam: morning :)
<jam> maxb, guilhembi: On Debian and Ubuntu we plan on using the system configobj if possible. I believe we just didn't want to require people running from source to have it installed. (We did the same for ElementTree a long time back.) As for divergence... that is why we run the tests as part of the build process now.
<jam> vila: oh noes! my super-important-but-not-backed-up work
<jam> vila: I guess it's bzr revert for me
<vila> :)
<maxb> jam: I think the problem here is more that by placing copies within bzrlib.util, they become part of bzrlib's API in the perception of plugin authors
<guilhembi> maxb: indeed, in the latest qbzr:
<guilhembi> ./lib/util.py:from bzrlib.util.configobj import configobj
<guilhembi> (http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk/)
<guilhembi> that will break on Debian, unless Debian has a custom qbzr?
<jelmer> Debian has a patched qbzr, but the qbzr devs are also fixing it upstream
<fullermd> Yeah, right now it's fixed so it doesn't work on my non-Debian system   :p
<jelmer> fullermd: what's a non-Debian system ? :P
<fullermd> jelmer: It's a thing with up to date software   :p
<ssandberg> hi! when bzrgtk is installed, is there a way to detect from a pre-commit hook of another plugin whether this was a gcommit or a commit ?
<jelmer> ssandberg: not really - why would you want to?
<jelmer> ssandberg: I mean, you could inspect the stack..
<ssandberg> jelmer, the plugin needs to display a message. would be nice if the message was a dialog for gcommit and a text for commit
<jam> maxb: everything in util is 3rd party code, hence the 'util' section. So the general recommendation is to do stuff like "try import foo except ImportError: import bzrlib.util.foo" or something along those lines.
<jam> (possibly reversed)
<maxb> Right, but is that actually stated as a mandatory rule of bzrlib api compatibility?
<jml> hello
<jml> just another vote for fixing that thing where merging branches that delete directories that contain build artifacts causes conflicts.
<vila> jml: you haven't paying attention to bzr.orphan_policy=move don't you ?
<vila> s//been/
<vila> err, bzr.transform.orphan_policy=move
<jml> vila: no. it's been a long time since I've read NEWS file, and I don't recall seeing it mentioned in release announcements.
<vila> jml: it's off by default :-/
<vila> jml: I thought you were subscribed to the relevant bug and every day since I landed the fix I waited for your feedback ;-(
<jml> vila: I saw that it had been split into two bugs and lots of talk about possible ways of fixing but nothing about it actually being fixed. maybe it slipped by.
<vila> hmm, I don' remember the details... oooh, now that you mention it, yeah a more complete solution has been asked for, but for your particular case, the config option should do
<vila> jml: as always, bugs and feedback welcome ;)
<vila> jml: and sorry for not telling you more directly, I didn't realize you missed it
<jml> vila: np.
<vila> jelmer: I didn;t dream after all: bzr-builddeb 2.6+bzr518~lucid1
<jelmer> vila: ah, the daily builds have 2.6 :-/
<vila> yeah, so the upstream should too no ?
<vila> jelmer: and sorry for not pointing you there yesterday, Alzheimer... you'll see... pain...
<jelmer> no, the daily builds debs have it completely wrong - they claim to be /post/-2.6
<jelmer> vila: hey, you're talking to the guy who probably actually set it to 2.6 in that recipe...
<vila> lol
<vila> thanks, I feel better ;)
<vila> grr, no whoami set, grr
<jelmer> vila: What, and bzr let you commit without a whoami set??
<vila> hehe, no indeed
<vila> but in this particular case I don't want to set one... err... let me explain :)
<vila> on my local package importer I don't want a whoami set in bazaar.conf, except that I'm fixing a bug and I need to commit...
<vila> and I don't think I can set one in branch.conf... let's try locations.conf
<vila> Yes !
<vila> <evil grin>
<jelmer> hehe
<vila> jelmer: point is (playing the devil's advocate), the actual behaviour suits me :)
<jelmer> vila: would it have been sufficient if it just warned?
<vila> if we add a warning, we may think about adding an option for restoring the *actual* behavior
<vila> in that precise case no
<jelmer> I guess we can have a tri-state option ("strict", "guess", "warning") that defaults to "warning" ?
<vila> I want to stay without a default whoami because I'm paranoid here, I don't want to commit anything so I won't push anything to lp
<vila> but that's one a good reason to keep the actual behaviour as the default one, hence the option mentioned above
<jelmer> jam: hi
<jelmer> jam: I'm digging into my lazy hooks work again, and am wondering if your comments on lp:~jelmer/bzr/lazy-hooks-pt1 were perhaps intended for lp:~jelmer/bzr/lazy-hooks ?
<jam> jelmer: possibly
<vila> jam: did you get some feedback on the forked server ?
<jam> vila: I've put up a lot here: https://wiki.canonical.com/IncidentReports/2011-02-11-Codehosting-Forking-Service-Down
<jam> from what I can glean from the logs
<jam> but there is a 30-min gap where we don't have any logs... :(
<jam> and things are fine before it, and failing after it
<jam> the forking service itself was up and running and still servicing connections until it was stopped
<jam> so it might be bugs in the Twisted code I wrote
<jam> by the time it started failing (that I can see) it seems that Conch was out of file-handles
<vila> ha, right, so, AIUI, there was some 'no more fd available' at some point
<jam> maybe we have a handle leak in there
<vila> yup
<jam> vila: well, there were a lot of "no random entropy source available" which could have been masking no-more fd
<jam> but there was one no more fd at some point
<vila> right, that was the piece of info I wanted to make sure you had
<jam> vila: any idea why os.urandom would be failing?
<jam> I was trying to check the Python source code, but it looks to me like "urandom" is only available for #MS_WINDOWS and #__VMS, but that doesn't make any sense, since I see it on babune
<vila> O_o
<jam> but the code tries os.urandom before it tries to open the file
<vila> /dev/urandom exists here indeed
<jam> vila: so, in "os.py" if there isn't a built-in random, it creates one by opening /dev/urandom
<jam> built-in urandom
<jam> however, that also doesn't make sense, since Babune says it is a builtin function
<jam> ah wait, that is locally, let me check babune again
<jam> it is the native one
<jam> which opens the file
<jam> vila: so... if open() is failing, then you will, indeed, get secureRandom failures
<jam> now the question is how do you find those...
<vila> jam: IMHO you'd better check on the code hosting host, it probably runs lucid for one so babune may not be the best reference
<vila> hosting host...
<jam> vila: I just checked the python source code. I'm not worried about it, I doubt it changes much
<jam> /usr/lib/python26/os.py
<jam> Implements 'urandom' in pure python by opening /dev/urandom
<vila> bzr 2.3.0 is still in the upload queue :-/
<vila> what;s the process from there ? Is it automatic or should someone approve something ?
<jelmer_> vila: which upload queue?
<vila> https://launchpad.net/ubuntu/natty/+queue?queue_state=0&queue_text=&start=30
<jelmer> I think it needs an archive admin to look at it
<jelmer> uhm
<jelmer> I think it needs be looked at by an archive admin
 * vila summons archive admins
 * vila needs more goats
<jelmer> hehe
<fullermd> I've got a chicken with a mean temper; is that close enough?
<vila> fullermd: what ? You're supposed to be my goat official provider remember ?
<vila> nokia/microsoft and now no more goats >-/
<vila> I can live without a mobile phone but...
<jelmer> maemo was great in that it could run bzr-gtk out of the box :)
<fullermd> Sadly, work has got my goat.
<vila> wow, you mean you work with no goat at all now ? Scary...
<fullermd> Well, wandering around bleating about it won't help anything, so...
<jelmer> vila: I'm trying to add a function somewhere that returns an old bzr format (e.g. one that uses old style locking, or doesn't support stacking)
<jelmer> vila: and I'm not sure where to put it. bzrlib.tests.TestCase already has enough stuff on it. Would it work as a fixture?
<vila> jelmer: whatever you chose, make sure it's well hidden ;)
<vila> fixtures sounds like a better place than test case, especially if you prefix it when you use it ;-D
<jelmer> vila: did you see my comment about the contact address for udd?
<vila> no ?
<jelmer> vila: it still mentions james as the contact address in case of broken imports at the moment
<jelmer> vila: s/it/the web page/
<vila> hmm, right (how did I miss that 8-/)
<vila> s//#bzr on freenode / ?
<jelmer> vila: in the MP
<vila> ooh, I see your comment now, I often have a hard time when you don't leave a blank line ;-/
<vila> but do we want to put a real email there ?
<vila> I thought james_w put his name (instead of his email) to avoid spam ?
<jelmer> vila: Perhaps we could just mention the list, or the bug tracker
<jelmer> I'll try to remember to leave a blank line next time :)
<vila> jelmer: the bug tracker is now mentioned, I was about to put an URL for the list, but the page contains the email, so i think I will just put the email ;)
<jelmer> wfm :)
<cody-somerville> Is there a document that describes bzr error codes?
<cody-somerville> It seems like 3 is used when there are no changes to commit AND when the bound branch is out of date with the master branch.
<jelmer> cody-somerville: IIRC we use three different exit codes - success, failure and success but e.g. differences (for bzr diff)
<jam> cody-somerville: we only really use 0, 1, 3
<jam> cody-somerville: and I'm pretty sure we don't distinguish for those particular cases
<shakaran> Hi, I would contribute with bazaar translating the docs to spanish, where should I start for find the files, maybe on rosetta launchpad?
<fullermd> I'm pretty sure it's all in a branch somewhere; I don't believe the bzr project uses Rosetta.
<cody-somerville> Odd.
<cody-somerville> I just did an update of a branch that fetched a single small revision, that took 7.675s. Doing it again took 7.970s immediately after (tree is up to date).
<lifeless> most of that is probably ssh handshaking
<lifeless> + bzr invocation on the server side
<lifeless> we have an improvement in the works but it blew up when we deployed it last night
<cody-somerville> ah, cool.
<jam> cody-somerville: "time echo hello | ssh bazaar.launchpad.net bzr serve --inet --directory=/ --allow-writes"
<jam> that gives the baseline time for bzr to handshake to the server
<jam> hi lifeless
<lifeless> hi jam
<jam> lifeless: the symptoms all point to a file-descriptor leak, but I haven't been able to reproduce it yet.
<lifeless> jam: ouch
<lifeless> unreproducable issues suck
<jam> yep
<jam> lifeless: argh... 'make run_codehosting' dump the file handles I'm using. Spawn 20 connections, it goes up to 60, next connection, back down to 12,13,14, perfectly clean
<lifeless> jam: its using 3 fds per connection ?
<jam> lifeless: stdin, stdout, stderr, yes
<lifeless> jam: how long does it hold them open ?
<vila> . o O (A thread with its 3 subprocess file handles not join'ed  ?.... ? ... ? 40% bet)
<jam> at the time the forking service was shutdown it claimed to have 138 children active
<jam> that is about 400 file handles
<lifeless> accounted for, yes.
<lifeless> did we get an lsof ?
<jam> lifeless: we didn't get any extra debug info, AFAIK
<vila> hmm, I'm pretty sure wgrant pointed to a graph with ~300 connections
<jam> I wasn't around
<lifeless> so
<lifeless> we have this live on qastaging
<lifeless> hammer that?
<vila> +1
<vila> with hammer >> 300
<jam> lifeless: I did a hammer of it when we were deploying it, running 10+ concurrent connections for ~10 hours and didn't see it
<jam> but yes, we can do more
<jam> vila: I'm checking https://lpstats.canonical.com/graphs/CodehostingCrowberryConnections/ now
<vila> jam: if it's related to some limits setting you may run 10 years if you're below
<jam> vila: sure, but getting 300 concurrent connections is way over what we've generally seen. 138 is high
<jam> it is certainly possible
<jam> lifeless: I can say that for "echo hello | ..." the file handles are closed ~ as soon as the process exits
<lifeless> our log files should tell us the concurrency we see
<vila> hmm, I think the graph was showing an average of ~260
<lifeless> jam: hang on
<jam> lifeless: they do, but it is a bit tricky
<jam> vila: just waiting for lpstats to actually graph something
<lifeless> jam: why are the file handles kept open in the parent at all ?
<jam> lifeless: to ferry the content from the bzr process to the client
<jam> same as before
<jam> no more file handles than we used to have
<jam> just to a different process
<lifeless> ok
 * lifeless is imaginging a design where once handed off the fds are only needed by the bzr-sftp service
<lifeless> less handshaking as well
<vila> jam: meh, me too, wth ?
<lifeless> lpstats has a linear-growth design
<lifeless> we're pushing its capacity
<vila> . o O (Or spwan a clone once you reach too many fds)
<lifeless> first thing I think is what jam is already doinig - reproduce
<jam> vila: or run multiple front end services load balanced across instances... ooh look, already working on that :)
<vila> :)
<vila> jam: well done ;)
<jam> lifeless: right. As for lpstats, not having intermediate filtered content is a bit of a pain. Just a denormalized table with pre-averaged samples by day or something would probably make a big difference
<jam> vila: https://lpstats.canonical.com/graphs/CodehostingCrowberryConnections/ link is cached now
<jam> spikes of active connections up to 360
<jam> but the important ones *should* be Active Smartserver Processes
<vila> yup, same here, not the one wgrant showed me, 100% sure
<jam> which is pretty much always under 100, usually under 90
<jam> or even average of about 40
<vila> https://lpstats.canonical.com/graphs/CrowberryProcesses/20110211/20110212/nocache/
<jam> I don't really know how those are computed, though
<vila> ~sure the fork server was killed at the peak
<jam> vila: the peak of 360 I see is back on 2011-01-29
<jam> but I'm checking your graph
<jam> vila: the # of processes
<jam> there is ~200 baseline processes on Crowberry
<vila> indeed
<jam> so that is only 320 - 200
<jam> or 120 new bzr processes
<vila> when this was occurring I couldn't even get 'bzr info lp: xxx' working
<jam> vila: well, some people could
<vila> jam: not 'bzr pull lp:bzr'
<jam> I saw connections made and finished
<vila> hmm
<jam> it depended when a connection would close so that handles would free up
<jam> and then get used by the next connection
<lifeless> jam: how well did it perform before it went bang, do we know ?
<jam> vila: there does seem to be an issue with child processes not terminating immediately.
<vila> at the time it was switched off, nobody in the #launchpad-ops mentioned a successful connection which was part of the decision to switch it off
<jam> lifeless: very hard to tell from this graph: https://lpstats.canonical.com/graphs/CodehostingPerformance/20110211/20110212/
<vila> jam: I just give you my feeling, better check the irc logs...
<jam> the problem is the 23s spike drowns out the numbers
<jam> vila: sure. I'm just going through the disk logs and seeing a new connection come in, and successfully exit
<jam> I don't doubt that it could have been a 90% failure rate
<jam> looking at bzr-sftp.log
<jam> lots of "I can't open a new file"
<jam> I don't know what would have happened if we just restarted without disabling the forking code
<vila> then that's an additional data point, not all of my connections failed, the other only hung
<jam> ATM, I'm wondering if there is a failure condition that is leaving the spawned bzr processes still alive
<vila> jam: yeah, *I* would have wait a bit longer, but it's  easier to say when your finger is not on the trigger
<jam> vila: what really bothers me is that the 30 minutes that are probably the most interesting, are just completely missing from the logs
<jam> somewhere between bzr-sftp.log.10 and bzr-sft.log.11
<jam> I see the process get started, things get handled fine
<vila> jam: on the flip side, *I* wasn't expecting troubles either, so when they showed up...
<jam> and then 11:01 ish, they are all dying with no file handles available
<jam> vila: what also concerns me about: https://lpstats.canonical.com/graphs/CrowberryProcesses/20110210/20110212/
<jam> is that the baseline has moved
<jam> even after restarting the machine
<jam> it was 200-240
<jam> it is now 260-280
<vila> jam: yeah, I encounter the same problem when my HDD died and they were no trace in the logs because.... well, the systeme couldn't tell me...
<vila> jam: blame the p-i ?
 * vila hopes jam can connect my replies to his remarks :-/
<vila> jam: I'm long EOD, take my thoughts as random inputs, I offer no guarantee on their technical merit ;)
<fullermd> vila: Well, they'd still be written to the other drive in your RAID, right?   :p
<vila> fullermd: indeed not, and the more I think about it, the less I'm tempted by RAID as a substitute for good backups and admin mods versioning :-P
<jam> vila: serve different purposes. but certainly important
<jam> RAID won't save you from rm -rf /
<jam> backups don't save you from hardware crashes
<jam> especially hot-swap RAID
<fullermd> Actually, the one time I did that (intentionally; the box was being decomissioned), it blew away something the system needed before it got done.  So rm -rf / saved me from rm -rf /   :p
<vila> fullermd: hehe, doesn't feel the same when you really tried it ;)
<vila> jam: but yeah sure
<vila> my current experiment starts from the assumption that we crossed the point where you can archive what matters for... ever
<jam> fullermd: certainly, I can imagine it removing a kernel module that it wanted to read, etc.
<vila> so I have ~10 full backups of the important family data
<jam> vila: except how can you archive those 10 backups... wait
<fullermd> Well, I dunno what it ended up being.  But it stopped cold before it finished the rm.
<fullermd> 'course, I've also induced hard "failures" by putting small pieces of metal at very high speeds through the drive.  Not while it was running though; maybe I should try that sometime...
<vila> fullermd: err, how did you achieve the high speed then ?
<vila> fullermd: Or is it just a way to say you *throw* them ?
<fullermd> Extremely exothermic chemical reaction inside a small brass case.
<vila> :)
<vila> bra what ?
<fullermd> i.e., I shot it   :p
<vila> hehe, indeed , for same value of throw ;-D
 * vila off... really ;)
<wgrant> jam: Sorry, I was more concerned about getting codehosting back up. Did minimal gathering of what processes were around, and then restarted everything.
<wgrant> jam: Some connections did succeed.
<jam> wgrant: I understand
<wgrant> But then hung.
<jam> just hard to debug the next day with only so much logging
<wgrant> Most were dropped during kex.
<wgrant> Yeah.
<wgrant> There also seems to be 30 minutes of logs missing.
<wgrant> Possibly because it couldn't open the new one.
<jam> wgrant: dropping during kex because it was trying to open /dev/urandom and couldn't open another file
<jam> wgrant: possible. A bit odd that it succeeded 30min later when it was still failing to open files
<wgrant> jam: Really good timing, maybe?
<jam> wgrant: certainly possible
<jam> It does seem to hold open a log file
<jam> since there were lots of failures in the next log
<wgrant> Right.
<wgrant> I initially thought the quick rotation meant that the rsync had missed a log.
<wgrant> But it was confirmed that that was not the case; the log really is missing.
<wgrant> jam: FWIW things were already going wrong in the bit before the missing log.
<jam> wgrant: the previous log shows no failures
<wgrant> jam: I couldn't see anything relevant in the log, but the connection time graph showed that things were bad.
<jam> wgrant: AIUI the connection time graph is only computed every 5-10 minutes or so, so not very good granularity
<jam> but sure
<wgrant> Hmm.
<jam> I certainly could say that things were close to dying at the point, since it was unable to open the log file
<wgrant> We should get the actual data points.
<wgrant> True.
<maxb> jelmer: I'm confused. Why is the bzr-builddeb-daily recipe set to a 2.5.1~ based version?
<maxb> (Given that 2.6 is tagged and in maverick/natty/sid/wheezy
<jelmer> maxb: consistency with its changelog
<jelmer> maxb: we need to ping james_w about this
#bzr 2011-02-12
<echo-area> Is there a bzr-svn version that supports bzr-2.3.0?
<maxb> yes, but not a release
<echo-area> maxb: Okay thanks
<Zblakany> i have a simple question
<Zblakany> along time ago i set bunch o bzr repos as bzr user in /home/bzr
<Zblakany> then i moved them to new server as bazaar user in /home/bazaar
<Zblakany> after that i must add symlink /home/bzr which points /home/bazaar
<Zblakany> that solution is not my idea, but person who uses this bzr repos
<Zblakany> and my question is: why this symlink is needed?
<maxb> Zblakany: You have not provided enough information about your environment for anyone to help you.
<maxb> < Zblakany> that solution is not my idea, but person who uses this bzr repos
<maxb> You mean your users told you to create it?
<Zblakany> maxb: yes, exactly
<Zblakany> he wrote: create symlink and this fix problem
<maxb> Why don't you ask the users what problem they were having then?
<maxb> I imagine the users just didn't want to have to update existing references to the branches
<Zblakany> how can I fix all bazaar repositories, because I want to remove that ugly symlink
<maxb> You haven't said anything that leads me to believe they are broken
<maxb> Merely that your users don't want to have to deal with them moving
<Zblakany> maxb: if I remove this stupid symlink, then part of theese repositories can't work
<Zblakany> so probably in this repositories is static path in form /home/bzr/ not /home/bazaar
<Zblakany> so I should fix this path
<Zblakany> how can I find them?
<Zblakany> maybe it's in .bzr/branch/branch.conf?
<Zblakany> or .bzr/branch/location?
<Zblakany> in some files with /home/bazaar in this files are proper path with /home/bzr
<Zblakany> can I safely change them?
<Zblakany> maxb: part of them has moved location to /home/bazaar, because in his bzr serve command i see different paths
<maxb> Zblakany: Just saying that something doesn't work does not give enough information for people to figure out what the problem might be
<maxb> You should always try to be as precise as possible, including exact error messages, when asking for help on IRC
<Zblakany> maxb: I know, but logs and messages after I moved that repos to new location are gone :-/
<maxb> The only reference to other filesystem paths in bzr branches that I can think might cause things not to work is stacked_on locations in .bzr/branch/branch.conf
<Zblakany> maxb: I can change this stacked_on locations manually, or should I use some command?
<Zblakany> s/I can/can I/
 * jelmer waves
<maxb> Zblakany: yes, you can edit them manually for this sort of fixup
<Zblakany> maxb: thanks :-)
#bzr 2011-02-13
<marcog> trying to setup a lp project for the first time and getting an error trying to checkout
<marcog> $ bzr checkout lp:umonya-website trunk
<marcog> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/%2Bbranch/umonya-website/".
<marcog> project is https://launchpad.net/umonya-website/trunk
<marcog> any ideas?
<sobersabre> hi.
<sobersabre> I am getting the error
<sobersabre> bzr: ERROR: No WorkingTree exists for "file:///D:/foo/.bzr/checkout/".
<sobersabre> even though I have .bzr folder in the dir.
<sobersabre> It seems something messed up the folder.
<sobersabre> is there a way to fix  ?
<sobersabre> (except a full checkout)
<sobersabre> and if I am running status command that folder: http://pastie.org/1559377
<sobersabre> very strange.
<jelmer> sobersabre: there is a branch present but no working tree
<jelmer> sobersabre: try running 'bzr co' in that location
<sobersabre> jelmer: I think the problem is the p4 messup.
<sobersabre> I am not sure which exactly.
<theAdib> hello all. I want to apply a patch to a project using bzr. Someone provided a diff output using git:
<theAdib> http://launchpadlibrarian.net/63734242/fix-gcc-4.6-build.patch
<theAdib> when I do "bzr patch foo.patch" then I get only error messages like
<theAdib> 1 out of 1 hunk FAILED -- saving rejects to file b/src/xml/helper-observer.h.rej
<theAdib> what can I do?
<maxb> theAdib: Based on that error message, I am guessing you need to use the "-p 1" option to patch
<theAdib> hm, less errrors there. But still:
<theAdib> adib@vega:~/Projekte/Inkscape/inkscape/myproject-707205$ bzr patch -p 1 fix-gcc-4.6-build.patch
<theAdib> 1 out of 1 hunk FAILED -- saving rejects to file src/2geom/utils.h.rej
<theAdib> 1 out of 1 hunk FAILED -- saving rejects to file src/application/editor.h.rej
<theAdib> bzr: ERROR: Patch application failed
<theAdib> adib@vega:~/Projekte/Inkscape/inkscape/myproject-707205$
<theAdib> ah, ok I see. The target file has been change since and now I have to apply the patch manually. Thx, my bad.
<maxb> If it's only 2 files out of 78 with errors, it suggests that those are valid conflicts caused by changes upstream
<maxb> right
<dlynch> I've been using bzr for 3 or 4 years now, without problems, until recently I encountered this error: bzr: ERROR: No WorkingTree exists for "file:///home/damon/digitalPhotos/rapid/.bzr/checkout/".
<dlynch> I don't know what caused it, or how to fix it
<lifeless> dlynch: is that on your server perhaps?
<dlynch> lifeless, no... it's on my laptop
<lifeless> so what it means is that you don't have a working tree, and you're running a command that needs one
<dlynch> the machine I do all my development on
<lifeless> we don't create working machines when you push over the network
<dlynch> I always had a working tree before
<lifeless> (otherwise we'd be pushing twice as much)
<lifeless> its a bit of a mystery why you don't have one
<dlynch> yes indeed
<lifeless> did you change your toolchain recently?
<lifeless> (e.g. start using bzr-explorer or something)
<dlynch> I've been using bzr-explorer for a while
<lifeless> anyhow
<lifeless> to make a working tree
<lifeless> cd to rapid
<lifeless> and do
<lifeless> 'bzr checkout .'
<dlynch> what will happen to all the changes I've made in the code?
<lifeless> uhm
<lifeless> can you do 'ls -al /home/damon/digitalPhotos/rapid/'
<lifeless> and
<lifeless> ls -al /home/damon/digitalPhotos/rapid/.bzr/
<dlynch> I can always overwrite them from backup, so I guess it's not a big deal
<dlynch> I guess there are two ways to handle this: 1) do the checkout, potentially overwrite all my changes, and then restore those changes from local backup, or 2) take your time and mine do try to get to the bottom of it. Does option 1) sound better? :)
<lifeless> I'm easy
<lifeless> I'll be surprised - and it will indicate a pretty severe bug - if you have working files in  /home/damon/digitalPhotos/rapid/ already.
<dlynch> http://pastebin.com/T8TRmMt5
<dlynch> http://pastebin.com/1Fj2WPrQ
<lifeless> interesting
<lifeless> can you look in backup.bzr
<lifeless> dlynch: is rapid itself meant to be a project, or is it a collection of projects?
<dlynch> ok.... I just thought of something..... recently I moved my home partition, restoring from backup using rsync.... with an exclude rule for checkout/
<dlynch> I had that rule because I was experimenting with gnome 3 code
<dlynch> I guess when I did the restore, a bzr dir was excluded!
<lifeless> a
<lifeless> yes, that would do it
<dlynch> ok sorry about that
<lifeless> rsync filters are regexes
<dlynch> yes
<lifeless> or something like them
<dlynch> I should have used a full dir path
<lifeless> they need to be rooted or they match every dir
<lifeless> mystery solved
<dlynch> ok
<dlynch> so to fix this problem, I do a checkout, overwrite whatever gets overwritten, and then restore from local backup
<dlynch> lifeless, thank you very much :)
<lifeless> or just copy that checkout from the backup
<lifeless> (the .bzr/checkout)
<lifeless>  /all/ your bzr working areas are going to have this issue
<lifeless> If I was you I'd figure out how to get rsync to copy all the bits you missed
<lifeless> be faster over all
<dlynch> lifeless, the problem is they were not backed up to begin with, because I use the exclude rule in the actual rsync command to backup
<lifeless> ah
<lifeless> so
<lifeless> there is another thing you can do
<lifeless> will avoid the need to restore
<lifeless> cd /tmp
<lifeless> bzr checkout --lightweight /home/damon/digitalPhotos/rapid/ foo
<lifeless> cp -a foo/.bzr/checkout /home/damon/digitalPhotos/rapid/.bzr/checkout
<dlynch> wow bzr status now works
<lifeless> find /home -name 'branch' -type d
<lifeless> should find all the places you need to do that
<dlynch> thanks very much lifeless.... I really appreciate it!
<lifeless> no worries
<mwhudson> hm
<mwhudson> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/files
<mwhudson> no
<mwhudson> $ bzr get lp:~linaro-infrastructure/launchpad-work-items-tracker/linaro
<mwhudson> bzr: ERROR: Invalid http response for https://xmlrpc.launchpad.net/bazaar/: Unable to handle http code 400: Bad Request
<mwhudson> not seen that before
<lifeless> meep ?
<mwhudson> huh, worked the second time
<mwhudson> nothing much in .bzr.log either
#bzr 2012-02-06
<bob2> 'clone' was deprecated?
<lifeless> yes, it isn't what git means by clone, nor hg, so it was confusing (it was deprecated -ages- ago)
<bob2> hm, in the sense that it "clones" a branch not a repo like hg/git?
<lifeless> right
<bob2> fairynuff
<lifeless> possibly it ca come back with colocated setups
<infinet> how to resume an interrupted "bzr branch lp:xxxxx " command?
<bob2> afaik you're boned unless you run it in a shared-repo
<AuroraBorealis> why are you boned? try just running the command again
<AuroraBorealis> they say that bzr is failure resiliant
<bob2> pretty sure it won't use the already downloaded data
<AuroraBorealis> well a branch operation is pretty easy to just start over anyway so if it doesn't then it doesn't matter :>
<infinet> it says "bzr: ERROR: Target directory "calibre" already exists.", so seems like have to delete data already download and start over
<bob2> as above
<bob2> AuroraBorealis, not if it is a large branch
<AuroraBorealis> bzr's dev branch takes less then 5 minutes =
<AuroraBorealis> you might have to delete the .bzr directory
<infinet> the calibre appears quite large, I end up over 100M of unfinished data when last interrupted
<infinet> what a waste
<bob2> pretty sure as above
<AuroraBorealis> try
<AuroraBorealis> bzr branch --use-existing-dir
<infinet>  --use-existing-dir make no difference, it is what bzr explorer did by the way
<AuroraBorealis> i would just try again, then.
<infinet> thanks
<AuroraBorealis> i think operations that change stuff (like history) are safe, but i guess branch isn't since you don't really lose any data if it gets interrupted.
<infinet> true, it is the first time to fetch the branch, so nothing lost
<bob2> still immensely tedious though
<AuroraBorealis> i agree. i dont know why it wouldn't resume if its just downloading revisions
<infinet> more carbon emission, perhaps
<AuroraBorealis> perhaps its just on the ever growing todo list.
* 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
<poolie> hi vila?
<vila> hi all !
<vila> hey poolie
<poolie> hi there
<poolie> vila, tangentially, what did we end up with as preferred config option naming
<poolie> jelmer is adding 'bzr.transform.orphan_policy' but i thought we were going to drop the 'bzr.'
<vila> he didn't add it, just migrated it
<vila> yes, we settled on dropping the leading 'bzr.' but this option predates that decision
<poolie> k
<poolie> true
<mgz> morning all!
<poolie> hi mgz, and good night
<mgz> night poolie :)
<apw> anyone else seeing a large delay (leading to compiz greying out) in bzr vis after the progress bars are done filling and before showing the first commit
<mgz> try profiling it and seeing what the call that blocks is.
<apw> mgz, any hints as to how to profile it, is there something pythony in my toolbox
<mgz> you can run it via a bzr command line thing right?
<mgz> so `bzr --lsprof-file bzr_viz_prof.txt viz ...`
<mgz> and close the window as soon as it's done loading.
<mgz> I've used that for bzr explorer/qbzr issues
<AfC> apw: yeah, I've seen that delay lately. It's pretty awful.
<jelmer> I think it was introduced with our migration to gtk3, haven't had time to investigate either though :-/
<mgz> it's worth a bug at any rate.
<mgz> jelmer: how was the weekend's snow?
<jelmer> mgz: terrible :)
<mgz> did the trains go in the end?
<jelmer> had long delays on Friday and Sunday, but got back home safely
<LarstiQ_> can I turn 'pypy' into an official tag?
<mgz> LarstiQ: if you can, do so.
<LarstiQ> mgz: done
<mgz> LarstiQ: for bug 926869 it's as poolie says, I'd have added features.RefCountingGC or something to the tests were there an obvious way of detecting that
<ubot5> Launchpad bug 926869 in Bazaar "TestUncollectedWarnings failures under pypy" [Medium,Confirmed] https://launchpad.net/bugs/926869
<mgz> there's no sensible way of implementing detection of test cases living too long without depending on gc implementation details
<mgz> and though some of the pypy gc options will benefit from testcases that die promptly, there's no way short of running a collection after each case to actually do that, and that will have other downsides
<mgz> it should perhaps have been more clearly documented as such, but I wasn't particularly thinking that any other python implementations were close to working
 * LarstiQ nods
<LarstiQ> mgz: now that an entire testsuite run completes, I'm not too worried about the memory consumption
<LarstiQ> so for my part skipping would be fine
<mgz> for bug 927581 win32 has a similar but worse problem, pypy only uses the bytestring version
<ubot5> Launchpad bug 927581 in Bazaar "pypy raises UnicodeDecoderError on os.listdir(unicode) in a C locale" [Low,Confirmed] https://launchpad.net/bugs/927581
<mgz> so really I think they need to make listdir less broken with non-ascii data, but the way we use it doesn't help.
 * LarstiQ nods
<mgz> I couldn't find an upstream pypy bug, it may be worth filing one and linking it.
<LarstiQ> mgz: I can do that
<LarstiQ> mgz: do you have a link for the win32 version?
<mgz> I thought I'd posted a bug, but now can't find it, so maybe I just noticed the issue but didn't file
<wgz> <http://float.endofinternet.org/xmlbin/pypy_non_per_FAIL#bb.test_alias.TestAlias.test_unicode_alias>
<wgz> note we create a file that we then can't remove with a standard library function in cleanup
<tsdgeos> hi guys
<tsdgeos> i obviously messed up something in a merge
<tsdgeos> and ended up with https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_rtl/+merge/90455
<tsdgeos> where i have "added file 'tests/launcher/autohide_show_tests_common.rb'" and "removed file 'tests/launcher/autohide_show_tests_common.rb'"
<tsdgeos> instead of just the differences in that file
<tsdgeos> is there a way i can fix that?
<LarstiQ> tsdgeos: try `bzr status --show-ids` on that change
<LarstiQ> tsdgeos: it sounds like two files with different file-ids
<tsdgeos> i mean probably
<tsdgeos> the file was already there
<tsdgeos> and then the merge brought a file named the same
<tsdgeos> so that's basically where i messed up i guess
<tsdgeos> just wondering if it can be repaired
<LarstiQ> tsdgeos: well, you could backtrack to where the extra copy got introduced
<tsdgeos> LarstiQ: otoh it's weird, because if you go to http://bazaar.launchpad.net/~aacid/unity-2d/unity-2d-shell_rtl/revision/969 that is the merge commit
<LarstiQ> tsdgeos: but if that has already been merged into the project history, might not be worth it to disrupt that
<tsdgeos> it looks acceptable
<tsdgeos> when you unfold "tests/launcher/autohide_show_tests_common.rb "
<tsdgeos> it looks like only the changes there, not a whole replace/rewrite of the file
<LarstiQ> tsdgeos: right, so that's the wrong place
<tsdgeos> well, that's the place i merged the two branches that had the same file, before that all was fine
<tsdgeos> anyway, not important
<tsdgeos> thanks!
<LarstiQ> tsdgeos: you're merging into lp:~unity-2d-team/unity-2d/unity-2d-shell
<LarstiQ> tsdgeos: so could be that there the change happened
<LarstiQ> tsdgeos: (or maybe there is a bug in the merge proposal preview)
<tsdgeos> maybe
 * LarstiQ branches and checks
<tsdgeos> this is my first merge with files coming from everywhere
<tsdgeos> so probably did something wrong somewhere
<LarstiQ> tsdgeos: so ` bzr log -p tests/launcher/autohide_show_tests_common.rb` in your branch shows it getting added in r957
<LarstiQ> tsdgeos: and ` bzr st --show-ids -r ancestor:../unity-2d-shell` tells you the fileid of the removed versions
<LarstiQ> tsdgeos: hmm, I don't quite get it
<LarstiQ> tsdgeos: `bzr missing --line ../unity-2d-shell` and then `bzr log -v -r 935..-1` show you didn't remove or rename them
<mgz> I think both sides of the merge added the file, so there was a path conflict rather than a content conflict, and he took his copy?
<LarstiQ> mgz: that sounds plausible
<mgz> so then, merging that into trunk replaces the existing file
 * LarstiQ nods
<mgz> the right thing to do is redo that merge, keep trunk's file, add in any changes needed, which should then merge back to trunk cleanly
<LarstiQ> tsdgeos: what mgz said.  Trunk added autohide_show_tests_-20120131103636-9609yigoypwit8fi-1 in r953, you added autohide_show_tests_-20120130172001-gjk3mfvvx7hksg75-1
<pippijn> hi all
<pippijn> I'm having some issues committing
<pippijn> http://xinutec.org/~pippijn/files/txt/ca85c58612e67f7eb1b5581a6478aa2c.txt
<jelmer> hi pippijn
 * mgz wants to make a joke about this being the wrong place for relationship advice
<jelmer> vila: ^
<mgz> pippijn: did that not also print out the version and plugin version info?
<pippijn> hmm
<pippijn> I did bzr merge, got an error, did bzr commit again, got a different error
<pippijn> one that does not read Traceback
<pippijn> there we go, it's suddenly fixed
<jelmer> pippijn: this seems odd, the error suggests you have files from different versions of bzr installed
<tsdgeos> LarstiQ: mgz: how would i do that? bzr uncommit + push again? will that overwrite the old history?
<pippijn> it's working now
<pippijn> magically
<jelmer> pippijn: do you have a dist-upgrade / yum upgrade job going on in the background, or something like that?
<pippijn> jelmer: no
<mgz> tsdgeos: either uncommit, or to be safer branch the rev just before to a new directory and try again
<jelmer> pippijn: it sounds like there's something really funky going on with the files in /usr/lib/python2.7/dist-packages/bzrlib
<mgz> tsdgeos: then, after doing the merge, committing, and maybe testing against a local copy of trunk to see the merge back works as expected, you can push --overwrite to fix your branch and mp
<tsdgeos> mgz: nice that worked :-)
<tsdgeos> tx
<mgz> cool.
<vila> jelmer: what ? mgz's joke ?
<jelmer> vila: sorry, unping
<jelmer> vila: it was about the config hooks issue pippijn was running into
<vila> jelmer: oh, ok, just seen the traceback, quite weird indeed, I don't remember changing hook signatures there... I agree with your feeling about some weird update
<mgz> eheh, the ping was amusingly timed.
<cabbey> anyone familar with oddball errors out of bzr rebase around?
<cabbey> trying to rebase my branch and it's given me a "conflict" on a directory and file that are new in my branch
<cabbey> can't seem to convince bzr resolve to clear the bogus conflict messages
<jelmer> hi cabbey
<cabbey> howdy jelmer
<jelmer> cabbey: you should be able to run 'bzr resolved' and then 'bzr rebase-continue'
<cabbey> heh, if anyone is familiar with this code, I suspect you would be. :)
<cabbey> so right after I posted that, a co-worker suggested explictly resolve'ing by name... that worked when bzr resolved wouldn't
<jelmer> cabbey: bzr resolved can only automatically resolve text conflicts, not shape conflicts
<jelmer> there is also 'bzr resolved --all' which makes it consider all conflicts as resolved
<cabbey> mmm... --all woulda saved me some copy/paste
<cabbey> hey jelmer, I'm starting to think what I'm doing is not a good use of rebase. Got a moment to confirm/reject that?
<cabbey> we've got 3 branches: trunk -> feature A -> feature B
<cabbey> feature A landed to trunk last week, now I'm trying to rebase my branch for B to trunk, since A is deadended
<cabbey> rebase is dragging me through lots of nasty manual conflict merges that make no sense to go through again... I had already dealt with all of them as I pulled A into B
<cabbey> (A and B were in parrallel development since last september... I've probably done 1000 hand merges during that time)
<cabbey> oh god. I just looked at some of the supposed merge results it handled without flagging as conflicts. :(
<jelmer> RE
<jelmer> cabbey: I would do a reverse merge of the changes from A in B
<jelmer> cabbey: rebase will try to create all commits again on top of trunk, one by one - so it's probably not what you want, indeed
<cabbey> sadly it seems to be doing a very bad job of re-creating them :(
<jelmer> cabbey: it's just applying the changes again
<jelmer> cabbey: you might have more luck trying to rebase on the revision from trunk before feature A was started
<cabbey> that's not what I'm seeing in these .BASE, .THIS and .OTHER files
<jelmer> cabbey: it's basically just doing "bzr diff -c" for each revision and then calling "patch -p0" for that revision on top of trunk
<poolie> hi jelmer, wgz
<jelmer> hi poolie
<jelmer> are you feeling better?
<poolie> yes thanks
<poolie> how are things with you?
<cabbey> jelmer: it should be replaying the commits from my branch, right?
<poolie> i'm going to try to get through the queue today
<poolie> and maybe then look in to debugging some precise bugs
<jelmer> poolie: I had fun at FOSDEM :)
<Riddell> jelmer: you never came by my stall!
<poolie> hi riddell, how are you?
<Riddell> poolie: recovering
<Riddell> enjoyed fosdem, had to limit my intake of belgian beer of course
<jelmer> Riddell: well, you missed the Ubuntu dinner >-)
<jelmer> Riddell: I did spot you at some point during the weekend, but you were in conversation with somebody
<Riddell> that's because I had about 25 KDE cats to herd to the dinner I organised
<jelmer> ah, heh :)
<Riddell> I might be concussed but I still can organise better than most free software types
<jelmer> cabbey: did you merge trunk during the feature development at all?
<jelmer> Riddell: :)
<cabbey> yes. via A
<cabbey> A pulled trunk in, B pulled A in
<jelmer> cabbey: replaying the changes from B on top of trunk means that older B revisions won't have all the changes from trunk merged in yet
<cabbey> well, pulled or merged... mostly merged there in the latter days as things diverged :)
<jelmer> basically, rebasing anything that has merges of the branch onto which you're rebasing in it somewhere is going to cause massive conflicts
<cabbey> right, so rebase-abort here I come. :(
<lifeless> poolie: hiya
<lifeless> poolie: LP would like to be able to import bzr plugins from eggs (in our buildout environment) - are you aware of an existing bug for having bzr find plugins via setuptools voodoo ? I don't want to file a dupe, I vaguely recall such a bug, but flacoste couldn't find it when he looked
<poolie> hm
<poolie> as in, it doesn't automatically find them?
<poolie> or, you can't even load them by hand?
<poolie> this seems to get into namespace package ickiness
<poolie> but
<poolie> i don't recall a bug for it and i don't object
<poolie> the only bzr tasks i have been objecting to are the ones where the bug is not yet actionable in bzr
<lifeless> sure; I wasn't referencing or impeded by that :)
<lifeless> poolie: as in the load_plugins call needs to call some setuptools api to ask it to iterate the available bzrlib.plugins.* eggs; that would get the package path setup fo r'import bzrlib.plugins.foo' at the same time; I think its fairly shallow (but possible expensive to call so may need an option to turn it on)
<jelmer> cabbey: I would recommend doing a reverse merge of the changes between A and trunk
<poolie> +1
<jelmer> cabbey: rebase is just conceptually problematic in this regard
<lifeless> bug 78520 is tangentially related (in that you can't install plugins into an egg distribution, so if plugins are desired, this is a pre-cursor to fixing that existing bug report)
<ubot5> Launchpad bug 78520 in Bazaar "build a Python Egg installer package?" [Medium,Confirmed] https://launchpad.net/bugs/78520
<cabbey> jelmer: yeah, I'm starting down that route in copy of my branch right now
<lifeless> poolie: I've filed https://bugs.launchpad.net/bzr/+bug/927920 about this
<ubot5> Launchpad bug 927920 in Bazaar "plugins installed as eggs are not found by bzrlib" [Medium,Confirmed]
<poolie> thanks lifeless
<lifeless> poolie: de nada :)
<milki> hm
<milki> bug 0
<ubot5> Error: Launchpad bug 0 could not be found
<milki> :o
<milki> bug 1
<ubot5> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<milki> lol
<wgz> a little bazaar before bed
#bzr 2012-02-07
<poolie> hi wgz
<wgz> hey poolie
<vila> hi alll !
<mgz> morning!
<vila> heya mgz
<jelmer> hi mgz, vila
<wgz> shall we get this party started?
 * vila nods
<wgz> I created a thingy via the new cunning means described in a thread on the wotsit
<vila> jelmer: joining ?
<jelmer> vila: sorry, on my way
<vila> jelmer: no worries
<bialix> hi
<bialix> mgz, vila: can you look at the "what's new iun qbzr 0.22" and check this text for mistakes? http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/view/head:/NEWS.txt
<wgz> looking
<wgz> seems good bialix
<bialix> thank you, wgz
<bialix> new hat? new clothes?
<bialix> :-)
<wgz> I need to dress up in two outfits at once :)
<bialix> ninja
<bialix> wgz: I'll release qbzr then
<bialix> not sure what I can do for explorer right now
<wgz> bialix: I want to still get some fixes in for explorer
<ccxCZ> can anyone help me with converting svn to bzr? currently I'm stuck at: bzr: ERROR: Unable to convert Subversion path e16/fnlib/fonts/fonts/shinymetal/45/\.tif because it contains characters invalid in Bazaar.
<jelmer> ccxCZ: that's a really hard thing to work around, bzr doesn't support backslashes in filenames at the moment
<ccxCZ> I guess that filename is there by mistake anyway and I certainly don't need the e16/ subtree
<jelmer> ccxCZ: you could dump the svn repository, remove the problematic filename and then import
<ccxCZ> can we import from svndump?
<ccxCZ> atm I have local copy of the repo obtained with svnsync, can I branch a subdir of that?
<ccxCZ> it uses /trunk/projectname layout and I need only few of these
<jelmer> ccxCZ: you can use a subdir, you just can't exclude a subdir
<jelmer> ccxCZ: "bzr branch" allows you to specify a path in the repo
<ccxCZ> ah got it to work now, thanks
<ccxCZ> jelmer: I branched out successfully and now I tried to pull new changes from the source on the net http://paste.pocoo.org/show/547220/
<ccxCZ> I can svn co from that uri successfully; when I disable all plugins but svn it behaves the same
<ccxCZ> fileabug?
<jelmer> ccxCZ: you're running an old version f bzr-svn
<ccxCZ> should I try 1.1.2 or trunk?
<jelmer> 1.1.2
<ccxCZ> seems to work now, thanks again
 * ccxCZ should have checked for latest version himself
<ccxCZ> hmm but why is it checking out the whole history?
<jelmer> ccxCZ: it's just caching the revision metadata, not the contents of the revisions
<ccxCZ> server is too unstable to get all 6k commits in one session, that's why I used svnsync
<ccxCZ> seems I'll have to keep the sync version around for pulling then
<ccxCZ> 60k commits actually
<ccxCZ> that's one unhappy server :-( bzr: ERROR: A Subversion remote access command failed: REPORT of '/svn/e/!svn/bc/58596': Could not read response body: Connection reset by peer (http://svn.enlightenment.org)
<ccxCZ> okay, I'll make some scripts to update my repos from the svnsync copy then
<mgz> man, lwn trolls pretty hard of riddell's post about kubuntu
<mgz> *off
<mgz> and it works, 32 comments already :)
<Riddell> mgz: yeah that jono guy holds no punches :)
<mgz> Riddell: all those people saying nice things about you too :)
<Riddell> I've had two job offers in the last hour :)  [not wanting to take them]
<Jesdisciple> I have two revisions numbered 1, local and remote, and the local is the "real" one.  It was actually derived from the remote, but I wrestled with bzr and had to make a new repo with the old code.
<Jesdisciple> How can I merge?  I can't find anything about how to specify a "base revision"
<Jesdisciple> what I have been trying: bzr merge lp:chaos2d --revision 1
<LarstiQ> Jesdisciple: why not just `bzr merge lp:chaos2d`?
<Jesdisciple> LarstiQ, $ bzr merge lp:chaos2d
<Jesdisciple> Enter passphrase for key '/home/chris/.ssh/id_rsa':
<Jesdisciple> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<LarstiQ> Jesdisciple: aha
<Jesdisciple> ended up finding the solution here http://selfdocumentingcode.blogspot.com/2009/04/merging-unrelated-branches-in-bazaar.html
<LarstiQ> Jesdisciple: right, that way you can get it done
<LarstiQ> Jesdisciple: but since you're just starting out
<LarstiQ> Jesdisciple: do you need the "old" one?
<LarstiQ> Jesdisciple: if not, you could maybe just replace it with the new one and go from there
<Jesdisciple> nope
<Jesdisciple> how...?
<LarstiQ> Jesdisciple: `bzr push lp:chaos2d --overwrite` should do it I think
<Jesdisciple> (it's too late now, and I accidentally deleted the wrong half of the conflict... now rewriting one of those four files where I had made massive changes)
<Jesdisciple> alright, thanks
<LarstiQ> Jesdisciple: if you had everything committed, and the merge went wrong, you can use `bzr revert` to get back to the latest commit
<Jesdisciple> sweet, thanks
<idnar> is bzr-colo in core yet?
<idnar> I found some mailing list traffic about something like but couldn't follow the discussion
<idnar> ah I guess not
<jelmer> idnar: hi
<idnar> jelmer: hi :)
<jelmer> idnar: there is some degree of colocated branch support in core nowadays
<jelmer> idnar: in 2.5 onwards
<edakiri> I set global ignores in ~/.bazaar/ignore , but do not see them with 'bzr ignore --default-rules' .  Ideas why?  Strace tells me  ~/.bazaar/ignore is never accessed.
<Kamping_Kaiser> edakiri: is your version of bzr new enough to use it?
<edakiri> Kamping_Kaiser: Bazaar (bzr) 2.5.0dev6
<edakiri> The docs i am looking at are for 2.5.0dev1 , so I figure the version of bzr i have should be new enough.
<jelmer> edakiri: I think --default-rules just prints the hardcoded list in bzr itself that it will write out if there is no ~/.bazaar/ignore file
<edakiri> I think that is so.
<thomi> Hi - qbzr's diff app has an option to ignore whitespace changes. Is there a way to do that with straight 'bzr diff' as well?
<jelmer> thomi: hi
<thomi> hi jelmer
<jelmer> thomi: I think something like "bzr diff --diff-options -w"
<thomi> jelmer: ahh, thanks
<jelmer> thomi: anytime :) are you having fun in unity land?
<thomi> jelmer: yeah, it's good fun. Working from home takes a bit of getting used to though, but once you learn to avoid distractions it gets easier
<thomi> I need to get out of the house more though - some weeks I hardly go outside during the day...
<lifeless> wgz: hey
<lifeless> wgz: so I found a bug in your testtools encoding detection code; triggers implicit decode if the linecache has unicode contents in it
<lifeless> \o/
#bzr 2012-02-08
<abadger1999> Does Robert Collins hang out here?
 * abadger1999 not sure which time zone he'd be in either.
<bob2> yes, and gmt+12 or something equally ridiculous
<bob2> lifeless, ^
<lifeless> abadger1999: ola
<abadger1999> ola
<lifeless> toshio ?
<abadger1999> I'm Toshio
<abadger1999> Yep
<lifeless> cool :)
<abadger1999> Do you release loggerhead with python setup.py sdist?
<abadger1999> If so, I've got some additions to MANIFEST.in and some questions :-)
<lifeless> abadger1999: I think I do; sure - shoot
<abadger1999> lifeless: Cool. Do you want the loggerhead/tests directory in the installed plugin?
<lifeless> don't really care
<abadger1999> lifeless: Okay.
<lifeless> if it works without it there is no particular reason to include it
<abadger1999> <nod>
<lifeless> I think the sdist should include it
<abadger1999> bzr selftests can access it
<abadger1999> So I wasn't sure whether to install it or not
<lifeless> I think the sdist needs to include it so that folk doing their own installs can validate etc
<lifeless> but for an installed package, that sort of variation is eliminated
<lifeless> if that makes sense?
<abadger1999> Yeah.  just a choice of whrether to put it in MANIFEST.in or in setup.py's packages=[]
<abadger1999> Sounds good.  I'll put it in MANIFEST.in then
<abadger1999> Other two directories I wasn't sure of were loggerhead/middleware and load_test_scripts
<lifeless> hmm, lets see
<abadger1999> middleware has a profile middlewware in it that loggerhead seems to use if a config option is set to do profiling.
<lifeless> yeah, that should be included
<lifeless> we should break that out to a separate package, let other folk reuse it
<abadger1999> <nod>
<lifeless> and then depend on it, but that is for later
<abadger1999> The stuff in load_test_scripts not sure if that needs to be included at all?
<lifeless> yeah
<lifeless> leave it out I suspect
<lifeless> bbs, baby needs me
<lifeless> actually still here
<lifeless> but in 10 I may not be :P
<abadger1999> Okay :-)
<abadger1999> I'll push a branch for this and propose for merging.
<lifeless> thanks!
<abadger1999> de nada :-)
<mgedmin> oh, cool, a yet another wsgi profiler middleware?
<lifeless> of course
<poolie> hi all
<jvargas> hi
<jvargas> when I run a script which perfoms several bzr commands, and then I press ^C, the full script doesn't stop, just the current bzr command being run.
<jvargas> Is there a way to tell bzr not to handle by itself ^C and let it die? Would that be transaction safe?
<abadger1999> lifeless: Just letting you know, with the changes in the lp:~toshio/loggerhead/sdist-post-1.8.1 branch, I have a working loggerhead package.  (tested with bzr-2.4.2)
<lifeless> abadger1999: cool
<lifeless> abadger1999: I won't get to your branch today, but will soon
<lifeless> jvargas: 'set -e' in your shell script
<abadger1999> Cool
<lifeless> jvargas: its not a bzr issue, its your script
<jvargas> thank lifeless! just wondered if that behaviour was parametrized.
<lifeless> jvargas: its totally outside bzr's control
<lifeless> the ctrl-c is received by the shell running the script, and passed onto the current subcommand (bzr in this case) and then it decides based on the subcommand exit code, and the setting of -e (or +e which is the default) whether to continue or not
<jvargas> okay
<mlh> <3 set -e
<vila> hi all !
<poolie> hi there vila
<malfyz> http://www.youtube.com/watch?v=BbuXK1pWD-M LOOOOOOOOOOOOOOOOOOOOL
<mgz> morning
<poolie> hi mgz, jelmer
<mgz> hey poolie
<LarstiQ> morning mgz, poolie
<LarstiQ> hmm, how do I link an upstream bug again?
<mgz> LarstiQ: two ways, one do "Also affects project" then do the project name, then add the upstream bug url
<poolie> hi there larstiq
<mgz> that should be what you want for pypy
<LarstiQ> mgz: cheers!
<vila> heya mgz
<vila> hey LarstiQ, it's good to see you around ;)
<LarstiQ> hey vila :)
<LarstiQ> vila: anything to avoid spackling more walls ;)
<vila> ha ha ha
<LarstiQ> mgz: I must admit that I didn't quite grasp what the problem on win32 was, so haven't filed a bugg about that yet
<mgz> LarstiQ: the bug you filed sort of covers it anyway, except the implementation in pypy would need to be different
<LarstiQ> right
<mgz> jelmer: just seeing bug mail on a loom change, are there any other plugins I need to double check I have the latest version of when I do the installer?
<jelmer> mgz: I'm not sure
<jelmer> we should have a more structural way of testing the plugins
<mgz> jelmer: that was as in, "ones you remember touching to fix colo things" rather than please give me an exhastive list
<jelmer> mgz: ah
<jelmer> mgz: the foreign ones, but I'd guess you already have those
<mgz> but yeah, just running the plugin tests and being confident that means they're okay would be nice
<jelmer> for loom at least, the tests broke because of the bzr core change
<mgz> have subvertpy 0.8.9; bzr-svn 1.1.2; dulwich 0.8.2; bzr-git 0.6.6
<mgz> more things are just tip than I remembered, so should generally be fine
<jelmer> cool
<ccxCZ> bzr pull forkbomb! it spawned ~400 children when pulling from svn
<jelmer> ccxCZ: huh? It shouldn't create any child processes at all
<jelmer> ccxCZ: what kind of processes were they?
<ccxCZ> bzr pull ...
<ccxCZ> seemed it just forked zillion times, but not exec'd
<ccxCZ> http://wpr.cz/ccx/bzrpull.png
<jelmer> is that actual processes, or could it also be threads?
<ccxCZ> you can see the PIDs
<jelmer> ccxCZ: sorry, I would have no idea what's going on - we don't fork as far as I know
<ccxCZ> ah sorry they *might* be threads
<jelmer> ccxCZ: ah, ok - that could be the case if you have 'use-cache = False' set
<ccxCZ> they probably are, didn't know threads use up PIDs too
<jelmer> ccxCZ: do you have 'use-cache = False' set?
<ccxCZ> doesn't seem so
<ccxCZ> load >200 :D
<ccxCZ> no such setting in ~/.bazaar
<ccxCZ> I just grepped
<jelmer> ccxCZ: hmm, that's odd
<jelmer> mgz: are you looking at bug 921484 ?
<ubot5> Launchpad bug 921484 in Bazaar "bzr: ERROR: exceptions.AttributeError: 'InventoryLink' object has no attribute 'children'" [Undecided,Incomplete] https://launchpad.net/bugs/921484
<vila> mgz: ping
<mgz> pong
<vila> what's the status for 2.5b6 windows installers ?
<mgz> unstarted.
<vila> :-/
<mgz> I probably have some time this evening
<mgz> but really want to release with some bzr-explorer changes
<mgz> jelmer: see the update to that bug in my mail now
<mgz> *I have just seen
<vila> jelmer: did you upload 2.5b6 to debian ?
<jelmer> vila: yep
<jelmer> not to precise yet
<vila> ok, cool, thanks !
<jelmer> vila: ubuntu done too
<mgz> okay, that bzr bug is a little fun, I'll update so current state is clear
<pmezard> hello, I have seen people using "init-repo --no-trees" to create repository within existing treeless repositories (see http://paste.pocoo.org/show/547792/ ). Is it legit?
<jelmer> pmezard: yes, that should be valid
<pmezard> How does it compare to regular branching? Do you know documentation about this?
<jelmer> pmezard: compare in what sense? the innermost repository gets used, the outer one isn't involved at all
<pmezard> what puzzles me is calling .find_branches() on outer seems to return the inner branch as well, while I would have expected it to be ignored somehow
<pmezard> and calling .get_revision() on outer fails with this revision
<pmezard> so it is not clear to me how bother repositories/branches(?) interact
<jelmer> pmezard: find_branches() just recurses to find branches. You have to specify using=True as argument to only get those branches that actually use the repository you call it on.
<pmezard> oh that's what "using" means
<pmezard> jelmer: excellent, thank you
<jelmer> np :)
<mgz> ho hum hum
<jelmer> mr gz, sir!
<mgz> ...that makes me sound a little more noble than I deserve
<mgz> mumble mumble?
<vila> mumble gz sir ?
<mgz> feel free to jump on as well vila
<vila> oooh I thought you mean mumble as in... well, mumbling :)
 * vila try to focus again :)
<djfroofy> hey everyone! fabuluous morning over here and I hope everyone is feeling the same. [rub rub]
<djfroofy> quick question on bzr and any pointers to docs etc i would appreciate
<djfroofy> I have a branch which i've been working on and piling on a few changes which have gone beyond the scope of the ticket i was working on
<djfroofy> i'm coming from a git background ... would usually start a new branch and then cherry pick changes up to a related point etc.
<djfroofy> what's the best workflow for this in bzr
<LarstiQ> djfroofy: have you commited them?
<djfroofy> LarstiQ: yep
<djfroofy> all of the changes are in neat (or neat enough) little commits ... so cherry-picking should be a simple task
<djfroofy> i'm going through the bzr docs right now
<LarstiQ> djfroofy: mirroring the git workflow, you could use `bzr merge -c <introducing-revision> path/to/original/branch` per revision you want to have
<LarstiQ> perhaps the rewrite plugin has support for it too, but I don't know it well
<exarkun> What does backspace do at the 'bzr shelve' "shelve? [yNfq?]" prompt?
<mgz> nothing currently.
<mgz> a whoopsie go back button would be nice.
<LeoNerd> +1 to having a "back" button
<LeoNerd> I hate having to quit and restart because I answered one thing wrong
<exarkun> I don't think it does nothing
<exarkun> The process advances to the next hunk after I hit it
<mgz> what I tend to do most is ynnnnn and hit n one too many times and cancel out at the final "no really?" prompt
<mgz> exarkun: possibly a bug with the getchar thing on your platform? what's the bzr version and system?
<exarkun> Ubuntu 11.10, bzr 2.4.1
<exarkun> running in screen in gnome-terminal
<mgz> can you do this in a prompt?
<mgz> >>> from bzrlib.osutils import getchar
<mgz> >>> getchar()
<mgz> '\x7f'
<mgz> that's hitting backspace after enter on the getchar line
<mgz> I'll double check 2.4.1 too
<exarkun> Same
<exarkun> Some experiments suggest it's equivalent to n
<mgz> ah, I got repo
<mgz> how did I just do that
<mgz> was trying different num/caps lock keys and the nth backspace hit moved me to the next hunk
<mgz> but I now can't get it to do that again
<mgz> maybe I just hit the wrong key
<mgz> nope, can't get 2.4 to do it for me. best guess is some weirdness with screen or term emu
<exarkun> Hm, can do it in gnome-terminal w/o screen
<exarkun> And in xterm w/o screen
<mgz> ah, I'll try xterm here
<exarkun> and uxterm
<mgz> okay, happens in xterm with 2.4
<mgz> but not on 2.5 so the new shelve ui fixed whatever the issue was
<exarkun> wacky.
<exarkun> thanks.
<mgz> ah... er... any char will do?
<mgz> seems 2.4 defaults to 'n' for any unrecognised imput
<mgz> *input
<mgz> and I clearly suck at testing given I must have done something wrong when switching to the older branch first time around
<achiang> hello, i can't figure out how to specify a merge base revision, when there are no common ancestors
<achiang> staring at the bzr merge man page doesn't enlighten me, sadly
<achiang> "If this fails, you may need to give an explicit base."
<achiang> ok, but how?
<LeoNerd> Umm.. /can/ you merge with no common ancestors?
<LarstiQ> LeoNerd: one can
<LeoNerd> Sounds an unlikely thing to want, or that could possibly work
<LeoNerd> Oh.. hrmm.. OK
<LarstiQ> achiang: can you provide some more context to what you're trying to do?
<achiang> LarstiQ: i wish i could explain
<achiang> LarstiQ: https://bugs.launchpad.net/ubuntu/+source/appmenu-gtk/+bug/655241
<ubot5> Launchpad bug 655241 in AppMenu GTK+ "the pidgin accounts menus are not displayed" [High,Fix released]
<achiang> LarstiQ: at some point, i branched what i *thought* was  lp:ubuntu/maverick/appmenu-gtk
<achiang> LarstiQ: i made some changes...
<achiang> LarstiQ: today, i want to merge lp:~om26er/ubuntu/maverick/appmenu-gtk/appmenu-gtk-fix-655241
<achiang> but i guess my original branch came from somewhere else
<achiang> so looking in my bzr log, i see that, e.g., r56 of my copy == r27 of the source
<achiang> i don't know how i got in this state
<mwhudson> achiang: can you do bzr log -r 1 --show-ids in both branches?
<achiang> anyway, all i really want to do is cherry-pick r28 from source into my dest
<mwhudson> i have been known to do (cd ../other-branch ; bzr diff ) | patch -p0
<LarstiQ> achiang: when I run missing from your branch wrt the maverick one, you have one extra revision
<LarstiQ> achiang: so it seems they are perfectly related?
<achiang> LarstiQ: ah, no. i am not ~om26er, my branch isn't pushed anywhere
<LarstiQ> achiang: ah, ok
<LarstiQ> achiang: can you push it somewhere so we can have a look?
<achiang> one sec, getting info requested by mwhudson
<LarstiQ> sure
<achiang> LarstiQ: mwhudson: http://pastebin.ubuntu.com/834324/
<achiang> mwhudson: yeah, i know how to generate a manual patch. i guess i'm yak-shaving to try to learn a bit more about bzr right now. :)
<LarstiQ> achiang: aah
<mwhudson> the first one looks like a native bzr branch, the second is from the ubuntu package importer
<achiang> so, given that i have confidence the branches are pretty darn close, can i force bzr to merge from the source somehow?
<achiang> (again, i know how to generate a manual patch ;)
<LarstiQ> achiang: you can with `bzr merge -r 0..-1`
<LarstiQ> achiang: but the result is not something that I personally would submit
<achiang> why not?
<mwhudson> the file ids will be different too won't they?
<LarstiQ> achiang: merging unrelated branches is a hefty thing to do, you have to live with the complete history from both forever on
<mwhudson> so i think you'll have a pretty hard time getting bzr to do something useful
<LarstiQ> mwhudson: oh right, conflicts galore
<achiang> hummmmm.....
<LarstiQ> achiang: so while it is  possible, it will not be as clean as supplanting your revision on the other branch
<achiang> what does "supplanting your revision" mean?
 * LarstiQ wonders if rebase minds that the branches share no history
<LarstiQ> achiang: doing what mwhudson suggested with diff and patch
<LarstiQ> achiang: or rebase, or by hand
<LarstiQ> achiang: I may have abused the meaning of the English word :)
<achiang> LarstiQ: mwhudson: ok, thanks. i think, since my local branch doesn't really contain useful stuff anyway, i will just adopt the source branch wholesale. this probably means a push with a forced overwrite for where i plan on pushing.
<achiang> LarstiQ: mwhudson: thanks for the help
<mwhudson> np
 * achiang wonders where mwhudson is. isn't it night time in upside-down-landia?
<mwhudson> achiang: i'm in the bay area with linaro people
<mwhudson> but it's 8:30 or so at home, so i _could_ be up by now
<achiang> mwhudson: ah cool! i'll try and say hi tonight. i'm going to crash the computer history museum thingy. :)
<mwhudson> cool
<achiang> (and now i realize that's quite overloading the word 'crash')
<LarstiQ> LeoNerd: so the trick is that secretly all branches are related through the null revision
<LeoNerd> Ahhhh
<LarstiQ> achiang: let's hope you won't get kicked out of the us now for that ;)
<achiang> LarstiQ: heh. would the us deport its own citizens? i guess i shouldn't speculate. :-/
 * fullermd carefully steps away from achiang...
<achiang> ;)
<mathrick> hiya, just to make sure: the new multibranch format is compatible with bzr-colo, right?
<djfroofy> LarstiQ: sorry i was away. thanks for the tip using 'bzr merge ...'
<djfroofy> go back one space?
<djfroofy> woah ... sorry had my screen way scrolled up ... no context to that comment. nm. move along now.
<mathrick> hmm, is it safe to install a newer bzr windows standalone on top of an older one?
<SamB> mathrick: probably not a good plan
<mathrick> so uninstall, then install the new one?
<SamB> oh, if it's an actual full installer it's probably fine
<SamB> that just sounded suspiciously like "unpack new archive in existing tree" ...
<AuroraBorealis> doesn't it upgrade?
<AuroraBorealis> the windows installer one
<SamB> yeah
<SamB> pretty sure it does
<AuroraBorealis> some installers (like vlc) just remove the old one
<AuroraBorealis> then reinstall
<djfroofy> i'm trying to merge in a branch i made and push to trunk on a project on lp and getting ...
<djfroofy> Transport operation not possible: readonly transport
<djfroofy> the command was: bzr push lp:~djfroofy/someproject/trunk
<djfroofy> any ideas?
<djfroofy> more specifically ... bzr: ERROR: Cannot lock LockDir(chroot-76185552:///~djfroofy/someproject/trunk/.bzr/branch/lock): Transport operation not possible: readonly transport
<poolie> hi
<poolie> this means you don't have write access to that branch
<poolie> hm
<djfroofy> poolie: odd ... this is a project i created ... yada yada
<poolie> if it's your own user id that's a bit strange
<djfroofy> yep
<poolie> try 'bzr launchpad-login djfroofy'
<djfroofy> poolie: ok just tried that and: http://paste.pocoo.org/show/548011/
<poolie> interesting
<poolie> does that file exist?
<djfroofy> no it doesn't
<djfroofy> "Use ssl.cert_reqs=none to disable certificate verification."
<djfroofy> poolie: do you know if that's something i add to a bzr config file or sth?
<poolie> or install ca-certs
<poolie> *ca-certificates
<poolie> on ubuntu/debian
<poolie> or whatever it is on your os
<djfroofy> on mac os x
<djfroofy> yeah ...
<AuroraBorealis> i also do not have that directory
<AuroraBorealis> but launchpad-login (username) works fo rme
<djfroofy> great ... jinxed
<AuroraBorealis> where is bzr looking for ssl certificates?
<AuroraBorealis> or python rather
<djfroofy> when the singularity comes i'll be the first to be wiped out by evil machines
<LarstiQ> heh
<djfroofy> AuroraBorealis: so i don't know where it's looking. i'm new to bzr mostly
<LarstiQ> AuroraBorealis: you're using a slightly older bzr I guess
<djfroofy> 2.5b6
<AuroraBorealis> i'm using the latest stable
<AuroraBorealis> not that old...
<LarstiQ> djfroofy: the ssl certificate business here is being hammered out for 2.5
<djfroofy> AuroraBorealis: so the latest stable version is ... ?
<AuroraBorealis> 2.4.2 i think
<djfroofy> AuroraBorealis: awesome. thx.
<LarstiQ> vila: ^^
<djfroofy> i should afaik acutally by logged in to lp. been pushing to branches owned by myself, etc
<LarstiQ> djfroofy: what does `bzr info` or `bzr config` say is the push location?
<poolie> djfroofy, you can put 'ssl.cert_reqs=none' into ~/.bazaar/bazaar.conf
 * LarstiQ has a feeling the ssl certificate warning may be a red herring
<poolie> probably
<poolie> i would like to work out if he's connecting by ssh or not
 * LarstiQ nods
<djfroofy> thanks poolie. i'm reinstalling stable version (2.4.2) now and will try some other things if that doesn't work.
<djfroofy> LarstiQ: i'll let you know when i've finished reinstalling
<poolie> djfroofy, can you tell me the actual project name, or is it private?
<LarstiQ> djfroofy: sure thing
<LarstiQ> djfroofy: I will fall asleep at some point, but I can check the logs tomorrow
<lifeless> the .bzr.log may tel you
<poolie> o/ lifeless
<LarstiQ> lifeless \o/
<LarstiQ> lifeless: re bug 927581, I understand not wanting to change local path handling now, but initially I had expected bzr to be passing bytestrings to begin with
<ubot5> Launchpad bug 927581 in Bazaar "pypy raises UnicodeDecoderError on os.listdir(unicode) in a C locale" [Low,Confirmed] https://launchpad.net/bugs/927581
 * LarstiQ was a bit slow in discovering it was a unicode argument
<lifeless> LarstiQ: :) no worries
<LarstiQ> lifeless: anyway, the point is moot. Pypy has been fixed to behave in the same way, will be in 1.8 which is due out rsn
<LarstiQ> so maybe we'll get to a 0 failure run this month
 * LarstiQ babbles
<djfroofy> LarstiQ: no you're not allowed to fall asleep. you must stay up all night until my problem is resolved.
<djfroofy> ah ... good times: 2.5b6
<djfroofy> woops
<djfroofy> bzr: WARNING: bzrlib version doesn't match the bzr program.
<djfroofy> is what i meant to paste
<djfroofy> sorry for the play-by-play ... i'm reinstalling bzrlib now
<poolie> djfroofy, i really don't think going back to 2.4 is necessary
<poolie> you can just disable ssl validation and you'll get past that warning
<djfroofy> poolie: yeah ... i'm going to try that ... except now i've already gone back ... sort of. the bzrlib dep mismatch is ugh ... a problem.
<lifeless> LarstiQ: cool
<poolie> djfroofy, how did you install it?
<djfroofy> poolie: pip install bzr==2.4.2
<djfroofy> poolie: and i'm reinstalling now just the regular ol' way that always works. downloaded the package ...
<Jesdisciple> when I commit, I'm given a commit message to edit...
<Jesdisciple> But how do I submit that message?
<Jesdisciple> the only way I've found so far is to save a message to disk and specify it with -F / --file=
<Jesdisciple> both the default behavior and -m / --message= leave me hanging and I just end up using Ctrl+C
<djfroofy> poolie: the project name is bafload btw ... sorry i missed that
<AuroraBorealis> bzr commit -m "something" should work
<poolie> Jesdisciple, when you interrupt it, there should be a traceback in ~/.bzr.log saying what it was doing
<Jesdisciple> checking
<Jesdisciple> in which directory?  pwd as of the call to commit?
<Jesdisciple> I'm not seeing anything unless it's deep within .bzr
<Jesdisciple> ah woops
<Jesdisciple> missed the ~
<djfroofy> poolie: tried everything ... wuh wuh
<djfroofy> (bafload)quaternion:trunk dsmathers$ bzr launchpad-login djfroofy
<djfroofy> (bafload)quaternion:trunk dsmathers$ bzr push
<djfroofy> Using saved push location: bzr+ssh://bazaar.launchpad.net/~djfroofy/bafload/trunk/
<djfroofy> bzr: ERROR: Cannot lock LockDir(chroot-85139408:///~djfroofy/bafload/trunk/.bzr/branch/lock): Transport operation not possible: readonly transport
<djfroofy> sorry for the spam ...
<poolie> np, ok
<poolie> oh ok
<poolie> it's an import of a bitbucket branch
<poolie> that's why you can't push to it
<Jesdisciple> BzrError: Must end write group before releasing write lock on CHKInventoryRepository('')
<Jesdisciple> (the single-quotes had a long path)
<djfroofy> poolie: righto
<djfroofy> the idea was to ditch the bitbucket one and just start using lp
<djfroofy> since it related to some other projects on lp, namely txaws
<djfroofy> big dat red herring
<djfroofy> s/dat/fat/
<poolie> djfroofy, ok, i see
<poolie> so then i suggest you rename this branch to, say, 'import'
<poolie> then you can push your local copy to that url
<poolie> and then you'll have made a new writable branch
<poolie> sorry the error message is so confusing
<djfroofy> poolie: rename or branch to another branch?
<djfroofy> it is confusing. life is full of confusing error messages.
<poolie> i'm suggesting you rename this one, so that the name 'trunk' is freed up
<djfroofy> okay
<poolie> also, you might like to make a 'bafload' team to own it
<poolie> not just you
<poolie> in case you expect more contributors later
<poolie> thanks for moving it
<poolie> i'm using txaws a bit myself
<djfroofy> poolie: yeah, i'll probably make a team later. thanks.
<djfroofy> i'm more just trying to get versed in lp
<poolie> https://bugs.launchpad.net/launchpad/+bug/543797 :-(
<ubot5> Launchpad bug 543797 in Launchpad itself "poor "readonly transport" message when trying to write to an import branch" [Low,Triaged]
<poolie> that's what bit you
<djfroofy> poolie: ok, so i renamed to import, made a branch off this named trunk and then push to that ... or sth. https://code.launchpad.net/bafload
<poolie> awesome
<poolie> you might like to mark that as the trunk branch in https://launchpad.net/bafload/trunk
<djfroofy> will that all for "bzr branch lp:bafload" for example?
<djfroofy> s/all/allow/
<poolie> yes
<djfroofy> hotness
<djfroofy> poolie: and ... no idea how to "makr that as the trunk branch" after some clicking around
<djfroofy> configure project branch?
<djfroofy> yep ... that did the trick
<djfroofy> poolie: thanks for all your help
<poolie> no problem, thanks for going through it with us
<poolie> ok i need to reboot to test something, biab (i hope)
<djfroofy> going home myself
#bzr 2012-02-09
<Twelf> Hi guys/girls, I'm confused as to how to restructure my repository to allow better developer visibility into each other's branches. I have set things up like this: http://wiki.bazaar.canonical.com/SharedRepositoryLayouts#nested-style-project-branch-sub-branch
<Twelf> If Alice creates a new feature branch in "project/alice/featureA", how can the other developers know that she created such a branch?
<AuroraBorealis> i dont think bzr will tell you, just gotta look or something
<Twelf> Hm yeah, this is not what I want then. Can you think of an alternate configuration (or some kind of plugin or web interface) that would make feature creation more visible?
<AuroraBorealis> http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/hooks-help.html
<poolie> Twelf, how do you want them to be told?
<AuroraBorealis> so it seems you just write a simple plugin
<AuroraBorealis> and then do in python however you want them to be notified, email, whatever
<Twelf> poolie: well, ideally, just by pulling project/alice
<Twelf> or some bzr command I'm not aware of
<poolie> ok i thought you meant you wanted them to be mailed or something
<AuroraBorealis> you could have it branch to their machine by using python right?
<Twelf> hm, I'm not sure
<Twelf> I think I am operating under the mistaken assumption that a shared repo enables this sort of functionality
<Twelf> maybe multi-pull in bzrtools would help
<poolie> yes i think that's what you want
<poolie> that will soon be built in
<poolie> as part of
<poolie> https://lists.ubuntu.com/archives/bazaar/2012q1/074217.html
<AuroraBorealis> what does multi pull do
<poolie> pulls all the branches from one repository
<AuroraBorealis> even if they are nested ?
<AuroraBorealis> like in that workflow twelf linked, where you have a branch that contains another branch, etc
<poolie> in a sub directory?
<poolie> i think it only goes down one level
<AuroraBorealis> http://wiki.bazaar.canonical.com/SharedRepositoryLayouts#nested-style-project-branch-sub-branch
<AuroraBorealis> i'm confused on if that workflow ^ means that every folder is its own branch or not, since bzr doesn't support that
<AuroraBorealis> so i think feature1 and feature2 are just folders?
<poolie> featureA will be a directory containing a .bzr/branch
<Twelf> yep, that's what it looks like in my test
<AuroraBorealis> so the top level directory has a 'trunk' folder too (thats not shown)?
<AuroraBorealis> it says its a shared repo and a branch
<Twelf> I created a shared repo at "project", and then "project/trunk", "project/alice", "project/bob", "project/bob/featureA", etc.
<AuroraBorealis> yeah ok.
<Twelf> I wonder if bzr_access will be compatible with the new colo stuff. I do need to restrict access for some developers to certain branches
<AuroraBorealis> docs are slightly confusing in that regard, since it doesn't support nested branches (like svn)
<poolie> biab
<Twelf> thanks poolie
<vila> hi all !
<mgz> morning!
<vila> morning mgz !
<hariom> Hi, it appears that I have hit the bug where pycurl is not verifying the self signed cert. Is there any solution?
<mgz> what version of bzr and what platform?
<mgz> what you probably want is to install the self signed cert into your system's location for certificates
<hariom> mgz:    bzr = 2.4; ubuntu: 10.04 LTS
<mgz> so, try copying the .pem to /etc/ssl/certs then run update-ca-certificates
 * mgz is just googling this
<chmac> Can I see the history of a file if it was previously deleted, then a new file of the same name created?
<mgz> yup.
<mgz> ...what, you want to know how? :)
<fullermd> Yes, although how is always the opposite of the way I want.
<chmac> mgz: Yes please :-)
<mgz> fullermd, please enlighten us.
<fullermd> A number of commands can take a revision and a filename.  IME, they all lookup the fileid from the filename as of that revision, except for the ones where I want it to lookup the filename as of current and backtrack to that rev.
<fullermd> And I think I meant "except that" there.  Dunno.  Viri stealing my brainz.
<mgz> basically `bzr log -r<a revision the file existed> <the filename at that point>` should work
<mgz> alternatively you can find the fileid, then use that in some places
<fullermd> Probably have to dig through logs to find the rev where it was deleted, then do something like `log -r0..$THAT $FILE`.
<fullermd> Or maybe ..before:$THAT, since in $THAT it's deleted.
<fullermd> I've wished for the ability to explicitly pass fileid's to things like log/diff/etc a number of times in the past   :|
<mgz> that might make a few things easier indeed.
<chmac> mgz: Thanks, I'll look into it now
<chmac> Awesome, thanks folks, I have my old my.cnf back thanks to etckeeper :-)
<mgz> good good :)
<mgz> hm, dulwich has a copy of the lru_cache module
<libertas> hi, I have a conflict I've not been able to resolve: Path conflict: bin/update_bds.OTHER / <deleted>
<libertas> the file is not there, how can I do this?
<mgz> libertas: `bzr resolve bin/update_bds.OTHER` probably
<mgz> though as it's an OTHER file you may have done something a little wrong during the merge, so I'd double check the diff of changes as well
<libertas> it resolved now, strange, I guess I was inside bin/ and it wasn't doing it...
<libertas> mgz thank you!
<fullermd> That probably means that you deleted the file in your branch, and the branch you merged made changes to it.
<mgz> okay, first upgrade pain, consolekit hung itself
<fullermd> Luckily, that never happens to me.  At least, I don't think it does.  I dunno how I'd know if it did.  Or what it is...
<mgz> I suspect freebsd saves you from such an 'upgrade'
<fullermd> Well, as near as I can tell at a glance, it's some internal bit of gnome.  Not messing with such a thing also saves me  :p
<crisb> can anyone recommend an approach to me regarding automatically updating a bug tracker when --fixes is specified on commit? ie should this be done at the repository side, if so how to do this from a push request?
<crisb> i'm thinking it must be the repository side so that a public branch name is available
<LarstiQ> crisb: trac-bzr might have some way of doing that?
<LarstiQ> Jesdisciple: concerning your commit message, if I understood it correctly: an editor pops up, write your message, and save and quit the editor
<LarstiQ> crisb: so you can have a hook local when the commit happens, or in some central location that gets pushed to (smart server hook if you use that, or then cron/inotify/something like that)
<iamben> hello sirs.  is threads support on python required unconditionally for bzr?
<mgz> no. but we use the logging module which imports it.
<mgz> dummythreading should be enough
<mgz> +_
<iamben> so this logging module can be disabled? simple "bzr init-repository --no-trees <repo-addr>" errors w/o threads support
<mgz> python should work still provided you have the dummy_threading module
<mgz> what's the extact error?
<mgz> !pastebin
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<iamben> http://paste.pocoo.org/raw/548446/
<iamben> i know that i can fix it by adding threads support, i just want to make sure my distro has their dep list correct
<mgz> ah, that looks like our fault
<mgz> try hacking in something like:
<mgz> import dummy_thread
<fome> hi, im trying to branch a package of launchpad and i allways get this error: bzr: ERROR: Revision {package-import@ubuntu.com-20110812122506-zko6c7zfexvyg71q} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
<fome> any idea what that means?
<mgz> sys.modules['thread'] = dummy_thread
<iamben> mgz: i'm no python guy but i hacked these 2 lines into /usr/lib64/python2.7/site-packages/bzrlib/bzrdir.py and it works, is that what you were thinking?
<mgz> anywhere will do, it's a global change
<mgz> I was thinking of the bzr script, but shows that dummy_thread is enough
<mgz> grepping shows we only use thread.get_ident except in the smart server and testing using the smart server
<jelmer> fome: hi
<jelmer> fome: I think that can be avoided by disabling the up-to-date-ness check in bzr
<iamben> mgz: /usr/bin/bzr is some kind of wrapper script on gentoo, i'll just report this and let our bzr and/or python maintainers decide what to do, thanks
<fome> jelmer: how would i go about that?
<iamben> mgz: is this dummy_thread module a kind of "safe fallback" that will use threads when available, or do we need to use it conditionally ONLY when threads are not wanted?
<mgz> iamben: I'm not clear from the python documentation on who the onus to do this fallback is,
<jelmer> fome: set launchpad.packaging_verbosity=False in the configuration
<lifeless> iamben: I suggest you just require a threaded python
<mgz> either every python module that uses either the thread or threading module,
<lifeless> iamben: pretty much /every/ build of python out there that isn't on tiny embedded systems is threaded.
<mgz> or the maintainers of python distributions that build without threading enabled
<iamben> i'll just report with a suggestion to force threading, and mention the possibility of dummy_thread
<jelmer> iff building without thread support is really something we want, then I'd argue this is a bug in the logging module
<mgz> well, I think logging actually uses threading, which *does* fall back to dummy_threading correctly
<mgz> but thread does not automatically fall back to dummy_threading
<mgz> and a few of the smart bits import it just for get_ident (the actual smart server does want to start threads),
<mgz> but for some reason we're pulling in enough in bzrdir to import thread in some train from there apparently
<jelmer> hmm, odd
<jelmer> anyway, EOD.. time for some lp hacking :)
<mgz> that's what I'm guessing from the traceback and grepping around at any rate, I've not actually traced it
<mgz> I need to finish bending twisted to my will first...
<mgz> gah, that was a silly error to waste half an hour on
<LarstiQ> mgz: twisted?
<mgz> don't ask >_<
<mgz> the best way I found of debugging this test was waiting the 120 seconds for the timeout
<mgz> there was a timeout param on an object that din't actually change the duration
<LarstiQ> mgz: d'oh
<mgz> I think there are probably cleverer ways of doing lots of these things but I've yet to learn them
<mgz> okay, done
<mgz> time to head down
<wgz> hm, now what
<LarstiQ> wgz: should I close a bug as Inv
<LarstiQ> alid if work somewhere else has already taking care of it?
<wgz> LarstiQ: hm.
<LarstiQ> s/taking/taken/
<wgz> in this case that's probably the best option,
 * LarstiQ was looking for a "Not For Us" option
<wgz> as we want a record of the bug, but aren't going to be changing how we use os.listdir for this reason
 * LarstiQ nods
<bdmurray> I've noticed that the update-manager branch for lucid is out of date
<bdmurray> Is there something that can be done to fix this?
#bzr 2012-02-10
<bdmurray> I've noticed the update-manager branch for lucid-updates is out of date.  Is there anything that can be done?
<spiv> bdmurray: possibly; at a glance it appears someone may be able to run the missing-chk repair script on that import to get it going again
<bdmurray> spiv: someone being?
<spiv> Someone with admin access to the package-import.ubuntu.com system; poolie in this timezone, if he's around.
<spiv> In general anyone on the ~canonical-bazaar team
<spiv> And maybe one or two other folks.
<bdmurray> spiv: okay, thanks
<lifeless> a good thing to do is to file a bug on udd
<poolie> hi spiv
<poolie> hi bdmurray, i'll have a look in a bit
<bdmurray> poolie: thanks
<Jesdisciple> LarstiQ, yeah I finally figured it out...  QtCreator is my default editor for bzr, and I was saving and closing the document but not closing the QtCreator window. So that process was blocking the progress of the commit, then I hit Ctrl+C to try again
<poolie> k night all
<LarstiQ> Jesdisciple: aha! Wonder if there is a way to signal QtCreator is done with the document without quiting
<vila> hi all !
<fullermd> ETOOCHEERFUL
<AuroraBorealis_> apparently freenode is getting ddosed
<vila> fullermd: that's to exorcise my upgrade troubles
<fullermd> Oh, did mgz infect you?
<vila> hehe, not even ;)
<fullermd> Y'know, you wouldn't have these sort of problems if you used a real OS   ;p
<fullermd> Instead, you'd have totally different problems.  But they'd be problems I could solve with a wave of my hand and a condescending half-smile.  Which is kinda fun.
<vila> hehe, yeah, I appreciate that when I use those kind of OS ;)
<kgoetz> hi all. can i bzr add with excludes? 'bzr help add' doesn't mention it, but i thought i'd ask anyhow
<kgoetz> just tried, didn't work. ah well
<mgz> kgoetz: you mean, more than just `bzr ignore` on files you don't want versioned?
<mgz> you want to only prevent a subset being added, and only right then?
<kgoetz> yeah. want to ignore half a dozen files and add 'other'
<kgoetz> ignore hten add instead of add then ignore could be a winner, thanks
<jml> how can I set submit-branch to local trunk for all branches in my colo?
<mgz> how do you do it when not using colo?
<mgz> jml: I guess that's a zen way of saying I'm not aware of any way of automatically setting the submit branch across multiple branches, so file a bug.
<jml> mgz: I think I can do it by editing my locations.conf
<jml> mgz: which is a bit yuck.
<mgz> yeah, that would work provided you don't move the repo
<jml> it would be nice if there were a single character shortcut for 'file:,branch='
<jelmer> jml: there's an open bug about that
<jml> I guess it would be better still if it could just be inferred
<jelmer> jml: ideally most commands will just take a branch name without anything special (like switch)
<jml> jelmer: what does 'file:' mean anyway? cwd? path to the repo?
<mgz> it's a relative path
<jml> yeah, but relative to what
<mgz> ah, er, there was some question about what exactly locations.conf should be doing there
<mgz> and I can't remember which is currently the truth :)
<jml> oh well, at least my ignorance is in good company :)
<jelmer> jml: It's a shorthand for "file://`pwd`/" basically
<jml> jelmer: thanks.
<AI-team> [13:26] <AI-team> @anyone how is familiar with bzr on windows[13:26] <AI-team> "Doing on-the-fly conversion from RepositoryFormatKnitPack4() to RemoteRepositoryFormat(_network_name='Bazaar repository format 2a (needs bzr 1.16 or later)\n'). This may take some time. Upgrade the repositories to the same format for better performance. bzr: ERROR: An inconsistent delta was supplied involving '<unknown>', '4612@7d95bf1e-0414-0410-9756-b784
<AI-team> woops
<AI-team> <.<
<AI-team> ok so again, is there anyone that is familiar with bzr on windows?
<mgz> file a bug and attach the part of .bzr.log (running `bzr version` will tell you where that is) that ends in that error
<mgz> after that, what you probably want is to upgrade the source repository to 2a
<AI-team> it's not my repository it's just a branch
<AI-team> but I will attack the bzr.log
<AI-team> voila
<AI-team> http://pastebin.com/AqmriiSN
<AI-team> you can skip the first part, it's just the lock breacking
<mgz> AI-team: run `bzr upgrade C:/Users/Nik/Desktop/tron/0.4` from cmd
<mgz> then try `bzr push lp:~ai.tron/armagetronad/0.4-chat_layere` again from cmd as well
<AI-team> kk
<AI-team> I'm getting exactly the same error again
<AI-team> just tried upgrading again and now it worked o.o
<AI-team> mgz: alright a different error is appearing now
<AI-team> http://pastebin.com/8f83A54v
<AI-team> how come it says "~ai.tron/armagetronad/0.4-chat_layere" with an "e" at the end?
<wgz> is that not what it should be?
<AI-team> no
<wgz> did seem a bit odd
<AI-team> and it only says "layere" at the end of the file
<AI-team> however in the beginning it's without the additional e
<AI-team> hmm according to the arguments I said layere
<AI-team> which I did not do as you can see at the first line
<wgz> if you run `bzr info` in your local branch what does it say?
<wgz> you might just want to correct the parent_branch config setting
<AI-team> Standalone tree (format: 2a) Location:   branch root: .  Related branches:     push branch: bzr+ssh://bazaar.launchpad.net/~ai.tron/armagetronad/0.4-chat_layer/   parent branch: bzr+ssh://bazaar.launchpad.net/%2Bbranch/armagetronad/0.4/
<wgz> odd, probably just a display bug then.
<AI-team> I hope so
<AI-team> ok so back to the actual error
<AI-team> "has no revision"
<wgz> okay, so the current issue is:
<wgz> File "bzrlib\vf_repository.pyo", line 2547, in _walk_to_common_revisions
<wgz> NoSuchRevision: CHKInventoryRepository('file:///C:/Users/Nik/Desktop/tron/0.4/.bzr/repository/') has no revision picnik2@online.de-20120209231332-zv4rslfrlsel5bmt
<AI-team> ofc it has to revision yet
<AI-team> as I can't even push to it
<wgz> this is basically a sign of your local repo missing some revision your locale branch thinks it has
<wgz> as in bug 903906
<ubot5`> Launchpad bug 903906 in bzr (Ubuntu) "bzr crashed with NoSuchRevision in _walk_to_common_revisions(): CHKInventoryRepository('file:///home/username/code/unity/.bzr/repository/') has no revision <email address hidden>" [Undecided,Incomplete] https://launchpad.net/bugs/903906
<wgz> it's generally related to moving a branch with a stacked or shared repo
<AI-team> so I just fetch the files again?
<AI-team> (and delete the old ones)
<wgz> the easiest way to fix is probably to convert your local branch to use a shared repo
<wgz> then branch upstream into that same shared repo
<wgz> so, `bzr init-repo C:/Users/Nik/Desktop/tron/`
<wgz> `bzr branch lp:<whatever_upstream_is> C:/Users/Nik/Desktop/tron/trunk`
<wgz> `bzr reconfigure --use-shared C:/Users/Nik/Desktop/tron/0.4/`
<wgz> you follow me?
<AI-team> yes
<wgz> then your upstream copy and local branch with changes use the same repo, which should contain all the revisions needed after the change
<AI-team> ok
<AI-team> kk I folled all the steps
<AI-team> will try to push it again
<wgz> *hope*
<AI-team> umm
<AI-team> my upstream copy is empty yet, so it even make sense to branch it?
<wgz> you want the actual upstream, or the 0.4 series to be specific
<wgz> it appears to be lp:armagetronad/0.4 - you want to branch that into your shared repo
<AI-team> oh
<AI-team> I'm an idiot
<AI-team> I branched my empty one
<wgz> well, no harm, delete that dir and branch the right one instead
<AI-team> bazaar hates me
<AI-team> "RemoteRepositoryFormat(_network_name='Bazaar pack repository format 1 with rich root (needs bzr 1.0)\n') to RepositoryFormat2a(). This may take some time. Upgrade the repositories to the same format for better performance. bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', 'InconsistentDelta', "An inconsistent delta was supplied involving '<unknown>', '4612@7d95bf1e-0414-0410-9756-b78462a59f44
<AI-team> I guess upgrade would do the job?
<jelmer> AI-team: hmm, that almost looks like there's something problematic in your original branch
<jelmer> AI-team: is this an import from svn?
<AI-team> not sure
<AI-team> might be
<wgz> AI-team: it's possible the upstream branch is what really needs fixing
<AI-team> is there a way to make sure it's the upstream branch that's causing the error?
<wgz> jelmer may have some more ideas
<AI-team> ok
<AI-team> ):
<jelmer> I don't really have any other ideas, other than that the original branch might be broken in some way
<jelmer> what's the original branch, perhaps one of us could verify that?
<AI-team> https://code.launchpad.net/~armagetronad-dev/armagetronad/0.4-armagetronad-work
<AI-team> jelmer so?
<mgz> AI-team: two things you can usefully do
<AI-team> yes?
<mgz> 1) tell one or both of the project maintainers and launchpad that you can't branch the project
<AI-team> yeah that's what I was gonna do asap
<mgz> 2) file a bug against bzr with the log extract from the simplest way you can get the error
<AI-team> kk
<mgz> the ~launchpad-users team mailing list is a reasonable place to start
<mgz> if you can do a fresh branch, to a new location, of the upstream 0.4, then upgrade that local copy, then try and branch that into the shared repo,
<mgz> that may either work or fail with a more useful error than the ErrorFromSmartServer you got last
<AI-team> that's what I'm trying right now
<mgz> ace.
<mgz> thanks for persisting.
<AI-team> ;)
<AI-team> mgz I created a new branch on the launchpad website and now it's working o.o
<mgz> well, that's fine too
<AI-team> thanks for all your help :)
<mneptok>  /m cr3 meep
<mneptok> gah
<vindolin> hello, how do I view a file from a specific revision without checking it out first?
<vila> vindolin: bzr cat -r<specific revision> file
<vindolin> oh.. cat.. thanks :)
<djfroofy> so ... i think the git concept of "cherry-pick" is not exactly anolgous to "bzr merge -r <revno> some-other-branch" so far as a i can tell
<jelmer> djfroofy: no, that's not a cherrypick - that's merging the changes up to <revno>
<jelmer> djfroofy: a cherrypick merge would be 'bzr merge -cX'
<djfroofy> jelmer: right, that's what i was noticing
<djfroofy> what is X? the rev no?
<jelmer> djfroofy: yep
<djfroofy> and is there an additional arg after that for the branch?
<jelmer> djfroofy: yes
<djfroofy> jelmer: awesome. thank you.
<crisb> is there any way to get the value passed to --fixes in the pre commit hook?
<jelmer> crisb: I think it might be in the commit object, in the revision properties
<crisb> thanks jelmer
<djfroofy> back to my cherry-pick question ... what's the correct way to cherry-pick from someone's branch and note the real author's name? (give credit where credit's due etc)
<djfroofy> something like [a=whoever] in the commit message?
<mgz> --author
<djfroofy> mgz: so bzr commimt --author lpusername ...?
<djfroofy> s/commimt/commit/
<mgz> see `bzr help commit`, format is Real Name <email@example.com>
<mgz> same as for `bzr whoami` / committers
<djfroofy> ok
<djfroofy> no bzr whoarethey?
<djfroofy> hehe
<mgz> generally if you know the lp username that page will give you the info you need
<mgz> and can get that via the lp api
<mgz> a whoarethey would be nice though :)
<djfroofy> how so?
<djfroofy> yeah, like bzr whoarethey djfroofy mgz ...
<mgz> what's your lp nick?
<djfroofy> mgz: djfroofy
<mgz> bah, slowed down by the auth mess
<mgz> and sso is borked since last I did this... so much for demonstrating how easy it is
<mgz> okay, hoops jumped
<djfroofy> hehe no
<djfroofy> s/no/np/
<mgz> and... a UnicodeDecodeError on the new password handling
<mgz> I think I should have just downgraded launchpadlib instead
<mgz> I'll try upgrading first in vain hope
<djfroofy> so i'm finiding bzr's merging less smooth than git's. or at least i'm having way more merge conflicts that are messy and hard to resolve. placebo effect?
<djfroofy> i wish that's something i could help with. good merge algos are above my head.
<mgz> it's possibly workflow related?
<mgz> if you're used to just copying files around or creating them in multiple branches,
<djfroofy> well, i'm trying to cherry-pick certain revisions from old branch (started in 2009), so possibly
<mgz> then tracking fileids hurts rather than helps
<djfroofy> i should probably take that branch and try to merge trunk into it first or sth
<djfroofy> i'm used to git, not copying files around
<mgz> okay, I forgot what a massive pain launchpadlib is to do anything with
<mgz> djfroofy: sooo... about how easy that was
<mgz> >>> from launchpadlib.uris import LPNET_SERVICE_ROOT
<mgz> >>> from launchpadlib.launchpad import Launchpad
<mgz> >>> #lp = Launchpad.login_with("gz throwaway script", service_root=LPNET_SERVICE_ROOT)
<mgz> ...
<mgz> >>> djfroofy = lp.people['djfroofy']
<mgz> >>> "%s <%s>" % (djfroofy.name, djfroofy.preferred_email_address.email)
<mgz> the only fun part is the dance needed for login
<djfroofy> mgz: thanks. i think we should expose this as a command to bzr. i'll note this and see if i have time to contribute such a thing: whoarethey or whatever
<djfroofy> or i'll just open a ticket noting this
<mgz> yeah, file a bug, it's the kind of thing bzr's launchpad plugin could supply a command for, and would be a good thing to try writing if you're interested
<djfroofy> mgz: under bzr project?
<mgz> yeah
<djfroofy> cool: https://bugs.launchpad.net/bzr/+bug/930319
<ubot5`> Launchpad bug 930319 in Bazaar "Add a "whoarethey" option for lp plugin" [Undecided,New]
<djfroofy> ugh .. add a "command" not "option"
<mgz> you can edit :)
<djfroofy> righto ... did that. thanks :)
<djfroofy> are there ways to link current branch to tickets with the bzr command line or does this need to be done on lp?
<jelmer> djfroofy: you can link particular commits to bugs by using "bzr commit --fixes"
<jelmer> djfroofy: launchpad will recognize that and create links in the web UI
<djfroofy> jelmer: thanks
#bzr 2012-02-11
<Noldorin_> hi folks
<Noldorin_> jelmer, :-)
<jelmer> hi Noldorin_
<Noldorin_> how's things?
<jelmer> alright, how are you?
<Noldorin_> good ta
<Noldorin_> busy, so not been working in my bzr projects lately :-(
<Noldorin_> all hg :O
<Noldorin_> i know, shock horror
<Noldorin_> hg at work
<Noldorin_> no git at all fortunately...
<Noldorin_> speaking of which, bzr-git progressing nicely?
<jelmer> Noldorin_: haven't really had time for it recently, mostly hacking on Samba in my spare time atm
<Noldorin_> ah okay
<Noldorin_> Linux Samba eh?
<Noldorin_> jelmer, i'm still scared of python, else i would have fixed my bug long ago ;P
<Noldorin_> not a fan of the language
<jelmer> Noldorin_: not Linux-specific, anything POSIX
<Noldorin_> jelmer, whenever someone says POSIX we all know they're really targeting Linux ;-)
<Noldorin_> or MAYBE bsd
<Noldorin_> just maybe
<jelmer> Noldorin_: no, it's really POSIX in general. Lots of AIX/Solaris too.
<Noldorin_> but do you care about that stuff or are you really interested in Linux support ? :-P
<jelmer> Noldorin_: me personally, I'm mostly interested in Linux. But that's not the same across the rest of the team.
<Noldorin_> jelmer, ok so i WAS right about you ;-)
<Noldorin_> although i take your point
#bzr 2012-02-12
<Noldorin> hi again jelmer_
<jelmer_> hi Noldorin
<Noldorin> jelmer, i was thinking, since this bug fix might not happen for years, mind doing a quick write-up of what needs to be done? ;-)
<jelmer> Noldorin: IIRC I already did that on the bug report?
<Noldorin> jelmer, it was very brief, and quite unclear to me :-(
<Noldorin> perhaps if you explain a bit more, i can rephrase
<Noldorin> i know it's not always easy when it's not one's native language
<jelmer> Noldorin: Sorry, I don't think I can add much more detail than that without actually spending an hour or two on it myself
<Noldorin> hmm ok
<Noldorin> :-(
<Noldorin> the problem is
<Noldorin> it's not enough for someone to solve it themself
<Noldorin> unless they know bzr really well
<jelmer> Noldorin: I don't think it's really "if they know bzr really well"; they do however have to be aware of the internal models of both bzr and git
<Noldorin> that's what i mean :-P
<jelmer> Noldorin: I don't see how you could fix this bug without being aware of that though
<Noldorin> you're just getting into semantics now
<Noldorin> no indeed
<jelmer> the alternative is for me to spend a day or so and describe in very fine detail what needs to be done
<jelmer> but at that point I might as well do the fix myself
<jelmer> I don't think it's fair to say that it will take many more years for this bug to be fixed
<Noldorin> haha
<Noldorin> "many more"
<Noldorin> just 1 eh? ;-)
<jelmer> Noldorin: no idea, sorry
<jelmer> Noldorin: this is a corner case bug in an experimental feature of something I work on in my spare time
<Noldorin> *wanders off to Hg*
<jelmer> I appreciate that you are hitting this, but I have only 24 hours in my day
<Noldorin> they seem to be more active :-)
<Noldorin> pfft
<jelmer> Noldorin: fair enough
<Noldorin> this take 2 hours to fix
<Noldorin> been going on 6+ months now :-P
<Noldorin> i've had enoug hi think
<mathrick__> hmm, bzr+ssh:// results in smart protocol being used, but with appropriate credentials, right?
<mathrick__> and it requires a compatible bzr version to be installed on the remote side
<lifeless> yes, though bzr is wide compatible with itself
<mathrick__> lifeless: not when I use the development format on the branch, though. Or is it?
<lifeless> if that dev format is supported by the bzr at the other end it should be
<lifeless> it will narrow the options though
<mathrick__> well yeah, but it's the current format, which means 2.5b
<mathrick__> hmm, what's the bzr send syntax for "send a packaged patch of the current branch for revisions 19 and later"?
<mathrick__> lifeless: any hint on the above?
<lifeless> bzr send -r 19.. ?
<mathrick__> lifeless: oh right, I mean "without consulting the submit branch, just locally"
<lifeless> mathrick__: I don't know, sorry.
<mathrick__> ok
<lifeless> possibly -r 19..-1 . or something
<lifeless> mathrick__: you could have a copy of the submit branch locally
<mathrick__> well yeah, but at this point I think it's faster to wait for the terribly slow submit branch than to copy
<lifeless> mathrick__: well I mean you can carry it round with you routinely
<lifeless> mathrick__: doesn't matter if its a bit stale when you submit that way
<lifeless> there are folk that have run totally disconnected from each other, both with a copy of the others branch, kept up to date with send
<mathrick__> lifeless: I know, it was a stop-gap measure though intended to save time (very slow push branch and it just decided to repack the whole 80MB of history), rather than systematic solution
<mathrick__> I just hoped file:.,revno=19 would help, but apparently it doesn't
<thumper> bzr error in recipe build: https://launchpadlibrarian.net/92511530/buildlog.txt.gz - anyone got an idea what it means?
<jelmer> thumper: you have whitespace at the beginning of the control file
<jelmer> thumper: this causes older versions of python-debian to blow up
<thumper> um...
<jelmer> thumper: actually, whitespace or comments
<thumper> since it uses nest part, I'll ahve to look
<jelmer> thumper: there is an RT open about upgrading python-debian, FWIW. there are a lot of desktop team packages that are affected by this bug
<thumper> jelmer: http://bazaar.launchpad.net/+branch/compiz/view/head:/debian/control
<jelmer> thumper: according to the log file, you're using a different control file
<jelmer> thumper: http://bazaar.launchpad.net/+branch/~smspillaz/metacity/metacity.lim/view/head:/debian/control
<thumper> hmm...
<thumper> perhaps I was looking at the wrong build...
<jelmer> (which does have comments at the top of the control file)
 * thumper fines another
<thumper> https://launchpadlibrarian.net/92617403/buildlog.txt.gz
<thumper> this one had failed to upload
<jelmer> thumper: do you have the upload log?
<thumper> yes, just found it
 * thumper sighs
<thumper> INFO 	compiz_0.9.7.0~bzr2995-r3009really2995-p713~precise1.dsc: Version older than that in the archive. 1:0.9.7.0~bzr2995-r3009really2995-p713~precise1 <= 1:0.9.7.1-r3009really2995-p710~precise1
<thumper> jelmer: so... the first one
<thumper> jelmer: is there any workaround?
<jelmer> thumper: remove the comments from the beginning of the control file
<poolie> hi all
<jelmer> thumper: for the second, make sure that your recipe generates newer version strings for newer versions of the package
<jelmer> thumper: admittedly, launchpad's UI sucks in this regard at the moment
<thumper> jelmer: yeah... I'm using others branches
<thumper> jelmer: so I'm constantly surprised at what they have the values set to :(
<jelmer> 'morning poolie !
<jelmer> thumper: launchpad should be able to see that a build it's going to fire off will have a version string that's older than that of the last build; it shouldn't even start the build and print a clear error rather than failing confusingly during the upload
<thumper> jelmer: care to file a bug for that :)
<thumper> I'll "me too" it
<jelmer> I suspect I have filed on in the past
 * jelmer searches
<jelmer> I have done this thing previously where I reported the same bug 3 times over the course of 6 months...
<ubot5> Launchpad bug 3 in Launchpad itself "Custom information for each translation team" [Low,Fix released] https://launchpad.net/bugs/3
<poolie> jelmer, bugs.launchpad.net/~/+affectingbugs :)
<jelmer> poolie: 1 â 75 of 639 results :)
<poolie> yeah there is that
<jelmer> thumper: bug 670474 is part of it
<ubot5> Launchpad bug 670474 in Launchpad itself "Hard to make predictions about Debian version number" [Low,Triaged] https://launchpad.net/bugs/670474
<jelmer> thumper: filed bug 931131
<ubot5> Launchpad bug 931131 in Launchpad itself "shouldn't attempt to build out-of-date packages" [Undecided,New] https://launchpad.net/bugs/931131
<thumper> ta
<lifeless> jelmer: small request, if you would
<lifeless> jelmer: don't use imperatives in bug descriptions or summaries
<lifeless> jelmer: (for LP anyhow; I don't care what you do elsewhere :P)
<jelmer> lifeless: sure
<jelmer> updated bug 931131
<ubot5> Launchpad bug 931131 in Launchpad itself "attempts to build packages with version older than previous build" [Undecided,New] https://launchpad.net/bugs/931131
<jelmer> lifeless: is that better?
<lifeless> yes, much
<lifeless> https://plus.google.com/105660309458564946897/posts/BLhnbgoouXV <- my previous mention of this ;)
<lifeless> jelmer: I've tweaked it to say recipes too, but yeah, thanks.
<lifeless> jelmer: also, it looks like a duplicate to me :)
<poolie> snort
<jelmer> lifeless: I thought so too, but I couldn't find a bug it would be a dupe of
<lifeless> jelmer: bug 620248 ?
<ubot5> Launchpad bug 620248 in Launchpad itself "daily built recipes may error if a manual build has been done" [High,Triaged] https://launchpad.net/bugs/620248
<poolie> sorry
<lifeless> poolie: for being amused ?
<jelmer> lifeless: the have the same cause but are different bugs
<poolie> yeah it was a bit snarky, sorry
<poolie> but i was amused by repeatedly rephrasing it then duping it
<poolie> i do agree with the general thing of the g+ post
<lifeless> jelmer: I'm torn in such cases; probably mutually referenced each other in the summary is a good starting point
<lifeless> jelmer: when its the same root cause I usually do dup them, but list /all/ the symptoms
<jelmer> lifeless: I would argue that they should be two different bug reports precisely because of your G+ post
<poolie> but i think sometimes there is a semantic difference and sometimes it is just a different phrasing
<jelmer> it would be possible to fix one and not the other
<lifeless> jelmer: I would love it if we had [symptom ...] -> [cause] -> [fix ...] in our model
<lifeless> jelmer: I don't mind either way :) - just sharing how I try and balance these tensions
<poolie> a graph of nodes like that would be nice
<lifeless> poolie: I find it -much- easier, years later, to deal with reports that describe symptoms rather than solutions
<lifeless> poolie: having spent a few weeks earlier this year doing precisely that (dealing with years old reports), I'm more convinced than ever that it helps
<poolie> that is the general thing that i agree with
<jelmer> lifeless: sure :)
<lifeless> poolie: \o/
<poolie> istr asking you to do this in bzr too :)
<poolie> i'm just saying, if it's a transform from "shouldn't screw up X" to "screws up X"
<poolie> it's fairly mechanical, and not that hard to do it years later
<poolie> perhaps it's worth changing for the sake of setting a good example
<lifeless> sure, ack on that
<poolie> i wish people wouldn't file bugs like "bzr crashes while trying to push"
<poolie> :/
<poolie> ffs
<jelmer> poolie: that's still better than "bzr crash"
<jelmer> :P
<poolie> barely
<lifeless> I think its a combination of having good examples, good search juice, and making it easy for devs that decide to go spelunking in the bug db
<jelmer> lifeless: launchpad's search is a lot better than it used to be but still kindof sucks
<jelmer> browsing is a lot better than in e.g. bugzilla though
<poolie> btw did you see http://castrojo.tumblr.com/post/11360873455/lets-make-it-personal
<lifeless> poolie: I hadn't but I agree.
<lifeless> I wish folk would /do/ rather than /suggest/
<poolie> +1
<AuroraBorealis> well changing the layout of the profile dosn't seem like a trivial task, and a lot of people are better at ideas rather then coding :>
<poolie> though this is a rare case where it at least has inspiring mockups
<lifeless> AuroraBorealis: its a task which requires little guts-of-lp-knowledge
<lifeless> AuroraBorealis: so is amenable to folk that just want to get stuck in and help, and know e.g. html + css + (some) js
<poolie> there's a couple of things
<lifeless> AuroraBorealis: we mentor folk happily
<poolie> one is that peopel ought to customize it a lot
<poolie> the other is just removing a lot of the details of that page....
<lifeless> hide / delete  / shove to a dedicated directory service / ...
<poolie> a good mockup of the lp page that either preserves or specifically removes all the information that's currently on it would be more than half the way towards improving it
<AuroraBorealis> true.
<AuroraBorealis> i do agree that the main profile pages, and the main pages of projects are pretty ugly.
<AuroraBorealis> like github, you go to a project page and you see code / the information about the code
<lifeless> the problem is that we have so many /functional/ problems
<AuroraBorealis> takes a few clicks to actually see code, and even then its weird
<lifeless> that things like this are many many months or years away from getting traction
<lifeless> so unless (a) priorities change or (b) we get radically more efficient at development [trying to] or (c) someone steps up and does it, it won't happen
<AuroraBorealis> hmm.
<poolie> i reckon if someone had a compelling mockup that improved it they might get some volunteer development help
<abentley> jelmer: around?
<poolie> ok, rebooting precisely
<AuroraBorealis> i've been trying to get myself working on bzr code, but its hard to follow admittedly =P
<poolie> just ask here
<jelmer> abentley: hi
<abentley> jelmer: I'm trying to add native colocation support to bzr-pipeline.  I fail at creating a native colocated branch in a test case.  Can you help me get started?
<jelmer> abentley: ah, cool
<jelmer> abentley: what would you like to create exactly?
<jelmer> abentley: a colocated branch in a control directory that already holds an active branch and a working tree?
<abentley> I want to create a working tree with a single colocated branch.
<lifeless> AuroraBorealis: the lp code is rather different; some folk may find one easier than the other
<AuroraBorealis> well i'm interested in both =P
<AuroraBorealis> so in due time.
<poolie> o/ abentley
<abentley> poolie: o/
<poolie> you could say that lp is kind of a harder environment but easier code
<AuroraBorealis> my main problem with..python code i guess is i use a text editor, but then i cant like ctrl+click and go to a class/function definition
<AuroraBorealis> like i can with java/IDE =P
<poolie> you can use eclipse and pydev
<AuroraBorealis> yeah. i have been using that
<AuroraBorealis> since with unkown code its the only way i can even get anywhere
<lifeless> AuroraBorealis: wallyworld highly recommends some IDE whose name I forget
<poolie> jcharm?
<abentley> lifeless: You beat me to it.
<poolie> or, Wing IDE is pretty good
<lifeless> abentley: :)
<AuroraBorealis> jcharm is the ide?
<poolie> but, there is generally speaking, a problem that when python code says "o.foo_method()"
<lifeless> AuroraBorealis: wallyworld hangs out in #launchpad-dev, from ~ 1 hour from now, if you want to ask him
<poolie> it is anyone's guess what code that's actually going to call ;)
<abentley> jelmer:  I want to create a working tree with a single colocated branch.
<jelmer> abentley: I guess we could use a utility function for creating something like that in bzr core
<poolie> anyhow really rebooting
<AuroraBorealis> ok.
<jelmer> abentley: that could basically do:
<jelmer> abentley: x = self.make_bzrdir('.')
<jelmer> abentley: x.create_branch(name='colocated-thing')
<jelmer> abentley: x.set_branch_reference(_)
<jelmer> abentley: x.create_workingtree()
<abentley> jelmer: I have http://pastebin.ubuntu.com/839691/ from attempting to copy switch -b behaviour, but it doesn't work.
<mlh> AuroraBorealis: people I know love pycharm and sublimetext
<mlh> sublime is not free though
<mlh> oh, pycharm isn't either :-)  .  Both have free trial periods
<mlh> and windows /mac only
<jelmer> abentley: I don't think make_branch() will handle URLs with colocated branch names in them very well at the moment.
<abentley> jelmer: oh, I should have deleted that line, eh?
<jelmer> abentley: Yeah, I don't think that's necessary - sprout should already create the branch
<abentley> jelmer: Okay, that works.  Cool.  I'll still try it the way you showed, as that looks cleaner.
<AuroraBorealis> mlh, sublimetext works on linux too. I use them already =)
<mlh> AuroraBorealis: ah, that's new to me.  Not that I pay much attention.
<LarstiQ> AuroraBorealis: so is there anything you'd like to do with bzr code?
<AuroraBorealis> i have...like 2 bugs that i think are assigned to me at the moment
<AuroraBorealis> or i said i'd try and work on
<AuroraBorealis> https://bugs.launchpad.net/bzr/+bug/81689 and https://bugs.launchpad.net/bzr/+bug/847388
<ubot5> Launchpad bug 81689 in Bazaar "Branches with symlinks can't be checked out on Windows" [High,Confirmed]
<ubot5> Launchpad bug 847388 in Bazaar ""gpg: cannot open `/dev/tty': No such device or address" on Ubuntu when signing commits" [Medium,In progress]
<poolie> ooh they would be great to fix
<abentley> jelmer: given two branches, how would you detect whether they were colocated with one another?  I'd expect bzrdir.root_transport to the same, but it's not.
<poolie> i would be happy to talk about them with you
<AuroraBorealis> poolie, the second one i believe i have fixed, since all it involves is just adding '--no-tty' to the command line for gpg, i just need to test it on windows"
<jelmer> abentley: Branch.control_url
<AuroraBorealis> and the first one ive emailed someone about, and he said it would be fine if files that are symlinks are just checked out as text files with the 'location' inside the text file
<AuroraBorealis> since in the bug report, normal users don't necessarily have permission to do NTFS junctions
<abentley> jelmer: I get values like "file:///tmp/testbzr-Ca9fWS.tmp/bzrlib.plugins.pipeline.tests.test_pipeline.TestPipeStorage.test_insert_pipe_uses_native_colo/work/first/.bzr/branches/second/" for control_url, so the urls are going to be different even for colocated branches.
<poolie> perhaps there should be a method to check if they're the same, rather than defining that callers should check the urls
<jelmer> abentley: that's a bzr-colo branch
<jelmer> abentley: not a bzr 2.5 colocated branch
<jelmer> though I like poolie's suggestion of just adding a method for this
<abentley> jelmer: I'm calling bzrdir.sprout('file:///tmp/testbzr-Pm8VYT.tmp/bzrlib.plugins.pipeline.tests.test_pipeline.TestPipeStorage.test_insert_pipe_uses_native_colo/work/first/,branch=second') and getting a bzr-colo branch?
<jelmer> abentley: checkling..
<abentley> jelmer: I'm stepping through it with pdb, and "bzr branches" thinks it's colocated.
<jelmer> abentley: What does Branch.open(x).control_url say?
<jelmer> I wonder if there's an inconsistency here between Branch.open and BzrDir.sprout()
<abentley> jelmer: I've renamed 'first' to 'colo', and Branch.open(ctrl.root_transport.base).control_url => 'file:///tmp/testbzr-U_SFec.tmp/bzrlib.plugins.pipeline.tests.test_pipeline.TestPipeStorage.test_insert_pipe_uses_native_colo/work/colo/.bzr/branches/second/'
#bzr 2013-02-04
<MeaCulpa> merge from non-common ancestor... howto?
<MeaCulpa> Hi guys, I have a project dir under bzr control. Now I want to make a branch, containing only small txt files, delete those big files, and push to elsewhere. How can I merge it into original treee WITHOUT deleting the files I excluded in this branch?
<MeaCulpa> Do I have to specify the revision number the after the deleting action each time I merge?
<lifeless> MeaCulpa: yes, or you have to edit the merge before committing and revert the deletion of the big files.
<lifeless> MeaCulpa: why do you want to delete the files?
<MeaCulpa> lifeless: I figured out... I should have used the DELETED brance as master tree
<MeaCulpa> lifeless: And then add in those big files in another branch
<MeaCulpa> So they share same ancestor
<MeaCulpa> lifeless: My need is simple: My work have both binary and sourcecode/doc, I use ftp to store all of them, which is slow but unlimited in space
<MeaCulpa> and use Dropbox to store source/doc, which is fast, portable but lack space
<MeaCulpa> So now I working on the branch which pushed to dropbox, and keep thoese management chart shit in ftp
<MeaCulpa> Have to work like this unless human beings eliminate excel
<n00b99> is there a way to find when a particular line in a file was added/modified?
<LeoNerd> blame/annotate  ?
<n00b99> blame shows only the most recent revision for a particular line
<n00b99> if there were something that showed me all revisions which include a change to a given line that might be useful
<alkisg> Hi, what do I need to transfer to another PC in order to be able to push to my launchpad bzr branches? ~/.bazaar and what else, ~/.gnupg?
<alkisg> Ah, .ssh, got it
#bzr 2013-02-05
<Azendale> So, I have a bzr branch that I'm getting ready to release to other people. The problem is that way back in the commit history there is a password in a code comment. I could take the password out today, but it would still be in the history. (In fact, there is one commit that if I could make it so that it never happened, it would be perfect). Is there a way to do this?
<bob2_> bzr-rewrite and a lot of fiddling
<Azendale> Ok, thought it might be using that tool, but I'm not sure I get how the big picture would work
<Azendale> I'm guessing you branch before the bad commit
<Azendale> but from there I'm not quite sure. But the replaying patches part of rebase sounds like what I need. I'm just not sure how you keep it from replaying the bad commit
<leighman> get http://paste.ubuntu.com/1613366/ when trying to build with the following recipe http://paste.ubuntu.com/1613375/ any ideas?
<ccxCZ> are there any docs on sandboxing bzr to specific repo when used via .authorized_keys/sshd_config command= directive?
 * ccxCZ examines http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/view/head:/contrib/bzr_access
#bzr 2013-02-06
<bobsapp> hi guys is there a way to embed the revision number inside source code files?
<xnox> https://launchpad.net/bzr-keywords
<bobsapp> cool thanks xnox
<fullermd> 'keywords' is the search phrase you want to use (at least, when I started typing that, before xnox chimed in), but the answer in practice is 'not really that'.
<fullermd> The usual solution is something in a build process using 'version-info' or the like.
<xnox> ccxCZ: there was also a script in one of the "hosting" bzr docs to do gito-lite type authentication, where only a single user "bzr" exists with shell set to that script.
<bobsapp> I was thinking if that was the right thing to do.  esentially im trying to set the version number of my app in a javascript file.
<xnox> and then one could limit bzr to one dir and/or specific keys to limit to that repo.
<ccxCZ> xnox: thanks, I'm writing my own wrapper script since I'll be runing more than bzr. the regexp in the bzr_access seems reasonable, so I guess I'll replicate that in shell
<xnox> ok.
<ccxCZ> I don't need accounts, I'm just making sure the dir is within the allowed sandbox
<warren> I haven't used bzr in nearly 2 years.  Now wondering what happened to bzr-gtk.
<warren> Is it replaced by another tool, or merged into?
<gmarkall> warren: run 'bzr visualise' i think
<jelmer> gmarkall: 'bzr visualize' is a part of bzr-gtk
<jelmer> warren: bzr-gtk is still bzr-gtk, not replaced by anything or merged
<ScottK> Is there a document that explains how to set up a bzr repo remotely accessible via bzr+ssh where not all users have shell accounts on the host?
<xnox> ScottK: yes. there is a script in the admin book about setting that up.
<ScottK> Where do I find the admin book?
<xnox> ScottK: http://doc.bazaar.canonical.com/bzr.2.5/en/admin-guide/security.html#using-ssh
<ScottK> Thanks.
<xnox> ScottK: not sure if it's the right page.
<xnox> but somewhere there was a: gitolite equivalent for bzr
<ScottK> It's definitely part of the answer.
<xnox> Also "gitolite bzr" is good keyword to find it.
<ScottK> Thanks.
<warren> error: can't copy 'credits.pickle': doesn't exist or not a regular file
<warren> failure during setup.py install of bzr-gtk-0.104.0
<warren> https://bugs.launchpad.net/bzr-gtk/+bug/397526
<ubot5> Launchpad bug 397526 in Bazaar GTK+ Frontends "0.96.0, 0.99.0 tarball does not contain credits.pickle" [Critical,Fix released]
<warren> forget it..
#bzr 2013-02-07
<vinmassaro> Having trouble getting bzr-svn working. I've got bzr installed via homebrew and when i try to merge from svn, i get an error that "subvertpy is not installed". Any ideas how to fix?
<jelmer> vinmassaro: install subvertpy
<jelmer> homebrew should be installing it if it is supposed to install all bzr-svn dependencies
<vinmassaro> jelmer: hmm, i don't see it
<jelmer> vinmassaro: how do you mean? subvertpy isn't installed?
<vinmassaro> jelmer: i mean i don't see it installed by homebrew
<jelmer> vinmassaro: that sounds like an issue in homebrew
<vinmassaro> jelmer: what's the easiest way i can install it under MacOS?
#bzr 2013-02-08
<Wiz_KeeD> hey guys
<Wiz_KeeD> If i have a ubuntu server and ssh access to it, how can i init a bzr branch and pull/push from localhost? :D
<Wiz_KeeD> anyone?
<Wiz_KeeD> anyone online?
<maxb> Uh, use the bzr init, push and pull command?
<Wiz_KeeD> Well how will that work? I went to the dev server did bzr init
<Wiz_KeeD> then what?
<trident_job> Hi there. I've seen that latest bzr version is v2.6.2 and is 1 year ago (nearly).
<trident_job> next version v2.6.3 still have 3 bugs to fix ... do you think the project is stall ?
<mgz> we lack anyone who's job it is to do the release these days
<mgz> you're right that there's stuff on trunk that could have done with being released a good while ago
<xnox> mgz: speaking of which. What needs to be done to get access to package-importer? do I need to request access on that/those machines?
<trident_job> mgz: yeah, that's not good advertisement for an open source project to have 1 year release cycle ...
<mgz> xnox: well poked... so, probably an rt unfortunately
<mgz> you just want a user account on jubany with su to the pkg_importer user
<trident_job> I tried to push BZR in my company, but ... that's hard to open their eyes far from SVN !
<mgz> trident_job: sadly, for many, having only a one year cycle is doing well
<trident_job> I fear they will go for git ... just because it's 'famous' ... but what I really love with bzr, it's the simplicity.
<xnox> trident_job: don't fear changes =)
<trident_job> mgz: if users can wait 1 year to see a bug fixed
<trident_job> xnox: fear leads to sanger ... blabla I know :)
<LeoNerd> Whyfore "bzr sw" not a synonym for "bzr switch", in the way many other commands have twoletter aliases?
<jelmer> LeoNerd: update the aliases attribute on cmd_switch in bzrlib/switch.py
<jelmer> patches welcome :)
<LeoNerd> Hrmm... Lot of overhead for me there, can you sumarize? I.e. start from  bzr branch $URL  for some URL, and ending with how I submit said patch.
<xnox> LeoNerd: follow the steps from here https://help.launchpad.net/Code/FindingAndDownloading to futher all the way down to merge proposal.
<xnox> use lp:bzr
<LeoNerd> Cool
<xnox> the changes needed are already summarised by jelper.
<LeoNerd> Yah
<xnox> "update the aliases attribute on cmd_switch in bzrlib/switch.py" you should find similar example on the status command which has "st" alias.
<LeoNerd> Mhm
<vila> LeoNerd: alternatively 'bzr alias sw=switch' will record it in your .bazaar.conf, but that's less fun than a patch ;)
<lifeless> vila_: LeoNerd: also bzr-guess will Just Work ;)
#bzr 2013-02-09
<vila_> lifeless: hehe, indeed, I'm so used to it (tyops ? me ?), that I forget it's a plugin ;)
<lifeless> vila_: if you want to merge into core I'm fine with that :P
#bzr 2013-02-10
<vila_> lifeless: if I had the bandwidth, that would be a no-brainer :-}
<vila_> lifeless: I'm not even sure I can remember an open bug I encountered myself... I mean, in years, without even checking I was up to date...
#bzr 2014-02-04
<Gokul12> 	Hi. I am trying to install Kicad from the kicad-install.sh on my Ubuntu 12.04. Half way through installation, it asked me for bzr launchpad account, I created it, uploaded my public key, added my launchpad id in terminal, If I try to restart installation, it says "bzr: ERROR: No WorkingTree exists for "file:///home/gokulakrishna/kicad_sources kicad.bzr/.bzr/checkout/"
<Gokul12> How do I get the .sh to restart installation now?
<Shoo6> hi. is it intended resp. dodumented that i cant add dirs to a repo which contain .git/.gitignore files?
<Shoo6> i spend hours searching for a mistake in .bzrignore files, argh
<jelmer> Shoo6: do you have bzr-git installed?
<Shoo6> btw if i want to use bzr to keep track/backup of linux config/system files like /etc /boot, what would be the best repo structure?
<Shoo6> nope, 2.6.0*
<Shoo6> i think
<Shoo6> let me recheck
<jelmer> (see the output of 'bzr plugins')
<Shoo6> 2.6.0 on archlinux
<Shoo6> is bzr-git solid enough
<Shoo6> ?
<Shoo6> btw i had some crashed throu unicode errors from @ or \ on filenames too
<jelmer> Shoo6: it's broken, I no longer  maintain it
<Shoo6> what is broken, bzr-git?
<jelmer> Shoo6: if it is installed, it might prevent you from adding .git/.gitignore files
<Shoo6> i didnt add them, they were there before ;)
<Shoo6> regarding my question to usr bzr for system backup. when i want to have deduplication and space efficiency i have to put all host data into on repo separated thoutgh branches right?
<jelmer> I think the same applies as with other data; if you use a shared repo you can avoid storing multiple copies of revisions
<Shoo6> k thx just to make sure
<Shoo6> jelmer: shoudl i go on with 2.7*?
<Shoo6> -dev
<jelmer> Shoo6: 2.6 should be fine
<Shoo6> hhm crossing fingers
<Shoo6> btw it woukd be really nice if i could do python regexp when doing 'bzr add "RE:...'
<Shoo6> the usual ignore syntax really sucks
<jelmer> zyga: how's your bzr3 port going?
<zyga> jelmer: hey
<zyga> jelmer: I had some attempts and got a few things working but I didn't have the time to touch it lately, lots of stuff going on on weekends here
#bzr 2014-02-06
<LeoNerd> would an argument called  bzr update --fail-if-diverged  really be so much to ask for?
<LeoNerd> I keep getting upset that 'bzr up' causes pending merges on divergant history. I _never_ want merges. If the history has diverged I want to rebase it because that implies I Have Messed Up
<mgz> why not just use pull then?
<LeoNerd> Because in 99.999% of cases 'up' is what I want
<LeoNerd> It's only that one-time-in-almost-never case that they have divergant history in the first place
<achiang> hello, what is the incantation to make bzr to branch from LP, but use as many bits from my local repo as possible?
<achiang> i am finding the help for `bzr branch` to be slightly hard to comprehend
<achiang> use case is: large branch in LP, slow network, want to grab something that hasn't been merged yet, and i have a local copy of trunk
<fullermd> There is no invocation, that's just how it works.
<fullermd> Assuming you _have_ a local repo, anyway.
<achiang> fullermd: hm, i should explain more... i do a bzr branch lp:~colleague/project/branch and it is grabbing a lot of data over the network
<achiang> but i also have a ./trunk/ locally on my disk
<achiang> i'm not sure how to grab ~colleague/project/branch without downloading everything...
<achiang> fullermd: should i just `bzr branch ./trunk foo` and then inside foo/ do `bzr pull lp:~colleague/project/branch` ?
<fullermd> Well, that would be one way.  But a better way would just be to make a repo.
<achiang> i'm reading through http://wiki.bazaar.canonical.com/SharedRepositoryTutorial and i don't get how to combine a local repo with remote branches
<mgrandi> if you just create a shared repository
<mgrandi> every branch inside that shared repo will share the commit data
<fullermd> There's no real "combining".  A repo is a purely local construct, all your interaction with remotes remains at the branch level.
<fullermd> So you'd just have both trunk and foo inside a repo locally.
<mgrandi> so if you have two branches that have diverged, say, 12 commits, but the first 10 are the same, then it will store 14 commits, and share the first 10, while storing the unique 4 when they diverged
<achiang> so create a local repo, then bzr branch "remote" and the branch command will try to use as many objects from the local repo as possible, and download the rest from the remote?
<mgrandi> i assume so
<fullermd> Well, you'd need the step of "change local trunk so it uses the repo" to get the objects into it.
<fullermd> But that aside, yes.
<mgrandi> wouldn't just branching into the shared repoistory do that?
<fullermd> I'd presume he'd just make the repo around the current location.
<mgrandi> ah
<mgrandi> you would have to repack it
<fullermd> Wouldn't do anything.
<fullermd> You'd need reconfigure --use-shared (I think that's what it's called; xref docs)
<mgrandi> doesn't it figure out that there is now a shared repo and put the pack in the shared repo rather then the local branch .bzr file?
<fullermd> No, it's perfectly reasonable to have a standalone branch located inside but not using a shared repo.
<mgrandi> interesting
 * achiang studies http://stackoverflow.com/questions/6500282/can-i-take-a-bazaar-branch-and-make-it-my-main-shared-repository
<fullermd> It's not majorly different from having one branch stuck inside another, after all.
<mgrandi> for that stack overflow post, to create a new shared repo with 'only' the objects that the branches you want inside it are using
<mgrandi> just create a shared repo, then branch the ..branches into it and it will get the stuff it needs
<mgrandi> don't bother with copying the .bzr directory as bazaar does the work for you!
 * achiang thinks the 2nd answer looks interesting
<achiang> the one calling bzr reconfigure
<mgrandi> i think thats too much work
<mgrandi> say you have branchA and branchB, you want to put inside a shared repo
<mgrandi> cd shared_repo
<fullermd> branching the branches in would require resetting all the per-branch config (like parent locations).
<fullermd> IT's easier to just do it in place.
<mgrandi> bzr init-repo --no-trees.
<mgrandi> (space before the dot)
<mgrandi> then just bzr branch branchA and bzr branch branchB
<mgrandi> it will branch the old branches that you want to convert, make them used the shared repo automatically and only copy the objects it needs
<fullermd> Much simpler to start from ~/work/whatever/trunk and just do bzr init-repo ~/work/whatever ; bzr reconfig --use-shared ~/work/whatever/trunk
<mgrandi> or that
<mgrandi> depends on how the folder structure is set up, and you arn't creating a repo in some random directory with other stuff in it
<fullermd> Well, you can just mv the branch wholesale to some new place if things are too cluttered already.
<achiang> fullermd: thanks, i just did that: cd trunk ; bzr init-repo ../ ; bzr reconfigure --use-shared
<fullermd> But that's independent of the repo step, and you should do that anyway   ;)
<achiang> then i did cd .. ; bzr branch lp:~colleague/project/branch and it was super-fast
<achiang> so thanks!
<fullermd> Eggselent.
<mgrandi> this reminds me when i was trying to figure out how best to 'archive' a bzr repo, as someone told me the .bzr folder might not be the best thing to transfer across filesystems and whatnot
<mgrandi> the solution i found on SO was to create a new repo and then do a email merge request for the entire branch and have that saved as a file, seems a bit hackish but it works
<jelmer> mgrandi: what would be wrong with the .bzr directory?
<jelmer> the only thing I can think of is that if your backup actually does go bad that it's easier to recover from an email merge request by hand
<mgrandi> i dunno, someone mentioned that it 'could' be not the most portable thing if you are creating a branch on windows, copy to linux or mac or whatever
<fullermd> Grabbing a .bzr of just a branch might miss all the repo stuff if it's using one, grabbing the .bzr of a repo won't get any of the branches in it...
<mgrandi> on the website, it says the best 'backup' of a bzr repo is to use bzr itself, but that doesn't really lend itself to like, saving it as an archive or something
<jelmer> mgrandi: what fullermd says, you have to make sure you backup all the relevant .bzr directories
<jelmer> mgrandi: but there are no portability issues
<mgrandi> only one i can think of is if there is any OS specific stuff to a checkout, like symlinks maybe?
<fullermd> The simplest way to back up a _repo_ would be to just tar the whole thing up.  For a _branch_, just 'branch' it somewhere temporary and tar that up.
<jelmer> mgrandi: there are no symlinks under .bzr/
<mgrandi> yeah, but the checkout of the branch could have them or something
<mgrandi> but you are probably right that the .bzr format is fine to just tar up and save somewhere
<jelmer> mgrandi: you're not including those, that's why you're backing up just .bzr/
<mgrandi> ah
<mgrandi> http://stackoverflow.com/questions/1976857/bzr-create-tgz-file-containing-full-repository is what i was referring to
<fullermd> The alternate answer is "use git-bzr or something to turn it into a git repo, then create a new email account, use git-send-email to dump an endless stream of patches into it, then just carry the mbox around"  ;)
#bzr 2014-02-07
<mgrandi> well bzr has
<mgrandi> bzr send which is what the 'hack' in the above link uses
<mgrandi> so its just one attachment =P
<mgrandi> also, has anyone ever updated the windows build of bazaar?
<mgrandi> if the person who usually does it isn't around, i could possibly do it if i had a guide
<jelmer> mgrandi: I'm not sure who was the last person to update the build, but I know there was a guide around at some point..
<mgrandi> I have access to visual studio so if i could just get a rough guide i could probably produce one
<mgrandi> ...given enough time, building anything on windows is a pain >.>
<fullermd> I recall there being trickiness due to having to match compilers with the one python uses, or something like that.
<mgrandi> yep
<fullermd> I dunno.  Windows is a black box.  That I bury in the back yard.
<mgrandi> Which is why i can't wait for clang to come to windows, then that problem wouldn't really matter
<fullermd> Not MY back yard, of course.  I don't want that kinda crap on my land.
<fullermd> Ideally in a different state...
#bzr 2014-02-08
<TJ-> How do I tell bzr-builddeb -S *not* to try to sign the package? I've tried ~/.bazaar/builddeb.conf "source-builder= dpkg-buildpackage -rfakeroot -S -us -uc" but that is ignored; the build shows it using  "dpkg-source -b c $PACKAGE"
<TJ-> typo, that should read "dpkg-source -b $PACKAGE"
#bzr 2016-02-08
<ngaio> I've currently a bunch of python scripts for a project in a directory (with a few minor subdirectories). They're in bzr and up on launchpad, so all is good. Now I want to add a top level directory above it, with setup.py and other such necessary files for a proper project. Regarding bzr and keeping good history, is the best thing to treat the current directory as the new root directory, create a subdirectory (e.g. myyproject), and bzr mv all current files and
<ngaio> folders into the new subdirectory?
<fullermd> Conceptually, it may be best to pivot a new root into place.
<fullermd> But since there's no command to do that...
<ngaio> actually I have no idea how to do that, so moving all existing files is the best I can up with
<fullermd> Well, there really isn't one.  Hence...   :)
#bzr 2017-02-07
<ManuelSantana> Hi guys
<ManuelSantana> Can I use launchpad for private projects?
#bzr 2017-02-10
<throstur> how do I make my bzr commit also push to a remote url, instead of just committing locally?
<LeoNerd> throstur: bzr bind
#bzr 2018-02-06
<jelmer> Walex: It depends a lot on the context; e.g. if you have the libreoffice, linux or firefox repositories.. there are also a lot of files
#bzr 2018-02-08
<LeoNerd> It seems to be nontrivial to actually delete tags
<LeoNerd> I can  bzr tag --delete  and that indeed removes it from my local branch, and the bound one
<LeoNerd> But if there's other bound branches, they seem to put them all back next push
<LeoNerd> And then next update, I get them back locally too
<LeoNerd> I think I have to delete them from every branch and checkout simultaneously and ensure nobody pushes in the meantime
<fullermd> Prexactly.
<LeoNerd> One of those annoying stop-the-world changes
<fullermd> Eh, the whole 'world moving' thing is a bug anyway   ;)
<LeoNerd> A lot of concurrency bugs go away if you have a big STW button
<fullermd> Ask any Renaissance pope, they'll tell you "yet it moves" is heresy.
#bzr 2020-02-03
<CcxWrk> bzr shell was too fiddly last time I tried to use it. Mercurial actually has fully functional background program for this.
<CcxWrk> Or rather, bzr shell really really isn't designed for non-interactive/scripting use.
<CcxWrk> https://www.mercurial-scm.org/wiki/CommandServer
<CcxWrk> FWIW on POSIX platforms you can just send CWD and stdio file descriptors over unix socket, so it can work pretty seamlessly. I wish there was a generic Python module for that, as the start up time for a lot of software is really bad.
<LeoNerd> Yah; it's a common thought. It's basically just "do FastCGI"
<LeoNerd> The "Fast" part of FastCGI is really just a UNIX process server system, it has verylittle to do with CGI or webserving or anything else
<LeoNerd> Connect to a socket, send initial environment, stream stdin in, stream stdout / stderr back out, accept exit code at the end
<CcxWrk> It's a hack ultimately. Workaround for slow startup time. But there is only so much you can do with Python to speed it up.
<LeoNerd> It's a nice idea regardless of the language though. It means programs can open database connections, precache things,.. whatever they need..
<CcxWrk> Idea is nice, how many edge cases you will run into depends on how you use it. But with shoveling all of env/cwd/stdio into it the rest is pretty much inherent issues of preloading libraries.
<CcxWrk> And signals, which also need special handling. Oh well, operating systems are messy. :-]
<jelmer> CcxWck: are you sure you're talking about 'bzr shell' and not 'bzr service'?
<jelmer> The latter is a background service
<jelmer> The former is just a way of not paying for cache load/import time repeatedly
#bzr 2020-02-04
<CcxWrk> jelmer: I don't know about "bzr service", my install doesn't have it, but "bzr server" is yet another thing. The client to that needs to understand bzr too much, can't be just simple shell or C wrapper executing commands.
#bzr 2020-02-06
<fullermd_> brz: ERROR: unknown command "br". Perhaps you meant "rm"
<fullermd_> Preeeeety sure I didn't...
<Peng_> Maybe it's angry and thinks every commands hould be "rm"
#bzr 2020-02-07
<fullermd_> Maybe it's an easter egg in python, and it noticed I was working on perl code.
