#bzr 2008-02-11
<lifeless> abentley: ok, bit of a missive, but its on its way
<abentley> lifeless: At first blush, it looks like violent agreement.
<abentley> I've just skimmed so far.
<lifeless> abentley: I had the sense from you that other things than bytes would be on your 'storage' object, but if not then it was just mutual confusion I think
<abentley> Well, graph data also, I guess.
<lifeless> thats something I explicitly rejecting at this point
<lifeless> I don't know if I'm right too
<abentley> Well, the build graph seems like it must be there.
<lifeless> abentley: thats under the wraps
<lifeless> rephrasing, you don't need to expose the fact compression has happened at all outside the byte store
<abentley> Okay, I guess we're in disagreement, then.
<lifeless> thats good; it means there's more to explore :)
<abentley> There are several things we can't implement without that.
<lifeless> I'm going to go for a walk and get lunch and think about those things, if you could list them now :)
<abentley> One of them is Goffedo's inventory hack.
<abentley> Another is fetching via the stream thing that Andrew and you added.
<lifeless> it doesn't depend on exposing deltas in the api
<lifeless> it depends on exposing 'the set of lines from all these texts'
<abentley> Another is iter_changes based on a semantic inventory delta.
<abentley> That's all I can think of at the moment.
<lifeless> I can't parse that last one.
<abentley> You know your journalled inventory stuff?
<lifeless> oh right, well that doesn't do deltas within the byte store, its a form of fulltext always
<lifeless> its a layer up
<abentley> Is that the right layer?
<lifeless> but the stream-fetching one I will cogitate on, I think I didn't /quite/ have my ducks in a row
<abentley> If it's a layer up, does that mean we can't get a comprehensive inventory directly from the multi-versionedfile?
<abentley> lifeless: Oh, sorry plenty more.
<lifeless> I don't think inventory should be in a versioned file abstraction at all eventually. We will want an index for the inventory tree, and then read the lot.
<abentley> Anything that tries to accelerate test comparisons using knit deltas.
<lifeless> 'test comparisons' ?
<abentley> s/test/text
<abentley> Currently, annotate and send use that.
<lifeless> how does that work?
<abentley> We derive the SequenceMatcher.get_matching_blocks output from the knit delta and a pair of fulltexts.
<abentley> The fulltexts are used to fix up the eol bogosities.
<lifeless> sounds like what you want is 'byte_store.get_matching_blocks(from_key, to_key)' ?
<lifeless> lets not detail it now
<lifeless> lets just keep thinking of issues
<abentley> lifeless: At least some of the time, you want the fulltexts as well as the matching_blocks.
<abentley> I think the new "knit merge" also uses that information.
<abentley> ie the matching_blocks.
<lifeless> abentley: to come back - sure; we can handle that variation I think
<abentley> Yeah.
<lifeless> -> to think. (inventory hack, journalled_inv, stream_fetch, get_matching_blocks)
<abentley> So I think the use cases for raw compression artifacts are 1. transmission between repos, 2. use of partial data, 3. acceleration of comparisons.
<poolie> lifeless, good point about acting as an ssh agent
<lifeless> poolie: thanks ;)
<poolie> so
<poolie> really this is a broader reason not to use builtin ssh, more than anything else
<lifeless> Yes
<lifeless> if you want ssh credential caching, use an ssh agent, kthxbye. IMNSHO
<poolie> lifeless, quick call?
<lifeless> sure
<cr3_> is there any plans to have a dapper .deb on the ppa?
<Solarion> is there a way to import the revision history of an RCS directory?
<lifeless> sure
<lifeless> cvs init a repo
<lifeless> copy the RCS files into a subdir there
<lifeless> use cvsps-import
<abentley> lifeless: The other reason I wanted access to raw records was repository stacking.
<lifeless> abentley: that would interact badly with different delta formats cross-repo
<abentley> lifeless: that depends how stupid we are.
<lifeless> lol
<abentley> I had the impression that we were going to explore the possibility of multiple delta formats per repository anyhow.
<lifeless> I think that for stacking we basically do iter_file_texts on the repos we're stacked *against*, for every component we can't create ourselves
<lifeless> annotation is the other thing not really covered
<abentley> Producing unnecessary fulltexts takes CPU time.
<abentley> So if we can treat the foreign repo raw entries the same as local ones, that can aid performance.
<abentley> John discovered that we were wasting time inserting lines in the middle of lists building fulltexts from knits.
<abentley> That's why MPDiff can generate a fulltext from the top down without generating intermediate fulltexts.
<lifeless> I think this is an undesirable abstraction violation in the general case.; the cost of getting data from a remote repo in the first place dwarves local cpu cost
<lifeless> secondly, the number of stacked components is going to be small - I don't imagine many getting more than 3-4 steps
<abentley> Which is the abstraction being violated?  delta compression?
<lifeless> and that will mean we 3-4 points where we enforce a full text basis
<abentley> I think that we have enough use cases for compression deltas that it's reasonable to question whether that abstraction is a helpful one.
<lifeless> I'm refining it now, the great thing about strawmen is they get comments
<lifeless> I really want something that can be consistent across repositories sensibly, and I don't think something exposing deltas itself can; not the way we handle deltas today
<abentley> lifeless: I think just tagging deltas with their format goes a long way.
<igc> lifeless: re hg-import, the guts of install_revision in there does diff from the same in repository.py ...
<igc> is that the per-file graph issue ?
<lifeless> you're a little opaque in that sentence
<igc> in repository.py, that bit of code has a "FIXME: TODO:" from yourself and abentley fwiw
<igc> sorry, I'll try again ...
<lifeless> I haven't looked at hg-import in great detail; but as I know of no reason to have different to bzr-hg, I'm suspicious from the get-go
 * igc looks up line numbers
<igc> lifeless: in repository.py, the for loop beginning with a comment on line 1973 is the bit of interest
<igc> in the hg-import plugin, that routine is largely repeated but that inner loop is different - perhaps a copy of some older code at a quick guess
<lifeless> meh
<lifeless> so why does hg-import exist?
<lifeless> what does it do differently to 'bzr pull' with bzr-hg installed ?
<igc> http://rafb.net/p/drJQkk16.html is the code btw
<igc> hg-import exists because bzr-hg doesn't work ...
<igc> and Lukas found it easier to write it that fix bzr-hg
<igc> s/that/than/
<lifeless> its definately buggy
<abentley> LukÃ¡Å¡ also thinks that bzr-hg does its topo sorting wrong.
<lifeless> If I was spending time on this I would be updating bzr-hg, because its more generally useful, and can have the bzr repository conformance tests run against it
<lifeless> which if taken to completion would give -real- confidence in it
<igc> lifeless: my actual focus right now is the git->bzr converter. I'd like to see hg-import merged into bzr-hg and whatever issues bzr-hg has fixed. I'm ok to do that once other stuff is off my plate
<igc> I'm raising this now simple because ...
<igc> users are using hg-import in the absence of a working bzr-hg so if it's broken ...
<lifeless> meh, I hope its got a different namespace
<lifeless> if it doesn't I'll be seriously miffed
<igc> then we ought to be sure key people like you know about it
<lifeless> its an incompatible converter
<igc> the namespace prefixes as hg: (bzr-hg) vs hg- (bzr-hgimport)
<lifeless> good
<igc> s/as/are/
<jamesh> lifeless: by the way, you can replace the code in http://www.advogato.org/person/robertc/diary/78.html with "python -mtrace -t program.py"
<johnny> mwhudson, what is the current state of the loggerhead_dev branch?
<abentley> igc: You mean hg-import doesn't use a colon in its prefix?
<jml> is there an API in Bazaar to make all non-existing directories above a directory?
<spiv> jml: there's a "_create_prefix" function in bzrlib.builtins
<spiv> jml: not exactly a public API, but you could crib from it I guess.
<jml> spiv: thanks
<mwhudson> johnny: it works better than anything else
<mwhudson> johnny: i have a few plans for further improvements but they're a ways off realistically
<johnny> just wondering why there wasn't a newer release on the loggerhead page
<mwhudson> ah, yes, i should make a release
<mwhudson> i'm lazy when it comes to releases :)
<johnny> i noticed that you were still messing with it recently via the launchpad page
<johnny> also, the demo of loggerhead seems not to work
<johnny> it kinda hangs
<johnny> same for bzr-webserve too strangely enough
<johnny> proxy error i think
<lifeless> jamesh: thanks. (Groan at wheel invention)
<lifeless> jml: I would use _create_prefix directly.
<lifeless> jml: not public just means 'wont get deprecated'
<lifeless> :)
<jml> lifeless: yeah, that's what I'm doing
<lifeless> jamesh: when was the trace module added ?
<jamesh> lifeless: not sure.  It has been around for a while though
<jamesh> lifeless: http://svn.python.org/view/python/trunk/Lib/trace.py <- it has been in the standard library since 2003, and was in Tools/scripts before that
<lifeless> rotfl
<lifeless> thanks
<bob2> -mtrace has worked since 2.4
<spiv> Yeah, the "-m" was new in 2.4 IIRC.
<igc> abentley: hg-import's bzr_revision_id(node) does this: return 'hg-' + mercurial.hg.hex(node)
<jamesh> the module was in 2.3 too, but you couldn't use the "python -m" syntax, yes
<abentley> igc: Well, I can't say I'm surprised.
<lifeless> igc: (thats not namespaced in our terms, so they could conceptually collide more easily)
<abentley> But that is an entirely legal revision-id for bzr itself to generate.
<lifeless> I'm glad he didn't use hg: though, because colliding with bzr-hg would have been hilarious
<abentley> lifeless: It used to.  I asked him to change it.
<lifeless> abentley: thank you!
<abentley> np
<igc> abentley, lifeless: so what is the convention here?
<igc> bzr-git is using git-experiemental-r:
<igc> as the prefix
<lifeless> igc: if you are generating random ids, use bzr to create them
<spiv> I think ideally the prefix ought to be (or at least include) the name of the plugin, so you know who to blame ;)
<igc> as an experiment, I changed that to git-r: in one of my test runs and it saved a fair amount of space
<lifeless> igc: if they are deterministic, namespace them with CONVERTER:, and change CONVERTER whenever the algorithm changes
<abentley> Revision ids that include a ':' will never be generated by bazaar-- the ':' is a namespace separator.
<abentley> Revision ids ending with ':' are reserved.
<igc> thanks
<jamesh> igc: so doing the same import twice produces the same results? (same file IDs, revision testaments, etc?)
<igc> jamesh, yes, that's the point to determinstic ids as I understand it
<jamesh> what do you use as file IDs?
<jamesh> (out of interest)
<igc> the different converters all do something slightly different it seems
<jamesh> yep.  It depends on what sort of file identity rules the source VCS has
<igc> jamesh: the git does this: file_id.replace('_', '__').replace(' ', '_s')
<igc> which looks a little suspect to me
<jamesh> where file_id is what?
<igc> (path.encode('utf-8')
<lifeless> igc: thats ok, brittle, but ok.
<igc> ah good
<igc> I was concerned about any existing sequences of _s
<igc> that couldn't be mapped back the other way uniquely IIUIC
<lifeless> git is a rename-free system
<jamesh> igc: "_s" would get encoded to "__s"
<lifeless> so paths are fine but project specific
<lifeless> things like svn and hg that support some form of rename are much more complex
<lifeless> you need to find the tail of the per-file graph
<lifeless> and assign a unique id (using the path of the name at that point is reasonable)
<igc> ah - ok
<spiv> igc: that escaping scheme is unambiguous, although it'd be easy for the unescaping to be buggy...
<lifeless> spiv: what unescaping :)
<igc> :-)
<spiv> Ah, good point.  Problem solved, then ;)
<jamesh> spiv: right.  Doing it in two passes (like the escaping is done) would be buggy.
<lifeless> other fugly thing is paths are long
<jamesh> that was a problem for bzr-svn in the past, right?
<lifeless> I'd probably use the revision-id at time of file creation + a serial within the tree for number of files added in that revision numbering via alpha-sort, or something like that
<jamesh> git does have some idea of tracing a file's history over renames, so simply using the path as a file ID will give a different view of history
<lifeless> jamesh: pickaxe you mean? Thats always derived
<lifeless> (its history mining. lolz. hahaha)
<igc> lifeless: so IIUIC, a repo converted from other tool may well have a different (usually bigger?) size than a vanilla bzr repo and might also perform differently
<igc> I wonder how different on a large repo like the OOo one
<igc> s/other/another/
<jamesh> lifeless: I was thinking of "git-log -M"
<jamesh> I don't know if that's the same thing as pickaxe
<lifeless> igc: if you use something like tailor, no. Because its non-deterministic and equivalent to serially doing bzr commits
<lifeless> jamesh: looks like - note the 'detect renames'.
<lifeless> igc: if you use something designed primarily as a foreign repository interface, then yes, because we're thunking across to the native metadata.
<igc> makes sense to me
<lifeless> abentley: updated proposal sent
<abentley> Cool.  Good night.
<ubotu> New bug: #190832 in bzr-svn "PROPFIND exception during check out of Subversion branch behind https" [Undecided,New] https://launchpad.net/bugs/190832
<ubotu> New bug: #190843 in bzr-svn "Attempting a lightweight checkout raises KeyError exception" [Undecided,New] https://launchpad.net/bugs/190843
<appcine> What am I doing wrong here?
<appcine> My previous workflow was (using svn): client: commit, server: update -- restart web server. done.
<appcine> My new workflow: client: bzr commit, bzr push .. server: bzr merge, bzr commit -- restart web server. done.
<appcine> If i do not run the bzr commit on server, it complains the next time i merge about having uncommited changes
<appcine> Am I doing something wrong, or is this my new life? :)
<luks> appcine: you can do exactly the same as with svn
<luks> that is, server: update
<luks> that is, if you push directly to the published branch on the server
<luks> othewise you want pull instead of merge and commit
<garyvdm> Or - client: bzr commit , server: bzr pull
<garyvdm> luks - you beat me :-)
<luks> :)
<appcine> hmm
<appcine> so I get this: bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<luks> because you did commit
<appcine> then I merge, but can't because I have uncommitted changes.
<luks> so the branches don't match anymore
<appcine> So I commit, then merge again
<appcine> Hehe. I guess this wasn't made to be used like this :)
<luks> nope
<luks> merge is for merging branches :)
<garyvdm> or server: bzr pull --overwrite
<luks> but be sure you have no local changes with that
<appcine> Perfect.
<appcine> :)
<appcine> I'm not changing anything on server .. It's my way of updating the server source
<luks> right, so you want pull
<garyvdm> --overwrite will only be necessary this first time. From now on, just bzr pull
<fullermd> Or push into it and update.
<appcine> garyvdm: Yeah, testing it now. Neat! :)
<appcine> fullermd: I couldn't get bzr+ssh working on the server .. besides, I want three repositories.. one backup, one working copy and one live version on server
<appcine> working copy = development copy
<fullermd> Well, but if the live running version is always just a duplicate of one of the others, is there really a need for it to have a separate copy?
<fullermd> (which isn't intended as a rhetorical "Why, of course there isn't", but it's not obvious that there is)
<appcine> fullermd: Well, I want all my code in one place. I'm running several projects.
<appcine> fullermd: If I'm not on my computer and the server for project #1 screws up, I can still access the code
<appcine> fullermd: And I can burn it to dvd from just one location
<appcine> Gives me some kind of freedom. I always know where all my code is. If that server gets borked, I re-push from my personal computers or the servers where I've distributed the code.
<appcine> And it's the perfect test-server .. if I need to test something on a machine that's accessible from outside of our office lan, I can just launch a project from the intermediary server :)
<appcine> So. What I've done now is translate my svn work flow into bzr. Removed the need for a cumbersome process of adding a new project on the svn server, I am more agile. Given myself the ability to commit locally (something I rarely do though). bzr ignore is soo much easier than anything that svn has :) I haven't tested branching yet, but I hear that's a lot easier as well.
<appcine> What else should I be considering? :D
<johnny> hmm fun.. trying to get loggerhead running under lighttpd
<weigon__> johnny: works as planned ?
<johnny> not yet
<johnny> sadly
<igc> jelmer: ping
<jelmer> igc: pong
<johnny> getting  cherrypy.msg: : Page handler: "The path '/loggerhead' was not found."
<igc> jelmer: how well does svn-import scale?
<johnny> i could be wrong on how to set it up on the lighttpd side
<igc> I'm about to try the OOo repo ...
<jelmer> igc: As well as the rest of bzr-svn
<jelmer> igc: Ah..
<igc> it's 76K files, 506K revisions!
<jelmer> igc: I'm not sure :-)
<weigon> johnny: let's walk through it in #lighttpd
<igc> the svn dump file is ~ 85G
<jelmer> whoa
<igc> so I'm wondering whether ...
<jelmer> igc: A few things that may help are:
<igc> to load the dump file or ...
<igc> run directly on the dump file if I can
<jelmer> igc: Load the dumpfile into a Svn repository first (otherwise bzr-svn will ahve to do it for you)
<igc> ok
<jelmer> igc: Use python-subversion with the memory leak patch (should already be in Ubuntu Hardy)
<igc> is the one in gutsy good enough?
<igc> I had a quick go at building subverison 1.5 but the toolchain dependencies seem long
<jelmer> igc: No, the gutsy one doesn't have it yet
<rolly> Any place I can see loggerhead in action?
<igc> I got as far as autoconf, swig and a few others
<jelmer> igc: You should be able to rebuild the hardy one on gutsy easily
<igc> as in just the python-subverison bit or all of subversion?
<igc> rolly: launchpad uses loggerhead
<igc> so go to any lp branch and click on 'browse code'
<rolly> ah thanks :p
<jelmer> igc: All of subversion
<jelmer> igc: How much experience do you have with building Debian packages?
<igc> jelmer: I'll give it another go. Very little experience building debian packages but ...
<igc> there's no time like now to learn :-)
<fullermd> All the patches and such will be in 1.5.0, right?
<jelmer> igc: when you download the .orig.tar.gz and the .diff and apply the diff, it should be a matter of running 'debuild' in the resulting directory
<jelmer> fullermd: yep
<fullermd> Oh, good.  All these problems should be in the past in only 18 months or so then   ;)
<dato> igc: to apply the diff, just download the .dsc as well, and do `dpkg-source -x $foo.dsc`
<igc> jelmer: so I should build subversion trunk before bothering to load the dump file right?
<igc> is subverison 1.4 compatible with 1.5 w.r.t repos or does it want a dump-load cycle?
<jelmer> fullermd: Well, the 1.5 release is only 3 months away. Always has been.
<jelmer> When I started on bzr-svn it was 3 months away and it still is now :-)
<jelmer> igc: 1.4 should work fine as well for loading the repository
<igc> jelmer: it's a shame we don't have a ppa for subversion 1.5 given we require it
<jelmer> igc: 1.5 isn't required per se
<jelmer> Ubuntu Feisty, Gutsy and Hardy have 1.4 with the required patches backported
<jelmer> However, only Hardy has a memory leak fix for python-subversion which you will really want given the size of your repository
<igc> ah
<fullermd> Ah, just think of it as a good excuse to buy more RAM.  A lot more RAM.
 * igc wonders whether he should upgrade to hardy tonight
<jelmer> fullermd: right, somewhere in the range of, uhm, 250 to 500 Gb...
<jelmer> :-)
<fullermd> Well, see?  After the import's done, he can even install Vista!
<igc> :-)
<igc> jelmer: do you have any rough metrics w.r.t. import speed, e.g. revisions per minute?
<jelmer> it should be delta-dependent
<igc> bzr-git takes around 18 secs per revision btw
<jelmer> wow
<igc> it appears to be limited on the bzr import side, not the git read side
<igc> that's for the OOo repo -with 76K files ...
<igc> it's much faster on smaller code bases
<jelmer> the same is probably true for bzr-svn
<igc> the trouble is, at 3 revs per minute, OOo will take 3 months to import
<jelmer> whoops
<jelmer> Samba has ~3000 files and ~25000 revisions and takes only a couple of hours to import
<igc> cool
<igc> it will be interesting to see how my import compares
<fullermd> Well, those above stats are about 13dB over on files and revs.  That adds up a tad...
<igc> yes, 76K is 25X higher than 3K; 506K revs is 20X more than 25K
<igc> so 400 times "a couple of hours" ought to cover it :-)
<igc> assuming everything scales linearly, of course
<fullermd> So the real question is, which will finish first; converting the history, or compiling the program   ;)
<igc> sounds like a close race :-)
<jelmer> igc: is this all in one branch?
<igc> jlemer: I believe the branch count is 500
<igc> see http://wiki.services.openoffice.org/mwiki/index.php?title=SCM_Migration#Clean_up
<igc> the git repo has a 2.4G pack file
<igc> which I thought was large until I bunzip'ed the 85G svn dump file :-)
<igc> jelmer: ^^^
<jelmer> igc: In that case, you should be able to run several processes in parallel, one for each branch
<igc> jelmer: I don't think so? I meant branches as in 'branches of the one code base', not branches as in separate modules
<jelmer> ah
<igc> I think getting the revisions in is the bottleneck
<igc> jelmer: it looks like they've been bitten by having too many modules and so the want to explicitly go to a monolithic repo
<igc> that's repo as in 'bzr branch'
<appcine> ok, so I've pushed my code using sftp to the server. On the server, should I run "bzr update ." in the directory containing the .bzr directory?
<jelmer> igc: Ahh
<jelmer> igc: I wonder how much time the initial step of bzr-svn is going to take
<jelmer> igc: (analysing the repository history)
<igc> jelmer: when I tried with bzr-git, I used your branch btw which ...
<igc> was based on ddaa's which was based on ...
<igc> jam's, etc.
<jelmer> true distributed development :-)
<igc> it created a git-cache directory which was 100G today :-)
<jelmer> how did the bzr-git run go?
<igc> it got to 12K revisions converted when I killed it earlier today
<igc> it had been running since Friday night
<jelmer> ah
<igc> 4K revisions/day is around the 18 secs per rev I mentioned
<jelmer> I'm convinced bzr-svn should be able to do better
<igc> it looks like the git-cache stuff was copied from bzr-svn
<igc> so I was wondering how big ...
<appcine> If I push my code to a server, I get a .bzr directory on the server. How do I make that .. code? :)
<igc> the similar thing gets with bzr-svn
<dato> appcine: `bzr checkout .` in the server
<jelmer> igc: The framework was, but it caches different things
<igc> it's true that bzr-git is more experiental of course
<appcine> dato: Perfect
<igc> ah - good
<appcine> dato: And the next time I push? still checkout?
<jelmer> igc: The Samba svn cache is only 69 Mb
<dato> appcine: update
<appcine> dato: sweet
<igc> jlemer: that's sounds much better
<igc> s/jlemer/jelmer/ - damn
<igc> that's twice now
<jelmer> :-)
<awilkins> How does bzr-svn get the revision data? By asking for the file from each revision?
<jelmer> awilkins: It retrieves the delta for the revision
<awilkins> e.g. is it doing the equivalent of svn log ; foreach(changedfile in revisionLog) { svn cat file@revision } ; bzr commit ?
<jelmer> no
<awilkins> That's good :-)
<jelmer> it's equivalent to "svn update -r$(R-1):$(R)
<jelmer> for each revision
<awilkins> Where's the bottleneck?
<jelmer> in bzr writing the revisions and in bzr-svn processing of the revisions
<jelmer> awilkins: is speed being an issue?
<awilkins> It's slow enough to put me off using it more, if that's enough to fret about :-)
<awilkins> But you can say the same about SVK, which theoretically should be a lot faster (since it uses SVN at the back)
<awilkins> Want a bzr-svn test log for revision 926?
<awilkins> (win32)
<jelmer> awilkins: Don't use the 0.4 branch if you want performance, use 0.4.7
<awilkins> Are you saying that r877 performs better than r 926?
<jelmer> yes, there is refactoring going on in the 0.4 branch, that has degraded performance temporarly
<awilkins> I think my assesment was probably on 0.47, but I tell you what, I'll wind back and see how it cope with our big, nasty repository
<awilkins> Lots of binary Visio files, etc
<awilkins> And some multi-megabyte access databases :-)
<awilkins> To be honest, the performance on our SVN server has sucked hugely since they virtualised it ; I have this theory that they have the storage on a SAN somewhere and SVN doesn't like it.
<jelmer> what is the size of the repository (num revisions, num files)?
<awilkins> Hang on, I'll get some stats for you.
<awilkins> 13k revisions, 39,344 files comprising 699 MB at HEAD, and 1.5GB of revision data in the repository
<jelmer> I think bzr itself would be the main bottleneck there
<jelmer> given the size of the tree
<awilkins> It's actually chugging along quite nicely ATM
<awilkins> Doing 1 or 2 revisions per second (highly unscientific measurement)
<awilkins> It seems a lot faster than git-svn was (although that's also highly subjective)
<awilkins> I believe the svn cache for this repo runs to about 58MB
<awilkins> Ah, it must be getting to some meatier revisions now :-)
<awilkins> If I put this into a repo-tree and branch all the branches in this SVN repo do they share packs?
<jelmer> awilkins: yes
<awilkins> Do you need to set up the branching scheme for this to happen?
<jelmer> possibly, if it's a repository that doesn't use the usual svn conventions
<awilkins> Oh, it doesn't :-)
<appcine_> Can you do selective branching in bzr? Like, the temlate authors can branch "temlates" and editors branch "templates/static" without any extra setup? :)
<awilkins> Not simply anyway
<awilkins> appcine_: You'd just both take a branch and merge them
<appcine_> awilkins: Aye, I was just curious if I could remove the "overhead" of making them browse my source tree to the specific part where they may update stuff
<awilkins> appcine_: Which OS... if it's a *nix, they can just have a link to the lower folder :-)
<awilkins> Hell, even on win32, they can have a shortcuty
<appcine_> awilkins: OS X, and yeah .. i could create a link :)
<Leonidas> is there a way to merge a treeless branch into another one? I get an error because there are no working trees
<abentley> Leonidas: No, because after you merge, you need to commit.
<Leonidas> hmm, indeed.
<awilkins> jelmer: It dropped dead before it finished :-(
<jelmer> awilkins: How?
<awilkins> bzr: ERROR: bzrlib.errors.KnitCorrupt: Knit <bzrlib.knit._PackAccess object at 0x0176A330> corrupt: While reading {svn-v
<awilkins> 3-trunk0:97052673-6ba5-7c4e-b85a-d09b8cc4c1f0:trunk:779} got MemoryError()
<jelmer> awilkins: Ah, it ran out of memory
<jelmer> awilkins: You should be able to resume it
<jelmer> awilkins: perhaps you're not using a version of python-subversion with the memory leak fixes
<awilkins> That the cd/branch ; bzr init ; bzr pull <url> ?
<awilkins> THe page that I got them from claims to have rolled that fix into them
<jelmer> yeah, you should be able to just run bzr pull again now
<jelmer> are there any big files in the repository?
<awilkins> Yes
<jelmer> how big?
<awilkins> Up to 20-30MB I think
<Leonidas> abentley: it would be cool if it could create lightweight chechouts on the fly and commit afterwards provided there are no conflicts. This is what I do at the moment.
<jelmer> mwhudson: is there any chance loggerhead is going to support being used inside of apache?
<jelmer> awilkins: hmm, that shouldn't be a problem
<awilkins> I'm trying a resume now
<awilkins> It is just cd branch ; bzr init ; bzr pull <url> isn't it?
<jelmer> this time you should only have to run the bzr pull bit
<awilkins> It says "not a branch" AFAIk if you do that
<jelmer> if you're running init again it wouldn't be resuming anything
<awilkins> I didn't run init to start with
<awilkins> I started it with a bzr branch
<jelmer> oh, ok.
<jelmer> In that case it won't be resuming
<awilkins> Bum
<jelmer> unless you're inside a shared repository
 * awilkins issues expletives
<awilkins> Pack-0.92 not compatible with bzr-svn?
<jelmer> awilkins: No, you need rich-root-pack
 * awilkins suggests that should be in the error message
<jelmer> yeah, there's already an open bug about that
<abentley> Leonidas: Autocommits are dangerous.  Just because there are no text conflicts doesn't mean the merge was successful.  We encourage people to have a test suite and run it.
<Leonidas> abentley: I see your point. How about an option like --i-am-absolutely-sure-that-this-will-merge-properly-and-take-all-the-responsibility?
<awilkins> Heavens, my powershell script is running slowly
 * fullermd sighs.
<abentley> Well, I'm not going to write such a thing.
<fullermd> I really with irssi would stop chopping wrapped lines   :(
<fullermd> And sometimes, I even wish...
<jelmer> Leonidas: perhaps a plugin with a command with that behaviour
<jelmer> ?
<Leonidas> jelmer: Would be fine, indeed.
 * Leonidas takes a look on how bzr plugins look like
<awilkins> Ouch, python is eating 550MB now
<awilkins> jelmer: 1.2GB now :-{ 1.3 .... oh, finally, the GC kicks in, still 955 MB though.....
<awilkins> You can just branch something into a repository tree to convert it from standalone to repo-tree, yes?
<jelmer> yes
<awilkins> jelmer: For what it's worth, the UI for "bzr branch svn+http://" is much more reassuring than that for bzr pull ; the former tells you how many SVN revisions it's got through, the latter just sits at "Pull phase 0/2" for a looong time.
<awilkins> jelmer: Do you think it might go faster if it supressed repacking as it went, or slower?
<jelmer> awilkins: Not sure
<awilkins> I guess it's not easy to work it out without profiling - do you know any good Python profiler?
<awilkins> THe ultimate goal would be to get the speed network-limited on a typical desktop machine :-)
<awilkins> Although I think it might be disk I/O limited here, it's running between 80-100% CPU utiisation.
 * awilkins finds the profilers in the std python library ans is humbled
<jelmer> there is lsprof support in bzr I think
<awilkins> There's even a pre-prepared output in the wiki :-)
<awilkins> Why am I not surprised to find XML processing eating a lot of time .....
<awilkins> Looks like the most could be gained from improving find_longest_match though (which is probably really hairy-scary)
<abentley> awilkins: The thing is that repacking does reduce seek time, so it really is a tough call.
<awilkins> Oh yes, I would guess at it, but it's not an improvement unless you measure it.
<awilkins> Does the API provide for supressing packs temporarily?
<abentley> awilkins: I'm not sure whether you mean pack creation or repacking, but both are controlled in the API.
<awilkins> It's repacking, I've been watching the folder while bzr-svn pulls - packs vanish, old packs get bigger
<abentley> awilkins: What command are you executing?
<awilkins> pzr pull
<awilkins> Might not be true that old packs are getting bigger
<abentley> Packs should only get bigger when they're being created, before they're renamed into place.
<awilkins> I think it's just my bad interpretation
<awilkins> Old packs are disappearing and being replaced with bigger ones in the same ordinal place in the list
<awilkins> I'm just watching explorer sorted by mod time
<abentley> awilkins: The code that copies revisions from an svn repo to a bazaar one does one revision at a time.  I believe it could do more than one at a time, though it probably wouldn't make sense to do them all at once.
<jelmer> abentley: How could it do more than one? That would just mean keeping more data in memory and waiting with writing it out to disk.
<abentley> As long as you don't close the write group, the data is still written to disk, but the pack isn't finished and renamed into place.
<awilkins> There _are_ a lot of dinky little 2k packs here.
<awilkins> I'm guessing it's ending up with 1 pack-per-revision, until it repacks
<awilkins> Well, it's now pulled nigh on 700MB from an SVN repo of 1.5GB, the rate at which it's increasing has slowed tremendously.
<awilkins> The trunk accounts for 9000 out of 13000 revisions, but I can't tell where it's got to in terms of those 9000
<ubotu> New bug: #191001 in bzr "checkout doesnÂ´t work" [Undecided,New] https://launchpad.net/bugs/191001
<sistpoty|work> hi, how can I remove a stale lock? (it says s.th. like "Unable to obtain lock file:///srv/revu.repo/.bzr/repository/lock")
<dato> sistpoty|work: bzr break-lock
<sistpoty|work> ah, thanks
<mwhudson> jelmer: um, it does?
<jelmer> mwhudson: what did I say exactly?
<mwhudson> <jelmer> mwhudson: is there any chance loggerhead is going to support being used inside of apache?
<jelmer> mwhudson: Ah
<jelmer> mwhudson: That should be "easily" be supported
<mwhudson> jelmer: what about it is not 'easy'?
<mwhudson> jelmer: you set up mod_proxy/mod_rewrite and set server.webpath in the conf file
<mwhudson> i mean, documentation is lacking, but other than that?
<jelmer> You have to run an extra daemon
<mwhudson> so you'd rather a cgi like setup?
<jelmer> yeah
<jelmer> bitlbee is using hgweb atm and we were considering migrating, but it's just too much trouble atm
<jelmer> that, and the dependencies (but I think that's been brought up before)
<mwhudson> loggerhead currently caches way too much at branch object creation time for that to really work
<mwhudson> though i guess for small projects it could work
<mwhudson> abentley and i were talking about making loggerhead (or something a bit like it) into a more of a library for generating html describing a branch
<mwhudson> and decoupling it more from the publishing side
<jelmer> BitlBee is probably too big for that
<jelmer> we're currently looking into alternatives for what we're using atm (hgweb and trac with trac-bzr)
<jelmer> the size of our revision history tends to bring trac down occasionally
<mwhudson> oomph :)
<mwhudson> how many revisions?
<jelmer> ABOUT 1.1K, SO NOT TOO MANY
<jelmer> sorry for shouting
<jelmer> so not too many
<jelmer> mwhudson: I think that would be a good idea actually, splitting out a library that can generate HTML representations of Bazaar data
<mwhudson> ok, in my testing i've been using launchpad (5k files, 20k revisions) as a "large project"
<jelmer> ah, ok
<jelmer> it's probably tracs fault then, it already feels really slow for BitlBee for simple operations (and runs as a separate daemon so it can do caching)
<mwhudson> jelmer: yeah
<mwhudson> loggerhead.bitlbee: built revision graph cache: 0.021812915802001953 secs
<mwhudson> certainly, loggerhead seems pretty quick on bitlbee
<jelmer> hgweb is pretty quick too, but it's unmaintained and has regressed recently
<jelmer> building the revision cache is the most inefficinet step?
<mwhudson> it depends
<mwhudson> for launchpad, the pain point is extracting inventories
<mwhudson> also, computing the files changed in a revision can be slow
<mwhudson> (but you can cache that)
<jelmer> that depends on the size of the tree I guess?
<mwhudson> yeah
<lifeless> moin
<hsn_> any big projects migrated to BZR after 1.0 rel?
<johnny> mwhudson, is there a reason you don't use wsgi in loggerhead?
<johnny> i've been trying to get loggerhead to work with lighttpd, but the simple proxy method wont' work with 1.4.x
<mwhudson> johnny: i don't know, is there any reason why i *would* use wsgi in loggerehad?
<mwhudson> johnny: but i should point out that this side of loggerhead is very much Not My Fault :)
<johnny> ?
<weigon> johnny: WSGI should be a feature of turbogears, it is one for all
<johnny> atm it seems like your script has to be modified?
<johnny> maybe i'm wrong
<mwhudson> johnny: loggerhead runs happily enough behind a proxy
<mwhudson> you need to set server.webpath in the config
<johnny> i did
<johnny> maybe i set it wrong
<weigon> mwhudson: can you tell loggerhead to strip the a path-segment from the URL ?
<johnny> i bet that's possible within turbogears
<jelmer> mod_proxy can IIRC
<johnny> i just don't know how yet :)
<weigon> mwhudson: so if the URL is /foobar/baz/loggerhead/... that you string the first part and loggerhead only sees its part
<mwhudson> johnny: i guess "won't work" isn't a good bug report :)
<mwhudson> weigon: i hear a rumour that this is possible yes
<johnny> hmm.. now that i'm more awake,i'll go look it up
<weigon> johnny: you need that strip-prefix feature and lighttpd+mod_proxy will happily work for you
<johnny> mwhudson, do you happen to know off the top of your head on how to strip it?
<mwhudson> johnny: no
<johnny> hmm.. back to my cvsps import, what is the proper procedure to get the head branch of a module out of the repository and use that as the base for another shared repository?
<johnny> just branch it directly?
<bob2> a
<lifeless> b
<bob2> oops
<abentley> Yeah, that "a" revision was a bit of a goof :-)
<reggie> anyone seen bzr-svn give a xxx not a branch error?
<jelmer> reggie: yes
<reggie> I have a svn fsfs repo that appears to convert ok to about 25%
<reggie> and then I get a not a branch error which I don't really understand. I think the folder it shows is a branch
<jelmer> you're running "bzr svn-import" ?
<reggie> yes
<jelmer> that would be bug 183361
<ubotu> Launchpad bug 183361 in bzr-svn "bzr-svn on a branches not working" [Medium,Triaged] https://launchpad.net/bugs/183361
<reggie> so branches don't work at all?
<reggie> we have someone here that got it to work
<reggie> perhaps it's intermittent
<jelmer> it works, but there's a bug if something strange happened in the history of a branch
<jelmer> I haven't quite worked out what causes it to break
<foom> but it works if you set a custom branching scheme correct for your project, i seem to recall
<reggie> I assumed that auto would determine I'm using trunk (which I am)
<jelmer> foom: it will never fail halfway through a svn-import though
<jelmer> reggie: yes, it will. You're just hitting a bug in bzr-svn caused by some oddness in your repository
<reggie> and fighting my own ignorance of bzr.  I've just started using it
<reggie> what does --standalone do and is it the default?  seems like it is trying to convert all branches but I didn't give --standalone
<jelmer> standalone determines whether it should use a bzr shared repository or not
<jelmer> it will by default
<reggie> so, use the svn repo as the parent?
<reggie> which I don't want
<jelmer> no
<jelmer> a bzr shared repository
<reggie> oh ok
<reggie> I understand
<reggie> sorry
<jelmer> reggie: no worries
<reggie> so I'm pretty much left with --prefix or just doing a bzr branch on the branches I care about?
<jelmer> reggie: Any chance you can add a comment to that bug about the issue you're hitting?
<jelmer> in particular, the "svn log" for the revision that's problematic could be useful
<reggie> sure, let me figure out how (and I"m not sure what i would say other than I hit it too)
<reggie> hmm.  don't think it's a revision.
<jelmer> It's the changes in a parituclar revision that are problematic
<jelmer> you can figure out what revision is problematic by running "bzr -Dtransport svn-import ..." and looking at the last few lines in .bzr.log before it crashes
<reggie> be happy to help just have no idea how to determine what revisoin that is based on what bzr is saying
<reggie> ahh thanks
<jelmer> the bit that would be useful then would be the "svn log -v" output for that particular revision (commit message/author, etc shouldn't matter)
<jelmer> reggie: or, if this repository is public, just mention the repository URL
<reggie> hmm.  that reminds me we do have a public repo.  maybe I'l try to convert that one
<reggie> jelmer, .bzr.log shows a svn update and a svn revprop-list -r on 689 and then the crash
<reggie> so is it 689 or 690 that caused it?
<jelmer> 689
<jelmer> the output of "svn log -v -r688:690 <url>" would be useful
<reggie> jelmer, comment attached
<reggie> now I'll try our public repo
<igc> morning
<jelmer> reggie: Thanks!
<reggie> np
<reggie> jelmer, got a sec?
<reggie> I did a bzr svn-import --prefix=trunk on my url and it ran to completion but I don't see any files other than a .bzr folder
<jelmer> reggie: Run "bzr checkout" inside that directory
<reggie> oh.  bzr log shows some info
<reggie> hmm.  I made a shared repo inside a shared repo.  I did  mkdir tmp; cd tmp; bzr init-repo .; bzr svn-import <url> trunk
<reggie> and now I have tmp/trunk/trunk/.bzr
<reggie> jelmer, ok seems to be working.  how are svn tags handled?  as native bzr tags?
<jelmer> no, they're converted into branches at the moment
<jelmer> there's an open bug about it
 * Peng wonders why bzr decided to think the submit branch is ".".
<Peng> At least I happened to notice that before sending an empty patch. :\
<reggie> jelmer, so if I import a few of my branches and then someone fixes the tag bug with bzr-svn, can I then somehow get my svn tag info into my braches (even though I've been using the branches)?
<reggie> can I merge two branches into a tag?
<jelmer> reggie: Yes, once that bug is fixed you will see the svn tags as bzr tags
<jelmer> I'm not sure what you mean by merging two branches into a tag
<reggie> for example with svn I have branches labeled 5.0, 5.1, 5.2 ( for each version) and I would have the same for bzr
<reggie> but there are also tags in those like 5.1.1 and 5.1.2 and 5.1.3.  These should not be branches since I never go back and commit code to them
<reggie> can I convert the 5.1 branch, start using bzr to commit code to it, and then later add the tag info once that bug is fixed?
<reggie> maybe it' sjust easier for me to recreate the tags.  just take  a couple of hours
<reggie> just do bzr tag -r for each tagged revision in svn
<jelmer> I think that's probably the easiest solution
<reggie> yup.
<reggie> thanks for your patience.  I really appreciate it
#bzr 2008-02-12
<lifeless> poolie: re 1.2: the launchpad tests are still broken
<lifeless> poolie: I think this is release critical
<lifeless> poolie: also there are other critical bugs IIRC
<poolie> (back)
<lifeless> poolie: see scrollback
<abentley> lifeless: I profiled a launchpad checkout with my fast-iter-changes code, and index.iter_entries was only 24%.  file.seek was 31.19
<lifeless> abentley: I think lsprof islying
<lifeless> seek shouldn't be doing IO :)
<abentley> Well, no, but it must be doing something...
<abentley> It's being called 14, 308 times.
<bignose> my revspec fu is failing me
<bignose> 'bzr diff --revision "date:2008-01-28..before:date:2008-02-03" fails
<bignose> bzr: ERROR: Invalid revision-id {None} in KnitRepository('file:///home/benf/Projects/.bzr/repository/')
<bignose> presumably because it doesn't have any revisions *on* 2008-02-03
<bob2> what a friendly error
<bignose> but I'm specifically asking for all revisions *before* that date, so I don't think it should spit an error
<bignose> $ bzr --version
<bignose> Bazaar (bzr) 1.1.0.candidate.1
<bignose> this is being run from an automated script, that doesn't know what the last date in the branch is.
<bignose> how can I supply a "date:foo..before:date:bar" range without that error?
<lifeless> bignose: strange, perhaps before:date:2008-01-29 ?
<bignose> lifeless: I'm not sure what you're asking. the date range I have is "date foo, through to before (foo + one week)"
<bignose> I have no way of knowing that (foo + one week) is the last date, without a lot of mucking about
<bignose> s/is the last date/is *past* the last date/
<lifeless> bignose: I'm saying that if you don't know of a commit that will match, you should ask for the first commit before the date you want it to match
<bignose> lifeless: that's exactly why the range I gave above is bounded by "..before:date:2008-02-03"
<lifeless> bignose: you're not using before on both sides though are you?
<bignose> no.
<lifeless> which is what I was suggesting
<bignose> but, AFAICT, it's the upper bound that causes it to fail
<bignose> because the range "date:2008-01-28..-1" works fine
<lifeless> oh
<lifeless> in which case, welcome to bugs
<lifeless> please file one :)
<bignose> okay. someone else will need to do that, because Launchpad doesn't let me file bugs without creating an account.
<lifeless> done
<lifeless> neither does bugzilla, or trac, nor nearly any other bugtracker though
<lifeless> so its a bit of a specious argument against using it :)
<bignose> most good ones allow bug submission via email
<lifeless> I just submitted that bug by email
<bignose> by email, without requiring specific registration with the system
<lifeless> I'm only aware of one system that allows that - debbugs
<bignose> anyway: thank you for submitting the report
<lifeless> poolie: did you see my comments on 1.2 ?
<lifeless> bignose: no problem
<bignose> debbugs, roundup, gnats, ...
<lifeless> I would never call gnats a good system.
<lifeless> roundup I haven't used enough to comment on
<ubotu> New bug: #191156 in bzr "bug in revision specs before:date: ?" [Undecided,New] https://launchpad.net/bugs/191156
<abentley> lifeless: What was that memory ceiling you were suggesting for iter_files_bytes?
<lifeless> abentley: 10M or something
<lifeless> on a 100M tree thats 10-20 * latency multiplier, which is tolerable
<lifeless> and on most trees its a tiny fraction
<lifeless> single files > that have to exceed it of course
<abentley> Yes.  Actually with a 100K ceiling, local checkouts of bzr.dev are fast.
<lifeless> I'm thinking network to some degree. but lets say 1MB then
<lifeless> remembering that some exceptional trees (moz) may actually need 10M or something
<Toksyuryel> bignose: bugtrackers are a major spam magnet, requiring accounts help to limit it
<abentley> Sure.  Easily tweaked.
<abentley> lifeless: Need it because of individual file size?  That's covered.
<lifeless> abentley: no, file count
<abentley> I'm not sure whether it would be much faster even with a much larger buffer.
<lifeless> abentley: I'm thinking sftp lightweight branches/ shallow checkouts
<lifeless> abentley: unrelated question, when I have shallow branches working I'm thinking that 'bzr checkout foo' should create a shallow branch
<lifeless> abentley: so the difference between that and --lightweight is whether data accumulates locally or not
<lifeless> abentley: and have an option '--deep' or --full or something, to get the current deep copy
<abentley> That sounds reasonable to me.
<lifeless> cool
<abentley> I think lighweight is too light for a default when dealing with remote branches.
<abentley> But when dealing with remote branches, lots of people would complain if it was too heavy, also.
<lifeless> so I htink a good default is a shallow branch with one copy of each text
<lifeless> for pushing I think an option to say 'cheap', and then a shallow branch with unique deltas only
<i386> lifeless: cant find the fab source code!
<abentley> lifeless: I would consider going 10% higher than one-copy-of-each, just for the improved merging.
<lifeless> i386: https://edge.launchpad.net/fab
<lifeless> abentley: one copy of each will have up to 50 or so texts due to the delta chains
<lifeless> abentley: so on merge we'll often only need to grab the revision data
<reggie> why would I be getting a repo not compatible error on a bzr branch?
<lifeless> (as inventories are delta'd too)
<lifeless> reggie: bzr-svn has been used on one end
<reggie> lifeless, hmm.
<lifeless> abentley: What I mean here, is yes - I've considered that, and think it'll be ok
<lifeless> reggie: the bzr svn faq talks about this
<reggie> ok, let me go look
<abentley> lifeless: Probably.
<reggie> lifeless, not sure that is it. let me show you the error
<abentley> The issue is, what if the "bound" repo is unreachable, and the repo you're merging doesn't have those revisions.
<abentley> s/bound/master/
<reggie> pack-0.92 is the latest repo format?
<reggie> no.  rich-root is latest I guess
<reggie> hmm.  both local and remote repo report as pack-0.92
<abentley> reggie: Not sure what you mean by latest.
<abentley> Current default is pack-0.92.
<abentley> rich-root and rich-root-pack are newer than that.
<reggie> abentley, well I did a svn-import on ubuntu and then did a push from that repo onto a different server
<reggie> so far so good
<reggie> now I'm trying to do a bzr branch from that second repo onto a windows machine and get a repo not compatible
<reggie> the error says something like KnitPackRespository(u'file:///<path>) is not compatible with respository RemoteRepository(bzr+ssh://...)
<abentley> Right.  So you don't really care what's latest, just what's compatible.
<abentley> rich-root-pack ought to be compatible.
<reggie> I pushed from a rich-root to a 0.92. now I'm trying to branch from a 0.92 to a 0.92
<reggie> hmm.  it has to have something to do with svn since I now attempted a branch of a non-svn import between the same repos and it works
<abentley> Well, 0.92 is compatible with 0.92, so I can't see causing the error you're seeing.
<reggie> I think I found the problem.  my repo still have parent set as the svn parent
<abentley> bzr-svn requires a rich-root format.
<abentley> At least the 0.4 series does.  the 0.3 series didn't.
<reggie> can I take a branch that is parented on svn+ssh and break the relatinoship or do Ihave to re-import?
<lifeless> abentley: shallow branches will be unusable offline in the first instance, because they don't consider the non-local data to be ghosts.
<abentley> reggie: The parent is just the default pull location.
<abentley> You can set it to anything with pull --remember.
<abentley> But it really shouldn't matter.
<reggie> oh.  so branches can have their own format?  I thought that was repo wide
<abentley> It is repo wide.  The parent has nothing to do with the format.
<reggie> so is rich-root unstable?
<reggie> should it be avoided currently?
<reggie> got it.
<reggie> abentley & lifeless: thx
<abentley> reggie: rich-root is stable, in the sense that it will not change.
<pooliex> lifeless, abentley, i would say bug 189757 is high, but not critical for 1.2
<ubotu> Launchpad bug 189757 in bzr "Interrupted initial push leads to branch reference" [Critical,New] https://launchpad.net/bugs/189757
<abentley> pooliex: that was my feeling.
<pooliex> ok
<pooliex> do you think it'll be reproducible
<abentley> pooliex: In the sense that I can write a test case for it, sure.  But it will only happen if the interruption happens at the right time.
<pooliex> so you could deterministically reproduce that interruption from a test script, but it's not certain people will hit it
<lifeless> I think folk have on lp
<pooliex> lifeless, would you please make a 1.2 pqm branch for me?
<lifeless> pooliex: done
<pooliex> should i register it?
<lifeless> under ~bzr yes :0
<abentley> pooliex: The necessary ingredient is a .bzr control directory with no branch directory in it.
<lifeless> right, patch away
<lifeless> pooliex: I'm done for the day; any last requests ?
<pooliex> lifeless, so that branch exists but is empty?
<pooliex> lifeless, just wanted to check with you that i'm planning to fix only the launchpad plugin bug, and the dirstate bug, for 1.2rc1
<pooliex> have just sent mail to that effect
<pooliex> can't think of anything else
<lifeless> pooliex: the branch exists and I've pushed bzr's trunk into it
<lifeless> pooliex: I would have to look to find other thins to do :)
<pooliex> yes, i see now
<pooliex> just a lag in lp between mirroring and scanning
<pooliex> have a good night!
<lifeless> just ordred a new dishwasher :)
<i386> lifeless: what was wrong with the old one?
<lifeless> I'm getting a little rusty.
<i386> lifeless: :)
<abentley> lifeless: I'm off to bed, but what would you think of the old-style shallow checkouts (with lots of ghosts) as a default?
<lifeless> abentley: I think its easier to get to checkouts that require you online; so we can and should do that first
<lifeless> abentley: we can look at soft-handling missing-key errors later IMO
<ubotu> New bug: #191203 in bzr "Error at second commit in same dir" [Undecided,New] https://launchpad.net/bugs/191203
<Peng> The "0.12-release-process" blueprint depends on nested trees. Oops? :)
<lifeless> gnight
<Lunkwill> i'm looking at http://bazaar-vcs.org/Specs/Tagging which says this was implemented in 0.15
<dato> yes
<Lunkwill> yet that's the only doc I can find that mentions versioned tags
<dato> tags are not versioned
<Lunkwill> iow, tags aren't implemented according to the spec I just pasted?
<dato> doesn't seem to be the case, indeed
<jamesh> Lunkwill: there is some documentation on tags in the users guide
<Lunkwill> jamesh: yes. basically it says "use bzr tag to tag" and "use bzr tags to list tags"
<Lunkwill> just looking into different DVCSes and some devs I know tried to convince me bzr had versioned tags, but the above mentioned url was the only "doc" they could refer to
<AnMaster> is there a command like git bisect for bzr? that is perform a binary search for what revision introduced a bug in a simple wway
<AnMaster> way*
<AnMaster> if there is nothing like git bisect then is there at least any way to change the working tree to reflect another revision temporarily than HEAD?
<hmeland> AnMaster: See https://launchpad.net/bzr-bisect/ (which I have zero experience with)
<bob2> bzr revert -r XXX
<AnMaster> ah
<reggie> anyone use (or write) svn2bzr?
<reggie> or any subversion import specialists around?
<reggie> anyone know if there is an easy way to adjust the rev-ids on a series of revisions?
<reggie> !seen jelmer
<ubotu> Sorry, I don't know anything about seen jelmer - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<reggie> !tz jelmer
<ubotu> Sorry, I don't know anything about tz jelmer - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<ignas> hi
<ignas> is there a way to perform something analogous to "svn import" using bzr?
<ignas> i would like to get a repository with all the files in some directory without modifying that directory in any way ...
<luks> not sure what exacltly svn import does, but maybe: bzr add && bzr ci -m 'Import of ...'
<ignas> like bzr import /path/to/my/new/repo /path/to/stuff/i/have/readonly/access/to/
<luks> hmm
<ignas> well bzr init + bzr add creates a repository in the original place
<ignas> and i'd like to avoid the "cp -r" part if it's possible
 * luks is a bit confused
<luks> that sounds like a branch, not import
<luks> or is /path/to/stuff/i/have/readonly/access/to/ not a bzr branch?
<ignas> yes it's not
<luks> then I guess bzr init/cp/bzr add/bzr ci is the only way
<ignas> i see
<ignas> thanks
<dato> ignas: bzrtools provides `bzr import`
<dato> ignas: which does what you want
<ignas> dato: bzrtool
<ignas> i mean thanks
<dato> you're welcome
<fullermd> jam: Q for you when you have a minute...
<jam> fullermd: go for it
<fullermd> jam: Just curious as to whether the speedups you're doing on annotate would also speed up weave/knit merges.
<fullermd> Or if they're just local to ann.
<jam> I think there are bits to bothe
<jam> sorry both
<jam> I think Aaron made a case for LCA merge which is very similar to knit merge
<jam> when there are multiple ancestors
<jam> and is otherwise 3-way
<jam> and does a little bit better about not needing to do full annotations.
<jam> as for my changes..... if knit merge is implemented as "give me the full annotation, and then compute the merge" then yes, it would effect it
<jam> so probably it would help, but I wouldn't guarantee anything just yet
 * fullermd nods.
<fullermd> Good 'nuff for me.  Thanks.
<jam> fullermd: do you use knit merge often?
<fullermd> Hardly ever.  I almost never hit something 3way doesn't handle just fine (or at least, when I do, knit doesn't help)
<fullermd> Just something I wondered about skimming the mails about it.
<jam> ultimately, I think we'll need a cache of some sort
<jam> because history gets longer, and any annotation algorithm is generally going to just get solwer
<jam> slower
<jam> I've just been pushing that down the stack, since this code should be cleaned up anyway
<fullermd> Well, better a cache to speed up a fundamentally slow operation, than a cache to speed up a fundamentally slow operation with a pessimized implementation   :)
<sistpoty|work> hi, when I want to commit, bzr tells me that I would already hold a lock (with the pid of the very bzr process, that tries to commit)... any clues?
<beuno> sistpoty|work, you can break the lock with:"  bzr break-lock
<beuno> some process must of hung while pushing/commiting
<sistpoty|work> beuno: nope, then the same error occurs again
<jam> sistpoty|work: it sounds like you are working on a heavy checkout in the same repository
<jam> aka "bzr init-repo repo; cd repo; bzr checkout a b; cd b; commit"
<jam> which sounds like bug #95004
<ubotu> Launchpad bug 95004 in bzr "commit into checkout fails when shared repository used" [High,Confirmed] https://launchpad.net/bugs/95004
<sistpoty|work> jam: hm... might indeed be possible... I'll try s.th.
<jam> sistpoty|work: so one workaround is to use  a"lightweight" checkout, since that actually shares the branch and doesn't try to open the repo 2 times
<jam> I believe you can do "bzr reconfigure --lightweight" in newer versions of bzr
<jam> check "bzr help reconfigure"
<sistpoty|work> jam: actually it was a leightweight checkout...
<jam> I don't know why a lightweight checkout would do that... Are you sure the branch it is a checkout of isn't bound to another branch in the repository?
<sistpoty|work> however there might be s.th. wrong in the first place, since I've got a .bzr directory at /srv/revu.repo and my checkout was lying in /srv/revu.repo/sistpoty (from /srv/revu.repo/production)
<jam> a few "bzr info" calls might help sort things out
<sistpoty|work> jam: hm... so /srv/revu.repo/production is a branch from shared repository: /srv/revu.repo... and I had a leigthweight checkout in /srv/revu.repo/sistpoty from /srv/revu.repo/production, when the error occured
<sistpoty|work> jam: however doing that checkout from a different directory solved the problem, thanks!
<jam> sistpoty|work: I'm glad you got it sorted out. Though I'm guessing you might want to post a bit of a comment on the bug
<jam> just to remind us all that it is still present
<sistpoty|work> jam: will do, once I'm home from work... thanks again!
<jelmer_> reggie: hi
<reggie> jelmer_, hey.
<reggie> was just about to get a bite to eat and then I had another svn-import issue for ya
<jelmer_> reggie: I'll be away in a couple of minutes as well, back at ~8:30 PM (CET)
<reggie> jelmer, bac
<reggie> you have to leave now
<reggie> I think you can answer my svn-import question pretty quick
<synic> abentley: that developer is back online with information about what corrupted that branch
<fbond> Hi, I ran out of memory trying to bzr branch an svn repo... Does svn-import handle this situation better?
<bob2> fbond: upgrading your python subversion bindings might help
<lifeless> moin
<thatch> howdy
<reggie> jelmer, you back?
<jelmer> reggie: hi
<reggie> jelmer, my question is about the revision id mapping
<reggie> I want the bzr tree to be separate.  I won't be pushing or pulling to/from the  svn tree
<reggie> but when my svn branch moves from trunk to branch, then the imported bzr tree uses different revision ids.  so different branches don't merge right
<reggie> maybe I did something wrong?
<jelmer> reggie: how do you mean different revision ids?
<jelmer> reggie: Every revision has its own revision id
<jelmer> which should be unique
<reggie> right.  I use the trunk scheme so I work on trunk until I release a product at which point I branch it.  pretty standard
<reggie> so my product has branches 5.0, 5.1, 5.2, and trunk
<reggie> trunk being what will be 5.3
<jelmer> reggie: in /trunk and /branches/5.0, /branches/5.1, etc?
<reggie> right
<jelmer> I don't see the problem
<reggie> as we talked about yesterday I had to individually import the branches because my 1.0 branch shows that bug
<reggie> so I did --prefix=branches/5 on my import
<reggie> and it seemed to do what I wanted
<reggie> now what I expect to be able to do is
<reggie> when I make a change in 5.0, I expect to be able to commit it and then pull that change up into 5.1 and then pull from 5.1 into 5.2
<mtaylor> reggie: I expect the same thing
<jelmer> reggie: You mean merge, not pull
<mtaylor> reggie: hello, btw
<reggie> jelmer, ok. I'm coming from bk so forgive my terminology ignorance
<reggie> mtaylor, hey
<jelmer> reggie: unless 5.0 and 5.1 contain *exactly* the same data, and
<reggie> ok, so I do a merge from 5.1 to 5.2 and it shows *lots* of changes (it shouldn't)
<reggie> so I worked with it with chad miller (not sure if you know him)
<reggie> and it seems that bzr thinks that the last common revision was 384 (in my case).  the last revision in 5.1 was like 490
<jelmer> reggie: It will merge from the latest common revision between 5.1 and 5.2
<jelmer> reggie: is this a public repository?
<reggie> jelmer, we have a public copy of it yes
<reggie> yes, I know what the merge will do but bzr is trying to merge > 100 changes.  months and months of work mainly because the revision ids don't match
<jelmer> reggie: What's the URL of that repository? If I can have a look at the actual data it may be a bit easier to comment
<reggie> because it was at revision 354 that 5.1 moved off trunk and into branch
<reggie> just a sec
<reggie> http://svn.mysql.com/svnpublic/connector-net/
<reggie> mtaylor, feel free to stop me if you have this already figured out  :)
<mtaylor> reggie: nope. haven't even looked at it
<reggie> grr.  mplayer won't play on my second monitor
<mtaylor> reggie: is this after doing an svn-import ?
<mtaylor> that's annoying
<reggie> mtaylor, yes
<mtaylor> reggie: how did you do the merges from trunk to 5.1 while it was in svn?
<mtaylor> like, once you cloned off trunk to 5.1 at rev 354
<reggie> mtaylor, never from trunk to 5.1
<reggie> always up
<reggie> from 5.0 to 5.1, 5.1 -> trunk, etc
<mtaylor> so, you cloned 5.0 from trunk at one point... and then at a later point you cloned 5.1 from trunk
<mtaylor> right?
<reggie> mtaylor, we're talking svn here so no cloning
<mtaylor> (sorry - _really_ using all the wrong words here)
<mtaylor> sure
<reggie> with svn you work on trunk and then at some point you branch (which basically just copies your work to another dir)
<mtaylor> right... but when you made a change in the 5.0 branch in svn... how did you propagate that to the 5.1 branch?
<reggie> svn merge
<mtaylor> hm
<jelmer> reggie: svn merge doesn't store any information
<jelmer> reggie: merge tracking information that is
<reggie> jelmer, I know
<reggie> svn merging is crap
 * mtaylor giggles
<reggie> one of the reasons that I want to move to bzr even though we are not done with svn
<reggie> let bzr do the heavy lifting regarding merges
<jelmer> reggie: what's wrong with merge showing a lot of changes
<jelmer> there are a lot of revisions that are in 5.1 and not in 5.2
<jelmer> uhm, sorry
<jelmer> 2 revisions are
<jelmer> argh
<reggie> are you using bzr-svn to see that?
<jelmer> no, svn log
<jelmer> yes, there are *a lot* of revision that are in 5.1 and not in 5.2
<reggie> well, svn merge allows me to cherry pick revisions.  each branch has things (deletes, renames, etc) that I don't want merged up
<reggie> so I skip those
<jelmer> everything between r825 and 1175 that affects /branches/5.1
<jelmer> is that what you were expecting as well?
<reggie> no that's not right.
<jelmer> reggie: what are you expecting it to do then? r824 is the last common ancestor of both 5.1 and 5.2
<wolever> Would anyone happen to know why I'm getting "SubversionException: ("Unrecognized URL scheme for 'https://example.com/svn/project'", 170000)" using bzr-svn to get the 'svn status' of a repository?
<jelmer> wolever: what version of bzr-svn are you using?
<wolever> most recent -- 0.4.7
<jelmer> is your subversion library built with ssl suppotr?
<reggie> perhaps I've used svn merge wrong but you can see that revision 1165 is a commit to 5.2 that is the merging of revision 1104 to 1161
<wolever> Yup -- I just re-built svn from trunk, and when I run "svn status" or "svn up" from the same directory, it doesn
<wolever> 't have any problem
<reggie> svn is saying that 824 is the last common ancestor because that is the last time they both sat on trunk
<jelmer> reggie: yes, and that is what bzr will do as well. That's the last common ancestor. I don't see how it can be more intelligent than that without extra cherrypicking tracking data
<wolever> Err, odd -- svn up just hangs, then later fails.  Time to re-build with ssl :\
<jelmer> reggie: bzr's merge should be able to deal with similar changes in both branches pretty well though
<chadmiller> Hi reggie.  If you're happy with the states of both trees right now, then you /could/ "cd higher; bzr merge ../lower;" and then "bzr revert .; bzr commit -m 'scorched-earth terrible idea from cmiller'" , which (IIRC) should prepare the higher tree so that it can accept merging patches from here on.
<reggie> could line endings be tripping it up?  I get 77 conflicts but many of them have no conflict markers
 * reggie needs a good conflict editor for bzr
<chadmiller> Reggie on win32, yes?
<bob2> ediff!
<reggie> it must be line endings because I see no conflict markers
 * reggie assumes the file.this is the merge attempt
<chadmiller> No, just "file" is.
<reggie> ahh
<chadmiller> foo.this is the previous version here.
<chadmiller> It makes sense with "other".
<reggie> chad, you said that approach would cause history issues
<chadmiller> It would duplicate the history, yes.  "log" would be much longer.  "vizualize" (from the GTK plugin) would have one more parallel line up to now, where it would rejoin the trunk.
<chadmiller> It's not perfect, but it may not be awful.  I bring it up again mostly to test the opinion of Bazaarkers here.
<reggie> wait.  this is stupid.
<poolie> hi chad
<jelmer> reggie: Yes, it could very well be line endings
<reggie> I need to just take the current files on all the conflicts
<reggie> and then mark them as resolved
<jelmer> bazaar badly needs eol support :-(
<chadmiller> Hiya poolie.
<jelmer> uhm, eol *conversion* support
<reggie> eewww. you mean it doesn't
<jelmer> our lines do actually have ends :-)
<chadmiller> reggie: Beware of successful merges not being what you intend, then.
<chadmiller> "bzr revert ." is probably better.
<reggie> chadmiller, right.  was about to do a svn diff to see what the successful merges actually did
<reggie> I wonder if I could avoid the history problem by using svn revert to revert all the successful merges, take the current file on all conflicts, and then bzr commit
<reggie> bzr shouldn't know the diff
<reggie> unless it gets confused by me reverting under it's nose
<vinc456> hi, i'm trying to connect to my bzr repository from a windows machine. The ssh server is configured to only and i have configured my settings as per "http://bazaar-vcs.org/Bzr_and_SSH". I'm unable to specify my login/username though
<reggie> since merge and commit are separated should be ok
<chadmiller> vinc456: What "url" are you specifying?
<vinc456> C:\Program Files\Bazaar\test>bzr branch sftp://ucalgary.hopto.org:9922/var/www/4
<vinc456> 71Project/trunk
<vinc456> the connection is made as i can see it in the ssh logs
<vinc456> but something assumes that i would to log in with the username "vincent"
<CardinalFang> Yes.  Does no sftp://vinc@ucalgary  work?
<vinc456> and no such user exists on the system
<vinc456> ok that worked
<vinc456> thanks!
<vinc456> i believe there was a script to configure so that users would not necessary need a shell account on the host machine to check out from the repository. Does anybody remember what it was called off hand?
<beuno> vinc456, can't you just branch through http?
<vinc456> i didn't think that bzr supported commits via http
<beuno> vinc456, absolutely
<beuno> http, sftp, ssh, bzr (it's own protocol)
<vinc456> i will try http then, thanks
<beuno> np
<jam> vinc456: contrib/bzr_access is also available
<jam> but it uses ssh keys
<vinc456> the server only accepts ssh keys so that will not be a problem
<jam> so you have 1 account that people can share, but it is limited to only running bzr
<jam> so it isn't a full access shell account
<vinc456> perfect, that is exactly what i'm looking for
#bzr 2008-02-13
<jdong> can someone tell me what bzr-rebase does exactly, or smack me and tell me to just get the plugin and play with it?
<jdong> it sound intriguing but I guess I don't completely understand what it's doing from the wiki's description
<lifeless> its a tool for discarding history
<lifeless> and making it hard to merge with people
<jdong> ok tell me about why not to use it after telling me what it does :)
<beuno> or making it linear, not having nested commits
<lifeless> but can be used to make the 'revision graph' look 'clean', and some projects consider this more important than good merging and collaboration.
<lifeless> jdong: what it does is transcribe the content of commits to a new revision graph
<lifeless> beuno: you don't need rebase to do that
<jdong> lifeless: so it essentially extracts the patch associated with each commit in a child branch and linearly commits it to the parent branch?
<beuno> lifeless, you don
<beuno> er,  you don't?
<lifeless> beuno: merge; bzr revert --forget-merges; bzr commit
<lifeless> jdong: no, bzr is not patch based.
<beuno> lifeless, ah, right, but that's on a per-commit basis
<beuno> though it's interesting to know, I've needed that a few times
<jdong> lifeless: the operation that it rebase does is similar to a merge in end result, but not in history, correct?
<lifeless> beuno: concurrency is endemic to collaboration; trying to hide it is a lie.
<jdong> wow I can't type coherently today
<lifeless> jdong: no, because it _discards history_
<jdong> lifeless: in what way?
<jdong> (ok I think I should just play with bzr-rebase to find out for myself)
<lifeless> jdong: anyone following the branch that has been rebased can no longer follow it; they have to start over
<jdong> lifeless: oh.... ouch.
<lifeless> jdong: the revision graph is what gives you the ability to do merges at all
<beuno> lifeless, assuming that you always have non-conflicting merges, it shouldn't actually loose any useful history, no?
<beuno> aaaaaaaah, interesting...
<lifeless> beuno: it always loses history
<beuno> _not_ what I need then  :D
<lifeless> beuno: if you are a leaf node in the contributor graph, then the impact of this loss is minor or even trivial.
<beuno> it should be stressed that i's more of a cosmetic thing
<lifeless> beuno: if you are not a leaf node in the contributor graph, then every node following you has pointers to revisions that your branch no longer refers to
<lifeless> beuno: imagine if linus rebased the linux mainline to insert a new commit a few days ago, which he'd done on a 'private mainline' or something
<jdong> eep, what does a KeyError on a pack during commit mean?
<jdong> bzr: ERROR: exceptions.KeyError: 'sftp://linerva/%7E/docs/.bzr/repository/upload/zq5x7hmwfonjtr1jgpd9.pack'
<lifeless> beuno: so - if you want to encourage a strict hub and spoke merge graph, rebase may fit the leaf nodes only
<lifeless> beuno: but if there are no leaf nodes, noone can use rebase without impact
<beuno> lifeless, I see. I understand why you're so pesimistic about it now  :D
<lifeless> jdong: no idea; what bzr version? try it again ?
<jdong> 1.0 locally, 1.1.0rc was used a bit remotely, seems to happen consistently with this commit (9 pngs)
<lifeless> file a bug
<lifeless> get the backtrace from ~/.bzr.log
<jdong> will do
<ubotu> New bug: #191402 in bzr "bzr resolve fails on files with certain strings" [Undecided,New] https://launchpad.net/bugs/191402
<ubotu> New bug: #191409 in bzr "commit on bound branch yields KeyError" [Undecided,New] https://launchpad.net/bugs/191409
<jdong> lifeless: ^^ filed. Let me know if any more information would be helpful
<jdong> lifeless: odd, looked like bzr+ssh:// worked fine (remote smartserver is 1.1.0~rc)
<mtaylor> anyway to find out in which revision a file was removed?
<mtaylor> or to get a log of a file not currently in a working tree?
<jdong> mtaylor: probably not best way, but bzr log -v shows all the add/modify/deletes associated with each commit....
<jdong> mtaylor: so you can pipe that to less and search through it for a filename
<jdong> the first catch should be the deleted revision
<rolly> there are two grep plugins, aren't there? Maybe one of those can help
<mtaylor> cool. that worked
<mtaylor> so now if I want to revert the deleted file to that rev... ?
<mtaylor> I actually want to restore that file and another, and then revert two other files to the state they were in that rev
<beuno> mtaylor, you can:  bzr cat dir/file -r revno
<mtaylor> hm
<beuno> cat it to a file
<mtaylor> yeah
<beuno> and there you have it
<beuno> bzr cat dir/file -r revno > new_file
<mtaylor> well hot-damn, look at that
<lifeless> mtaylor: please file a bug
<mtaylor> lifeless: against what?
<jdong> mtaylor: probably against log deleted_file_name not working
<lifeless> mtaylor: using revert to reinstate a deleted file to an old version
<mtaylor> ah. ok
<lifeless> mtaylor: because you want to restore the file id too
<jdong> lifeless: shouldn't there be a way to log old_file_name too?
<lifeless> mtaylor: I think there is one for deleted-way-back file names not working. we need a syntax for saying 'this file in that revision'
<jdong> that doesn't involve a long grep
<lifeless> mtaylor: also, for your case, to restore the file name I suggest you do:
<lifeless> bzr merge -r 0..before:DELETEDIN ./path/to/filename
<lifeless> mtaylor: rather than playing games with cat
<mtaylor> lifeless: can I give that a list of filenames?
<lifeless> mtaylor: no, not yet. there is a bug about that ;)
<lifeless> mtaylor: OTOH you can give it a directory :)
<lifeless> if a directory was deleted
<mtaylor> well, I actually do want to cherry pick file from the dir...
<mtaylor> but that's why bash has for!
<jdong> for file in.....
<lifeless> beuno: jdong: for reference, 'revert' is an alias for a special form of merge. So problems with revert can usually be addressed by using merge in a clever way.
<lifeless> this matters because you get better results with log afterwards.
<lifeless> and with merge
<jdong> lifeless: thanks. I should put this channel in my autojoin. I've learned more here the past 20 minutes than my entire day :)
<beuno> lifeless, but won't you have to manage conflicts for a file you actually want to overwrite with a previous version?
<lifeless> beuno: rarely
<lifeless> beuno: anyhow, note that this is the exception, normally just revert will DTRT
<beuno> lifeless, interesting. Thanks for the tip
<jdong> lifeless: interesting, it seems like the problem is pushing over sftp onto an OpenAFS filesystem causes all kinds of blowups that I didn't notice before
<jdong> bzr: ERROR: Generic path error: 'x5mcow4qnooegj14jua7.fetch': Failure: unable to rename to '../packs/e99efc4177e3d29106b0219514f8c3c4.pack')
<jdong> that's a new one
<jdong> lifeless: is there any way to get paramiko or whatever the SFTP backend is to give more debugging info?
<poolie> jdong, there may not be a debug option, but there is a debug setting in paramiko
<poolie> i'm just not sure how it's exposed
<poolie> it may be an environment variable
<poolie> separately, the failure i have at the moment is bzrlib.tests.blackbox.test_bundle_info.TestBundleInfo.test_bundle_info
<poolie> i'm planning to fix bug 189771 by keeping a record of plugins that failed to load,
<ubotu> Launchpad bug 189771 in bzr "launchpad plugin tests broken" [Critical,New] https://launchpad.net/bugs/189771
<poolie> and having the test suite fail if that list is nonempty
<spiv> poolie: that sounds good to me
<poolie> i think the other dirstate thing is now merged
<poolie> god and pqm willing
<lifeless> poolie: I don't know that the launchpad plugin fails to load
<lifeless> poolie: it may be that the tests for it fail to load, but that that is a soft error.
<poolie> true
<lifeless> poolie: if its the plugin failing to load, perhaps a test that all present plugins load  ?
<lifeless> (said test disabled by --no-plugins of course)
<poolie> ok actually it does load
<lifeless> if its the tests for it failing to load; then I think failing to load a test containing module should be a hard error not a soft error
<lifeless> I've always thought this :)
<lifeless> as in - don't run any tests, just stop cold
<poolie> right
<poolie> and it'd be a simple way to fix it
<poolie> if you don't like it, you can always use --no-plugins
<lifeless> poolie: can you land the 1.3 NEWS sections etc asap
<lifeless> poolie: its a blocker for doing merges to mainline, unless you're going to fixup NEWS for us :)
<lifeless> hmm, well not 1.3, but at least the markers for what is 1.2
<poolie> lifeless, sure
<lifeless> (this is why its in the release process docs)
<poolie> i have not got up to that part of the process yet
<lifeless> ah
<lifeless> so technically I can land something in mainline still. _cool_
<lifeless> :>
<poolie> lifeless, i'm submitting that patch now
<poolie> the static declarations in symbol_versioning are a bit ugly
<poolie> remember to check you merges to NEWS go into the right place
<lifeless> which patch?
<poolie> to call it 1.3dev
<lifeless> oh the release stuff
<lifeless> yes
<lifeless> I'll hold off this merge then
<lifeless> I suspect your release process is somewhat difference in internal nature than mine
<lifeless> thumper: so why did you add test_lp_registration when there is test_register already ?
<thumper> lifeless: test_register was testing the register branch command
<lifeless> and the rpc
<thumper> lifeless: whereas test_lp_registration was testing the launchpad xmlprc bits
<poolie> lifeless, also your change to use edge seems to break the tests, now that they're running, but probably in a straightforward way
<lifeless> poolie: well, when my change landed all the tests passed :)
<lifeless> thumper: for instance, test_register has test_mock_server_registration, testing the service directly
<thumper> lifeless: I was pairing with abentley to do this
<thumper> lifeless: and he suggested it and it seemed reasonable at the time
<lifeless> thats fine, I am worried that we either have duplication, or confusion.
<lifeless> if there is no duplication then its at best confusing to me
<poolie> i think i will merge the files and dedupe
<lifeless> because test_register is just blackbox tests
<lifeless> thanks poolie
<thumper> the tests in test_lp_registration are very simple and explicit, I don't think there is any duplication
<lifeless> is *not*
<thumper> I don't have a strong opinion one way or the other
<thumper> the tests could be moved if that would help unconfuse you
<lifeless> poolie has already said he will
<abentley> poolie: But using --no-plugins means I can't use gselftest to run my tests...
<poolie> ! i didn't know of gselftest
<lifeless> abentley:
<lifeless> abentley: tests that fail to load are still broken; I _really_ want hard errors on all such things
<lifeless> abentley: I don't really care if its expressed as a failing test ('all test scripts loaded'), or as an earlier error ('failed to create test suite')
<abentley> lifeless: I think I agree.
<abentley> There are some plugins I don't run because their test suites don't pass.
<poolie> abentley, so you mean you want it shown as a failure, but other tests should run?
<abentley> poolie: I think that would be fine.
<lifeless> I think its unneeded complexity though
<poolie> note that this is only when the plugin's tests can't even be imported
<lifeless> as failing to run any tests is much easier to signal
<poolie> hopefully that's rare
<abentley> I think mainly I was saying that --no-plugins is not a panacea.
<abentley> But the plugin should be fixed, and I have a low tolerence for broken plugins.
<abentley> I have a very big ~/.bazaar/plugins/inactive directory
<poolie> lifeless, re indenting of news, you want the asterisks in column 5?
<lifeless> poolie: yes
 * igc bbl
<poolie> lifeless, spiv: patch for 189771 sent, would appreciate if someone could look at it
<poolie> i'm going out for a bit
<ubotu> New bug: #191449 in bzr-gtk "tests should skip if there's no $DISPLAY" [Undecided,New] https://launchpad.net/bugs/191449
<lifeless> bleh what a day of little-tasks
<lifeless> time for some coding
<i386> lifeless: im getting another me here at work
<i386> so they can do those sorts of things :)
<lifeless> didn't they break the mold?
<i386> haha
<i386> urgh
<i386> large PNG is large
<mwhudson> hee: AttributeError: '_PreviewTree' object has no attribute 'get_symlink_target'
<mwhudson> i guess we didn't think that code was complete
<abentley> mwhudson: nopes.
<ubotu> New bug: #191466 in bzr "bzr update on missing file does nothing. svn update brings back file." [Undecided,New] https://launchpad.net/bugs/191466
<poolie> lifeless, what do you mean "5 spaces rather than 2"?
<lifeless> rather than 4
<lifeless> from
<lifeless>     here
<lifeless> from
<lifeless>      here
<lifeless> thats what the diff shows
<poolie> thought so
<poolie> did you have an objection to vila's patch other than the trace thing?
<lifeless> vila? or alexander?
<poolie> vila
<poolie> regarding setup.py
 * igc dinner
<lifeless> poolie: oh right the test cleanup one?
<lifeless> poolie: note vs info ?
<poolie> yes
<lifeless> poolie: I hadn't seen his follow up
<lifeless> iz fine
<poolie> i have a tarball
<poolie> night all
<rolly> yay, rc1
<johnny> if i do a cvsps-import, what exactly do i have ? layoutwise?
<cropalat> hi, i need some help with bzr. Any body???
<garyvdm> There are lots of people here. Go ahead an ask.
<cropalat> since yesterday, i try to use "bzr branch http://bazaar.launchpad.net/~canonical-training/ubuntu-desktop-course/ubuntu-desktop-course-beta", and the transmission stop as you can see with this part of tcpdump output.
<cropalat> 08:04:52.496764 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: P 2615850:2616810(960) ack 6326 win 8416 <nop,nop,timestamp 1084713278 39394400>
<cropalat> 08:04:52.496852 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394531 1084713216,nop,nop,sack 2 {2598570:2616810}{2561450:2592810}>
<cropalat> 08:04:52.510477 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2616810:2618250(1440) ack 6326 win 8416 <nop,nop,timestamp 1084713278 39394400>
<cropalat> 08:04:52.510582 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394535 1084713216,nop,nop,sack 2 {2598570:2618250}{2561450:2592810}>
<cropalat> 08:04:52.524143 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2618250:2619690(1440) ack 6326 win 8416 <nop,nop,timestamp 1084713279 39394403>
<cropalat> 08:04:52.524272 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394538 1084713216,nop,nop,sack 2 {2598570:2619690}{2561450:2592810}>
<cropalat> 08:04:52.537799 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2619690:2621130(1440) ack 6326 win 8416 <nop,nop,timestamp 1084713279 39394403>
<cropalat> 08:04:52.537903 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394541 1084713216,nop,nop,sack 2 {2598570:2621130}{2561450:2592810}>
<cropalat> 08:04:52.551418 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2621130:2622570(1440) ack 6326 win 8416 <nop,nop,timestamp 1084713280 39394406>
<cropalat> 08:04:52.551511 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394545 1084713216,nop,nop,sack 2 {2598570:2622570}{2561450:2592810}>
<cropalat> 08:04:52.565075 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2622570:2624010(1440) ack 6326 win 8416 <nop,nop,timestamp 1084713281 39394410>
<cropalat> 08:04:52.565177 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 <nop,nop,
<garyvdm> Please use http://pastebin.org/
<beuno> please :D
<cropalat> my screnn show this "| [=                                                         ] Transferring 0/4"
<cropalat> sorry
<beuno> cropalat, does bzr output an error?
<cropalat> beuno, no
<cropalat> but it get out with timeout
<beuno> cropalat, doesn't seem bzr-related than
<beuno> what version of bzr are you using?
<cropalat> Bazaar (bzr) 1.0.0
<beuno> cropalat, seems good enough. It's probably related to some problem with your ISP
<beuno> you can try updating to the latest bzr if you want to try _something_ on your end
<beuno> 1.1 es the latest release
<cropalat> i will get the traffic to see. Thanks
<cropalat> my distro are working with 1.0
<beuno> cropalat, what distro would that be?
<cropalat> Ubuntu 7.10
<beuno> cropalat, you can get the lastest from: https://launchpad.net/~bzr/+archive
<beuno> either add the ppa to your sources.list, or just plain download and install the deb
<cropalat> beuno, what is new in this version?
<beuno> cropalat, nothing significant enough that would fix your timeout, but it won't hurt  :D
<cropalat> beuno, thanks
<beuno> cropalat, np
<cropalat> beuno, where the bzr put the temp files?
<garyvdm> cropalat: yourbranch/.bzr/
<cropalat> garyvdm, any specia name?
<garyvdm> cropalat - sorry - I don't understand
<garyvdm> What are you looking for>
<garyvdm> *?
<cropalat> garyvdm, how can i identify where the bzr are storing the download data at this time?
<garyvdm> yourbranch/.bzr
<garyvdm> where yourbranch is the dir you are creating the branch in
<cropalat> ok
<garyvdm> If you bzr branch mybranch and it stop half way you can cd mybranch then bzr pull and it will carry on from where it stopped
<mikeX> hello, this is somewhat OT, but is it possible for your patiencediff to output only the *characters* that differ, not the whole line?
<luks> you can split the input on characters, not lines
<luks> but then it will be very slow, obviously
<mikeX> how would that work?
<luks> list("foobar") -> ['f', 'o', ...]
<mikeX> well actually i don't wont characters, just the subsets that differ
<mikeX> hello world vs hell0_world, in such a case 0_
<lifeless> mikeX: yes the algorithm can do this
<lifeless> mikeX: and our internal code too
<mikeX> can you point me to the files that require modification for changing the output then?
<lifeless> mikeX: but its much more expensive (if each line was 80 characters, and it was a linear cost, 80 times slower, but its > linear, upto quadratic worst case)
<lifeless> mikeX: what you could do is something slightly different, and on the differing lines run the more expensive algorithm
<lifeless> bzrlib.diff has the bulk of the diff high level logic
<mikeX> thanks a lot
<lifeless> gnight
<lifeless> oh also
<lifeless> check out bzrlib.tests - there is a thing in there -assertEqualDiff that does a character level diff output
<luks> mikeX: PatienceSequenceMatcher(None, "hello world", "hell0_world").get_opcodes()
<mikeX> that's greak, thanks luk
<mikeX> s
<jdong> is there a bzr plugin yet that can act like a "branch aggregrator"
<jdong> i.e. check X different branch locations for new commits
<awilkins> jdong: Even if there was, would there be any difference between that and a shell script?
<jdong> awilkins: well other than from a UI perspective, no.
<jdong> that would be a final fallback if there weren't a plugin AND I wasn't willing to write one :)
<awilkins> Sort of like a branch manager GUI?
<awilkins> Keeps track of all your branches and such?
<jdong> kind of like let's say "foobar" has a large developer community, with 20+ branches
<jdong> right now, if I want to check for new commits from one of the developers, I'd have to keep track of 20 branch URLs by hand
<jdong> or edit aliases by hand in a text editor... both of which are kind of annoying
<jdong> I'd love to be able to do like "cd foobar; bzr check-related-branches"
<jdong> and get a quick summary of type "Branch $foo has $n new revisions"
<ignas> hi
<ignas> if i have 5 branches and want to put them into a shared repository that i have just created using "bzr init-repo" what would be the command to use?
<LeoNerd> Just push them there
<luks> bzr branch
<ignas> i want to pull 1 branch as a trunk, and put other 4 in branches/
<luks> oh, or push
<ignas> LeoNerd: thanks
<mikeX> hmm, PatienceSequenceMatcher seems to yield very bad results for unicode strings
<ignas> hmm I get bzr: ERROR: No WorkingTree exists for "file:///home/ignas/src/schooltool.devtools/.bzr/checkout/" if I try bzr mkdir branches in the central repository
<fullermd> You just want to use mkdir for branches/...
<ignas> oh
<ubotu> New bug: #191569 in bzr "Cannot set "whoami" at a repository level" [Undecided,New] https://launchpad.net/bugs/191569
<ubotu> New bug: #191572 in bzr "KeyError when pulling from svn repo." [Undecided,New] https://launchpad.net/bugs/191572
<ubotu> New bug: #191576 in bzr "TypeError when using `bzr branch` on an svn repository" [Undecided,New] https://launchpad.net/bugs/191576
<dato> abentley: hi. do you think `shelf show` could use colors like `shelve` itself does, and maybe gain a --no-color switch?
<abentley> dato: I don't remember what shelf show does.
<dato> display the contents of a patch from the shelf
<dato> basically `cat $topofshelf`
<abentley> Yeah, I think that's reasonable.
<dato> would you like a bug? I'm afraid time doesn't allow me to offer anything else =)
<abentley> dato: Launchpad actually provides for feature requests as "blueprints".
 * dato guesses he has the "wishlist bug" concept very hard wired in his brain
 * abentley doesn't like it when people say his software has bugs just because it doesn't have a feature they want :-)
<abentley> I actually prefer the Trac approach of "Issues" being "Bugs", "Enhancements" and "Tasks".
<schierbeck> fuck
<schierbeck> had a network outage, now the bzr-gtk trunk is locked, and break-lock ain't working
<abadger1999> Any packagers of bzr & company for Ubuntu/Debian/etc around?
<dato> abadger1999: yes
<abadger1999> Do you guys do anything out of the ordinary to manage the large number of bzr plugins?
<abentley> schierbeck: Pastebin us a traceback, and I can take a look.
<dato> abadger1999: yes: most of them are not packaged
<dato> personally I wanted to create a big package with a selection of the most useful ones
<dato> but several core people disliked the idea
<abadger1999> dato: Yeah, that would make my day as well :-)
<dato> and I'm afraid I'm not going to spend my time in creating 10 or 12 different packages for such tiny stuff
<abentley> dato: Isn't that what I do? ;-)
<schierbeck> abentley: well, the only thing i get which resembles an error is "Disconnecting: Received extended_data after EOF on channel 0."
<schierbeck> right after using break-lock on the remote branch
<dato> abentley: hehe
<abadger1999> abentley: That's why bzrtools is packaged for Fedora but bzr-{dbus,avahi,bisect} is not :-)
<abentley> schierbeck: That resembles a bug we had with old versions of Paramiko.
<abentley> But it was a harmless message
<schierbeck> maybe, but the locks are not released
<schierbeck> actually, it just resets the lock time
<abentley> schierbeck: Okay, so you probably have a couple of "bzr serve" processes running on the server.
<abadger1999> If there was an effort to get things into a single upstream product (like bzrtools) and make releases as part of that product then there'd be more uptake of the individual utilities.
<abentley> You should be able to run break-lock several times.
<schierbeck> abentley: yeah, it seems like it
<schierbeck> i'll try
 * abadger1999 resigns himself to asking for more bzr related packagers on the fedora lists
<abentley> Each time you break-lock, a bzr process should stop.
<schierbeck> abentley: that worked! thanks!
<abentley> schierbeck: No problem.
<dato> abadger1999: and what do the packagers say? they'll do more packages?
<schierbeck> i've drunk an unhealthy amount of coffee today...
<abadger1999> dato: I'm guessing I'll get a bunch of people telling me to use git :-/
<dato> abadger1999: heh
<abadger1999> dato: I don't think the overlap between packagers and bzr users is very high in Fedora ATM.
<dato> abadger1999: there are a lot of git fanboys in debian as well
<abentley> abadger1999: Could you post something to the list?  If the authors are amenable, I'd be happy to incorporate more stuff into bzrtools.
<dato> damn, abentley was faster about the list bit
<abadger1999> abentley: I sure can.
<dato> :)
<abentley> And that's not exclusive with shipping the plugins separately.
<abadger1999> Anything to help me scale more effectively :-)
<ignas> how do I do a push without being in the branch, like bzr push /path/to/some-repo sftp://place-for-push ?
<abadger1999> abentley: Oh?  Meaning you'd help manage releases as separate tarballs from the bzrtools tree?
<abentley> abadger1999: Meaning that bzr-dbus can be provided as a standalone plugin and as part of bzrtools.
<abadger1999> abentley: okay.  that would be awesome for packagers.
 * dato bbl
<abentley> I suppose the converse also applies, if people think bzrtools is getting too big.
 * awilkins sulks because there is no dbus on Windows
<LeoNerd> There were rumours of a port
<awilkins> Cursory searching reveals one
<awilkins> I mean, it wouldn't be hard, windows is thick with IPC methods it could wrap
<awilkins> Only wanted to see if commit-notifier worked
<awilkins> It puts an icon in the toolbar then dies :-)
 * Debolaz has a dbus-daemon.exe running on his Windows XP box.
<Debolaz> At least according to task manager. :)
<orospakr> Hey, can I get bzr diff to do colour diffs with paging like git can do?
<awilkins> Right, I've switched from svk to bzr for my working-at-home needs from the SVN repo
<orospakr> awilkins, do you have issues where bzr eats all available ram (due to a bug in libsvn) when doing a big svn checkout?
<awilkins> orospakr: Yes, I have that problem, esp on my big repo
<orospakr> awilkins, it's been ongoing for years.
<awilkins> orospakr: Alas, it's now failing on something else, having successully converted about 7900 / 9000 revisions
<orospakr> recently I finally saw some activity on the svn bug tracker about this issue.
<orospakr> harsh.
<awilkins> You can at least resume it after it MemoryErrors you
<awilkins> But now it's the same KeyError on a pack each time
<awilkins> It's in the upload folder which makes no sense to me because it's PULLING not pushing
<awilkins> Go figure.
<awilkins> There's a bug in for it
<awilkins> #191572
<awilkins> I think increasingly SVN is going to end up as the nice, safe, steady backend for roving teams of developers using wild and crazy new VCS tools
<awilkins> Despite all the effort they put in for v 1.5
<awilkins> And when TortoiseBzr or TortoiseGit are done, SVN will really start to die.
<awilkins> Tortoise<DVCS> ought to be possible - just use the common idiom and a plugin backend
<awilkins> Should cover bzr, mtn, hg, git ; there aren't too many radical differences there.
<awilkins> cd ..
<awilkins> oops
<abentley> orospakr: "bzrtools" provides cdiff.  You can also use diff --using colordiff.  The pager side is generally done using |less -R.
<zurgutt> folks, help me understand something: apparently i can commit just one subdir of branch by "bzr commit dir" but how to update just some file/subdir? "bzr update dir" updates whole branch.
<kiko> for general reading and comments: http://news.launchpad.net/general/the-great-source-code-supermarket
<kiko> zurgutt, I'm not sure that's actually possible
<zurgutt> bzr help update says "bzr update [DIR]"
<fullermd> That should probably say "bzr update [BRANCH]" instead...
<zurgutt> what would [BRANCH] mean in this case ?
<fullermd> "bzr update foo" instead of "cd foo ; bzr update"
<dato> kiko: 'three or more of the words: "foo"' <-- the foo stuff is screaming for commas, otherwise you try to read it as a sentence and choke
<kiko> that's kind of the point ;)
<zurgutt> ah.. but no way to update one file?
<fullermd> No, that's not a sensible operation.  Files aren't versioned, whole branches are.
<dato> kiko: well, suit yourself. IMHO it sucks, but it's not my problem. :-)
<zurgutt> in respect to this, how does committing just one file make sense?
<fullermd> You can create constructs like "a branch at rev6, with this file at rev3", but what you'll end up with is a branch at rev6 with one altered file; that it happens to have the same content as the file did at rev3 is periphal and of no interest to bzr.
<fullermd> In that you're implicitly creating a branch state that only partly corresponds to what's on disk.
<zurgutt> should be ok to update (well, get) one file to working tree from central repo without updating local status.. someone used to svn is asking for it, i myself am not familiar with svn
<fullermd> Well, "central" is kinda question-begging.
<fullermd> You can use 'revert' to throw a file's contents to some arbitrary rev.
<ubotu> New bug: #191651 in bzr "bazaar.conf::editor line quoting is not preserved correctly" [Undecided,New] https://launchpad.net/bugs/191651
<n[ate]vw> what's the best way to send another coder a repo over, say, email? just tarring the project folder up can leave "dangling pointers" to other branches on my machine
<fullermd> Does that matter?
<n[ate]vw> it doesn't hurt, I suppose. It's not like "merge" would have a better reference given that mode of transportation
<n[ate]vw> so that's not a bad way to do do a lo-fi share without involving an HTTP server or opening ports for ssh?
<fullermd> I s'pose you could just push it to /tmp somewhere and tar that up.  Then it wouldn't have those cosmetic issues.
<dato> right
<dato> push /tmp/foo
<dato> remove-tree /tmp/foo if you'd like
<fullermd> That would also take care of issues you might have with it being in a repo, too.
<n[ate]vw> ok, that makes sense. the push would let bzr know it's a distinct branch, which is basically what I was wanting. and the remove-tree would help the other guy get familiar with basic usage :-)
<luks> hm, would be nice to have an option to do this from bzr export
<n[ate]vw> yeah, I'd looked into export, but it didn't seem to be quite what I was looking for (a complete branch, but able to go wherever a .tgz can)
<abentley> n[ate]vw: bzr send is a good choice for sending a branch to someone.
<n[ate]vw> abentley: that's not just for patches?
<luks> that would involve creating an empty target branch, no?
<abentley> n[ate]vw: It preserves all data except tags.
<fullermd> I thought bundles were a wildly inefficient means of bulk rev moving...
<abentley> luks: yes, it would
<abentley> fullermd: They are actually more efficient, because they use MPdiff and don't have any fulltexts.
<abentley> And they use bzip.
<fullermd> Interesting.
<abentley> The previous bundle format was much more inefficient, in terms of both storage and speed.
<dato> n[ate]vw: there is --no-patch, in case you want that if you use send
<dato> (that'd be the equivalent of the remove-tree above :)
<fullermd> D'oh, you moved bzrtools to launchpad...
<abentley> Something wrong with that?
<fullermd> Not as such, really.  Just the URL's for the download files are unfriendly.
<fullermd> Are you planning to keep using the 'stable' release series?
<fullermd> (i.e., for 1.3.0 and 1.4.0 and such)
<abentley> Yes, that's the plan.
<n[ate]vw> dato: so I would "bzr send --no-repo -o ../sendable_repo", and then the other developer would need to create an empty branch and "bzr merge sendable_repo"?
<fullermd> 'k.  I think I can get away with using the 1.x.y version for that bit of the path too, and not have to update the base URL for every upgrade then...
 * fullermd is trying to get a head start on port updates for the next release while he waits for a phone call.
<abentley> I can't really keep hosting stuff on panoramicfeedback.com now that I don't work there.
<fullermd> Some places are funny like that.
<dato> n[ate]vw: sorry, gotta run, but : `bzr send --no-patch -o ../sendable ../empty-branch` <-- *you* create the empty branch
<dato> leaving now, but I leave you in good company ;)
<n[ate]vw> thanks, I'll keep experimenting!
<fullermd> Hm.  I guess I should add LP as a backup source for bzr too, as long as I'm here...  means I need to get creative on that anyway.  Blah.
<fullermd> Heck with it, I'll just change it by hand for every release series.
<n[ate]vw> can someone explain what the function of the PUBLIC_BRANCH argument is on bzr send?
<fullermd> It's the location of a public mirror of your branch (assuming one exists)
<n[ate]vw> how can I "unremember" it? I was playing with it, and now I can't play *without* it
<fullermd> You can edit the branch.conf manually.  Don't think there's a UI for it.
<appcine> Hi! I've been using svn for a project about a year. Is it possible to preserve revision history somehow when switching to bzr? I'm not likely to revert as the system is quite stable, but it's fun to check out oooold stuff to see what you had back then :)
<n[ate]vw> fullermd: ok. so by setting it, it would cause the branch to push changes to submit_branch?
<n[ate]vw> hmm, but that role seems to be fulfilled by push_location already
<fullermd> No, it's not used for push.
<fullermd> I'm not sure if it's used for anything except send.  Maybe some of the PQM stuff?
<abentley> appcine: Check out bzr-svn.  It provides lossless import from svn and export to svn.
<appcine> abentley: Ah, sweet
<n[ate]vw> fullermd: so I guess I'm confused as to what happen's when I specify dato's ../empty-branch
<abentley> fullermd: Yes, it's used by PQM-submit also.
<abentley> I can't think of anything else that uses it offhand.
<fullermd> n[ate]vw: 'send' can include the revisions inline, or it can refer to an external branch ("Get these revs from there").  The public loc is used for the latter.
<fullermd> (it may be used in the former too, if the person trying to do the merge needs other revs you didn't include)
<n[ate]vw> ok, so if I specify a public branch, the ../sendable file won't actually include the history?
<fullermd> No, you need --no-bundle to cause that.
<abentley> But if you specify --no-bundle, then a public branch is required.
<n[ate]vw> ok
<abentley> The important thing to note is that dato's commandline specifies only one branch: the empty one
<n[ate]vw> I guess I don't see why you would specify a "public_branch" on your local machine when sending to another developer
<abentley> What you are sending is a requst to pull or merge your changes.  If you have a public mirror, there's no need to include a bundle, and that's what public_branch is for.
<n[ate]vw> ok, so the public_branch usually goes with --no-bundle, so that you can send some changes to somebody who already has a branch or can grab one from the public repo
<abentley> Yes.
<n[ate]vw> cool. then for a one-off "here's my code, and also please play around with bazaar",  it looks as though my options are:  A) push+remove-tree+tar on my side, untar+co for the receiver, or B) send on my side, init+pull on the receiver
<n[ate]vw> in this case, A seems preferable given that I'm a little more familiar with bazaar than the other developer
<johnny> so, what exactly do i get when i run cvsps-import on a repo
<johnny> is it a repository already?
<lifeless> johnny: 'bzr info' :)
<johnny> lifeless, it says repository branch: .
<johnny> in each area
<lifeless> sounds like each has been converted separately, which is what I would have expected if you didn't create a repository yourself
<lifeless> you can create a repository and bzr branch them into it all at once via bzr multi-pull (from bzrtools)
<johnny> i only have 1 branch
<johnny> HEAD
<lifeless> no tags?
<fullermd> Eh?  If it says "repository branch", it's in a repo...
<lifeless> fullermd: but a path of . ?
<lifeless> johnny: perhaps I'm confused
<lifeless> fullermd: unless 'repository branch' means 'the shared bit is on'
<fullermd> I didn't say it's a great UI   :p
<fullermd> You're in the root of the branch, so it gives the branch path as '.'
<johnny> it doesn't matter where i am
<fullermd> The line after it gives the location of the repo.  If it were a standalone branch, it would say "branch root: .", not "repository branch: ."
<johnny> i have one tag called start
<fullermd> But anyway, cvsps always puts its stuff in a shared repo.
<johnny> i just want to shorten the path i think
<lifeless> fullermd: oh god thats just confusing
<lifeless> fullermd: surely it should say branch root always; and only sometimes show the repository root
<fullermd> Well, it could be a checkout, in which case it'll say "repository checkout root: ."   :)
<fullermd> Of course, if you move into a subdir, it calls the branch root (by whatever name) by its full path, instead of relative to $CWD like it does with '.'...
<abentley> The fact that it says "repository branch" not "standalone branch" means that it's in a shared repo.
<johnny> any where in here ~/projects/redemmas/infoshopkeeper/branches/HEAD
<fullermd> Or if you info $DIR from elsewhere, it always uses a path relative to ., unless that path would include a '..'...
<johnny> it says repository branch: .
<johnny> under infoshopkeeper thatis
<fullermd> johnny: I don't think cvsps-import creates working trees in the repo, so there's nowhere you could go inside any of the branches BUT the root.
<lifeless> abentley: I think it is confusing to have something that is always the same datum labelled differently
<lifeless> abentley: if I understand what the output is doing correctly that is
<johnny> aha.. ok
<johnny> so, i think i'd like to reformat per the recommendations in the user guide
<lifeless> if they are all under the same repository
<lifeless> just mv the directories to where you want them (still under the repository)
<fullermd> I never directly touch the repos/branches cvsps-import creates.  I branch them elsewhere and rearrange stuff there.
<fullermd> (that leaves them pristine for future incremental conversions, for one thing)
<johnny> good recommendation
<abentley> lifeless: Well, you've got a point.  When I worked on "info", it was mostly to make it handle more cases show more paths.  I didn't want to make too many changes at once.
<abentley> ...handle more cases AND show more LOCATIONS...
<johnny> now i just need to make loggerhead work
<RainCT> Hi
<lifeless> hi
<james_w> hi
<RainCT> is it possible to force a merge with uncommited changes?
<lifeless> yes
<lifeless> --force
<lifeless> but its usually a bad idea; why do you want to?
<RainCT> lifeless: because I have some changes that are not intended for commiting (local changes to get the code working on my machine)
<lifeless> RainCT: merging with them present will result in you committing them
<lifeless> RainCT: its definitely not what you want to do.
<lifeless> RainCT: bzr shelve --all
<lifeless> RainCT: then merge
<lifeless> RainCT: commit
<lifeless> RainCT: bzr unshelve --all
<lifeless> RainCT: (but have you considered having a branch where the changes to make it work are committed)
<RainCT> it's database password, path locations and such stuff..
<RainCT> lifeless: thanks
<james_w> lifeless: won't that be a problem if the changes you merge affect the same area that your local changes do?
<james_w> (as I recall shelve currently only does two way, and doesn't handle diffs that don't apply).
<lifeless> james_w: shelve --force
<lifeless> james_w: its less of a problem than a commingled tree with stuff you don't want to commit and a merge you need to commit
<mwhudson> james_w: it's not worse than having conflicts in your tree where some changes are from the merge and some from your uncommitted changes is it?
<james_w> no, it's not worse at all.
<lifeless> RainCT: sounds like that stuff should not be altering versioned files; I'd consider making a branch that adds an include facility or some such, then you can have an ignored file with that local stuff
<james_w> It's just not the perfect solution in all cases.
<lifeless> RainCT: or you could still have a branch called 'machineX' that you commit them too, but never ever merge from it.
<lifeless> james_w: for the given scenario --force is never the right thing
<RainCT> it doesn't commit: http://paste.ubuntu.com/4565/plain/ (had an error like that some days ago too)
<lifeless> james_w: (merge --force) I mean
<james_w> it would be great to have a shelve that could do 3 way merges to avoid all of this.
<lifeless> bb crashing on the resubmit tab :(
<james_w> RainCT: I think that is the name of one of the directories in the path that is causing the problem.
<james_w> I can't find the bug report at the moment.
<lifeless> abentley: the containing dir?
<lifeless> meh
<lifeless> james_w: ^ the containing dir?
<lifeless> RainCT: have you committed in other projects under programaciÃ³ ?
<RainCT> lifeless: yes, all my branches are there and they work fine
<james_w> lifeless: yeah, ProgramaciÃ³
<james_w> RainCT: do you have versioned symlinks in the other branches?
<lifeless> RainCT: please try the commit with BZR_PDB=1 (BZR_PDB=1 bzr commit ....)
<lifeless> RainCT: when it stops you'll be in a python debugger
<lifeless> RainCT: and able to example the path it fails on
<RainCT> james_w: ProgramaciÃ³ is a symlink to another hard disk
<RainCT> beside that there is no other symlink I think
<james_w> ah, but if it is that then it would be odd to only fail in this branch.
<RainCT> lifeless: ok I'm there, what now
<james_w> RainCT: p abspath
<RainCT> ?
<RainCT> u'/media/sdb2/rainct/Programaci\xf3/Python/revu/bin'
<lifeless> ok thats wrong
<lifeless> :)
<lifeless> whats os.getfilesystemencoding()
<abentley> lifeless: bb restarted.
<lifeless> thanks
<james_w> RainCT: also "p path" please.
<RainCT> lifeless: in an interactive python console?
<RainCT> u'bin'
<lifeless> RainCT: where you are right now :)
<james_w> RainCT: and "p self.basedir" please.
<lifeless> jam: ping
<RainCT> lifeless: *** AttributeError: 'module' object has no attribute 'getfilesystemencoding' (and the some with python -c "import os; print os.getfilesystemencoding()")
<RainCT> u'/media/sdb2/rainct/Programaci\xf3/Python/revu'
<james_w> it's sys.getfilesystemencoding() I think.
<lifeless> print bzrlib.osutils._fs_enc
<dato> yes
<RainCT> james_w: 'UTF-8'
<RainCT> lifeless: UTF-8
<luks> os.readlink doesn't seem to like unicode strings
<lifeless> >>> '/media/sdb2/rainct/Programaci\xf3/Python/revu'.decode('utf8')
<lifeless> Traceback (most recent call last):
<luks> lifeless: u'/media/sdb2/rainct/Programaci\xf3/Python/revu/bin' already is unicode
<lifeless> and giving it the u and encoding to utf8 fails too
<lifeless> luks: yes I know
<lifeless> luks: I am probing for what particular mis-interpretation has occured
<luks> if I make a file 'Ã¡' on utf-8 filesystem, os.readlink(u'Ã¡') fails, but os.stat(u'Ã¡') works
<lifeless> luks: which thanks to the entire lack of structure (its all bytes, HAI), is mainly trial and error
<lifeless> oh foo, misread the output.
<lifeless> ok, so its valid unicide
<luks> yeah
<james_w> so abspath = os.path.pathjoin(posixpath.realpath(safe_unicode(basedir)) , u'bin')
<lifeless> right, we need a readlink wrapper
<luks> but it's encoding it in ascii, not the FS encoding
<lifeless> a) file a bug on python
<lifeless> b) wrap readlink and do the fs_encoding ourselves
<lifeless> RainCT: please file a bug on bzr
<lifeless> RainCT: to work around this, cd to where the symlink points first
<lifeless> RainCT: or if the symlink is in the tree you are committing; you'll have to patch bzr
<luks> hm, from http://svn.python.org/projects/python/trunk/Modules/posixmodule.c it looks like it should be using the FS encoding
<luks> but maybe it's a recent bugfix
<awilkins_away> Hmm, shame you can't have bug dependencies in launchpad
<lifeless> awilkins: we can't depend on python being fixed anyway
<awilkins> No, but it would be nice to unpick the fix if it is ?
<RainCT> ok, thanks :)
<lifeless> awilkins: its a C module; we're not going to monkey patch with a new build of that at runtime :)
<mwhudson> pff, ctypes!
 * mwhudson hides
<james_w> http://svn.python.org/view?rev=52415&view=rev
<lifeless> mwhudson: I know where you live
 * RainCT renamed /media/sdb2/rainct/ProgramaciÃ³ to something without special chars (but the symlink still has them) and now it works
<lifeless> RainCT: what python version are you using ?
<RainCT> 2.5.1-5ubuntu5
 * RainCT is away for a while
<lifeless> RainCT: please file a bug on ubuntu's python then; this is a regression from the look of it
<awilkins> Looks like you need a test case for this anyway
<lifeless> oh yeah, we have to change bzr
<lifeless> someone has this in the field :(
<james_w> lifeless: that fix isn't in 2.5
<james_w> it wasn't also fixed in the 2.5 branch as far as I can see.
<lifeless> james_w: its from 2006 !
<james_w> yeah, but 2 months after the 2.5 branch was created.
<lifeless> ekk
<lifeless> anyhow, all moot; we support 2.4
<schierbeck> you guys know of a generic patching library for python? i just need to be able to apply a patch
<lifeless> schierbeck: application is really trivial, the main issue is actually parsing
<lifeless> schierbeck: if you mean patches created by 'diff -u' I *think* there is a parser in bzrtools.
<RainCT> lifeless: so, what should I report?
<lifeless> RainCT: the error and original backtrace
<schierbeck> lifeless: okay
<lifeless> RainCT: for bzr itself. For python, that os.readlink in 2.5 barfs on unicode paths.
<schierbeck> just checking to see if there's anything obvious, i'm not that well-versed in python libraries
<schierbeck> and searching for "patch library" yields quite a bit of noise...
<lifeless> RainCT: and point at the fix in svn :) - this should be an ubuntu bug, because we can cherry pick that fix from svn
<lifeless> schierbeck: yeah I can imagine
<foom> surely it should be filed against upstream python so they backport it into the 2.5 branch...
<lifeless> foom: well they presumably already know that 2.5 doesn't have it, they committed it solely to trunk after all
<foom> lifeless: if they know 2.5 doesn't have it, and explicitly didn't backport it, I (as a python software developer) would be very unhappy to see it appear only in ubuntu python 2.5
<lifeless> foom: why?
<foom> going against the explicit stable release policy decision of upstream for no particularly good reason.
<lifeless> distros are more than a build engine
<foom> it's not like anyone writing software could ever depend upon that fix existing, seeing as how no other python 2.5 will have it.
<foom> so it provides no value
<lifeless> I would be very unhappy if ubuntu didn't carry patches in advance of huge numbers of upstreams
<foom> in advance is one thing, in opposition to is another
<lifeless> -> #ubuntu-policy or something
<igc> morning
<lifeless> I've got some code to write, sorry.
<foom> me too.
<RainCT> bug 191694 reported
<ubotu> Launchpad bug 191694 in bzr "bzr crashes commiting a branch from a directory with special characters" [Undecided,New] https://launchpad.net/bugs/191694
<foom> my only point was: it should be filed against upstream python to make sure they're aware. didn't want to get into an argument. :P
<lifeless> foom: my point was file it against ubuntu where the bug was observed; doko will do something sane from there.
<RainCT> (the title is not very good but I couldn't think of anything better..)
<lifeless> RainCT: thanks
<foom> lifeless: great. we can agree to that point. :)
<luks> ouch, some tests are failing is readlink returns unicode strings
<RainCT> lifeless: np
 * RainCT thinks that it would be better if some of you reported the bug in python as he isn't really understanding what's going on :P
<luks> using %r in diff output is probably not a good idea, anyway
<RainCT> well, good night
<lifeless> night
<ubotu> New bug: #191694 in bzr "bzr crashes commiting a branch from a directory with special characters" [Undecided,New] https://launchpad.net/bugs/191694
<abentley> schierbeck: Actually, the patch parsing / applying code lifeless was referring to is in Bazaar: bzrlib/patches.py
<schierbeck> abentley: thanks!
<hipertracker> Is there any Baazar plugin for Eclipse, Netbeans6 or TextMate?
<igc> poollie, jam, spiv: call?
<mwhudson> hipertracker: there's at least something for eclipse
<jam> igc: I don't want to talk to you, I just want to listen to the pretty music
<igc> it's prettier today than normal for some reason :-)
<igc> it's even bearable
<jam> igc: I'll just enter the leader code, and we'll get done with it
<pickscrape> Hi, does anyone know of a quick way to publish a fresh branch to a remote host?
<LeoNerd> bzr push ?
<pickscrape> The working copy is 384M, and the .bzr direcotry of my shared repo (containing just this branch) is 228M.
<pickscrape> It's taking *ages*.
<pickscrape> Well, it's taken about 40 minutes so far and the remote shared repo has reached 63M in size. Does that sound about right?
<pickscrape> I'm using bzr+ssh. I'm just wondering if there's a way to speed it up. For example, tarring it up and using scp would be much quicker, but I doubt that it would put things in the right place.
<LeoNerd> It should do
<pickscrape> Even taking into account the shared repository?
<LeoNerd> Oh.. hrm.. possibly not
<LeoNerd> bzr push it locally to another local dir, then tar/scp that
<pickscrape> Yeah, I'm thinking it's probably quicker to scp the raw WC to the server, and import and then branch locally to kick things off.
<pickscrape> Thanks for the idea :)
<pickscrape> My other question is, is it possible to do something like bzr branch <remote_url> <remote_url> to create a new branch remotely?
<mwhudson> hard to beat tar.bz2 + scp for the initial transfer
#bzr 2008-02-14
<lifeless> pickscrape: what format branch are you using ?
<lifeless> mwhudson: actually, its quite easy to beat that :)
<pickscrape> lifeless: default. Branch format strikes me as being a quite scary thing to mess with (coming from an svn/svk background here).
<Odd_Bloke> pickscrape: What version of bzr are you using?
<pickscrape> 1.1.0
<lifeless> pickscrape: bzr info will tell you
<lifeless> pickscrape: I want to know if it says pack-something
<lifeless> pickscrape: if it does, pushing over sftp rather than bzr+ssh will likely be much faster, for big pushes.,
<lifeless> jam: ping
<pickscrape> lifeless: Knit repository format 1
<pickscrape> I was actually using sftp before I tried bzr+ssh. It was running slowly too.
<pickscrape> Pushing locally on the server is going much quicker though (obviously)
<lifeless> you should upgrade to packs
<lifeless> _much_ faster
<lifeless> looking for review: http://bundlebuggy.aaronbentley.com/request/%3C1202953186.6790.187.camel@lifeless-64%3E
<lifeless> abentley: I have a use case to cherry pick against two branches simultaneously :)
<abentley> lifeless: err?
<ubotu> New bug: #191729 in bzr-svn "Initial svn+http repository not remembered" [Undecided,New] https://launchpad.net/bugs/191729
<lifeless> abentley: I have two branches which have pending merge requests on bb; I have a third branch based on both, which I'd like to send in for separate review
<abentley> I think the best you can do is merge one into the other and then generate a merge directive against that.
<abentley> I'm willing to consider the possibility, however slight, that this is not an ideal workflow for some people.
<lifeless> ;)
<lifeless> normally I would stack them that way
<lifeless> this was unplanned
<abentley> I'm not sure whether the notion of cherrypicks can be naturally extended to multiple bases.
<lifeless> so given A,B ->C
<lifeless> I want a cherrypick of C to have the unique lines added to C but not added to A or B
<lifeless> clearly it won't apply cleanly to just A, if I alter what B added in C, and vice verca.
<abentley> Yeah, I think I understand what you want.  I'm not sure what that would require for patch generation or merge application.
 * igc food
<abentley> lifeless: I think the technique used to do cherrypicks with knit and LCA merge could be extended to multiple bases.
<lifeless> wow
<lifeless> the vim packaging folk really don't like 'Just Works'
<lifeless> http://pkg-vim.alioth.debian.org/vim-policy.html/
<ubotu> New bug: #191731 in bzr-svn "Memory problems prevent branch of large svn repositories" [Undecided,New] https://launchpad.net/bugs/191731
<javamaniac> Hi
<javamaniac> someone knows an equivalent to "hg incoming" en bzr?
<javamaniac> in*
<Peng> javamaniac: bzr missing.
<Peng> javamaniac: It does both incoming and outgoing. See "bzr help missing" for args to only show one of them.
<javamaniac> ok, let's see
<Peng> javamaniac: If you're planning to pull, you can also do "bzr pull -v" to pull new csets and list them at the same time.
<javamaniac> Peng, in mercurial , there's a -p to show the patch of those "missing" changesets, I can't see something like that in bzr, How can I achieve  that?
<bob2> bzr diff branch_path
<mwhudson> bzr diff -r ancestor:branchpath is often more what you want
<pickscrape> n
<pickscrape> Sorry, wrong window :)
<lifeless> ok, I need to do some more upgrade infrastructure
<lifeless> tomorrow
<spiv> BzrDir.find_branches seems to eat a lot of memory.  (I've noticed this with bzr multi-pull and now the bzr-avahi plugin)
<jamesh> spiv: I used to have my own version of it in bzr-avahi
<jamesh> by using code from bzrlib, it is magically someone else's problem
<spiv> jamesh: :)
<spiv> I should play with heapy or similar and find out where the memory is going.
<vila> poolie2, poolie__ : hi. It looks like bzr-1.rc1.tar.gz and bzr-1.2 branch do not match
<poolie__> i think it was rejected
<poolie__> i'll check
<poolie__> i'm trying to fix bug 189915 at the moment
<vila> poolie__: kthks
<ubotu> Launchpad bug 189915 in bzr "bzr 1.1 dapper PPA debs FTBFS" [Critical,Confirmed] https://launchpad.net/bugs/189915
<jml> poolie__: you may find this site amusing: http://www.freerice.com
<jml> man, that reads like spam
<poolie__> rice rice baby
<poolie__> hm
<poolie__> refined carbs/handouts/banner adds/bizarro wristband campaigns/etc
<poolie__>    1. hoary means:
<poolie__>    2. urgent
<poolie__>    3. singsong
<poolie__>    4. gruesome
<poolie__>    5. ancient
<jamesh> 6. Linux Distribution
<AfC> 5
<Peng> Should patches that haven't been merged yet move their NEWS entries out of the 1.2 section?
<pygi> hi
<Peng> Oh no! I typoed a commit message! :(
<Parker-> then uncommit :P
<Peng> It's a few commits old.
<Peng> I never noticed, so perhaps no one else will, eh?
<Parker-> heh... yep...
<Parker-> and tyops aer cmmoon
<Peng> Yeah.
 * mvo_ sends a valentines card to bzr shelve/unshelve for being so nice
<pygi> hey folks
<pygi> how would I resolve a tag conflict?
<ignas> hi
<ignas> how do I get a changelog when comparing 2 branches? I want to get a list of changes present in one branch, but not in the other ...
<jelmer> ignas: bzr issing
<dato> ignas: missing, passing --mine-only or --theirs-only as appropriate
<jelmer> *missing
<ignas> thanks
<ignas> but it has no "-d" parameter it seems :/
<pygi> this tags stuff seems so weird ...
<pygi> solved
<ubotu> New bug: #191813 in bzr-webserve "Inventory: Pressing a binary file show binary data" [Undecided,New] https://launchpad.net/bugs/191813
<vila> ubotu: Don't Do That Then ! :)
<cr3> thanks folks for having created that bzr package for dapper :)
<ubotu> New bug: #191917 in bzr "bzr cvsps-import crashes with assertion error" [Undecided,New] https://launchpad.net/bugs/191917
<garyvdm> Hi - I'm trying to use bzr-svn for the first time. I'm geting this error: http://pastebin.org/19627
<garyvdm> What am I doing wrong?
<jelmer> garyvdm: use "bzr svn-push" if you're trying to create a new branch
<garyvdm> Ok
<jelmer> Whoops, looks like you're not trying to do that...
<garyvdm> Trying to create a local branch
<garyvdm> Not one on svn :-)
<garyvdm> ~/meld = init-repo --subversion
<jelmer> then you are trying to create a new branch in subversion
<jelmer> if you want to make a local copy, use init-repo --rich-root-pack
<garyvdm> Oh - ok
<jelmer> init-repo --subversion creates a subversion repository
<garyvdm> Thanks - its working now.
<james_w> poolie__: hi. I'm not sure if you did the upload to the PPA, but it FTBFS again.
<james_w> poolie__: from a quick glance it seems that you need to Build-Depend on python-all instead of python.
<james_w> poolie__: also, it seems that you may be using python-support, rather than python-central. If you have changed this then you should be aware that last time I looked the plugins and the core had to use the same system otherwise the plugins weren't registered.
<james_w> poolie__: if you already know all of this, or it wasn't you then my apologies.
<igc> morning
<poolie__> james_w, thanks, i was aware it had probably failed
<poolie__> https://bugs.edge.launchpad.net/bzr/+bug/189915
<ubotu> Launchpad bug 189915 in bzr "bzr 1.1 dapper PPA debs FTBFS" [Critical,In progress]
<poolie__> lamont says that python-central isn't in dapper
<lamont> poolie__: exactly
<dato> there was a patch for dapper by jeff licquia
<james_w> is python-support?
<dato> but it was so minimal when I read it that I don't know if it was correct
<dato> you *could* try to build the sarge backport
<poolie__> there is a patch on that bug from lamont
<poolie__> so can we switch it to python-support on all distros, or do they need to remain different?
<james_w> yeah, you could do that. However all plugins would have to be changed at the same time.
<james_w> (all packages of plugins I mean)
<lifeless> poolie__: are you using the bzr-packaging-teams packaging ?
<poolie__> I was trying to just uupdate from that
<lifeless> poolie__: if you extended my packages you are
<poolie__> but i have tried to use the same packaging across all distros, which is the problem
<poolie__> do they have different branches for each distro?
<lifeless> yes
<lifeless> distro release rather
<james_w> there is an etch-backports branch I think, but it doesn't have the changes you need.
<lifeless> sid & hardy are the same
<lifeless> and dapper and etch
<lifeless> I used the patch from the list to convert the hardy branch down to dapper
<dato> dapper != etch
<lifeless> dato: hmm, true; I'd actually have to go check my branches
<lifeless> poolie: point is - yes every distro code name had its own branch
<lifeless> poolie: where the deps and build stuff was the same I pulled between them, when it wasn't I merged changes.
<dato> personally I think not using nor pycentral nor pysupport would be best for dapper
<lifeless> too many negatives
<poolie> using neither you mean
<poolie> ok
<james_w> Couldn't it just be built for the default python in dapper?
<lifeless> james_w: dapper is pre the modern python packaging stuff entirely
<dato> right
<james_w> yeah, but I mean just don't even try and support more than one python.
<dato> so you just build it the old way
<dato> and it's much easier than sarge because python points to 2.4 and not 2.3, and docutils is already at 4.x
<dato> 0.4 I mean
<lifeless> poolie: spiv: ping
<spiv> igc: file:///usr/share/doc/python2.4/html/lib/standard-encodings.html
<spiv> lifeless: pong
<igc> thanks spiv
<lifeless> can we talk about the network protocol; I've sent mail but I have to assume there is some confusion reigning
<spiv> lifeless: sure
<spiv> lifeless: it looks like I was unclear in my mail
<lifeless> I read 'lets not do X because Y, where Y is unrelated'
<spiv> lifeless: by "interruption", I mean interruption by the sender, not the receiver.
<spiv> lifeless: i.e. "here's a body... *streams* -- Oops!  I just exploded, and am aborting the stream."
<spiv> lifeless: it's still all half-duplex.
<lifeless> spiv: which is precisely why I suggested have the tuple stuff exclusively after the body
<spiv> lifeless: but requests have the same issue.
<spiv> lifeless: they can also stream bodies, and should have a way to explicitly signal "oops, that's not a complete stream because I just blew up."
<lifeless> spiv: right, symmetry. do it the same way for both directions.
<spiv> lifeless: but requests can't have the body come before the verb, because that would force the server to buffer, because it wouldn't know what the body was for.
<lifeless> spiv: this is true
<lifeless> spiv: so noting that; the situation is not identical because the server doesn't have state but neither does the client
<lifeless> spiv: also the client may well be unable to finish the stream without additional structured data.
<lifeless> spiv: so perhaps saying entity: [*TUPLE|BYTES)+]
<spiv> lifeless: you mean rather a body being just a series of byte chunks, make it optionally more structured?
<lifeless> no, I mean making the entire message a series of things
<lifeless> where each thing is either a tuple
<lifeless> or a bytestream
<spiv> That sounds like an over-generalisation to me.
<lifeless> perhaps
<lifeless> but you are proposing
<lifeless> TUPLE [BYTES, TUPLE]
<lifeless> already
<lifeless> or something like that
<spiv> I'm worried that sort of free-form structure would require more complexity than we need...
<spiv> Something like that.  Basically it's still ARGS [BODY], with the possibility to abort the BODY.
<lifeless> which means the body is delimited
<lifeless> and you wanted to add error details when its aborted
<spiv> And so far the ARGS + BODY idiom has fit pretty well with what we've wanted to do.
<lifeless> which means another ARGS
<lifeless> :)
<spiv> Right, those are some of the details.  I'm just saying the protocol still conceptually is directly related to what the code does and expects.
<poolie> i can't parse
<poolie> <lifeless> spiv: so noting that; the situation is not identical because the server doesn't have state but neither does the client
<spiv> [(TUPLE|BYTES)+] basically suggests to me a whole extra layer.
<poolie> and i'm not sure how that would map into the api
<poolie> at the moment, it is: after getting the header, you can read the bytes, but that
<poolie> and each call to do so can either 1-return bytes 2-return eof 3-raise an erro
<poolie> r
<poolie> this seems reasonable for both client and server
<poolie> hm
<poolie> i guess i can see how the more general structure would work
<poolie> allowing the receiver to say, stream some bytes, now read a tuple, etcr
<lifeless> I don't seee TUPLE [BYTES[TUPLE]] as being any harder than (TUPLE|BYTES)+
<poolie> i guess we could have messages saying, um
<poolie> or message types
<spiv> Well, we can always use streamed bodies for complex structured data like that.  I don't know that that's a common enough case to make it be the overall protocol.
<poolie> start of message, parameters, bytes, error, end of message
<spiv> Adding flexibility to the protocol has the downside that now you expect the request handlers and response handlers to be able to cope with that flexibility.  *Maybe* we can hide most of that in the default base class for request handlers (although we don't really have such a thing for response handlers), but I'm not sure.
<poolie> if we had the messages marked that way, and the receiver knew what they expected, then it could be an error for them to get parameters when they expected bytes
<spiv> poolie: we already have "start of message, parameters, bytes, error, end of message", we call them requests ;)
<poolie> so i think robert is saying
<poolie> why not make that ordering a convention rather than a requirement
<poolie> so that the api can possibly send more parameters after the body, or some such
<poolie> and i guess it'd be an error if the receiver was not expecting it
<spiv> I guess because I'm not sure that we'll actually have a use for this complexity.  We can always send bencoded structures (and already do), or multiple requests.
<poolie> i share that uncertainty
<spiv> And degrees of freedom don't come for free, so my inclination is to say YAGNI.
<poolie> here is one case, which has an analog in http
<poolie> we want to send the contents of a file, and afterwards send its hash for verification
<poolie> the sender wants to compute the hash as it's streaming the file
<poolie> it would be possible for it to encode that into the stream, but that seems a bit redundant since the protocol already has markers for the byte steram
<spiv> Hmm.
<poolie> this is a case where the receiver might reasonably read the stream, then ask to read more parameters
<spiv> That's true, but I still wonder how common it really is?
#bzr 2008-02-15
<poolie> well
<poolie> i'm not sure 'common' is the right measure, compared to
<spiv> Maybe there's something involving graph logic that already would help bzrlib?
<spiv> I mean,
<poolie> if there are cases where we need it, how much trouble or friction or
<spiv> maybe there's already an operation bzrlib does, or would like to do, that could benefit from this?
<lifeless> sory about interruption
<lifeless> hardy is not _that_ stable
<lifeless> I'm saying that the structure I understand you to be heading towards is hand coded
<lifeless> but needs on the wire the exact same degree of encapsulation
<lifeless> so why not just define the encapsulation, then let the client and server use them as desired
<spiv> Basically, the tradeoff is at the moment the encapsulation encoder/decoder has a pretty simple interface with the objects that use it, and there's a single place that knows things like "this message part is a body".  If we generalise, we push that work to the individual message handlers.
<spiv> I guess that's manageable, but I'm also not sure it's work that we'll get much benefit from.
<lifeless> well
<lifeless> you could make sure the wire protocol is generalised
<lifeless> and then only add api complexity as needed
<spiv> Hmm.
<lifeless> long as the error-handling cases the protocol object knows how to eat the entire entity we're good to extend it later.
<lifeless> (extend in the python code I mean)
<lifeless> so START, TUPLE|BODY+, END
<spiv> Right, similar to the container format...
<lifeless> where TUPLE and body are both self delimited
<lifeless> and BODY is able to be ended_complete and ended_incomplete
<lifeless> lol https://pqm.bazaar-vcs.org/ refuses to show in ff3
<spiv> And if a body is ended_incomplete, then it can be followed by another TUPLE?
<spiv> (as a convention)
<lifeless> right
<lifeless> but even if not we'll know it was incomplete
<lifeless> and can error regardless
<spiv> Well...
<spiv> that's the sort of thing that bugs me :)
<spiv> More options == more cases == more tests & work :P
<lifeless> ok
<lifeless> up to you
<lifeless> I've exhausted my ideas on this, but it seems pretty clear to me that there are different layers here
<spiv> It's not so much that that one part is a big concern, but it's the sort of thing that we're enabling with this plan.
<jelmer> lifeless: wtf
<jelmer> lifeless: maybe it was just bad timing
<jelmer> but going to pqm.bazaar-vcs.org just crashed my kernel :-)
<lifeless> jelmer: LOL
<poolie> !!
<spiv> Wow.
<lifeless> jelmer: get a new kernel
<poolie> Before You Die, You See...
<jelmer> maybe it'll work better if I run a kernel out of bzr instead of out of git...
<poolie> lifeless, i think it's a good point about the protocol
<poolie> spiv, lifeless, i think we should allow for it in the protocol doc
<poolie> the actual encoding iirc would already support this
<spiv> brb, fixing a KnitCorrupt in Mary's PhD branch...
<mwhudson> ouch
<spiv> Newlines in filenames leads to broken inventory.knit...
<radix> it seems the dapper packages of bzr on ppa don't work? they're complaining about not having python2.5 when I try to install them
<poolie> radix, yes, it's bug 189915, i'm working on it
<radix> poolie: cool, thanks
<radix> fwiw, the reason it's not working for me is   bzr: Depends: python (> 2.5) but 2.4.2-0ubuntu3 is to be installed or
<radix>                 python-celementtree but it is not installable
<radix> which doesn't seem to be exactly what bug #189915 is talking about
<ubotu> Launchpad bug 189915 in bzr "bzr 1.1 dapper PPA debs FTBFS" [Critical,In progress] https://launchpad.net/bugs/189915
<poolie> lifeless, what is the best address for the bzr packaging team?
<poolie> ^branch
<poolie> http://bzr.debian.org/pkg-bazaar/bzr/ubuntu/ ?
<lifeless> http://bzr.debian.org/pkg-bazaar/bzr/unstable/
<poolie> ok
<poolie> the changelog for the pakcage i took from bazaar-vcs.org is somewhat diverged from that
<poolie> starting with your "New bazaar-vcs.org build" on 3 dec
<lifeless> poolie: yes, merged numerous times; but theres nothing in the bazaar-vcs.org devel-distro-release packags that wasn't sent back to bazaar-vcs.org
<lifeless> possibly some dependency differences
<lifeless> and the dapper package has the patch from the bzr list
<lifeless> abentley: ping
<lifeless> abentley: I'm looking for the branch nick on bb, I can't see it
<LaserJock> anybody around who has experience using the cvs plugin for bzr?
<abentley> lifeless: I think it's not there.
<lifeless> LaserJock: do you mean cvsps-import ?
<abentley> I assume you want the branch nick from the last-committed revision?
<LaserJock> yes I guess that's the one
<abentley> We do have the source branch location, if the user provides it.
<LaserJock> lifeless: I'm assuming I can use cvsps-import to track a CVS repo
<lifeless> abentley: yes, I'd like it to be visible
<lifeless> LaserJock: I don't know if it can do incremental or not; it certainly doesn't have the logic to handle all the idiocies people can do to cvs like cscvs does
<LaserJock> well, I've been using git-cvsimport and it seems to be working well
<LaserJock> I'm just trying to figure out the bzr equivalent
<lifeless> LaserJock: well cvsps-import is the plugin to examine
<lifeless> I've used it for one-shot conversions very successfully
<LaserJock> k
<LaserJock> I have about 14 different VCS repos in CVS, SVN, bzr and I thought I might give it a go at trying to just use bzr for everything
<LaserJock> Riddell keeps saying it's the only way to go :-)
<lifeless> LaserJock: riddel is right :)
<lifeless> bzr-svn will get your svn stuff beautifully
<lifeless> for CVS, just one-shot convert and never look back
<LaserJock> well, I don't own the CVS repos so I'll have to keep updating periodically
<lifeless> ok
<lifeless> have a look at it; or use the launchpad cvs service
<LaserJock> hmm
<LaserJock> actually one of them is already in launchpad
<abentley> I wonder how hard it is to 0wn a CVS repo
<lifeless> its ok security wise, if you like crunchy shell
<thumper> what's a better merge type to use for criss-cross merges (in bzr 1.1) ?
<spiv> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01212.html
<spiv> thumper: --lca
<thumper> spiv: so `bzr remerge --lca`?
<spiv> thumper: yeah.
<thumper> 7 conflicts -> 2 conflicts \o/
<thumper> both of which were entirely valid
<thumper> when is --lca becoming the default?
<spiv> abentley: ^
<poolie> lifeless, how can i avoid dpkg-source complaining about the binaries in the debian/.bzr directory?
<lifeless> -x .bzr
<poolie> ok, i have to give that every time?
<lifeless> or use bzr builddeb to do most of the machiner for you
<lifeless>    bzr builddeb --working --builder="pdebuild-$distro --override-config"
<lifeless> thats how I built the packages
<poolie> so to do that i should have the source in one branch, and the debian/ directory in another branch checked out below it?
 * poolie reads the maunal
<poolie> lifeless, so it looks like people are using it in "merge mode", since the packaging is alone in a branch?
<abentley> thumper: I would give it another release cycle.  See I got this new job, and it's been a lot to learn all at once...
<abentley> Unfortunately, there's some work needed before it's a complete replacement for merge3.  It doesn't do reverse-cherrypicks, and there's an edge case where it doesn't give a conflict when it should.
<lifeless> later all
<poolie> have a good weekend
<abentley> lifeless: later
<lifeless> poolie: you have mail; if you want a call ring now :)
<poolie> thanks
<poolie> no i don't think so
<poolie> am just learning more about builddeb
<appcine> hi! getting "bzr: warning: unknown encoding . Continuing with ascii encoding." every time I call bzr.
<appcine> echo $LANG reports C
<appcine> LC_ALL is not set
<appcine> tried exporting LANG as sv_SE.UTF-8 too, still the same message
<appcine> Mac OS X 10.5.2
<Debolaz> Eww, UTF-8
<Debolaz> Latin1++
<ubotu> New bug: #188058 in bzr-gentoo-overlay "Launchpad transport error installing bzr-vimdiff-0_pre17 (dup-of: 181945)" [Medium,Incomplete] https://launchpad.net/bugs/188058
<appcine_> So, I've pushed my source to my server -- bzr update doesn't work, what do I run to initialize?
<kedmccabe> What's the best/recommended way to install bzr on OS X; easy_install or macports?
<appcine> kedmccabe: Probably what you're most used to working with
<appcine> I used ports .. because, well I use it for lots of things and it's easy to keep stuff updated.
<rotty> how's the support for cherry-picking these times? bzr still does not track them, right?
<dato> nope
<rotty> :-/
<lifeless> rotty: will be discussing this in the up coming sprint
<rotty> so it could be implemented in the foreseeable future?
<appcine_> How do you ignore all files in a certain directory? Like bzr ignore dir/*, but that adds all specific files to the .bzrignore file .. should I manually edit the file?
<appcine_> :)
<luks> I think bzr ignore 'dir/*' should work
<luks> or "dir/*" on windows
<luks> (to disable the * in the shell)
<appcine_> sweet
<appcine_> worked, thanks :)
<appcine> can you remove all ".svn" directories from your project somehow?
<appcine> I added them, and the ingored them .. now I want to remove them :P
<Peng> appcine: If you're on *nix or something, that would be easy. 'find -name .svn -execdir bzr rm {} +' or something.
<rotty> lifeless: I have an ideas for a new feature: tracking the currently-checked-out revision, so when you do "bzr get -r FOO", a subsequent "bzr status" will compare against the revision FOO and not HEAD
<rotty> does that make sense?
<dato> jelmer: ping?
<jelmer> dato: pong
<dato> jelmer: I have a situation, and I'd like to know whether rebase could help. well. situation. I commited some stuff over a revision that I didn't thought it was there...
<dato> how much would I need to write to make rebase re-commit the good ones on top of $BAD-1
<dato> I don't mind a dirty+ad-hoc solution
<jelmer> well, there's also the "replay" command that's part of rebase
<dato> oh
<dato> ooh
<jelmer> if you check out $BAD-1 then you can just run "bzr replay -r<revision-to-replay>"
<dato> right
<dato> thank you
<jelmer> for $BAD+1
<dato> I get a conflict, whereas I think I shouldn't get one
<dato> $BAD touches foo1.py
<dato> and $BAD+1 is a merge that does not touch foo1.py
<dato> ?
<dato> jelmer: ^
<fullermd> rotty: Err?  get == branch; it does do that...
<rotty> fullermd: but "revert -r" doesn't, does it?
<hallu> hello, i'm running into a repository compatibility problem with bzr hosted on launchpad.
<fullermd> Well, what you'd want for that use case isn't revert, it's "update -r".
<hallu> i used svn-import to create a new branch on my machine.
<fullermd> Which comes with a minor hitch.
<hallu> then i push it onto launchpad
<hallu> but bzr co complains that KnitPackRepository is not compatible with RemoteRepository...
<rotty> fullermd: according to "bzr update --help", update doesn't have that option "-r"
<fullermd> rotty: That's the minor hitch   8-}
<hallu> i should say: I push it *first* and that works, then I try *bzr co* and that fails.
<dato> oh well, I used WorkingTree.commit for $BAD+1. replay did $BAD+2,3 fine
<rotty> fullermd: is this implemented in bzr HEAD?
 * fullermd shakes his head.
<fullermd> rotty: https://bugs.launchpad.net/bzr/+bug/45719
<ubotu> Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,Fix committed]
<appcine> Peng: Ah, yes. I'm on unix. Something like the find-command might work, but {} doesn't print the path to the file .. know how to do that? :)
<Peng> appcine: It doesn't? What? Depending on your shell, you might need to escape it.
<appcine> find . -name .DS_Store -execdir echo {} +
<appcine> prints: .DS_Store .DS_Store .DS_Store
<appcine> bash on os x
<appcine> ah
<Peng> appcine: Yeah, exactly. execdir 'cd'es to the directory and then executes it.
<Peng> appcine: It's supposed to be safer. Shrug.
<appcine> Peng: Hmm, hehe.. let me try again .. bzr reported that .DS_Store didn't exist
<appcine> with --exec it worked
<appcine> Peng: Nevermind me. I'm just sloppy. It works just fine.
<appcine> Thanks for the tip
<rotty> fullermd: where can I get a recent version of this patch?
<rotty> (the repos mentioned in the report don't apply to current HEAD anymore)
<fullermd> I don't think there is one.
<rotty> :-(
 * fullermd ponders.
<fullermd> I guess poolie's long since gone for the night...
 * lamont wonders when bzr 1.2.0 will hit the ppa
<LarstiQ> lamont: it did yesterday
<LarstiQ> or well, the buildds and then failed
<lamont> it's not there....
<LarstiQ> so eh yeah, can't use it yet :)
 * lamont notes the lack of a debian directory in the tarball, too
<LarstiQ> lamont: which one, upstream?
<lamont> launchpad.net/bzrtools/...
<LarstiQ> I'm not clear on what you mean, but fwiw there are something like 4 different debian dirs needed
<LarstiQ> since dapper/etch/sid are all different enough that there is no universal packaging (yet?)
<lamont> most people tend to package something that's the latest...
<LarstiQ> as the Bazaar project, debs for all those distributions need to be made
<LarstiQ> anyway, I haven't been involved in that area for a while now
<lamont> heh.  it took longer to test the backport to dapper/edgy than it did to do it.
 * fullermd wonders whether 1.2 is officially released.
<fullermd> I see the file, but I haven't seen any announcements.
<ubotu> New bug: #145811 in nautilus-python "python-nautilus: Feisty: Python script's methods seem to be not called by extension." [Undecided,Fix released] https://launchpad.net/bugs/145811
 * rotty is annoyed that the "update -r" patch has been abandoned
<fullermd> Here's your number; there's the line   :p
<rotty> unfortunatly, I'm not able to forward-port the patch, as I don't have knowledge of bzr internals
<Peng> I have an entirely off-topic quandary: I created a GPG key for myself 5 days ago. I had a copy of my private key on a server I don't own the whole time. Should I be paranoid and revoke it or not? I'm not using it for much so it would be no big deal if I did revoke it.
<fullermd> I s'pose it depends on how much you trust whoever has root on it.
<Peng> Also, if I ever got a VPS, I might need to put the private key on it, which would be just as bad...
 * fullermd shrugs.
<fullermd> Any hardware that anybody else ever has physical access to is insecure and untrustworthy if you're paranoid enough.
<Peng> I'm trying to find the right level of paranoia.
<johnny> and the changelog needs to be updated for 1.2 too..
<radix> is there any recent .deb of bazaar that works on dapper?
<Peng> radix: https://launchpad.net/~bzr/+archive ?
<Peng> Huh, Hardy and Dapper are the only ones that have had their 1.2rc1 debs built.
 * Peng wanders off.
<radix> Peng: the dapper debs from ppa are broken
<radix> they depend on python2.5
<Peng> Oh.
<Peng> Nice.
<Peng> I dunno nothin' then.
 * Peng wanders off.
<Peng> Sorry I couldn't help.
<jdong> Are the bazaar-vcs.org branches going to be packs?
<jdong> I notice that they're still dirstate/knits currently
<beuno> jdong, bzr.dev has been in packs for a while now
<beuno> beuno@beuno-laptop:~/bzr_devel/bzr.dev$ bzr info http://bazaar-vcs.org/bzr/bzr.dev/
<beuno> Standalone branch (format: pack-0.92)
<jdong> beuno: what? no way
 * jdong questions his sanity
 * beuno questions it too  :p
<jdong> beuno: oh I see my idiocy
<jdong> beuno: I looked at bzr.1.2
<jdong> not bzr.dev
<beuno> jdong, I think 0.92 and on have been in packs on bzr.dev. Especially since at that poing packs<>knits operations where painfully slow
<jdong> WOW the performance difference with packs over HTTP is very noticeable
<beuno> jdong, yeap, lifeless and jam did an amazing job at it  :D
<beuno> and I understand the smart server has improved greatly too
<jdong> yeah I'm impressed at dumb http alone
<jdong> I haven't branched something big from HTTP since packs came about
<beuno> I think the "less amounts of round-trips" was the key
<jdong> right, that's always been the case
<beuno> gazillion knits vs a dozen packs
 * beuno wonders why the 1.2 branch is in knits...
<beuno> and no poolie around...  :/
<jdong> beuno: yeah the 1.2 branch took nearly 5 minutes to get, while I just grabbed dev in under a minute
<jdong> and looking @ how it's 85MB, most of that time would've been simply network transfer
<beuno> jdong, I'll send an email to the list and see if it just got forgotten or if there is a good reason for it
<jdong> beuno: cool
<beuno> thanks for the heads up!
<jdong> anytime
 * jdong reconciles bzr.dev for fun
<beuno> jdong, if it's in packs, it should be fairly fast. Knits, on the other hand, might take a while. I have 3gb branch that took 40+ hours to reconcile on a AMD 4000+ dual core
<jdong> beuno: yeah right now the packs are taking over 10 min to reconcile, looks CPU bound
<jdong> oh well, i twas for fun anway
<beuno> jdong, you can also run "bzr check" if you feel like making the CPU sweat a while  :p
<mw> someone should change the topic to mention 1.2
<johnny> and add a changelog entry
<johnny> on the site
<mario_limonciell> is there no way to pass bzr through an authenticating proxy?
<mario_limonciell> it would seem according to bug 83954 that the support should be there
<ubotu> Launchpad bug 83954 in bzr "Error while using "bzr branch" through proxy" [Undecided,Fix released] https://launchpad.net/bugs/83954
<ubotu> New bug: #156299 in bzr "bzr bash completion error (compgen: --: invalid option)" [Wishlist,Confirmed] https://launchpad.net/bugs/156299
<mtaylor> GARRRRR
 * mtaylor hates that Branch.open_containing() returns a tuple and not a branch. 
<mtaylor> just FWIW
<treeform_> hey my network is just awful but i need to copy a big bzr repo (300mb) to a server it always disconnect while doing it
<treeform_> is there a way to zip up the repo and rsync it there?
<beuno> treeform_, "pull" has resume integrated
<beuno> you can of course just rsync the folder
<beuno> and/or zip it
<beuno> you don't need anything special
<treeform_> beuno, does push has resume integrated?
<beuno> treeform_, I'm not 100% sure, but I don't see a reason why not
<treeform_> it always errors out with a python stack trace so i think it bzr just crashes
<beuno> treeform_, what version of bzr are you using?
<beuno> if it's spitting out a traceback it should be a bug
<treeform_> 1.1
<treeform_> sorry i would post the trace back but i dont have it
<beuno> treeform_, would you happen to have a traceback handy that you can paste somewhere?
<beuno> ah, right
<treeform_> i will run it again just wait about 10 min
<beuno> well, just plain rsyning the dir will work just fine
<treeform_> but the dir is about 600mb
<treeform_> with the .bzr 300mb and the contents is 300mb
<beuno> treeform_, can you run "bzr info" and see what repository type it is?
<beuno> treeform_, I suppose you can rsync the .bzr directory and then just do "bzr revert"  (which is sort of what bzr branch would do)
<beuno> zip up .bzr, rsync that, unzip, "bzr revert"
<beuno> (I'm sure there are better solutions though)
<treeform_> as long as that works
<treeform_> "Standalone tree (format: pack-0.92)"
<treeform_> oh my format is lower version
<beuno> treeform_, that's the latest version
<treeform_> i been using bzr since .14 and never had reasons to upgrade but it looks like i did at .92
<treeform_> oh ok
<treeform_> i think i needed to upgrade it because some one could not read it
<fullermd> That seems unlikely...
<beuno> treeform_, if they have a pre 0.92 version than they might not be able to read packs
<treeform_> ok but i am up todate?
<beuno> treeform_, if you have bzr 1.1 and are using the packs repository, yes
<treeform_> ok thanks
<beuno> np
<fullermd> 1.1?  Jeez, that's SO yesterday...
<treeform_> fullermd, i should upgrade?
<beuno> fullermd, :p
<beuno> treeform_, 1.2 is out _today_
<beuno> so 1.1 is _yesterday_
<beuno> upgrading is always recommended, but you're good at 1.1
<treeform_> oh i just installed 1.2 on the server
<treeform_> that is how it crashes http://dpaste.com/35397/
<beuno> treeform_, it says you're using bzr 1.0
<beuno> and, a release candidate
<treeform_> ok 1.2 it is
<beuno> I'd recommend upgrading to at least 1.0 final
<beuno> treeform_, your traceback says: bzr 1.0.0.candidate.1 on python 2.5.1.final.0 (linux2)
<treeform_> yes it does
<treeform_> i am sure i am wrong
<treeform_> grr installing it also fails http://dpaste.com/35399/
<treeform_> i got my current bzr is the latest in my repos
<rthalley> Assume we have a centralized shared repository for product foo.  directory "foo" has been bzr init-repo'd.  we then make branch "foo/head", and do work.  Now, getting reading for a release, we bzr branch foo/head foo/release-1.0.  Question: is there any way to see what branches are available within foo?  (within bzr, that is...)
<mtaylor> rthalley: not that I know of
<mtaylor> rthalley: but a simple ls of foo will give you some idea
<vin> how does the bzr_access script work? I've added set up the .ssh/authorized_key file. Do I just invoke the script with the appropriate parameters?
<abentley> rthalley: bzrtools provides a "branches" command that lists the branches under a given location
<rthalley> thanks, that's handy.  now a "best practices" question...  let's say we now finish foo-1.0 and ship it.  do I tag foo/release-1.0 to indicate the version that was released?  Do we worry about people still being able to commit to foo-release-1.0?
<jdong> is it clean to clean .bzr/repository/upload by hand or is there a tool for it?
<jdong> s/clean/safe/
<mneptok> jdong: sounds like my dating career
<jdong> mneptok: that probably explains the global shortage of nitrile gloves :)
<jdong> some little developing conscience in my head is telling me I shouldn't go into .bzr with /bin/rm and whack out things I don't think belong :D
<foom> whatcouldpossiblygowrong
<jdong> lol well ASS-U-ME-ing that nothing is uploading to the location, I would expect the 35MB of packs in upload to be simply in-transit cut-connection junk
<abentley> jdong: you can't break your repository by removing the contents of upload.
 * jdong saves this chat log ;-)
<abentley> If someone was in the middle of uploading, you might cause their upload to fail with a nasty error.
<jdong> awesome
<jdong> this one branch I have, I regularly commit to it via a crappy connection... it's nearly double its pristine size because of cruft in upload
<jdong> I'm wondering if bzr should have a command for dealing with cruft like that?
<abentley> Well, perhaps robert can fix that, but it's not an open-and-shut case like obsolete-packs.
<jdong> granted, else it would've been naturally fixed already
<jdong> btw if you haven't heard yet, packs rock :)
<jdong> I am astounded by the performance difference over plain HTTP
<jdong> now if there's only a way for LP to upgrade all branches to packs rather than me having to sftp them.
<abentley> Yeah, I did see your talk in the scrollback.
<jdong> yeah, you guys really came through for me. That was just about the last complaint I had about bzr :)
<abentley> jdong: You would not believe how snowed-under the launchpad-bazaar team is.
<abentley> I don't think we'll have time for nice-to-haves in the near future.
<jdong> I can imagine :(
<jdong> oh well scrape-and-loop time :)
<jdong> if there's one skill I've learned in my time around Ubuntu, it's how to abuse Launchpad :)
<abentley> But create a blueprint, and then we'll at least have it in the system.
<jdong> yeah, I'll do so in a sec
<fullermd> Seems like "smart server upgrade verb" would fill that niche pretty well.
<jdong> well the thing is...
<jdong> I don't think $average_lp_user knows or cares what the heck a pack is.
<jdong> and I don't think people are aware in general of this massive speedup. LP should be more active in telling owners of branches to upgrade to packs
<abentley> Where would you suggest we tell people about packs?
<mtaylor> when was rich-root-packs added?
<lifeless> jdong: yes it should and I think there is a bug open for htat
<lifeless> mtaylor: 1.0 IIRC
<lifeless> mtaylor: bzr help formats or so should say
<lifeless> also bzr should start nagging soon
<mtaylor> lifeless: thanks
<beuno> anyone up to helping me brainstorm what tests I should include with the automatic plugin thingie?   I've got working code and would like to strap on the tests and send to the list for initial review
<abentley> beuno: You should test all the commands you add, and the major functions you add.
<abentley> I'm not sure whether you're doing network stuff.  That can be annoying, but you should be able to run your own server if necessary.
<beuno> abentley, the problem is that I'm not actually adding any commands at this point, just catching unknown commands and checking to see if another plugin provides it
<abentley> Okay, so you should be testing the command-line functionality you've added.
<beuno> abentley, right, I got that far. The question is a bit more specific. I should make the test execute a command that I know will be caught as a plugin and test if the output is correct?  Maybe also commands that I know will be unknown and make sure they are still unknown?
<abentley> Yes.
<abentley> You don't necessarily have to do exhaustive tests of the commandline.
<abentley> But that's pretty key functionality.
#bzr 2008-02-16
<abentley> In general, you want to know that the commandline works, and that the library stuff is well-implemented.
<beuno> abentley, uhm, right. I'll take the plunge than
<beuno> thanks  :D
<abentley> np.  Got to go.
<vinc456> hi, i'm trying to use the /contrib/bzr_access script to limit user access. The script successfully blocks users from connecting to the shell account and upon branching, authentication is successful
<vinc456> but after Secsh channel 1 opens, i get an error "bzr: ERROR: Unable to start sftp client ucalgary.hopto.org:9922; EOF during nego"
<vinc456> tiation
<vinc456> any idea how this i can fix this?
<Peng> bzr_access and sftp? I thought bzr_access was only for bzr+ssh.
<vinc456> oh that may be it, i will do some more investigating
<vinc456> ok that fixed it, thanks
<Peng> I guess bzr_access should handle sftp better though.
<abentley> lifeless: BB now shows the last branch nick just above the commit messages.
<gioele> hello
<lifeless> abentley: thank you!
<ubotu> New bug: #192365 in bzr ""bzr plugins" error: unexpected keyword argument 'verbose'" [Undecided,New] https://launchpad.net/bugs/192365
<gioele> is there a way to show the diffs along with the messages in bzr log?
<dato> not at the moment, no
<dato> I also miss it
<mtaylor> wow. bzr is seg-faulting on me
<jdong> whee, just finished upgrading all my LP branches to packs :)
<RainCT> Hi
<RainCT> Is it possible to ignore *everything* except the files in a certain directory?
<RainCT> (if you only want to have that directory versioned but don't have the .bzr dir inside it)
<beuno> RainCT, you can only version stuff that's inside the bzr directory
<james_w> RainCT: I'm not sure but set .bzrignore to * and then add the directory you want may be the way.
<james_w> RainCT: there is also regex support in .bzrignore I think, so having a negative regex of the directory name may also work.
<RainCT> * works, thanks
<awilkins_> Has anyone seriously tried running Bazaar in IronPython?
<kedmccabe_> So wait, is 1.2 out or not
<jelmer> kedmccabe_: There is a RC out
<kedmccabe_> Oh.  The download page says that the current stable version is 1.2, and that's what easy_install grabbed.  But, bzr-svn seems to be angry if you try it with 1.2
<jelmer> ahh, I guess it's out already then
<jelmer> Yes, I haven't released a bzr-svn compatible with bzr 1.2 yet
 * awilkins_ refrains from upgrading
<pygi> hello folks
<pygi> what's the status of bzr-webdav writing plugin?
<johnny_> can somebody update the bzr changelog link for 1.2?
<kedmccabe> Is it recommended to run bzr-svn against svn trunk, or svn's 1.5.x branch?
<kedmccabe> it seems to fail an assertion when run against trunk, at least on Leopard.
<jelmer> kedmccabe: What sort of assertion?
<kedmccabe> http://pastebin.com/d20b7afc3
<kedmccabe> gc stuff
<kedmccabe> I've been mostly following the OS X 10.5 install instructions, though if I run the perl scripts against bzr-svn it doesn't even recognize https as a valid branch
<jelmer> kedmccabe: I don't think I've ever seen that error before
<kedmccabe> Sweet.
<kedmccabe> I'll try it against svn-1.5.x and see what happens.
<jelmer> kedmccabe: What exactly do you mean by "doesn't recognize https as valid branch" ?
<kedmccabe> Just spits out "Not a valid branch" if I try to branch from the same URL.
<kedmccabe> or "Not a branch"
<kedmccabe> brb
<jdong> awilkins: I've tried doing it (ironpython) before, I didn't put too much effort but it seems to run slower and took A LOT of UTF-8 coercing to even get bzr rocks to work
<jdong> though the performance issues could've been entirely my fault
<lifeless> jdong: hmm, we're very careful to keep unicode and byte strings separate; it shouldn't need any coercing unless its doing something fundamentally not-python.
<jdong> lifeless: no no I think it's just not 100% cpython compliant yet
<mathrick> hiya
<mathrick> http://www.pastebin.ca/906662
<mathrick> I get this crash
<mathrick> bzr.dev updated 2 minutes ago
<mathrick> is that known?
<lifeless> I would guess a file whose name is invalid in your locale's encoding
<lifeless> try LANG=C bzr rm --keep Downloads
<mathrick> lifeless: ah, lemme try that
<mathrick> lifeless: however, my locale is UTF-8, and the error talks about ASCII
<mathrick> yep, still crashes with C
<lifeless> mathrick: yes, it talks about ascii cause its transcoding
<mathrick> lifeless: well, hmm, LANG=C is of no help
<lifeless> hmm
<lifeless> well, please make sure there is a bug; you can run with BZR_PDB=1 to drop into a debugger and figure out what path is causing the problem.
#bzr 2008-02-17
<mr-rus1> how to I checkout an svn branch/trunk using ubuntu bzr?
<mr-rus1> bzr-svn doesn't exist and I can't find commands on the website for what to do.
<jelmer> mr-russ: ? ubuntu has bzr-svn
<mr-russ> I installed bzr-svn package, but there is only a bzr command
<jelmer> ah
<jelmer> bzr-svn allows the regular bzr command to access svn urls
<mr-russ> ah, then I did have it sort of working.
<mr-russ> how then do I commit without committing to svn, and only commit to the bzr tree?
<jelmer> mr-russ: If you create a standalone branch it won't automatically commit to svn
<mr-russ> ah, so you need to pass that as a parameter.
<jelmer> ?
<mr-russ> Unfortunatley I'm too new at bzr altogether for this to be as easy as it might be.
<jelmer> if you create a branch by running "bzr branch svn://..." it won't automatically commit to svn
<mr-russ> I'm using https://  I hope that doesn't make a difference.
<jelmer> no
 * mr-russ waits for it to download to see how we go at attempt 2.
<mathrick> mr-russ: bzr branch off an SVN repo is the same as a branch off any other repo, it's independent and separate from the original branch
<mr-russ> for some reason my first attempt committed to svn.  but it doesn't now.
<mr-russ> thanks for the help.
<mr-russ> I'll now work out how to commit the changes to svn.
<james_w> mr-russ: if you are now using the result of "branch" then you only commit locally. Use "bzr push" to move the changes to svn.
<james_w> see "bzr help bind" if you wish to make it default to commit to both.
<mr-russ> a basic tutorial on the subversion page would be quite helpful.  especially for those of us coming from SVN.
<mr-russ> because bzr push  doesn't automatically put the tree back in the same place you got it from.
<james_w> mr-russ: to which subversion page do you refer?
<mr-russ> http://bazaar-vcs.org/BzrForeignBranches/Subversion
<james_w> and what do you mean by that statement?
<mr-russ> coming from svn, when you checkout something.  when you hit svn commit, it commits to the same svn tree.
<mr-russ> bzr push to an svn tree MAKES you specify the location.
<mr-russ> I would have expected it cached as the "default"
<mr-russ> But that is just my gut expectation as an SVN user.
<jelmer> mr-russ: bzr does do that if you used "bzr co"
<jelmer> it doesn't when you use "bzr branch"
 * mr-russ needs to read more about how to use bzr.
<mr-russ> and bzr co commits straight to the SVN repository.
<james_w> mr-russ: and after the first bzr push then it will use that location by default next time, so it should be a one time thing.
<mr-russ> ah.
<mr-russ> I'll read through the whole bzr manual and see how I go from there.
<mr-russ> thanks very much for your guidance all.
<james_w> mr-russ: no problem, feel free to ask any more questions.
<c1|freaky> hi all. how can i checkout a repository without any history or other files, just as if i would have downloaded a package or smth.?
<Parker-> export?
<c1|freaky> ok
<c1|freaky> thank you
<c1|freaky> doesnt work can someone give me an example
<c1|freaky> ?
<Parker-> you can only export branch... not repository
<james_w> c1|freaky: also checkout --lightweight
<james_w> that gives you slightly more than export, but no history.
<james_w> c1|freaky: bzr export to-this from-URL-of-branch
<c1|freaky> can i only export one subdirectory of a project
<james_w> no, that's not supported by bzr, but it is quite easy to add on top.
<c1|freaky> james_w: how to add something on top?
<james_w> c1|freaky: well you can extract to a directory and then just delete everything that you don't want.
<james_w> export to a directory, sorry.
<c1|freaky> ok thank you
<brlcad> does anyone know of a project that provides a "libbazaar"?  i.e. C library interface bindings for creating/reading/writing a bazaar repo for directly integrating into a C/C++ application without some wrapper layer?
<brlcad> from my searches, it looks like the answer is a solid 'no', but I figured if anyone heard of someone working on such an effort, it'd be in here..
<james_w> brlcad: yeah, as far as I know that is a definite no.
<brlcad> james_w: mm, darn but thanks
<abentley> brlcad: what for?
<brlcad> for integrating into a c/c++ app as a revisioned data store backend for storing data created/used by that app
<aadis> join #actionscript
<aadis> heh, sorry
<abentley> brlcad: It is possible to use a python library from C/C++, just not very straightforward.
<brlcad> abentley: of course, just such wrapper layers are usually quite distasteful to have at all, much less maintain over a long term -- that's why I specifically said without it, just not worth it that way
<abentley> Of course, a C/C++ library is even more work to maintain over a long term, and no one so far is interested in doing that.
<brlcad> I have a workable path through libsvn, but it means I'll have to resort to repository synchronization into the application layer
<brlcad> that certainly depends on the dev audience, for the bzr devs that may very well be the case
<brlcad> in any regard, thanks for the insight/responses
<NichardRixon> $ bzr init-repo --no-trees sftp://mrlachatte_flyinformation@ssh.phx.nearlyfreespeech.net/
<NichardRixon> mrlachatte_flyinformation@ssh.phx.nearlyfreespeech.net's password:
<NichardRixon> bzr: ERROR: Permission denied: "/.bzr": [Errno 13] Permission denied
<NichardRixon> what could be causing this error?
<NichardRixon> (using bzr 1.2 on vista in msys)
<ryanakca> How can I pull from a branch without putting it on a webserver or on launchpad? I have ssh access to the server where the branch is located
<frsk> bzr pull sftp://user@host/path should work
<ryanakca> frsk: ok, thanks :)
<jdong> that's the loveliness of bzr :) No server needed
<jdong> hey jelmer , how much RAM is branching a 16k rev svn repo supposed to take?
<jdong> at rev 6k, I'm seeing 400MB or so usage
<jdong> I've applied the python bindings memory leak patch backported from Hardy
<aadis> NichardRixon: it seems to try to create a directory .bzr in your / dir (C:?). Do you have enough permissions?
<NichardRixon> I would assume so
<NichardRixon> I mean, if I ssh in and run mkdir .bzr it works fine
<aadis> mkdir /.bzr ?
<NichardRixon> oh, hrm
<NichardRixon> how can I fix this problem :<
<abentley> NichardRixon: Your command is trying to create a repository in the root directory of your server.  User accounts do not typically have create rights to the root directory.
<aadis> ah, sftp defaults to root dir.
<abentley> You would specify a directory you do have rights to, like your home directory.
<NichardRixon> I assume there's a flag I can set?
<radix> yeah. you didn't put a path at the end of that URL
<abentley> e.g. bzr init-repo --no-trees sftp://mrlachatte_flyinformation@ssh.phx.nearlyfreespeech.net/~/
<NichardRixon> hrm
<NichardRixon> bzr: ERROR: No such file: '': [Errno 2] No such file
<abentley> Perhaps you don't have a home directory?
<abentley> What directory do you have access to?
<NichardRixon> but I do :(
<radix> huh, I didn't know "~" works.
<NichardRixon> if I go cd ~ it works fine
<jdong> try an absolute path to your intended destination?
<radix> or maybe it doesn't? :)
<jdong> maybe you don't have a home via sftp
<abentley> radix: It works on sftp, but not on bzr+ssh
<jdong> radix: it works for sftp
<NichardRixon> would /home/ work at the end of the path?
<radix> NichardRixon: /home/yourusername/ should work. but so should ~
<NichardRixon> bzr: ERROR: Permission denied: "/home/.bzr": [Errno 13] Permission denied
<radix> NichardRixon: /home/yourusername, not /home.
<NichardRixon> bzr: ERROR: No such file: '/home/mrlachatte': [Errno 2] No such file
<NichardRixon> I've got /home when I ssh in
<radix> NichardRixon: it sounds like the server setup is broken
<abentley> It looks like there's a bug that server/~/ must be followed by a directory name.
<radix> NichardRixon: what happens if you "echo $HOME" when you ssh in?
<radix> abentley: oops
<NichardRixon> \/home/private
<NichardRixon> without the \
<radix> NichardRixon: that's... weird
<radix> NichardRixon: can you create files in /home/private? maybe you will need to put your bzr branches in there.
<NichardRixon> yeah, I'm trying that now
<radix> but it's very strange that your home directory isn't /home/<username>
<NichardRixon> maybe I can use ~/bzr/
<radix> NichardRixon: yeah, maybe that'll work.
<NichardRixon> yay!
<NichardRixon> no errors :)
<radix> hooray
 * radix gets lunch
<NichardRixon> huh, I'm not seeing anything in ~/bzr/, though
<NichardRixon> ls -A shows me nothing
<radix> NichardRixon: did you mean to type "ls -a"?
<radix> oh, hmm, -A
<radix> NichardRixon: that's strange :)
<radix> NichardRixon: you're typing "ls -A ~/bzr/" ?
<jelmer> jdong: it shouldn't really leak
<jelmer> 25k revisions is easily possible here
<NichardRixon> friggin' weird
<NichardRixon> suddenly my computer started thinking I was pressing alt and shift continuously
<NichardRixon> and left arrow or something
<NichardRixon> so all my messages started typing backwards
<NichardRixon> anyways, ls -A problem still stands
<radix> heh
<jdong> jelmer: hmm 8k revisions, 600MB RAM :(
<lifeless> NichardRixon: if I understand correctly you can push but the content is not there when you look for it ?
<jelmer> jdong: Are you sure you've backported the fix correctly and regenerated the SWIG code?
<NichardRixon> I haven't pushed yet
<NichardRixon> I'm just trying to do an init
<jdong> jelmer: I'm 99% certain
<jdong> grumble maybe I should just do this on my hardy box and preserve my sanity
<lifeless> NichardRixon: whats the exact init command line you are running ?
<NichardRixon> $ bzr init sftp://mrlachatte_flyinformation@ssh.phx.nearlyfreespeech.net/~/bzr/Denkatsu/
<jelmer> jdong: It may well be that not all the required changes are backported to 1.4
<radix> NichardRixon: oh, that command should create .bzr in ~/bzr/Denkatsu/
<radix> NichardRixon: not in ~/bzr/
<NichardRixon> yeah, and there's nothing in /bzr/ at all
<NichardRixon> er, ~/bzr/
<lifeless> NichardRixon: does it fail ?
<NichardRixon> nope
<NichardRixon> no errors
<lifeless> NichardRixon: so echo $? right after it echos 0 ?
<radix> I don't see what the problem is.
<radix> oh, Denkatsu doesn't even exist?
<NichardRixon> radix, there should be a Denkatsu directory in ~/bzr/, right?
<NichardRixon> yes
<NichardRixon> lifeless, where does it echo 0?
<lifeless> NichardRixon: run this "bzr init sftp://mrlachatte_flyinformation@ssh.phx.nearlyfreespeech.net/~/bzr/Denkatsu/ && echo ok"
<lifeless> NichardRixon: tell me if it prints 'ok'
<NichardRixon> bzr: ERROR: Already a branch: "sftp://mrlachatte_flyinformation@ssh.phx.nearlyfreespeech.net/~/bzr/Denkatsu/"
<radix> there is something weird with that server.
<radix> maybe you should avoid use of ~
<NichardRixon> ....oh, interesting
<radix> maybe the sftp server thinks that ~ is something different than the shell does.
<NichardRixon> under /home/public/bzr there's Denkatsu
<NichardRixon> how intriguing
<radix> oi.
<lifeless> NichardRixon: my next question was 'please run "ssh mrlachatte_flyinformation@ssh.phx.nearlyfreespeech.net pwd"  '
<radix> apparently when he sshes in he gets sent to /home, and $HOME is /home/private
<NichardRixon> just a straight ssh in dumps me into /home/public
<radix> <NichardRixon> I've got /home when I ssh in <-- is it putting you in random different directories each time you log in? ;)
<NichardRixon> :D
<NichardRixon> non-deterministic ssh
<lifeless> NichardRixon: does the presence of the username in the command line alter things?
<NichardRixon> eh?
<NichardRixon> it's working now
<lifeless> NichardRixon: ok good; enjoy
<NichardRixon> thank you :)
<NichardRixon> arghhhhh
<NichardRixon> so I've commited everything to ~/bzr/Denkatsu/
<NichardRixon> but there are no files besides .bzr inside that folder :(
<awilkins> This a push? Push doesn't update the tree
<NichardRixon> wait whoops, wasn't doing ls -A
<NichardRixon> there's a .bzr folder and the world is right
<igc> morning
<bmonty> can anyone help with using bzrlib? I'm trying to restrict the results from workingtree.changes_from to a specific dir.
<lifeless> specific_paths=['dir']
<bmonty> does it have to be a relative path (or is there any requirement?)
<lifeless> yes, tree relative path
<bmonty> thanks
<lifeless> if you have an absolute path, tree.relative_path(abs_path) it first
<bmonty> ah, that helps alot!
<lifeless> because there can be N aliases to a tree, we only work with relative paths in the tree api (with some very, and odd, exceptions)
<lifeless> (symlinks, mount points etc generate aliases)
<ubotu> New bug: #192743 in bzr-svn "bzr-svn is irritating when in a (non-svn) subdirectory of an svn working tree" [Wishlist,Confirmed] https://launchpad.net/bugs/192743
#bzr 2009-02-09
<igc> morning
<poolie> hello igc
<poolie> spiv, (garyvdm): so what was the outcome re that patch and 1.12?
<igc> hi poolie
<lifeless> igc: hi
<lifeless> igc: is it ok with you if I rename 1.12-preview to development4, or whatever the current sequence number is up to ?
<lifeless> igc: (its why we use a different namespace, the problem of predicting when-ready)
<igc> lifeless: the format's ready. It's just not reviewed :-) :-)
<igc> lifeless: seriously ...
<igc> my concern with developmentN in this case is that ...
<igc> it's not related to any of the other development formats in any meaningful way ...
<lifeless> igc: why is that a concern?
<igc> i.e. it's not built on N-1, not is it an experiement towards N+1
<igc> potential confusion
<igc> lifeless: I'm happy to rename it btw ...
<igc> just not sure developmentN is the best choice but it's no big deal
<lifeless> can you read the rationale in doc/developers/development-repo.txt
<igc> I did
<lifeless> its a little repo centric, but I did envisage branch and tree doing the same thing
<igc> at the time, new development formats were coming thick and fast in brisbane-core
<lifeless> 1.12-preview is just as confusing as devN IMO - see the question from Karl
<lifeless> 1.12-preview as named appears more solid than dev4, when its really a separate dimension, as we both know
<lifeless> I'd personally prefer devN because we have docs about that, and a defined way for people to find out what it does differently
<lifeless> lower learning curve
<igc> fair enough. I don't want to waste our time arguing about this btw ...
<lifeless> alternatively, if you want a different approach, perhaps use a namespace that maps to tree ;P
<lifeless> igc: me neither, was just trying to be clear
<lifeless> igc: thank you
<igc> "maps to tree"?
<lifeless> well, development-wt1
<lifeless> or something
<igc> ok, that's better by me
<lifeless> cool, its fine by me.
<igc> lifeless: would development-wt5 be ok you think?
<lifeless> igc: yeah, thats fine IMO.
<igc> lifeless: I'll put a patch up.
<lifeless> igc: it does lead to 'how do we do a new tree+branch+repo' as a question, but we can cross that another time, or just collapse back to developmentN
<igc> lifeless: just reviewing your unshelve patch now btw
<lifeless> igc: thanks
<igc> lifeless: did you get any feedback from abentley on it so far?
<lifeless> none that I can see
<Phill> Hey, I used the bzr remove command on something I shouldn't have removed, how can I find the file and bring it back from the death?
<Odd_Bloke> Good evening.
<igc> hi Odd_bloke. Nice to see the patches flowing from you again!
<Phill> Up, nevermind, I figured it out.
<igc> Odd_Bloke: ^^
<Odd_Bloke> igc: It's nice to have found some time to send them. :)
<Odd_Bloke> Thanks for the reviews, BTW.
<igc> np
<jelmer> hey Odd_Bloke
<jelmer> Managed to get home safely?
<Odd_Bloke> jelmer: Yup.
<jelmer> hi Ian
<Odd_Bloke> jelmer: How was your journey?
<jelmer> Odd_Bloke, pretty good
<jelmer> Odd_Bloke, there was some power blackout
<jelmer> which meant that the train was redirected *through* my home town, saving me some transfers
<jelmer> (and causing them for most of the others)
<Odd_Bloke> Heh, nice.
<Odd_Bloke> Well, not so nice for them. :p
<igc> hi Jelmer
<garyvdm> poolie,spiv: I've hacked a quick fix for qbzr re:TooManyConcurrentRequests bug.
<poolie> in to bzr or into qbzr?
<garyvdm> poolie: into qbzr
<poolie> ok
<poolie> so we're ok to merge that if we want?
<garyvdm> Sure
<garyvdm> Yes
<Odd_Bloke> The test suite seems much slower than it used to be.
<lifeless> thanks igc
<KhaZ> Ooh.  Just encountered that TooManyConcurrentRequests error.  Is there a good end-user work around for it?
<KhaZ> (Win32, bzr 1.11)
<garyvdm> KhaZ: is it in qbzr?
<lifeless> KhaZ: using the gui?
<garyvdm> Khaz: if you are using bzr 1.11 -  then it can't be the same bug I was talking about just now. Please could you file a bug report.
<Odd_Bloke> garyvdm: Thanks for the pointer to the upload stuff, I'll look at that when I'm next looking at stuff.
<Odd_Bloke> garyvdm: On a sidenote, are you aware that your Reply-To is set to qbzr@googlegroups.com?
<garyvdm> Odd_Bloke: Pleasure
<garyvdm> Yes
<Odd_Bloke> Cool.
<Odd_Bloke> I think I shall call it a night.
<garyvdm> gmail does not allow you to change you reply-to for 1 msg :-(
<garyvdm> Forgot to change it back
<KhaZ> OK.  I'm using bzr from the command line on windows
<KhaZ> If anyone wants to have a look: http://pastebin.com/m66706082
<KhaZ> I'll put it into the tracker however.
<lifeless> KhaZ: from the CLI it probably indicates a permissions issue or something similar
<lifeless> KhaZ: it *may* be a bug
<KhaZ> Hrmm.  I suppose that's a possibility.  I mean, I'm accessing a linux repo from windows, so anything's possible.
<KhaZ> Although the authentication I'm using is ssh, and I've always accessed the share the same way
<lifeless> is there a backtrace on the server in its .bzr.log
<KhaZ> Ooh, you're a clever one lifeless.  lemme check.
<KhaZ> Hrmm, doesn't appear to be.
<KhaZ> But I imagine it wouldn't be anyways.  THe backtrace in the client is barfing on '_send_request'... I'm guessing the server hasn't even been involved yet.
<KhaZ> What is a 'SMartSSHClientMedium' anyhow?
<lifeless> one step up from serialisation, its a broker for requests to the server
<garyvdm> Night all
<fullermd> About halfway between SmartSSHClientRare and SmartSSHClientWelldone.
 * KhaZ drums a rimshot
<KhaZ> Ah, you know what, I bet you're right and this is a permissions issue.  I just rebuilt my MSYS on windows, and I bet it's trying to log me in with the wrong case....
<KhaZ> Hrmmm.. Now where do I set my ssh username in bzr...
<KhaZ> Oh holy hell.  The whole concept of --local just made sense to me.
<KhaZ> So if I bzr branch off some other server to my local copy, I'm essentially commiting against that 'other server's copy of code, yeah?
<fullermd> Not if you branch, no.
<lifeless> if you checkout
<KhaZ> ANd --local emulates as if I've got a local repository on my HD, until such time as I commit normally?
<fullermd> --local is for shooting yourself in the foot if you checkout.
<KhaZ> Hahah
<lifeless> KhaZ: --local is for treating a checkout like a branch for a short period of time
<KhaZ> Hrmm..  So checkout is more akin to svn co, I guess.
<KhaZ> Right.
<lifeless> KhaZ: checkout is intended to be identical to svn co/cvs co/etc
<KhaZ> Can I see whether I have a branch or a checkout somehow?
<lifeless> bzr info
<KhaZ> Faaaaancy.
<KhaZ> Hrmm, so apparently I am bound with the right username.  Bizarre.
<lifeless> KhaZ: two things
<lifeless> KhaZ: firstly you don't need '.' in your commit line
<lifeless> its the default ;)
<lifeless> secondly, the 'bash: bzr: command not found' says to me bzr can't find bzr on the server
<KhaZ> Hrmm.  Good catch.  Definitely tr...
<KhaZ> Oh damn
<KhaZ> I switched the server over from using gentoo's version of bzr to the copy I have with a patch.
<KhaZ> I bet that's got something to do with it.
<KhaZ> THank God, too.  Traversing that smart ssh code was making me feel dumb.
<fullermd> You should try starting with ReasonablyIntelligentSSHClientMedium and working up.
<lifeless> fullermd: slow day? :P
<KhaZ> Haha.
<fullermd> Well, it's early morning, and I'm desperately trying not to have to get into the work I need to do...
<KhaZ> fullermd: You in Australia/NZ?
<fullermd> Oh, no.  US.
<fullermd> I'm just surrounded by people who keep weird hours   :p
<fullermd> (~300 million of them to be precise.  My life would be so much easier if they'd just stay in sync with me...)
<KhaZ> fullermd: Try ReasonablyIntelligentRSync and work up. ;)
<KhaZ> HeeHee, it is fun!.
<KhaZ> Hrmm.  Does bzr do it's actions in some sort of different usermode than if I were to ssh in manually?  It must, I just can't figure how to emulate it.
<lifeless> KhaZ: no, 'ssh host bzr --serve --allow-writes /' or something like that
<lifeless> there is an environment variable to control what it thinks bzr is called - BZR_REMOTE_SSH or something like that
<fullermd> BZR_REMOTE_PATH
<KhaZ> Right.  Just weird - bzr exists on the command line in the path.  I'm guessing that it's in /usr/local/bin that's the problem.  Just not sure where/who I have to say "Hey!  Look in /usr/local/bin, douche!" to.
<KhaZ> Right, but that's a per repository or per client setting, yeah?
<KhaZ> I'm thinking it's better if I just fix my server.. This *was* working.
<lifeless> yes :P
<KhaZ> ... now if only I could find out where. ;)
<lifeless> late fooding
 * igc lunch
<poolie> lifeless: ping?
<poolie> lifeless: i'm thinking about whether to push for an SRU for a whole bzr release
<poolie> or just to get it into backports
<lifeless> poolie: well, backports is a good start
<lifeless> but an SRU isn't done trivially
<Demosthenes> i've done some searches with little luck. what is the status of nesting repositories?
<vila> hi all
<mwhudson> in a test suite, i want a revision object
<mwhudson> oh hm
<davidstrauss> Is it possible to clean up unused revisions stored in a shared repository?
<Lo-lan-do> davidstrauss: Not yet, but LarstiQ and I (but mostly LarstiQ :-) started a gc plugin two days ago at FOSDEM.
<davidstrauss> nice
<davidstrauss> Lo-lan-do: gc plugin?
<Lo-lan-do> I'm about to migrate to a proper workplace in a few minutes, but I'll be online again later.
<Lo-lan-do> garbage collector
<Youssef> hi guys!
<davidstrauss> ah
<Youssef> how are u?
<davidstrauss> Happy that the Drupal Paris sprint is underway
<lifeless> davidstrauss: excellent
<lifeless> davidstrauss: hey, we haven't reproduced that windows users bug yet
<davidstrauss> lifeless: Let me email him for his directory
<lifeless> davidstrauss: but a different issue I've found which caused the 'corruption' is something I will be fixing, which at least would mean things get pushed correctly
<lifeless> davidstrauss: I think you gave us a copy already?
<davidstrauss> lifeless: Not *his* checkout
<davidstrauss> lifeless: I'd be happy implementing something that would have caught this pre-commit.
<davidstrauss> lifeless: If there's an immediate error, it will be much easier to catch in the future
<dholbach> hi guys
<dholbach> jelmer: where does Debian get python-subvertpy from?
<dholbach> jelmer: just checking out the bzr* sync requests
<dholbach> bug 325930 is the one I was stumbling over
<ubottu> Launchpad bug 325930 in bzr-svn "Please sync bzr-svn 0.5.0-1 (universe) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/325930
<lifeless> davidstrauss: indeed, but we need a good theory of what happened to do that :P
<davidstrauss> lifeless: We know it failed bzr check after that revision got added.
<davidstrauss> lifeless: So it's detectable, albeit inefficiently.
<jelmer> dholbach, hi
<jelmer> dholbach, subvertpy is in NEW
<dholbach> jelmer: hrm :-/
<dholbach> makes it somewhat hard to sync :-/
<jelmer> dholbach, I can upload to REVU if that makes things easier for Ubuntu
<dholbach> jelmer: or just put it up somewhere and link to it in the bug report - I'll review and ask the archive admins what needs to be done
<dholbach> (the source package)
<dholbach> luckily the bzr-svn is in universe so we don't need to write a main inclusion report for subvertpy :)
<jelmer> dholbach: :-)
<dholbach> jelmer: thanks for helping out there!
<jelmer> dholbach, I'll upload a source package this afternoon, gotta run now
<dholbach> rock and roll
<dholbach> have a great day
<Youssef> hi guys
<Youssef> I have a problem
<Youssef> im working with vista
 * Lo-lan-do sympathizes
<Youssef> looool
<Youssef> yes but
<Youssef> okay
<Youssef> I explain
<Youssef> im creating a folder it looks like this check
<Youssef> I would like to create a folder with my project
<Youssef> but i want it to work in a server
<Youssef> im working with my computer
<Youssef> alo?
<Youssef> i there someone?
 * Lo-lan-do doesn't understand the problem
<Youssef> lol
<Youssef> okay
<Youssef> i repeat more clearlly
<Youssef> mmhhh
<Youssef> just a second
<Youssef> localy I create a server
<Youssef> with a shared foler
<Youssef> check
<Lo-lan-do> What's a server?
<Youssef> C:\>mkdir MyOfficialProject
<Youssef> C:\>cd MyOfficialProject
<Youssef> C:\MyOfficialProject>bzr init
<Youssef> Standalone tree (format: pack-0.92)
<Youssef> Location:
<Youssef>   branch root: .
<Youssef> C:\MyOfficialProject>bzr add
<Youssef> Added files
<Youssef> C:\MyOfficialProject>bzr commit -m "Initial Commit"
<Youssef> Committing to: C:/MyOfficialProject/
<Youssef> Added files.
<Youssef> Committed revision 1.
<Youssef> C:\MyOfficialProject>bzr serve
<Youssef> listening on port:  4155 ...
<Lo-lan-do> Please use pastebin for pasting stuff!
<Youssef> this is what a do for a dedicated server
<Youssef> Oops sorry
<Youssef> really sorry
<Youssef> I prefer rafb
<Youssef> http://rafb.net/p/FHobII85.html
<Youssef> check
<Youssef> Logically my folder is a shared folder
<Youssef> no?
<Lo-lan-do> I don't know.  What do you mean by shared folder?
<Lo-lan-do> (I'm clueless with Windows, you'll have to forgive me)
<Youssef> hmm :)
<Youssef> I imagine
<Youssef> okay
<Youssef> listen i just want to create a project in a distant server from where ill be able to simply checkout it to my laptop
<Youssef> how a can do that please?
<Lo-lan-do> Can't you connect to your server?
<Youssef> no no i can connect but when I chek it out he is the server log
<Youssef> http://rafb.net/p/M991cN26.html
<Youssef> what is it?
<Lo-lan-do> Not sure.  Firewall?
<Lo-lan-do> How did you try to access the server?
<LarstiQ> Lo-lan-do: thanks, I branched bzr-gc
<Lo-lan-do> LarstiQ: You probably saved yourself, oh, I don't know, at least five minutes of work :-)
<Youssef> in localhost
 * LarstiQ grins at Lo-lan-do 
 * Youssef hope in Lo-lan-do
<Lo-lan-do> LarstiQ: Thanks by the way, bzrlib is no longer a scary monster to me.  It's just a large unknown beast now.
<Lo-lan-do> Youssef: Command line?
<Youssef> ???
<Youssef> what?
<LarstiQ> Lo-lan-do: the motivational aspect is the important bit, I'm going on a ~24 hour trip now, so I'm hoping to hack more on it if the power is with me.
<Lo-lan-do> What was the command like you used?
<LarstiQ> Lo-lan-do: that's good to hear
<Youssef> okay check
<Youssef> WHAT?
<Youssef> Lo-lan-do:
<Youssef> when i do => C:\LocalCopy>bzr branch bzr://localhost/
<Youssef> Branched 1 revision(s).
<Youssef> and it copy the folder where i am
<Youssef> is it correct?
<Lo-lan-do> Looks like so.
<Youssef> when
<Youssef> C:\LocalCopy>bzr checkout bzr//localhost
<Youssef> bzr: ERROR: Not a branch: "C:/LocalCopy/bzr/localhost/".
<Lo-lan-do> Missing :
<Youssef> Lo-lan-do! juste come back to : http://rafb.net/p/FHobII85.html
<Youssef> is it correctly done?
<Youssef> with my computer it seems to be correct
<Lo-lan-do> It looks like it is, and since you managed to branch from it I don't see what the problem is.
<Youssef> hhmm okay
<Youssef> stay there im comming
<Youssef> forgot the branch
<Youssef> okay
<Youssef> now
<Youssef> when my server works
<Youssef> as client what do i have to do to get a copy of the project
<Youssef> bzr checkout bzr://localhost/MyOfficialProject ?
<Youssef> C:\LocalCopy>bzr checkout bzr://localhost/MyOfficialProject
<Youssef> bzr: ERROR: Not a branch: "bzr://localhost/MyOfficialProject/".
<Lo-lan-do> You did it already: bzr branch bzr://localhost/
<Youssef> yeah but do I have to do it first i chekcout?
<Lo-lan-do> ?
<Youssef> lol okay in english now
<Youssef> do I have to do a branch before a checkout?
<Lo-lan-do> Depends on what you want to do.  Do you want a branch or a checkout ?
<Youssef> first a checkout
<Lo-lan-do> Then just do a checkout.
<Youssef> in a simple directory ? or a have to do sometings before a ckekout
<Lo-lan-do> Just do a checkout :-)
<Lo-lan-do> You're not using git, things are supposed to just work here.
<Youssef> loooool the checkout successed ppfff
<Youssef> okay stil stay with me
<Youssef> I have done a "C:\LocalCopy>bzr checkout bzr://localhost/"
 * Lo-lan-do â food
<matkor> Hi ! I did bzr push bzr+ssh://<remote>/<dir>         Now how can I see WT in <dir> ?
<beuno> matkor, no, push to remote locations doesn't produce WT
<matkor> bzr update   gives:   bzr: ERROR: No WorkingTree exists for <dir>
<matkor> bueno: So how can I get WT in <dir> ?
<beuno> matkor, via a plugin
<awilkins> ssh me@remote ; cd <dir> ; bzr up
<beuno> you have either push-and update
<beuno> or, bzr-upload, which *just* uploads the WT
<matkor> awilkins: I get bzr: ERROR: No WorkingTree exists for "file:///<dir>/.bzr/checkout/"
<jdong> he meant bzr co
<jdong> you run bzr co the first time, bzr up subsequent times :)
<jdong> (check out a working tree, update existing working tree)
<matkor> Ah ! Right. Thank you very much jdong, awilkins
<matkor> and bueno
<Toksyuryel> I just thought of something. for a "clone" checkout (i.e. where the user is downloading the tree for the very first time and does not currently have a working copy) is it really necessary to send each file one-by-one? would it be better to compress and archive them first and just send that?
<Lo-lan-do> I think what goes over the network is actually the repository, and the files are checked out of the new copy.
<phinze> hey so how does bzr play with symlinks in a repository?  i'd like to have a "latest" symlink in my "releases" subdir that points to the last release branch
<phinze> will that confuse bzr?
<Lo-lan-do> phinze: It my experience it seems to work.
<Lo-lan-do> But that may confuse users, since the contents of a stable URL may change.
<phinze> Lo-lan-do: it's for internal use in a department where we have a weekly release cycle
<Lo-lan-do> I'm jus' sayin' :-)
<phinze> right, this is true
<Lo-lan-do> It's basically the same as rebasing a public branch.  If your users expect it, no problem.
<phinze> also, thanks :)
<phinze> sounds good
<phinze> so now if i have a local branch of "latest", and the symlink has been moved to a new release, i can "bzr pull"? or must i remove and rebranch?
<Lo-lan-do> You can pull if the new one is a direct descendant of the previous "latest".
<phinze> hmm... new one will be branched off a later revision of trunk
<Lo-lan-do> If histories have diverged, you'll need to either merge or pull --overwrite.
<phinze> not sure if that constitutes "direct descendent"
<fullermd> pull --overwrite will probably be faster and easier than removing and rebranching...
<phinze> probably pull --overwrite will be what i want, as it will just be used as a mirror for diffing
<fullermd> Roughly speaking, if the "release branch" is an older version of trunk, the history isn't diverged.
<fullermd> It diverges if a commit is made on the release branch that wasn't pulled from trunk.
<fullermd> So it really depends on what "release branch" means.
<phinze> ahh okay
<phinze> yeah we're still developing our software release procedure w/ bazaar, but we're thinking in the case of an emergency we'll have a commit directly to the release branch that we merge back into trunk
<phinze> so in that case we may have diverged
<fullermd> If it's merged back into trunk, then trunk becomes a superset of the release branch, so pull can work.
<phinze> ah wow
<phinze> nice
<fullermd> It's all revision based.  If trunk contains the head revision of the release branch, it's a proper superset, and if it's a proper superset, you can pull.
<phinze> cool
<phinze> man i'm still only scratching the surface of this domain of knowledge :)
<fullermd> An alternative would be to use tags for the releases, and a sliding tag for the latest.  If it's very rare that you commit onto a release branch, that may be simpler.
<fullermd> (or it may not, considering tag propogation issues)
<phinze> yeah we looked into that, but we were hesitant because of a bug we encountered having to do with tags not being pulled until a revision is bumped in some other way
<phinze> perhaps that is referring to the "tag propogation issues" you mention
<fullermd> Mmm.  I'm pretty sure they always pull.  Maybe they don't propogate with merge unless there are revs to merge.
<fullermd> I was thinking more of the lack of versioning causing headaches when they change.
<phinze> ah yeah that's another issue
<fullermd> (wihch doesn't matter for the release tags, but sure as heck does for a slider)
 * fullermd waves at bialix.
<phinze> right right
 * bialix waves at my here
<bialix> err
<bialix> pfff
<bialix> sorry
<bialix> hi fullermd
<bialix> I wish to have nested trees year ago
<bialix> LarstiQ: new layout almost finished
<bialix> LarstiQ: i.e. Ive started using it. I think nested trees should be killer feature. Sad they are not here
<bialix> ubotu
<bialix> ubottu
<bialix> sorry for noise
<Odd_Bloke> jelmer: Thanks for the reviews. :)  I'll look at the tweak this evening.
<kirkland> is it possible to edit an existing commit message, for a previous revision?
<beuno> kirkland, no
<beuno> but you can uncommit
<beuno> and commit again with a new message
<kirkland> ah
<kirkland> beuno: beuno
<beuno> recursive me!
<kirkland> :-)
<awilkins> kirkland: Problem with uncommit is if other people have branches based on the revision(s) you've uncommitted
<kirkland> awilkins: thanks, gotcha.  i think this is just a one time deal
<vila> abentley: ping
<abentley> vila: pong
<vila> is read_bundle_from_url still useful or can it be deprecated ?
<vila> abentley: the reason I ask is that it causes problems in tests
<abentley> vila: lemme see...
<vila> because it's an url based API, it fools the test framework when special purposes transports must be used
<vila> the root cause is the get_transport call in read_mergeable_from_url (i.e. we have read_bundle_from_url -> read_mergeable_from_url -> read_mergeable_from_transport)
<abentley> vila: So read_bundle_from_url is a problem but read_mergeable_from_url is not?
<vila> it's a problem too but I found a work around for it in the tests ;-)
<vila> because it accepts a possible_transports parameter !
<abentley> vila: That does not sound good, but I'm okay with deprecating read_bundle_from_url.
<vila> I can add a possible_transports parameter to read_bundle_from_url too, but I thought that if some cleanup was possible it was better to do so
<vila> I agree, that's not the proper fix, the problem is that there are tests that are buggy today
<vila> i.e. they declare to test a transport while in fact they use another
<abentley> vila: You may also be able to eliminate the _do_directive parameter.
<vila> nobody can detect that yet, I ran into it while using a special https transport
<vila> eliminate the _do_directive parameter ?
<abentley> vila: I believe it's only false when called by read_bundle_from_url.
<vila> aah, you mean once read_bundle_from_url is deprecated ?
<abentley> I did, but actually, that must wait until it's removed.
<vila> ok
<vila> thanks, I'll do that (deprecate) then
<theAdib_> does bzr handles svn branches via https? i.e. bzr branch https://server/pathtorepos
<jelmer> theAdib_, yes
<theAdib_> jelmer, so how can I enter username and password for that connection? I get: Unable to handle http code 401: Authorization Required
<jelmer> theAdib_: make sure you have a new bzr-svn (0.5.0) and specify the username in the URL
<theAdib_> I am on win32 using latest bzr 1.11,
<theAdib_> and that worked thx, jelmer ! :-)
<KhaZ> There's no way to do partial checkouts of a tree in bzr, correct?
<santagada> KhaZ: partial checkouts of a branch is not supported ATM
<jelmer> KhaZ, there's a partial implementation waiting to (hopefully) go into 1.12
<phinze> a partial implementation of partial checkouts? ;D
<jelmer> :-P
<KhaZ> exxxxciting.
<KhaZ> How partial, exactly?
<santagada> jelmer: will it need changes on the repo format or is it only a client thing?
<santagada> or is it client/server thing but not repo format dependant?
<jelmer> it needs a new repository format (which will not be stable as of 1.12)
<jelmer> it's partial in that it is specific to the working tree
<jelmer> you'll still need the full branch history
<KhaZ> jelmer: Is 'full branch history' just everything under .bzr ni a repo?
<jelmer> KhaZ, yeah, basically
<KhaZ> OK, I supopse that's not so bad.  A bit bizrre to think that one directory will sync almost 900 MB, but not as bad as the 2 GB in the full repo!
<phinze> what's a good way to get patch-level confirmation of a merge?
<phinze> "yes this, not that, not that, yes this" etc
<nDuff> phinze, ...patch-level, not hunk level? AIUI, it's most common to do cherry-picking (what that workflow is called) on the commandline setting up the merge, not afterwards but prior to committing.
<phinze> nDuff: sorry i meant hunk level
<asabil> phinze: check the bzr-interactive plugin
<nDuff> phinze, (actually, doing it patch-level *is* supported, too: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#reverse-cherrypicking)
<asabil> well the bzr-interactive only gives you interactive commits for now
<nDuff> phinze, ...but hunk level, I most often cheat and rely on shelve.
<phinze> nDuff: yeah i was wondering if it could be used in that way
<phinze> how does that work for you?  (i.e. what commands are you running roughly in what order?)
<phinze> asabil: that looks promising, but atm i'm interested in interactive merge
<asabil> phinze: adding interactive merges shouldn't be difficult
<asabil> you can try to extend it, that would be pretty neat
<phinze> asabil: cool, perhaps i'll look into it
<phinze> nDuff: nm i can imagine it pretty well... bzr merge, then bzr shelve, and shelve things you dont want to commit
<jdobrien> is there any clearer guidance available about the --no-trees option for init-repo?
<jdobrien> thanks rockstar ^^^ nice post http://theironlion.net/blog/2009/01/23/more-advanced-bazaar-concepts/
<rockstar> jdobrien, thanks!
<rockstar> jdobrien, did that answer your questions, or do you still need help?
<jdobrien> i think so.
<jdobrien> rockstar: can I push my (feature) branches to launchpad from the lightweight checkout?
<rockstar> jdobrien, yeah.  I almost never have to go into the ~/Projects/repos folder at all.
<jdobrien> rockstar: sweet, that's what I'm looking for
<garyvdm> jdobrien: you can run bzr push -d :bound
<garyvdm> Then it will use the saved push location of the bound branch.
<jdobrien> thanks garyvdm, i'll have to look that up.
<jdobrien> i wonder how long it will take to master bzr .. probably never will
<jdong> garyvdm: what other :names are available?
 * jdong didn't know bzr supported those
<garyvdm> :push, :pull
<nDuff> Are the bzr and bzrtools releases in the PPA out-of-sync?
<garyvdm> There must be a list somewhere, but I don't know where.
<garyvdm> nDuff: yes
<jdong> garyvdm: are those documented somewhere?
<garyvdm> jdong: probably - but I don't remember where.
<bialix> garyvdm: well done, thanks
<garyvdm> Hi bialix - Everything correct?
<Peng_> jelmer: ping?
<jelmer> Peng_, pong
<bialix> garyvdm: well, one tiny detail: you forgot to update QBzr page at bazaar-vcs.org/QBzr
<bialix> but this is easily fixable
<garyvdm> bialix: Oh - Do I still need to do it?
<bialix> I can do it
<bialix> garyvdm: actually I have  a question to you about qlog
<garyvdm> Ok
<Peng_> jelmer: Oh hi. Errm.
<garyvdm> jdong: from the source code:
<bialix> is it possible to show not all history, but revision range instead in the qlog?
<garyvdm> :parent, :submit, :public, :push, :this, and :bound are currently supported.
<garyvdm> bialix: there is no ui
<jdong> garyvdm: good sleuthing; thanks :)
<bialix> garyvdm: do you mean command-line interface UI?
<garyvdm> and if we add a ui to do it - it would not improve the performance
<Peng_> jelmer: I used bzr-svn 0.4 to branch an svn branch, and committed locally a few times, but never pushed back. Now that I'm using 0.5, it wants to use svn-v4 revids, confusing everything. Advice?
<garyvdm> bialix: command-line nor gui
<bialix> garyvdm: let's say specific example: is it possible to show qlog for pending revisions?
<garyvdm> bialix - not yet - but I'm hopeing to do that soon - so I can reuse the new log_list widget in qcommit
<bialix> garyvdm: or if I want to implement cherrypicking dialog to show selected revisions for picking?
<bialix> I'm thinking exactly about situation with revision range for some spefic use cases
<garyvdm> bialix: if you just want to filter, that easy. What tricky is to filter, and not have to load the whole revision graph.
<bialix> at least it's the start
<bialix> Good evening, dear bzr hackers! Is it possible to collect code coverage info for the tests?
<garyvdm> bialix: I've just merged my log refactoring into trunk.
<bialix> garyvdm: cool
<bialix> garyvdm: one more question about qlog: can we create revision picker dialog based on qlog?
<garyvdm> Yes!
 * bialix mulling this idea very long time
<bialix> it was super-optimistic!
<jelmer> Peng_, 0.5 wants to use svn-v4 revids when?
<garyvdm> Should be very easy now.
<bialix> great! really-really great!
<Peng_> jelmer: Whenever. "bzr merge" or whatever.
<garyvdm> I want to use the log widget in qcommit, qannotate, and make a revision selector for push, pull, tag, merge etc...
<Peng_> jelmer: Since I never committed back to the svn repo with 0.4, it doesn't know any better.
<bialix> jam who knows everything: can you suggest something about coverage? mensieur vila? anybody?
<bialix> garyvdm: you simply read my mind
<jelmer> Peng_, "bzr svn-upgrade" should fix that
<bialix> jelmer: hi, can you suggest something about coverage statistics?
<vila> bialix: I think selftest has a --coverage option but AFAIK it's broken for plugins
<jelmer> Peng_, merge isn't aware of foreign branches (yet)
<bialix> vila: I've thoughts so, but I've re-read selftest -h 5 times and I don;t see this option
<bialix> broken for plugins: :-[
<bialix> it's not my day then
<vila> bialix: That's because it's not in the online help, that's for devs, they don't read help :-)
<bialix> ah
<bialix> yes
<vila> seriously, that's a bug, it should be documented
<bialix> oh no
<vila>     --coverage
<vila>         Generate line coverage report in the specified directory.
<bialix> it's not bug
<vila> that's a global option
<bialix> yep, PEBKAC
<bialix> I need addtional module I guess
<bialix> coverage.py from Ned Batchelder, is it?
<beuno> poolie, hi. Are there still known problems with the new progress bars, or should I report the bug that status text concatenates instead of replacing eachother?
<bialix> vila: why you said it's broken for plugin?
<vila> bialix: I don't think it's a very serious bug, I don't remember the details but I think it has to do with the fact that the plugins aren't in PYTHON_PATH or something
<vila> bialix: did you try it ?
<bialix> oops
<vila> My memory may be wrong, it may have been fixed...
<bialix> I'd like to
<Peng_> jelmer: "svn-upgrade" sounds a little scary. And wouldn't I need to install the rebase plugin?
<jelmer> Peng_, yeah, that depends on the rebase plugin
<vila> bialix: bzr --coverage cover selftest -s bp.qbzr
<bialix> -s bp.qbzr?
<vila> bialix: don't tell me you don't know -s bp.qbzr !!!
<vila> Just try: bzr selftest -s bp.qbzr
<bialix> me me me
<bialix> I don't remember
<bialix> I've not followed your bzr toys many months
<vila> bp.qbzr expands to bzrlib.plugins.qbzr it will speed up running your plugin tests by orders of magnitude
<vila> I'm sorry I didn't publicize that much :-/
<Kobaz> mmm
<bialix> right
<bialix> I recall it now
<bialix> it was your patch
<bialix> in first half of 2008, yes?
 * bialix using full form -s bzrlib.plugins.scmproj
<vila> Could be, can't remember that sort of date generally :-)
<vila> bialix: haaaa, ok, so the shortcuts are far more recent yes.
<bialix> found in the HACKING.txt
<bialix> Test coverage
<bialix> =============
<vila> As are the ability to specify mutiple ones
<bialix> All code should be exercised by the test suite.  See `Guide to Testing
<bialix> Bazaar <testing.html>`_ for detailed information about writing tests.
<bialix> not so many info
<vila> bialix: that's right --coverage is underused :-/
<bialix> vila: -s bp.xxx -- it's worked! nice!
<bialix> I have obscure feeling it was the patch from spiv
<vila> --coverage is from spiv yes
<bialix> oh no, it soo loong to wait for oz people to wake up
<bialix> well, thanks, you gave ne a clue
<bialix> will test how it selftest :-)
<vila> bialix: are you in the Kiev TZ ?
<bialix> aha
<bialix> UTC+2
<vila> bialix: I see, yes, waiting for NZ will be a bit hard for you :-/
<bialix> vila: bzr --coverage FILENAME -- that's right?
<bialix> vila: are you not in Europe?
<vila> bialix: no --coverage DIRECTORY
<vila> bialix: I am in France
<bialix> what DIRECTORY?
<vila> bialix: one that will contain files whose names are the python modules
<bialix> vila: should I think waiting is not so hard to you? ;-)
<vila> try it on a sample and look (you may have to create it first, I don't remember) looking at the results things should be obvious
<bialix> sample?
<vila> bialix: one hour less :)
 * bialix downloading coverage.py
<vila> huh ?
<bialix> you think I should not?
<vila> I don't remember needing an additional package... I may be wrong, checking
<bialix> vila: I'd like to not start using python-based bzr if I can
<bialix> bzr.exe is much pleasure
<vila> haaa. sry
<bialix> I knew only one actively maintained coverage lib: http://nedbatchelder.com/code/modules/coverage.html
<bialix> I suppose spiv used it
<vila> can you just try ./bzr selftest --coverage cover -s bt.test_read_bundle
 * bialix trying
<vila> A quick look seems to imply using the standard trace python module
<vila> Ok, I just run it, no need to create the cover directory, it's created automatically
<bialix> PermissionDenied: blah-blah-blah: I've almost forgot this stuff
<vila> rats, tests failing ?
<bialix> 51 tests, tests passed
<bialix> 16 leaking tests :-P
<vila> do you have a cover directory ?
<bialix> have the "cover" dir full of files
 * bialix m-m-m
 * bialix looks
<vila> bialix: get it ? '>>>' not executed, 'n' number of executions
<bialix> >>> not executed? you kidding
<bialix> or the result id weird
<bialix> how it can't execute def blah(foo):
<bialix> vila: you're right
<bialix> vila: about plugins
<bialix> it don;t see my plugin
<bialix> only launchpad
<vila> A workaround can be to install your plugin in a directory XXX/bzrlib.plugins with XXX in PYTHON_PATH
<bialix> so... if I'm put it inside bp, perhaps it will collect the info
<bialix> ja!
<vila> be aware to *not* leave it in .bazaar/plugins though...
<vila> Bah, that's gross, we should really fix that
<bialix> this makes my job harder
<bialix> but actually I keep my plugins in the BZR_PLUGIN_PATH dir
<vila> I know, that's the bug :)
 * bialix will try suggested hack
<bialix> merci beaucoup
<vila> :-)
 * bialix mutters: "I just need to create special lightweight checkout and blow"
<vila> I'm off, report your results, I'll read it tomorrow !
<bialix> ok!
<imnotparanoid> hello all! I'm a new bzr user, and need some help with my "workflow" (just a quick question). can anyone spare a few minutes?
<Peng_> jelmer: svn-upgrade doesn't edit the subversion repo or anything, right?
<jelmer> Peng_, no
<bialix> shoot your quick question
<Peng_> jelmer: Alright.
<imnotparanoid> i have a shared repo, a checkout using bzr-svn. i branch and work on them, etc. how can i create a branch on a flash drive, for example, so I can work at home?
<imnotparanoid> (i have copied a normal branch.. but, the revisions were in the repo.. so i could not use it at home)
<bialix> what's your OS?
<imnotparanoid> XP @ work (where i have the repo), linux @ home. bzr 1.11 on both
<bialix> ok
<ericvw> Where should I post about getting an appropriate version of bzrtools in the PPA?
<Peng_> Ergh, wait a minute. I branched off of the bzr branch too. How do I svn-upgrade the child?
<Peng_> An idmap-file?
<bialix> 1. create treeless repo at flash: bzr init-repo --no-trees E: (or other drive letter of your USB)
<jelmer> Peng_, no, the upgraded ids are consistent
<bialix> err, actually you need sensible patg
<jelmer> Peng_, Just run svn-upgrade there as well
<bialix> path
<Peng_> jelmer: Oh, nifty.
<imnotparanoid> ok.. next step
<bialix> then do bzr push from your branch to the repo on flash
<imnotparanoid> do i need to use the --create-prefix ?
<bialix> you'll get the new branch inside repo on flash with full history
<bialix> more specific example, let's say your flash drive letter E: and you create repo/ dir
<bialix> bzr init-repo --no-trees E:/repo
<bialix> cd your-local-branch
<Peng_> Argh, how the heck do I tell svn-upgrade where the original svn branch is?
<bialix> bzr push E:/repo/trunk
<jelmer> Peng_, it's the first argument
<bialix> this will create new branch called trunk
<Peng_> jelmer: You mean the one that causes it to say "No repository present"?
<jelmer> Peng_, ah, you have to give it a repository URL
<jelmer> Peng_,  not a branch URL
<imnotparanoid> thank you! I think I can handle it from here!
<bialix> because you're using bzr-svn you need to specify format --rich-root-pack (or more recent) for init-repo
<Peng_> jelmer: Oh.
<imnotparanoid> (it hasn't crossed my mind to create another repo on the flash drive)
<Peng_> jelmer: Indeedy, that worked.
<Peng_> jelmer: Thank you for the help. :)
<jelmer> np
<imnotparanoid> (yes, i know about the --rich root-pack from the initial repo)
<bialix> you may want to look at repo-push plugin
<bialix> and/or multi-pull command (from bzrtools)
<imnotparanoid> i'm still reading the documentation (i'm not sure - yet - about the differences between push/commit/branch or pull/checkout).
<ericvw> why isn't the new 1.11 version of bzrtools in the PPA?
<imnotparanoid> thank you for your time. i'm going to give it a try tonight! have a nice evening!
<bialix> good luck
<Peng_> jelmer: Thank you for the help. "bzr svn-upgrade" seems to have gone fine. :)
<jelmer> Peng_, np
<jelmer> Peng_, ideally "bzr merge" will do the right thing in the future
<jelmer> once revision-id aliases work :-)
<poolie> hello all
<bialix> jelmer: rev-id aliases?
<jelmer> 'morning poolie
<bialix> hello poolie
<jelmer> bialix, yeah, though hooks in the graph code might be sufficient for the moment
<bialix> poolie: I hope this patch will go into 1.12: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C497A0CD9.7030005%40arbash-meinel.com%3E
<bialix> it should fix many problems
<poolie> it looks good to me too
<poolie> you keep asking me about patches i've approved :)
<poolie> although admittedly yesterday to say it caused breakage
<bialix> no, yesterday it was garyvdm
<poolie> is jam still around? he should be
<jam> poolie: I'm around
<jam> bialix, poolie: It works for "shelve" but causes some tests for things like "diff" to break
<bialix> rats
<jam> I can give specifics
<jam> but basically, our lock ordering is a bit haphazard
<poolie> diff probably has to work :)
<poolie> i was going to start the release in about 5 hours from now
<jam> poolie: yeah, I would guess it is something like "bzr diff -r branch:" not working correctly.
<bialix> so, I'd better won't try to ping you both then
<jam> poolie: you're up early, btw
<poolie> i am
<jam> bialix: I'll see if I can't get it working today
<poolie> i wanted to review ian's patches
<poolie> i don't know if they'll land for this release but my review of them is pretty overdue
<bialix> jam: I was in big hope about locks problem'
<bialix> but I can live without shelve2
<jam> I still have some hope for it
<bialix> but shelve1 required patch.exe to be present
<bialix> anyway, I'd better stay on the side
 * bialix hides
<jam> btw, poolie, you forgot to package bzrtools in the ppa during the 1.11 release, which seems to cause troubles for a lot of people, we should both get it packaged, and keep an eye out for that with the 1.12 release
<poolie> yes, i saw :/
<poolie> also, i think it would be easier to just merge everything across
<poolie> i wonder if people are actually using bzrtools features, or if (as one person said) they were just told it's good so they keep it installed
<jelmer>     s = self.filesock.readline(size)
<jelmer> TypeError: readline() takes exactly 1 argument (2 given)
<jelmer> anybody else seeing this?
<lifeless> jam: pooliee: I believe that is what johnf wants to help by doing
<lifeless> jelmer: yes, it was on the list, post b john on sunday
<jelmer> lifeless, ah, thanks
<jam> jelmer: vila and I have posted a fix. It has to do with https and python<2.6
<bialix> jelmer: you've mentioned launchpadbugs recently. is it the separate library?
<jelmer> jam, ah
<jelmer> bialix, yeah - see lp:python-launchpad-bugs
<bialix> jelmer: is it possible to use it to mark all bugs related to milestone to mark as "Fix Released"?
<jelmer> bialix, not out of the box
<jelmer> but you could write a script using it that would do such a thing
<bialix> it's very boring task, so I'm ready to write the script
<mwhudson> beuno: hello
<beuno> mwhudson, howdy
<mwhudson> beuno: do you know what History.get_merge_point_list is trying to do in loggerhead?
<mwhudson> and simplify_merge_point_list
<beuno> mwhudson, the latter, no idea. The former, IIRC, is used to find out what revisions to look at to get the files changed in a mainline revision
<beuno> but I get dizzy everytime I try and go in there
<mwhudson> ok
<mwhudson> i guess it's time to step back and say
<mwhudson> "what information is interesting to display"
<beuno> right
<beuno> well
<beuno> I think the information we're displaying is fine
<beuno> we *could* drop the merged in revno
<lifeless> I'd like a datestamp
<beuno> so we don't pay the cost of the dotted revno
<lifeless> more than a revno
<mwhudson> i have to say
<mwhudson> i have _no idea_ what's going to appear in the "merged in" section
<lifeless> in a 'query again' interface, a revno is essential
<lifeless> in a 'click through' interface, its noise unless requested
<beuno> mwhudson, good enough reason to drop it  ;)
<beuno> if we do manage to load stuff more lazily, then the ajax bits would be a huge performance improvement
<beuno> igc's new API makes it pretty easy, and if we can tweak the plugin to save the cache somewhere else, everything is going to feel *very* fast
<beuno> but, AFAICT, we have to re-write quite a few bits in LH before being able to use it
<mwhudson> beuno: well, i harbour a perhaps naive belief that there is something useful to display here
<mwhudson> so about revision numbering
<mwhudson> the thing is that, in today's reality at least, numbering _one_ off-mainline revision does enough work to number them all
<mwhudson> so taking one revision number off the page doesn't really help
<beuno> mwhudson, if we don't fetch non-mainline revs in the changelog view, we can use jam's lazy revno API
<mwhudson> i think that would hurt usefulness too much
<phinze> eek! "[Errno 11] Resource temporarily unavailable"
<mwhudson> phinze: not as scary as it sounds, are you doing a diff during a commit or something?
<phinze> revert
<phinze> bzr break-lock, bzr: ERROR: The lock for '/home/phinze/proj/uiris3/trunk' is in use and cannot be broken
<phinze> but bzr info doesn't list any locks
<beuno> mwhudson, really? The default changelog view doesn't really have to display dotted revnos. We could check to see if it's mainline revs being navigated or not
<phinze> a ha
<phinze> found a zombie process
<phinze> that was running a diff | vim -
<phinze> disaster averted :)
<mwhudson> beuno: the unexpanded view doesn't, i guess
<mwhudson> beuno: can i ask you to step back some more?
 * beuno steps back more
<mwhudson> beuno: i'm trying to think about what information we want to display, and it feels like you're trying to optimize revno display
<beuno> alrighty
<mwhudson> beuno: so i actually think the unexpanded changelog view is more or less right already
<beuno> agreed
<mwhudson> in the drop down thingy
<mwhudson> i think we could show a bit more about the merged revisions
<mwhudson> beuno: do you remember this screenshot? http://people.ubuntu.com/~mwh/hacked_up_changelog_view_3.png
<mwhudson> obviously that's not right, but...
<beuno> mwhudson, yeap, showing more information would be good
<beuno> basically, bzr log -v, I guess
<mwhudson> yes
<beuno> I'd add the date next to the merged revs
<beuno> as lifeless pointed out
<mwhudson> yeah
<mwhudson> i do think branch nick is useful too
<beuno> sure, maybe even group commits by branch nick
<beuno> would make weird sorting sometimes though
<mwhudson> mm
<mwhudson> i guess you need to be careful about displaying too much information too
<mwhudson> argh argh where to start
<beuno> mwhudson, I can think of two (very different) places:  1) start refactoring things so we can be clearer about what is being accessed, or, 2) finally implement your screenshot
<beuno> something basic intially, just the revno, author, shortened commit message and date
<mwhudson> what i was trying to do last night was removing history.py somewhat
<mwhudson> i hate the way you have template -> controller -> history.py -> bzrlib
<mwhudson> it makes the intent so hard to unpick
<beuno> that sounds like my favorite thing  :)
<beuno> of course, it's probably the hardest
<mwhudson> but now i've bumped into this line of code
<mwhudson>             merge_revids = self.simplify_merge_point_list(
<mwhudson>                                self.get_merge_point_list(change.revid))
<mwhudson> which is where we started :)
<beuno> right
<beuno> maybe that flattens it into a list instead of a graph?
<beuno> I remember debugging it at some point
<mwhudson> so one interpretation of a 'merge point' is 'oldest mainline revision that has it as an ancestor'
<mwhudson> which is actually something that's a little annoying to determine with the command line client
<poolie> hello beuno
<beuno> hiya poolie
<igc> morning
 * beuno goes home, bb in ~20'
<igc> morning beuno, mwhudson
<beuno> mhey ig	
<beuno> er
<beuno> "hey igc"
<beuno> "I hate my internet connection today"
<mwhudson> hi igc
<veritos> Is it possible to pull just one directory from a repository, Ã  la Subversion?
<bob2> no
<veritos> Thank you.
<bob2> well, you could bzr split, but that doesn't reduce the amount of downloaded date
<jml> you know, that call was shorter than I expected :)
<mwhudson> yesd
<mwhudson> we only veered off once or twice, and not for very long
<jam> interestingly, it is easier not to veer off when you know there are 10 other people around
<jam> though it was still fairly long given that you have that many people to deal with
<jam> (it wasn't *longer* than expected, just expectedly long)
<mwhudson> beuno: i guess you're on the phone now?
<phinze> so i've got 6 distinct commits i want to pull out of trunk before we deploy, and i'm at a loss for how to proceed
<beuno> mwhudson, in theory, but not in practice
<phinze> reverse merge each one and commit?
<beuno> thumper left me for abentley
<mwhudson> beuno: heh
<abentley> beuno: It's alright, you can have him now.
<mwhudson> beuno: how long are you going to be around for tonight?>
<mwhudson> not necessarily for in depth discussion, just for sounding-board type stuff
<beuno> mwhudson, I have quite a few more things to do, so probably within the range of "hours", on and off while I go for a run and eat
<mwhudson> cool
<Peng_> phinze: Probably, yeah.
<jml> igc: the patch at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cd06a5cd30901260349v321f27a8uc1ab6a75bacb0f06%40mail.gmail.com%3E has all the tweaks in it.
<phinze> gah, some of the commits i want out of trunk are sub-commits of other commits
<phinze> sigh, i think i'm just going to comment out the crucial changes we don't want deployed :(
<Odd_Bloke> There doesn't seem to be a great deal of shelve/unshelve blackbox testing.
<Odd_Bloke> Is there ongoing shelve/unshelve work somewhere?
<spiv> Odd_Bloke: not that I know of
<spiv> Odd_Bloke: well, ISTR lifeless sent a small bug fix for it to the list recently.
<beuno> poolie, hi. Are there still known problems with the new progress bars, or should I report the bug that status text concatenates instead of replacing eachother?
<spiv> beuno: report
<beuno> will do, thanks spiv
<Odd_Bloke> spiv: OK, cool.  It seems there are a few things that could be made nicer, so I wanted to check I wasn't duplicating effort.
<Odd_Bloke> Do all new errors need a test in bzrlib.tests.test_errors?
<spiv> Odd_Bloke: yes, please.
<lifeless> spiv: its merged
<spiv> Odd_Bloke: it's amazing how easy it is to create an Exception with a broken __str__ :)
<Odd_Bloke> Heh, like the one I was about to commit. >.<
<lifeless> jam: if you return tonight, I filed a bug on annotate on thursday I think
<lifeless> vila: ^ or you
<Odd_Bloke> Two quick questions: 1: does 'shelf' seem like a reasonable bug tag to people (1.5: do we have a process for choosing bug tags?), and 2: what do people think of named shelves?
<lifeless> Odd_Bloke: yes.no nice
<spiv> Odd_Bloke: what lifeless said
<igc> jml: so merging that diff, the tip is "Jonathan Lange 2009-01-25 Blackbox tests, forgot to add these earlier."
<jml> igc: yep
<igc> jml: that include everything?
<jml> igc: it does.
<jml> igc: I just checked :)
<igc> jml: cool. Sending it off now ...
<jml> igc: thanks.
<lifeless> spiv: sync(
<eydaimon> I've got a checkout on a host blah@foo.com. I want to clone it to my laptop. bzr clone bzr+ssh://blah@foo.com/my_checkout  doesn't work. what am I doing wrong?
<eydaimon> the error is "ERROR: Not a branch"
<Peng_> eydaimon: The path is relative to the root, not your homedir.
<eydaimon> ok, thank you
<Peng_> eydaimon: So, unless you actually have a directory called "/my_checkout", alongside "/usr" and "/dev"...
<spiv> lifeless: the current code is at lp:~spiv/bzr/fetch-streaming
<Odd_Bloke> What does 'f' in the shelve prompt mean?
<Odd_Bloke> Looking at the code it means 'yes to all'.  So 'force'?
<lifeless> Odd_Bloke: sounds plausible
<lifeless> spiv: ok...
<lifeless> spiv: I'm fooding; may I ring?
<spiv> lifeless: sure.
#bzr 2009-02-10
<abentley> Odd_Bloke: It stands for "finish".
<Odd_Bloke> abentley: 'finish' implies "I'm done shelving things now, everything else should remain unshelved", whereas it seems to mean "shelve the rest" (which I would equate with a 'yes to (a)ll' option).
<Odd_Bloke> abentley: I would like to modify '(f)inish' to be 'yes to (a)ll' and create a '(d)one' which means no to all.  Thoughts?
<lifeless> Odd_Bloke: what about 'n(o) to all'
<lifeless> Odd_Bloke: its odd to have one side abbrev and one fully expressed
<Odd_Bloke> lifeless: I'm not sure that the meaning is symmetric.  That is to say, I don't expect 'yes to all' to change previous responses, but some part of my mind says that 'no to all' might change previous responses.
<lifeless> Odd_Bloke: yes to remaining, no to remaining
<Odd_Bloke> How about: '(y)es, (N)o, (s)helve remaining, (d)on't shelve remaining, (q)uit'?
<Odd_Bloke> For some context, I'm looking at bug #327429, so am adding a help option to the prompt (with these longer strings).
<ubottu> Launchpad bug 327429 in bzr "bzr shelve interactive prompt is inexplicable" [Undecided,In progress] https://launchpad.net/bugs/327429
<lifeless> does lp mark bugs as fixed when commits land?
<lifeless> mwhudson: ^
<mwhudson> nope
<mwhudson> we've been told to fix that soon, i understand
<abentley> Odd_Bloke: I don't want that.
<abentley> Odd_Bloke: I want it to behave the way shelf1 did.
<abentley> Odd_Bloke: Which is that it applies the current default to everything.
<abentley> Odd_Bloke: I especially don't want to use "d", because I want that to mean "diff".
<Odd_Bloke> abentley: 'the current default'?
<abentley> Odd_Bloke: That's why I changed it from "d", which is what shelf1 used.
<abentley> Odd_Bloke: Yes.  Shelf1 had a current default, either yes or no.
<abentley> Odd_Bloke: If you pressed enter, you got the default.
<abentley> If you pressed "f", it applied the default to everything.
<abentley> sorry, "d" for shelf1.
<Odd_Bloke> What determined that default?
<abentley> Odd_Bloke: The "i" key.
<abentley> Odd_Bloke: It was a toggle.
<Odd_Bloke> So if I get a '[yN..]' prompt, 'i' would change it to '[Yn..]' and 'd/f' would apply whichever the default was to the remainder?
<abentley> Yes.
<Odd_Bloke> Interesting.
<lifeless> that seems more complex, is it really more useful than y/n/Y-remaining/N-remaining/toggle-all/diff ?
<lifeless> s/useful/suable/
<abentley> lifeless: what's toggle-all?
<lifeless> invert-selection or whatever it was called
<lifeless> didn't shelve1 let you switch all the current selected hunks
<lifeless> not sure that that is needed even, to be honest
<abentley> lifeless: I don't think so.
<abentley> I'm pretty sure "i" just changed the default.
<lifeless> oh
<abentley> lifeless: Are you suggesting using capital letters for the "do-it-to-the-remainder" commands?
<lifeless> abentley: yes, in my sketch there
<spiv> "toggle-all" in shelve1 was "shelve --all; unshelve", and then the meanings of "y" and "n" were inverted :)
<Odd_Bloke> Using caps for options makes indicating the default harder.
<abentley> lifeless: I guess we could eliminate the "default" concept.
<abentley> lifeless: I'm less keen on using capitals to represent "do-it-to-the-remainder".
<abentley> I guess "a" and "v" have sometimes been used for Always and NeVer.
<lifeless> abentley: a and v would work too
<Odd_Bloke> I prefer the always/never option to the toggle-default option.
<abentley> Odd_Bloke: Yeah, I probably do, too.
<Odd_Bloke> OK, so go for: '(y)es, (N)o, (a)lways shelve remaining, ne(v)er shelve remaining, (q)uit'?  With a '(d)iff' option to come later.
<lifeless> I prefer different letters to caps on consideration
<igc> poolie: I think http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090130002957.52fd7d09%40gibibit.com%3E ought to go into 1.12rc as well
<igc> it's a small patch that I'll land later today if no-one else gets around to reviewing it
<Odd_Bloke> abentley, lifeless: Are you happy with the options I suggested at :40?
<lifeless> 11:37 < Odd_Bloke> OK, so go for: '(y)es, (N)o, (a)lways shelve remaining, ne(v)er shelve remaining, (q)uit'?  With a '(d)iff' option to come later.
<lifeless> ?
<abentley> Odd_Bloke: Yes.
<lifeless> I think quit should be '(c)ancel'
<lifeless> quit isn't clearly 'quit-and-do' or 'quit-and-abort'
<jelmer> so, ohloh finally has Bazaar support (-:
<mwhudson> beuno: hello?
<mwhudson> LarstiQ: you here/awake?
<beuno> mwhudson, hi
<mwhudson> beuno: have a look at this http://pastebin.ubuntu.com/116271/
<mwhudson> it's a template and some code
<mwhudson> i'm trying to think of ways of using bzrlib objects in templates, but still having nice spellings of things that are important to us
<beuno> mwhudson, looks good, although I don't think I understand very well why you have revinfo and revision
<mwhudson> revision is a bzrlib revision
<mwhudson> revinfo is a way of getting extra information about it
<mwhudson> maybe it would be better to wrap the bzrlib revision in some other object
<beuno> yeah, I kinda like accesing the revision in only one way
<mwhudson> is that a voted for a wrapped revision?
 * beuno thinks
<beuno> I think so. Is there something bad about it I'm missing?
<lifeless> mwhudson: what extra info?
<beuno> lifeless, I think it's more like branch info
<beuno> anyway, that's it from me today
<beuno> mwhudson, I'll read the backlog and reply tomorrow. Have fun  :)
<mwhudson> lifeless: revision number, formatted date
<mwhudson> nothing very deep, but i dislike having too much python in my templates
<lifeless> mwhudson: ok, so its RevisionInBranch not Revision
<lifeless> formatted date -> patch bzrlib please
<mwhudson> yes, i guess that makes sense
<mwhudson> bzrlib already has a RevisionInfo-that-is-really-RevisionInBranch
<Lag117> hello
<Odd_Bloke> Lag117: Hi.
<Lag117> anyone else get "bzr: ERROR: No module named PyQt4" when running "bzr help commands" in bzr 1.11?
<Lag117> used to work, not sure when it broke though
<Lag117> by work, I mean a list commands and brief desc was output in plaintext, not Qt GUI or anything
<Lag117> should I just try install PyQt4 manually? i.e. from http://www.riverbankcomputing.co.uk/software/pyqt/download
<igc> Odd_Bloke: I'd like to land your --no-tree patch but it's failing tests ...
<igc> test_sprout_branch_no_tree() for BzrDirFormat5 and BzrDirFormat6
<igc> Odd_Bloke: do you have a moment to tweak that?
<Odd_Bloke> igc: Sure, I'll look at it in a moment.
<igc> Odd_Bloke: thanks.
 * igc lunch
<spiv> Lag117: sounds like a bug in the qbzr plugin, maybe?
<Lag117> to list help?
<lifeless> Lag117: yes
<Lag117> spiv: just trying to run "bzr help commands" -- is qbzr plugin part of that?
<lifeless> Lag117: plugins can add commands
<Lag117> oh GREAT
<lifeless> Lag117: 'bzr --no-plugins help commands' will list commands without plugins
<Lag117> lifeless: that works
<Lag117> is there a verbose or something else to see more clearly where it fails?
<lifeless> -Derror will cause a traceback to be shown, I think
<lifeless> if not, then your ~/.bzr.log will have the import error traceback
<Lag117> sweet, `tail -f ~/.bzr.log` and then running `bzr help commands` shows the errors
<Lag117> should I paste it somewhere / file a bug?
<lifeless> Lag117: well, if its that pyqt4 isn't installed, I'd install it :)
<lifeless> if it stopped working, I'd chat to some of the qbzr guys, they do hang out here
<Lag117> lifeless: I tried, but getting errors trying to compile it
<lifeless> but they aren't on at the moment
<lifeless> perhaps ask a question at http://answers.launchpad.net/qbzr
<Lag117> I'll do that, great idea
<Lag117> another question, is it possible to kill a built-in plugin?
<Lag117> i.e. so I wouldn't have to add --no-plugins every time?
<Lag117> haha, I can't get PyQt installed from source or using MacPorts.  I'm a failure.
<poolie> spiv: hello?
<poolie> Lag117: just remove the directory
<poolie> which one?
<Lag117> poolie: "which one?" -> for spiv?
<poolie> for you
<Lag117> poolie: sudo port install py25-pyqt4
<Lag117> although it looks like maybe py-pyqt4 will work?
<Lag117> (trying it now)
<jdong> have fun building qt4 if you haven't :)
 * jdong inserts 80,000 leap seconds or so to pass the time
<jdong> would it be unreasonable for me to whine to the qbzr folks that setup.py should not build and/or install if it can't import pyqt4?
<Lag117> I am all for having a working bzr install, so no, not unreasonable
<Lag117> either make it work, or don't include it in base install
<lifeless> poolie: spiv is here hacking with me
<poolie> > Lag117: another question, is it possible to kill a built-in plugin?
<jdong> Lag117: oh it came with the default without bundling an qt4?
<poolie> which plugin do you want to kill?
<Lag117> poolie: qbzr
<jdong> poolie: the qbzr
<jdong> assumes on OSX  you have pyqt4 bindings
<Lag117> poolie: I can move /Library/Python/2.5/site-packages/bzrlib/plugins/qbzr/ ?
<poolie> lifeless: thumper and i have scheduled a meta-development call
<jdong> Lag117: yeah you can just remove that directory
<poolie> i don't know if maybe it's better to just let you two get on with actual development?
<jdong> though That's A Bug (tm) if the OS X version installs that by default
<jdong> where Bug = 99.9%-false assumption ;-)
<lifeless> poolie: my 2c would be that you two can have a meta-development call, and spiv and I will get streaming push pushed forward :P
<Lag117> jdong: are you saying it's just a problem with the OS X binary installer? that makes some sense
<jdong> Lag117: I know for sure the Windows installer properly bundles the QT libs needed for an out-of-box install
<jdong> Lag117: perhaps the OS X installer attempts to do so but fails
<jdong> I've never installed bzr from the OS X installer before; I've always used Macports for that
<Odd_Bloke> What's meta-development (and is this question meta-meta-development)?
<jdong> Odd_Bloke: I suppose that's where you hash out a working plan for what to work on :)
<jdong> and lifeless is conducting meta-meta-development.
<jdong> which I'll coin (meta^n)development for some integer n
<Lag117> PROBLEM RESOLVED, THANKS: cd /Library/Python/2.5/site-packages/bzrlib/plugins; sudo tar -cf qbzr.tar qbzr; sudo rm -rf qbzr
<jdong> while you're having fun, would you like to file/search for a bug on this?
<jdong> just so the people who do the OS X installer are aware
<Lag117> where is the proper place to file OS X installer bug?
<jdong> they probably are that 0.1% who lug around a 500MB or whatever QT4 install and never know that the bug exists ;-)
<Lag117> point me I'll happily file a bug
<mwhudson> anyone want to look at a loggerhead branch?
<jdong> Lag117: since it's a bzr installer issue I'd file it against launchpad.net/bzr unless the devs here tell you otherwise
<Lag117> jdong: will do, thanks again!
<jdong> sure thing, but thank YOU :)
<Odd_Bloke> igc: Just sent you (and the ML) a mail with an updated --no-tree patch.
<Odd_Bloke> We now error on old formats, and the test tests for this.
<Odd_Bloke> I don't know if you want to merge that without another BB vote, though. :)
<Odd_Bloke> Right, as I have to leave for work in just over 4 hours I should probably go to bed. :p
<Odd_Bloke> NN.
<Lag117> bug for my OS X installer issue: https://bugs.launchpad.net/bzr/+bug/327487
<ubottu> Ubuntu bug 327487 in bzr "bzr: ERROR: No module named PyQt4" [Undecided,New]
<Lag117> hmm, auto-bot?
<igc> thanks Odd_Bloke
 * igc offline for an hour or so
<mwhudson> mmm
 * mwhudson fails to see an easy way to get the most recent change for a path from a revision tree
<mwhudson> i.e. "inventory_entry.revision"
<Peng_> Is a copy of bzr.dev supposed to have 2 ghosts?
<lifeless> yes
<lifeless> mwhudson: tree.inventory[tree.path2id(PATH)].revision
<Peng_> lifeless: Thanks?
<Peng_> Hmm, am I going to bother to reconcile the inconsistent parent?
<lifeless> Peng_: up to you :)
<Peng_> I normally would, but I'm not sure this machine has the RAM to do it, so I rsynced it down, and really don't want to rsync a different version back up again.
<Kobaz> or at rackslice
<Kobaz> er
<igc> back
<mwhudson> man
<mwhudson> there's "not designed for testability"
<mwhudson> and then there's loggerhead
<Peng_> Oh good, I do have the RAM for reconcile.
<lifeless> poolie1: http://paste.ubuntu.com/116333/
<lifeless> igc: ^
<lifeless> pop quiz, which one is packs, and which is gc?
<lifeless> (they are both the first 2K revs of bzr.dev)
<Lag117> spiv: lifeless: poolie1: jdong: THANKS, YOU ARE GREAT HELP! Keep up awesome work :)
<igc> lifeless: gc is the latter?
<lifeless> yes :)
<igc> lifeless: so I always expected gc to be smaller. How's the speed in your tests?
<lifeless> ~ the same
<igc> sweet
<lifeless> random access ops need a large page cache
<igc> lifeless: I did run some gc-plain benchmarks last Friday but I'm yet to check them
<lifeless> and I want more instrumentation about where things are going on
<igc> (have been visiting Mum & Dad until a few minutes ago)
<lifeless> cool
<lifeless> igc: repo-details has support for gc now; it needs a bzr.dev, rather than a bbc branch when you invoke it, because of api changes in bbc
<lifeless> but the same repo-details code can also analyse a bbc branch if run from a bbc bzr :P
<poolie1> lifeless: nice
<davidstrauss> How experimental is "bzr join"?
<poolie1> fairly
<davidstrauss> What's the best vendor branching strategy at the moment, then?
<davidstrauss> ConfigManager looks ancient and unmaintained.
<poolie1> i would say probably using the scmproj plugin
<davidstrauss> Isn't that alpha code?
<poolie1> yes, but simple and actively maintained
<poolie1> lifeless: can you please make a 1.12 branch before you sign off?
<poolie1> now is fine
<davidstrauss> Is it release time?
<Sup3rkiddo> hi all, i am beginning to use bzrlib. and I am stuck at the type which 'source' belongs to when I call the pull method of the Branch class
<mthaddon> poolie1, lifeless: the looping PQM failure you saw a while back was that I'd added a script to "clean up" the chroot before each run, but it was failing on 4 temp files that were owned by root - these have been removed, so you okay for me to re-enable?
<poolie1> mthaddon: not today please, i'm about to do a release
<poolie1> now+24h would be ok
<poolie1> hm
<mthaddon> poolie1: ok, fair enough - will look at it again tomorrow (will check with you first)
<poolie1> do you know how root-owned files got in there?
<poolie1> our make check doesn't run as root (afaik)
<mthaddon> poolie they were from May 22nd of last year, so not recent in any way
<lifeless> poolie1: done
<poolie1> mthaddon: i don't suppose you noticed what they were?
<mthaddon> poolie1: empty files
<jeddy3> hmm, does bzr-svn warn about upgrading to subversion 1.5 always? seems like i have newest version, still it hints :|
<lifeless> jeddy3: you have svn 1.5 on the server?
<jeddy3> lifeless: yes, afaict
<lifeless> jeddy3: I'm not sure then - perhaps ask a question on https://answers.launchpad.net/bzr-svn
<jeddy3> lifeless: svn --version:
<jeddy3> svn, version 1.5.2 (r32768)
<lifeless> jeddy3: thats your client isn't it?
<jeddy3> svnserve --version:
<jeddy3> svnserve, version 1.5.2 (r32768)
<jeddy3> svnadmin: the same
<lifeless> jeddy3: thats still on your machine - I'm saying you need to ssh into the server or something (unless you've done that alread)
<jeddy3> lifeless: that is on the server, yes
<lifeless> jeddy3: ok, definitely don't know the answer then sorry :(
<lifeless> jeddy3: though I believe you have to do a dump-load on the repo to upgrade it
<jeddy3> lifeless: hmmmmm, the repo was svnsynced from a old repo, that might have something to do with it?
<jeddy3> lifeless: then it still might be a old repo i guess
<mthaddon> lifeless: any idea what's going on here - https://pastebin.canonical.com/13652/ ?
<lifeless> mthaddon: I think you're pasting text to me
<jeddy3> :D
<lifeless> poolie1: oh. 1.12 forgot the config, one sec
<poolie1> lifeless:  i forgot, i should have asked spm for the practice
<lifeless> poolie1: its ok :)
<lifeless> done
<mthaddon> lifeless: I am, yes - would you prefer me to paste it in channel?
<lifeless> mthaddon: just teasing :P
<lifeless> mthaddon: as it says, old format, can't lock over the wire
<mthaddon> oh, I'm a little slow - must be the jetlag...
<mthaddon> lifeless: should I ask stub to update the branch and that should fix it?
<lifeless> yes
<mthaddon> thx
<lifeless> that format apparently can't be used over bzr+ssh at all
<lifeless> I would file a bug on that, but don't expect it to get radical action
<poolie1> ah
<poolie1> that was me
<poolie> i think it was still a good idea though
<poolie> mthaddon: you must have been getting that warning for the last several months
<vila> hi all (still shaving so not quite still there)
<poolie> otoh you can't upgrade it yourself
<poolie> be careful, vila! :)
<vila> poolie: :-)
<mthaddon> poolie: yeah, I have only just tried to do this now - haven't tried to branch from this one before
<vila> I just replied to the standup mail where you said my https was complex, is there anything I can explain which could help ? (I didn't mean to make it complex, I even tried to avoid going too far there :-/)
<vila> s/my https/my https fix/
<poolie> hm
<poolie> i think i was transcribing john saying that
<poolie> i had not read it at that time
<poolie> mthaddon: either ask stub or file an lp ticket asking for an upgrade
<poolie> or are you a losa yourself?
<mthaddon> :)
<vila> poolie: ha, then may be he referred to the fact that I found nasty bugs in tests on the way...
<poolie> mthaddon: pqm seems to be neither accepting or rejecting my merges
<poolie> ie i sent one and i got neither mail nor anything in the web ui
<mthaddon> poolie: let me check the logs
<poolie> thanks
<mthaddon> poolie: when did you send it?
<poolie> a few minutes ago
 * poolie checks
<mthaddon> nothing in the logs...
<poolie> sorry, problem here
<mthaddon> ok, np
 * igc dinner
<poolie> vila, i get a failure in test_http with your patch
<poolie> about the deprecation
<poolie> it should be easy
<davidstrauss> .join #nexenta
<davidstrauss> oops
<poolie> vila, hi
<vila> poolie: Hello :)
<igc> poolie: I've sent that commit template patch off to pqm now. If it misses the RC, it would be nice to include it in 1.12 final.
<poolie> igc, thanks, i already branched
<poolie> seems ok for final though
<igc> poolie: I expected as much. np.
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test bzr 1.12rc1 (released 10 Feb) | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<poolie> woo
<Peng_> Congrats :)
<Kinnison> poolie: ace.
<poolie> hello kinniwinnie!
<poolie> reading the news for this release it's just ian ian ian :)
<Kinnison> Heh
<Peng_> poolie: Maybe that should be the codename. :D
<poolie> maybe it should have been
<Youssef> hi
<poolie> ok i think that's enough for me
<Youssef> Lo-lan-do: are you threre?
<poolie> have a good day or night as appropriate
<Youssef> lol
<Youssef> a good day for me
<Lo-lan-do> Yes
<Mez> hey, is there a way with bzr to make sure that all branches are automatically binded upstream. Pretty much so it works like svn, but so you can also --local or similar (bzr seems to work better with merging)
<Mez> I'd say something like binding a repo, rather than a branch
<Lo-lan-do> Mez: Use locations.conf
<Youssef> okay Lo-lan-do see the error i get after a commit under windows
<Lo-lan-do> bound_location = bzr+ssh://...
<Lo-lan-do> bound_location_policy = appendpath
<Lo-lan-do> bound = True
<Lo-lan-do> ...all that in a [/path/to/local/repo] block
<Mez> that should work
<Youssef> Lo-lan-do: see http://rafb.net/p/fjwkwU75.html
<Youssef> and?
<bialix> it's a know bug. poke spiv about it
<bialix> I'd say it harmless
<Youssef> but one thing! the checkout works well
<Youssef> but i have this error log
<Youssef> bialix: can you give me the adress to this reported bug please?
<bialix> please, looking for in the bzr bugtracker. I'm sure I've filed this bug in the past
<bialix> perhaps it's tagged with "win32"
<Youssef> bug tracker?
<Youssef> where is it?
<Youssef> sorry if I disturb you man
<Youssef> hihi ^^;
<bialix> @launchpad.net/bzr
<Youssef> thanks
<Youssef> https://bugs.launchpad.net/bzr/+bug/327558
<ubottu> Ubuntu bug 327558 in bzr "windows checkout raise an 10054, 'Connection reset by peer' error" [Undecided,New]
<Youssef> my bug
<Youssef> any comment?
<Lo-lan-do> Did you find the previous bug?
<Youssef> wich?
<Lo-lan-do> The one filed by bialix
<Youssef> the only one from bialix is https://bugs.launchpad.net/bzr/+bug/307270
<ubottu> Ubuntu bug 307270 in bzr "bzr pull lp:bzr wo ssh key: password prompt + empty password = traceback" [Undecided,Confirmed]
<Youssef> they are not alike
<Youssef> hihi ^^;
<ronny> moin
<Youssef> ronny ?
<Youssef> what are you saying?
<ronny> jelmer: can bzr's internal db be extended to additional object types?
<bialix> ronny: hi
<bialix> ronny: you're the author of anyvc, right?
<ronny> yeah
<bialix> I've looked at your project a bit
<bialix> seems interesting
<ronny> thanks :)
<bialix> and perhaps could be useful for scmproj
<bialix> where its development happens? it has ML? irc channel?
<ronny> i developed it as part of the pida ide
<ronny> so pidas irc channel/google group is the right place to take a look
<bialix> so you're the author the pida ide as well?
<ronny> im one of the core devs, the orginal author is ali afshar
<bialix> the code seems a bit coupled to the pida itself, it's not generic enough, does it?
<ronny> anyvc is fully extracted and not coupled
<ronny> needs nothing of pida
<bialix> I mean at design ideas
<bialix> level
<ronny> nothing there, too
<bialix> well, then it was wrong impression
<ronny> the usage from pida is rather simple - invoke anyvc in another thread
<bialix> I'd like to clarify my interest: I'm working in scmproj -- it's a vcs-agnostic emulation of nested trees/repos/submodules etc.
<bialix> so your lib will be in help to support mixed projects
<bialix> where there are components checked out from different vcs
<bialix> I need to finish some other things in scmproj, then I'l ltry to look at your lib closer
<ronny> so single branch management would come in handy
<ronny> cause thats one of the things i need to get done rather soon
<bialix> single branch?
<ronny> basically get me "rev x from repo/branch y into this dir"
<bialix> yes, agreed
<ronny> however it might tricky to get that working with stuff like darcs
<bialix> I can help from bzr point of view
<bialix> yeah, darcs is special there
<ronny> bzr should be the most easy there
<ronny> just a branch
<bialix> ronny: am I understand correctly you mostly familiar with hg?
<ronny> yeah
<bialix> bzr branch model a bit different from hg/git
<ronny> yeah
<bialix> so maybe we need to cooperate on this
<ronny> bialix: http://ronny.uberhost.de/2009/1/12/reasonable-abstractions-of-vcs-history-and-branching <- this is my basic highlevel idea, the bits  about the relations might need some changes
<bialix> ok, I'll read it
<ronny> bialix: i took quite some time to figure this first iteration, its not quite right, but a reasonable starting point
<bialix> ok, anyway I'm tabula rasa today. Maybe I'll can suggest something reasonable. will see
<ronny> tabula rasa?
<bialix> empty mind
<bialix> http://en.wikipedia.org/wiki/Tabula_rasa
<bialix> i.e. I'm not ready tosay anything smart yet
<ronny> hmm
<ronny> btw, personaly i belive git-style content addressed databases are the way to go, just git isnt
<beuno> mwhudson, FYI, I did upload LH to the bzr PPA when I released
<vila> verterok: hi
<verterok> vila: hi!
<vila> 1.12rc1 is out, do you think you can do an OSX-10.4 dmg for it ?
<verterok> vila: yes. but not until friday :( (I'm not at my home, and don't have my ibook with me)
<beuno> vila, I'll let you in on a little secret, verterok now has a newer mac, so he can actually build for both versions!
 * beuno runs
<vila> ha rats
<vila> hehe, which one ?
<beuno> the new and shiny mackbooks
<verterok> vila: the aluminum
<vila> unibody ? 15" ? 17" ?
<vila> they are gorgeous...
<vila> verterok: jokes apart, will you be able to build for both 10.4 and 10.5 ?
<verterok> vila: unibody 13'
<verterok> vila: I'll try to talk with somebody at home, and try to plug my ibook to the net, if I can get that building the dmg its just a matter of ssh :)
<vila> verterok: that would be awesome !
<verterok> vila: I'll need to create the installer for 10.5, or talk to phanatic to get his installer sources
<verterok> vila: once that donem I can build the dmg
<vila> verterok: it would be good if you can notes doing that, I'd like to be able to a be backup for building them
<vila> s/can notes/can take notes/
<verterok> vila: the best case, is that phanatic has the 10.5 installed source pushed to some public location :)
<verterok> vila: cool
<verterok> beuno: are you back in .ar? would you mind to go to my home and plug my ibook? :p
<verterok> ;)
<beuno> verterok, I am!   hahah
<beuno> I could...
<verterok> beuno: welcome back!
<beuno> verterok, thanks  :)
<verterok> beuno: for the moment isn't neccesary, I think my parents should handle the task. i'll let you know otherwise.
<beuno> although I leave on Sat again
<beuno> Berlin
<vila> verterok: beuno said: "runs" minutes ago, I think he's on his way to your home
<beuno> so if you're around here before that, we can have some lunch or dinner  :)
<beuno> vila, it's too hot to run. I probably meant "gets on a taxi"  :)
<vila> rats, you happy guys, there is a storm here with rain and wind going up to 140km/h (they said, but 95km/h has been observed this morning)
<vila> fullermd: ping, what was the funny option you used with 'date' and '1234567890' ?
<awilkins> What's the recommended Python version for bzr? 2.5 or 2.6?
<verterok> awilkins: I keep using 2.5 for bzr
<vila> awilkins: 2.5
<vila> pqm runs 2.4, almost everybody else runs 2.5
<Odd_Bloke> Why do we still support 2.4?
<Lo-lan-do> Odd_Bloke: Etch and Dapper?
<Lo-lan-do> Bah, scrap Etch, 2.5 is available there too.
<Lo-lan-do> Maybe other distros :-)
<Odd_Bloke> Lo-lan-do: But can you run recent versions of bzr on Dapper anyway?
<Odd_Bloke> And the RPM distros won't have it because they don't seem to support multiple versions of Python.
<Lo-lan-do> Don't look at me, I don't think I installed Dapper even once.
<Odd_Bloke> Fair enough.
<Lo-lan-do> I still have quite a few Etches, but they'll migrate to Lenny pretty soon after the release (unless all my potential clients demand to become actual clients *right now*).
<nevans> ugg... just encountered a nasty bug with "bzr svn-push".  reporting it now, then I'll see if I can reliably replicate it.
<Odd_Bloke> My one server is tracking lenny ATM.
<nevans> hmm... never mind.  it would appear to be a bug in trac, not a bug in bzr-svn.  :-)
<nevans> trac was reporting the changeset incorrectly.  "svn log -v" shows everything is okay.
<jam> jelmer: I'm working on the 1.12rc1 win32 installers, should I be using bzr-svn 0.5, or still 0.4.17?
<verterok> yay! ohloh.net just added Bazaar support!
<jelmer> jam, 0.5.0
<jam> jelmer: did we get clear "upgrading bzr-svn" notes written?
<jelmer> jam, see UPGRADING in the source tarball
<jelmer> They're quite short though
<Lo-lan-do> verterok: Yay indeed :-)
<jam> abentley: if you get a chance, can you release bzrtools 1.12? I'm trying to put together the win32 installers
<LarstiQ> mwhudson: I'm alive again now.
<yee> does someone knows how to update a remote working tree using bzrlib??
<abentley> jam: sure
<LarstiQ> oh hey 1.12
<Lo-lan-do> yee: There's a plugin for that.
<LarstiQ> yee: the bzr-upload and push-and-update plugins do work in that area.
<NfNitLoop> the web site claims that "A candidate for the 1.11 release is also available, released on the 10th of February."
<NfNitLoop> typo?  ;)
 * NfNitLoop reads up on the changelog. 
<yee> the thing is I'm building a webapp wich needs to push local changes to a remote branch, and I'm using bzrlib to open the branches and push from one to the other
<yee> but the working tree doesn't get updated
<NfNitLoop> yee: that's by design.
<NfNitLoop> 1) bzr push doesn't require that bzr be installed on the remote location.
<NfNitLoop> (which is nice)
<NfNitLoop> 2) because of that, recontructing a working tree would require re-pushing things as plain files, uncompressed.
<NfNitLoop> which would be slow.
<NfNitLoop> so, it doesn't happen.
<NfNitLoop> If you need to reconstruct a working tree, you should connect to the server and do a pull.
<NfNitLoop> Or, if you don't mind 2 steps, you could push, then log in to the server and update.
<yee> and there's nothing in bzrlib that can allow me to update the remote tree?
<NfNitLoop> You know, I see that complaint so often, maybe an option to recontruct the working tree would be nice...
<NfNitLoop> but I don't know that it exists yet.
<NfNitLoop> yee: how are you pushing?  over ssh?
<LarstiQ> NfNitLoop, yee: more importantly, updating the working tree involves dealing with conflicts
<NfNitLoop> LarstiQ: aah, good point.
<LarstiQ> yee: 1) are you sure you actually need the working tree 2) you can call plugin code via bzrlib too
<yee> I'm creating a Branch object and use the push method
<yee> it would be a fast forward
<yee> but I can't login with ssh beacuse I need to set the password and this needs to be done by the webapp
<LarstiQ> yee: ssh keys instead of passwords might be a good idea, but anyway
<LarstiQ> yee: could you explain more of what the webapp does, why is it pushing a branch, what does it need to do?
<LarstiQ> yee: say, why do you need both a bzr branch and a working tree present?
<lucypher> Hi, I can't undestand how ingore works
<yee> its like a frontend for the repository, the files get edited on the web, or by uploading them, and then the changes need to propagate to the production servers
<NfNitLoop> lucypher: Which part are you having trouble with?
<lucypher> I'm trying tpo ignore an entire folder
<LarstiQ> yee: ah, I see.
<lucypher> I did bzr ignore app/tmp
<LarstiQ> yee: can you guarantee no local changes on the remote working tree?
<yee> yes
<LarstiQ> yee: good, that's the easy case :)
<NfNitLoop> lucypher: had you already `bzr add`ed things in that directory?
<lucypher> NfNitLoop : yes
<LarstiQ> yee: I think I'd look at the bzr-upload code if I were you.
<NfNitLoop> lucypher: that's your problem.   Ignore only ignores files that you haven't specifically versioned.
<NfNitLoop> lucypher: anything you add manually will still be versioned.
<LarstiQ> yee: combining that with the push on Branch you're already doing should cover your needs afaics
<lucypher> how do i remove these files?
<NfNitLoop> bzr remove --keep  path-to-dir
<NfNitLoop> (assuming you want to keep the files, but just remove them from bzr)
<yee> LarstiQ: ok, i would look into that
<LarstiQ> yee: if you're feeling ambitious, rework it into bzr core as a --yes-i-know-no-local-changes or somesuch option to push
<LarstiQ> mwhudson: I'm going offline for a bit again, if you didn't transiently need me, please contentfully ping again :)
<Goundy> yope :)
<Goundy> How to delete a branch forgot ^^
<lucypher> NfNitLoop : thanks, so the next time I have to set ignores before the first bzr add .
<NfNitLoop> lucypher: Yep. it's a good idea.
<NfNitLoop> Just make sure to skim the changelog to your initial `bzr add .` and see if there's anything you didn't want to go in there. :)
<NfNitLoop> then you can go "oops"  `bzr revert .`  `bzr ignore xyz`   `bzr add .`
<NfNitLoop> Goundy: are you asking how to delete a branch?
<Goundy> NfNitLoop indeed.. Sorry for the weird sentence !
<NfNitLoop> Goundy: Just delete the directory that it's in. :)
<Goundy> NfNitLoop oh? nice ^^ thank you
<Goundy> NfNitLoop but wait I want it to disapear from my launchpad repo
<NfNitLoop> OH.  Sorry.  I'm not sure about that.
<Goundy> hmm
<Goundy> NfNitLoop well the question is: How to delete a branch from a repository :-)
<NfNitLoop> so if you have /repo/branchXYZ
<NfNitLoop> you just rm -r /repo/branchXYZ
<Goundy> NfNitLoop I don't have ssh access on launchpad ;)
<NfNitLoop> ah, *on launchpad*.
<Goundy> NfNitLoop bzr branch -delete
<Goundy> :-)
<Goundy> it doesn't work >_<
<Goundy> wrong ingo
<Goundy> info
<santagada> Goundy: doesn't launchpad have some UI for this on the website?
<Goundy> santagada it does was just asking how to do it through bazaar so I know for future use ;)
<santagada> Goundy: you need to have access to the repo to do on the server side... that's why it uses an web ui on launchpad
<Goundy> ah i get it
<Goundy> thank you
<santagada> Goundy: this is just speculation on my side... but I read the bazaar docs and it had nothing about removing it with a remote command
<santagada> s/it/a branch
<Goundy> santagada k :)
<Odd_Bloke> Is BB down for anyone else?
<LeoNerd> BB?
<Odd_Bloke> BundleBuggy.
<abentley> Odd_Bloke: Fixed.
<abentley> jam: released.
<santagada> I wash seeing the Linus Torvalds google talk about git and he talks about annotating and knowing the history of a function
<santagada> like something that got moved from one file to another
<santagada> is this possible with bzr?
<BasicOSX> Did the bzrtools.dev repo move? I see Aaron's announcement about 1.12.0 but a 'bzr update' doesn't update and
<BasicOSX> 'bzr plugins' shows 1.11.0
<BasicOSX>  http://bazaar.launchpad.net/%7Eabentley/bzrtools/bzrtools.dev/
<jbermudes> hello!
<jbermudes> What does it mean when one tries to push and an error is returned "Cannot lock lockDir...Transport operation not possible. HTTP does not support mkdir()" ?
<Lo-lan-do> jbermudes: You're trying to push to a branch through HTTP, which isn't possible as far as I know.
<Lo-lan-do> HTTP branches are read-only.
<jbermudes> so saying bzr push lp:blahblah uses HTTP?
<jelmer> abentley, Where is the main bzrtools branch these days?
<Jc2k> jbermudes: unless you tell it your launchpad login, then it uses bzr+ssh afaik
<jelmer> hi Lo-lan-do
<Lo-lan-do> jbermudes: Not sure about lp.  It may do the right thing if you are registered with Launchpad.
<Lo-lan-do> Hi jelmer.  Did you recover? :-)
<jbermudes> Lo-lan-do, so to be safe, I should just specify the full URL using sftp?
<abentley> jelmer: http://bazaar.launchpad.net/%7Eabentley/bzrtools/bzrtools.dev/
<jelmer> Lo-lan-do: Somewhat :-)
<jelmer> Lo-lan-do, how was the rest of FOSDEM for you?
<Lo-lan-do> jbermudes: I'm clueless about lp.  I suggest reading bzr help plugins/lp
<jbermudes> Lo-lan-do, sorry! Thanks though for helping me get on the right track. :-)
<Lo-lan-do> jelmer: It was my first time there, and I'm not sure I liked it.  Too many people for me, I think.
<Lo-lan-do> Interesting talks, though.
<Jc2k> Lo-lan-do: same for me. not really too many people, just that the halls were too congested
<jelmer> Yeah, they should really find a bigger location :-/
<Jc2k> its too short, i didnt even get to see the jhbuild/buildbot guys in gnome
<wally> can bazaar be stored on a samba share?
<Kobaz> i wouldn't see why not
<Tak> I'm doing that
<wally> i don't see why not either, need to know for sure though
<wally> cool
<wally> thanks.
<Tak> in fact, I'm using a samba share as a bridge between a locked-down svn server and my local bzr branches
<Lo-lan-do> jelmer: You told me you figured out how to fix the bzr-svn slowness, but that meant just understanding, right?
<Lo-lan-do> (If not, I regret to have to mention it still happens with current r2529)
<alefteris> I get the following with bzr status, any ideas?
<alefteris> Conflict adding file sites/all/themes/zenubuntu/images/gr/ubuntu-gr-developers-1.png.  Moved existing file to sites/all/themes/zenubuntu/images/gr/ubuntu-gr-developers-1.png.moved.
<alefteris> I have deleted the .moved file
<fullermd> vila: date -r1234567890
<alefteris> nevermind
<lifeless> jam: so, http://paste.ubuntu.com/116333/ 2000 revs of bzr.dev, 1.9 and gc-plain
<wally> is there any case where mercurial is better than bzr?
<jam> 25MB => 9.4MB is pretty nice.
<lifeless> wally: I don't think so :P
<lifeless> wally: but I'm an author of bzr, so can't claim an unbiased opinion
<Lo-lan-do> Isn't mercurial still mostly faster than bzr?
<Lo-lan-do> Like for startup times?
<lifeless> Lo-lan-do: yes, its starts up faster
<lifeless> but hot cache bzr starts up in ~200ms
<lifeless> and its a python issue so not trivial tojustfix
<lifeless> and thats fast enough not to be an issue for most use cases
<Lo-lan-do> Yeah, I understand it's hard to fix and mostly good enough for now.
<Lo-lan-do> There's still one use case where it gets annoying: when you "grep -rl something . | xargs emacs" and Emacs runs bzr on each file.
<Lo-lan-do> Presumably to check if it's up-to-date, I didn't check.
<lifeless> argh
<Lo-lan-do> When you have several files in the set, you can wait for a minute or two before being able to do anything in the editor.
<lifeless> yes that will blow
<lifeless> emacs should just 'bzr st'
<lifeless> at least, if you have under 5K files its basically the same time as 'bzr st FILE'
<lifeless> so if there are > 5K files, then do 'bzr st FILES'
<Lo-lan-do> I'm not sure it's even aware of its own behaviour.  I believe the hook is called when opening a file.
<Lo-lan-do> [pid 21600] execve("/usr/bin/bzr", ["/usr/bin/bzr", "status", "Makefile"], [/* 42 vars */]) = 0
<Lo-lan-do> Argh.  It even runs bzr status *twice* on each file.
<Lo-lan-do> http://pastebin.com/d7f9f6dca
 * Lo-lan-do reports that as a bug
<jam> lifeless: I just submitted http://bzr.arbash-meinel.com/branches/bzr/jam-integration which clearly has tags
<jam> and the merge was accepted
<jam> but there are still no tags in "http://bazaar-vcs.org/bzr/bzr.dev"
<lifeless> possibly an old branch format instance lurking somewhere I guess
<lifeless> though I am pretty sure trunk is all upgraded
<mwhudson> good morning
<jam> The http branch itself in 1.9 as expected
<jam> So it only leaves the "hidden" pqm branch
<jam> morning mwhudson
<lifeless> jam: $ bzr info
<lifeless> Repository branch (format: 1.12-preview or 1.9)
<jam> lifeless: can you do "bzr tags" on that branch, just to see if they are getting that far, and just not propagating out?
<lifeless> jam: it does not have the tags
<bialix> fullermd: what is topic of the day?
<fullermd> Furbys: Are they really out for your blood, or is it just a clever disguise?
 * jelmer tries to remember what Furbys were
<Lo-lan-do> Animated plush toys.
<fullermd> Evil.  They're pure distilled evil.
<wally> trying to do bzr init on a samba share:  bzr: ERROR: Transport error: [Errno 95] Operation not supported: '/home/ryan/.gvfs/goldfields on redbull.rec.ri.cmu.edu/Software/bzrtest/.bzr' [Errno 95] Operation not supported: '/home/ryan/.gvfs/goldfields on redbull.rec.ri.cmu.edu/Software/bzrtest/.bzr'
<Tak> do you have it mounted, or are you using a smb:// url?
<wally> i am using smb:// url
<Tak> ah - I'm using a mounted share
<wally> it works with mounted share
<wally> but that only runs as root right now, tr ying to fix.
<wally> any quick fixes?
<Tak> I don't know of any; others may
<jelmer> jam, subvertpy will also need to be included in the windows installer
<lifeless> wally: hmm, I wonder what operation is failing; possibly oslock()
<jam> jelmer: it isn't installed as part of "setup.py install" for bzr-svn?
<jelmer> jam, no, it's a separate package
<wally> i think so lifeless
<jam> jelmer: any chance you could send a diff of 'build_release.py' to build it?
<jam> is it an entirely separate package?
<jam> (as in I need to 'bzr branch' from launchpad?)
<jelmer> jam: yeah, I should be able to (though I don't have Windows around here atm)
<jelmer> jam, yeah, it's completely separate
<wally> fixed by using CIFS in usermode via /etc/fstab
<jelmer> jam, what do we do to install paramiko atm?
<jam> just have it on the machine
<jam> py2exe picks it up
<jelmer> jam, so it doesn't come with the bzr installer?
<jam> it should
<mwhudson> beuno: hey, review this http://pastebin.ubuntu.com/116598/
<jam> I'm saying we don't do anything specially to package it
<jam> having it installed in the machine that is building the installer is enough
<beuno> mwhudson, looking
<jelmer> jam, AhÂ¸ ok
<jelmer> jam, I would expect it to work similarly for subvertpy
<jam> well, we have to specially handle the other plugins
<jam> and 'bzrlib' never imports subvertpy
<jam> like paramiko
<kfogel> mwhudson: just some context: sylvain beucler is (somewhat) essential to the emacs->bzr switchover.  Not that you have to treat him with kid gloves, but just be aware that we (well, I) will be having repeated interactions with him for some time :-).
<beuno> mwhudson, looks good. Want to add in the simpletal version as well in?
<mwhudson> kfogel: i've gathered
<mwhudson> beuno: i guess that makes sense
<lifeless> jam: is 4 seconds per hundred about right for knit->chk conversion of bzr.dev?
<jelmer> kfogel, congrats on getting your first bzr patch in btw :-)
<lifeless> now, how about bzr svn-serve?
<kfogel> jelmer: thanks!  (Did that happen?  I haven't opened up that folder yet today.)
<jelmer> jam, ah..
<jam> lifeless: I've never done the conversion outside of my "hacks" branch, which cheats to be a lot faster
<lifeless> jam: kk
<lifeless> $ time ~/source/baz/repository/bzr branch ../bzr.dev chk-gc/t -r 2000
<lifeless> bzr: ERROR: Unknown record type: '\x89'
<lifeless> hmmm
<jelmer> kfogel: yep, Ian merged it
<lifeless> back shortly
<kfogel> jelmer: Yay!  I wish it were a more important bug, but at least it was one I could do something about :-).
<lifeless> jam: ah, pack() is broken in gc
<mwhudson> beuno: i don't think there's been a simpletal release in three years
<keithy> hi I just upgraded from 1.3 to 1.11 on windows box and something isnt happy
<mwhudson> and it doesn't seem to be installed in such a way that pkg_resources can find it
<keithy> is there a self test
<mwhudson> keithy: bzr selftest
<wally> awesome, thanks for the help
<wally> got everything working
<beuno> mwhudson, fair enough. And we haven't gotten any bugs about it either.
<mwhudson> right
<mwhudson> kfogel: does beuc IRC?
<lifeless> jam: ping
<kfogel> mwhudson: he seems to say not
<kfogel> in an email he posted to emacs-devel, he sai:
<kfogel> said:
<kfogel> It's not the first time savannah-hackers is carbon-copied in the
<kfogel> middle of a conversation. If you have a request, follow
<kfogel> http://savannah.gnu.org/contact.php and explain things clearly.
<kfogel> For reference, the IRC channel is not a support channel but an admin
<kfogel> coordination channel, and #savannah-hackers isn't the right name.
<jam> lifeless: pong
<lifeless> jam: I'm just pushing to my bzr-groupcompress preliminary support for chk-gc
<mwhudson> kfogel: ok, thanks
<lifeless> jam: but there are two problems; something in bzr.dev broke pack()
<lifeless> jam: so it can't fetch more than 10 batches
<lifeless> jam: and for some reason, it is ending up with a xml inventory in the store
<jam> weird
<jam> is this in your gc plugin?
<lifeless> yes
<lifeless> revno 25
<lifeless> $ ~/source/baz/repository/bzr repository-details chk-gc/
<lifeless> bzr: ERROR: exceptions.ValueError: not a serialised CHKInventory: '<inventory format="5" rev
<lifeless> I also taught repository-details how to handle gc VFs objects correctly
<lifeless> fetching -r800 into --gc-plain-chk worked
<lifeless> of bzr.dev
<lifeless> by 'worked' I mean, I got a tree :)
<lifeless> and I can run log -v
<mwhudson> beuno: ok to merge that then?
<beuno> mwhudson, yeap
<mwhudson> ta
<lifeless> jam: found the issue I think
<jam> ??
<lifeless> the monkey patch to compatible
<lifeless> I hope :P
<lifeless> probably several things in fact
<jam> InterPackRepo.is_compatible = staticmethod(pack_incompatible)
<jam> that one?
<igc> morning
<jam> you need to include a "chk_support" in that code
<jam> at least looking at it, RepositoryFormatPackGCPlainCHK is defined but not part of the "incompatible" check
<lifeless> yes, also I need to cubclass CHKInventoryRepository
<jam> morning igc
<jelmer> am I right to think that upgrades to brisbane-core will require rewriting of the revision XML as well, since the inventory sha changes?
<jelmer> If so, any chance we can fix the XML escaping too?
<jam> jelmer: probably, though that is pretty cheap versus rewriting the inventory
<jam> jelmer: what escaping?
<jelmer> jam, right now some characters are escaped at commit-time because they can't be used in XML
<jelmer> jam, except the escape character is not escaped
<jelmer> which makes it impossible to do proper unescaping
<jelmer> and which requires plugins like bzr-svn to do escaping of XML-invalid characters in their commit messages during pull
<lifeless> jelmer: Its not part of the focus for brisbane core
<lifeless> jelmer: patches appreciated :P
<igc> hi jam
<jelmer> lifeless, I wish I got a dollar for every time you said that :-P
<lifeless> jelmer: I wish I got patch for every time I say it !
<lifeless> jelmer: btw have you had a look at why your text reconstruction is slow?
<jelmer> lifeless, me being dulwich?
<jelmer> I'm quite sure why it is so slow, just haven't gotten round to fixing it yet. We need to LRU cache delta bases as well as not do as much string copies during delta apply
<jam> jelmer: would bzr-svn 0.4.17 still work with 1.12?
<jam> As near as I can tell, getting subvertpy bundled is going to be non-trivial
<jelmer> jam, it's not just a matter of running install similarly to what we do for modules?
<jam> jelmer: best I can say is "maybe"
<poolie> hello all
<jam> getting it built into the package
<jam> seems like it requires a different path
<jam> hi poolie
<jam> more like updating "setup.py" to know it needs to be included
<jam> jelmer: subvertpy doesn't sit in bzrlib/plugins, right?
<jelmer> jam, no, in the python path
<jelmer> jam, what about qbzr's dependencies?
<jam> jelmer: pyqt et all are custom handled in setup.pfy
<jam> setup.py
<keithy> I installed bazaar 1.11 on tiger using pacports is that a tested combo
<keithy> macports*
<jelmer> jam: theirs or ours?
<keithy> its not working properly
<jam> jelmer: bzr's setup.py has code to bring in the PyQT libs if we are running py2exe, IIRC
<lifeless> jeyes
<lifeless> jelmer: yes
<keithy> ah, sftp works, but bzr+ssh doesnt!
<bob2> keithy: ssh remotehost bzr rocks
<lifeless> jam: pushing a better groupcompress
<jam> lifeless: I don't think you wanted this:
<jam> +    if chk_support:
<jam> +        formats = formats = (RepositoryFormatPackGCPlain,)
<jam> pretty sure you wanted "+"
<keithy> bob2 I dont understand
<lifeless> jam: yeah
<keithy> ok, bzr log sftp://name@host/dir/branch works
<keithy> ok, bzr update sftp://name@host/dir/branch doesnt
<bob2> keithy: run that command
<bob2> keithy: a common reason for bzr+ssh not working is bzr not being in PATH on the remote side
<keithy> ah that might be it
<eleftherios> what's the best way to setup a secure bazaar repository on my server without giving an ssh account to contributors?
<jelmer> jam, I would think this should take care of it: http://samba.org/~jelmer/tmp/setup.py-svn.diff
<jam> jelmer: for subvertpy-0.6.1, for some reason it is trying to copy "libapr.dll" into bzrlib\plugins\svn
<jam> shouldn't 'py setup.py install' for subvertpy not know anything about bzrlib and bzr-svn?
<jelmer> jam, yeah, that's a bug - it was fixed in r2014
<keithy> ok "It sure Does!"
<jam> jelmer: so... can't use a tag for subvertpy?
<jelmer> jam, you can, if you give me a second to release :-)
<jelmer> jam, try subvertpy-0.6.2
<keithy> ok now I am getting error not a branch
<jam> jelmer: what revno?
<jelmer> jam, 2021
<jam> just waiting for things to propagate
<jelmer> (tag:subvertpy-0.6.2)
<keithy> checkout lightweight seems to work
<jam> sure, http://bazaar. only has 2020
<jelmer> it would be nice if launchpad had a "Mirror now" button for bazaar branches, just like it has for foreign imports
<mwhudson> yes it would
<keithy> so I am getting "not a branch errors when it is a branch
 * jelmer fears the day Launchpad becomes Open Source
<mwhudson> you can do it through the api
<poolie> jelmer, why?
<mwhudson> jelmer: because we'll just say "patches welcome" to everything?
<jelmer> mwhudson, yes, it would make it harder to complain about stuff
<poolie> hopefully when it's released we'll get patches merged and running quickly
<poolie> if they languish it will suck
<beuno> sssssh, don't rat us out  ;)
<keithy> I'll try a fresh check out
<poolie> beuno: i heard you're not coming to brisbane after all?
<keithy> is editing the location file a bad idea?
<beuno> poolie, no  :(  I suck
<beuno> poolie, you know how priorities are handled sometimes, especially considering the location of the other one....
<jelmer> poolie, yeah, I'd be curious to see how that works out. There don't seem to be a lot of other centralized projects FOSS projects
 * beuno -> home
<beuno> bbiab
<jam> jelmer: are you sure 2021 is uploaded? I still haven't seen it yet on http://
<jelmer> jam, It's a mirrorred branch
<jelmer> jam, the original is on http://people.samba.org/bzr/jelmer/subvertpy/trunk
<jam> ah, so that is hours to trigger ...
<jelmer> this is why it would be nice to have a "Mirror now"  branch on LP like there is for vcs-imports
<lifeless> jam: can you think of any reason pack() shouldn't use get_record_stream now ?
<jam> lifeless: rather than Packer?
<lifeless> in packer
<lifeless> gc packis broken
<lifeless> because it reimplements get_record_stream basically
<lifeless> http://paste.ubuntu.com/116614/
<lifeless> jam: ^ some stats
<lifeless> spiv: so, how are we getting together
<spiv> lifeless: the weather is cool... feel like a change of scene, i.e. Hornsby?
<lifeless> sure, I can pop up
<jam> lifeless: kind of a shame to have copying 1/2 the data take 10x longer...
<spiv> lifeless: ok.  See you soonish.
<lifeless> jam: indeed; and its going to be in your hands shortly
<lifeless> spiv: probably get the 10:30, be rushing for the 10 sharp
<spiv> lifeless: ok
<lifeless> jam: thats the conversion though, its 17 seconds to copy native chk-gc
<lifeless> jam: but the chk nodes aren't compressing at all well
<lifeless> jam: haven't looked into why yet; I suspect its 'many record streams' or some such
<jam> jelmer: I just confirmed... just adding "subvertpy" as another "setup.py install --install-lib=XXX" doesn't work
<jam> because it installs it *next* to bzrlib
<jam> and so it isn't auto-detected by the rest of the code
<jam> (I didn't actually install anything, but it isn't in the directory where I expected to find it)
<jam> lifeless: well, if you are using original format, they are still "one long line" format
<jam> so if the leaf nodes are only an entry or two, there isn't much to compress
<jam> when one changes
<jelmer> jam, did you see the patch I put up for setup.py ?
<jelmer> that tries to include it in a similar way to qbzr's dependencies
<jam> jelmer: I have not seen one
<jelmer> http://samba.org/~jelmer/tmp/setup.py-subvertpy.diff IIRC
<jelmer> sorry, http://samba.org/~jelmer/tmp/setup.py-svn.diff
<jam> I have a bundle-buggy post, but no recent mails from you
<jelmer> I only mentioned it here on the channel about half an hour ago or so
<lifeless> jam: thats part of it; also I think there are too many record streams, which drives the group count up
<jam> lifeless: you mean a separate stream for "inventory" versus "chk" or that chk itself has lots of streams because of the layering?
<jam> I assume the latter
<jam> note, hash prefixes does help here
<jam> though I'm not sure why it would *have* to start a new GC group
<lifeless> the latter
<lifeless> each call to insert_record_stream starts a group at the moment
<jam> gotcha
<lifeless> simplest, to fit with other assumptions
<lifeless> 804
<lifeless> record streams
<lifeless> so 804 groups at minimum
<jam> lifeless: couldn't you tie it to commit_write_group()?
<jam> 804 seems severe
<jam> I would have thought 18 or so
<jam> that at least sounds like 1 per chk
<jam> rather than 1 per level
<lifeless> for record in inv_stream:
<lifeless> ...
<lifeless>     to.insert_record_stream(...)
<lifeless> its one per inventory
<lifeless> this is fixable at least :P
<jam> well, one per inv * one per level
<jam> I would guess
<lifeless> no
<lifeless> its one per inv + 1 for revs, sigs, texts, chk_nodes
<lifeless> 804
<lifeless> fixed, pushing to bbc
<eleftherios> is there a tutorial about putting a repository on a server and pushing/pulling over HTTPS or SSH even?
<lifeless> jam: I've pushed to brisbane core
<jam> lifeless: yeah, I saw it
<lifeless> eleftherios: its in the docs
<jam> I'll just mention that I don't think the final inventory bits will compress well
<lifeless> jam: so if you grab bbc, bzr-gc, bzr-repodetails
<jam> as it is mostly revision ids
<jam> and sha hashes
<lifeless> jam: yeah
<lifeless> it makes little difference
<lifeless> but you've got toys for playing with this
<lifeless> I've just been gluing bits together
<jam> yeah, I've gotten all your updates (for now :)
<spiv> Who builds the Mac OS X installer?  There's a bug about it: https://bugs.edge.launchpad.net/bzr/+bug/327487
<jam> interestingly, if you rename "groupcompress" "groupcompress-trunk" then Pyrex breaks
<ubottu> Ubuntu bug 327487 in bzr "bzr: ERROR: No module named PyQt4" [Undecided,New]
<jam> because it tries to create variables with "-" in them
<lifeless> jam: fun
<jam> jelmer: your patch looks like it might work, I'll try to play around with it tomorrow
<lifeless> jam: so I'll see about 'i' doing byte ranges
<lifeless> jam: on the way to spivs
<jam> lifeless: sounds good
<lifeless> jam: then at least the format can handle trying byte-sequence matching
<jam> I also think changing the serialized chk pages to allow '\n' in them may still be the fastest win for better compression
<jelmer> jam, cool
<jam> but that is stuff to play with
<lifeless> jam: well you have the code to do that :P
<lifeless> jam: so you could try it now if you like :)
<jam> anyway, I've got to go pick up my son. Have a good night everyone
<lifeless> good night
<lifeless> jam: if you read this before your next morning: where is your \n line breaking branch
<lifeless> vila: bug 327487 is an installer bug in bzr
<ubottu> Launchpad bug 327487 in qbzr "bzr: ERROR: No module named PyQt4" [Medium,Confirmed] https://launchpad.net/bugs/327487
<vila> lifeless: I don't think so, I encounter it on OSX when running selftest for example because I don't have qt there
<lifeless> vila: use case 'install bzr via the installer, and it works'
<vila> and I seem to remember that I tracked it one day to the point where an exception is violently raised
<lifeless> vila: -> installer bug
<lifeless> the installer should include or depend on qt if we're bundling qbzr in that installer
<vila> right
<lifeless> seperately, qbzr probably needs to be better, yes. But *that bug* is about the installer, please put it back :)
<vila> but qbzr shouldn't abort like that either
<lifeless> vila: thats true, but that is a seperate bug
<lifeless> even if qbzr was better the use case won't be fixed without fixing the installer
<vila> lifeless: I see your point
<lifeless> cool ;)
<lifeless> hmm, I need to hammer on evo's sync code more
<lifeless> but its not low hanging anymore
<Odd_Bloke> abentley: Thanks. :)
<jml> what's the recommended way to make bzr and emacs play together these days?
<lifeless> hammer n tongs?
<bob2> vc-bzr in emacs cvs matches whatever is on lp, and seems to work well
<bob2> for what it does
<igc> hi vila
<vila> hi Ian !
<igc> can't sleep? :-)
<vila> hehe, I was passing around *before* going to sleep, bad idea ;)
<jml> bob2: thanks.
<jml> istr the last time I tried a vc mode, it had problems with breaking hardlinks
<thumper> jml: I think it still does
<thumper> jml: check with kfogel
<thumper> jml: it works fine as long as you don't use hardlinks
<lifeless> ok, 30 minutes to sync mail== bad
<lifeless> -> train
<kfogel> jml: I gave up on VC mode in Emacs long ago, I just run cvs/svn/bzr on the command-line in a shell-mode buffer now.
<jml> :\
<jml> I used to find having a keybinding for 'bzr diff' quite useful
<jml> (and thence to 'commit')
<vila> kfogel: ever tried dvc ?
<vila> kfogel: or M-x shell-command-on-region RET bzr diff -rsubmit: ?
<vila> kfogel: diff-mode the resulting buffer and you got some interesting C-c C-c or C-c C-a ....
 * jml really needs to publish branch-todo
#bzr 2009-02-11
<kfogel> vila: I think I have tried dvc before.
<kfogel> vila: I dunno, I guess I just find the productivity gains not worth the effort of learning a new interface.  bzr in shell mode is already 95% of what I need, and it always Just Works.
<mwhudson> dvc seems quite nice, but what you really need is for emacs to learn what a 'project' is, i think
<mwhudson> or at least a branch
<mwhudson> i hate having to C-x v all my buffers when i change branches
<fullermd> Always works fine for me.  First, you fire up vim...
<mthaddon> poolie: now a good time for me to switch on the "clean up the chroot" for bzr PQM?
<poolie> yes please
<mthaddon> cool
<mthaddon> poolie: that's done - would be good if we were able to do a test commit
<poolie> mthaddon: sure
<mthaddon> poolie: any chance of that test commit so we can confirm the new PQM setup works?
<poolie> mthaddon: yes, will send it soon...
<mthaddon> cool, thx
<jam> lifeless: I don't think I ever got around to factoring out the changes from my "hacks" branch, http://bzr.arbash-meinel.com/branches/brisbane/hack
<jam> lifeless: but the specific changes are pretty small
<lifeless> jelmer: ping
<jelmer> lifeless: hello
<lifeless> your InterBzrDirTransport
<lifeless> is that in a patch for bzr.dev?
<jelmer> BranchBzrDirInter?
<lifeless> oh right
<jelmer> that's in a branch here, but not submitted yet (since it lacks tests)
<lifeless> uhh don't think that matches our needs - thanks
<lifeless> poolie: spiv and I have just had a use case pass, which is "'bzr push bzr+ssh://foo' uses a smart verb to send the revision data in one stream"
<lifeless> poolie: just don't ask what it does under the hood :P
<poolie> igc, did you say you'll help OOo with their error? i'd like that.
<igc> poolie: jelmer has replied to Heiner explaining that it's a bzr-svn bug and he's hoping to work on it this weekend
<poolie> oh, great!
<poolie> thanks
<igc> poolie: also, I'm looking into a batch of fast-import bugs/patches today so that might help as well
<lifeless> poolie: did you see my command hooks mail?
<poolie> not yet
<jelmer> lifeless, btw, I plan to submit a patch for InterBranch as well (for update_revisions/pull/push)
<jelmer> lifeless, not really fit for your use case either, probably, but might change some of the same areas of code
<jelmer> lifeless: also, would bug 272444 be appropriate for brisbane-core?
<ubottu> Launchpad bug 272444 in bzr "Support symlinks to non-ascii file names" [Medium,Triaged] https://launchpad.net/bugs/272444
 * igc lunch
<lifeless> jelmer: patchesyadayadayada
<lifeless> jelmer: I'm surprised we don't today
<jelmer> lifeless, well, that one I don't actually care about :-) Was just wondering
<jelmer> I might sent in one for the revision XML escaping
<jelmer> having workarounds for that in bzr-git and bzr-svn is annoying
<jelmer> and could potentially lead to corrupt revisions when roundtripping
<jelmer> since there's no way to tell escaped characters apart
<lifeless> I certainly think the core should be fixed
<lifeless> bbc is purely focused on scaling-and-less-work-to-diff-two-inventories
<mwhudson> verterok: ping
<lifeless> if its not a scaling issue (size or performance), or a work-to-generate-diff issue, then its not going to get my attention at the moment, nor would I expect it to get John/Ian/Andrews (dataloss bugs and regressions are obvious exceptions to this rule of thumb)
<lifeless> patches to the bbc development branch, to fix things that interest you would be cool
<lifeless> jelmer: once the bbc focus is reached, obviously we can look for minor tweaks to do, but there is no reason to delay them if someone else is interested.
<jelmer> lifeless, I should rephrase that; I meant it would be nice to get a new revision serializer in if we're going to be introducing a new repository format and rewriting revisions when upgrading to it.
<jelmer> so not necessarily as part of bbc but rather of whatever format it will end up in
<jelmer> (or is there no difference?)
<lifeless> jelmer: there isn't a difference
<jelmer> k
<lifeless> lp:~bzr/bzr/brisbane-core
<lifeless> development4* formats in there
<poolie> mthaddon: if you're still here - i sent a trivial merge to pqm
<mthaddon> poolie: yep, watching the logs
<mthaddon> poolie: seems to be working nicely
<lifeless> spiv: http://paste.ubuntu.com/116673/
<lifeless> poolie: and we now have an acceptance test for pushing to a stacked branch using a streaming format
<lifeless> poolie: passing
<mthaddon> lifeless: bzr pqm seems to be hung on the sending the mail portion - should i just kill it, or is there any troubleshooting we can do?
<lifeless> mthaddon: strace
<lifeless> mthaddon: lsof
<lifeless> mthaddon: etc etc etc
<lifeless> (pqm doesn't do any magic here - if the 'mail' command is wedged, I'm not any more sure than you are whats causing it.
<mthaddon> ok, nothing obvious there - thx
<lifeless> what syscall is the program in?
<lifeless> is the mail server itself wedged?
<mthaddon> "read(0, " was all I got
<mthaddon> mail server seems to be responding fine, though
<lifeless> read(0 is in mail ?
<lifeless> thats reading from stdin
<lifeless> what syscall is pqm in?
<lifeless> I have to go cathc a train
<lifeless> can you brain dump all the info you have to a bug please
<lifeless> get a python bt in pqm if possible
<lifeless> and then kill it
<lifeless> so people aren't blocked
<mthaddon> was in "wait4(4294967295, "
<mthaddon> have killed it - will keep an eye on it - have seem this every now and again before, just want to make sure it's not related to the config change I've just made
<lifeless> mthaddon: thats a deadlock for sure, pqm is waiting, mail is wating
<lifeless> mthaddon: so the question is, why is mail waiting
<lifeless> spiv: so, turns out the Branch tests were running with real branches
<spiv> lifeless: even when they were supposed to be parameterised not to?
<lifeless> :P
<lifeless> remember the bug we found where we got a real object back?
<lifeless> thats why it expected a remote, because we fixed that bug
<lifeless> the reason it only saw a real was... drum roll, because that was the server side one raising the event
<lifeless> (RemoteBranch.set_revision_info doesn't invoke hooks)
<poolie> lifeless: we've seen this before with pqm
<poolie> congrats on your test passing btw
<poolie> i suspect somebody relying on gc to close the pipe or something similar
<lifeless> poolie: its in wait4(
<lifeless> pqm is waiting for the response
<lifeless> and mail is in read(0
<lifeless> so its reading from stdin
<poolie> yes exactly
<lifeless> I can't remember what module pqm uses to send mail
<poolie> pqm thinks mail should finish up but it hasn't actually closed the input pipe
<poolie> i looked into this last time
<lifeless> erm, 'which mail'
<lifeless> so it might be bzr-mail
<lifeless> or it might be the pqm success mail
<lifeless> the backtrace should tell us
<poolie> i think it runs it directly through subprocess
<lifeless> there are two mail events
<poolie> the command arguments to mail made it clear which it was
<lifeless> ok
<poolie> well, i'm assuming here that there are not two bugs with identical symptoms
<lifeless> well, I started well before 9 :) and its >5, so really calling it a day
<poolie> sure
<poolie> unfortunately we must have discussed it only on irc
<poolie> ah bug 242262
<ubottu> Launchpad bug 242262 in pqm "deadlock while sending mail" [Undecided,Confirmed] https://launchpad.net/bugs/242262
<poolie> complete with suggested patch
<lifeless> mthaddon: ^
<mthaddon> aha
<poolie> complete with suggested patch all tidied up by launchpad
<poolie> getting rid of all that messy indenting :)
<vila> hi all
 * fullermd waves at vila.
<vila> fullermd: hi !
<vila> rats, Rejected:
<vila> PPA uploads must be signed by an 'ubuntero'.
<fullermd> A rare species of vole found only on Madagascar?
<vila> fullermd: should be that yes :)
<vila> poolie: I can't dput the same file anymore, which '1' should I change into a '2' in 1.12~rc1-1~bazaar1 ?
<vila> rc1-2 ?
<poolie> hm i guess so
<poolie> if it was rejected i'm surprised it cares
<poolie> did you sign the thing?
<vila> yes
<vila> argh, wait, there is a warning:
<vila> gpg: WARNING: This key is not certified with a trusted signature!
<vila> gpg:          There is no indication that the signature belongs to the owner.
<vila> just fater saying:
<vila> gpg: Signature made Wed 11 Feb 2009 07:43:03 AM CET using DSA key ID DEF6218F
<vila> gpg: Good signature from "Vincent Ladeuil <v.ladeuil+lp@free.fr>"
<vila> gpg:                 aka "Vincent Ladeuil <v.ladeuil@free.fr>"
<vila> though...
<poolie> wow
<poolie> launchpad has translations into 272 human languages
<poolie> or at least it thinks it does :)
<vila> poolie: ok, I fixed that warning, I'm ready to try to dput again unless you have a better idea to check first
<poolie> um
<poolie> so i see you are an ubuntero now
<poolie> let's go
<vila> poolie: yeah, I did that and fix a glitch in my gpg config too
<vila> dput done, no warning
<poolie> ooh
<vila> Package includes an .orig.tar.gz file although the debian revision suggests
<vila> that it might not be required. Multiple uploads of the .orig.tar.gz may be
<vila> rejected by the upload queue management software.
<vila> is harmless I presume ?
<poolie> you should be able to see in the web ui if it's building
<poolie> yes, that's normal
<vila> poolie: mail received, accepted, hurrah ?
<poolie> https://edge.launchpad.net/~bzr-beta-ppa/+archive/ppa/+builds?build_text=&build_state=all
<vila> Built successfully
<vila> Purging chroot-autobuild/build/buildd/bzr-1.12~rc1
<vila> is the relevant part ?
<poolie> so Hassium, the element after which the machine that built your package is named
<poolie> was not called that when i studied chemistry
<vila> yet another joke flying high above my head ? :-)
<poolie> no
<poolie> it changed name in only 1997
<poolie> http://en.wikipedia.org/wiki/Hassium | http://en.wikipedia.org/wiki/Element_naming_controversy
<poolie> we have a machine for each element i think
 * fullermd has sure never heard of 'hassium'...
<vila> I always feel bad when scientists lose their energy on such disputes :-/ (Not only scientists for what it's worth...)
<vila> How many builds should there be ?
<fullermd> If it makes you feel better, I rarely lose my energy for arguing about things nobody else cares about   ;p
<vila> fullermd: thanks, that helps :)
<poolie> vila, about 3
 * fullermd . o O (to most people's everlasting chagrin...)
<vila> right, the three built successfully
<vila> Is there a better way to check that than visual-grepping the 'Built succesfully' line ?
<poolie> In https://edge.launchpad.net/~bzr-beta-ppa/+archive/ppa look at the 'build status'
 * igc dinner
<vila> Ha, of course, thanks :)
<poolie> so that was only jaunty?
<poolie> i think now you should send the others
<vila> poolie: yup
<vila> yet another glitch to fix first (reverting to checkouts my cautious change to branches)
<vila> lol
<vila> my bzr.dev doesn't include the fix for httlib broken readline so I can't bzr launchpad-login, the irony...
<poolie> :/
<poolie> it should
<poolie> i thought john merged it
<vila> Yeah, I should pull :)
<vila> far better :)
<poolie> ok that's enough
<poolie> night all
<vila> How long should I wait between a successful build and its occurrence in synaptic ?
<mvo> vila: for the main ubuntu archive that can be easily 2h
<vila> mvo: ok, thanks, nothing to worry about then ?
<vila> err, should bzr-beta-ppa be considered the same as ubuntu archive in that respect ?
<mvo> hm, no (I missed that it was about a PPA). but it does take a bit too nowdays
<vila> mvo: ok, I'll just wait then
<Lo-lan-do> mvo: The Ubuntu mirrors are refreshed every 2 hours?!
<mvo> Lo-lan-do: the main archive, I can't speak about the mirrors. might be a bit more than 2h nowdays though
<Lo-lan-do> Impressive.
<mvo> yes, its pretty nice
<vila> mvo: the user experience regarding uploading to ppa is really nice too, congrats
<vila> mvo: showing up in synaptic ! That was fast too :)
<mvo> nice :)
<vila> poolie: ppa uploaded for dapper feisty gutsy hardy intrepid jaunty, build for jaunty and intrepid ok, others pending
<lifeless> spiv: entertaining...
<lifeless> [54/1114 in 17s] branch_implementations.test_branch.TestFormat.test_set_reference(RemoteBranchFormat-default)
<lifeless> Command terminated
<theAdib> hello, I did a 'bzr branch https://username/server/pathtorepository' from my svn server. now I did some changes and 'bzr commit' to apply locally but 'bzr push' says: 'bzr: ERROR: No push location known or specified.'
<theAdib> so: How do I push my changes to the central svn repository?
<Odd_Blok1> theAdib: "bzr push :parent" or "bzr push https://username/server/pathtorepository"
<Odd_Blok1> The former is shorthand for the latter in more recent versions of bzr.
<theAdib> :parent works smoothly :-) Thx.
<shankhs> how to get the source code of bazaar ... bzr branch lp:amarok is giving me error( cannot pass through proxy) I think I should try to create a patch...
<Odd_Blok1> shankhs: 'bzr branch lp:bzr' presumably won't help. ;)  Try 'bzr branch http://bazaar-vcs.org/bzr/bzr.dev/'.
<shankhs> Odd_Bloke: thanx
 * Lo-lan-do likes "apt-get source bzr"
<Odd_Bloke> Lo-lan-do: Not necessarily the best way to get a bzr that's worth patching.
<Odd_Bloke> If you're running unstable that gives you the source for bzr 1.5.
<Odd_Bloke> shankhs: What do you get if you run 'bzr launchpad-login'?
<shankhs> Odd_Bloke: No Launchpad user ID configured.
 * awilkins thinks an lp: resolver that worked through SSH would be great
<awilkins> I can't use the lp: convenience links, I have to work out the full SSH link because our proxy config is such a PITA
<awilkins> bzr branch bzr+ssh//bazaar.launchpad.net/~bzr/bzr/trunk bzr.dev  # That should work, might have to add username, and of course, you need a public key registered on your LP account
<Lo-lan-do> Missing :
<awilkins> Darn
<awilkins> Using lp: resolves the detail through some kind of HTTP-RPC which doesn't work through a bad proxy config even if SSH will work
<lifeless> awilkins: yeah, bug in the python xml-rpc library, not trivial to work around
<shankhs> so what should I do?
<awilkins> shankhs: Register a public key on LP and use ssh, or if you can pull over plain http, use that
<shankhs> I registered and got some SSH key now???
<LarstiQ> shankhs: no, you need to generate an ssh key yourself, and then upload the public part
<LarstiQ> shankhs: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<shankhs> ya I got it a very long string i registered starting ssh-rsa
<shankhs> LarstiQ: How is that going to help me ?
<LarstiQ> shankhs: it won't use http, so no http proxy
<shankhs> LarstiQ: ok
<shankhs> LarstiQ: can you please tell me the commands that I can use with ssh and bzr to download the source codes?
<LarstiQ> shankhs: after you have followed that CreatingAnSSHKeyPair page, do `bzr launchpad-login <yourlogin>`, and then the `bzr branch lp:bzr` command
<LarstiQ> although, maybe that only works for people in the bzr team, not sure
<LarstiQ> shankhs: you tried `bzr branch http://bazaar-vcs.org/bzr/bzr.dev` and that didn't work?
<shankhs> LarstiQ: bzr: ERROR: Unknown repository format: 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n'
<shankhs> LarstiQ: when i tried bzr branch http://bazaar-vcs.org/bzr/bzr.dev
<Odd_Bloke> shankhs: What version of bzr are you using?
<Odd_Bloke> The latest is 1.11.
<shankhs> Odd_Bloke: how to know that?
 * LarstiQ leaves shankhs in Odd_Bloke's capable hands and goes afk
<LarstiQ> shankhs: bzr --version
<shankhs> Bazaar (bzr) 1.6.1   Python interpreter: /usr/bin/python 2.5.2   Python standard library: /usr/lib/python2.5   bzrlib: /usr/lib/python2.5/site-packages/bzrlib   Bazaar configuration: /home/shankhs/.bazaar   Bazaar log file: /home/shankhs/.bzr.log  Copyright 2005, 2006, 2007, 2008 Canonical Ltd. http://bazaar-vcs.org/  bzr comes with ABSOLUTELY NO WARRANTY.  bzr is free software, and you may use, modify and redistribute it und
<Odd_Bloke> shankhs: Right, that's quite an old version.  What distribution/OS are you running?
<shankhs> ubuntu 8.10
<shankhs> updated an hour ago
<shankhs> Odd_Bloke: by the way what is the <yourlogin> in bzr launchpad-login <yourlogin> is it the ssh key?
<Odd_Bloke> shankhs: No, it's your Launchpad username.
<shankhs> ok
<Odd_Bloke> The SSH key is associated with the user account somewhere in the Launchpad UI.
<Odd_Bloke> shankhs: I suggest you look at https://launchpad.net/~bzr/+archive/ppa
<shankhs> i am getting ERROR: Connection error: while sending GET /%7Eshankhs/%2Bsshkeys: (111, 'Connection refused')
<Odd_Bloke> It has more recent versions of bzr available.
<shankhs> Odd_Bloke: what about the login problem I tried `bzr launchpad-login shankhs`
<Odd_Bloke> shankhs: What login problem?
<shankhs> am getting ERROR: Connection error: while sending GET /%7Eshankhs/%2Bsshkeys: (111, 'Connection refused')
<shankhs> my login name is shankhs
<shankhs> i tried my email id which i used to login
<shankhs> every permutation still getting the same error
<shankhs> I tried bzr launchpad-login <yourlogin>
<awilkins> shankhs: You'll have the same problem because it uses the same XMLRPC mechanism
<shankhs> I reinstalled bzr and the version is 1.11
<shankhs> awilkins: oh!
<awilkins> Do it with
<awilkins> --no-check
<shankhs> awilkins: thanx I got through
<shankhs> awilkins: now how to log out
<shankhs> and how to download stuffs
<shankhs> is there any good tutorials
<awilkins> All launchpad-login does is configure the username it uses for LP branches.
<awilkins> Which OS are you using~?
<shankhs> ubuntu
<awilkins> Ok then, ssh-agent running?
<shankhs> awilkins: how to check?
<awilkins> Try   ps -e | grep ssh
<shankhs> ya  `4771 ?        00:00:00 sshd `
<awilkins> Ok, just an ssh server running
<awilkins> Not sure if Ubuntu will automatically prompt you for a key password actually. Try.
<awilkins> Is your new private key on your ubuntu keyring?
<shankhs> I am a complete newbie...
<shankhs> how to check them...please explain thankyou
<awilkins> Ok, did you generate a keypair for Launchpad?
<shankhs> awilkins: ya
<awilkins> Ok, go to Accessories > Passwords and Encryption Keys
<awilkins> Is there "Secure Shell Key" on your personal keys tab?
<shankhs> ya I think i have SSH key and a GPG key
<awilkins> Ok, so your key is already installed.
<shankhs> awilkins: now?
<awilkins> Try  bzr branch bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk bzr.dev
<shankhs> its running
<awilkins> Big branch, may take a while :-)
<shankhs> awilkins: ok :)
<awilkins> I'm doing it too, just to slow you down some more
<awilkins> (mostly to check I'm not talking out of my rear)
<shankhs> ssh: connect to host bazaar.launchpad.net port 22: Connection timed out
<shankhs> :(
<shankhs> whats wrong now ? :(
<shankhs> awilkins: bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<awilkins> Ah, so you didn't get the twirly baton and stuff
<shankhs> awilkins: nope :(
<awilkins> Sounds like your firewall policy doesn't allow outgoing connections on port 22
<awilkins> You in a corporate office?
<shankhs> awilkins: no in a college
<awilkins> Only slightly better
<shankhs> awilkins: we have squid proxy if this might help
<awilkins> You know your proxy settings?
<shankhs> ya
<awilkins> (bzr.dev hit revision 4000, woohoo)
<awilkins> Is your HTTP_PROXY env variabl eset?
<shankhs> yes
<awilkins> try
<shankhs> trying again
<Odd_Bloke> I got r4000. \o/
<shankhs> awilkins: its not working and I am about to give up on bzr
<shankhs> awilkins: hey wait look https://bugs.launchpad.net/bzr/+bug/241698
<ubottu> Ubuntu bug 241698 in bzr "POST to authenticating proxy causes "necessary data rewind wasn't possible" error" [Undecided,Confirmed]
<awilkins> Is that what you're getting?
<awilkins> AFAIR that's a squid issue
<shankhs> I tried using -Dhpss and I got HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0xa29f3ac>
<shankhs> svn commands are working fine... though
<awilkins> svn has a simpler protocol for http I think
<shankhs> I think so
<awilkins> It's backed up by a more complex server
<shankhs> anyways I got to go hope some simpler remedy comes
<awilkins> Bazaar should work if you just serve the branch out of a dump http server
<shankhs> awilkins: thanx for your precious time...
<shankhs> awilkins: dump http server....!!!
<awilkins> dumb
<awilkins> sorry
<shankhs> ohh
<shankhs> ya i also think so
<awilkins> noo... it does work
<awilkins> svn has it's own WEBDAV server
<awilkins> It integrates as an Apache module
<shankhs> does that mean bzr wont work behind proxy servers?
<shankhs> awilkins: I see
<awilkins> It should work behind proxy servers ; but not all proxy servers are equal
<shankhs> awilkins: i agree
<awilkins> It didn't work out of IIS to start with either
<shankhs> awilkins: have you ever tested on squid...?
<awilkins> Because both IIS and Python ignore RFCs
<awilkins> shankhs: I know there there is at least one protocol bug related to a bug in squid
<shankhs> awilkins: I am login using SSH , how to log out?
<awilkins> launchpad-login doesn't "log in" it just configures the username
<shankhs> awilkins: ok
<shankhs> awilkins: does bzr implements its own protocol or some existing one?
<shankhs> awilkins: thanx once again for your help
<awilkins> Bazaar will use ; direct file reads, FTP, SFTP, HTTP, bzr protocol (raw, over SSH, or HTTP)
<awilkins> file/FTP/SFTP/bzr+http are writable
<awilkins> plain HTTP is read only
<awilkins> The smart protocol tries to reduce bandwidth consumption, the dumb ones all read indexes and read regions of files
<awilkins> You can also send merge bundles as files and have them treated as first-class branches as long as you have access to the branch they are based on
<awilkins> (well, for pulling/merging purposes)
<awilkins> So email also works (this is generally how patches to Bazaar are accepted, by mailing a merge bundle to the mailing list)
<awilkins> And i've been talking to myself....
 * awilkins slaps head
<Odd_Bloke> awilkins: I hadn't noticed. :p
<AfC> awilkins: we're all very impressed, honest.
 * awilkins hides under his comfort blankie
<clemente> Hi; how can you resume an interrupted âbranchâ command? I assume you can't easily, since there's bug #125607 open
<ubottu> Launchpad bug 125607 in openoffice.org "package openoffice.org-evolution 2.2.1-5ubuntu2 failed to install/upgrade: AbhÃ¤ngigkeitsprobleme - lasse es unkonfiguriert (dup-of: 125400)" [Undecided,New] https://launchpad.net/bugs/125607
<ubottu> Launchpad bug 125400 in openoffice.org "[MASTER] package openoffice.org-common 2.2.1-5ubuntu2 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [High,Fix released] https://launchpad.net/bugs/125400
<vila> awilkins: welcome to http://bazaar-vcs.org/Quotes :)
<clemente> mmm.... #125067
 * vila watches the DOS failure in ubottu....
<clemente> bug #125067 ?
<ubottu> Launchpad bug 125067 in bzr "allow 'bzr checkout' to resume" [Wishlist,Confirmed] https://launchpad.net/bugs/125067
<Youssef> Hi all!
<Odd_Bloke> Youssef: Hello.
<Youssef> Odd_Bloke: can you help me please?
<Youssef> im new to bazaar
<Odd_Bloke> Youssef: I'm about to go for lunch, actually.
<Odd_Bloke> awilkins might be around (PING!).
<Youssef> hmmm... okay thank you very much!
<awilkins> Ptthp
<awilkins> Go on then
<Youssef> awilkins I need you
<Youssef> i have a problem with bazaar
<awilkins> It's that or implement an XML/XSLT layer for a shell script
<Youssef> awilkins?
<awilkins> Ask
<Youssef> hhaa okay
<Youssef> so, i'm trying to push my project but it says =>This transport does not update the working tree of: bzr://localhost/. See 'bzr help working-trees' for more information.
<Youssef> why?
<Youssef> i checked it out
<awilkins> Because it's pushing to a smart server - it concerns itself with getting the revision data across but it doesn't update the remote tree.
<awilkins> If you want that tree updated, do `bzr up` in it
<Youssef> in it?
<awilkins> You also seem to be pushing to a branch on your own machine
<Youssef> yeah thats it
<awilkins> With a shell whos present working directory is inside the tree are pushing to
<awilkins> It's not necessary to push to a server if you are pushing locally
<awilkins> Just push to the actual filesystem folder and you get your tree update thrown in for free
<Youssef> hhmmm just a second please
<Youssef> i'll try trough my lan
<Youssef> so i'm doing a : c:\pjTemp>bzr checkout bzr://192.168.0.35
<Youssef> my LAN is a bit slow
<awilkins> Right, so 192.168.0.35 is another machine?
<Youssef> yes
<Youssef> now
<Youssef> check
<awilkins_sandwic> The not-updating-remote-branch thing is by design
<awilkins_sandwic> Are you just using the remote machine as a repository?
<awilkins_sandwic> You don't need the working tree if you just want somewhere else to keep your revisions
<Youssef> yes im using the server as repository
<Youssef> check now
<Youssef> http://rafb.net/p/C1I0Wf50.html
<Youssef> you see
<Youssef> if i understand what you said
<Youssef> when I commit it saves automaticlly the modifications.?
<Youssef> awilkins_sandwic?
<awilkins_sandwic> Ok, the push is redudant because your local checkout is bound to the branch you are pushing to
<awilkins_sandwic> sandwich
<Youssef> so it's not usefull to do a push then?
<awilkins> Not in that case, no
<awilkins> A checkout will commit both locally and to the remote barnch it's bound tyo
<Youssef> tyo?
<awilkins> to
<Youssef> really?
<Youssef> hmm
<awilkins> That's why it says "committing to bzr://192.168.0.35" and not c:\pjTemp\192.168.0.35
<Youssef> so when i checkout the commit will commit locally and to the server
<awilkins> And "no new revisions to push" (they are already there)
<awilkins> Yes
<Youssef> and making a push is useless
<Youssef> and now when i want to export my projet to a finished projet i use bzr export
<Youssef> but where in the server or directly localy?
<awilkins> For an export, either is appropriate
<Youssef> but without any push?
<awilkins> push is only required when you want to put revisions where they are not already. They are already on the server because you are working with a bound checkout and not a standalone branch
<Youssef> ooooh okay!
<Youssef> thanks many thanks man
<awilkins> You're welcome
<Youssef> :D
<Youssef> :DD
<Youssef> ooh yeah I forgot
<Youssef> see i reported a bug yesterday
<Youssef> awilkins?
<Youssef> https://bugs.launchpad.net/bzr/+bug/327558
<ubottu> Ubuntu bug 327558 in bzr "windows checkout raise an 10054, 'Connection reset by peer' error" [Undecided,New]
<Youssef> awilkins:
<Youssef> now if i do a revert
<Youssef> or an uncommit
<Youssef> does it work like the commit or it work only locally?
<hsn_> https://bugs.launchpad.net/bzr/+bug/305006 - can someone confirm that this bug is still not fixed in rc1? i would test it but i dont want to risk breaking my existing working bzr shelve instalation
<ubottu> Ubuntu bug 305006 in bzr "shelve fails with "Could not acquire lock"" [Undecided,Fix committed]
<mod_cure> is there a way to see the output as i grab a branch ?
<hsn_> okay, i did testing on windows and bug 305006 is still not fixed in 1.12rc1 and it is marked as fix commited. is there way to reopen bug?
<ubottu> Launchpad bug 305006 in bzr "shelve fails with "Could not acquire lock"" [Undecided,Fix committed] https://launchpad.net/bugs/305006
<betus> hello
<Odd_Bloke> hsn_: 'Fix committed' means that a patch has been submitted to the mailing list.
<betus> i'm a newbie and i have installed bazaar on my host running CentOs, but I can't run the command svn on the ssh client
<betus> can someone help me please?
<Odd_Bloke> jam: This bug seems to be assigned to you.
<Odd_Bloke> betus: What do you mean by "can't run the command svn on the ssh client"?
<betus> I have to do this svn co http://svn.askeet.com/trunk
<betus> I'm on putty
<Odd_Bloke> betus: Are you trying to use bzr as a client for an SVN repository?
<betus> yes is it worng?
<betus> wrong?
<betus> I read that I need a SVN client and on wikypedia I found that
<betus> I supose that bzr was for that
<Lo-lan-do> Only if you installed the bzr-svn plugin.
<betus> sorry for my poor english
<Odd_Bloke> betus: No, bzr can be used as a Subversion client.  However, Subversion does have its own client, which might be what you're looking for...
<betus> ok, but I didn't found the plugin for CentOs
<betus> and I don't know how to install it (this is the bad part)
<Odd_Bloke> hsn_: The patch to fix the bug is being tracked at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C497A0CD9.7030005%40arbash-meinel.com%3E
<Tak> have you tried `bzr co svn+http://svn.askeet.com/trunk` â½
<betus> ok Odd_Bloke: what have I do install for subversion?
<Odd_Bloke> betus: Probably 'subversion'.
<betus> Tak: not i didn't try it
<Youssef> Hi guys
<betus> Odd_Bloke: and do you know a subversion client that can I run on putty?
<Odd_Bloke> betus: Yes, the SVN client is command line based.
<Odd_Bloke> poolie: You also seem to have approved that patch. :)
<Youssef> okay I explain
<Youssef> yesterday i've reported a bug okay
<Youssef> https://bugs.launchpad.net/bzr/+bug/327558
<ubottu> Ubuntu bug 327558 in bzr "windows checkout raise an 10054, 'Connection reset by peer' error" [Undecided,New]
<Youssef> i noticed that is not only with checkout BUT with every command
<betus> Tak: then do you think I don't need to install another svn client?
<Youssef> hmm.
<Youssef> ..
<Odd_Bloke> Youssef: It's more valuable to add such information to the bug report than talk about it here, as it won't be seen when someone comes to help you.
<betus> tak: when i do that command it say me that: bzr: ERROR: Unsupported protocol for url "svn+http://svn.askeet.com/trunk"
<Odd_Bloke> betus: That means that you don't have bzr-svn installed.
<betus> and how can I install it?
<vila> Youssef: can you include a bit more of your log file in the bug report or at least mention which versions of bzr you are using for client and server ?
<Odd_Bloke> betus: What version of bzr are you running?  (bzr version)
<betus> the last I supose, i have installed with the instructions on yhe page yet
<betus> i did it: su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-2.noarch.rpm'
<betus> 5.2 maybe
<Youssef> done
<awilkins> Youssef: Hah, I was just about to submit that as a bug
<betus> and after this: c 'yum install bzr'
<Youssef> huh what?
<Youssef> hooo hehe
<awilkins> The "connection reset by peer" error
<awilkins> "Windows client diconnects rudely"
<awilkins> It works fine with lunix client > windows server - no errors
<Youssef> yeah okay than add a comment like this it will help
<Youssef> really?
<Youssef> maybe it's a problem of crlf character problem, no?
<Youssef> everything works fine but that raise this error anyway
<jdong> is it by design or bug that bzr pull shows much less progress info than bzr up?
<betus> Odd_Bloke: I didn't find a subversion for CentOs
<Lo-lan-do> jdong: They don't do the same thing.
<Odd_Bloke> betus: How are you installing it?
<Youssef> awilkins: are you writing a comment ?
<jdong> well in the usecase of having a bzr-svn checkout, I've tried updating a bound-branch and pulling in an un-bound brand from the same location..
<jdong> the bound branch displays things like "Determining Changes X/30000" ==> "Getting revision 1/30"
<awilkins> Youssef: Yes
<jdong> the unbound branch pull displays "Pull Phase 0/1"
<jdong> the latter I find to be much less useful to a user who wants to see a progress bar :)
<betus> Odd_Bloke: I'm install it throw SSH client
<betus> Odd_Bloke:with putty
<Odd_Bloke> betus: What command are you running?
<betus> Odd_Bloke:ok i found a command that is installing subversion: yum install mod_dav_svn subversion
<Odd_Bloke> betus: Yes, that's what you want.
<betus> ok i'm happy thank you
<betus> but 1 thing more: when i run this command line svn co http://svn.askeet.com/trunk
<betus> what will be happen, where the files will be installed?
<Odd_Bloke> betus: That's more of a Subversion question than a Bazaar question, so you should probably find a better channel to ask in.  However, I do know that that will create a directory called 'trunk' containing the files in the repository.
<betus> I supose you all with this question will be lughing
<jelmer> jdong, that should be a bit better in 1.12
<jelmer> jdong, progress bars have been improved
<Youssef> did awilkins let me a message?
<jdong> jelmer: that's great to hear :)
<Youssef> im back now
<jdong> jelmer: and I haven't told you yet that recent bzr-svn using subvertpy is simply wonderful
<Youssef> but
<awilkins> Is subvertpy installer bundled with win32-python-installer?
<Youssef> awilkins: like I said it is maybe a problem of CarriageReturn and LineFeed Charachters?
<Youssef> I dunno
<awilkins> Youssef: Not sure without either looking at the code or sniffing it
<Youssef> hhmmm
 * awilkins looks at the code
<luke-jr> jdong: haven't been using it long? :Ã¾
<Youssef> thanks awilkins
<awilkins> It's not a problem, it's been like that for aws long as I've been using it
<jelmer> awilkins, jam was looking into that
<Youssef> aws?
<awilkins> as
<Youssef> what is it?
<Youssef> loooooooool
<Youssef> okay
<jelmer> awilkins, hopefully the 1.12 compiler will come bundled with subvertpy and bzr-svn 0.5.0
<awilkins> Sorry, I was on a different keyboard yesterday
<jam> awilkins: ATM, it does not, but I'm trying to get it working now
<jam> I either need to get subvertpy bundled, or revert to bzr-svn 0.4.17
<awilkins> jam: I've noticed that the setup has changed in that it seems to ignore your LIB and INCLUDE vars if you set them
<luke-jr> jelmer: see that bzr log issue I reported?
<awilkins> jam: Or that might just be because I installed Python 2.5.4 and broke a customized build environemnt
<jam> awilkins: are you using "setup.py" or doing "make" ?
<awilkins> jam: make
<jam> k
<awilkins> make + msvc
<awilkins> The distutils stuff does it's own LIB/INCLUDE finagling
<jam> so what are you trying that is failing, exactly?
<awilkins> Compile extension ; can't find io.h
<jam> io.h sure seems like it should be a system lib
<awilkins> It's not passing INCLUDE as an include_dir
<jam> which you shouldn't need to provide a custom INCLUDE for.
<awilkins> jam: You'd think so, but I thikn you have to pass all the include dirs to the msvc compilers
<awilkins> Which suited me fine because I was trying to stick to the 2003 vintage (because that's the Python vintage)
<jam> well, for 2.4 and 2.5, you have to
<awilkins> What was 2.6 built with?
<jam> VS 2008, IIRC
<jam> the fact that it is v9, and 2008 always confuses me
<awilkins> It's not wonderful
<awilkins> Why the damn compilers aren't backward compatible is a mystery
<awilkins> (well, +more+ backward compatible)
<jelmer> luke-jr, which one?
<jam> yeah
<jam> each has its own runtime
<jam> I *think* you can use special flags to change which runtime they would use
<jam> but at best it is hard
<awilkins> jam: I recall projects that managed it (I think maybe an SVN project of some description)
<luke-jr> jelmer: 'bzr log' being totally screwed up with revnos
<awilkins> jam: I've royally fiddled with my registry to make distutils work with the MSVC2003 toolkit
<bialix> awilikins: recently I'va managed to create valid SConstruct to build pyrex/c extensions
<bialix> it may help in the case of MSVC2003 toolkit
<bialix> but I did not have a chance to test it with
<awilkins> bialix: I had it working at one point
<awilkins> bialix: The distutils team made a mistake pandering to all the registry BS IMHO
<bialix> with SConstruct I don't need to change the registry
<awilkins> What does SConstructy do?
<bialix> www.scons.org
<bialix> it's a build system
 * awilkins has ModelM fingers on a Cherry keybaord today
 * bialix bbl
<awilkins> Bah, it worked once.
<jelmer> luke-jr, I don't think there is an open bugreport about that
<jelmer> luke-jr, at least not afair
<luke-jr> I do.
<awilkins> I shall revert the tree and see if it works with a known revision, if it doesn't, I know it's some difference between Python2.5.2 and 2.5.4
<luke-jr> https://bugs.launchpad.net/bzr/+bug/326278
<ubottu> Ubuntu bug 326278 in bzr-svn "'bzr log' KeyError" [Undecided,New]
<jelmer> luke-jr, ah, I remember now - sorry
<jelmer> luke-jr, I had it in mind as a svn-upgrade problem, but it obviously occurs in other situations as well
<Youssef> guys
<Youssef> what is scons?
<Lo-lan-do> You don't want to know.  Really.
<Youssef> what?
 * Tak agree
<Youssef> but yes I do lol
<Youssef> what is it?
<luke-jr> lol
<jam> Youssef: it is a build tool, similar to "make"
<shankhs> hi again
<Odd_Bloke> shankhs: Hi. :)
<shankhs> after 2 hrs of troubleshooting with Odd_Bloke and awilkins and 3 hours of googling did not help me to get bzr working through squid
<Odd_Bloke> :(
<jam> shankhs: old version of squid?
<shankhs> i think so really old version
<vila> jam: ping
<shankhs> so i decided to review the source code myself but how to download the source code of bzr without bzr
<awilkins> Tarball
<jam> vila: pong
<shankhs> from the bzr home site?
<jam> shankhs: so, there is a known bug in squid that was fixed a while back
<jam> which bzr triggers
<jam> http://launchpad.net/bzr/1.11/1.11
<jam> there will be a tarball there
<jam> the fix is pretty easy
<vila> shankhs: upgrading squid is the best option if what you're observing is bzr downloading whole files when it should download only part of them
<jam> just a sec
<vila> jam: I'm looking into doing ppas for bzrtools
<shankhs> vila: I am not the net admin I am a student...
<vila> I find mails between you and poolie dating back to 1.8, they seem to imply doing what is described in ppa.txt should mostly work, is that still true ?
<vila> shankhs: You're a *user*, admins are here to server you :-) Ask for an upgrade !
<vila> shankhs: You're a *user*, admins are here to serve you :-) Ask for an upgrade !
 * vila hates when typos ruin jokes
<vila> shankhs: the bug is squid will slow down bzr severely
<vila> shankhs: the bug in squid will slow down bzr severely
<vila> damn
<shankhs> vila: I would do so...anyways do you know how to check the squid version ( from "user" terminal)
<vila> shankhs: that's generally the hard part as squid is good as hiding itself (that's why it's called a *transparent* proxy...)
<awilkins> Try pointing your browser at the squid server address
<awilkins> Some proxies also return revealing pages when you try to browse to a 404
<awilkins> Or a non-existent domain
<awilkins> (but I'm not sure about squid)
<shankhs> this is what I got http://www.mibbit.com/pb/cTLauf (i have the latest version of bzr)
<jam> shankhs: http://paste.ubuntu.com/116853/
<vila> jam: meh. I can find bzrtools-1.8.0 in bzr-beta-ppa and bzrtools-1.10 in bzr's ppa, where is bzrtools-1.11 ?
<jam> vila: it was never built
<jam> which is why poolie is trying to get you to do his work
<vila> jam: ha great, I like it when I understand things :)
<jam> shankhs: hmm... that looks more like lp: not working through a proxy
<jam> which is a known issue
<jam> what happens if you do "bzr branch http://bazaar.launchpad.net/~bzr/bzr/trunk"
<vila> jam: But strangely enough lp:~bzr/bzrtools/packaging-dapper mentions
<vila>    11 Martin Pool	2009-01-20
<vila>       1.11.0 release
<Odd_Bloke> shankhs: Try 'bzr branch http...' -- yeah, what jam said
<jam> vila: maybe he built it, but didn't get it uploaded
<vila> jam: I will work from that assumption then
<jam> vila: 'bzr diff -c 11' might also give clues
<shankhs> jam: Odd_Bloke : trying
<shankhs> Hey its working...stuffs getting downloaded
<shankhs> so I always have to download by getting the url of the trunk!!!!
<shankhs> thanx guys
<Odd_Bloke> shankhs: \o/
<jam> shankhs: unfortunately "lp:" doesn't support proxies yet
<shankhs> jam: :(
<mod_cure> is there a way to see the output as i grab a branch ?
<shankhs> hope someday it will
<Odd_Bloke> mod_cure: What 'output'?
<mod_cure> trying to grab a branch and it never completes
<mod_cure> i was curious it there was a verbose option or something
<Odd_Bloke> mod_cure: TIAS. ;)  Failing that, look at ~/.bzr.log.
<Odd_Bloke> mod_cure: Also, what version of bzr are you using?
<mod_cure> just installed bzr from yum
<Odd_Bloke> mod_cure: 'bzr version' will tell you.
<shankhs> bzr --version :)
<mod_cure> Bazaar (bzr) 1.3.1
<shankhs> mod_cure: I think you should update
<mod_cure> how ?
<shankhs> I dont know how to do this in fedora
<mod_cure> thats the lastest version in the repos
<Odd_Bloke> mod_cure: I don't know about a Fedora-specific way, but you can get the latest bzr by running 'bzr branch lp:bzr' or 'bzr branch http://bazaar.launchpad.net/~bzr/bzr/trunk'.
<Odd_Bloke> And then you can use that.
<mod_cure>  bzr branch lp:bzr
<mod_cure> bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n'
<Odd_Bloke> Oh, goodie.
<shankhs> Odd_Bloke: How can I find the url address everytime we need to?
<Odd_Bloke> mod_cure: Look at http://bazaar-vcs.org/Download
<Odd_Bloke> shankhs: It's (bzr+ssh|http)://bazaar.launchpad.net/~<branch owner>/<project>/<branch name>
<Odd_Bloke> You can get all of that information by finding the branch in the Launchpad web UI.
<mod_cure> Package bzr - 1.3.1-1.el5.1.i386 is already installed.
<mod_cure> 1.3.1 seems up to date
<Odd_Bloke> mod_cure: Have you tried the EPEL-testing repo?
<mod_cure> yep
<Youssef> okay guys nice to meet you all i'll be back tomorow (if God want it)
<Odd_Bloke> OK, in that case download a tarball.
<Youssef> cya all++
<Odd_Bloke> Youssef: Bye!
<mod_cure> Odd_Bloke, which one as  i have 1.3.1
<jam> jelmer: can you link your subvertpy patch again? I still haven't gotten an email on it
<jelmer> jam: I never sent one :-)
<Odd_Bloke> mod_cure: Download the latest bzr.
<jelmer> jam: http://samba.org/~jelmer/tmp/setup.py-svn.diff
<mod_cure> 1.1.1 ?
<mod_cure> oic
<mod_cure> tired, sorry
<mod_cure> should i remove bzr then install the tarbar or just install the tarball ?
<Odd_Bloke> mod_cure: I would suggest extracting the tarball somewhere in your home directory and running from there.
<Odd_Bloke> Else you might run into problems when trying to install future bzr releases with your package management system.
<mod_cure> ok
<phinze> so is the general feeling here "there is no task too small for a task branch" ?
<Odd_Bloke> phinze: It is for me.
<Odd_Bloke> I'll sometimes have single revision task branches.
<phinze> i'm still working on my workflow and while the personal task branch makes a lot of sense it's harder to see if it's actually unnecessary overhead for tiny issues
<phinze> Odd_Bloke: so how do you keep your branches organized?  i'm just worried about having a billion task branches lying around
<Lo-lan-do> I think I'll use more task branches when they are colocated, but so far I tend to avoid branching for trivial stuff (except when needed for separation of private and public stuff).
<phinze> Lo-lan-do: "when they are colocated" refers to furture bzr functionality or a specific configuration you don't always use?
<Odd_Bloke> phinze: Well, I get rid of them once they are merged.
<Odd_Bloke> I know jam has bzr/<target version>/<branch name> to avoid too much clutter.
<Lo-lan-do> phinze: Future (hence uncertain ;-) bzr functionality.
<jam> phinze: I tend to have a "trivial-fixes" branch
<jam> but otherwise everything is a separate feature branch
<phinze> Odd_Bloke: so you differ from jam by deleting branches, right?
<phinze> i.e. jam you never delete a branch?
<jam> phinze: and you can see my "forest" here: http://bzr.arbash-meinel.com/branches/bzr
<jam> phinze: correct
<jam> all 450+ are there
<phinze> jam: nice :)
<Odd_Bloke> Actually, I don't tend to delete them.
<nDuff> phinze, my workflow here is to create one branch per ticket
<Odd_Bloke> But I have no objection to doing so.
<jam> phinze: also, ISTR there being an "archive-branch" command written for you guys :)
<nDuff> phinze, ...and to delete the branches after the tickets are closed.
<jam> so you don't delete them, but move them into an archived location
<phinze> jam: right, i'm probably going to be the one writing it ;)
<jam> well, I wrote the first part, you just need to finish it for your final workflow
<phinze> i figure it's a good idea to work out some workflow kinks for myself before imposing them on the group
<phinze> honestly i haven't had the chance to look at what you wrote yet :\
<phinze> your email fwd is still sitting in my inbox, heh
<Odd_Bloke> Who's "you guys"?
<jam> Odd_Bloke: a dev group. I used to work with one of the sys admins, so I convinced him to convince his group to switch to bzr
<phinze> Odd_Bloke: my place of employment (small IT shop @ Uni of Iowa) where jam's got a buddy in one of my coworkers
<phinze> there you go, two perspectives on the same fact :)
<Odd_Bloke> Cool. :)
<phinze> jam: so looking at your "forest", for a given version where are you mirroring and pushing and pulling?
<jam> "mirroring pushing and pulling"?
<jam> Generally, I have a treeless repo on my local machine
<phinze> erm, still getting the terminology right
<jam> with a couple lightweight working trees pointing at whatever branch
<jam> my local repo matches the shape of the remote one
<jam> so I can:
<jam> bzr branch bzr.dev 1.12/feature-x
<jam> cd work
<jam> bzr switch ../1.12/feature-x
<jam> bzr commit -m fix it
<jam> bzr push
<jam> And the "bzr push" will push it to $SERVER/1.12/feature-x
<Lo-lan-do> Are there any documented workflows for using two machines (laptop+desktop)?
<phinze> jam: okay, slowly getting that.  now when you'd merge there, you'd merge back into bzr.dev... which is 'tip'?
<jam> phinze: well, I submit things to PQM, and it does the merging for me
<jam> but if we didn't have that
<jam> yes
<phinze> ah yes
<jam> bzr.dev would be a heavy-checkout of tip
<jam> which is on another machine
<phinze> and 'work' is...?
<phinze> a lightweight checkout?
<jam> phinze: correct
<jam> (I technically have a 'work',  'alt_work', bzr.dev, and 'jam-integration' as checkouts, I don't think most people work on that many threads at once)
<phinze> and the whole kit and kaboodle was started with bzr init-repo --no-trees
<jam> phinze: correct
 * phinze is learning!
<jam> phinze: something like:http://paste.ubuntu.com/116911/
<jam> I won't claim it is the *easiest* to set up
<jam> but it works pretty darn well
<jam> especially if you want *lots* of feature branches
<phinze> i like it
<jam> You'll also probably want lines like:
<jam> [$PATH/local/bzr]
<jam> push_location = $HOST/repo
<jam> push_location:policy = appendpath
<jam> That is what makes "bzr push"
<jam> already know where to push
<phinze> ah that's helpful indeed
<jam> (in "~/bazaar/locations.conf")
<phinze> i've definitely had to wrestle with the client pushing and pulling places i wasn't expecting
<phinze> lots of furious ^Cs flying around :)
<phinze> and subsequent 'bzr break-lock'ing and crying
<vila> verterok: hi !
 * verterok waves
<vila> verterok: any progress on the OSX installers ?
<verterok> hi vila
<verterok> vila: no  :(
<vila> You don't play with your new toy ??? I can't believe that :-)
<verterok> vila: I'll try to get my ibook hooked up to the net today (need to have a lonk call phone with my parents in order to get it done :/ )
<verterok> s/lonk/long/
<jam> jelmer: what is the official branch for packaging bzr-svn for debian?
<jam> bzrtools is here, right? http://bzr.debian.org/pkg-bazaar/bzrtools/unstable/
<jelmer> jam: experimental rather than unstable at the moment (since Debian is in freeze)
<jam> thanks
<jam> I realized that when I saw bzrtools 1.6 there :)
<jelmer> jam: I seem to've forgotten to upload again though
<jelmer> doing that now
<jam> you have 1.12 in experimental
<jam> just 1.6 in unstable
<jam> Of course, I read the range wrong, you have 1.11 in experimental
<jam> (had)
<verterok> vila: do you have the sources of the 10.5 installer? I could start with that one :)
<vila> verterok: no :-(
<jelmer> jam: pushed
<verterok> vila: ok, I'll send a mail to phanatic about that, thx!
<Lo-lan-do> You guys are aware of http://bzr.debian.org/loggerhead/pkg-bazaar/ right?
<vila> verterok: ok, keep me informed
<verterok> vila: sure thing
<santagada> I asked yesterday, is there a way to trac a piece of code in a bzr branch? like a function that gets refactored to another file for exampl
<santagada> this is the only feature of git that seems really interesting
<Lo-lan-do> That, and revision squashing.
<santagada> Lo-lan-do: what is that?
<santagada> the way that git tracs changes using the whole project and not file by file is pretty interesting
<Lo-lan-do> Merging successive revisions so that when you send your branch for inclusion it only has like 10 commits rather than 200.
<santagada> Lo-lan-do: this seems cool also
<Lo-lan-do> Maybe it'll happen in bzr-rebase sometime? :-)
<santagada> but it is a cosmetic thing (a pretty interesting one), but looking at revision data as a whole project is very interesting
<santagada> I don't know, maybe bzr is just like git....
<elmo> why doesn't bzr assume push location is where I pulled from?
<mwhudson> elmo: because reasonably often that's not what you want
<mwhudson> you can say bzr push :pull
<mwhudson> to push to where you pulled from without having to remember it
<mwhudson> beuno, rockstar: loggerhead review ping!
<elmo> mwhudson: it's what I want every time I've tried to use push, FWIW  and AFAICR :-P
<elmo> maybe I'm just special
<beuno> mwhudson, it's on my ToDo list, but now that you're up, I'll review now
<rockstar> mwhudson, I don't really have the cycles to review it right now.
<mwhudson> elmo: there was a long argumen^Wdiscussion on the mailing list on this
<beuno> elmo, FWIW, I feel the same
<mwhudson> rockstar: np
<mwhudson> beuno: cool :)
<elmo> mwhudson: the push :pull short hand is neat though, thanks
<vila> elmo: and it will be remembered so you need it only once
<beuno> mwhudson, done. Very small comment.
<mwhudson> beuno: i think your comment is about a bzrlib api?
<beuno> mwhudson, ah!  well, I guess you can ignore me then  :)
<mwhudson> beuno: thanks :)
<guest123> Hi all, I have just recently started using Bazaar (and in general VCSs). Would anyone kindly point me to the best place where I can ask some newbie questions?
<NfNitLoop> guest123: ask away.
<NfNitLoop> guest123: on IRC, it's generally best to avoid asking permission to ask a question.   You might wait a while for a response.
<NfNitLoop> guest123: so just put it out there. :)
<guest123> :) thanks. We have a small group of 4 developers inhouse, so all the projects are in the shared folder over network. I'm thinking of having some local bug tracking tool and was wandering if it be possible to integrate that with bzr
<lifeless> elmo: you really need to start giving other projects patches then :)
<lifeless> guest123: it certainly is possible to do that
<lifeless> guest123:
<lifeless> if you ru 'bzr help bugs' you will get the online docs about our bug tracking integration support
<elmo> lifeless: pfft
<guest123> I found how to integrate web-based bug support (bugzilla etc) but puttin url in the config file, but can it be used to call some other local application?
<lifeless> elmo: (thats where our default makes sense - we're optimised for non-core contributors by default)
<lifeless> elmo: and in fact, for core contributors working on non-trunk features too
<kfogel> hunh
<kfogel> I guess we're at revision 4000 now on trunk.
<kfogel> At first I thought it was an error when my checkout stopped at that, because it was such a round number :-).
<lifeless> abentley: have you seen 'bzr send' bring up a mail address prefixed with /// ?
<abentley> lifeless: Yes.  There's an open bug about it.  xdg-email is broken in Intrepid.
<lifeless> ah
<lifeless> thanks
<lifeless> bug 291847 ?
<ubottu> Launchpad bug 291847 in bzr "xdg-open mangles mailto: urls to ///foo@bar.com" [High,Fix released] https://launchpad.net/bugs/291847
<lifeless> abentley: would it be reasonable to not use xdg-email with intrepids version?
<abentley> lifeless: You mean use the editor client on intrepid?
<lifeless> I guess
<lifeless> or do `which evolution`, `which thunderbird` ..
<lifeless> I'll look at the xdg-open bug this weekend I hope
<abentley> lifeless: If the user configures their client, everything's fine.  It's only the default that's broken.
<lifeless> so the setting you refer to is an xdg-open setting?
<abentley> lifeless: No, it's a bzr setting.
<abentley> lifeless: the mail_client setting.
<lifeless> ok
<lifeless> so I'd like the default to work
<lifeless> I just got bitten myself, a merge request I'd 'sent' was queued by evo because it doesn't understand /// is bogus, and thus the smtp daemon was rejecting
<abentley> lifeless: Me too, but I was hoping someone on the distro would fix intrepid.
<lifeless> indeed
<lifeless> however, its new-unconfirmed which means noone has seen it
<lifeless> I'll see what I can do about that
<jelmer> I've seen it as well on Debian fwiw
<lifeless> I was however, asking about other options, if its hard/tricky/whatever
<lifeless> jelmer: probably upstream bug
<lifeless> most things are :P
 * jelmer tries to think of ways to describe a working tree without using the word WorkingTree to not break test_source.TestApiUsage.test_branch_WorkingTree
<Lo-lan-do> jelmer: Sandbox?
<lifeless> jelmer: why?
<jelmer> I've added a "workingtree_updated" boolean to PullResult
<jelmer> I guess I should probably move PullResult instead
<lifeless> jelmer: or have a WorkingTreePullResult
<abentley> lifeless: I don't think the difficulty is too high.  We already have code which tries one and falls back to another, so we can crib from that.
<lifeless> which decorates BranchPullResult
<jelmer> lifeless, hmm, yeah, that might be an idea as well
<mwhudson> beuno: mmm, do you know if any of those "replace mootools with yui" for loggerhead we did at the epic were complete enough to use?
<beuno> mwhudson, no. BUT, I'm planning on using lazr-js, so I should be able to actually do that in a day or two of work
<beuno> I've been working on the stuff I need for this in lazr-js directly
<beuno> so we all win  :)
<mwhudson> ah, ok
<mwhudson> when? :)
 * beuno pretends that message never got across
<lifeless> I have a layering problem
<lifeless> Hopefully lazyirc will help me :)
<lifeless> I want to change the TestResult instance used by 'bzr selftest', controlled via an option to 'bzr selftest' introduced by a plugin
<lifeless> I'd rather not use global state
<Lo-lan-do> beuno: Any chance of releasing a serve-branches-based loggerhead soonish?
<beuno> Lo-lan-do, what do you mean exactly by that?
<beuno> with configs n' stuff?
<lifeless> I'd also rather not expose this as 'use this result class' at the UI, mainly because I don't want things like 'default' to be visible - I just want a single simple option
<Lo-lan-do> beuno: Configs would be neat, but at least a working init script without local patching :-)
<Lo-lan-do> I'd like to go forward with my FusionForge bzr plugin, which would require a branch browser.
<beuno> Lo-lan-do, ah, that should easy I think. There are like 4 different patches that do that, including one that jelmer includes in the package
<beuno> I don't really know which one to include though
<beuno> jelmer, any ideas on that?
<jelmer> beuno, if serve-branches is the way to go then Lo-lan-do's init script would be the way to go
<Lo-lan-do> Also, the URL generation bug is rather nasty, if you allow me to bitch about that :-)
<jelmer> beuno, that complies with common practices for init scripts
<beuno> Lo-lan-do, file a merge proposal, I'll merge  :)
<mwhudson> lifeless: i too have wanted to control which TestResult objects get used in tests
<lifeless> jml: does your TeeTestResult or whatever it is called pass on all method calls and attribute access? or only the 'protocol'
<lifeless> mwhudson: I think what I'm going to do is fix the lower layers, so I can have my plugin 'just do it'
<lifeless> mwhudson: and then at the top probably just punt and set a global
<Lo-lan-do> beuno: The branch is at http://bzr.debian.org/~lolando/bzr/loggerhead/daemonise/
<Lo-lan-do> browsable at http://bzr.debian.org/loggerhead/users/lolando/loggerhead/daemonise/changes
<beuno> Lo-lan-do, I'll try on get that merged in soon
<Lo-lan-do> Yay :-)
<Lo-lan-do> There's also the system-yui branch, but it's probably not interesting to you until yui 3 enters Debian.
<beuno> Lo-lan-do, if I don't, please hunt me down and force me to  :)    I'm a bit over-committed this month
<Lo-lan-do> Sure
<lifeless> beuno: s/(.*)this month/\1/
<beuno> lifeless, I'm taking it one month at a time  :)
<lifeless> beuno: if only :)
<jml> lifeless: ummmm... I can't remember.
<jml> lifeless: probably only the protocol.
 * kfogel is away: back on later
<lifeless> jml: how would you feel about a more generic T adapter
<lifeless> oo pycon downunder
<jml> lifeless: as in a __getattr__ hack?
<lifeless> jml: details, details :P
<lifeless> jml: as in, I want to glue the new shiny subunit stuff
<lifeless> and bzr's visual progress together
<lifeless> subunit doesn't have bzr's additional protocol
<lifeless> right now I'm finishing a patch to replace the runner altogether
<lifeless> I'll see if that satisfies my itch; it may
<mwhudson> beuno: is it possible to mix mootools and yui on the same page?
<beuno> mwhudson, yeap, no problems with doing that
<mwhudson> i still have this crazy plan for swapping between unified and side-by-side diffs using js
<jml> go crazy
 * jml bops to Prince
<beuno> mwhudson, do that with ajax, and it's a triple win
<beuno> fetch diffs with ajax, and make them interchangeable
<mwhudson> oh right yes, that too i guess
<beuno> the servers will *love* you
<mwhudson> seems somewhat orthogonal
<mwhudson> revision pages seem to be the main performance terrorizer right now
<beuno> it is, it's just me trying to you sneak one of my ToDo's  ;)
<mwhudson> :)
<lifeless> what I really want is "the user made this selection, maybe a lower layer wants it, hand-off"
<lifeless> mwhudson: jml: http://paste.ubuntu.com/117030/
<lifeless> thats a sketch
<lifeless> does it make baby jesus uncomfortable? I don't know
<vila> lifeless: this has undeniably a perl taste :-)
<poolie> hello
<thumper> hi
<jelmer> hi vila, poolie, thumper
<igc> morning
<vila> hey
<beuno> hiya igc
<mwhudson> lifeless: it's mildly odd, but not too horrific i guess
<igc> hi beuno
<mwhudson> morning all
<igc> morning mwhudson
<thumper> lifeless: pycon downunder different to nzpycon?
<thumper> lifeless: is that the one in singapore next year?
<lifeless> thumper: nzpycon
 * thumper nods
<thumper> lifeless: #nzpug
<bob2> trying to exploit our good name
 * mwhudson must try to not entirely miss the next planning meeting for that
<thumper> lifeless: even if you aren't in nz right now
<lifeless> bob2: 2/3rds of the region can't be wrong
<thumper> poolie: are we standing up?
<lifeless> bob2: North island
<lifeless> bob2: South Island
<lifeless> bob2: West Island
<bob2> lol
<poolie> vila: are you around? want to join our standup?
<vila> poolie: yup
<jml> Can I get a bzr dev to look at bug 328146 please?
<ubottu> Launchpad bug 328146 in launchpad-bazaar "Pushing a non-stacked branch to a project using stacked branches fails" [Undecided,New] https://launchpad.net/bugs/328146
<thumper> jml: that is pushing a rich root branch stacked on a non-rich root branch :-|
<jml> thumper: yeah, I got that far :)
<spiv> jml: comment added, and opened it against bzr too
<jml> spiv: I noticed! Launchpad trashed the comment I had just written :)
<jml> spiv: I've marked it as invalid on launchpad-bazaar, because there really is no bug in what we're doing.
<igc> poolie: calling back?
<jam> poolie, igc: I'd like to finish, but I also need to go pick up my son
<jam> Is there a lot left to discuss?
<igc> jam: I'd like some rough idea of how much "core" engineering you think is left
<igc> weeks still?
<jam> igc: There is the "is it good enough for limited rollout" versus "it is what we really want to ask people to upgrade to"
<jam> I know lifeless has mentioned wanting a really solid next repo format
<jam> rather than continuing the "release early, release often" and have incremental improvements
<jam> If we just want to get it to the point that we could merge it as a --dev format that exists in bzr.dev
<jam> I would think we could do that in a week or so
<phinze> okay so i have a completed task branch at tasks/1.2.3/cool_task
<phinze> which is lightweight checked out at work/
<phinze> when i'm running merge inside trunk/ is there any different between bzr merge ../work and bzr merge ../tasks/1.2.3/cool_task ...?
<jam> phinze: no
<poolie> igc, jam, lifeless, vila, spiv, i can't connect to skye
<phinze> jam: happy days
<phinze> thx
<jam> poolie: do you want robert to call your house?
<thumper> spiv: I have to head out to the dentist
<thumper> spiv: shall we defer until tomorrow?
<spiv> thumper: ok
<poolie> it seems to be dentist week
<lifeless> spiv: lets talk pairing in 15 minutes or so, I'm knackered
 * igc breakfast
<spiv> lifeless: agreed
<mxpxpod> I shelved some changes and now I'm getting this error unshelving them: bzr: ERROR: No such file: None
<lifeless> mxpxpod: thats a bug, fixed in bzr.dev
<mxpxpod> lifeless: 1.12rc1?
<lifeless> mxpxpod: that has the fix too, I believe
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/319790
<ubottu> Ubuntu bug 319790 in bzr "bzr unshelve crashes losing all changes" [High,Fix released]
<mxpxpod> lifeless: thanks... I just applied the patch from that bug
<mxpxpod> works like a charm
#bzr 2009-02-12
<lifeless> spiv: so, I'm nearly human again
<lifeless> spiv: want to pop over?
<spiv> lifeless: to Epping?  Sure.
<lifeless> cool
<spiv> I'll finish humanising myself and head over.  I'll let you know my eta.
<lifeless> kk
<lifeless> Odd_Bloke: if you're looking at bzr send
<lifeless> Odd_Bloke: apparently we should us xdg-email
<lifeless> *use*
<Odd_Bloke> lifeless: My next few cycles are going to be spent looking at shelf.
<Odd_Bloke> s/shelf/shelves/
<r0bby> yeh if only i initialized the String :x
<r0bby> that wouldn't have made it less wrong
<Odd_Bloke> r0bby: Wrong channel? :)
<Odd_Bloke> What's brisbane-core?  I keep seeing references to it, but missed the kicking off point.
<lifeless> Odd_Bloke: next gen format
<ronny> is there any schema on how the database of the in bzr works?
<ronny> (and if there are ways to extend it)
<lifeless> ronny: you can't really extend the core (though you can use it to do different things for you)
<lifeless> ronny: in terms of docs, there are the Classes stuff on the wiki, and docstrings in the code - pydoctor gives quite good results on that I believe
<ronny> hmm, any listing ? i missed the stuff in the wiki
<lifeless> http://bazaar-vcs.org/Classes
<spiv> lifeless: eta 1220
<lifeless> roger wilco
<ronny> lifeless: at what part of the src should i look?
<lifeless> ronny: well, what are you interested in? If you're interested in the 'db' implementation, btree_index, knit.py (the pack mapped index and access objets), and repofmt/pack_repo.py's RepositoryPackCollection class)
<ronny> lifeless: mainly the db stuff
<lifeless> if you're more interested in the model, I don't think there is a single good reference
<ronny> the model is important for me, too
<ronny> just researching the different stuff
<lifeless> I'd cast an eye over doc/developers/
<ronny> so far git's model seems the most reasonable
<ronny> just the rest of git isnt
<lifeless> :P
<ronny> any reason why bzr did choose uuid's over content hashes other than the rehashing (aka switch hash algo) issue?
 * ronny waves for attention
<mwhudson> well, bzr-svn includes more information in the uuid
 * RAOF is by no means a bzr hacker, but IIRC it allows better tracking of file moves.
<ronny> RAOF: nope, not at all
<ronny> mwhudson: like what?
<mwhudson> ronny: uuid of the repository + revno of the import
<ronny> ok, also nothing that would reqire a uuid
<mwhudson> i think it's more a matter of style of approach than requirement
<mwhudson> but way way before my time
<ronny> RAOF: git's bad move tracking is derived in the fact that trees dont have parents, thus the parent/child relation is only in commits
<ronny> so any comments?
<Odd_Bloke> ronny: I'm not sure the IRC channel is the most appropriate place to look for this kind of discussion.  The mailing list might be better...
<ronny> hmk
<ronny> i mostly just want to know the reason tho, not discuss it over again
<Odd_Bloke> ronny: I still think a post to the ML is most likely to get a useful response.
<Odd_Bloke> Anyway, I intended to go to bed half an hour ago.
<Odd_Bloke> So, good night #bzr.
<lifeless> ronny: we chose uuids for revisions for a couple of reasons; not wanting to redo everything when sha1 is broken, and supporting imports from arbitrary systems is the other (and its been very susccessfuly)
<lifeless> ronny: for file ids, we use uuids as a memo, but equally could use just history pointers
<ronny> hmm, why does import from others require uuid's?
<lifeless> ronny: transitive history is not always available
<ronny> i dont see how that makes uuid's an requirement
<ronny> i need to sleep
<mwhudson> oh that's right, ghosts
<mwhudson> i always forget that one...
<jelmer> not just that
<jelmer> having to calculate the contents in the native format for all contents in the ancestry of a revision is expensive
<jelmer> never mind, just read up on what transitive means :-)
<mlh> ronny's design questions remind's me that poolie's design notes used to be available somewhere
<mlh> like old.bazaar-vcs.org or bazaar-vcs.org/old (I've checked there)
<spiv> mlh: http://doc.bazaar-vcs.org/obsolete-docs/ ?
<mlh> thanks spiv
<mlh> that's an excellent historical document.  I remember meaning to give that link to ESR when he was going to (threatening to ? :-) write a history of (D)VCSs
 * igc lunch
<lifeless> jml: we need to spend a few hours on 'how to represent skip etc for .unittest
<lifeless> '
<jml> lifeless: yes.
<jml> lifeless: in fact, a mini-sprint on pyunit-friends stuff would probably be a Good Thing
<jml> lifeless: let's go to Perth and visit jamesh :)
<lifeless> jml: :P
<jamesh> lifeless: that reminds me.  I uploaded a testresources branch implementing the make/reset/clean API I suggested.
<lifeless> yes, its in my aroundtuit pile :(
<jamesh> you said my original description was a bit hard to understand, so maybe some code will make it clearer :)
<lifeless> thank you
<jamesh> and I don't know whether you'd want to come to Perth at this time of year.  It may be a bit dryer, but it is also a lot hotter
<lifeless> jamesh: yeesh, don't need more heat
<lifeless> jml: I was thinking dinner, wine, laptops
<jml> lifeless: sounds delightful
<lamalex> Can I version a single file only? For example I want to keep my .emacs file in sync across a few computers, is there a simple way to do this?
<lifeless> lamalex: bzr init ~/my-emacs
<lifeless> mv ~/.emacs ~/my-emacs
<lamalex> lifeless: so "no"
<lifeless> ln -s ...
<lifeless> lamalex: yeah, sorry
<lamalex> no problem
<lamalex> it's not the point of bzr
<lamalex> that will probably be cleaner anyway, I'll just make a dir of my misc files, then link to them
<bob2> sure, cd ~/ ; bzr init ; bzr add .emacs ; bzr ignore ".*" ; bzr ignore "*" ; bzr commit
<lamalex> can someone help me set up a shared repo? I can't get it to not do working trees in the repo
<bob2> bzr init-repo --no-trees
<bob2> you can alias init-repo to 'init-repo --no-trees' if you like
<lamalex> :P as soon as I asked i got it
<lamalex> thanks
<lifeless> vila: your --load-list is quite nice, thank you
 * jml <3 branch-todo
<lifeless> jml: ?
<jml> lifeless: I'll explain later :)
<lifeless> jml: I have a feedback loop going with tests
<lifeless> jml: bzr selftest --load-list=foo.list, where foo.list is from selftest --subunit | subunit-filter | tail -n +2 > foo.list
<lifeless> jml: 'run only failing tests'
<jml> lifeless: *nod* that'd be very handy to have for lp
<lifeless> I'll do some more on it this evening I hope
<lifeless> would likst to get foo.list by $() rather than a file on disk, or something like that
<lifeless> jml: so, see my most recent post to bazaar@, it has the glue needed for a pyunitish runner
<jml> lifeless: cool
<ronny> moin
 * ronny still fails to see how transitive history needs uuid's
<ronny> mlh: thanks
<lifeless> jml: what are you doing tomorrow evening?
<vila> hi all
<vila> lifeless: glad you like it :-)
<dholbach> hiya
<dholbach> pushing a branch to LP with bzr 1.11-1 I get "Permission denied (publickey)" although my pub key is exactly the same as the one I have on LP
<dholbach> is there any known issue?
<mthaddon> dholbach: sure you're connecting as the right username?
<dholbach> mthaddon: I don't think I changed anything
<dholbach> email = Daniel Holbach <daniel.holbach@canonical.com>
<dholbach> launchpad_username = dholbach
<mthaddon> dholbach: ok, just checking - not sure if it's a known issue, haven't used bzr 1.11-1 myself
<dholbach> it's in jaunty now
<mthaddon> brave soul - still on intrepid here
<dholbach> where do I use "-Dhpss"?
<dholbach> it tells me to use it
<dholbach> argh, now it worked
<dholbach> ok... whatever
<dholbach> I'll let you know when I run into it again
<mthaddon> I won't be much use - not an expert in any way, just happened to be idling here...
<mthaddon> but I'm sure someone else will
<jml> lifeless: travelling to Hobart
<vila> poolie: ping
<spiv> lifeless: you'll be happy to know I have a working right arrow key again.
<lifeless> spiv: cool
<lifeless> spiv: you hit it harder?
<lifeless> jml: well then, upon your return
<fullermd> Obviously, it started acting right   :p
<spiv> lifeless: if by "hit" you mean "took the cap off and removed a pile of impacted crud", then I guess so...
<spiv> It doesn't quite like new, but it basically works...
<mbp__> hello spiv, lifeless
<mbp__> lifeless: thanks for the post this morning about gc
<fullermd> I've managed to not have to do a significant keyboard cleaning on this one yet.  Next month is its 18th birthday, too.
<mbp__> kiko, i'm writing up http://bazaar-vcs.org/Roadmap/BrisbaneCore
 * fullermd should throw a party.
<mbp__> wow
<mbp__> fullermd: it must even predate PS/2 connectors?
<fullermd> Wikipedia says PS/2 was 1987.
<fullermd> But the cable is detachable, so it could have come with an AT connector originally I guess.
<mbp__> kiko ^^
<kiko> I don't know a lot about PS/2 but brisbane sounds like just the place for summer
 * fullermd recalls laughing his head off at http://ars.userfriendly.org/cartoons/?id=20010211
<kiko> mbp__, can you tablify that? tables beat lists
<kiko> well maybe.. hmm
<mbp__> for the tasks?
<mbp__> working on it
<kiko> maybe
<mbp__> at least a table is better if we have estimates
<kiko> indeed, indeed
<mbp__> at the moment i'm adding more descripiton of the changes and digging up some numbers
<mbp__> yay numbers
<mbp__> the infallible indicator of objective truth :)
<fullermd> Except 8.  I don't trust him.  Shifty eyes and all that.
<Toksyuryel> and 13
<Toksyuryel> unlucky n' such
<fullermd> Yeah, but it's reliably unlucky.  So it's infallible in a way   :p
<awilkins> Yegods, this "Python DVCS comparison" thread is long
<awilkins> I think the attitude that "We want all the benefits of a DVCS without changing how we work" attitude is rather blinkered though
<fullermd> If only that were the most blinkering I ran across in a day...
<AfC> But it's worse than that - many people have already fought the learning curve to learn git, and now we seem both cumbersome and slow as a result.
<Odd_Bloke> awilkins: I dunno, we claim to be flexible, but are we actually?
<Odd_Bloke> (I think so, but maybe we could be more flexible)
<fullermd> Considering that the complaints all seem to boil down to "TOO flexible", how would that help?   :p
<Toksyuryel> that's a silly thing to complain about though
<Toksyuryel> if you don't want to use the flexibility, don't
<fullermd> It's a silly world.
<AfC> I suspect a global [per user, anyway] revision cache would help enormously.
<AfC> bit late now, though
<Toksyuryel> it's not foisted on you
<fullermd> I don't see it, personally.
<fullermd> To be much use, it would have to be several times the size of a "large" project.  Otherwise anything you want would be cycled out by the time you'd profit from it.
<fullermd> And that's *BIG*.
<AfC> fullermd: (if you're talking to me) no, I'm not talking about in-memory, I'm talking about never ever forcing someone to network transfer the same revision twice in from a remote location. I imagine `bzr init-repo ~` would do it.
<fullermd> Of course, the solution to the direct problem is "If you want to work just like svn, just use co --lightweight".  Then we can move on to "zomfg that's slow" and make forward progress on letting them keep marching toward the cliff.
<fullermd> I don't mean in-memory, I mean wherever; it would have to be a couple gig at least to get a high enough hit rate to be worth it.  I don't have a could gig to spare.
<AfC> fullermd: but since that isn't what the Bazaar hackers expect you to do, it's not a good idea to suggest.
<fullermd> And "Use bzr, it'll keep anything you ever pass to it around forever cluttering your hard drive" isn't the best advertising either  :p
<AfC> fullermd: assume for a minute you don't know about a) shared repos and b) creating local mirrrors of remote branches. Then do bzr log on a large remote branch a few times and you'll start appreciating how awful Bazaar appears to people.
<AfC> That is, in essence, the critique that the Python crew have levelled, and it has as a result disqualified us.
<fullermd> Did I say something that gave the impression that I fail to appreciate how awful performance is in many cases?
<Odd_Bloke> AfC: 'bzr init-repo ~' has a couple of problems.  Firstly, it's not a cache (you can't delete ~/.bzr safely), and secondly, as noted on the mailing list, it assumes people work underneath a single directory.
<AfC> Odd_Bloke: sure. Admittedly, though, most people work under ~ :)
 * fullermd branches into /tmp with some regularity.
<Odd_Bloke> AfC: Windows users don't.
<AfC> fullermd: I don't really think any of us in this channel qualify as normal users in so far as Bazaar (or any DVCS) is concerned
<AfC> Odd_Bloke: that's fine. They can `bzr init-repo c:`. Suckers.
<AfC> ENOSYMPATHY
<AfC> :)
<fullermd> Anyway, the solution to logging large remote is to use a dumb server.
<fullermd> log --limit 10 bzr.dev.   sftp: 7 seconds.   bzr+ssh: 40 seconds.
<fullermd> Doesn't help when they branch into d: now does it?   :p
<AfC> fullermd: it doesn't matter that there is a "solution". The problem is that out of the box the way that most people try to use Bazaar turns out not to be wise. So then we tell them how they should use the tool (thus voiding most of the supposed flexibility) and then they bitch at us for being so presumptuous.
<fullermd> Er.  I was being ironic...
 * AfC has, in essence, given up advocating Bazaar. I'm tired of shouting at the rain. It's too bad we picked bzr because we really appear to be zealots out in left field for using it.
<fullermd> You seem to keep getting this impression that I'm defending the status quo and mocking the poor silly users who just don't Get why it's so vital to use the DUMB SERVER to get good performance...
<AfC> Such a shame, because I'm very happy with it.
<AfC> fullermd: I would advise against sarcasm in discussions like this. Most people won't get it.
<AfC> fullermd: especially when we're exploring the question of whether it's too late for this project.
<fullermd> But back to the thread in question, the activity of hg would be exactly the same; a fresh clone would still pull everything across the network.  The activity of git would be example the same; a fresh clone would still pull everything across the network.
<AfC> fullermd: right, but in the Git case, the *second* transaction would NOT pull everything - or anything - across the network.
<fullermd> The difference is only when you pull another branch into an existing repo.  That brings us back to metabranches.
<AfC> fullermd: since we support NOT forcing a full mirror since we support anonymous remote operations, we look bad for doing 100s of MB of transfer just to do a log only to force another 100 MB of transfer to run the same command again.
<AfC> Like I said, too late now.
<fullermd> Again, what are you trying to convince me of?  Have you EVER seen me advocate to ANYBODY to do `log URL`?
<AfC> fullermd: I'm not talking about YOU. Relax. I'm talking about the tool that you and I both have stuck our necks out for. The tool permits that behaviour, and so people think that's what they're supposed to do, and so they do, and then the tool looks horrible.
 * fullermd shrugs.
<fullermd> I've lost much ability to care about those people.  The train has long since pulled out of the station, and it doesn't matter anymore.
<AfC> fullermd: you're lucky, then. I work in a community where virtually every other project has adopted Git, or will. So I'm odd man out, and suffering for it.
<AfC> it sucks.
<fullermd> Projects will use bzr because political forces dictate (like emacs) or somebody with enough clout likes bzr and decides to impose it (like I did).  Anybody else will look at it and say "slower than other choices", and game over.
<AfC> yup
<awilkins> I use Bazaar because I had a project that needed really good merge support, it's being used by neophytes, on Windows     ; hg can't handle the tree because it's too deep for it on Windows, git is too scary
<awilkins> The performance leaps of bzr between 0.9 and 1.6 on win32 were really gratifying
<fullermd> On the day when bzr reaches performance parity, it still won't gain much, because then it'll be "the program that's no longer as slow as it used to be"
<AfC> fullermd: shit, I've been trying that line for over a year now.
<awilkins> It started off just "ooh, much faster than SVN" and became "wow, that's nice and fast"
<AfC> fullermd: and indeed, it didn't help
<AfC> Whatever. It's nice and fast for me. That's good enough.
<AfC> But as you said, game over.
<awilkins> You then use it on Linux and go "Holy crap, WTF is windows DOING under the bonnet?"
<awilkins> The fact that it's written in a langauge I grokked easily enough to pick up was a real plus ; several windows bugs have been fixed that way
<fullermd> Obviously, the real trick is to slow everybody else down.
<fullermd> Look how well that strategy has worked for web browsers.
<awilkins> I'd like to see a 4-way DVCS/SVN benchmark on Windows
<fullermd> Remember when you refused to move to Netscape 4, because it was a stupidly slow unbelievably bloated pile of crap?
<awilkins> I'm not sure git would be such a clear winner on Win32
 * fullermd laughs in his past self's face.
<fullermd> The flaming death for bzr is network.  The platform won't affect network that much.
<fullermd> I'm left with the assumption that, for whatever reason, bzr didn't grab enough mindshare early on, and the manpower deficiency has left it permanently in the hole.
<Lo-lan-do> I think bzr can still prevail within the "enterprise".
<Lo-lan-do> It is, after all, easy to use, and seeing how much effort is required to get people to switch from CVS to SVN, getting them to switch to git is going to be *ugh*.
<Lo-lan-do> Remember not all paid developers are uber-elite geeks :-)
<awilkins> Linux format had a "bluffers guide to git" this month
<Lo-lan-do> (And not every VCS user is a developer, either)
<fullermd> Paid developers do whatever the paymaster says.
<ronny> hmm
<fullermd> Heck, we just covered "bzr is way more flexible than everything else".  Flexible is kinda the opposite of what enterprise aims for  ;p
<ronny> i came to the conclusion that all dvcs's suck
<awilkins> What DVCS really needs for use in the enterprise is gui tools with a good visual metaphor for the distributed-ness
<Odd_Bloke> fullermd: I think Lo-lan-do's point is that it'll be easier to convince the paymaster than the paid developers.
<ronny> awilkins: i will probably do such a gui tool that manages git/hg/bzr
<Lo-lan-do> My point was that it took me *years* to get people to use CVS at a previous job, and I left before managing to get them to switch to SVN even though the syntax/UI is identical.
<fullermd> I dunno if that's true.  Really, the business case is pretty much like the open source case.
<fullermd> You'll never convince the bulk of the project to move to foo.
<awilkins> I always do think that Tortoise[DVCS] should just be one codebase with backend plugins
<fullermd> Some group of sufficiently interested and clouted parties will make the decision, and drag everybody else along.
<ronny> awilkins: im working on such a thing ^^
<ronny> the catch is i dont yet have history/sync support implemented ^^
<fullermd> bzr's advantages in flexibility and workflow just aren't obvious unless you (a) think carefully about it, or (b)(1) use it for a while without (2) trying to make it act like $OTHER_VCS.
<fullermd> Performance, however, is trivially easy to test and very easy to natter on about to convince people.
<ronny> and the comclusion is - all dvcs's suck and are awfull (just less bad than the centralized ones)
<ronny> -m+n
<fullermd> So really, there are 3 types of people who end up with bzr.
<fullermd> (1) the people who are already there
<fullermd> (2) the people who are drug there by someone with enough persuasive power
<AfC> fullermd: re your original "flexibility and workflow just aren't obvious unless you (a) think carefully about it, or (b)(1) use it for a while without (2) trying to make it act like $OTHER_VCS", hear, hear
<fullermd> (3) the people who like VCS's in particular or tools in general enough to spend a lot of time playing and fiddling with the options, and have usecases where the performance is "good enough".
<ronny> fullermd: i just recently moved some bzr managed projects i inherited to hg cause bzr wont let me do my workflow
<fullermd> Me, I'm used to using totally superior solutions that most people bypass for mostly ill-thought-out reasons.  I run FreeBSD.
<Lo-lan-do> Is FreeBSD still totally superior?
<Lo-lan-do> (Genuine question -- it's been years since I last tried it)
<fullermd> Of course.  That penguin doesn't stand a chance against something with horns and a trident.
<ronny> it certainly has less stupid
<Odd_Bloke> ronny: What's your workflow?
<fullermd> I think so, obviously.  It's just so much easier to manage long-term.
<ronny> Odd_Bloke: inherited from using monotone, i want multiple heads in one place, and i dont particulary have to care if they get names
<fullermd> (now, if we could harness the elastic force of yanking that far off-topic...)
<ronny> fullermd: bsd seems to be generaly free of micro-otimizing bullshit (compilers evolve for a reason)
<ronny> bbl, gona eat
<bob2> ronny: bzr can do that
<fullermd> Ono, not this discussion again...
<Mez> are nested branches working yet ?
<ronny> bbl, gona eat
<ronny> bob2: until collated branches it can do it
<ronny> eh cant
<bob2> ronny: the ui is a bit dodge, but you can do it
<bob2> ronny: push to a repository and the tips will just hang around forever.  use 'bzr heads' to see the current ones.
 * fullermd blinks.
<fullermd> Using explicit branches is too obnoxious for him, so you suggest grubbing around under the hood instead?   :p
<bob2> haha
<ronny> bob2: fuck unnatural hacky in particular unplanned workflows - either it works good or it's useless
<fullermd> "I'd like a sandwich, but until bzr's bread comes presliced, it's too much trouble."  "Well, bzr lets you grind wheat..."
<bob2> ronny: ok!
<ronny> anyway, on the conceptual level i dislike all common dvcs's
<Odd_Bloke> ronny: How would you do it differently?
<awilkins> Whoa, python just ate 101% of CPU time doing a bzr-fast-export
<ronny> Odd_Bloke: collated branches for bzr will mostly solve it
<awilkins> Is that a known bug in `top` ?
<Odd_Bloke> awilkins: How many CPUs do you have?
<awilkins> This is a 1 CPU boxy (with HT)
<Odd_Bloke> That might do it.
<Odd_Bloke> I don't really know.
<ronny> Odd_Bloke: oh, you mean how i would do dvcs different?
<fullermd> Rounding errors like that are hardly unknown in top   :p
<Odd_Bloke> ronny: Yeah.
<fullermd> (rather, in stats reporting like that in general)
<fullermd> Race conditions and observer skew and yada yada yada.
<Toksyuryel> this has me curious too
<ronny> Odd_Bloke: gits model is nice, but it needs more metadata
<ronny> and of course no git around it ;P
<Toksyuryel> I bet you could write a bzr plugin to do it
<ronny> no
<ronny> bzw wont get content addressing
<awilkins> More like a git porcelain that looks like bzr
<awilkins> I dunno, people rate about gitk but I just fast-exported my big branch here and it looks a right mess in gtik
<awilkins> Maybe I'm not giving it enough hints
<ronny> duno, git only tracks snapshoots of trees
<ronny> makes it very messy for tracking history
<awilkins> Damn.... git _is_ fast
<awilkins> Just did git reset --hard on my fresh imported repo with no tree - p'chow!
<Mez> any of the devvies around ?
<Odd_Bloke> Mez: Don't ask to ask, etc. :)
<Mez> Odd_Bloke: I asked earlier :D noone responded :D
<Odd_Bloke> In re: nested branches?
<Odd_Bloke> I think the short answer is 'no'.
<Mez> :(
<Mez> long answer?
<Odd_Bloke> Real Soon Now. :)
 * Mez headwalls
<Odd_Bloke> I believe LarstiQ is working on it.
<beuno> Mez, there are very strong rumors that someone will be working on it full time-ish soon
<beuno> so maybe we'll get that in a few months
<mrevell> vila: ping
<vila> mrevell: pong
<LarstiQ> Odd_Bloke, beuno: http://bazaar-vcs.org/NestedTreeProgress should be the focal point of nt progress
<Odd_Bloke> Mez: ^
<Odd_Bloke> LarstiQ: Thanks. :)
<LarstiQ> now, I'm down to a couple of conflicts in merge.py and transform.py, so updating that page is next
<LarstiQ> we're going to visit my girlfriend's brother now, so ciao :)
<Odd_Bloke> LarstiQ: Have fun. :)
 * vila doesn't quite follow how the nested boyfriend comes into play...
<jam> morning vila
<vila> hi jam, stop loonking above my shoulder I am *already* reviewing your patch !
<jam> :), I was just saying good morning
<vila> :)
<beuno> healthy paranoia
<jam> well.. paranoia, we can discuss the "healthy" part
<jam> 8)
<vila> On my right screen I was looking into bbc tests, I think the first failing ones are for you, but obviously your plate is already pretty full today
<vila> I say for you because they seem to be related to some '\n' splitting
<vila> ./bzr selftest -s bzrlib.tests.per_repository_chk.test_supported.TestCHKSupport.test_pack_preserves_chk_bytes_store
<vila> should include them all
<vila> -s rocks :-)
<Goundy> guys I want your advices on organizing my project repository
<Goundy> I'm writing a server/client gaming suite (for poker atm)
<Goundy> So I have the client + the server + the project website
<awilkins> Is it a problem to just have it all in the same tree :-)
<Goundy> Atm I've two branches: One branch mainline which contains two directotries (client and server)
<Goundy> and another one for the website
<awilkins> Why separate client/server branches?
<Goundy> someone think i can do better ?
<Goundy> awilkins they're not seperated
<awilkins> Ah, sorry,
<awilkins> Misread
<beuno> Goundy, is the client open source?
<Goundy> it's the same branche and it contains the sources in different dirs :)
<beuno> (is the server?)
<Goundy> beuno all's open source :)
<Goundy> I'm hosted on launchpad :)
<beuno> Goundy, then I'd think the separation is good
<Odd_Bloke> Heh, 'in before'.
<beuno> client + server on one side, and webpage on the other
<Odd_Bloke> Goundy: Sounds good to me.
<Goundy> beuno well I thought the same thing also but guess what a serie can only have one branche :/
<Goundy> beuno client and server in the same branch ?
<Odd_Bloke> Goundy: It does depend how closely linked they all are.
<Goundy> That's what you're saying ?
<beuno> Goundy, a LP series you mean?
<Goundy> beuno yes
<Odd_Bloke> If the website is going to heavily depend on code from the other branch, maybe you want it in the same branch...
<Goundy> Odd_Bloke well the link is the networking heh client <> server :Ã¨)
<Goundy> well the website is totaly in xhtml atm
<Goundy> the server is in C and the client in Java :Ã¨)
<Goundy> The server and the client aren't linked at a source level
<Goundy> and the website isn't linked to these sources.
<Goundy> ( https://code.launchpad.net/~auresdev )
<Goundy> Here's my current organization
<Goundy> So you think I'm good keeping it that way guys ?
<jam> vila: yeah, that failing test is because we changed the serialization format, and didn't change it there
<jam> it isn't really about '\n', just about having another line of data
<jam> vila: fixed in brisbane-core
<funkychicken818> hey
<funkychicken818> i have a merge a repository and it want me to run bzr update but i do not want to run the merge i want to simply remove it cause it screws up my files
<funkychicken818> and when i try to run a push from another repository i says that nothing has changed
<funkychicken818> hello?
<Demosthenes> regarding nesting, isn't there some support for nesting in bazaar?
<Demosthenes> i'm trying to model several users with a copy of their own data, centralized into on place for reporting, by pulling from the user branches....
<bialix> fullermd: what do you mean by: "(b)(1) use it for a while without"
<bialix> fullermd: you talk about: "flexibility and workflow just aren't obvious unless you..."
<lifeless> Mez: its not finished, and I don't know anyone currently developing it
<Mez> lifeless: apparently LarstiQ is...
<Mez> though, by-value should suffice for my needs
<lifeless> Mez: 'actively' :P
<lifeless> jam: ping, test_sprout_uses_bzrdir_branch_format
<jam> lifeless: pong
<lifeless> vila: "is used as an id by several tests" -> does this load them all, or fail to laod ?
<lifeless> jam: hi, I replied to the mail
<lifeless> jam: like to get this bedded down today so I can put the branch (which contains a lot more fixes :P) up
<jelmer> if somebody could have a quick look at my InterBranch patch, that would help me a lot
<jam> so what are you trying to change that would cause this test to break?
<jam> I can sort-of agree that RemoteBranchFormat doesn't contain a lot of info
<jam> but I don't see why the test would specifically break because of it
<lifeless> jam: the direct cause is that branch_implementations was testing RemoteBranch using the real branch object
<lifeless> due to round about things
<jam> and so it was passing by accident?
<lifeless> oh yes
<lifeless> and when I looked at it
<lifeless> I could see it actually ends up asserting that the proxy object is a proxy object, which while it meets the letter, doesn't meet the spirit
<jam> so what we want to assert is "source.sprout()" creates a target branch in the type that was initialized by the bzrdir object.
<jam> I don't know that it matters for Remote
<lifeless> well sure, because if I sprout into a remote url, I want to copy across still
<jam> If you push into a remote url, you want to preserve the source format, yes. But that isn't what this is testing.
<jam> If you push "--stacked" into a remote url
<jam> you want a stackable format on the target
<lifeless> what you specifically test though is, 'branch.sprout(a_bzrdir) uses a_bzrdir's branch format'
<jam> lifeless: right
<jam> as that is how "branch --stacked" support is implemented
<lifeless> spiv and I were nearly quoting zork looking through this yesterday :)
<lifeless> so
<lifeless> if I change
<lifeless> self.assertIs(self.branch_format.__class__, target._format.__class__)
<lifeless> to
<lifeless> self.assertIs(target_bzrdir.branch_format.__class__, target._format.__class__)
<lifeless> would that still be correct? It seems more obviously so to me, because its testing the direct behaviour
<lifeless> rather than relying on the assumption that self.branch_format == target_bzrdir.branch_format
<jam> umm... if "self.make_bzrdir('target').branch_format != self.branch_format" we have a serious problem with the test permutations code
<jam> as it means we aren't actually testing the permutations we think we are testing.
<lifeless> jam: one is backed by a real bzr dir object
<lifeless> one is completely fictional
<poolie> hello
<jam> lifeless: but it is important to be testing the "fictional" apis
<jam> hi poolie
<jam> We *need* to be testing that  RemoteBranch conforms to the api that the rest of Branch does
<jam> I could accept that _format members may not be identical, etc.
<jam> So if you have a case that "X._format != self.branch_format" I can accept that
<lifeless> jam: get_cloning_metadir gets a real branch format, not a RemoteBranchFormat
<lifeless> jam: *because* of the way stacking is addressed
<jam> As long as isinstance(X, ?) is still correct
<lifeless> jam: so we need to test the apis that are used, not the fictional ones
<lifeless> jam: self.branch_format is a RemoteBranchFormat; target_bzrdir is a RemoteBzrDir; target_bzrdir.branch_format is a BranchFormat5/BranchFormat6/BranchFormat7
<lifeless> hi poolie
<poolie> hi
<jam> lifeless: I'm willing to give in to someone who is focused on that portion of the code right now.
<jam> But if target_bzrdir is a RemoteBzrdir then it seems that target_bzrdir.branch_format *should* be RemoteBranchFormat
<jam> I need to go pick up my son to be back in time for the standup.
<jam> I don't want to block you
<jam> and I'll admit to not having a perfect understanding of what the code should be
<jam> get_cloning_metadir() probably needs real objects
<lifeless> jam: I would have thought so to, but then I looked :)
<lifeless> and cloning_metadir() on remote delegates to _real_bzrdir
<lifeless> so yes, we end up with real objects being initialized on a remote branch
<lifeless> one side effect of that is that we initialize via VFS calls
<lifeless> 100 or so in fact
<jam> lifeless: which seems incorrect
<lifeless> andrew and I would like to fix this
<jam> anyway, I do need to go, bbiab
<lifeless> ciao
 * lifeless is fooding
<bialix> a while ago I've read the article about dagger fixes. I can't find it anymore with google. Anybody has the link or the saved article text?
<lifeless> 'dagger fixes?'
<jelmer> s/dagger/dag ?
<mwhudson> poolie: can you explain to me the relationship between progresstask and progress bars?
<lifeless> bialix: oh, 'daggy fixes'
<bialix> daggy? mmm, perhaps
<jelmer> bialix: a dagger is a kind of knife IIRC
<bialix> it sound similar, is not?
<lifeless> http://monotone.ca/wiki/DaggyFixes/
<lifeless> bialix: yes, its a false friend
<bialix> yes, it's what I need
<poolie> it is kind of similar, being a pointy bit
<poolie> mwhudson: um
<bialix> "daggy" -- queer word
<mwhudson> poolie: bzrlib.ui.ui_factory.nested_progress_bar returns a task it seems
<poolie> mwhudson: we used to have just one ProgressBar class
<bialix> lifeless: thanks
<poolie> i'm now doing a model:view separation
<mwhudson> ah right
<poolie> the model object is a ProgressTask
<poolie> however some of the apis have not been renamed yet
<poolie> does that help?
<mwhudson> yes
<mwhudson> what launchpad wants to do is intercept all progress reports
<mwhudson> i just don't quite see how to impose my own progressbar class any more
<mwhudson> (or indeed, if attacking this at the view level is the right place)
<mwhudson> it seems like i could do this by overriding _progress_updated in my uifactory, but um
<poolie> you should provide your own ui
<poolie> modulo bugs, that should be able to completely replace any concept that progress bars are being drawn on a tty
<mwhudson> right
<mwhudson> i'm just not completely sure what this ui should do :)
<mwhudson> maybe it should override _progress_updated
<poolie> nested_progress_bar should not be overridden
<poolie> yes
<poolie> progress_updated is the main one you should care about
<mwhudson> the _ scared me off
<poolie> do you just care about "it's still alive"?
<mwhudson> yep
<mwhudson> the process gets killed after 15 mins of inactivity or something
<poolie> calls to that indicate that it is
<poolie> um
<poolie> possibly we should give the ui a chance to return an object upon which progress_updated will be called
<poolie> ie the view object
<poolie> but i didn't do that yet
<poolie> then it would make sense for the model just to be directly constructed
<mwhudson> you mean get rid of nested_progess_bar?
<mwhudson> anyway, i'm at least moderately happy as i can delete some code now :)
<igc> morning
<jam> poolie: I just missed it, ring again
<mwhudson> though overriding a _method means that i'll get to do this again in a month
<poolie> sorry
<poolie> it is the intended method
<mwhudson> cool
<mwhudson> it's hard to distinguish between "don't call this unless you know what you are doing" and "this may go away"
<lifeless> mwhudson: 'method' is for 'clients of bzrlib use/fully public/fully supported'
<lifeless> mwhudson: '_method' is for 'for subclassing/private do not use/unsupported use but be ready to update'/
<poolie> mwhudson: also and "this is public for subclassing" and "for calling"
<lifeless> mwhudson: too many bits, not enough space
<poolie> wot he said
<lifeless> mwhudson: so ready the docstring, we try to be clear there :)
<mwhudson> yeah, this says "Should be specialized to draw the progress."
<mwhudson> so woot
<poolie> mwhudson: i'd like to come back and clean it up more
<poolie> will ping you when i do
<mwhudson> poolie: thanks
<Odd_Bloke> lifeless: I think LarstiQ has been doing some nested tree stuff recently.
<vila> lifeless: they are loaded, that's how I detect that several ones have the same id (which may be a problem or not, it seems wrong to me in general, but I don't know that it can cause a problem except when one fails and you try to understand which one)
<Odd_Bloke> He and jelmer were pairing on it at FOSDEM, possibly...
<lifeless> vila: cool, we should fix them, but not-right-now
<vila> jam: thks for the fix
<lifeless> vila: did you see my two patches yesterday (in bzr.dev now)
<vila> lifeless: if you found same, mail them to me, I'll record them in my TODO list
<lifeless> vila: the second one has a plugin for bzr/subunit, which you will probably like :P
<lifeless> vila: '"bzrlib.tests.tree_implementations.test_walkdirs.TestWalkdirs.test_walkdir_versioned_kind(DirStateRevisionTree)" is used as an id by several tests
<lifeless> '
<vila> lifeless: I would like to look at the one around the command, but didn't find th etime yet
<lifeless> vila: you can just drop the code in the second one into ~/.bazaar/plugins/subunit
<lifeless> vila: as long as you have subunit installed :P
<jelmer> subunit \o/
<lifeless> jelmer: yeah, I got around to my long threatened 'I should be able to use this with bzr'
<jam> vila: which fix would that be?
<vila> subunit appeared on my radar quite strongly today especially the 'reports to the parent as tests begin and end' since I'm currently thinking about parallelizing the test suite...
<vila> jam: hehe, the bbc one :)
<jam> ah, yeah no prob
<jam> are the tests close to all passing now?
<jam> (did you get poolie's work?)
<vila> I didn't work much on them I wanted to review igc patch about log multiple files and directory
<vila> I've seen poolie's work yet
<vila> In fact, I'm not there, I'm in bed and I sleep :)
<vila> I've *NOT* seen poolie's work yet
<vila> grr
<vila> sleeping indeed :)
<lifeless> spiv: can I delete FakeRemoteTransport? used in one, disabled, test
<spiv> lifeless: sounds good
<poolie> vila, i'll send today i promise
<vila> poolie: I asked nothing ! I don't even know what you're talking about :-) But I'm curious now... will I be able to sleep ? :)
<jam> lifeless: I'd like to chat quickly about '\n' delimited chk records
<jam> vila: poolie did some work on making the test suite pass
<jam> he claims he made progress
<jam> nobody else has seen the results :)
<jam> I think he is secretly planning on actually doing the work
<jam> and then sending it
<lifeless> jam: sure thing
<jam> lifeless: so... I think it is a good decision to use '\n', as it means we don't have to try quite as hard to make a compressor that is not line based
<jam> my main concern is "compatibility"
<lifeless> with?
<jam> I introduced the hash prefix stuff
<jam> in such a way that we can read -dev4 or hash based ones
<jam> should I try to do the same for this
<lifeless> so the hash thing I think thats worth doing, because we're still comparing IMO
<lifeless> however this \n is trivial its not a strategic decision, if you like
<lifeless> its should have little to no long term impact
<lifeless> so JFDI imo
<jam> k
<lifeless> twiddle a bit in the dev3 and dev4 disk format labels to stop confusion
<jam> it makes *my* life a lot easier :)
<jam> doing it means fixing a lot of serialization dependent tests, so getting the answer up-front is important
<jam> I sent my hash prefix stuff to the list just now
<jam> igc: I think I know why you couldn't reproduce bug #328135
<ubottu> Launchpad bug 328135 in bzr "bzr init-repos --development-wt5-rich-root gives: "AttributeError: 'module' object has no attribute 'WorkingTreeFormat4'"" [High,Fix committed] https://launchpad.net/bugs/328135
<jam> I would guess you had a plugin that did "import bzrlib.workingtree"
<jam> which was happening *before* the initialize() code was doing it
<jam> I'm not sure why I *don't* have a plugin which does that
<jam> though I did spend a bit of time to make a couple of my installed plugins a bit more "lazy"
<igc> jam: interesting. Thank you *so* much for tracking this down
<jam> igc: you can test yourself with "python -c 'import bzrlib.workingtree_4'"
<jam> that should break
<jam> (even with my fix)
<jam> but at least it isn't user-visible for now
<igc> jam: yep, that breaks for me
<jam> lifeless: do you think we need to keep -dev3 around?
<jam> igc: now, in theory, this would pass "python -c 'import bzrlib.plugin; bzrlib.plugins.load_plugins(); import bzrlib.workingtree_4'"
<lifeless> jam: I think its clearly substandard, so no
<jam> lifeless: that was my feeling
<jam> if I was going to change the format string, I may as well get rid of it
<lifeless> jam: sure
<igc> jam: yes, that works
<jam> igc: there you go :), I assume "bzr init --development-wt5 --no-plugins" would also fail for you
<igc> jam: yes
<jam> I believe that should work on the bzr.1.12 branch
<igc> lifeless: so groupcompress has a minor bug - it needs to import repo_registry before the 'if chk' test
<igc> lifeless, jam: also, so we please start using WorkingTreeFormat5 in the new dev formats
<igc> s/so/can/
<igc> that will increase testing
<jam> igc: not by a lot, but sure
<jam> I'll go ahead and bump everything to v5
<jam> just to make it obvious
<lifeless> jam: have you looked at performance with mmap?
<jam> lifeless: I have a branch which changes LocalTransport.readv() to use mmap to return the strings
<jam> My initial tests showed no real difference
<jam> But I didn't test thoroughlty
<lifeless> jam: I'd like to try minimising the open() calls
<jam> lifeless: yeah, it cached the mmap
<jam> and then trapped for rename(), tec.
<lifeless> ok call
<lifeless> ok cool
<jam> lp:~jameinel/+junk/bzr-mmap-readv
<igc> jam: were you going to send the development-wt5 to bzr.dev or wait for poolie to merge the 1.12 changes across?
<jam> It does a "trace.note()" when used
<jam> just to be sure
<jam> igc: I was just waiting for 1.12
<jam> since it is ~today
<igc> jam: np. I'll update the bug report to say as much
<lifeless> do teams have +junk?
<lifeless> spiv: so, the disabled test turns out to be one that would have trapped the double get_stacked_on verb call :)
<Demosthenes> regarding nesting, isn't there some support for nesting in bazaar?
<Demosthenes> i'm trying to model several users with a copy of their own data, centralized into on place for reporting, by pulling from the user branches....
<Demosthenes> the master doesn't seem to like committed when subdirs are branches.
<Demosthenes> er, committing
<lifeless> Demosthenes: there isn't user-ready code, no.
<lifeless> LarstiQ: you need a bot to pipe up here
<lifeless> spiv: bzr: ERROR: [Errno 2] No such file or directory: '/tmp/testbzrG-RDn6.log'
<lifeless> spiv: I think there is a bug actually, in the log related test code, cause I'm getting that and I'm not working on write groups ;P
<lifeless> spiv: something like a gc event causing it
<Demosthenes> lifeless: so i'm better off symlinking or putting the "child" branches in sibling directories then.
<lifeless> Demosthenes: or merging them into subdirs - see the merge_into plugin
<spiv> lifeless: chatting to thumper atm
<lifeless> spiv: when you can, I have a nontrivial issue in this branch
<mwhudson> poolie: this is the ui factory code i have now, does it look vaguely sane? http://pastebin.ubuntu.com/117472/
<garyvdm> poolie,luks:  Alex is not around so I'm asking you guys. We have a regression in qbzr 0.9.7 - bug 327395 - we allready have a fix - should we do another release with just a cherrypick of that fix - to be included in bzr 1.12 finial?
<ubottu> Launchpad bug 327395 in qbzr "qinit does not work" [Medium,Fix committed] https://launchpad.net/bugs/327395
<poolie> hey
<poolie> mwhudson: yes that looks good
<poolie> i'd also like to factor out the various types of questions we ask the user into abstracted methods
<poolie> so you don't need the icky string compare
<mwhudson> poolie: yes, that would be nice :)
<mwhudson> poolie: thanks for the sanity check
<poolie> garyvdm: so where would this change have to be included?
<lifeless> woo nearly there
<poolie> in the bzr branch, or just in the windows installers?
<lifeless> poolie: windows / macosx installers from the look of it
<lifeless> garyvdm: doing a release makes it clearer to folk, I'd say do one
<garyvdm> Ok -
<garyvdm> Should I call it 0.9.8 or 0.9.7-rc2 or ...?
<poolie> what was your previous release, rc1?
<garyvdm> Just 0.9.7
<poolie> if you're just changing that i'd just call it final
<garyvdm> I guess that because we did not specify rc1 on the prev release - we have to call it 0.9.8
<lifeless> spiv: ok, that fail list all passes now.
<lifeless> whew
<lifeless> spiv: so I'm running all tests again, see if there are any new fails
<spiv> lifeless: woo
<spiv> lifeless: yeah, I'm pretty sure from yesterday that the test infrastructure's handling of the log file is busted, because I kept hitting it
<spiv> something to do with raising an exception during a cleanup func perhaps?
<spiv> So long as my tests weren't erroring it was fine ;)
<mthaddon> anyone able to comment on https://bugs.launchpad.net/pqm/+bug/191393/comments/3 - I'm assuming this is a bug in bzrlib rather than PQM, but just checking
<ubottu> Ubuntu bug 191393 in pqm "PQM outputs 'No handlers could be found for logger "bzr"'" [Undecided,New]
<lifeless> mthaddon: its likely a case where pqm needs to setup a handler or some such
<mthaddon> lifeless: but how come I can reproduce it in such a simple test? doesn't that suggest bzrlib.branch should be doing something different?
<lifeless> mthaddon: maybe :P
<mthaddon> who'd be best to comment on that?
<lifeless> mthaddon: its coming from the pytohn logging stuff
<jelmer> would somebody perhaps have time to have a look at my InterBranch patch?
<lifeless> bzr uses that to output progress data to  ~/.bzr.log
<lifeless> we kindof want that facility to work
<lifeless> possibly a better thing to do would be to check if there are no handlers, and if not setup either our normal ones, or null handler
<jelmer> It's blocking my bzr-git work a bit atm, as it's required to do bzr pull from remote git branches
<lifeless> jelmer: I'll try
#bzr 2009-02-13
<jelmer> lifeless: thanks, much appreciated!
<poolie> lifeless: could you repaste to me or point me to the numbers for gc performance on bzr.dev please?
<lifeless> http://paste.ubuntu.com/116333/ <- these?
<lifeless> poolie: or the usertest ones ian did?
<poolie> that looks right
<poolie> that's the first 1000 commits of bzr?
<Odd_Bloke> So I'm using looms for something at the moment.  I have two looms currently, and I have a change to make which belongs between them.  Can I do that in any sensible manner?
<lifeless> poolie: thats more
<lifeless> poolie: I have the first 1000 stats , one sec
<poolie> if this is more that's fine
<poolie> so it's something more than 1000 commits of bzr? all of them?
<lifeless> 7410
<lifeless> not sure of the revno
<lifeless> http://paste.ubuntu.com/117486/
<poolie> thanks
<lifeless> spiv: woo
<lifeless> spiv: no new failures, just that one test I discussed with John to tweak, and a 1200 line patch to eyeball :P
<spiv> Heh.
<spiv> Hmm, overdue for breakfast.
<lifeless> spiv:
<lifeless> # branch.sprout(bzrdir) is defined as using the branch format selected
<lifeless> # by bzrdir; format preservation is achieved by parameterising the
<lifeless> # bzrdir during bzrdir.sprout, which is where stacking compatibility
<lifeless> # checks are done. So this test tests that each implementation of
<lifeless> # Branch.sprout delegates appropriately to the bzrdir which the
<lifeless> # branch is being created in, rather than testing that the result is
<lifeless> # in the format that we are testing (which is what would happen if
<lifeless> # the branch did not delegate appropriately).
<spiv> lifeless: +1
<mwhudson> which reminds me of something
<mwhudson> what's the difference between clone and sprout?
<lifeless> mwhudson: push and branch
<lifeless> mwhudson: identical copy vs new line of development
<lifeless> spiv: so with that explanation, it seems reasonable to me, to say, if (remote), parameterise bzrdir with [arbitrary non-source branch format]
<mwhudson> ok
<lifeless> spiv: and otherwise leave well enough alone
<igc> lifeless, spiv: pull is giving me grief in brisbane-core saying ...
<igc> "must end write group before releasing wrote lock"
<lifeless> igc: that means that its breaking in a @write_locked decorator
<igc> I've spent 30 minutes trying to find the problem but no luck so far :-(
<lifeless> and the code path isn't aborting the write group [generally a bug]
<lifeless> igc: disable that assertion, you'll see another one pop up; I thought we logged the real one or something, but perhaps not yet
<igc> I've looked at the changes to fetch.py, repository.py and pack_repo.py but nothing stands out to my untrained eye
<lifeless> spiv: ^ does my plan scan for you ?
<igc> lifeless: ok, I'll try that
<lifeless> igc: or even (if its nt a blackbox test) a pdb call inside the point that that is raise, would let you look at sys.exc_info
<spiv> lifeless: yes, that sounds good
<spiv> igc: ah yeah, as lifeless says that's typically like TooManyConcurrentRequests â there's an underlying exception being lost by the failure to abort the write group.  If you can change abort_write_group or something to log the current exception first, or just reraise, that might help.
<lifeless> spiv: ok thats done and passing
<lifeless> spiv: suggstion: in those acceptance tests we have
<lifeless> spiv: put a ratchet now on the hpss call count
 * spiv nods
<lifeless> spiv: bombs away, putting up a bundle - you can pull that to get the final code
<spiv> Ok.
<lifeless> spiv: I think you didn't pair with me on enough of this that you can review it with clear conscience:)
<lifeless> in the meantime, I'm going to eat, then look at record_stream().next().get_network_bytes conceptually for a bit
<lifeless> possibly by walking, I think this is a thinking time
<jelmer> hmm, activity reporting works on svn transports but I'm not sure it should be kept in, it makes svn look slow :-P
<lifeless> jelmer: why?
<jelmer> lifeless: average speed is < 100kb/s
<jelmer> I'm getting much more than that for "native" bzr
<jelmer> lifeless: I was kidding, it works well
<fullermd> Hey, maybe there'll be an entirely new and original statement made in this thread about explicitly-vs-not tracking renames...
<jelmer> I guess I should just do some more optimization
<mtaylor> hey all you wonderful people...
<mtaylor> anybody gonna update the bzrtools package in the PPA?
<mtaylor> I'd like to upgrade my bzr but I can't because it'll uninstall bzrtools, and I use those too much ... :(
<igc> lifeless, spiv: so disabling that exception didn't work, nor did looking at exc_info() via pdb ...
<igc> it does have an exception there about NotABundle but it's a red herring caused by ..
<igc> an attempt to read the location as a bundle early in cmd_pull
<igc> comment that bit out and exc_info is (None,None,None)
<jml> mtaylor: I don't know the answer to your question.
<mtaylor> jml: oh well.
<jml> mtaylor: but many people are in the same boat as you. perhaps the things that are in bzrtools that everyone uses should be pushed into bzr proper
<mtaylor> jml: yes. perhaps so.
<mtaylor> jml: or, a release policy that ensures bzrtools goes to the ppa at the same time as bzr - I'd be fine with either
<igc> lifeless, spiv: it might be something dumb on my end - let me keep looking
<jml> cdiff, cbranch & clean-tree are about all I use from it.
<jml> patch sometimes
<mtaylor> shelve
<jelmer> mtaylor: shelve is in bzr itself these days
<mtaylor> shelve is my savior in many case
<mtaylor> is it?
<mtaylor> cool
<jelmer> there was also agreement about having clean-tree in bzr itself, but nobody has stepped up yet and actually done it
<mtaylor> heh
 * jml adds a personal todo
<jelmer> poolie: what are your plans for backports exactly?
<lifeless> igc: hi
<jelmer> poolie: addition to PPA or replacement?
<lifeless> igc: so unlock was being called and no exception had occured?
<lifeless> igc: what specifici test is doing this?
<poolie> jelmer: in addition to the PPA
<poolie> maybe not updated immediately when we release, and maybe not done for every release
<lifeless> igc: (I will run it and give it a shot)
<poolie> > jml: mtaylor: but many people are in the same boat as you. perhaps the things that are in bzrtools that everyone uses should be pushed into bzr proper
<poolie> i agree with jml
<poolie> if "everyone has it" as seems to be the case why keep it separate
<lifeless> so network delta reuse
<lifeless> I think a sensible approach is:
<lifeless> each record in a stream has a network representation
<lifeless> we assume that a stream recipient can use any part of a stream they have seen before, for text extraction
<lifeless> we assume a stream recipient *will* extract every text, to validate them
<lifeless> a delta which needs data not introduced as a diff by that delta just includs that in its network representation
<lifeless> and the stream knows what to include/not include
<lifeless> finally, we have graph data seperate, but offer a single api call to get the right bytes for serialisation
<lifeless> this lets compressors like knits and gc which don't embed graph data not have to grow graph data foo
<lifeless> but lets compressors like weaves which do embed graph data just use the embedded data
<lifeless> a minor tweak would be to say that record.get_bytes_as(record.storage_kind) if record.storage_kind not in ('chunked', 'fulltext') will return something with inline bytes for graph and raw data
<spiv> I'm not clear on what you mean by "a delta which needs data not introduced as a diff by that delta just includs that in its network representation"
<lifeless> spiv: a knit-delta-gz
<lifeless> spiv: with include_delta_closure == True
<lifeless> would just include its parents transitively up to a full text in the blob you get when you ask for the bytes
<spiv> Ok.
<lifeless> so a naive implementation which never recompresses might include the same external parent several times
<spiv> So the network representation for record can vary depending on the stream's include_delta_closure flag, and what has gone on the stream prior to that record.
<lifeless> (when we have include_delta_closure ==True)
<lifeless> spiv: yes
<spiv> Ok.
<lifeless> spiv: should I start a branch that aims to test this and get it working with knits and weaves?
<spiv> Yes please :)
<lifeless> ok
<spiv> Hmm, I need caffeine, but I'm out of beans.
<lifeless> I have one remaining 'this may be bad' bit - which is that we may need (given this structure) to stash the stream of inventories during a rich root upgrade
<lifeless> because of the 'can use anything seen before' constraint
<lifeless> but I think writing a temporary versioned files to disk isn't really so bad
<spiv> Ugh.
<lifeless> alternatively, we window it
<lifeless> we say 'anything in the last 256 items', and the generator knows that it has to track what parents are available in that window
<spiv> Let's just kill non-rich-root already ;)
 * spiv nods
<lifeless> spiv: well it still applies with xml -> bbc
<spiv> I know :)
<lifeless> spiv: or even bbc-flavour-A to bbc-flavour-B
<spiv> And I'm sure we'll be varying the inventory format again one day, we're good at doing that ;)
<lifeless> because we may need random access to data from the source which is at the far end of the wire
<lifeless> so we need a contract where the sender can say 'you need these texts to read my shit', here they are
<lifeless> and the recipient can then access them all
<igc> lifeless: I'm about to grab some food so here's a brain dump ..
<igc> to trigger it ...
<igc> bzr-gcchk init --gc-plain-chk xx
<igc> cd xx
<lifeless> igc: there isn't a test case that dies?
<igc> bzr-gcchk pull ../some-pack-branch
<igc> bzr-gcchk is brisbane-core with the latest groupcompress plugin
<igc> usertest is dying
<igc> it gets pass 900 revisions being pulled so my theory is ...
<igc> it's something in groupcompress/repofmt.py, around auto-packing say
<lifeless> bzr.dev is the test branch ?
<igc> I added -Dpack and looked at bzr.log ...
<lifeless> igc: oh, packing is broken
<lifeless> igc: I was discussing this with jam
<igc> btw, groupcompress/repofmt.py needs to import trace and use trace.mutter for -Dpack to work :-)
<lifeless> probably need to disable autopack at the moment
<igc> bzr.log had a message about autopacking to 1000 revs but it wasn't the very last message fwiw
<igc> lifeless: so what's the easiest way to disable autopack?
<lifeless> bzrlib.repofmt.pack_repo - in there somewhere ;)
<igc> lifeless: np. I disable it in fastimport so I'll do the same thing I do there :-)
<jelmer> poolie: thanks
<doozer__112> hi - apologies for what's probably a basic question... ;)  But - I'm testing bazaar on XP and the tortoise? integration into the explorer shell works fine - but the only major task it doesn't seem to do is rolling back between versions of a file.  I can do it from the command line if necessary, but was wondering if I'm just missing something?!
 * igc grabs some lunch
<igc> lifeless: a quick update ...
<igc> I tried the same thing with bzr.dev+groupcompress using gc-plain
<lifeless> igc: it should break the same way, if you do multiple write groups to it; fetch from a compatible repo won't do that though
<igc> it falls over as well, but in a different place - insert_record_stream inside the group_compress plugin
<lifeless> doozer__112: I'm not sure, perhaps you could file a bug? (If its not obvious, thats a bug, if its not there, thats a bug too :P)
<lifeless> poolie: re: performance figures, the insertion time includes disk read IO
<lifeless> poolie: so its not a reliable figure yet. My observation is that its not wildly off, as each pass thrashes on the same content :P
<lifeless> igc: a backtrace, and the exception would be good
<doozer__112> lifeless: heh, thanks, just playing with some of the other GTK based GUI's too..
<lifeless> spiv: please paste your knit modem code :)
<victory747> I'm having troubles with bzr-svn - I am pulling into an existing repostiory, and since upgrading to jaunty (bzr 1.11, bzr-svn 0.5.0), all my revision-ids used to have blahblah:Dir%2Ftrunk: and now they have blahblah:Dir/trunk:
<victory747> So it sees the branches as having diverged
<lifeless> victory747: bzr-svn 0.5 is a fairly big upgrade, I suggest reading the release notes
<spiv> lifeless: you mean http://people.ubuntu.com/~andrew/bzr/streaming-push ?
<igc> lifeless: the backtrace from pulling into a gc-plain branch has just been emailed to you
<lifeless> spiv: just the bencode bits :)
<spiv> lifeless: http://rafb.net/p/rIAqn353.html
<victory747> lifeless: Thanks - I think I understand now
<lifeless> igc: ugh, uhm
<lifeless> === modified file 'repofmt.py'
<lifeless> --- repofmt.py  2009-02-10 22:08:17 +0000
<lifeless> +++ repofmt.py  2009-02-10 22:47:37 +0000
<lifeless> @@ -300,6 +300,8 @@
<lifeless>          self._reconcile_does_inventory_gc = True
<lifeless>          self._reconcile_fixes_text_parents = True
<lifeless>          self._reconcile_backsup_inventory = False
<lifeless> +        # Tell fetch what we require.
<lifeless> +        self._fetch_order = 'topological'
<lifeless>  
<lifeless> igc: ^ try that
<lifeless> igc: it shouldn't be needed, but if you have a broken source repo it may help
<lifeless> spiv: thanks
<kenichi> what's bzr for "up -r NN" where NN is a few revisions ago?
<lifeless> kenichi: currently the closest is 'bzr revert -r NN'
<kenichi> lifeless: that doesn't seem to work the way i'm thinking...  i want revert the whole working copy to rNN.
<lifeless> kenichi: thats what it does
<lifeless> kenichi: after doing that, 'bzr diff' shows the change from NN to -1
<kenichi> ugh.. sorry, i should stop working now... yes, thanks it works.
<poolie> igc, the display of merges in the commit template is a good idea but not a post-rc thing i think
<igc> poolie: ok
<igc> poolie: did you see markh's email re tortoise docs?
<igc> he'll like them in 1.12
<igc> apparently, it was ready for 1.11 but hasn't been landed by anyone
<poolie> i landed something related to that...
<tro> is ther an external api reference? http://starship.python.net/crew/mwh/bzrlibapi-oe/ seems down
<lifeless> tro: you can run pydoctor locally
<lifeless> mwhudson: ^
<poolie> ah i see it
<poolie> tro, lifeless, i'll see if we can run it on escudero
<tro> :)
<mrooney> Will upgrading my bzr in Intrepid fix this: "Selected-file commit of merges is not supported yet"?
<mrooney> or, is there a way to merge just one file
<fullermd> No, and not if you want merge tracking of it.
<mrooney> Crap. Okay, thanks
<lifeless> mrooney: you can merge just one file, but it becomes a cherrypick: 'bzr merge branch/FILENAME'
<fullermd> You can fling around single file changes or the like, but history-wise it's indistinguishable from doing the same thing manually.
<mrooney> lifeless: will merging again in the future (a full merge) work fine then?
<lifeless> mrooney: probably
<mrooney> okay that is what I need then, thanks I'll give it a try!
<mwhudson> tro: http://starship.python.net/crew/mwh/bzrlibapi/ ?
<poolie> tro: where is the -oe version linked?
<poolie> our main doc server is apparently too old to have a packaged version of pydoctor
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> spiv: how do you bdecode 'the first item from this long bytestream'
<spiv> You don't.
<lifeless> ah-ha!
<lifeless> no wonder it was seeming difficult
<spiv> At least, not with any bencode.py that anyone has written.
<poolie> you could write one fairly easily
<spiv> You could in principle do it.
<spiv> But honestly, I've written enough network stuff like that in recent times :)
<poolie> mwh: should i remove the link to the editable copy?
<mwhudson> poolie: yes, i think so
<lifeless> spiv: so heres my structure
<lifeless> I have a NetworkRecordStream calss
<lifeless> which takes a bytes_iterator
<lifeless> and has a read() method that returns a generator which reconstitutes the input stream
<lifeless> I want to dispatch to some code that isn't written yet
<lifeless> so I want the generating code to output enough data that I can dispatch on it
<lifeless> spiv: is _length_prefix in bzr.dev?
<spiv> lifeless: no, but it's trivial:
<spiv> def _length_prefix(bytes): return struct.pack('!L', len(bytes))
<lifeless> spiv: its ok for now I'm just handwaving, we can tune Monday
<lifeless> poolie: spiv: I'm calling it, have a good weekend
<lifeless> spiv: I have good progress at pushing that down to the VF interface
<lifeless> spiv: we'll still have to do the ugly vis-a-vis delta closures and so on
<poolie> night ll
<spiv> lifeless: cool
<spiv> lifeless: the write group stuff is looking good too
* poolie changed the topic of #bzr to: Bazaar version control system | 1.12 released 13 Feb | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<spiv> poolie: woo
<poolie> spiv, can we have a really quick call?
<AfC> poolie: I thought you were aiming for the 1234567890 timestamp :)
<poolie> not precisely
<AfC> Anyway,
<AfC> Congratulations to the Bazaar hackers on your continued persistence.
<spiv> AfC: even in the face of lengthy mailing list threads? :)
<fullermd> If it goes on long enough, somebody will say something that hasn't been said the last 50 times the topic was discussed.
<fullermd> Surely.  Statistics alone...
<fullermd> Hm.  The tarball for the 1.12 release is called bzr-1.12rc1.tar.gz ?
<vila> hi all
<vila> mtaylor: Are you having a problem with bzr/bzrtools getting out of sync ? Where are you getting them from ?
<mtaylor> vila: from the ~bzr ppa
<vila> Both will be upgraded today to 1.12 if poolie finish the 1.12 release (which he should ;-)
<mtaylor> vila: deb http://ppa.launchpad.net/bzr/ppa/ubuntu intrepid main
<mtaylor> cool
<vila> In the mean time the bzr-beta-ppa contains both 1.12rc1
<vila> mtaylor: which TZ are you in ?
<mtaylor> vila: Pacific US
<vila> mtaylor: then you should have then when you wake up tomorrow :)
<mtaylor> vila: yay! (although you are assuming I will go to sleep at a reasonable time...)
<mtaylor> vila: so I _might_ have it before I go to bed!
<vila> mtaylor: now *you're* assuming I can produce them before you go to sleep :)
<fullermd> Sleep?  Didn't we do that LAST week?
<igc> hi vila. Thanks for the review. I'll take a look next week.
<vila> igc: sure, enjoy your week-end, and remember that I like the overall direction, I just disagree on details :)
<igc> vila. cool. today was lost fixing fast-import bugs and trying to get the groupcompress stuff working under usertest
<vila> igc: and don't forget that failing test in usertest :-)
<igc> vila: which one is that? can you email me the details please?
<vila> I think I did in the past, but I'll mail a fresh one anyway :)
<vila> log from bzrlib.plugins.usertest.tests.test_blackbox.BlackboxTests.test_usertest_strict
<vila> with a ~440 line output totally opaque to me :-/
<vila> igc: still there in revno 137
<hno> Hmm.. 1.12 released but tarball not on launchpad?
<hno> seems 1.12rc1 got uploaded again instead..
<Youssef> Hi al!!!!
<igc> night all - have a good weekend
<LarstiQ> lifeless: it seems so
<radix> is someone going to add bzrtools to the bzr PPA
<radix> so that my update-manager stops telling me I need to do a partial upgrade
<radix> (and so that I can upgrade bzr without removing bzrtools)
<vila> radix: as soon as poolie fix the source upload, I'd build the ppas for both bzr and bzrtools
<radix> vila: cool, thanks
<vila> I jsut can't upload it myself being currently blocked by a failing test (apparently due to some weirdness in my install as ./bzr selftest bzrlib.tests.tree_implementations.test_path_content_summary.TestPathContentSummary.test_unicode_symlink_content_summary fails for both bzr.dev and bzr-1.12 >-/
 * fullermd gets a failure there too.
<fullermd> FAILED (errors=1, known_failure_count=2)
<vila> let's kill a chicken, how can pqm left that pass ?
<fullermd> I don't even know what it means  :p
<vila> fullermd: what python version are you using ? What os version ? 32/64 bits ?
<vila> it suceeds on hardy inside a 32 bits VM but failed on intrepid in 64 bits native
<fullermd> 2.5.2 FreeBSD/i386
<vila> 32 bits ?
<fullermd> Yah.
 * fullermd can't imagine word size has much to do with it though...
<vila> Of course... just when I thought word size couldn't have anything to do with it you confirm that 32bit works :-(
<fullermd> Hm?  It _fails_ for me.
<vila> Oh ! Thanks
<vila> do you have a python-2.4 handy ?
<fullermd> It would take a lot of sit-around-and-compile.
<vila> fullermd: nevermind, thanks anyway
<vila> Urgh, python-2.5.2 disagree with itself about encondig strings between my two tests 8-(
<fullermd> FWIW, 1.12rc1 out of the tarball "passes" (via SKIP'ing that test) on 2.5.2 FreeBSD/amd64
<vila> 2.5.2 on hardy/32bits says: '\u03b2-path', where 2.5.2 on intrepid/64bits says: '\xce\xb2-path'
<fullermd> Oh, wait, I've got LANG=C on that box...
<fullermd> Yah, it fails there too with the UTF-8 locale.
<UbuntuBoy> lol
<Lo-lan-do> jelmer: I don't know if you committed the fix you mentioned earlier, but a bzr update I did just now took one minute and a half instead of the previous five minutes.  Thanks :-)
<vila> jelmer: ping
<UbuntuBoy> brb
<nielsbom> (I'm a n00b), what's the correct way to stop having a simple local bzr repository?
<nielsbom> I just deleted the .bzr dir, that worked, but seemed wrong
<Kinnison> Depends what you mean
<nielsbom> Can you elaborate?
<Kinnison> Well, if all you wanted was to abandon your revision control then removing .bzr works
<nielsbom> Kinnison: Yeah, that answers my question :)
<Kinnison> If you wanted something with more complex semantics then it wasn't necessarily the right thing to have done
<nielsbom> Kinnison: is there a bzr command for that?
<nielsbom> Kinnison: or is just ok to rm .bzr?
<Kinnison> personally I'd use bzr export to create a non-controlled copy
<Kinnison> and then tar up and backup the version with the .bzr
<Kinnison> but that's because I don't abandon revision control, if I can help it
<fullermd> Me, I'd...   well, not do it in the first place   ;p
<nielsbom> Kinnison: ok clear, thanks
<Kinnison> sometimes I have to translate from one RCS to another, where importing the history isn't an option
<glade88> what would be the equivalent of "svn update" in bzr? "bzr update" doesnt seem to do the same
<glade88> ..neither "bzr upgrade"
<fullermd> bzr update does the same thing svn update does.  That may not be quite what you want in a given case, though.
<Kinnison> glade88: In a checkout, bzr update ought to work
<fullermd> Perhaps you want 'bzr pull'.
<Kinnison> glade88: in a branch, you may want bzr pull
<Kinnison> snappish
<glade88> it is a Launchpad branch.
<glade88> bzr pull LP:ideatorrent ?
<Kinnison> simply 'bzr pull' will pull from the last location IIRC
<glade88> damn this "ssh passphrase". can I make it not to ask each time? "ssh add URL" doesnt seem to work for some reason..
<glade88> URL=bzr+ssh://sayakb@bazaar.launchpad.net/~ideatorrent-developers/ideatorrent/devel/
<glade88> ^in my case
 * fullermd didn't know there WAS a 'ssh add'...
<glade88> fullermd: any other way to save the passphrase?
<Kinnison> do you mean your ssh password, or your ssh key passphrase?
<fullermd> bzr doesn't have anything to do with that, TTBOMK.  That's all in your ssh client.
<fullermd> Well, it has to be passphrase where LP is concerned.
<fullermd> There's a ssh-agent or something like that.
<glade88> its my ssh passohrase
<glade88> and yes, bzr has nothing to do with that :)
<Kinnison> ssh-add ~/.ssh/id_rsa
<Kinnison> that kind of thing
<glade88> since it is the same for svn
<glade88> Kinnison: fullermd: thanks, bzr pull works. I'll pondermore on the passphrase thing.
<glade88> cheerio
 * Kinnison 's suggested ssh-add commandline is what glade88 wants
<fullermd> Well, only once you have the agent running.
<nielsbom> Just found this in the user guide (d'oh!): If you accidently put the wrong tree under version control, simply delete the .bzr directory.
<fullermd> And you need that ancestrally to all your terminal creations (or manual hackery in each)
<Kinnison> fullermd: typically, linux systems start ssh agents as part of the X session
<Kinnison> fullermd: As for other systems, dunno :-(
 * fullermd always has a hand-crafted .xinitrc, so nothing gets started he doesn't order  :p
<glade88> Kinnison: w00t! yes, darn me I was using "ssh add" not "ssh-add". worksformenow (tm) . ty
<Kinnison> fullermd: How retro :-)
<fullermd> Oh, that's not retro.  What's retro is how the last line starts the window manager, ctwm  :p
<Kinnison> Oh dear
 * Kinnison pats fullermd gently on his clearly damaged head :-)
<fullermd> But it's ctwm with a few of my own local hacks applied, of course.
<fullermd> Sorta like the web browsing is firefox with my local hacks, and the mail reading is mutt with my local hacks, and...
 * fullermd . o O ( If the world would just cater to me more, things would be so much easier... )
<fullermd> Oh dear.  Somebody actually _likes_ $Log$?
<vila> fullermd: some even likes log --forward :-)
<fullermd> log --forward is almost as cool as missing --reverse!
<vila> Don't start *me* on --reverse :-)
 * fullermd reverses vila on --start.
<vila> --start is good :-)
<fullermd> Hey, we should add stat --backward, to show the merge revs in the opposite order, too.
<fullermd> Then we'll cover the gamut better!
<Kinnison> urf
<UbuntuBoy> Hi guys!
<UbuntuBoy> I would like to know how I can launch bazaar as windows service when i execute "BZR SERVE" please
<nielsbom> (noob question) is it possible to co-develop a website using 2 computers which can't be connected through SSH (or something like it) using bzr? (Something like sending a whole repositorie as a file and merging it locally, and vice versa?)
<Lo-lan-do> nielsbom: Yes, with merge requests sent by email.
<santagada> actually  you can save a bundle to a file and transport it anyway you fell like it
<santagada> for example a pen drive
<Lo-lan-do> Yeah, or a floppy disk or a punched card.  I sort of assumed the two computers still had access to *some* net :-)
<UbuntuBoy> Lo-lan-do!?
<UbuntuBoy> I would like to know how I can launch bazaar as windows service when i execute "BZR SERVE" how can I do that please?
<santagada> Lo-lan-do: you are not paranoid enough :)
<Lo-lan-do> UbuntuBoy: I don't even know what a windows service is...
<UbuntuBoy> lol
<UbuntuBoy> a deamon i u want
<UbuntuBoy> if
<UbuntuBoy> sry
<UbuntuBoy> a deamon if u want
<santagada> UbuntuBoy: you know a service is not really a daemon right?
<UbuntuBoy> :p
<UbuntuBoy> yep
<santagada> UbuntuBoy: so I'm guessing that if there is no service plugin and windows services are not mentioned on bazaar manual it is not supported
<UbuntuBoy> mmmhhhhh...
<santagada> UbuntuBoy: but maybe there is a way to use unix tools or something from microsoft to use a daemon as a service
<santagada> UbuntuBoy: why not use IIS and fastcgi?
<UbuntuBoy> because I prefer use directly bzr://
<UbuntuBoy> its more easy
<UbuntuBoy> it's sry
<santagada> UbuntuBoy: I don't really agree... but ok
<UbuntuBoy> :)
<santagada> UbuntuBoy: use the unix daemon tools or unix tools that came with your windows server to do it
<UbuntuBoy> unix daemon tools ?
<santagada> UbuntuBoy: with IIS you can easily integrate with AD also
<UbuntuBoy> I dunno
<UbuntuBoy> how
<santagada> UbuntuBoy: I think it is unix tools
<santagada> daemon tools is that thing to run .iso images
<santagada> UbuntuBoy: as an Ubuntu boy you probably know how to link LDAP and apache... with IIS is probably even easier to connect to AD for authentication
<santagada> authorization will be left as an exercise :D
<UbuntuBoy> hmmm
<UbuntuBoy> hmm...
<UbuntuBoy> i'm not really an ubuntyboy I took this nick becoz i didn't find anything else looooooooool
<UbuntuBoy> or my name
<Youssef> like this
<Youssef> hihi
 * Youssef put back his deguisment
<santagada> Youssef was cooler
<UbuntuBoy> Really?
<UbuntuBoy> okay
<Youssef> hihi
<Youssef> ^^
<Youssef> hmmm
<santagada> Youssef: windows services for unix is deprecated I think, and don't do what you want
<Youssef> about what?
<Odd_Bloke> Youssef: I would suggest a post to the ML.
<Youssef> ML?
<Youssef> what is it?
<Youssef> sorry guys im a windows user I try my best to learn the linux world
<Youssef> it's a bit hard for me the please use full words
<Youssef> not only those characters lol
<Youssef> santagada! You said -> and don't do what you want <- what does it means?
<Odd_Bloke> Youssef: Mailing List.
<Youssef> loooooooooooooooool
<Youssef> okay okay
<Youssef> and why would you suggest me to post to the mailing list?
<santagada> Youssef: I don't see a way to run a daemon as a service
<Youssef> hhoo okay okay
<santagada> Youssef: because them more people can see your question
<santagada> Youssef: and can give you a more complete answer
<Youssef> ooohhh
<santagada> Youssef: or just because your question might become a feature request for a future version of bazaar :D
<Youssef> okay
<Youssef> mmhhhh...
<santagada> Good luc
<Youssef> interesting hehe
<santagada> luck
<Youssef> thankyou very much
<Youssef> guys
<Youssef> thanks a lot hehe
<Youssef> but one last question
<Youssef> where is the mailing list?
<Odd_Bloke> Youssef: https://lists.ubuntu.com/mailman/listinfo/bazaar
<nielsbom> Lo-lan-do: thanks!
<xtian_> Can anyone tell me how to prevent bzr on windows from using plink for sftp (and get it to fall back to paramiko)?
<xtian_> I can force it to fallback by renaming plink, but I need plink on my path to edit remote files in emacs.
<xtian_> whoa, tumbleweeds, huh?
<Lo-lan-do> And crickets.
<Odd_Bloke> I don't know.
<Odd_Bloke> And I can't think who here uses bzr on Windows.
<xtian_> Fair enough! I might try the mailing list.
<Odd_Bloke> Probably wise
<xtian_> Cheers!
<Tak> eh, I use bzr on windows, but not with sftp
<xtian_> do you just use it with launchpad?
<Tak> no, I use it with bzr-svn and smb
<verterok> xtian_: try with set BZR_SSH=paramiko
<xtian_> aha! Thanks!
<xtian_> Trying now.
<xtian_> Is there any reference where I could find that kind of thing in future?
<xtian_> That worked! Thanks heaps.
<verterok> xtian_: I found it the mail list archive, but I'm sure it's in the official docs
<verterok> xtian_: if you can't find it in the official docs, please file a bug about it
<xtian_> Wilco
<xtian_> Just looking now
<xtian_> Gah - there it is - I was looking for the wrong keywords. I could find mention of restoring auto-detection of plink in some bug threads, but not that.
<xtian_> Thanks again!.
<verterok> xtian_: np, glad to hlep
<hno> Youssef: There is a tool in the windows resource kit for creating services of arbitrarily programs not having builting service capabilities.
<Kinnison> What's the status of tracking cherrypicks in bzr?
<vila> verterok: that was short :-)
<verterok_> vila: me netwokr is flaky, hopefully be back at home during the weekend :)
<verterok_> /me/my
<vila> s!/me/my!s/me/my/! :-)
<verterok> :)
<Odd_Bloke> s,s!/me/my!s/me/my/! :-),s!/me/my!s/me/my/!,
<Odd_Bloke> :)
 * fullermd hopes you don't try that in csh...
<yenzenz> hi
<Odd_Bloke> yenzenz: Hi. :)
<yenzenz> is this a known issue: download link to tgz of 1.12 release is broken at http://bazaar-vcs.org/Download
<Odd_Bloke> yenzenz: I wasn't aware of it.
<fullermd> Yes, it's known.
<yenzenz> fullermd: ok, thnaks. so just a matter of time :)
<nielsbom> {noob} I start a local repository on my pc (bzr init, bzr add, bzr commit), then I want to send the whole branch including all files to a colleague so he can start development on his own pc and then send patches my way. How do I export my whole dir, incl repository to him? Should I do that with bzr? Or just copy it?
<Lo-lan-do> You can copy the .bzr dir
<nielsbom> Lo-lan-do: yes, I understand that, and also copy all the files in the dir in which my files reside.
<Lo-lan-do> You don't *need* to copy those, since they can be regenerated from the .bzr dir.
<nielsbom> Even if he hasn't had the repo before?
<Lo-lan-do> The .bzr dir contains the full history.  So he can just bzr reconfigure --tree and get the working files from that.
<Lo-lan-do> (Or just bzr checkout)
<fullermd> Well, if you send the .bzr from a dir with a checkout, you'd use revert...
<jelmer> vila: hi
<vila> jelmer: hi
<vila> jelmer: did you see my mail about 1.12
<vila> jelmer: did you see my mail about 1.12  ?
<jelmer> vila: Yeah
<jelmer> vila: Strange it's failing for you :-/ Does it fail both with dirstate C extensions and without?
<vila> It fails *with* C extensions
<jelmer> does it work without?
<vila> let me check
<fullermd> It works for me without, and fails with.
<vila> works without
<vila> ...
<vila> gha...
<nielsbom> Lo-lan-do: ok, I'm starting to understand, I think (we're testing it now)
<Lo-lan-do> nielsbom: Maybe you could use the bzr-fast-export.py script from plugins/fastimport if you don't feel comfortable copying a .bzr dir.
<vila> jelmer: does it make sense to you ?
<jelmer> vila: Not entirely yet, but at least more
<nielsbom> Lo-lan-do: I'm ok with that for starters
<vila> jelmer: with my patch, that's the opposite, fail without extensions, works with
<nielsbom> Lo-lan-do: So I have a local repository, I committed to it, then I copy the .bzr directory to another directory, say example/. I then go to that dir and give the command bzr reconfigure --tree. I get the error "example is already a tree"
<nielsbom> Lo-lan-do: "example/ is already a tree
<jelmer> vila; Looks like there's an inconsistency in dirstate C extensions / Python
<Lo-lan-do> nielsbom: Try "bzr revert" instead.  Apparently the .bzr contains info on what's supposed to be outside itself :-)
<vila> jelmer: yup, we need more tests parametrized on C extension availability or not
<jelmer> vila, i.e. one already provides unicode, the other provides ascii
<nielsbom> Lo-lan-do: cool, that worked thanks!
<vila> What are the consequences if we revert your patch ? Is bzr-svn impacted ?
<jelmer> vila: No, bzr-svn is not impacted, but some repositories will be impacted (as it'll break symlinks with unicode names)
<jelmer> vila, Do you really need to revert it though? Only newly added tests seem to fail
<vila> jelmer: well, I came across it just before a release... I don't think it should block it, but that's for the RM to decide...
<vila> jelmer: plus, it fails only under unclear circumstances...
<vila> jam: ping
<jelmer> vila: I mean, the alternative would be to just remove the tests added by my patch
<jam> hi vila
<vila> untested code is broken code :-)
<jelmer> vila, well, that seems to be what's breaking for you
<vila> jelmer: Only because I came across it via the test but I presume I can reproduce it from command line, so our users can too
<jelmer> vila: this was already broken from the command-line
<jelmer> my patch was meant to address it
<vila> jelmer: I understand that, don't get me wrong.
<vila> But it the fix seems incomplete then, even if you can't trigger it yourself (or so it seems) because, well, your setup is different
<vila> I can't reproduce it either under hardy/32bits inside a VM,
<vila> I reproduce it only under intrepid/64bits on a real host
<vila> Same python version: 2.5.2
<vila> I fail to understand why the word size has an impact though....
<jelmer> I'll see if I can reproduce on my 64bit machine
<jelmer> it seems strange indeed that the word size would affect the type of a field in dirstate..
<fullermd> It happens for me on i386 and amd64 both.
<jam> fullermd: are you on BSD?
 * jam seems to remember that BSD has different ideas about fs_enc
<fullermd> What's the thing that makes bzr spit its fs_enc out?
<jam> fullermd: um... python -c 'import bzrlib.osutils; print bzrlib.osutils._fs_enc" ?
<jelmer> the problem seems to be that the dirstate C extensions call _read_link() with a str argument
<jelmer> and the native Python code calls it with a unicode argument
<fullermd> UTF-8
<jam> so the dirstate code should be using a UTF-8 string (always), which is probably incorrect on some situations
<fullermd> I note that (if it matters) it's the (PreviewTreePost) variant that fails.  (DirStateRevisionTree) and the other options work.
<fullermd> Well.  I assume pass == work.
<jelmer> jam: the dirstate code should always use unicode internally?
<jelmer> s/unicode/utf8
<jam> jelmer: generally, yes
<jam> The paths stored *in* the dirstate file should all be utf-8
<jam> And 90% of all processing is done via utf-8 strings
<jam> only when finally yielding them to upper layers do we decode it back to Unicode
<jelmer> and when reading from the OS encoding as _fs_enc?
<jam> jelmer: right
<LarstiQ> evening
<jam> hi LarstiQ
<jam> beuno: ping
<LarstiQ> hey jam
<jelmer> Hey LarstiQ
<jelmer> hi emmajane
<LarstiQ> hi jelmer, emmajane :)
<emmajane> jelmer, hello :)
<emmajane> LarstiQ, hello as well
<jelmer> emmajane, thanks for the report wrt the docs on samba.org, btw
<emmajane> jelmer, no problem.
<emmajane> jelmer, I wasn't sure if it was meant to work with local files, but not online. Or something.
<jelmer> emmajane, it's supposed to work, but seems to break from time to time as it's updated automatically
<emmajane> heh. Yeah. There's 'supposed to' and then there's 'output from scripts' :)
<jam> Does anyone else know if 'loggerhead' is fully plugin-ized now?
<LarstiQ> jam: yes, fsvo fullu
<jam> well, is "bundling it with the win32 installer" going to work
<LarstiQ> jam: I don't think it does the fancy decorating of 'bzr serve' yet
<jam> I guess is the question
<jelmer> emmajane, :-)
<LarstiQ> jam: ooh, goed question.
<jam> I think it will take a few steps
<jam> as it would also require extra dependencies
<jam> like we have to do with bzr-svn, etc.
<jam> I think I need to put together a spec
<jam> for handling setup issues with bundling plugins
 * LarstiQ cries as selftest slows his netbook to a crawl
<jam> as I'm tired of having to edit bzr's setup.py for each plugin
<jelmer> vila, jam: So the problem seems to be that py_update_entry() calls _read_link() with a unicode string
<jelmer> vila, jam: Whereas the C extensions call it with a utf8 string
<jam> hmm... something odd here
<jam> as the C extension just passes through the "abspath" it was given
<jam> which is also what "py_update_entry" does
<jam> So I'm guessing it isn't the 'update_entry' code
<jam> but the _process_entry code
<jam> which is getting something wrong
<emmajane> And now for something completely different: an on-topic comment! :)
<emmajane> Next weekend I'm giving a bzr talk at SCaLE. I'm giving essentially the same talk as I gave before.
<beuno> jam, pong
<emmajane> The slides are at: http://www.slideshare.net/emmajane/version-control-for-mere-and-freelance-mortals-presentation if anyone has comments for add/modify/deletes.
<jam> beuno: on bug #328860, Martin mentions wanting to bundle loggerhead with the win32 installer
<ubottu> Launchpad bug 328860 in bzr "Win32 Loggerhead installer wanted" [Medium,Confirmed] https://launchpad.net/bugs/328860
<jam> I was just curious if loggerhead has been fully turned into a "plugin"
<emmajane> The talk description is at: http://scale7x.socallinuxexpo.org/conference-info/speakers/emma-jane-hogbin (It's just an intro talk)
<jam> so that it would be bundled in the same fashion that bzr-svn, etc. would be
<beuno> jam, poolie actually did turn it into a plugin during our sprint
<beuno> let me find the merge proposal..
<beuno> https://code.edge.launchpad.net/~loggerhead-team/loggerhead/loggerhead-plugin/+merge/3095
<beuno> jam, ^
<beuno> I'll merge that in today
<jam> beuno: well, I won't change anything for 1.12
<jam> just thought I'd check where things were at
<jam> Does that also decorate "bzr serve" ? Or is it just "bzr loggerhead-commands"?
<beuno> it decorates serve
<beuno> which is what prompted jml's work on it
<jelmer> emmajane, do you have some other format than flash? gnash is not cooperating with me atm
<fullermd> Ooh look, a 1.12 tarball...
<emmajane> jelmer, is there an option to download the ODP from that page?
<emmajane> http://www.slideshare.net/emmajane/version-control-for-mere-and-freelance-mortals-presentation/download ?
<emmajane> it gives a PDF, I think.
<Lo-lan-do> beuno: Will you also merge the init script for daemon-like operation?
<jelmer> emmajane, that seems to require login :-/
<Lo-lan-do> (You did ask me to pester you :-)
 * fullermd keeps waiting for the day flash joins java applets in the dustbin...
<emmajane> jelmer, boo to slideshare.
<beuno> Lo-lan-do, I may put up a merge proposal for someone with a working brain to review  :)
<jelmer> beuno, and will you remove start-loggerhead ? (-:
<beuno> jelmer, not until I get config working with serve-branches  :/
<emmajane> jelmer, http://bazaar-vcs.org/Talks?action=AttachFile&do=get&target=bzr-intro-template.odp
<jelmer> emmajane, thanks
<emmajane> jelmer, thanks for looking! :)
<fullermd> Things you notice when updating packages:
<fullermd> bzrtools 1.12.0 is 1 'larger' than bzrtools 1.11.0.  Thus, it's fitting that the tarball is also 1 byte larger.
<jam> a single byte, that is quite intriguing
<Lo-lan-do> "Well, it's one louder, innit?"
<fullermd> But why not make each byte bigger?
 * fullermd nods at jam.
<fullermd> I thought so.
<fullermd> -SIZE (bzrtools-1.11.0.tar.gz) = 69765
<fullermd> +SIZE (bzrtools-1.12.0.tar.gz) = 69766
<jam> well, also of interest:
<jam> 3.8M Feb  9 04:42 bzr-1.11.tar.gz
<jam> 3.9M Feb 13 09:53 bzr-1.12.tar.gz
<jam> 1 (100kB) bigger
<fullermd> Well, not really.  It's 39807 bigger.
<Odd_Bloke> s/bigg/loud/
<fullermd> Of course, if you subtract that from the curent bzrtools, you get 29959.  Subtrace that from the previous bzrtools, you get 9848.
<Toksyuryel> Would Stackless provide any measurable speed improvements to bzr?
<fullermd> Sum those digits, you get 29, which starts the pattern.  The next digit is the 9 again from the start of 9848.  The 59 is one more than the trailing 48.
<fullermd> So it all works out anyway.
 * fullermd wanders off to smoke some more crack...
<Toksyuryel> seems to have done a lot for EVE Online, am wondering if bzr can achive similar performance gains
<Toksyuryel> http://en.wikipedia.org/wiki/Stackless_Python
<Odd_Bloke> Toksyuryel: Without really knowing anything more, I would note that EVE and bzr are fairly different apps. ;)
<Toksyuryel> Granted, but still :)
<jelmer> emmajane: seems good to me :-) simple, and quick
<Odd_Bloke> Essentially, I doubt it, because bzr isn't multi-threaded.
<jfroy> Morning!
<jelmer> emmajane, why does "bzr tags --sort=time" need special attention? The other commands mentioned seem much more common
<jelmer> hi jfroy !
<Toksyuryel> Is threading planned for a future development?
<Odd_Bloke> Toksyuryel: I don't know.
<emmajane> jelmer, it's just one that I use a lot myself (tagging what versions I send to the client). I talk a bit about it.
<Toksyuryel> Perhaps implimenting threading and moving to stackless coule provide performance improvements over the current model?
<Toksyuryel> *could
<fullermd> I would tend to doubt it, certainly in the near or mid term.
<jfroy> jelmer: congrats on 0.5 final
<emmajane> jelmer, thanks for taking a look. Much appreciated.
<Toksyuryel> fullermd: I see
<jelmer> Toksyuryel, what would the benefit of threading be exactly?
<Toksyuryel> potential speed increases? I'm just wondering and asking. someone's gotta actually answer the question with "yes that would make it faster" or "no it would not make it faster" :D
<jam> Toksyuryel: currently I think our big bottlenecks are stuff like graph walking
<jam> it is pretty hard to come up with efficient walking code
<jam> and even harder to do something that is also parrallel
<jam> One possible place would be text insertion, I guess
<Toksyuryel> like I said... I am just asking. I am not saying "this would definitely be faster and you should do it right now".
<jam> if you are trying to insert 100 different texts, you could probably farm a couple of those out to different threads
<Toksyuryel> please stop trying to spin my words to your own ends :)
<Toksyuryel> I understand that it's not a high priority compared to other things which need to be done
<santagada> jam: sorry to botther you but isn't this kind of stuff io bound?
<jam> santagada: some is, some is 'diff' bound
<fullermd> I expect the place we're most likely to pick up parallelism would be from python-level stuff, really.
<jam> stuff like 'annotate' could benefit
<fullermd> e.g., list comprehensions are inherently parallelizable.
<jelmer> Toksyuryel: You're talking about specifics, parallelism can be achieved through more than just threading
<jfroy> I was just asked by a friend if bzr had an equivalent to git add -p. He tells me it lets you commit a subset of all the changes in the branch, even from the same file. I've never done that in bzr, so I'm not sure.
<fullermd> You can specify files, you can use shelve to set aside bits before you commit, or...   I think somebody wrote a plugin to do a darcs-style record?
<fullermd> (I don't know if/how well it works)
<Odd_Bloke> jfroy: Yeah, shelve is probably what he's looking for.
<Odd_Bloke> You use it put some of your changes on the 'shelf', commit, then use unshelve to pull them back off.
<Odd_Bloke> It has the advantage of allowing you to confirm that you haven't broken anything with the subset of changes you're committing before you commit them.
<jam> jfroy: it is sort of the "inverse" of add -p, in that you are taking off things you don't want to commit, rather than explicitly listing the things *to* commit
<jam> however, it leaves the tree in a state that you can run "make test" on
<jam> which is generally beneficial
<lbieber> Can someone tell me how to modify the 1200 second timeout limit in bzr? I'm experiencing a problem on several of our machines where they occasionally time out, not sure if it is because they are behind a firewall or not
<jfroy> Thank you all.
<LarstiQ> lbieber: do you have a .bzr.log of when that happens?
<lbieber> LarstiQ:  one minute let me see if I can dig it up
<jam> lbieber: you can set bzrlib.lockdir._DEFAULT_TIMEOUT_SECONDS
<jam> though if you are hitting that
<jam> (default is 5 min)
<jam> I'm guessing it is something else.
<lbieber> LarstiQ: ummmm, where would I find .bzr.log, I'm not seeing it anywhere?
<jam> ~/.bzr.log
<jam> Or if on windows $My Documents/.bzr.log
<jam> bzr --version spells it out for you
<lbieber> ahhhh -  let me fix this first and see if it helps, from the log file - 0.120  WARNING: using slower ElementTree; consider installing cElementTree and make sure it's on your PYTHONPATH
<Myrtti> I was wondering if http://paste.ubuntu.com/117733/ this is an error of bzr, launchpad or me?
<Odd_Bloke> Myrtti: That looks like a bzr problem.  Is there any chance you could try with a newer version of bzr?
<jam> Myrtti: that is a known bug with bzr 1.6.1 when using -Dhpss
<jam> what bug happened that caused you to try and use -Dhpss
<jam> as that is the real issue
<jam> (that said, if you upgrade your bzr, it probably all goes away anyway)
<Myrtti> what I did was I removed some of the launchpad projects and tried to rebranch them
<Myrtti> bzr pull worked while the launchpad project working copies were there
<Myrtti> but now http://paste.ubuntu.com/117739/
<jam> so that looks more like you don't have you ssh keys set up properly
<jam> it may have been working before because you didn't do "bzr launchpad-login"
<jam> (so we were using anonymous http access, rather than authenticated bzr+ssh access)
<Odd_Bloke> Myrtti: OK, so you probably did the inital lp:foo branch before running 'bzr launchpad-login'.  So the branches had the http:// location stored (because currently we store the resolved URL, not just the 'lp:foo' bit).  Then you ran launchpad-login, and it's now trying to use bzr+ssh.  But you haven't set up SSH keys with Launchpad.
<Myrtti> well that's funny, because it gave me that even before I had logged in
<Myrtti> and now that there is a proper ssh key at launchpad, it still doesn't work.
<Myrtti> or that's what I think
<Odd_Bloke> Myrtti: What does 'ssh <username>@bazaar.launchpad.net' give you?
<Myrtti> Agent admitted failure to sign using the key.
<Myrtti> Permission denied (publickey).
<jpds> Ah, the seahorse-agent bug.
<Myrtti> <sarcasm>great</sarcasm>
<jpds> bug 328127
<ubottu> Launchpad bug 328127 in gnome-keyring "gnome-keyring-daemon returns Agent admitted failure to sign using the key." [Low,Triaged] https://launchpad.net/bugs/328127
<Myrtti> that's funny
<Myrtti> I'm on intrepid.
<Myrtti> >___<
<jpds> So am I, I have the same problem :/
 * Myrtti checks
<Myrtti> gnome-keyring: Installed: 2.24.1-0ubuntu1
<jpds> Really odd.
<Myrtti> I'm on xfce4 though
<Myrtti> and I know about these things about as much as my guinea pigs know about particle physics
<Odd_Bloke> Myrtti: Try "SSH_AUTH_SOCK= ssh <username>@bazaar.launchpad.net".
<Myrtti> and presto it works
<Myrtti> Odd_Bloke: thanks
<LarstiQ> abentley: from the standup reports you're not yet in nested territory?
<abentley> LarstiQ: No.  Hopefully next week.
<Odd_Bloke> Myrtti: :)
<Odd_Bloke> Myrtti: Adding a comment on the bug with your version details might be helpful. :)
<LarstiQ> abentley: k, I'm paging through a full test suite run log now, deferring most things for later, almost got myself convinced to commit/push the current status
<abentley> LarstiQ: Great.
<Myrtti> Odd_Bloke: done :-) thanks
<pickscrape1> Is bzr-1.12 compatible with bzr-loom 1.4?
<pickscrape1> I'm getting this when running bzr status: bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument 'verbose'
<pickscrape1> The backtrace refers to /usr/lib/python2.5/site-packages/bzrlib/plugins/loom/commands.py
<Odd_Bloke> pickscrape1: Could you pastebin a more complete error?
<pickscrape1> sure
<pickscrape1> Is there one for this channel, or should I just paste anywhere?
<LarstiQ> any pastebin works
<pickscrape1> http://pastebin.ca/1336235
<vila> pickscrape1: try updating your plugin I'm pretty sure it has been fixed on trunk
<pickscrape1> I was running it direct from apt... I'll uninstall that and grab it manually
<vila> pickscrape1: yup, seeing the traceback I'm even more sure :)
<pickscrape1> Is bzr-loom available in a PPA anywhere?
<vila> I don't  think so
<vila> Do you get 1.12 from bzr-ppa ?
<vila> Did you get 1.12 from bzr-ppa ?
<pickscrape1> vila: yes
<vila> pickscrape1: did you get bzrtools too ?
<pickscrape1> I had to uninstall bzrtools because 1.11 was never uploaded to the PPA, so currently I have that installed manually
<vila> pickscrape1: could you try to install bzrtools from bzr-ppa ?
<pickscrape1> vila: yes, I will once I've fixed etckeeper, which has also just started complaining :)
<vila> pickscrape1: argh, no wait, the builds aren't finished yet :-/
<pickscrape1> OK, using loom trunk has fixed the problem: thanks :)
<pickscrape1> etckeeper needed BZR_COMMIT_OPTIONS="--unchanged"
<LarstiQ> woops, unlocking other_tree once too many
<vila> pickscrape1: bzrtools-1.12 available in bzr-ppa, can you try it ?
<pickscrape1> vila: I just did, and it seems to work fine :)
<pickscrape1> Thanks for your help
<vila> pickscrape1: great, thanks for your test :)
<vila> pickscrape1: which os/version/arch are you using ?
<pickscrape1> vila: jaunty amd64 and intrepid x86 (tested on both)
<vila> pickscrape1: you're my man, two birds with one stone :)
<pickscrape1> :)
<jfroy|work> jelmer: I was wondering if you had some experience to share with setting up bi-directional bzr-svn syncing.
<ronny> jelmer: sup?
<jfroy|work> ronny: I believe he's away ATM.
<ronny> hmm
<ronny> -9 to 1234554321 ( 1234554330 19:45:30 UTC )
<ronny> [20:45]        MinceR | A4Tech: no u
<ronny> ops
<ronny> touchpads + broken syndaemon are hellish
<Lo-lan-do> jfroy|work: I'm usung bzr-svn, maybe I can be of help?
<jfroy|work> Lo-lan-do: ok, so here's the use case. Project A is hosted in a Subversion repository over which I have little or no control. I want to introduce a Bazaar bridge, of sort, to allow some developers to use Bazaar as their main VCS. However, it is likely some other will continue using Subversion.
<jfroy|work> I'm only interested in syncing one branch, the trunk,
<jam> vila: ping
<jfroy|work> That is, the Subversion trunk with a Bazaar branch, from which Bazaar-using developers would pull and push from.
<miracle2k> when I init-repo after I already have branches checked out, can I make them part of the repository, or they I need to re-clone?
<jam> miracle2k: check 'bzr reconfigure' I think it has some flags for that
<Lo-lan-do> jfroy|work: I think it's simpler for everyone if people just use bzr as a Subversion client then.
<jam> jfroy|work: I believe doing:
<jfroy|work> miracle2k: AFAIK you need to branch into the repo to get the branch to store its history data in it
<jam> bzr co svn+ssh://path/to/trunk
<jam> Should "just work"
<jam> as in, the developers can commit there, and it will update the subversion trunk
<Lo-lan-do> That's exactly what I'm doing, and it seems to works well.
<jfroy|work> Lo-lan-do: I see. So each developer would maintain their own Subversion trunk checkout.
<miracle2k> jam, jfroy|work: There's a reconfigure --use-shared which I'm gonna try. Thanks.
<jfroy|work> miracle2k: ah, good to know, didn't know that existed :)
<jfroy|work> jam: thanks for the tip
<jam> jfroy|work: it is certainly the easiest way
<jam> there are always others
<jam> you can also
<jam> cd my-local-trunk
<jam> bzr pull ../my-branch
<jam> and if that succeeds (branches aren't diverged)
<jam> it should be the same as doing "bzr push svn://...."
<pickscrape1> Was a release email sent out for 1.12?
<jam> pickscrape1: I don't think so
<jam> Or it was sent, but Martin forgot to approve his email
<jam> Let me check
<pickscrape1> I just enjoy reading the release notes is all :)
<jam> pickscrape1: http://doc.bazaar-vcs.org/bzr.1.12/en/release-notes/NEWS.html#bzr-1-12-1234567890-2009-02-13
<jam> Or to see the on-going one: http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html
<pickscrape1> jam: thanks
<jam> lifeless: to your earlier question, "groups" do not get +junk branches:
<jam> bzr: ERROR: Permission denied: "/~bzr/+junk/bzr-groupcompress": : +junk branches are only available for individuals. Please consider registering a project for collaborating on branches: https://help.launchpad.net/Projects/Registering
<zsquareplusc> bzr 1.12 and olive? i get errors on my ubuntu box. for example the log windows are shown, but the log itself is never shown
<jam> as such, I went ahead and created: https://edge.launchpad.net/bzr-groupcompress
<jam> since I needed to do a couple patches to the plugin
<jelmer> ronny: hi
<jelmer> jfroy|work: hi
<jfroy|work> hey
<jfroy|work> As you can read in your history, my question was mostly answered, unless you have something to add to Lo-lan-do's recommendation.
<jelmer> jfroy|work: ah, sorry, hadn't seen that
<jelmer> jfroy|work: yeah, his answer seems to cover it all - just pretend the svn branch is a bzr branch and all should be well
<ronny> re
<jfroy|work> jelmer: just need to make sure the other developers who wish to use bzr understand they really need to not use a bound branch for daily work, because operations on that branch will be *slow*.
<jfroy|work> Your standard "train them a bit" situation, I suppose.
<ronny> jelmer: im at the final point of vcs unhappyness, all reasonable vcs's have at least one major pain point i dont want to be brothered with
<jelmer> jfroy|work: just tell them to use 0.5.1, which will be lightning-fast
<jelmer> ronny: yeah, it's tricky to get right :-/ a task-specific API is probably easier than a generic one like anyvc
<ronny> jelmer: nah, also all common vcs's have at least one fail that makes me hate them
<jfroy|work> jelmer: is that so?
<jfroy|work> (this is a worst case scenario, the svn server is still 1.4 with no plan to upgrade to 1.5 anytime soon :p )
<sri> so..
<sri> is there a irc hannel for paramiko?
#bzr 2009-02-14
<zsquareplusc> hm. i can't commit if a completely different file in an other folder is in conflicted state?
<zsquareplusc> hm. i can't commit a specific file if a completely different file in an other folder is in conflicted state??
<Peng_> jelmer: ping?
<jelmer> Peng_, pong
<Peng_> jelmer: Little subvertpy bug: subvertpy/__init__.py calls warn() but never imports it. I could file a bug (or send a patch), but since it's really trivial and I'm not sure how you'd want to fix it...
<Peng_> (And I don't have a browser open ATM.)
<jelmer> Peng_, hmm
<jelmer> Peng_, There's nowhere to import from unfortunately
<jelmer> I guess I'll just change it to ImportError
<zsquareplusc> any hints for my problem?
<Peng_> jelmer: Just use warnings.warn()?
<Peng_> zsquareplusc: Well, you could resolve the conflict. ;P
<Peng_> zsquareplusc: Why are you even trying to commit when another file is conflicted?
<zsquareplusc> and when i dont want to? its in a different subfolder
<Peng_> zsquareplusc: Doesn't that mean you have an uncommitted merge or someting?
<jelmer> Peng_, Ah, wasn't aware of that
<jelmer> Peng_, fixed
<jelmer> Peng_, thanks
<Peng_> jelmer: Thanks for ifxing it. :)
<Peng_> Augh, more typoes.
<zsquareplusc> Peng_ well, i pulled the branch from a server. that generated the conflicts. that ok. now i want to commit locally one changed file
<zsquareplusc> the file i want to commit is not in conflicted state. it just modified
<Peng_> Eh, TV to watch. See ya later. :)
<Peng_> Good luck.
<zsquareplusc> hmm.. major disapointment :(
<zsquareplusc> and bzr-gtk isn't working neither :(
<zsquareplusc> ok the later was because an older copy of the gtk plugin was found in the .bazaar folder and they were mixed up when running olive-gtk :/
<jfroy|work> jelmer: mmmmm, just found out about a repository with 250K revisions. Should be fun to branch from that using bzr-svn.
<luke-jr> How do I resolve diverged branches when upstream is svn?
<luke-jr> âº
<luke-jr> hrm
<luke-jr> only 'bzr dpush' has the problem
<bob2> isn't that the point of dpush?
<luke-jr> bob2: the point of dpush is to not use metadata
<luke-jr> I ended up just using metadata anyway
<luke-jr> and that worked fine
<luke-jr> <.<
<Peng_> Is BB down?
<Peng_> "502 Proxy Error" says that it is. :P
<Odd_Bloke> Peng_: That has meant yes in the past.
<Odd_Bloke> abentley: ^
<abentley> Peng_: Fixed
<Peng_> abentley: What happened?
<crisb> hello, i have built some packages for bzr for AIX - anywhere I can put them?
<vila> crisb: Ideally they should end up here: http://bazaar-vcs.org/Download
<vila> You should find more info on the wiki itself
<fullermd> AIX?  Wow.  That brings back painful memories...
<crisb> ;)
<crisb> its not exactly speedy for some reason
<crisb> unfortunately i had to build most of the deps myself too - so they cant really go on the download page can they?
<vila> crisb: at least you can list yourself as a contact for any interested user ? Or explain how you proceed to get there (may be at least fun :)?
<vila> crisb: did you succeed in running 'bzr selftest' ?
<crisb> hmmm :)
<crisb> well it works, but so slow
<crisb> 30 minutes and it had not yet done 1000 tests
<crisb> i think something is up with either python or bzr itself on aix.
<vila> ouch
<crisb> im probably to blame as i built python too ;)
<vila> how about the C compile ? ;)
<vila> how about the C compiler ? ;)
 * vila wonders when he will able to make a joke without typo...
<crisb> not me, but its the IBM one...so should be fine on this platform!
<crisb> bzr rocks takes 3 seconds...
<vila> oooouch:
<vila> time -p bzr rocks
<vila> It sure does!
<vila> real 0.08
<vila> user 0.06
<vila> sys 0.02
 * fullermd is perfectly willing to assign blame to AIX for anything and everything.
<crisb> indeed fuller, its soooo.........IBM ;)
<fullermd> The first system I ever adminned ran aches.
<fullermd> That was in another millennium.  It still makes me twitch.
<ronny> aches?
<vila> crisb: wait, I thought IBM stopped to public ennemy #1 with AIX, or am I mixing with something else ?
<fullermd> That's how you pronounce "AIX"   :p
<ronny> ah
<ronny> hmm
<ronny> legacy systems can be a pain
<ronny> luckyly im not going to be an admin later
<vila> ronny: fullermd never talked about legacy here, I think the system was brand new :)
<crisb> sadly its got a good reputation in financial systems!
<fullermd> Well, that system would be pretty legacy now   :p
 * vila first one was SunOS (not that Solaris gizmo...) :-)
<fullermd> If it weren't smashed into a kadnillion tiny bits, stomped into the ground, pissed on, dug up so they could be buried upside-down, had runes scrawled and incantations spoken over...
<fullermd> I mean, not that I have any hard feelings toward it or anything.
<vila> :-)
<crisb> gotta love that man with the dumbells though ;)
<ronny> hmm
<ronny> i grew ~5 files in my repo every 500 commits
<ronny> how does bzr bundle up commits?
<fullermd> Sorta kinda log(10)ly.
<fullermd> It'll grow ~1 file every thousand commits.  Then ~5 every 5 thousand commits.  ~1 every 10 thousand commits.  etc.
<vila> It groups packs at 10, 100, 1000 etc
<crisb> would anyone be able to point me in the right direction if I showed the output of bzr rocks --profile-imports from my AIX machine?
<vila> Each pack comes with a set of index files .rix revisions, .iix, inventories, .tix texts, .six signatures
<vila> crisb: better post it to the mailing list: https://lists.ubuntu.com/mailman/listinfo/bazaar
<vila> but bzr rocks may not be the most interesting, it does really the minimum and doesn't involve any of the important parts
<vila> crisb: for a start did you build celementtree ?
<crisb> python 2.5 - so I dont need to right?
<vila> right
<vila> pyrex ?
<crisb> no, but I built solaris and bzr rocks is like 0.2 seconds
<crisb> on roughtly comparable, if not slower hardware
<vila> yes, not needed for bzr rocks
<crisb> perhaps if bzr rocks is slow then that points to python
<vila> crisb: right, start with that
<fullermd> Well, something lower in the stack than bzr anyway.
<fullermd> ISTM that AIX has always had rather painful fork()'s.  But certainly not 3-seconds-painful on even remotely up-to-date hardware.
<vila> time -p python -c 'print "hello"'
<crisb> 0.03s
<glade88> hi. I checkout from lp:ideatorrent. but as the project doesnt give me write access, I did "bzr push lp:~sayakb/ideatorrent/devel" to create a new personal branch. But http://bazaar.launchpad.net/~sayakb/ideatorrent/devel/files is giving me error
<vila> crisb: same here, are you using some mounted file system ?
<crisb> nop, all local
<glade88> btw, commit done about 45 mins back..
<vila> glade88: https://code.edge.launchpad.net/ideatorrent
<vila> the branch is empty
<vila> try pushing again
<glade88> vila: "bzr push lp:~sayakb/ideatorrent/devel" ?
<vila> glade88: It should works, yes
<glade88> vila: thanks. and what about future commits? "bzr commit -m 'blah blah' lp:~sayakb/ideatorrent/devel"
<glade88> sorry, I am too used to subversion I guess :)
<vila> glade88: If you want your commits to appear in the remote branch, you should bind your local branch to the remote one with
<vila> bzr bind lp:~sayakb/ideatorrent/devel
<vila> but push first
<glade88> vila: when I bind, will the fact that I checked it out from lp:ideatorrent matter?
<glade88> since I didnt bind it with lp:ideatorrent
<vila> glade88: no it doesn't matter
<vila> the branch you checked out *from and the branch you commit *to* may be (and are here) different
<vila> but until you're more familiar with bzr you may want to avoid 'bind' until you better understand what branches are involved when
<glade88> vila: cool. push under progress
<vila> bind transform your branch in a heavy checkout which is generally what users from cvs and svn want, but it can also be a source of misunderstandings when not working in a true centralized workflow
<glade88> to avoid that, can I always "push" to my personal branch ~sayakb/... ?
<vila> And here, your're not in a such a workflow because you don't have commit rights in the trunk
<vila> glade88: yes, you can push whenever you wnat to publish your changes, which amy not be at each commit
<glade88> will that show me diffs on the remote location?
<vila> push -v will show you what you push
<glade88> but push increments the revision number, right?
<vila> bzr missing will show you the revisions you need to pull as well as the revisions you created locally
<vila> push with increment the revno of the remote branch, not the local one
<vila> s/with/will/
<glade88> so what would be the best deal to pull from one branch and commit to another one (with increment in commit revs on both local and remote?)
<vila> exactly what you've done so far
<vila> bzr branch <upstream>
<vila> bzr push <my-version>
<vila> when you want to synchronized from <upstream> do
<vila> bzr merge <upstream> ; bzr commit -m 'Merging from upstream'
<glade88> cool. (as the original project owner would review and merge my revisions to lp:ideatorrent)
<glade88> damn, still "pushing" the rev..
<vila> 'bzr version' ?
<glade88> 1.6.1
<vila> glade88: 1.12 is out, try upgrading, what os/version are you using ?
<glade88> vila: kubuntu 8.10
<glade88> maybe it isnt sybce
<glade88> *synced
<vila> You may try adding one of the ppas : https://launchpad.net/bzr
<crisb> vila - ctypes not built on my AIX python, would that slow anything?
<vila> https://launchpad.net/~bzr/+archive will gives you the official releases
<glade88> vila: thanks. wil update as soon as the push is complete :)
<glade88> (still pushing :( :( )
<vila> you're certainly pushing the whole project, more recent bzr versions should allow you to use stacked branches which result in pushing only your additional commits
<glade88> ok
<vila> That will not be always true, but launchpad should be configured for stacked branches
<glade88> yes. true. that is the longest commit I ever did to a repo :)
<vila> crisb: ctypes is not installed here either, I think it's more important for windows though
<ronny> how can i turn a branch + worktree back to just branch?
<vila> ronny: first check you have to modifications pending (bzr st) then 'bzr reconfigure --branch' should do the trick
<ronny> hmm
<gskelly> Hello, I am just starting to learn bazaar. Is it possible to combine branches from multiple shared repositories into a single branch in a new shared repository?
<Lo-lan-do> gskelly: If the branches are related, you can merge back and forth to your heart's delight.
<Lo-lan-do> Where they are hosted, standalone or in shared repositories, local or remote, has no influence on the functionality, only on performance and disk space.
<gskelly> Lo-lan-do: The repositories were created independently.
<gskelly> Lo-lan-do: I created a different repo with a single branch for different aspects of a project, (docs, data, calcs) that really should be a single directory structure in a single branch.
<gskelly> Hmmm... I'm new to IRC also :)
<Lo-lan-do> "oops"
<thrope> so I updated my loggerhead - a recent change coflicted with a hack I had to put in to get the links right, so I thought it would be fixed, but it still seems to be completely broken as standar
<thrope> all the links are broken
 * Lo-lan-do eyes beuno 
<ronny> is there any statistic on how the performance incrases over the versions?
<thrope> ah take it all back - I had a trailing slash on server.webpath that was the problem
<thrope> sorry for the frustrated tone - its been a long day
<nevans> jelmer: ping
<jelmer> nevans, pong
<nevans> bzr-svn NEWS file says that svn-push => push requires patched version of bzr
<nevans> will everything else work with plain old bzr 1.12?
<jelmer> nevans, yes
<nevans> jelmer: thanks.  :)
<jelmer> nevans, (svn-push is also still there, for those who don't have the patch)
<nevans> wonderful
<nevans> jelmer: weird message: "Upgrade to Subversion 1.5 or higher for faster retrieving of revision properties."  but it only says this when I use the implicit (saved) push/pull location.
<nevans> I'm on Ubuntu 8.10.  as far as I can tell, everything svn is at 1.5.
<jelmer> nevans, it says that when pulling from a < 1.5 svn server
<nevans> ahhh.
<nevans> well then, I suppose the weird thing is that it *doesn't* say that when I use an explicit push/pull location.
<jelmer> nevans, are you sure you're specifying the same location?
<nevans> yep
<jelmer> nevans, This is all outside of bzr-svn
<jelmer> nevans, so bzr-svn will get the same URL in both cases
<nevans> weird.
<nevans> jelmer: a noop push now takes 1min (rather than 16 to 20).  not ideal, but MUCH better.  thanks.  :)
<jelmer> nevans, cool :-)
<chx> is there a way to edit the commit message of some older commit (and it's even pushed to launchpad :/ )
<Odd_Bloke> chx: No, revisions are immutable.
<chx> ok
<chx> i did a fix on a latest commit by first uncommitting it :) but sure.
<Odd_Bloke> chx: Uncommitting threw away the old commit, the second commit created a separate commit.
<chx> yes, i understand that.
<Odd_Bloke> OK. :)
#bzr 2009-02-15
<mxpxpod> is there a new bzr-svn for 1.12?
<jelmer> mxpxpod, 0.5.0
<mxpxpod> jelmer: thanks
<mxpxpod> jelmer: where do I pick up bzr-rebase 0.4.3?
<jelmer> mxpxpod, http://samba.org/~jelmer/bzr
<mxpxpod> jelmer: I only see up to 0.4.2
<jelmer> mxpxpod, try refresh :-)
<mxpxpod> nice
<mxpxpod> thanks
<mxpxpod> jelmer: will that eventually be in the ppa?
<jelmer> mxpxpod: I don't think rebase is part of the packages in the PPA
<jelmer> mxpxpod: (I don't upload to the PPA)
<mxpxpod> jelmer: gotcha
<mxpxpod> jelmer: now, to upgrade all of my branches ;)
<mxpxpod> jelmer: does 0.5 use any svn props?
<jelmer> mxpxpod: it uses svn:executable
<jelmer> and it will set svn:mergeinfo in some cases
<mxpxpod> but no bzr:
<jelmer> mxpxpod, you mean whether it will write them?>
<jelmer> mxpxpod: it will set bzr:... revision properties if the server supports them (svn >= 1.5), otherwise it will use file properties like 0.4.x
<mxpxpod> jelmer: right... it used to set bzr:revison-info, bzr:file-ids, bzr:revision-id:v3-trunk1, etc
<jelmer> mxpxpod, it will still do that if the server doesn't support setting revision properties
<mxpxpod> jelmer: gotcha
<mxpxpod> jelmer: thanks
<mxpxpod> jelmer: one last thing... is there any way to set other svn: props thru bzr?
<mxpxpod> for instance, svn:eol-style
<jelmer> mxpxpod: no, that would require bzr to support eol-style itself first
<mxpxpod> doesn't bzr just use the native eol-style on each platform?
<jelmer> mxpxpod, no, bzr doesn't convert eol-characters atm
<mxpxpod> jelmer: ah, gotcha
<jelmer> there are some plans to support it, not sure how far along they are
<mxpxpod> jelmer: oh, one last thing... does it support svn:external yet?
<jelmer> mxpxpod, no, same thing - bzr itself doesn't support nested trees yet
<mxpxpod> k
<jelmer> so there's no way for bzr-svn to do so
<mxpxpod> thanks for answering all of my questions
<jelmer> np
<mxpxpod> jelmer: does svn-upgrade upgrade the cache from ~/.bazaar/svn-cache? or does it grab the revisions fresh?
<jelmer> mxpxpod, it cache format has changed a bit so it will create a new cache
<mxpxpod> jelmer: ok
<mxpxpod> jelmer: thanks for all the help
<mxpxpod> jelmer: one thing that kind of frustrates me is that when I push revisions from bzr, I can't see the svn revision in the log of that check-in
<jelmer> mxpxpod: it should show up if you run "bzr log" against the remote server
<jelmer> mxpxpod: It won't show up in the log of the revision you have pushed, since that would be problematic:
<jelmer> it would require "bzr push" to change the source branch (which it doesn't do, by definition)
<jelmer> what would happen if you "bzr push"'ed to multiple svn repositories?
<mxpxpod> jelmer: ah, so bzr log :parent do what I'm talking about?
<mxpxpod> jelmer: makes sense
<jelmer> mxpxpod: Yep
<mxpxpod> jelmer: heh, bzr log :parent takes a long time on a repo with lots of revs ;)
<jelmer> mxpxpod, 0.5.1 should be a bit better in that regard
<mxpxpod> jelmer: cool
<mxpxpod> jelmer: here's something strange... when I svn-upgrade one of my branches, it tells me there are conflicting tags (which there aren't) and bzr tags tells me it can't find revisions for some of the tags
<mxpxpod> jelmer: but, a fresh branch of the repo doesn't have any conflicting tags
<jelmer> could it find revisions for the tags previously?
<mxpxpod> not sure
<jelmer> mxpxpod, any chance you can file a bug about that?
<mxpxpod> jelmer: if I can reproduce it on a repository that's public, yes
<mxpxpod> jelmer: will 0.5.1 help with pull speed?
<jelmer> mxpxpod, yes
<mxpxpod> cool
<maxb> jelmer: any compat issues between bzr-svn 0.5.0 and bzr 1.12, or would it be sane to requestsync 1.12 for jaunty?
<jelmer> maxb: no, 1.12 should be fine
<mxpxpod> jelmer: does svn-upgrade migrate revprops?
<jelmer> mxpxpod, what do you mean exactly?
<mxpxpod> jelmer: does it do bzr svn-set-revprops ?
<jelmer> mxpxpod, no, it only changes the local branch, never the svn repository
<mxpxpod> ok
<mxpxpod> jelmer: is there a way to get tags to list the correct revision rather than "?" ?
<jelmer> mxpxpod: Generally not, because the ? would be shown because the tag is on a revision that is not in the branch
<mxpxpod> jelmer: ah, ok
<jelmer> --show-ids will show the "raw" revision id
<mxpxpod> jelmer: hmm... some of the tags are still pointing to svn-v3-trunk0 ids
<jelmer> mxpxpod, that could be correct if you used bzr-svn to push revisions into svn in the past
<mxpxpod> jelmer: ok
<mxpxpod> jelmer: ok, so I have a branch of an svn branch that I do work for a release in... if I do bzr tags --show-ids, it shows some tags as svn-v3-trunk0 which show up as v4 in the svn branch
<jelmer> mxpxpod, was this the branch that you got the conflicts on earlier?
<jelmer> mxpxpod, what happens if you do a clean copy?
<mxpxpod> jelmer: here what I did: with 0.4.x I did this... bzr branch http://somerepo/trunk trunk; bzr branch trunk 1.3.4
<mxpxpod> then when I got 0.5, I did this: mv trunk trunk.old; bzr branch http://somerepo/trunk trunk
<mxpxpod> jelmer: make sense?
<jelmer> mxpxpod, yeah
<mxpxpod> jelmer: now, bzr tags --show-ids show v3 ids in 1.3.4
<jelmer> and trunk shows v4 ids ?
<mxpxpod> jelmer: yup
<jelmer> but you have the same amount of "?"'s in 1.3.4 and trunk?
<mxpxpod> yes
<mxpxpod> but when I do a pull in 1.3.4, it says there are conflicting tags for the tags that are v3
<jelmer> mxpxpod, that's correct
<mxpxpod> jelmer: how do I get those tags to point to the v4 equivalent?
<jelmer> if you run "bzr svn-upgrade" in 1.3.4 it should fix those tags
<jelmer> if it doesn't then that's a bug
<mxpxpod> it says trunk is not a foreign repository
<jelmer> mxpxpod, you need to specify the svn repository
<mxpxpod> jelmer: awesome! thanks
<mxpxpod> jelmer: and if I run that same command in trunk, it upgrades the old v3 ones to v4
<jelmer> mxpxpod, Ouch, that's wrong
<mxpxpod> it does the same thing in 1.3.4
<mxpxpod> it doesn't keep the v3 ones that are supposed to be v3 as v3
<jelmer> mxpxpod, should be fixed in the 0.5 branch
<mxpxpod> jelmer: will it fix the v4 thing?
<jelmer> mxpxpod, v4 thing?
<mxpxpod> jelmer: where 1.3.4 had v3 ids and then I ran svn-upgrade and got v3 ids... will it fix that?
<jelmer> mxpxpod, it will make sure svn-upgrade doesn't upgrade some revisions to v4 unnecessarily
<mxpxpod> jelmer: also, are you talking about the lp:bzr-svn branch?
<jelmer> mxpxpod: Where did you get v3 ids in the 1.3.4 branch exactly?
<mxpxpod> for some tags I made with the old bzr-svn a while back
<jelmer> mxpxpod: It's not incorrect if it leaves some v3 revisions
<mxpxpod> jelmer: right
<mxpxpod> jelmer: but it changed the v3 ones that I made to v4
<jelmer> mxpxpod: But it should only do that for tags that are not "?" tags
<jelmer> mxpxpod, that bit should be fixed now (upgrading some to v4 incorrectly)
<mxpxpod> jelmer: in lp:bzr-svn?
<jelmer> mxpxpod, bzr-svn's main branch is at http://people.samba.org/bzr/jelmer/bzr-svn/0.5
<jelmer> lp is usually out of date
<mxpxpod> ah, ok
<mxpxpod> jelmer: ok, so is there a way to fix a branch from svn-upgrade changing them to the wrong thing in 0.5.0?
<jelmer> mxpxpod: Fix the tags after  bzr-svn all changed them to v4 tags?
<mxpxpod> jelmer: yes
<jelmer> mxpxpod, if the tags are in svn, you can just "bzr pull" from svn
<mxpxpod> that doesn't change them from v4 back to v3
<mxpxpod> aha!
<mxpxpod> bzr pull --overwrite
<jelmer> ah
<mxpxpod> and that fixed it
<mxpxpod> jelmer: thanks for the help
<jelmer> mxpxpod, once again, np :-)
<mxpxpod> jelmer: now you know what to tell people that have the same problem as me :D
<jelmer> and thanks for helping fix that bug in svn-upgade
<mxpxpod> jelmer: not a problem
<mxpxpod> alright, gotta go
<mxpxpod> have a good nige
<mxpxpod> night
<evarlast> I'm attempting to install flup to get bzr-smart.fcgi to work on win32. Does anyone knwo if I can drop a flup egg into c:\Python25\lib\site-packages and expect it to work?
<evarlast> nevermind. I'm stupid. just copy fcgi.py along size bzr-smart.fcgi is easier.
<evarlast> anyone using bzr-smart.fcgi with modwsgi?
<evarlast> google is amazing, looks like someone had my same issue, very recently: http://pastebin.com/m533f12af
<evarlast> ok, that issue is fixed, now I can't auth on windows, but I can auth on linux with the same config :(
<gour> hi, how to get branch from LP when it reports: "bzr: ERROR: The API for "<module 'bzrlib' from '/usr/lib/python2.6/site-packages/bzrlib/__init__.pyc'>" is not compatible with "(1, 10, 0)". It supports versions "(1, 11, 0)" to "(1, 11, 0)"." ?
<fullermd> That's probably nothing to do with LP.
<fullermd> You've got a 'bzr' (the 'bzr' script itself, specifically, not the whole package) from 1.10 around, that's finding the 1.11 bzrlib.
<gour> hmm, i'm running 1.11
<Peng_> Or bzr-svn or some other plugin is doing it.
<Peng_> I think "bzr" itself raises a different error.
<fullermd> Oh, I forgot bzr-svn had that quirk in a version or two.  That sounds more likely.
<gour> hmm, ok..let me check bzr-svn
<gour> thanks. rm-ing bzr-svn did it :-)
<Peng_> That's a wee bit extreme.
<gour> sure it is, but, well
<gour> ...
<Leonidas> Is this a known issue: http://paste.pocoo.org/show/104115/
<Leonidas> It happened when I bzr unshelve'd
<Odd_Bloke> Leonidas: Yes, that's bug #328148.
<ubottu> Launchpad bug 328148 in bzr "Less spaff from unshelve, please" [Undecided,Confirmed] https://launchpad.net/bugs/328148
<Odd_Bloke> It's just a problem in the progress bar, nothing to worry about.
<Leonidas> Odd_Bloke: Thanks. I thought that it wasn't really important, just wanted to make sure the developers know about it :)
<Odd_Bloke> Leonidas: Thank you. :)
<radix> you know what'd be nice? if there were a way to have a bound branch which did the pushes asynchronously, so I could get back to hacking after a "bzr commit" quickly but also have the peace of mind of knowing that I can't forget to push.
<ronny> oh, that idea might be nice fir pida, too
<radix> of course, there would need to be some other mechanism for dealing with asynchronous conflicts. Ideally, some GUI window would pop up (or even just a desktop notification) if I'm in the appropriate environment.
<radix> but barring a GUI, I guess it could just notify you of the conflict next time you ran a bzr command, or something.
<radix> sorry, I'm saying "conflicts" but I actually mean "divergent branches"
<ronny> i think seting up per-user push branches is helpfull
<radix> just an idle thought while waiting for a 'bzr commit' to complete in a hotel room :)
<ronny> keeps conflicst out of the way till one chooses to do
<ronny> that would need another async checker that ckecks for changes on the pull path
<radix> ronny: yeah, sure, but I have the same branches bound on my desktop and my laptop machine
<ronny> and then pops up a notification
<ronny> radix: ah i see
<ronny> but you dont work at both at the same time?
<radix> I'll switch back and forth and often forget to update before changing something
<ronny> so asnc update checking might be helpfull, too
<radix> but yeah, something that automatically *pulls* would also help that
<radix> I could just set up a few cron jobs I guess
<ronny> i'll have to remember that
<ronny> it would certainly be a nice addition to pida
<ronny> (an ide)
<radix> ah, I was just about to ask what it is.
<ronny> jelmer: is there any documentation about bzr's current storage formats other than the source?
<ronny> im stil a bit lost on figuring where those weird xml things are needed
<ronny> ok
<ronny> now i figured it
<ronny> sad, just sad
<jelmer> ronny, xml things?
<jelmer> ronny, there shouldn't be a need for you to bother with internals..
<ronny> jelmer: well, i know the git and hg internals, now i want to know the bzr ones
<ronny> and i get more and more unhappy with that stuff
<jelmer> ronny: ah
<jelmer> ronny, there's some docs in doc/developers/
<jelmer> ronny, what makes you unhappy though?
<ronny> the kiss principle seems to be missing
<jelmer> it seems pretty simple to me - one store for revisions, one for inventories, one for texts, that's it basically
<jelmer> gtg, back later
<ronny> everything seems striple if you strip the details out
<edcrypt_> is there a way to iterate over all versioned files of a wt, on a specific dir?
<ronny> edcrypt_: there is WorkingTree.list_files, but it doesnt filter, maybe there is an better api im not aware of
<edcrypt_> ronny: the sdocstring says it list unversioned dirs, no mch better than WT.iter_entries_by_dir
<ronny> edcrypt_: there is the filter_unversioned_files method
<edcrypt_> ronny: thanks, I'll take a look.
<ronny> bbl
<yeonhoo> helloo
<yeonhoo> bzr push bzr+ssh bzr+ssh://login@bazaar.launchpad.net/~registrant/project/branch  <---> bzr: ERROR: Not a branch: "C:/program files blablablablal"
<yeonhoo> seems like bzr+ssh unknown command
<yeonhoo> any help?
<knitt1> hello. i made a stupid merge, how can i delete that commit? or how can i fix it? xD
<yeonhoo> hmmmm
<yeonhoo> i installed bazaar on ubuntu,, but same error occures
<knitt1> turns out i deleted the upstream changes, not mine
<yeonhoo> well.. seem like to not be an error
<yeonhoo> knitt1: hi
<knitt1> hi yea
<knitt1> * yeonhoo
<yeonhoo> yes im new here.. im having problem
<knitt1> ok, i'll try to help you. but i'm not so fit with bazaar either
<knitt1> go ahead :)
<yeonhoo> bzr push bzr+ssh <-- is this command always output " bzr: error: not a branch" ?
<yeonhoo> ok :)
<knitt1> yeah, that command makes no sense
<yeonhoo> bzr push bzr+ssh://mylogin@bazaar.launchpad.net/~mylogin/+junk/myproject
<yeonhoo> even this?
<knitt1> that one is ok
<yeonhoo> but it does not work
<yeonhoo> even on ubuntu or windows haha...
<knitt1> but you can simply do bzr push lp:~yeonhoo/+junk/yourproject
<knitt1> do you have an launchpad account? :p
<yeonhoo> yes i have
<yeonhoo> what is lp command?
<knitt1> it's just a shorthand
<knitt1> for launchpad branches
<yeonhoo> ok... same error
<yeonhoo> very strange
<knitt1> wait â¦ did you upload your public ssh key to lp?
<knitt1> you need to do that, otherwise you cannat push
<yeonhoo> upload my public ssh key?
<yeonhoo> no..
<yeonhoo> i uploaded to launchpad
<knitt1> yes, but you need to add your ssh key to launchpad before you can push to it
<yeonhoo> yes i add to launchpad already
<yeonhoo> but i have to add it to bzr ? something like that?
<knitt1> should work out on the box with ubuntu
<knitt1> on windows you need pageant for it to work
<yeonhoo> even on ubuntu doesnt work
<yeonhoo> the same error
<yeonhoo_ub> yeonhoo@yeonhoo-desktop:~$ bzr push lp:~yeonhoo/+junk/teste
<yeonhoo_ub> bzr: ERROR: Not a branch: "/home/yeonhoo/".
<yeonhoo_ub> its something like that
<yeonhoo_ub> huh
<knitt1> ouch â¦
<knitt1> you need to create a bzr repo first
<knitt1> bzr init
<knitt1> :/
<fullermd> Of course, you probably don't want to do that in $HOME...
<knitt1> well, yes, you don't want to do that in ~
<garyvdm> yeonhoo_ub: have you come right yet?
<thumper> yeonhoo: have you done a `bzr lp-login`?
<yeonhoo> opss im back
<yeonhoo> thumper: im logged yes
<knitt1> isn't there todo's en-masse on the net? *scnr*
<thumper> yeonhoo: I mean have you typed the command `bzr lp-login`?
<yeonhoo> thumper yes
<garyvdm> yeonhoo: Where is the branch you are pushing from?
<thumper> yeonhoo: have you got things sorted yet?
<yeonhoo> yes it seems to be working now
<yeonhoo> as knitt1 said i did bzr init
 * thumper nods
<garyvdm> yeonhoo: now you are pushing a empty branch? is that correct?
<yeonhoo> !?...
<yeonhoo> yes i think...
<yeonhoo> is branch a kind of project box yea?
<garyvdm> Yes
<yeonhoo> yes i created an empty branch called "teste"
<garyvdm> ok
<yeonhoo> and im now "push" to it
<yeonhoo> is push command just for access the branch yea?
<garyvdm> You would use push to copy your work form your computer to launchpad.
<garyvdm> You would use pull to copy from launchpad to your computer...
<yeonhoo> yea.. maybe im asking stupid question.....
<yeonhoo> yea..ok
<yeonhoo> it is asking for password
<garyvdm> On windows?
<yeonhoo> i think it is askin for ssh keys
<yeonhoo> yes
<yeonhoo> i have to put all the ssh !!...
<yeonhoo> !?...wow
<ubottu> Information about games on Ubuntu can be found at https://help.ubuntu.com/community/Games and http://www.icculus.org/lgfaq/gamelist.php
<garyvdm> Are you running  pageant?
<yeonhoo> no im not
<yeonhoo> pageant?
<garyvdm> On windows, you need to run pageant, and load your private key
<yeonhoo> ah..
<yeonhoo> ok.. im on way
<garyvdm> http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
<yeonhoo> yeah..it authenticate automatically
<yeonhoo> good...!
<yeonhoo> thank you :)
<yeonhoo> wow... im surprised with such tool...
<yeonhoo> is branch name can be changed?
<lifeless> sure
<yeonhoo> lifeless: could you give me keyword?
<lifeless> yeonhoo: 'mv'
<yeonhoo> thank you ! :)
<yeonhoo> hum
<yeonhoo> i think i need an exemple
<yeonhoo> to mv existe branch on net what should i do?
<yeonhoo> i was trying "bzr mv lp:~blbalbalbal/source lp:~blablabla/destinatino
<mwhudson> oh
<mwhudson> you have to do that on the website
<yeonhoo> oh.
<lifeless> yeonhoo: if it was on your disk it would be 'mv source destinatino'
<lifeless> yeonhoo: but launchpad isn't a file system :)
<lifeless> yeonhoo: if you go to the branch page you should be able to rename it
<thumper> yeonhoo: you can rename a branch on launchpad by clicking on the edit link (a yellow pencil IIRC)
<tristil> How do I set up a bzr ignore rule so that when I add  a git project I don't get any of the .git folders?
<lifeless> tristil: 'bzr ignore .git'
<tristil> lifeless, cool thanks. I was trying /.git/ */.git/*, etc.
<lifeless> tristil: we do support a regex syntax and zsh's magic syntax, but thats only needed rarely :)
<tristil> I guess I was using bash wildcards, but I thought the first one should have worked.
<lifeless> sorry :)
<jelmer> lifeless, hi
<lifeless> hi jelmer
<jelmer> lifeless: What format from brisbane-core should I use when importing large rich-root repositories (OOO) ?
<lifeless> development4
<lifeless> erm
<lifeless> you need rich root yeah? you'll need to add a rich root variant of dev4, or use dev4-subtree
<jelmer> thanks
<rockstar> If I want to test merge a remote branch into another remote branch programmatically, what's the best way to approach that?  Get a checkout of the target (for the working tree) and merge in source?
<lifeless> spiv: so, my place or yours? (please say 'lifeless' place')
<lifeless> rockstar: PreviewTree
<rockstar> lifeless, well, what if the end goal is committing?
<lifeless> rockstar: in principle you could commit a PreviewTree
<lifeless> no idea about practice :)
<rockstar> Alright, I'll go digging.
<lifeless> MutableTree.commit() is the entry point
<spiv> lifeless: yours is fine, but I can't get there until midday or so.  I have an errand to take care of.
<lifeless> spiv: cool. I have 'target_versionedfile.insert_record_stream(NetworkRecordStream([record.get_bytes_as(record.storage_kind) for record in source_versioned_file.get_record_stream()).read())' working
<lifeless> spiv: just let me know eta - sms or whatever. I'll try to get sprint tickets and other housekeeping done before you arrive
<spiv> Ok.
<spiv> I have resumed write groups committing successfully.
<lifeless> sweet
<lifeless> de alchemy progresses
<ronny> sup
<ronny> what are the plans for performance? compared to git/hg bzr still tends to feel a bit slugish
<spiv> ronny: extensive :)
<spiv> ronny: lifeless and I are tackling network performance at the moment, and other folk are working on building a faster repository format.
<ronny> another one again?
<ronny> btw, whats the reasoning behind xml in the repos?
<ronny> the sources have sarcastic comments about that
<spiv> There's a brief note about it at http://doc.bazaar-vcs.org/obsolete-docs/yaml.html
<spiv> I'm not sure if there's a more extensive discussion somewhere else.
<ronny> in comparisation git has some pretty neat optimized fieldsets there that can be parsed rather simple
<lifeless> ronny: xml was chosen because it was 'standard' - but we didn't appreciate how much of a burden it would turn out to be
<emmajane> vila, ping?
<lifeless> ronny: the reason for another repository format is to remove much of the xml we parse. As a datapoint, bzr.dev's repository has 3.3GB of xml inventory data
<emmajane> beuno, ping too :)
<lifeless> ronny: (after zlib and delta decompression)
<lifeless> ronny: thats a huge amount of data to parse and process, and its nearly entirely dead weight
<lifeless> spiv: success!
<lifeless> spiv: I can cleanly networkise and unnetworkise a knit's record_stream with delta_closure=False
<ronny> lifeless: will the xml gradually go away with new repo formats?
<lifeless> ronny: I imagine so, there is no reason to keep it; revision's for instance have problems with some legacy commit messages that can't be encoded in xml sanely
<lifeless> so doing away with it will fix bugs/ickyness
<lifeless> ronny: its just not worth doing a repo format solely to remove it
<ronny> ah, k
<lifeless> for instance, several folk did repo formats that were just yet-another-line-based-format, but not enough of a difference to force people to transcode their data
<lifeless> the brisbane-core format is really very different though; massively less raw data to process, so log -v and other commands should be a lot faster
<lifeless> igc is working on that aspect of brisbane-core at the moment
<ronny> any eta on when it will land?
<lifeless> we're hoping to have a beta (--developmentX) format for early adopters and benchmarkers in late march
<ronny> good
<lifeless> once we find and fix any issues from them we'll make a long term supported version of it
<garyvdm> lifeless: Where can I find docs/branch for brisbane-core?
<lifeless> lp:~bzr/bzr/brisbane-core
<jelmer> lifeless, I can notice the recent speed improvements in brisbane-core
<lifeless> jelmer: cool; what are you doing that you notice?
<ronny> another thing that makes me wonder - why different stores for revs, inventories and texts?
<jelmer> lifeless, importing 1k revisions from OOo
<lifeless> ronny: legacy; we're moving to a single key space. We nearly did at 1.6 but I was a bit of a stick in the mud at the time.
<ronny> ah, i see
<ronny> you gradually kill all points that i actually dislike
<lifeless> ronny: way way way back poolies prototype had seperate directories for each kind of thing
<ronny> lifeless: the last 2 things i actually miss is content addressing and custom objects
<lifeless> tla didn't even have stores so its not even worth mentioning, other than to say it did have three 'kinds' of things, and I think that coloured the bzr prototype somewhat
<lifeless> ronny: brisbane-core uses CHK (content hash key's - a reasonably widely used term) for the elements of its inventories
<lifeless> content addressing per-se isn't terribly useful IMO
<lifeless> re: custom objects, what system allows that?
<ronny> none atm
<lifeless> ah :)
<ronny> well, in git i can actually create them
<ronny> but then the repo is fscked
<lifeless> the network stream won't be able to handle them
<lifeless> just setting a type byte isn't enough :)
<lifeless> ronny: I'd like to understand a bit more about these things, how you want them to behave [without your plugin], how they should connect(or not) to revisions and inventories and so on
<ronny> lifeless: i would be ok if there was some kind of "rich" type that supported referencing + custom data
<ronny> lifeless: i'd like to use them for stuff like approvals for comits or testresults
<jelmer> lifeless, importing 1k revisions of OOo SVN takes 270 seconds on my 3-year old thinkpad, down from > 4000 seconds a few months ago
<jelmer> lifeless, admittedly bzr-svn has also improved since
<lifeless> jelmer: thats a nice improvement
<lifeless> jelmer: what tree adding api are you using?
<jelmer> lifeless, I'm using .texts directly, and calling Repository.add_inventory_by_delta()
<lifeless> jelmer: texts.insert_record_stream() ?
<jelmer> lifeless, texts.add_lines() actually
<lifeless> jelmer: ok; well if text adding starts to be important, I can suggest some refactorings to reduce duplicate work
<jelmer> lifeless, and get_record_stream() to retrieve the fulltexts to apply the delta against
<lifeless> jelmer: svn gives you byte deltas right?
<jelmer> lifeless, yeah
<lifeless> shame :P
<lifeless> line deltas we could nearly/probably translate directly to knit deltas, if svn gave  you the sha1
<jelmer> unfortunately svn still uses md5 :-(
<lifeless> jelmer: you might like to try the groupcompress plugin's --gc-subtree-chk, if I created one
<lifeless> jelmer: that would give a very interesting repository size :)
<lifeless> jelmer: but - you'd definitely want to use insert_record_stream, not add_lines
<jelmer> lifeless, I
<jelmer> 'll look at that, thanks
<ronny> lifeless: do you see any reasonable way to put support for recording things like testresults/approvals into the store ?
<lifeless> ronny: the former seems likely to be large
<lifeless> and the latter small
<lifeless> It seems like both of those would be indexed best by revision
<ronny> could approvals be solved by signatures by more than one person?
<lifeless> so you could say 'give me the test results for revid:XXX'
<lifeless> and likewise the approvals
<lifeless> so handwaving on how fetch would know to copy them, you could easily do what bzr-search does
<lifeless> and use the bzr machinery to create a store containing what you want
 * igc breakfast
<lifeless> I know thats probably not as integrated in as what you desire
<lifeless> but we tend to find good answers after a couple of plugins start doing things outside the core, to let them hook in closer to the core
<lifeless> things in the core need to move somewhat cautiously because of their broad impact on users (and the need to rev format ID's to ensure consistent handling of data etc)
<lifeless> there are currently two plugins I know of annotating the core data in [technically different, but morally the same?] ways - bzr-revnocache and bzr-search
<ronny> im kinda feed with enough info
<ronny> i'll reevaluate bzr again once the new repo format is there
<jelmer> igc, hi
<jelmer> lifeless, the main overhead now is in svn itself, the bzr-svn cache (turning it off boosts performance significantly) and get_raw_records
 * jelmer is happy and releases 0.5.1
<rysiek|pl> hi guys
<jelmer> hi rysiek|pl
<rysiek|pl> I've got a problem - my co-worker added some *huge* (as in 100MiB+ huge) files (actually, some ~80 files, 3-4MiB each), committed and merged with my branch
<rysiek|pl> those wqhere completely unneaded, so I bzr removed them
<rysiek|pl> but, they are still in the packs, arent they?
<bob2> yes
<rysiek|pl> this causes me to have ~400MiB branch for a code project we work on
<bob2> all you can really do is branch from before he/she did that
<rysiek|pl> which is a royal PITA, as you may guess
<rysiek|pl> thing is, it wasn't that bad PITA until now, so we're ~100 revisions ahead
<rysiek|pl> as I understand there is no way I can simply "delete" the removed files from the branch
<RAOF> IIRC you can branch to before the files were added and then replay the commits after the files were added to that branch; I think the 'bzr replay' command is what you're after, in the bzr-rebase plugin?
<rysiek|pl> as bzr's purpose of life is to preserve them :)
<rysiek|pl> ah
<rysiek|pl> there we are
<rysiek|pl> RAOF: thanks a bunch, that should work
<lifeless> jelmer: get_raw_records - you mean disk IO?
<RAOF> Right.  It's not often that you want to expunge something from the history, but it can happen, and I've seen discussions here about precisely how to make it work nicely.
<jelmer> lifeless: yes, retrieving the fulltexts to apply deltas against
<rysiek|pl> ok, I'll grok some IRC logs from Teh intertubes and google some more for bzr replay
<jelmer> lifeless, I might be able to avoid that a bit by keeping a LRU cache of recently generated fulltexts
<rysiek|pl> that should get me on the right track, I guess :)
<rysiek|pl> thanks again
<jelmer> lifeless, since bzr-svn usually imports children right after their parents, and since linear history is very common in svn
<jelmer> lifeless, ideal would be of course if bzr supported svn-deltas :-P
<RAOF> rysiek|pl: If you run into trouble, I'm sure lifeless knows how to do what you want, when he's less busy :)
<rysiek|pl> ok
<lifeless> jelmer: we could look at putting a small LRU back into VersionedFiles; we had one but it was terrible in the past
<lifeless> rysiek|pl: bob2 and RAOF are right
<lifeless> rysiek|pl: once you've done that you won't have to copy the 400MiB around anymore, though it will be dead weight in your current repos, it won't clog up network ops or things like that
<rysiek|pl> lifeless: exactly what I need
<rysiek|pl> ho-humm... "At the end of the process it will appear as though your current branch was branched off the current last revision of the target." - but right now it is "as if it was branched" from that very original branch and revision
<rysiek|pl> as it's just a single branch
<rysiek|pl> ah, well
<rysiek|pl> manpages ftw
<emmajane> vila, beuno I've made a new page for the bzr-upload plugin. http://bazaar-vcs.org/BazaarUploadForWebDev I wanted some extra documentation for a talk I'm giving. Please edit as appropriate. :)
<lifeless> rysiek|pl: are you stuck?
<rysiek|pl> lifeless: nah, rather massively multitasking
<lifeless> rysiek|pl: ok, just shout and RAOF and bob2 if you get stuck
<lifeless> I've just volunteered em :)
<rysiek|pl> ok, will do :)
<RAOF> lifeless: No fair!  I volunteered you first!
<lifeless> RAOF: you did, but I'm wearing my teflon underpants today
<rysiek|pl> RAOF, bob2, lifeless: that's not a problem, guys, you are simply all volounteers now :)
<rysiek|pl> lifeless: no teflon underpants can save you from sharks
<rysiek|pl> lifeless: ...with lasers!
<lifeless> haha
<RAOF> Eh.  You don't need teflon underwear to deflect sharks.  You just punch their nose through their skull.
<rysiek|pl> RAOF: I think you missed the "with lasers" part. see, when you punch the nose of a laser-equipped shark, you actually *fire* the lasers
<jelmer> lifeless, how much faster should it be to call insert_record_stream() with a single stream rather than multiple times with single items?
<lifeless> jelmer: "it depends" :P
<lifeless> jelmer: so GroupCompressVersionedFiles - they hold a single compressor context open during insert_record_stream()
<lifeless> jelmer: so insert_record_stream([foo]), i_r_s([bar]) -> two seperate compression groups
<jelmer> lifeless: in other words, it might matter if the texts were similar enough?
<lifeless> i_r_s([foo, bar]) -> one compression group
<lifeless> jelmer: and there is no delta compression between different groups in groupcompress today
<lifeless> jelmer: so, one call per text -> you get zlib'd texts
<jelmer> lifeless, ok
<lifeless> one call for all texts -> you get delta compression
<lifeless> for knits it doesn't make _as much_ difference
<jelmer> lifeless, ok
<jelmer> thanks again :-0
<jelmer> s/[0-9][)-(]/
<lifeless> its possible we should make gc hold the compression context open across inserts
<lifeless> but this slight constraint seems useful IME
<jelmer> will a repack change what compression context texts are in?
<lifeless> repack on gc repos is currently broken
<lifeless> bzr.dev changed to become more knit dependent, or something
<lifeless> the intent is that gc will on autopack combine single commits into larger groups, so yes.
<lifeless> but at a certain size of group it will stop fiddling ;)
<jelmer> ok, in that case I won't bother overoptimizing fetch in bzr-svn
<rysiek|pl> lifeless: let me get this straight:
<rysiek|pl> 1. branch the crufted branch
<rysiek|pl> 2. bzr revert to the revision with no crift yet
<lifeless> rysiek|pl: 1. branch -r REV_BEFORE_BADNESS crufted fresh
<rysiek|pl> 1 + 2 in a single step, right
<lifeless> no, fundamentally different
<lifeless> 'bzr revert' changes the tree only, you want to change the branch
<rysiek|pl> ah, revert will leave the cruft in packs
<rysiek|pl> okay
<rysiek|pl> if I know the name of a bzr removed file, is there a way to easily check in what rev it was removed?
<ronny> hmm, im a bit confused - is the only difference betwen normal and rich root a set of properties on the roots?
<lifeless> ronny: yes
<lifeless> rysiek|pl: bzr log -v | less - sorry :(
<rysiek|pl> ssure
<ronny> lifeless: then why the heck as normal necessary to begin with?
<lifeless> ronny: it was a design bug waaay back
<ronny> i see
<Peng_> The only reason rich-roots haven't been made the default long ago is backwards compatibility.
<lifeless> we all want rich roots to be 'normal' and 'normal' to go away quietly
#bzr 2010-02-15
<bob2> uh-huh
<malibu> bob2: I have many files (work related) that I don't want out there..
<jpds> malibu: rdiff-backup.
<bob2> tahoe in no way implies storing data with random people
<bob2> if you choose to do so, they are carefully encrypted
<wgrant> rdiff-backup is awesome.
<bob2> it does sound more like you want unison, though
<malibu> bob2: Lol.. well I saw "cloud" in the summary and it turned me off@!
<malibu> Yes, unison does sound interesting
<lifeless> poolie: http://github.com/droundy/iolaus looks interestingish
<poolie> interesting
<mathrick> yep!
<malibu> the thing that makes me leery about unison (and now I remember being here before) is that it points to some guys user directory to download it
<malibu> Although the documentation seems to be really good
<jelmer> mwhudson, pong
<mwhudson> jelmer: hi
<jelmer> hello
<mwhudson> jelmer: i'd very much like a reply to the latest "plan for incremental code imports" mail
<jelmer> mwhudson, a recent one, from after friday ?
<mwhudson> jelmer: hm, i don't have anything from you on the subject since tuesday
<mwhudson> jelmer: can you resent your latest?
<jelmer> perhaps I missed an email
 * jelmer looks
<mwhudson> jelmer: lots of worrying about topological sorting
<ed-209> I'm writing a small app in 2.7.0 that generates a SQLite DB but chokes when I try to add foreign key constraints.  What version of SQLite DBs does Mono.Data.SqliteClient generate?
<Peng> ed-209: Wrong channel?
<ed-209> oh ya
<ed-209> Reading is Fundamental I guess
<jelmer> mwhudson, found it
<mwhudson> jelmer: anything to talk about now?
<jelmer> mwhudson, I'm replying to your email
<mwhudson> jelmer: cool
<jelmer> also, I just switched to dvorak - so a bit slow still :)
<Peng> Enjoying it so far?
<mwhudson> :-)
<jelmer> peng: typing 8 times slower than usual is *really* frustrating
<jelmer> hopefully it'll get better soon
<jelmer> sent
<jelmer> mwhudson, ^
<Peng> If I typed 8 times slower than usual, wow, I couldn't use a computer at all.
<mwhudson> jelmer: thanks
<jelmer> mwhudson, that's exactly what it feels like
<mwhudson> jelmer: you can't even talk to the right person in irc!
<jelmer> s/mwhudson/peng
<jelmer> mwhudson, :)
<meoblast001> hi
<wgrant> I tried to switch to Dvorak a couple of years ago, but never got really fast, so I switched back.
<meoblast001> i'm told git does not store old revisions of binary files, is this true for Bazaar?
<wgrant> But now whenever I think about typing, I unknowingly switch to Dvorak.
<Peng> meoblast001: Bazaar does not distinguish between text and binary files.
<maxb> meoblast001: I don't think that's true of git, let alone bazaar
<meoblast001> ah, so i've been lied to
<Peng> Indeed. I'd be very surprised if Git did that.
<wgrant> It would make Git pretty useless.
<jelmer> wgrant, this is my 4th try :)
<lifeless> spiv: ping
<igc> hi all
<lifeless> spiv: are you on today? I'd like to point you at some polish on the merge hook you did
<mwhudson> jelmer: in import_git_objects, can we just limit the times we go around the last for loop?
<mwhudson> jelmer: i'm not sure what the "while heads:" loop is doing
<malibu> How do I retrieve older versions of files with unison?
<bob2> you don't
<bob2> it's a sync tool
<malibu> Oh but I want versions.. unison won't work for me
<malibu> So unison isn't much more then rsync then
<jelmer> mwhudson, yeah
<mwhudson> jelmer: cool
<mwhudson> jelmer: any idea how to test this?
<malibu> I basically want protection from anything... such as deleting a file by accident
<malibu> I think I might use unison, but also take an incremental backup of the repo a few times a day
 * wgrant wishes that bzr would warn when it had a bad email address set.
<_Andrew> Hi
<_Andrew> Anyone else have a problem where you can't commit through a mounted smb partition unless you do it as root?
<_Andrew> My /etc/fstab line looks like this...
<_Andrew> /computer/repo /mnt/repo cifs rw,username=user,password=pass,noauto,users,group,exec,dev,suid 0  0
<_Andrew> Any ideas?
<lifeless> well, what error do you get?
<_Andrew> It says permissions denied code 13
<_Andrew> Cannot lock lock dir
<_Andrew> I'm guessing it's how I setup the mount?
<lifeless> that suggests that you don't have permission to lock things
<lifeless> if your working tree is on the mount, this could be an OS lock, or a dirlock, where we rename a directory to take the lock.
<lifeless> if your working tree is not on the mount, then its only going to be a dirlock; check your users permissions to .bzr/repository/ .bzr/repository/lock and .bzr/branch and .bzr/repository/lock
<_Andrew> ok
<_Andrew> thanks
<_Andrew> Could it be because when I crate a file on the mount it create is with no permissions to write?
<_Andrew> create**
<lifeless> that would be a problem
<lifeless> poolie: I don't know the number that its a dupe of
<lifeless> poolie: but I'm very sure its a dupe
<poolie> mm it looked familiar
<lifeless> it was a smart server code path
<lifeless> issue
 * igc lunch
<poolie> igc, around?
<igc> hi poolie: back from lunch now
<thumper> just to confirm, if a bug was fixed for 2.0.1 it was also in the 2.1.x branch?
<lifeless> check the bug, it should have separate tasks
<lifeless> but generally, yes. it would have been fixed in trunk as well. and trunk became 2.1.x recently
<thumper> lifeless: https://bugs.edge.launchpad.net/launchpad-code/+bug/3918
<ubottu> Ubuntu bug 3918 in bzr "bzr can be caused to error with filenames containing newlines" [High,Fix released]
<thumper> lifeless: only one bzr task
<lifeless> should be fixed in 2.1.x then
<thumper> ta
<lifeless> damn I love noise cancelling headphones
<spiv> lifeless: not today, thu and fri
<lifeless> so on tue,wed only?
<spiv> lifeless: no, off mon,tue,wed, and on thu,fri currently.
<lifeless> kk
<AfC> How come `bzr ls` shows .~N~ revert files? It's not a problem, of course. Just a bit weird.
<lifeless> with no options it acts like 'ls'
<lifeless> AIUI
<spiv> lifeless: damn ambiguous language :)
<lifeless> spiv: I thought it was lovely and clear... and possibly wrong :)
<spiv> :)
<AfC> lifeless: er, not really. [when recursing] it leaves out [children of] ignored file paths. So why would it show ~ files?
<lifeless> AfC: file a bug please ;)
<AfC> anyway, I just thought it was weird.
<lifeless> it is - thus me wanting a bug ;)
<AfC> seeing as how there is a --ignored flag
<AfC> ok
<AfC> lifeless: https://bugs.launchpad.net/bzr/+bug/522015 filed for you
<ubottu> Ubuntu bug 522015 in bzr "bzr ls shouldn't show .~1~ revert files" [Undecided,New]
<lifeless> thanks
<poolie> AfC, so the problem is actually that it shows ignored files but does not recurse into them?
<poolie> spiv, lifeless, https://lists.launchpad.net/launchpad-dev/msg02590.html may be of interest
<lifeless> poolie: have you seen ground control ?
<lifeless> (i'm glad hydrazine is coming along)
<poolie> only briefly
<poolie> does it cover bug stuff?
<AfC> poolie: I should think that the problem is that it's showing unversioned files. The recursion interaction may be complicating things
<poolie> so the bug is 'i wish bzr ls excluded ignored files by default'?
<poolie> igc, so regarding annotate
<poolie> it would be good to fix
<AfC> um isn't it supposed to?
<AfC> I mean, otherwise, why the --ignored option?
<lifeless> I'd say that being inconsistent is a bug
<lifeless> either recurse into and show ignores, or do neither
<igc> poolie: hi poolie
<AfC> and meanwhile, if you do `bzr ls -R` it does not list contents of ignored [top level] directories]
<poolie> igc, so we should probably ask first whether you have anything else yet unfinished
<poolie> you, or we
<poolie> afc, ls --ignored means "only ignored"
<AfC> which is what you'd expect given the whole "ls me what's versioned" expectation
<poolie> i don't know if that's really the ideal behaviour
<AfC> poolie: [oh]
<lifeless> AfC: poolie is being very reflective ;)
<AfC> lifeless: just so long as he's not being recursive
<poolie> iow shiny
<AfC> anyway, I would have thought it wouldn't list any ignored files at all. Seeing as how it seems to ignore some (but not others) I'd say that's the bug
<spiv> poolie: (re hydrazine) interesting!  I was just realising earlier today that I can slowly read email and browse the web while holding the baby by carefully driving my laptop with my toes :)
<spiv> poolie: a mail client with good key bindings certainly helps when doing that!
<poolie> or, carefully hold the baby between your knees and type faster :)
<poolie> so i do think in principle one ought to be able to get through bug triage faster by typing than clicking
<poolie> it may even be possible on top of this
<poolie> s/on top of this/starting from the basic approach of hydrazine
<spiv> (Turns out http://en.wikipedia.org/wiki/Morton%27s_toe is not just a random mutation but a distinct advantage ;)
<lifeless> spiv: so, you and the statue of liberty huh
<JesseW__> What is the difference between a "master branch" and a "parent branch" and are there any other types of branches?
<lifeless> a master branch is the branch a bound branch synchronises with
<lifeless> a parent branch is the branch that 'pull' and 'merge' will read from by default if you don't supply a url
<poolie> spiv, can the cleanup work systematically get rid of TooManyConcurrentRequests etc?
<poolie> or could we turn them into eg a warning?
<JesseW> lifeless: thanks -- and there are no other kinds?
<Peng> It's not like they're different _types_ of branches. A branch just has e.g. "parent_location = foo" in its branch.conf.
<Peng> There are several others -- submit (bzr send's default destination), public (used as the public location by 'bzr send' and Loggerhead), and probably more.
<Peng> The stacked-on branch, if you're using stacking.
<JesseW> Peng: great, that was the sort of thing I wanted to know... so, these are effectively branch properties, that specify various relationships with other branches?  Is there a full list anywhere?
<Peng> JesseW: Dunno if there's a full list, aside from digging through the source dode. We definitely listed most of them. :P
<spiv> poolie: off the top of my head, only if we get pretty strict about replacing try/finally blocks that might issue smart requests in finallys with the more robust cleanup helpers
<JesseW> Peng: cool, thanks.
<spiv> poolie: and that's pretty hard to do short of forbidding finally: entirely in test_source
<spiv> poolie: but,
<spiv> poolie: I think the only_raises decorator that is already on unlock methods in 2.1 will have fixed the majority of cases
<spiv> poolie: so 100% seems very hard, but we may already be Good Enough
<spiv> (also, potentially except clauses could be troublesome too, so even banning finally perhaps wouldn't be sufficient)
<spiv> poolie: I'll be very interested to see how many reports of TMCR we get involving 2.1
 * igc dinner
<dholbach> hola
<dholbach> is bug 522041 known already?
<ubottu> Launchpad bug 522041 in bzr "ERROR: exceptions.TypeError: merge_text() takes exactly 2 arguments (3 given)" [Undecided,New] https://launchpad.net/bugs/522041
<Peng> Yes, and I'm 99% sure it's been fixed.
<Peng> dholbach: https://launchpad.net/bugs/515597
<ubottu> Ubuntu bug 515597 in bzr "TypeError: merge_text() takes exactly 2 arguments (3 given)" [Critical,Fix released]
<dholbach> nice, hope the fix gets into Ubuntu quickly! :)
<Peng> dholbach: Ehh, you could edit your bzr install -- it's a _really_ trivial change.
<dholbach> Peng: I'm sure I'm not the only one having the problem
<Peng> dholbach: Yeah, you're not the only one.
<Peng> If you didn't read them, the bugs say the fix will be in 2.1.0 final. I dunno when that will get into Ubuntu.
<Peng> It was also said that the bug probably isn't in 2.0, so backporting is not a concern.
<dholbach> yep, seems to be a problem "only" in ubuntu lucid and debian experimental right now
<poolie> dholbach, it may be fixed in the nightly ppa
<poolie> anyhow, good night
<mathrick> jelmer: ewww, dvorak
<mathrick> it's snake oil, don't believe it
<mathrick> malibu: have you looked at that git-based FS thing?
<marienz> woo dvorak
<idnar> dvorak ftw
<idnar> but yeah, learning a new keyboard layout is painful
<idnar> it gets easier after the first 5 layouts, though ;)
 * marienz blinks
<marienz> that is a lot of layouts
<fullermd> Well, compared to 101!, it's a pretty small sampling of the choices   :p
<idnar> I don't actually know 5 layouts; but languages get easier after the first 5, so I figure keyboard layouts should be the same ;)
<gerard_> lifeless: did you unban the guy that kept rejoining and leaving?
<slestak> somehow I have gotten to branches on lp linked.  I have a project branch that has my dotfiles repo lited as its parent
<slestak> i am sure this is soemthign I did, but I do not want to merge these two.
<slestak> could someone pls help me sep these two?
<slestak> this is the branch in question, https://code.launchpad.net/~slestak989/+junk/pt
<slestak> bzr info shows dotfiles as its parent which is not correct
<maxb> I don't think the parent of a launchpad branch actually has any meaning
<maxb> If you actually care to look for it, you can find all kinds of people's random local paths in there
<slestak> but if I try to sync my workstation to this, it will try to pull in vimrc and whatnot
<maxb> huh?
<slestak> This was not liek this on Friday, so I thought I would be able to rollback whatever transaction did this
<slestak> in the pt dir, if I do bzr missing, it says i am missing every revision in dotfiles
<maxb> The value in the launchpad branch is irrelevant for that
<maxb> It's the value in your local branch that you're running 'bzr missing' in that matters there
<slestak> so that is what I need to correct
<maxb> Just do a 'bzr pull --remember' from whatever branch you actually want
<slestak> this workign dir is actually the most receent, so I need to push.
<slestak> i wonder if this will try to push to dotfiles?
<slestak> the help for pull says it will only work for non-diverged branches.  I think these can be considered diverged.
<slestak> so try the merge to resolve diverge, or try the pull --remember?  either can be reverted right?
<fullermd> Wait...   is the actual _problem_ anything other than "this branch's 'parent' doesn't make sense"?
<fullermd> 'cuz if that's the whole problem, there's not a problem...
<slestak> fullermd: i am concerned that on my workstation, If I do bzr pull it will pull down src from lp that doesnt belong in this bracnh
<slestak> i can revert it if it doesnt work out right?  just try it and dont commit until verify?
<fullermd> Well, first off, pull won't pull unless what you're pulling is a superset of what you have (unless you --overwrite of course).  So if two branches are unrelated, pull won't do anything.
<fullermd> Second, if you're worried about the effect of the parent branch of the _branch on lp_, on anything you do locally, don't.
<slestak> but when I say bzr missing, it lists every revision for dotfiles
<fullermd> Saved locations like 'parent' (and 'push', etc) don't imply any linkage between the branches.  They just provide defaults for certain commands.
<slestak> add a -v and it shows all of my vim setup.
<slestak> I think I see what maxb was saying,  do a pull --remember to set it to the pt branch on lp i want
<fullermd> The parent branch of a branch on LP wouldn't matter.
<fullermd> Parent just sets the default for pull (and sometimes a few other commands)
<slestak> this is the parent branch on my workstation I an discussing
<fullermd> Ah.  Well, don't pull then   8-}
<fullermd> (not that it'll do anything unless the branches are related, as above)
<slestak> too late, lol
<slestak> sokay.  it did what both of you said, pulled nothing.
<slestak> and --remember did what was expected
<slestak> sorry for drama, trying to work bzr into my workflow
<igc> night all
<rubbs> night
<asac> hi ... what does "format: unnamed" mean?
<fullermd> It means there's no name for the combination of formats at the given location.
<fullermd> Try info -v for the details.
<asac> fullermd: hmm. how can that happen?
<fullermd> Oh, any number of ways.
<asac> for example?
<asac> if i merge a branch with a different format?
<asac> can i get the branch straight again ;)?
<fullermd> Branch format from upstream.  Upgrading one parts but not another.  Various combinations of formats given to init and init-repo.
<fullermd> It's not un-straight.  It's just unnamed.
<maxb> asac: The most common way it happens is when bzr 2.x combines the latest working tree format with an older branch/repo format.
<maxb> This is an unfortunate UI wart, since it obscures the interesting information unless you know to read bzr info -v and interpret it
<asac> hmm
<asac> so the problem is that i got a branch submission that i cant merge. it seems to use rich-root, but the guy did it on a recent checkout - i assume it means he ran upgrade before submission?
<fullermd> Not necessarily.  He could have branched it into an existing RR repository.
<asac> sigh
<jelmer> asac: Is there a reason you can't upgrade to 2a or another rich root format yourself?
<asac> since when does 2a exist?
<jpds> asac: karmic.
<jelmer> asac: it was introduced in bzr 2.0
<asac> right
<asac> so until hardy is eol i dont want to do that ;)
<asac> but i guess its already too late :(
<asac> since our branch somehow morphed into unnamed from pack-0.92
<fullermd> 2a isn't the only rich root format.  rich-root-pack dates to 1.0 for instance.
<jelmer> asac: alternatively you could switch to 1.0-rich-root, that's bidirectionally compatible with 2a
<jelmer> asac: that was introduced before 1.3.1 which is in hardy
<asac> thx will think about it ... but i just want to stay on pack-0.92 ... why is bzr so bad to me :(
<asac> is there a way to prevent changes to branch format on commits of a branch?
<asac> like the "always on top" ... a "never morph branch format" ?
<fullermd> Being distributed is kinda antithecal to being able to tie down what other people can do on other branches.
<asac> well i dont mind of what the peers do on their own
<asac> i just want to ensure that the online branch doesnt change his format
<jelmer> asac: fwiw you can always communicate branches in other formats freely, the only situation in which this doesn't work is from a rich root format to a non-rich-root format
<fullermd> Branches don't just change their format; somebody changes 'em.  An existing branch won't change unless you upgrade it.
<asac> right
<asac> but when i do a bzr merge lp:dirtybranch
<asac> bzr commit
<jelmer> asac: That won't upgrade your branch
<asac> and that changes my local branch format without a warning its not really an explicit decision
<asac> then how did the online firefox-3.6 branch got upgraded to unnamed?
<jelmer> asac: what's the url of that branch?
<asac> anyway ... i guess i need to live with this and hope for the best :(
<jelmer> asac: Somebody must've run bzr upgrade on it
<asac> http://launchpad.net/~mozillateam/firefox/firefox-3.6.head
<asac> i only ran bzr upgrade --pack-0.92 on it
<asac> i doubt someone else did
<fullermd> Standalone branch (format: pack-0.92)
<jelmer> asac: according to bzr info that's still pack-0.92
<asac> oh
<asac> its xulrunner-1.9.2.head
<asac> i think
<asac> heh
<asac> seems its all fine ... hell do i feel bad. sorry
<asac> let me complain to the guy that confirmed it was unnamend ;)
<jelmer> asac: it may be that when he cloned that branch locally he ended up in an "unnamed" format
<asac> probably
 * asac happy
<jelmer> asac: the "unnamed" bit is confusing indeed
<asac> so the reporter has this for  fresh checkout: http://pastebin.com/f13c46178
<asac> i have http://pastebin.com/f230277fa
<asac> in one case its Working tree format 6
<asac> (the unnamed one that is)
<fullermd> That's what you'd expect from a 2+ version of bzr.
<asac> for me its working tree format 4
<asac> fullermd: i have Bazaar (bzr) 2.1.0rc2
<asac> he has 2.0.4
<asac> seems 2.0 upgrades the working tree format to 6 while 2.1.0 doesnt
<asac> so guess that was a bug in karmic bzr?
<asac> thats 2.0.4
<fullermd> No, 2.1 does it too.
<asac> why not for me?
<asac> 15:51 < asac> i have http://pastebin.com/f230277fa
<fullermd> Because you're using http; it's preserving it over that.
<asac> thats bzr info -v
<asac> omg
<fullermd> Probably some side effect of the format hiding over the smart server.  Dunno.
<fullermd> Anyway, WT format doesn't matter anywhere except locally.
 * asac happy that thats the case
<asac> you are right
<asac> over ssh i get the unnamed thing
 * asac scared
<asac> ok thanks
<guilhembi> I'm doing "bzr check -v" on a shared repository (which should take 40 hours), I wonder if -vv would have given interesting info? Or is -v ok?
<maxb> I thought bzr's -v was just on/off, not level based?
<guilhembi> ah, maybe... :-)
<guilhembi> ok, I'll see after 40 hours.
<fullermd> I'm not sure -v does anything on check anyway...
<henninge> Are there any plans or is anybody working on providing context managers for Tree locks?
<jelmer> henninge: I'm not aware of any plans.
<henninge> I just implemented one locally in a Launchpad branch and thought this should really be in Tree code.
<henninge> jelmer: I am not too familiar with the class structure in bzr but is Tree the class that implementes the locking?
 * henninge goes to browse bzr code.
<jelmer> henninge: no - a Branch, Repository and Tree are all three lockable but they call out to another class to worry about the actual locks
<henninge> ok, now I remember reading the tree locks use branch locks.
<henninge> jelmer: should I file a bug about it to start with?
<jelmer> henninge, please do
<henninge> cool
<henninge> jelmer: https://bugs.edge.launchpad.net/bzr/+bug/522195
<ubottu> Ubuntu bug 522195 in bzr "bzrlib should provide context managers for locking" [Undecided,New]
<jelmer> henninge-afk, thanks
<Azag> hi
<Azag> how I can set a branch as default branch?
<Kinnison> Do you mean on launchpad?
<Azag> yes
<Kinnison> IIRC you set it as the development focus
<Kinnison> visit the project page and click "edit details"
<Kinnison> scroll to near the bottom
<Kinnison> see the dev focus dropdown?
<Kinnison> select something from there
<Kinnison> That should do it
<Azag> in that part
<Azag> show
<Azag> Development focus:
<Azag> <my_project-name> trunck
<Azag> but when I try: bzr co lp:<my-project> it say me that there is not default branch
<Kinnison> What is your package project called?
 * Kinnison will look
<Azag> Kinnison: shareit-server
<james_w> Azag: go to https://code.launchpad.net/<my-project> and there should be a link you can click to set the branch for htat
<Azag> I see
<Azag> thnx
<Kinnison> cool
<Azag> jeje, I was looking in the worng page
<Azag> thanks Kinnison and james_w
<Azag> :)
<Kinnison> tbf, it's not completely obvious to me because all my projects already have focusses :-)
<Azag> how I can download a bzr branch without a rsa directory
<Azag> Warning: Permanently added 'bazaar.launchpad.net,91.189.90.11' (RSA) to the list of known hosts.
<Azag> Permission denied (publickey).
<Azag> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<Azag>  
<mwhudson> jelmer: test_log_verbose (bzrlib.plugins.git.tests.test_blackbox.TestGitBlackBox) just errored for me, is this bzr's fault?
<mwhudson> bah
<jelmer> mwhudson, no idea - what's the error exactyl?
<mwhudson> jelmer: http://pastebin.ubuntu.com/377039/
<jelmer> mwhudson, ah
<jelmer> mwhudson, that's a bzr bug
<mwhudson> ok
<jelmer> mwhudson, I submitted a merge request for it, not sure what the current status is
<mwhudson> jelmer: shoving this information about how many revisions to import through all the layers is no real fun :/
<lifeless> gerard_1: thanks
<gerard_> lifeless: I was happy to remember it ;)
<lifeless> james_w: ping, bzr-builder ppa watching; hows that going? [I'm sure its a case of ETIME
<lifeless> :)]
<__monty__> Could someone have a look at this, the last comment in particular?
<__monty__> *https://code.launchpad.net/~toonn/bzr/no-repo-error-message/+merge/17039 This of course. (forgot the link)
<aleksander_m> hi all. Can anyone tell me why the shared-repository (bzr init-repo PROJECT) is needed when using the distributed development approach?
<fullermd> It's not strictly needed.  It's useful for saving space when you [would otherwise] have multiple copies of the same history.
<aleksander_m> fullermod: humm.. what do you mean?
<lifeless> fullermd: might be clearer to say its optional
<lifeless> aleksander_m: its optional; shared repository lets multiple branches reuse the same storage database ('repository')
<aleksander_m> aha, understood
<aleksander_m> another question... when using bzr push to publish commits in the main branch, it happened to me that one of my colleagues didn't do a pull in the mirror branch first, so he pushed his changes but overwrote already pushed changes... is there any way to avoid this?
<fullermd> It wouldn't discard other existing changes unless he did push --overwrite; that requires intention.
<fullermd> Or do you mean that the existing changes are now showing up in a merge, rather than on mainline like they previously were?
<aleksander_m> hum.... you got me
<aleksander_m> can't remember
<fullermd> Look at `bzr log -n0`.  If the already-pushed changes you're thinking are overwritten show up in some of the indented revs, it's the latter case.
<fullermd> If the problem is actually the former...  smack your colleague around for using --overwrite   :)
<fullermd> Either situation can also be prevented by setting a branch config option to preserve the mainline.  I'll remember what it's called in a second...
<fullermd> append_revisions_only I think?
<fullermd> Yeah, that's it.
<aleksander_m> will take a look at it
<aleksander_m> fullermod: thanks
<aleksander_m> s\fullermod\fullermd
<lifeless> james_w: hi
<james_w> hi lifeless
<lifeless> james_w: did you see my ping about builder?
<james_w> I did
<james_w> it's still on my list
<lifeless> kk
<james_w> I have spent time on it
<james_w> I'm just not happy with some of the interaction that the oauth stuff forces on the user
<james_w> so I'm thinking of better ways to structure it
<lifeless> ok. if you want a sounding board let me know
<james_w> for instance, it only checks whether it has the needed credentials right at the end, after it has gone through the process of building etc.
<james_w> and I don't think it should open a webbrowser if it doesn't have the credentials then wait forever for response, as that doesn't fit well with some situations it is expected to be used in
<lifeless> james_w: I can see the concern, however it only happens when someone uses this option :)
<james_w> that's true, but I don't think they should be punished for using it :-)
<poolie> hello lifeless
<lifeless> hi poolie
<lifeless> james_w: neither do I
<lifeless> james_w: but I've learnt to be wary about overgeneralising UI problems
<james_w> yes
<shakaran> hi, I use Lucid, and I can't install bzr-svn: http://pastebin.com/d3e9b5fe4
<mkanat> mwhudson: ping. Any info about the hangs?
<mwhudson> mkanat: no
<mwhudson> not yet
<mkanat> mwhudson: Okay. Why did I think that they weren't happening anymore?
<mwhudson> well, they are significantly less frequent
<mwhudson> now
<mwhudson> so you have to wait a while to get the full picture
<mkanat> mwhudson: Okay. Francis said it was every 3 days?
<mwhudson> on average
<mkanat> mwhudson: Okay.
<mwhudson> there was a crash last night, but i'm not sure if the admin did the stack trace thingy
<mwhudson> (which i had to rewrite last week, fun)
<mkanat> mwhudson: Ahhh.
<mkanat> mwhudson: Are the hang logs similar to the last one you showed me, where there are several minutes of nothing in the log, before the restart?
<mwhudson> mkanat: i don't know
<mkanat> mwhudson: Okay. Do the LOSAs know to get the stack trace the next time the process hangs?
<mwhudson> mkanat: i hope so
<mwhudson> mkanat: i'm on the phone and have been for a while, i'm not completely ignoring you :-)
<mkanat> mwhudson: Ahh, okay. :-) I think I commented on the bug about it several weeks ago, but I haven't gotten a stack trace since then, so I assume that some other form of communication is required?
<mwhudson> mkanat: welcome to life in a distributed company!
<mkanat> mwhudson: Well, yeah, I'm familiar with it from all the years of working with Mozilla. :-) I assume that the "follow the official process and then also ping people on IRC" solution is similar? :-)
<mwhudson> mkanat: yes
<mkanat> Okay. :-)
<mkanat> losa ping ? :-)
<mwhudson> mkanat: ideally we want codebrowse to fall over when i'm working
<lifeless> mwhudson: well
<lifeless> mwhudson: I beg to differ ;)
<mwhudson> lifeless: in a very particular way of course
<lifeless> Ideally no fall overs at all:)
<lifeless> we want it to learn to run
<igc> morning
<igc> hi lifeless
<lifeless> hi igc
#bzr 2010-02-16
<poolie> jelmer: thanks for lending your delete key
<jelmer> poolie: fewer functions on Repository means I have to implement fewer functions in the foreign branch plugins :-)
<poolie> jelmer: are you coming to UDS?
<jelmer> poolie: yep
<linuxcomputacion> hi
<linuxcomputacion> a have an error Not a branch what does it mean
<doctormo> How can I lock a branch for testing?
<spiv> linuxcomputacion: the location you specified isn't a branch.  It might be a shared repository (but not a branch in that repository), or it might simply be an empty directory somewhere, etc.
<spiv> doctormo: python -c 'from bzrlib.bzrdir import BzrDir; b = BzrDir.open('path/to/branch').open_branch(); b.lock_write(); b.leave_lock_in_place()"
<doctormo> thanks spiv
<doctormo> And you've probably given me the answer to getting rid of the lock too
<doctormo> https://bugs.launchpad.net/groundcontrol/+bug/519627
<ubottu> Ubuntu bug 519627 in groundcontrol "Need method to detect and break bzr locks" [Medium,Confirmed]
<spiv> doctormo: to break a lock, I'd look at how cmd_break_lock does it
<doctormo> spiv: I might as well just call that builtin right?
<spiv> doctormo: maybe, although it's an interactive command, so maybe no
<doctormo> spiv: I've got the thing tied up to gtk, depends on if the command uses the ui factory
<spiv> It should
<spiv> If not, file bugs :)
<doctormo> spiv: I can't seem to lock my branch using your code
<doctormo> spiv: When I run b.lock_write() it waits for self.wait_lock() (sleeps)
<poolie> doctormo: isn't there a .peek method already?
<doctormo> poolie: Not that I'd know how to use it
<doctormo> spiv: It might be locking and then when the program ends, it's unlocking
<doctormo> So even when I let my little lock script lock the branch, my problem still detects no lock
<doctormo> Is it not possible to lock a bazaar branch?
<doctormo> huh, so the branch _is locked_ in that the commit just waits around for the lock to go, but branch.is_locked() always returns False.
<doctormo> Ah I think I worked it out, get_physical_lock_status is the real thing
<spiv> doctormo: if it's sleeping in wait_lock, then there's already a lock on disk
<doctormo> spiv: I understnad
<spiv> doctormo: also, you *might* find that doing bzrlib.lockdir._DEFAULT_TIMEOUT_SECONDS = 0 is convenient
 * spiv wanders off
<igc> lifeless, spiv, poolie: if I have a corrupt dirstate file following a power failure, can I just delete it?
<lifeless> not much else you can do :P
<lifeless> you using ext4?
<igc> no
<lifeless> I have an idea
<doctormo> Hey guys
<doctormo> So I've got a lightweight checkout of my code and when I try a bzr pull I get:
<doctormo> Using saved parent location: bzr+ssh://bazaar.launchpad.net/~groundcontrollers/nautilus-lp/trunk/
<doctormo> When it was checked out from: Using saved parent location: bzr+ssh://bazaar.launchpad.net/~groundcontrollers/groundcontrol/trunk/
<bob2> pulling uses the parent
<doctormo> For some reason it seems to have saved the old launchpad project name somewhere
<bob2> you probably want 'bzr up'
<eydaimon> hi, i'm moving my files to a new repo on our server. A new repo was made on the server, I've check out the repo, and I tried doing a bzr merge on the empty repo to all my stuff. WHen I do the merge, all changes are applied successfully, but when I do a bzr st, I get 'working tree is out of date, run 'bzr update'' then it lists files which have been renamed. and then if I try to bzr revert, I get an error:
<eydaimon> bzr: ERROR: exceptions.ValueError: Cannot have multiple roots.
<eydaimon> how can I do what I'm trying to do?
<bob2> do you mean branch, when you say repo?
<poolie> igc, you can fix (or vote for) the bug asking for an easier way to recreate it :)
<bob2> are you trying to merge multiple branches in to one branch?
<igc> poolie: :-)
<eydaimon> bob2: the admin did a bzr init on a remote machine. I did a co on that branch. now I'm trying to get all my local change sinto that branch
<eydaimon> well, not my local changes to that branhc, but yes, my changes from another branch I guess
<bob2> that's probably not what you want
<eydaimon> so how can I get all my commit history for what I've done?
<eydaimon> (I did my own bzr init locally and was working there until someone set that up)
<bob2> cd yourcode  ; bzr push sftp://server/path/to/empty/branch
<eydaimon> thank you much :)
<eydaimon> sftp too? not ssh+bzr?
<bob2> whatever
<bob2> undo what you've done, first
<eydaimon> yeah, I've done nothing to my code, so that's easy
<bob2> have you done anything to the remote branch?
<eydaimon> ok, that worked very nicely :)
<eydaimon> no, I had only been trying to check it out
<eydaimon> so it was completely empty
<eydaimon> and the push worked great
<eydaimon> thanks again. I appriciate the help
<poolie> igc could you answer https://answers.edge.launchpad.net/bzr/+question/99465 and maybe some other open questions some time?
<igc> poolie: I'll take a look
<lifeless> poolie: I need a teddy bear; can you supply ?
<poolie> lifeless: ok
<lifeless> is now ok ? (voice)
<poolie> sure, call
 * lifeless sees if he remembers the #
<AfC> lifeless: here you go. Teddy bear, fixing everything. http://indiequill.files.wordpress.com/2009/04/teddy-bear.jpg
<dholbach> hiya
<dholbach> should bzr depends on python-testtools?
<dholbach> I got "bzr: ERROR: No module names testtools" when I tried to push to sftp://
<bialix> igc: ping
<bialix> hmm
<james_w> dholbach: it's a bug that it currently requires that
<james_w> dholbach: the workaround is to install it
<dholbach> ok :)
 * dholbach can live with that
<maxb> When is 2.1 final coming out, anyway?
<jelmer> 'morning
<Laibcoms> Q: Is there a way to preserve the date/time of the files during first branching? Ex. I'm branching/pulling from a trunk, but the files saved on my Linux is my local system time. So now if I use like Bzr Explorer, it tells me "Working tree differs from revision XXX", the diff is only the date/time of all files.
<jelmer> Laibcoms: that seems like a bug - it should also be checking the file contents
<mwhudson> jelmer: hi, i'd like to talk to you more about incremental imports, but i'm too tired i guess
<jelmer> mwhudson: hey
<jelmer> mwhudson: I think I'll be around on IRC during your morning
<Laibcoms> jelmer: The diff works (if I edit a file, it shows the changed lines). But I haven't started editing files yet, so it's only reporting that my pull is different because of the date/time.
<mwhudson> jelmer: that'd be great, i'll try to get up on time :)
<Laibcoms> oh, just noticed, maybe this is what triggered it: "(properties changed: -x to +x)"
<jelmer> mwhudson: :-)
<jelmer> Laibcoms: that would explain why the file is being marked as modified
<Laibcoms> jelmer: yep. But should it do that or something?  Hmm.. I'll give it a try via WinXP then see if I pull via Ubuntu again there'll be a properties change.  Tnx tnx!
<jelmer> Laibcoms, it means you have changed the permissions on the file
<jelmer> Laibcoms, the executable bit is now set whereas it wasn't earlier
<fullermd> Or alternately you're on a non-*nix filesystem that fakes them from not actually having +/-x itself.
<Laibcoms> fullermd: ahh! That explains it, my local repo is on my larger partition w/c is NTFS.
<Laibcoms> jelmer, fullermd thanks thanks!!
<jelmer> Laibcoms, we could probably detect that the fs doesn't support executable bits and Do The Right Thing
<Laibcoms> ahh
<jelmer> lifeless, ping
<Laibcoms> btw, should I file a suggestion for that -- +/- detection, or no need?
<jelmer> Laibcoms: please do
<jelmer> Laibcoms: at the moment I think we ignore the executable bit on just windows, but that really should be on any filesystem that doesn't support the executable bit (which includes all filesystems supported by windows)
<Laibcoms> jelmer: ahh ic.  ok, I'll enter it as a suggestion.  Thanks again ^^
<fullermd> It's sort of a specific case of behavior varying by FS, that we approximate by OS.
<fullermd> I think on Windows we also try to do a little more handling (if only at the "fail gracefully" level) of case-insensitive issues, for instance, but that's really depending on the FS rather than the OS.
<fullermd> (or maybe we don't, and I'm imagining things.  Always a possibility)
<jelmer> fullermd: we should distinguish between fs'es supporting the executable bit and case-insensitive/case-preserving file systems
<fullermd> Also, we should have a pony  8-}
<bialix> fullermd: there is case-insensitive fs check
<soren> How long does the test suite roughly take to run?
<soren> Hours?
 * jam peeks around for the current LOSA
<mthaddon> in a meeting at the moment - will be with you after that
* jam 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 has gone gold, time to build installers!
<jam> mthaddon: no rush, but eventually I'll need an 'lp:bzr/2.2' branch created and have it registered with pqm so we can start making 2.2 series releases.
<mthaddon> jam: have you filed an RT about that?
<jam> I have not
<fullermd> A 2.2 branch?  I'd think we'd just cut off trunk 'till RC-stage...
<jam> fullermd: we keep a dev branch so that I can take a day or two to make a release without blocking trunk
 * fullermd submits the ports update.
<fullermd> Always interesting seeing how much of the packing list changes every release are under tests/   :)
<brettalton> does anyone know if it is possible to start a new branch and make a commit from 2003 (for example)?
<brettalton> I've never used a vcs before but have revisions of some websites dating back to 2003 and I want to make a branch that has all that historical data in it
<fullermd> The commit command has a --commit-time arg (at least in recent enough versions)
<brettalton> so if I were to make an initial commit, I could get it to be set at 20031202 12:01 +0500 and then do it subsequently for all my other commits, working backwards all the way up to today?
<fullermd> Yah (assuming you actually have a 1-minute granularity on your old revs of course ;)
<fullermd> You'll want to check 'stat' in between commits, to catch any new or moved files and make sure they're recorded right of course.
 * fullermd scampers off for a bit.
<brettalton> fullermd: hmm, okay. I see this was recently recreated in 2.1 and will only be available in Lucid (re: https://bugs.edge.launchpad.net/bzr/+bug/459276)
<ubottu> Ubuntu bug 459276 in bzr "user specified commit date" [Low,Fix released]
<brettalton> so I'll have to upgrade to Lucid to do this
<brettalton> I wish there was an easier way instead of using stat on all 50 directories/revisions I have... some folders will be complete rewrites and will require adding hundreds of files
<jam> mthaddon, or some other losa: I opened rt #37561 for the request for another pqm branch of bzr
<mbarnett> jam: ok, once that makes its way into our queue, we'll attack.
<LeoNerd> GRRR...   bzr di --diff-options="-C 1"  => shows two chunks. This is good. I want to shelve one but not the other.
<LeoNerd> bzr shelve --diff-options  =>  doesn't understand --diff-options.  without said option, shows only one chunk.
<mwhudson> hmm, no jelmer
 * LeoNerd solves by  bzr di ... >patch.diff; vim patch.diff; patch -R <patch.diff; bzr ci; patch <patch.diff
<fullermd> Hm, funny.  bzr 2.1.0 cut today.  Parrot 2.1.0 released today.
<fullermd> COINCIDENCE?!
 * Tak head explode
<mwhudson> fullermd: i'm having trouble with my conspiracy theory generator here
<lifeless> fullermd: its all about the pigeons
<fullermd> Man, the pigeons are just tools of the finch hegemony.  It's ALL connected!
<Tak> via farcaster?
<elh4z> hi
<elh4z> how can i ignore a file without have to remove it from the central repo?
<elh4z> i try remove --keep, but it remove it.
<Pilky> elh4z: why do you want to ignore it?
<elh4z> is a config file.
<elh4z> has parameters for the db connection.
<Pilky> hmm, not sure how you'd do that then
<elh4z> uhmm is simple..
<elh4z> you have a config file, an commit it to the central repo.
<elh4z> but, what happen if other person checkout ?? then the config file updated.. and I have to re edit it.
<elh4z> if that person edit it, he have to commit it, then i have re edit it again..
<elh4z> over and over again...
<Pilky> yeah I'm meaning I'm not sure how you can have it so that one file isn't checked out
<Pilky> the only thing I can suggest is put the config file in a separate branch
<Pilky> others might be able to offer better suggestions
<elh4z> uh.. thanks ;)
<elh4z> but i have to merge over and over again, no??
<mtaylor> elh4z: I usually make a file called "config.template" or something, and the idea is that you check out the branch, then copy config.template to config and use that locally
<mtaylor> elh4z: or that you have something like configure or setup.py do that for you... my.config.in can go in the tree, but running configure fills my.config with values and leaves my.config.in untouched
<elh4z> uhmm good suggest.
<elh4z> but would be not good something like ignore without remove??
<elh4z> I mean.. i have rename over and over agan config files :P
<AfC> Is the equivalent of the push-and-update plugin now available in Bazaar core?
<lifeless> AfC: no, if you want that install the plugin
<jelmer> mwhudson, 'morning
<jelmer> hey lifeless
<lifeless> hi jelmer you pung
<mwhudson> jelmer: hi!
<jelmer> lifeless: I was wondering if you saw the merge requests I put up for bzr-dbus
<lifeless> nope
<AfC> lifeless: ok. Seems like it could be a simple option to push; surely bzr could pass it along its network protocol rather than having to set up a second SSH connection.
<jelmer> lifeless: one adds more laziness, the other adds support for zeitgeist
<jelmer> lifeless: I can provide links if you like, or whatever helps :-)
<lifeless> AfC: if you're using the smart protocol you can write a hook to sit on the server and do it for you
<jam> morning lifeless
<lifeless> AfC: and there is no ui for dealing with conflicts, which is one of the major reasons we don't do it by default anyway - that hasn't changed
<jelmer> mwhudson: should we talk about incremental imports?
<lifeless> hi jam
<mwhudson> jelmer: yes please
<lifeless> jelmer: link me up
<mwhudson> jelmer: here or skype?
<jelmer> lifeless: https://code.edge.launchpad.net/~jelmer/bzr-dbus/lazy/+merge/19002 is the lazy import one
<jelmer> lifeless, https://code.edge.launchpad.net/~jelmer/bzr-dbus/zeitgeist/+merge/19120 is zeitgeist
<AfC> lifeless: right, so if there are conflicts and that option is selected, then the push should fail. Wouldn't that be reasonable?
<jelmer> mwhudson: skype ? Good moment to see if the skype support in my N900 actually works :-)
<AfC> lifeless: but for the common case of pushing to a branch which is a [public] mirror of one of your own branches, there will never be conflicts.
<mwhudson> jelmer: heh heh heh
<mwhudson> jelmer: i'm michael.w.hudson
<jelmer> mwhudson, I'm jvernooij
<lifeless> AfC: actually there can be, in that common case - e.g. .pyc files
<jam> lifeless: testing question. for 'expectFailure(reason, assertion)' if the assertion succeeds, should expectFailure consider that an error?
<AfC> why would there be .pyc files in a Branch? Oh, like if someone is using that to push their website. Hm
<AfC> Well, it still leaves people who are trying to publish Bazaar branches out in the cold
<lifeless> jam: yes
<AfC> which is a bit of a letdown, since the whole "hey, you can just serve your branch with an HTTP server, and hey here are the files!" thing was a big seller for Bazaar early on
<lifeless> AfC: so the common case is something like dreamhost
<jam> lifeless: ok, it seems we regressed here. Testtools 0.9.2 tries to call addUnexpectedSuccess, but if that member isn't available, it calls addSuccess
<lifeless> where we suggest the 'bzr upload' plugin in fact
<lifeless> jam: and we have a result without addUnexpectedSuccess?
<jam> lifeless: I believe so
<AfC> lifeless: right, and since we recommend the upload plugin for the "run my website" case, why can't bzr push update the remote checkout?
<jam> I tested it, and expectedFailure silently succeeds
<lifeless> jam: so, find that result and we should fix it ;)
<jam> lifeless: but is this a bug in testtools, or bzr?
<lifeless> jam: almost certainly bzr
<jam> Certainly we can work around it in bzr
<jam> but doesn't it seem that the default UnexpectedSuccess action would be Failure ?
<lifeless> jam: by workaround you mean 'implement addUnexpectedSuccess'
<jam> lifeless: I'm saying the default behavior of testtools is wrong, but we can use the hook provided to get our own result
<lifeless> jam: I'm saying that even if the default is wrong, we should implement that method anyhow.
<lifeless> even if the default was right. That its orthogonal.
<jam> lifeless: well, given that it will just thunk over to addFailure, I don't see a specific need to have it
<jam> but we can
<lifeless> AfC: a few thoughts: we can't consistently do it efficiently (sftp). We don't have a UI for resolving conflicts in this case, so people will be unable to push further. We can't take out the right locks in some cases (sftp). Remote branches rarely have trees at all.
<lifeless> jam: I don't know that a hard failure is the right behaviour; certainly we'd want to know about it though.
<lifeless> jam: so I do agree that the current outcome is not good.
<lifeless> jam: as for why addU..S.. goes to addSuccess, there isn't a backtrace available, and it seemed to make sense at the time.
<RenatoSilva> does Canonical candidate for Google SoC?
<jam> lifeless: so, to complete this, 'addFailure' wants to have an 'err' which seems to be the value of sys.exc_info()
<jam> which was computed earlier when UnexpectedSuccess was raised
<jam> should I just pass None, though?
<jam> (since addUnexpectedSuccess does not take an 'err' parameter)
<lifeless> jam: well, the signature for addFailure should be (self, test, err, details=None)
<AfC> lifeless: fair enough. I can't help but note that the push and update plugin manages all that fine though sadly inefficiently. Oh well. I give up
<jam> lifeless: our addFailure has no details param
<lifeless> jam: you may be seeing unmigrated code; and passing None will probably lead to explosions
<lifeless> AfC: having inefficient things in the core is a problem!
<lifeless> AfC: also it doesn't manage all of those things, but if it does what you need I'm very glad.
<jam> lifeless: I tracked down what I could, and at least testtools as an "if err is not None: #pass to unittest"
<lifeless> jam: testtools has a details parameter too though, which is where it starts supporting err as None
<lifeless> if details is a dict
<AfC> lifeless: I've never once had a problem with it. I just wish it was a smart-server verb instead of a kludge to run a second external SSH process.
<AfC> lifeless: I'm probably going to switch back to using rsync to publish Bazaar branches, so I guess it won't matter anymore
<lifeless> AfC: if you ask nicely jam might update it to provide a hook so the server can do it for you
<jam> AfC: it would be possible for the plugin to provide a smart server verb, and require that you install it on both sides
<lifeless> AfC: really? won't rsync be slower?
<AfC> jam: "and require" <- hence my wishing it was in core!
<jam> AfC: well, you have to install it locally as well
<jam> and it would at least provide a proving grounds before we wanted to land it in core
<lifeless> jam: could use a post tip change
<lifeless> jam: and if chrooted activate then
<jam> lifeless: you mean server-side only hook, right?
<lifeless> essentially
<lifeless> using the server chrooting facility as a 'am I server side' check
<AfC> lifeless: probably not; it'd only be one ssh connection instead of two
<jam> AfC: though if the pack files aren't identical you'll get *way* too much transfer
<jam> and rsync doesn't send data in the transaction safe way
<jam> but as long as you push again, you'll eventually converge
<AfC> (I find myself rather frequently with "oh shit, gotta get up off the train" and waiting, waiting, waiting for push [-and-update] to finish. So it keeps being a sore spot for me)
<jam> and as long as you only publish from 1 location
<RenatoSilva> verterok: hi
<AfC> (plus forgetting that I installed in once 2 years ago and forgot about it, only to discover that it wasn't on new machine, so URLs to code I was giving out were not showing updated code. No end of embarassment)
<RenatoSilva> verterok: have you ever participated in Google SoC?
<verterok> RenatoSilva: hi
<verterok> RenatoSilva: no
<RenatoSilva> verterok: bzr-eclipse is a good candidate project :)
<AfC> jam: it's just a public publish mirror of my branch, so there's nothing happening there that isn't happening here
<AfC> though, if I have to go down this road, I'm more likely to do something like source-highlight the code locally and then rsync the lot up. That'd be pretty
<verterok> RenatoSilva: heh, it might be
<jam> igc: let me know what the final URLs for the CHM docs are
<jam> I'll wait to build the windows installers until you tell me
<RenatoSilva> verterok: we could mentor some student on coding bzr-xmloutput, bzr-java-lib, and bzr-eclipse towards releasing bzr-eclipse 1.0
<verterok> RenatoSilva: I can't participate, but I'ld be glad to help with it
<jam> I have to go for ~30min, bbiab
<verterok> RenatoSilva: indeed
<RenatoSilva> verterok: not having a really stable, working eclipse plugin for bzr is the only reason I don't talk to my co-workers to migrate from CVS to bzr :)
<verterok> RenatoSilva: oh, that's bad indeed :(
<verterok> RenatoSilva: I'ld like to spend more time hacking on bzr-eclipse...
<verterok> RenatoSilva: I need to finish testing the bundle-bzr-plugins branch on windows, with that it's a step closer to the next stable release
<verterok> RenatoSilva: external bzr-xmloutput proved to be a pain
<RenatoSilva> verterok: because of not being sure what version is installed?
<lifeless> AfC: you could run loggerhead, it has code highlighting via pygments
<verterok> RenatoSilva: yes, and because it make it simple to control the dependencies, we could even require a set of bzr versions
<verterok> RenatoSilva: e.g: this bzr-eclipse release work with bzr 1.9.x and 2.0.x, but <= 1.8 or >0 2.1 isn't supported
<jelmer> lifeless, VWS?
<lifeless> vertical white space
<lifeless> 'delete the empty line you put within that function'
<RenatoSilva> verterok: I have never participated in GSoC, but if I find a way, and one or more students interested/~skilled, can I contact you later?
<verterok> RenatoSilva: sure
<RenatoSilva> verterok: I don't have much time  too, but coding is for students, having ideas and telling what to do (and review code) is for us :)
<verterok> RenatoSilva: :)
<RenatoSilva> verterok: it's $500 for the project
<verterok> RenatoSilva: if "later" means today, I'll leave to play soccer in ~1h but be back online later tonight
<jelmer> lifeless: Ahh.. Fixed 'n pushed. Thanks for the review.
<jelmer> lifeless, What do you think about having the zeitgeist support live in the dbus plugin?
<RenatoSilva> verterok: in which stage is that project (forgot the name) which would allow to switch from java + bzr.exe to bzr lib?
<lifeless> jelmer: conceptually fine; needs copyright assignment, and I don't see why you hook commit when tip change is already hooked.
<RenatoSilva> verterok: not today, but don't worry, I send memos if you're offline
<RenatoSilva> s/too/either
<verterok> RenatoSilva: :)
<verterok> RenatoSilva: jython?
<verterok> RenatoSilva: there is still a lot work to do to make bzr + jython work
<jelmer> lifeless: there is a post branch tip change hook, not a post commit hook
<jelmer> lifeless: we don't want the zeitgeist plugin to trigger on push/pull finishing
<lifeless> jelmer: commits involve the branch tip changing
<lifeless> jelmer: why not ?
<jelmer> lifeless: because zeitgeist keeps a log of the actions of the local user
<lifeless> yes
<verterok> RenatoSilva: one of the biggest issues are missing CPython modules in jython
<verterok> RenatoSilva: the other option is to implement bzr in Java...
 * verterok hides
<verterok> :)
<jelmer> lifeless: the commits that local user pulls are not made by them, and should not show up in the log
<lifeless> jelmer: but its an action ('I pulled'), why shouldn't that show up?
<lifeless> jelmer: (and you could filter those out if you want by checking the committer/author)
<RenatoSilva> verterok: I think I mean CPython
<jelmer> lifeless: They pulled a lot of commits, not just the tip
<lifeless> jelmer: yes, however the 'action' was 'pulled a branch'
<jelmer> lifeless: if we would log those actions (push/pull) we should log them as actions on the branch
<lifeless> jelmer: right, thats what I'm proposing.
<RenatoSilva> verterok: it would be *really* nice to get the c modules ported to jython, correct me if I'm wrong but I think that would be a new era for bzr-eclipse
<RenatoSilva> verterok: I mean, talk directly to bzr-lib
<verterok> RenatoSilva: indeed, it will make all so much simple
<verterok> RenatoSilva: I'm seriously thinking of other way to do the bzr-java-lib <-> bzr communication, without using xml (nor xmlrpc but this is a detail)
<verterok> RenatoSilva: I mean, leave xmloutput as is, and work on a rpc plugin just for bzr-java-lib or any other non-pyhton lib that wants to talk with bzr, but without the xml overhead and complexity
<RenatoSilva> verterok: a new bzr plugin using rpc and some non-xml format?
<verterok> RenatoSilva: yes, the rpc could be xmlrpc or any other...but it's just crazy talking :)
<RenatoSilva> verterok: I like crazy talking :)
<RenatoSilva> verterok: but do you have any other format in mind? the overhead of xml is just parsing right
<verterok> RenatoSilva: and building it :)
<RenatoSilva> verterok: yes, mapping it to an object... have you ever tried xstream? maybe not suitable in this case but
<verterok> RenatoSilva: yes, I used it a while back
<RenatoSilva> verterok:  how about json? or maybe a custom format more easily parseable...
<verterok> RenatoSilva: yes, json is an option
<RenatoSilva> verterok: any chance of any "bzr jython edition"?
<RenatoSilva> ^^^
<verterok> RenatoSilva: not in the short term
<verterok> RenatoSilva: I need to pull the latest changes from jython trunk and see how it goes
<verterok> RenatoSilva: one of the big issues is missing OSLocks
<verterok> RenatoSilva: but I think it could be made using java.nio
<RenatoSilva> verterok: by jython edition I mean remove the C stuff, and replace with python code, do you think it would make things too much slower, unusable?
<verterok> RenatoSilva: bzr already have python fallbacks for all C/pyrex stuff
<verterok> RenatoSilva: the issue are missing modules in jython, or modules that aren't going to be implemented in jython
<RenatoSilva> verterok: but if jython misses the modules, bzr will use the fallbacks, right? so no problem in this part, right?
<lifeless> we only have fallbacks for the C modules we provide
<lifeless> ones CPython provides we don't.
<verterok> RenatoSilva: ^
<verterok> lifeless: :)
<igc> morning
<igc> poolie: can you take a look at the cron job for refreshing the main website ...
<igc> my edits from yesterday still haven't come through for some reason
<RenatoSilva> verterok: do you think that fallbacking CPython would make things considerably slow?
<lifeless> yes
<RenatoSilva> ok
<lifeless> it may also push memory use way up
<verterok> RenatoSilva: don't really know, but even if it's slower, it will be less fragile
<RenatoSilva> verterok: fragile == less risky?
<jelmer> lifeless: in that case, I think that makes sense but it's something I'd rather defer until later
<RenatoSilva> verterok: the ports to jython would be written in Java? or JNI + C?
<verterok> RenatoSilva: currently bzr-eclipse has a lot of moving parts, my in-progress branch to bundle xmloutput with bzr-eclipse should help with that
<RenatoSilva> verterok: moving?
<poolie> ok igc
<poolie> hello jam
<jelmer> lifeless, since we'd have to distinguish between commits from the user and branch actions and have a way to filter the latter out in the gnome ui
<verterok> RenatoSilva: bzr-java-lib, bzr-xmloutput and bzr itself
<jam> hi poolie
<jelmer> 'morning igc, jam, poolie
<verterok> RenatoSilva: and all the combinations between them :)
<igc> hi jelmer, jam
<jam> ah the N-way communications problem :)
<poolie> :)
<poolie> jam, you had a holiday yesterday i think?
<poolie> i felt lonely :)
<jam> igc: I saw that you were going to rebuild the docs, did that finish?
<poolie> vila is away too
<RenatoSilva> verterok: you want to bundle bzr executable too?
<jam> poolie: yeah, holiday. very lonely here today w/o vila
<fullermd> It was quiet.  Peaceful-like.
<verterok> RenatoSilva: no
<RenatoSilva> verterok: and python interpreter? :)
<jam> all of you don't show up until late
<verterok> RenatoSilva: :)
<verterok> RenatoSilva: other possiblity is to keep using the current approach, and work on a better rpc service
<verterok> RenatoSilva: the current implementation doesn't handle log very well, it just load the whole history in memory and the send it over the wire
<verterok> RenatoSilva: also authentication is missing, no way to prompt for a password
<verterok> RenatoSilva: there are a lot of stuff to fix/find a solution :)
<jam> poolie: do you want to do a call tomorrow? I know we missed yesterday, and it is getting a bit late today
<poolie> how about just ten minutes/
<poolie> fullermd: not silent, just different
<RenatoSilva> verterok: nice, if we could get into GSoC, you (mainly) could create a todo list, bundle them in "goals" or "blueprints" and have the students working on it
<poolie> jam i'm trying to get through but your robot doorbitch won't let me in :/
<igc> jam: the chm rebuilds are done - uploading now
<RenatoSilva> verterok: no idea if we could get a bzr-eclipse really-1.0, but it would still be 3 months of code progress
<jam> poolie: sure, you can do my cell if it is easier
<RenatoSilva> verterok: I could help with code review and keep more in touch with the student etc, while you would be the "master" guy :)
<verterok> RenatoSilva: yeap, sounds like a plan :)
<verterok> RenatoSilva: I need to run, but be back later
 * verterok is out
<RenatoSilva> does bzr use too many / complex CPython modules?
<lifeless> bzip2, zlib, re offhand
<RenatoSilva> lifeless: so if ~ these 3 libs get ported to jython, that would be enougth for accessing bzr-lib from Java code?
<lifeless> maybe
<lifeless> you should try
<igc> jam: http://doc.bazaar.canonical.com/bzr.2.1/downloads/ has the chm files now
<RenatoSilva> lifeless: ok, thanks
<jam> igc: can you make it 2.1.0 ?
<jam>  /bzr.2.1.0/ ?
<RenatoSilva> lifeless: from #jython: sabi: re is implemented. bz2, there's some code but it's not done yet (http://bugs.jython.org/issue1445). zlib also appears to be implemented, though maybe not all of it
<igc> jam: poolie decided to move away from doc builds for 2.0.x to simply having one for 2.0
<igc> jam: otherwise we need extra setup on escudero on every point release
<igc> jam: is there a reason why you want 2.1.0 vs just 2.1?
<poolie> yes, i still think that makes sense
<poolie> archiving every single one seems boring
<thumper> hey guys
<thumper> which bzr version officially deprecated knits?
<thumper> as in gave a warning with every command?
<lifeless> 1.something
<lifeless> thumper: how precise an answer do you need?
<thumper> lifeless: just wondering due to the number of branches I can see on launchpad using formats < knits
<thumper> sorry
<thumper> < packs
<thumper> so knits and earlier
<Peng> The warning isn't *that* old. Maybe, ehh, <6 months?
<Peng> (But I have no sense of time.)
<thumper> so debian stable may well not warn with knits?
<mkanat> mwhudson: I wonder if there's some problem we're hitting with NoLockingFileHandler.
<poolie> thumper: it's probably in NEWS
<mwhudson> mkanat: what makes you think that?
<mkanat> mwhudson: Because of the lack of output to the log.
<wgrant> Peng: I think it's much older than that.
<mkanat> mwhudson: I don't know whether loggerhead is actually doing nothing for several minutes, or just not logging for several minutes.
<Peng> Oh, really?
<mwhudson> mkanat: oh right
 * Peng shrugs
<mwhudson> mkanat: well in the most recent hang there wasn't a significant gap in the logs
<Peng> Maybe I'm confusing it with the InterDifferingSerializer (?) warning.
<mkanat> mwhudson: There was a five-minute gap in the one that you gave me.
<mkanat> mwhudson: I commented on the bug.
<jam> igc: if there is only one release, I can make it work, I was just trying to get it to use the same variable, but I think I can set that separately anyway
<mwhudson> mkanat: oh right
<fullermd> 2008-12-11 a quick ann/diff suggests.
<fullermd> Poking around log ways that's probably 1.11.
<lifeless> I hate whippersnippers
<mkanat> mwhudson: Although maybe that's not the problem, because none of the threads in the backtrace are writing to the log.
<fullermd> Whippersnippers are safer to be around than snapperwhappers.
<mwhudson> mkanat: right
<mwhudson> mkanat: i guess it would be good to know exactly when the backtrace is taken
 * mkanat nods.
<poolie> jam, oh https://lists.launchpad.net/launchpad-dev/msg02590.html may be of interest
<jam> poolie: as to Stubs comment about keeping the ssl connection open, I should comment that bzr does multiple requests over https
<jam> I don't know that lazr.restful et al support it, though
<jam> anyway, EOD for me
<jam> also, what does 'pillar' mean?
<mkanat> mwhudson: Is there somebody around who could get me the dmesg/log stuff that I wanted?
<jam> poolie, igc: argh... Visual Studio Trial ends today... I gotta get the release built quickly
<mwhudson> mkanat: it seems we need a full sysadmin for that
<mwhudson> mkanat: let's see if we can find one
<igc> jam: indeed :-)
<mkanat> mwhudson: Okay. :-)
<RenatoSilva> verterok: rpyc as alternative for missing c modules? not so clear to me, but http://pastie.org/828081.txt
<mwhudson> mkanat: nothing remarkable, apparently
<mkanat> mwhudson: No errors about files or sockets or anything?
<mkanat> mwhudson: Can I get the actual real gdb backtrace?
<mkanat> mwhudson: All those threads are in flush(), but that calls what looks like a C function.
<mwhudson> oh hm
<mwhudson> mkanat: btw this is what i wrote to get the python backtrace https://code.edge.launchpad.net/~mwhudson/%2Bjunk/pygdb/
<mwhudson> mkanat: feel free to modify it to get any info you're interested in
<mwhudson> (warning: a bit scary though)
<mkanat> mwhudson: Hmm. Could it be modified to work on a core dump?
<mkanat> mwhudson: Then we could get both the gdb and python trace from a core.
<mwhudson> mkanat: i was thinking it would make sense to output a c-level-like backtrace until you get to the first PyEval_EvalFrameEx, then output a python one
<mwhudson> mkanat: hm, probably
<mkanat> mwhudson: That would make sense, yeah.
<mkanat> mwhudson: The core-dump analysis would probably be easier though, at the moment.
<mwhudson> yeah i guess
<mwhudson> makes it a bit less all or nothing
<RenatoSilva> thanks all
<RenatoSilva> can I bzr missing outside the branch dir?
<Peng> Um, doesn't look like it supports --directory, so I guess not?
<fullermd> Maybe you can do something with --my-revision.
#bzr 2010-02-17
<spiv> mwhudson: regarding python backtraces from gdb, have you seen https://fedoraproject.org/wiki/Features/EasierPythonDebugging ?
<RenatoSilva> ok never mind I'm writing a script and I'm cd'ing to the dir anyway
<RenatoSilva> thanks all
<mwhudson> spiv: no i haven't
<mwhudson> spiv: rather a long way away from being supported in the gdb in hardy, i'd expect...
<spiv> mwhudson: probably
<poolie> spiv, did you see https://code.launchpad.net/~gz/bzr/test_ssh_client_medium_eintr__read_bytes/+merge/19439
<spiv> poolie: not yet, will look tomorrow
<poolie> cool
<poolie> how is V?
<spiv> Sleeping at the moment, thankfully.  He was up late last night!
<poolie> he looks just like you :-P
<Noldorin> can i force a push to a bzr branch on launchpad that has diverged from the local one?
<lifeless> yes
<bob2> bzr help push -> overwrite, beware the consequences
<Noldorin> bob2, yup. i just managed to clobber the launchpad branch, so no worries. thanks
<AfC> Noldorin: I think bob2 more means "consequences" more means "if anyone has grabbed the [revisions on the] previous version of the branch, then you'll never be able to get rid of them (should that person subsequently submit a patch to you and/or merge from your new history)"
<Noldorin> AfC, oh, fair enough. fortunately i'm the only dev on the project at the moment, and no-one else is submitting patches
<Noldorin> but i see the point
<fullermd> In those situations I like to use profanity.
<Noldorin> fullermd, hehe
 * fullermd watches openoffice build all his disk space away.
<AfC> I gotta say, I don't miss rebuilding all of oo for a single line patch
<poolie> lifeless: does https://bugs.launchpad.net/bugs/522637 ring any bells?
<ubottu> Ubuntu bug 522637 in bzr "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys" [High,Confirmed]
<fullermd> Pfft, the warning says it eats 11 gig of space for the build.  But it's barely 10.5; getting me all worried about nothing...
<fullermd> And to think, earlier I actually had a momentary thought of "Gee, 6.5 megs...  that seems a big tarball for a VCS"
<spiv> poolie: oh hey, that's some of that paranoia I added just before 2.0, I think?  Nice (relatively speaking) to see it catch something :)
<lifeless> poolie: yes, isn't there anothe rbug open like that? be great to help the user, figure it out and fix it.
 * igc lunch
<parthm> Hello, I am trying to understand bzr test infrastructure better in the context of http://old.nabble.com/Re%3A-help-needed-in-fixing-test-failure-%28-138600%29-p27617476.html
<parthm> after doing self.make_branch('foobar') I drop into pdb
<parthm> doing a system('ls
<parthm> doesnt show any directories. I am in test_home_dir. Should I be seeing a foobar dir? how does that work?
<mwhudson> parthm: which testcase class did you inherit from?
<parthm> TestCaseInTempDir
<parthm> I am trying to add the test case to blackbox/test_versioning.py: TestVersioning
<mwhudson> parthm: make_branch in that class only writes to a memory-backed transport, not the filesystem
<parthm> Ah. OK. Basically what I need to do is create a directory thats not a part of any repo/branch. I need to run 'bzr mkdir abc' there and ensure that dir abc is not created.
<parthm> What would be a good way to do that considering that test_home_dir is already a branch
<mwhudson> not sure tbh
<mwhudson> poolie: can you help parthm >
<mwhudson> ?
<poolie> hi there
<poolie> yes probably
<poolie> on the phone, will just be a minute
<mwhudson> parthm: if you inherit from TestCaseWithTransport, then self.make_branch _will_ create a directory, which might make things easier to understand
<parthm> hi poolie
<mwhudson> might not be the right thing to do though
<parthm> That seems fine (with my limited understanding). I am looking at blackbox.test_status.BranchStatus.test_tree_status_ignores. Maybe I can do a make_repository('foo', shared=True).
<poolie> (back)
<poolie> so istm that you have to use a real directory
<parthm> If this creates a dir. the mkdir should fail in this case also.
<poolie> at the moment wt must go to disk
<parthm> Yes.
<parthm> The 'init-repo' failcase http://pastebin.com/m6e5397c9
 * poolie looks
<poolie> ok
<poolie> and you're having trouble reproducing that inside a test?
<poolie> rebooting, biab
<parthm> Yes. The same failure can also be seen on the command line with a simple directory thats not a branch. I am trying to create the test case for https://bugs.launchpad.net/bzr/+bug/138600
<poolie> yep
<poolie> i saw your mail earlier
<poolie> so what happens?
<ubottu> Ubuntu bug 138600 in bzr "`bzr mkdir` create new dir before it checks is branch/checkout exists" [Low,In progress]
<poolie> it still sees the directory even with your fix in place?
<parthm> Really? Are you trying this branch https://code.launchpad.net/~parthm/bzr/138600 are are you referring to the pastebin
<parthm> The pastebin is bzr 2.0.4
<poolie> no, i'm asking where you're getting stuck now
<parthm> When I run bzr from the command line the fix seems to work. I am trying to add the test case right now.
<poolie> ok
<poolie> so i think the approach you described should work
<poolie> make a bzr repository, then try bzr mkdir inside that
<parthm> OK. The TestCaseWithTransport approach worked. Thanks mwhudson, poolie.
<parthm> One more question. Unlike other commands, mkdir doesn't seem to be having blackbox.test_mkdir. All tests are in blackbox.test_versioning.TestVersioning, so should I just add blackbox.test_versioning.TestMkdir or should it be blackbox.test_mkdir.TestMkdir?
<parthm> Hi poolie. I was just mentioning that the TestCaseWithTransport approach worked.
<poolie> oh ok
<poolie> so you're all good now?
<parthm> Yes. Just one more question. Unlike other commands, mkdir doesn't seem to be having blackbox.test_mkdir. All tests are in blackbox.test_versioning.TestVersioning, so should I just add blackbox.test_versioning.TestMkdir or should it be blackbox.test_mkdir.TestMkdir?
<poolie> probably add a new module for consistency
<poolie> but either is fine
<parthm> OK.
<parthm> I will add the tests and send a merge request for bug 138600.
<ubottu> Launchpad bug 138600 in bzr "`bzr mkdir` create new dir before it checks is branch/checkout exists" [Low,In progress] https://launchpad.net/bugs/138600
<parthm> Does the NEWS update need to be a part of the merge request or is that a part of the landing process?
<poolie> it's a bit better to put it in your proposal so that we can review that too
<poolie> also it acts as a good summary of what you think you've changed
<parthm> OK. Will do. Thanks.
<poolie> wow the review queue is so long
<spiv> Yeah wow, lots of reviews.  I guess I know what I'm doing tomorrow then :)
 * spiv wanders off again
<parthm> Is there a good way to check (and exit) if the current dir is a workingtree? currently I am doing "wt, dd = WorkingTree.open_containing(d)"
<poolie> that's probably good
<poolie> if you want to know about the specific directory, not just a containing directory, just use WT.open()
<poolie> bzrdir may have a method to tell you?
<parthm> The problem I am seeing with the current fix is that if we have abc/xyz where abc is versioned and xyz is unknown, if user does 'bzr mkdir ./xyz/foo', 'foo' is created before bzr exists. So I suppose I need to know if the first part of the path is versioned.
<poolie> oh i see
<poolie> right, that seems like a separate bug
<poolie> can you see how to reproduce this?
<parthm> Yes. I added a test case where I do os.mkdir('./abc') and chdir('./abc'). run_bzr('mkdir xyz') would create xyz.
<poolie> k
<poolie> biab
<igc> bbiab
<poolie> cheerio
<parthm> for some reason "print" in builtins.cmd_xxx cause a UnicodeEncodeError while running selftest. If I run bzr from the command like this works ok. I tried this with cmd_status and cmd_mkdir while debugging mkdir. Is this expected?
<bob2> printing unicode strings works differently when stdout is not a terminal
<bob2> maybe that's what you're encountering
<poolie> parthm: yes, the difference is that it's probably going into a stringio
<poolie> are you printing something nonascii?
<parthm> No. Even "print 'hello'" fails.
<poolie> !!
<parthm> http://pastebin.com/m51e779bc
<parthm> Whats the suggested way to put a debug print?
<parthm> Never mind. I will explore some more. Seems to be some issue in my setup. Even modifying an existing outf.write seems to be failing
<poolie> hi
<poolie> that's strange
<poolie> parthm: if you want to get arountd it
<poolie> at least for now
<poolie> change the note() code to do
<poolie> msg.encode(self.stdout.encoding, errors=replace)
<poolie> but this is a bit strange
<parthm> So I need to put the msg.encode(..) in my run?
<poolie> in trace.note
<poolie> i'm just testing your permissions patch
<poolie> thanks for doing that
<poolie> much karma for fixing elmo's bugs :)
<poolie> parthm: stuck?
<parthm> Thanks :).  I am trying to figure out what might be a good fix for http://pastebin.com/m56f77879 case.  Switching mkdir with open_containing (http://pastebin.com/m2648b1fb) works for the repo case or when user just does a 'mkdir xxx' but this case still fails.
<poolie> parthm: i think run_bzr has a parameter to set the cwd so you don't need to manage it yourself
<poolie> or use a scriptrunner
<parthm> Yes. Will do that.
<poolie> this is the thing about making sure it fails if the parent is not versioned?
<poolie> can you add it to the inventory before it exists?
<poolie> it seems like that would be cleanest
<parthm> I don't think I understand. So if user does a mkdir xxx/yyy and xxx is not versioned (unknown) whats a good way to check and fail?
<poolie> parthm: what i'm suggesting is that we try to add yyy to the inventory
<poolie> ie to the metadata
<poolie> before making the directory
<poolie> that will fail if xxx is not already in there
<poolie> then if that succeeds, mkdir
<poolie> the only catch will be if the add-to-inventory code checks it exists on disk
<poolie> which would be a bug imo, but maybe a slightly harder one
<parthm> Ah. I get it. What API should I look at?
<poolie> basically i'm just suggesting moving the mkdir after wt.add
<poolie> it may fail horribly
<poolie> but it's worth a go
<parthm> So this is what my current cmd_mkdir looks like http://pastebin.com/m57cffad5 . unfortunately I hit this painful unicode error http://pastebin.com/m3b815639 . I am using vim which I think handles unicode fine. Wow.
<poolie> ouch
<poolie> did you try changing note() to print the message with errors='replace' rather than spazzing out?
<poolie> i think you need to get unblocked from that to make other changes easer
<poolie> i don't know why it's failing there
<parthm> Yes. I just did the note change. That worked, thanks.
<poolie> it is annoying certainly
<parthm> http://pastebin.com/m57cffad5 doesn't seem to work. I may be doing something wrong.
<poolie> what happens?
<poolie> it's unfortunate you have to add the root
<poolie> though that is a bit of a separate issue
<parthm> Looks like the msg.encode change didn't work. msg is undefined. http://pastebin.com/m579486a7 Sorry I seem to have more questions than answers :( So is note called by self.outf.write?
<parthm> Can wt.has_filename be used for a conditional check on os.path.abspath(base)? We need to use abspath as the user may either do 'bzr mkdir foo/abc' or 'cd foo; bzr mkdir abc
<parthm> where foo is unversioned
<poolie> no, note should not be called by self.outf.write
<poolie> parthm: when you open the wt with open_containing, it gives you back the relative path
<poolie> you can then chop off all but the last component of that and check that it's versioned
<parthm> Oh OK. That makes sense.
<parthm> What do you suggest I do about the prints for now?
<poolie> which prints are these?
<poolie> just ones you're adding for debugging?
<parthm> Yes.
<parthm> This is the final version of cmd_mkdir.run http://pastebin.com/m3893f263 All tests are passing, yay!
<parthm> These are the three test cases
<parthm> http://pastebin.com/m2e37b536
<poolie> i think you need better docstrings
<poolie> rather than 'invalid' say 'unversioned'
<parthm> I agree. Will do that.
<parthm> OK.
<poolie> and rather than joining the strings, use ['mkdir', newdir]
<poolie> thanks for all the patches
<parthm> Welcome :)
<parthm> I am trying the winepython usage you suggested.
<parthm> After installing testtools and paramiko I get "bzr: ERROR: No module named Crypto.Util.randpool"
<parthm> Any ideas?
<parthm> paramiko installed without any errors.
<poolie> blah
<poolie> it's some kind of known bug about paramiko
<poolie> just run particular tests and avoid paramiko
<poolie> it's not very relevant to your bugs
<poolie> well, it's time for me to go
<poolie> push your branch and we'll rereview it
<parthm> OK. Bye.
<lvh> where can I see the branch format of a branch on launchpad?
<lvh> I just branched something using 2.0.4 and it was hella slow, AFAIK the main cause for that is typically branch format mismatch
<lvh> Ack. Why do I always spend 20 minutes looking for something, ask for help, and then find it immediately after? :|
<lvh> Sorry, I'm having to deal with a really bad wifi connection
<lvh> I've got a format 7 branch off of a format 7 trunk
<lvh> the format 7 trunk is synced from svn, it's not actually pushed to
<lvh> what are my options for upgrading the local format ?
<jderose> lvh: `bzr upgrade` should upgrade to local repo to the 2.0 format
<GaryvdM> Hi igc
<GaryvdM> igc: I'm trying to find the page that you had the OOo branch on.
<igc> hi garyvdm
<igc> garyvdm: if you want some large test repos, try http://people.canonical.com/~ianc/benchmarks/repos/bzr/
<GaryvdM> Thanks
<GaryvdM> Hmm 1.3 gB. That will cost me about R 260 to download :-(
<GaryvdM> ok - bye
<AntoineLaf> I have a very beginner level question and hopefully someone would be kind enough to point to where I could find some answers: here it goes. I'm trying to make sense of the "markers (not sure if it's the properword)" inserted in a conflicting merged file. I would like to know where I could find an explanation for <<<< TREE and >>>>>> MERGE SOURCE. Thank you.
<Kinnison> IIRC what you get is:
<Kinnison> <<<< TREE
<Kinnison> what you had in your tree
<Kinnison> so this is your change
<Kinnison> =======
<Kinnison> what the merge source had which conflicted
<Kinnison> this is what you're trying to merge in from the remote branch
<Kinnison> >>>>>> MERGE SOURCE
<Kinnison> type thing
<Kinnison> does that help?
<AntoineLaf> so what is before the ====== part is the changed part
<AntoineLaf> and under the ====== is the part I try to merge and is conflicting...
<AntoineLaf> I think it helps, let me have a better look at it again
 * Kinnison nods
<AntoineLaf> <<<<<<< TREE
<AntoineLaf> something
<AntoineLaf> =======
<AntoineLaf> >>>>>>> MERGE-SOURCE
<AntoineLaf> something like that means that the merge tries to remove something?
<Kinnison> It means that where the local branch changed <foo> to "something", the merge branch removed it
<Kinnison> yes
<AntoineLaf> this is starting to make sense...
<AntoineLaf> I guess I'll get more scout badges this month...
<AntoineLaf> :) thx
<Kinnison> :-)
<Kinnison> Scouts have a DVCS badge?
<AntoineLaf> yes, with 20 levels with different colors...
<AntoineLaf> sorry, this is my fantasy world...
<AntoineLaf> have to say that bazaar is the first versioning system that I finally had the guts to stick with and learn... I'm from a designer's background... not all that familiar with the thinking behind the tool. anyways.
<bialix> what is the new feature in bzr? cmd_foo.run_direct?
<igc> night all
<radoe> Hm, will there be full releasenotes for 2.1 put online? By now it seems one has to check all 2.1.0bX and 2.1.0.rY together with 2.1.0 to get all incremental changes.
<adiroiban> hi. I'm using bzr break-lock , but it tell me that the lock is in used and I can not break it
<adiroiban> is there a bzr command to show who is using t he lock?
<bialix> adiroiban: break-lock actually show you info about lock holder, do you have different experience?
<bialix> this command is interactive: it show you info about lock and then asking for y/n answer
<adiroiban> http://paste.ubuntu.com/378311/
<adiroiban> this is all I see
<adiroiban> no prompt for breaking the lock
<adiroiban> or hint about how can I solve this issue :)
<bialix> adiroiban: please run again as `bzr -Derror break-lock` and pastebin
<bialix> I suspect some application holds OS lock on dirstate file
<adiroiban> http://paste.ubuntu.com/378312/
<adiroiban> ..maybe, I'm not greping lsof
<bialix> most likely some application still has OS lock over file .bzr/checkout/dirstate
<bialix> usually you will see different message
<bialix> or there is bug
<adiroiban> yep. lsof, shows that gedit is using it (I'm using the gedit bzr integration)
<adiroiban> I still think it is a bug as bzr should inform me that gedit is messing the repository
<bialix> adiroiban: I don't know is there any API for this
<bialix> but I think you need to file a bug report
<Tak> hmm, should bzr-svn be able to auto-authenticate me over svn+https?
<jelmer> Tak: what do you mean by auto-authenticate?
<Tak> I mean, use my credentials from authentication.conf
<jelmer> Tak: it should be able to use a username/password if one is set in ~/.subversion or ~/.bazaar/authentication.conf
<jelmer> but you need a recent version for ~/.bazaar/authentication.conf to work
<Tak> ok
<Tak> I have bzr 2.0.4 and bzr-svn 1.0.2
<jelmer> that should be recent enough
<Tak> oh, what should the scheme be?
<jelmer> oh actually, authentication.conf perhaps doesn't work for svn+https, only https
<Tak> I have svn+https
<jelmer> for any particular reason? just https should work..
<Tak> it wasn't working for me at some point, with this server
<Tak> but that was several versions ago; let me try again
<Tak> ok - it looks like it tried to authenticate me that time - are there character restrictions on the passwords in authentication.conf?
<jelmer> Tak: it should be a utf8 string
<Tak> ok, but it can contain *&^#$^$# ?
<Peng> The config parser _might_ get a bit confused. E.g., # denotes comments. Try putting it in quotes?
<Peng> It's mostly standard ConfigObj, FYI.
<Peng> If you like using the Python prompt, import bzrlib.util.configobj.configobj and check how it parses it.
<Tak> hmm, quotes don't help
 * Tak do that
<Tak> yeah, it's truncating the password at the comment char
<Tak> if I single-quote it, it looks ok in the ConfigObj, but the authentication still fails
<Tak> is it maybe getting parsed again someplace else?
<bialix> http://martinfowler.com/bliki/VersionControlTools.html
<bialix> bzr is not mentioned at all
<bialix> maybe somebody know why?
<ronny> bialix: he write why in the text
<ronny> -i+o
<bialix> hmm, I've missed it
<bialix> ok, found
<bjp> i'm seeing this bug: https://bugs.launchpad.net/loggerhead/+bug/518679
<ubottu> Ubuntu bug 518679 in loggerhead "Unable to see diffs" [Undecided,Incomplete]
<bjp> with bzr version 2.1.0dev5
<bjp> and loggerhead from bzr reversion 400
<bjp> though the second to last comment implies this is already fixed?
<RenatoSilva> verterok: http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline
<jam> james_w: /wave
<james_w> hi jam
<jam> james_w: I'm happy to add an enable/disable flag for the lp cache, what would you like the default behavior to be
<jam> ?
<james_w> I'm happy for it to be disable the cache
<james_w> my one concern is that other people may try two in parallel and have it fall over
<james_w> with a confusing error
<james_w> but I don't see a way to avoid that really
<lifeless> james_w: why would it fall over?
<james_w> stupid stupid cache implementation
<jam> lifeless: https://bugs.edge.launchpad.net/launchpadlib/+bug/459418
<ubottu> Ubuntu bug 459418 in launchpadlib "Cache is broken with multiple processes" [Undecided,New]
<jam> the cache is not multi-writer safe, aiui
<lifeless> ah
<lifeless> closely related to 'stupidly needing a cache'
 * lifeless tries for bitter
<james_w> lifeless: how would you avoid one?
<lifeless> james_w: for lp apis?
<james_w> yeah
<lifeless> design it differently
<lifeless> the amazon EC2 -style- of API's don't need a cache
<lifeless> and operate hugely more efficiently
<james_w> ah
<james_w> ok
<lifeless> specific changes are - out of band definition of APIs; a-priori defined calling method; message signing rather than cookie-auth
<james_w> is it possible with bzr's Options to have no -- form?
<james_w> I only need the short form
<lifeless> yes
<lifeless> its optparse
<lifeless> (not that oauth is strictly cookie based)
<james_w> well, it's not possible with Option directly as far as I can see
<james_w> I can subclass
<lifeless> james_w: oh interesting, its less optparse than I remember
<lifeless> james_w: so no, it doesn't look like you can
<jam> james_w: yeah, you'd have to override Option.add_option so that it doesn't always add '--%s' % self.name
<jam> call it ShortOption, I guess :)
<jam> though I'm curious why it would be a problem to have a long option, even if you don't strictly need it
<james_w> just overhead
<james_w> I'm taking a bunch of arguments that a subprocess takes just so I can pass them through
<james_w> and it doesn't have long versions for some things
<lifeless> this is for -uc and the like ?
<james_w> yeah
<james_w> I'm not happy with any alternative I've come with so far
<james_w> and I have to override -v for verbose somehow
<lifeless> you might want to override run_argv instead
<james_w> oh, but I've never actually accepted verbose, so there won't be a behaviour change
<jam> james_w: I've pushed an update that adds an '--lp-cache' parameter, which lets you set the lp cache directory (defaulting to None)
<jam> It also includes my other small import-scripts tweaks
<james_w> your happy that everyone will have to add that option if they want to make use of it in testing?
<jam> james_w: well, lp doesn't provide things for you, and I'm not 100% sure where it should go
<jam> for example, it could go in ~/.cache/...
<jam> which is what bzr's launchpad plugin does
<jam> you may or may not want to share it
<jam> I think the # of people running it manually is probably low, vs how often it gets run in production :)
<jam> :(, it takes 300 seconds to list the PackageToImport for gnome-panel
<james_w> yes, but it's easy for me to change it once in production
<james_w> jam: first time?
<james_w> any quicker second time?
<jam> this is the second time
<jam> *with* the cache
<james_w> ok
<jam> there are 218 versions
<james_w> well, I was thinking about the Debian cache actually
<james_w> those files are larger than the LP wadl
<jam> it seems it can be as fast as 100 s
<jam> but it still took to 500s to get to "these packages are new"
<jam>  /me wonders if --lp-cache isn't actually causing it to be slower for some crazy reason
<james_w> well, it still has all the round trips
<jam> sure, but I'm wondering if it doubles the round trips
<james_w> shouldn't do
<jam> like "is this new enough: No", ok give it to me then
<jam> I realize it is supposed to be sending the date in the first check
<james_w> it's using etags
<james_w> "Give me this file unless it matches <this one>, in which case just tell me that and I'll re-use what I have."
<james_w> are you using --no-existing?
<jam> no
<james_w> then it may be opening a bunch of branches on LP too
<jam> sure, but
<jam> http://paste.ubuntu.com/378636/
<jam> it seems to be opening the *same* bzrdir over and over and over again
<jam> and it still took 300s before it got the package listing
<james_w> not sure why it seems to be repeating
<james_w> however, the delay is just LP taking a while for a getPublishedSources call
<james_w> which is unsurprising
<thumper> how does bzr determine if a file is text or binary?
<jam> seems to be from 'get_branch_parts'
<jam> thumper: checks for \0 in the first 1024 chars
<thumper> jam: is there a bzrlib method I can use?
<jam> james_w: I think the issue is that: find_unimported_versions tries to open a branch locally
<jam> and then falls back to remote
<jam> copying that branch locally
<jam> but if the remote branch doesn't exist
<jam> then it just spins
<jam> because it keeps getting None for the branch
<jam> thumper: bzrlib.text_something.check_text_lines
<thumper> jam: ta
<jam> thumper: bzrlib.textfile.check_text_lines
<james_w> jam: I don't think it will spin
<james_w> oh, no, I see what you mean
<james_w> yeah, that could be optimised
<jam> yeah, for each version it tries again
<jam> to open a branch that doesn't exist
<jam> note that when it *does* exist
<mkanat> So, looks like bzr doesn't understand query strings in URLs?
<james_w> I thought you mean "while target_branch is None:"
<jam> it still tries to open the same branch over and over again
<jam> mkanat: I would assume that we just ignore them
<lifeless> mkanat: do you mean loggerhead?
<mkanat> lifeless: No, I mean bzr.
<mkanat> bzr merge https://bugzilla.mozilla.org/attachment.cgi?id=427066 -- doesn't work.
<lifeless> hmm, we should preserve them
<mkanat> (That's a bundle, at that URL.)
<lifeless> mkanat: https://bugzilla.mozilla.org/attachment.cgi?id=427066/
<lifeless> mkanat: see the / - we add that, and moz barfs
<lifeless> mkanat: there is a bug for this.
<mkanat> lifeless: Ahh.
<james_w> mkanat: does it escape them or drop them?
<jam> james_w: no, we add a trailing slash
<lifeless> or we may be dropping them; check a tcpdump to see precisely what happens.
<mkanat> lifeless: The page that's getting returned seems to indicate that they're not getting through to Bugzilla at all.
<lifeless> for opening bundles etc this is bad.
<lifeless> mkanat: tcpdump time
<jam> lifeless: get_transport(http+query).base has no query param
<lifeless> ok, thats a bug
<lifeless> we've no reason to strip query params *until* we go up a dir
<jam> lifeless: ConnectedTransport._split_url calls urlutils.parse_url(url)
<jam> which returns a 'path' that does not have query parameters
<lifeless> sure
<lifeless> just saying, that this is a bug IMO
<jam> sure
<jam> parse_url gets 'query' and just discards it
<jam> it also discards "params"
<jam> which may be a problem for colocated branches
<IslandUsurper> is there a configuration option to control how qbzr highlights syntax? I want it to display files as PHP whose filenames don't end in .php
<jam> lifeless: it also appears to be falling back to vfs fetch, any idea why that would be?
<jam> both are in 2a format
<jam> currently at 100MB downloaded according to progress bar, but only 13MB on disk... :(
<lifeless> jam: on bzr+ssh ?
<lifeless> jam: if you do ctrl-\ you should be able to get a backtrace; that would help determine why the fallback
<lifeless> morning poolie
<poolie> hi lifeless
<jam> lifeless: not when running via import_package rather than bzr
<jam> since it doesn't set up the signal handler
<lifeless> jam: oh; then gdb python PID
<lifeless> and use the gdb python macros to get a backtrace
<jam> of course to do it "for real" requires waiting 5min (300s) for launchpad to finish giving me info...
<poolie> jam, jeez, what are you asking it for?
<lifeless> jam: you can attach live though :). still - yes, it will be painful
<jam> poolie: import_package.py gnome-panel
<jam> w/ ~ 218 getPublishedSources
<jam> anyway, I need to be off for now
<jam> I'll let it sit and spin a while
<jam> gnome-control-center isn't really any faster
<jam> ugh
<jam> fetching "+files" redirects to "%2Bfiles"
<jam> so anytime you download stuff from the librarian
<jam> it involves a redirect
<lifeless> or not 2b?
<lifeless> isn't + 2B anyway ?
<jam> lifeless: right, but "+" gets interpreted as " "I think
<jam> ah wait
<jam> I'm wrong
<jam> +files/foo redirects to /NUMBER/foo
<jam> 687.296  > GET /ubuntu/hoary/%2Bsource/gnome-panel/2.10.0-0ubuntu9/%2Bfiles/gnome-panel_2.10.0.orig.tar.gz
<jam> ...
<jam> < Location: https://launchpadlibrarian.net/1307193/gnome-panel_2.10.0.orig.tar.gz
<lifeless> on the wire, + is 2B anyway, its in the unsafe set
<jam> lifeless: yeah, I just read the redirect wrong
<fullermd> Yes, I have to manually resolve those redirects every time I update the port   :|
<lifeless> fullermd: what, why?
<fullermd> For hysterical raisins, the fetch stage of port building doesn't follow HTTP redirects.
<fullermd> One reason is various server configs built by geniuses that redirect to an error page rather than returning a 404, and that sort of thing.
<lifeless> is there a flag to say 'redirects are part of the spec dumbass' ?
<fullermd> "Not found" is a nicer error to show a user than "hey, I downloaded this file [of HTML rather than a tarball] and the size/checksum don't match"
<lifeless> fullermd: no easier to resolve when their browser shows the thing fine.
<fullermd> I didn't say I entirely _agreed_ with it.  It's just how it works, so either I put in the final URL, or we don't have a bzr port   :p
<lifeless> sure
<lifeless> jsut asking if there is an override variable
<lifeless> there often is in ports IME
<fullermd> Potentially, by manually overriding the FETCH_CMD or something.  But there's no ACCEPT_REDIRECTS sort of thing; the fetch(1) args are hardcoded.
<lifeless> fullermd: sounds like a worthwhile bugfix: do it once, save time in future.
<fullermd> That's more undercover reaching than I wanna do, so I just run a quick GET every update and copy in the new number on librarian.
<fullermd> Yeah, it wouldn't be a huge patch to implement.  Pushing through an infrastructure change like that would be more work though; I don't want it THAT much.
<fullermd> Anyway, it saves LP having to service a hit every download  :p
<lifeless> think of the kittens
<jam> james_w: as far as opening lots of branches, it doesn't help that gnome-panel is opening all of {warty,hoary,dapper,breezy,hardy,...}{,-security,-proposed,-updates,-backports,} none of which seem to exist
<james_w> correct
<james_w> I wasn't sure I wanted to make too many assumptions about which would exist based on others
<jam> fortunately it seems to  be a single BzrDir.open() probe, so a single rpc requset
<jam> at least once I added a "last_branch" cache
<poolie> igc, hi?
<spiv> Good morning.
#bzr 2010-02-18
<abentley> lifeless, would you mind reviewing this? https://code.edge.launchpad.net/~abentley/bzr/unbreak-merge/+merge/19556
<lifeless> ok, when it has a diff :)
<lifeless> abentley: perhaps it should try for the tree config and fall back to the branch config after that ?
<lifeless> abentley: rather than not permitting tree level configs?
<abentley> lifeless, it was never trying for the tree config.
<lifeless> abentley: ah! then its trivially ok, JFDI
<lifeless> abentley: you seem to have unrelated stuff in the diff
<abentley> lifeless, yeah, weird.
<lifeless> pages of it :). I suspect 2.0 -> trunk, or something ?
<lifeless> anyway, the intent of the change you describe is fine.
<lifeless> +1
<abentley> lifeless, Ah, I proposed it against 2.0 instead of 2.1 as I intended.
<mkanat> mwhudson: The format of loggerhead/1.17 needs to be updated:
<mkanat> bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/.bzr/)
<mkanat> is not compatible with
<mkanat> KnitPackRepository('bzr+ssh://bazaar.launchpad.net/~loggerhead-team/loggerhead/1.17/.bzr/repository/')
<mkanat> different serializers
<mkanat> Or Peng, if you're around and mwhudson isn't, I suppose.
<justdave> I got that trying to check it out over http, too, fwiw
<lifeless> its upgrading now
<mkanat> Yeah, I think it's because one is stacked on the other.
<lifeless> https://code.edge.launchpad.net/~loggerhead-team/loggerhead/1.17
<mkanat> lifeless: Thanks. :-)
<lifeless> there is a clicky clicky button in the webui
<mkanat> Ahh. :-)
<lifeless> mwhudson: is that button in the API now ?
<mwhudson> lifeless: no idea
<lifeless> mkanat: is upgraded
<mkanat> lifeless: Thanks! :-)
<mkanat> justdave: ^^^
<justdave> does it need to mirror out or something?  still getting the error
<justdave> proxy cache on bazaar.launchpad.net needs flushing I suppose
<lifeless> there isn't one
<lifeless> there is however a mirrored copy
<lifeless> I'm poking, gimme a sec
<lifeless> upgrade didn't seem to do much
<poolie> oh hi spiv
<lifeless> rockstar: where do upgrades get logged ?
<lifeless> rockstar: trying to upgrade https://code.edge.launchpad.net/~loggerhead-team/loggerhead/1.17, it doesn't seem to be actually, well, /doing/ anything.
<lifeless> mwhudson: thumper: ^ perhaps you know
<mwhudson> lifeless: i don't know anything off hand
<thumper> hmm...
<thumper> well
<thumper> if we had abentley's job console, we'd be able to see something there
<thumper> for now we just need to do db queries
<lifeless> !
<thumper> as in "ask a losa"
<thumper> which we can't do
<lifeless> I would have thought it would log like imports to, to somewere about the branch
<thumper> we do
<thumper> but the logs are synced daily
<lifeless> that would let any user get an idea ;)
<thumper> unless you ask a losa
<lifeless> that doesn't sound like the import system
<thumper> it isn't like the import system
<lifeless> thats ok; I'm just trying to be clearer about my comment 'I would have thought...'
<thumper> lifeless: noted
<lifeless> mbarnett: are you around?
<lifeless> thumper: should I file a bug that upgrade output isn't visible on the branch
<thumper> lifeless: yes please
<lifeless> mbarnett: around?
<lifeless> mbarnett: https://code.edge.launchpad.net/~loggerhead-team/loggerhead/1.17 isn't upgrading properly, we need a log looked at
<igc> morning all
<igc> hi poolie
<lifeless> igc: just!
<igc> lifeless: well I did some work in the morning 11 hours ago so it's morning #2 for me :-)
<poolie> hello igc
<lifeless> igc: :)
<poolie> i'm so glad parthm liked that
 * spiv -> lunch
<poolie> spiv/igc/lifeless: i'd like to turn off --verbose in 'make check' so that pqm failures are not so ridiculously long
<poolie> https://code.launchpad.net/~mbp/bzr/trivial/+merge/19567
<lifeless> poolie: it might be nicer just to turn subunit on
<lifeless> poolie: and let it run the entire test suite, so you get all the failures at once
<poolie> nicer, but harder :)
<lifeless> the bug about this has a suggested recipe
<poolie> bet you can't do it in one character
<lifeless> so you shouldn't need to think hard ;)
<lifeless> poolie: bet I can't either
<poolie> but aside from that, yes
<poolie> so it would send the whole subunit output?
<poolie> it sounds good
<poolie> especially with tribunal
<lifeless> yes
<poolie> but it will kind of suck for people wanting to just look at the mail
<lifeless> so do xml test reports
<lifeless> which other projects do by default
<poolie> if we could send mail with a short failure in the body and the subunit in the attachment that would be sweet
<lifeless> poolie: file a bug - I'm not about to do that immediately, but it certainly sounds nice.
<lifeless> in fact, I'd want all the failures in the body
<poolie> hm
<poolie> actually this could be mostly in subunit generally
<lifeless> sure.
<lifeless> anyhow, as I say the recipe has been hammered out for you
<lifeless> 'the'-  'a' recipe that should work
<poolie> this is "how to run --subunit and have pqm still have teeth?"
<lifeless> yes
<lifeless> once we're doing that reliably I'll happily change PQM to go 'oh look subunit, I'll have teeth no matter what'.
<lifeless> but its harder to deploy pqm changes, so I don't want to do that willynilly
<lifeless> poolie: small present for you (apt)
<poolie> ?
<lifeless> bug 22354
<ubottu> Launchpad bug 22354 in apt "apt-cache doesn't differentiate sources that share protocol, host, release and archive name" [High,Confirmed] https://launchpad.net/bugs/22354
<poolie> oh yay
<abentley> straw poll: It's currently possible to commit a revision whose tree has no root, but this isn't well-supported.  Should we forbid committing rootless trees or fix the support?
<lifeless> abentley: do you mean a root of TREE_ROOT, or actually no root ?
<abentley> lifeless, no root, like the null: tree.
<lifeless> abentley: I thought that no root at all wasn't support; and that TREE_ROOT was dependent on the repo
<lifeless> abentley: and presumably no content either?
<abentley> lifeless, no content either.
<abentley> lifeless, it's possible to do when committing a TreeTransform or using the CommitBuilder directly.
<lifeless> abentley: I'm surprised. I can see a theoretical argument to permit it, but I'm fairly sure it would provoke a lot of bug reports from code assuming things have /some sort/ of root.
<lifeless> my poll response: forbid
<lifeless> unless you have a need for it, in which case - talk on
<abentley> lifeless, I don't need it.
<abentley> lifeless, the possible problems with forbid are:
<abentley> lifeless, 1. if there are such commits in the wild already (I have no data)
<abentley> lifeless, 2. If there's a risk that it will happen in the future, despite us forbidding it in a given codepath.
<abentley> lifeless, end of list.
<lifeless> so, for 1 I'd expect that from custom code, not general use - as it has to be totally empty. I think its near-zero probability.
<lifeless> as for 2, well, we do what we can.
<abentley> poolie, in your review, you say "I would like to see the actual code changed to be 'propose' not 'submit'.".  This means changing class and module names, etc?
<poolie> yes
<abentley> poolie, this is an underhanded scheme to make me write some tests, isn't it?
<poolie> :)
<spiv> poolie: regarding turning off --verbose in make check, it hasn't really bothered me greatly, so I'm pretty neutral on the idea.  I agree that it would be nice to get the failure(s?) in the body and the complete log as an attachment.
<poolie> spiv, ok,
<spiv> poolie: with some test suites it can be helpful to have a "I'm running test X now" log in case one test hangs, but historically that hasn't been much of a problem for bzr.
<lifeless> spiv: pqm does that
<lifeless> spiv: for subunit, now.
<spiv> lifeless: right, but that's not turned on (etc etc)
<poolie> true
<lifeless> Gotta run; later. Ring or SMS if you want me.
<spiv> (I see you just had this discussion, I don't mean to make you go in circles!)
<poolie> hi igc?
<abentley> poolie, it would have been nice if you had raised the canonical_url thing earlier in the process.
<poolie> sorry
<poolie> just because it's better to get the whole review in one go?
<abentley> poolie, I think that replace('api', '') is a much worse idea than replace('https://api.', 'https://code.')
<abentley> poolie, because "api" can easily appear anywhere in the URL, while "https://api" is really unlikely to appear anywhere other than the front.
<poolie> i know
<poolie> otoh this function won't work for bugs
<abentley> poolie, because I feel like either I do it the wrong way to get it merged, or I have to do another round.
<igc> hi poolie
<poolie> anyhow it's gross that this is not provided by lplib
<poolie> well, it's negotiable
<poolie> let's look
<poolie> it's time to get this merged
<abentley> poolie, rationale for removing the https:// ?
<poolie> i keeping wanting to use it :)
<poolie> actually
<poolie> never mind about the replacement
<poolie> i would kind of like you to point to the bug, and to think about changing the name
<poolie> either expression is kludgy and mine isn't especially better
<abentley> poolie, the name in the Launchpad codebase is 'canonical_url', which is why I used that name.
<poolie> oh ok
<poolie> fair enough
<poolie> note that i'm using replace(x,y,1) which is maybe more robust against the term /beta/ turning up later in the url
<poolie> i don't know if that will actually happen
<abentley> poolie, canonical_url is not exposed over the API because it's a function, and functions don't exist in our REST API.
<poolie> right
<poolie> but perhaps it should be in lplib?
<poolie> or for that matter it could be an object property?
<poolie> as it is, variations of this code are copy-and-pasted into every lp api client
<poolie> spiv, to follow up from before
<abentley> poolie, this should definitely be provided elsewhere, ideally through the REST API directly.
<abentley> poolie, and making it an object property would be a reasonable way of doing that.
<poolie> spiv, http://doc.bazaar.canonical.com/bzr.dev/developers/bug-handling.html#backports discusses the use of bugtasks for backports
<poolie> patches welcome
<poolie> and that page is just impossible to find :/
<poolie> igc, is anything still needed on escudero or did the cron job run ok?
<spiv> poolie: ah right, I did find that eventually actually, but not before mailing you
<poolie> abentley: ok so feel free to merge without changing that
<abentley> poolie, but that wouldn't be a 1:1 reflection of the native API.
<igc> poolie: the cron job kicked in thanks
<poolie> what is 'that'?
<igc> poolie: we still need a bzr.2.2 directory as requested by jam
<igc> and for those files you emailed me about to be deleted
<abentley> poolie, providing the URL as an object property on all REST API objects.
<igc> poolie: I don't seem to have permissions to do any of that
<poolie> igc, ok
<poolie> abentley: ok, well, i hope it gets solved somehow
<poolie> igc: i want to unfold the 'enhancing bazaar' section in http://doc.bazaar.canonical.com/bzr.dev/developers/
<poolie> it's too hard to guess where the bug guidelines would be
<igc> poolie: fine with me. Go for it!
 * igc lunch
<poolie> igc, new page is nice, go for it
<igc> poolie: thanks
<poolie> spiv, what do you think of my suggestion at the bottom of https://bugs.edge.launchpad.net/bzr/+bug/376388
<ubottu> Ubuntu bug 376388 in etckeeper "~/.bazaar created owned by root (when run under sudo)" [Medium,Confirmed]
<spiv> poolie: hmm
<spiv> poolie: now is the time in the 2.2 cycle to try that sort of idea out :)
<poolie> i was going to suggest parthm try it
<parthm> Hi poolie. I just saw your comment "backport to 2.0 sent to pqm" and didn't understand it. (on https://code.edge.launchpad.net/~parthm/bzr/262450/+merge/19483)
<spiv> poolie: I guess the most obvious failure mode is "directory writeable by me, but not owned by a user I can chown to"
<poolie> hey
<poolie> i mean, i cherrypicked your fixes onto a branch of 2.0
<poolie> and have sent it for automatic testing
<parthm> poolie: is this about porting the backup.bzr perms? I have that against 2.0. Was waiting for the final merge in trunk so that any additional changes can also be put in.
<parthm> Oh cool. Then I won't bother.
<poolie> yeah, it's ok
<poolie> generally speaking it's easier to do the review and merge against the older branch first
<poolie> and then we can merge it forward
<spiv> poolie: for the case of writing to a file/dir in $HOME, I think your suggestion is good... I haven't thought of any likely scenarios where it will be worse than the status quo
<parthm> Yes. I was thinking of merging 369501_2.0_ver_on_bzr_cmd forward to 2.1 and 2.2.
<spiv> We typically tend to just merge all of 2.0 into 2.1 periodically (and 2.1 into 2.2, etc)
<parthm> Oh OK. Then should I just let that be for now?
<parthm> That sounds like a good idea.
<poolie> you can just let that be for now
<parthm> OK. I had a question regarding fixing of bugs. Is there a policy on deciding if the bug should be fixed againt 2.0, 2.1 or trunk?
<igc> poolie: the site upgrade has been merged now. I'm not sure how often the cron job runs but it will hopefully be live soon
<igc> poolie: I'll grab some lunch, reply to some support Qs and then take a look at templating next. Getting rid of manual updates will be good I think
<spiv> parthm: there's a little bit about it at http://doc.bazaar.canonical.com/bzr.dev/developers/cycle.html#bug-work (and the "Feature and Performance Work" section too)
<spiv> parthm: we probably should have a more formal description somewhere, I think maybe poolie has sent one to the list at some point?
<spiv> parthm: roughly speaking, the safer and more valuable a bug fix is, the more likely we are to accept it into stable branches
<fullermd> Speaking of docs, is there some good way to make random sweeping statements about parts of them needing skilled work?
<parthm> Thanks spiv. I will go through the docs and also see if I find something on the list.
<spiv> So a fix for a very rarely hit bug that has a significant chance of other regressions, we wouldn't accept that for 2.0.
<spiv> But a small, obviously correct fix for something pretty visible we would.
<spiv> fullermd: "good" in what sense?  In the sense that people won't be offended, or in the sense that saying it will cause the docs to be improved? :)
<fullermd> Well, the former is nice (though in this case, I doubt anybody who'd be offended would still be around  :p), but the latter was more what I was thinking.
<spiv> (And they aren't necessarily mutually exclusive options, of course)
<spiv> I'd talk to igc about that, then.
<fullermd> I could mention it here, and have it disappear.  Mail the list, probably ditto.  File a bug, it ends up being one of those overly-fuzzy "X could be improved" sorts of things...
<spiv> He seems to be pretty good at building enthusiasm for that sort of work in a way that causes stuff to happen.
<fullermd> And more importantly, why am I being disturbingly general when I have something specific in mind?
<fullermd> The "Performance Roadmap" needs rewriting.  Big chunks of it talk about things we'd like to evaluate based on 0.16 for use in a possible pack-ish format.  This doesn't seem important to have prominent in our docs.
<abentley> fullermd, I'd consider that a historical document at this point.
<fullermd> Well, there's still some good stuff in it about minimal-work evaluation of various commands too, so it doesn't (at first glance anyway) seem like a "OK, we can just discard this now".
<fullermd> But making it up-to-date useful is pretty skilled labor, so it's not low-hanging stuff.
<spiv> fullermd: I'd say that's possibly a specific-enough issue for a bug report
<abentley> fullermd, some of that will be out of date too, as we've gained more experience and implemented different things.
<fullermd> Yah.  Hm.  I guess I'll put it on my list to try drawing up a few specific slices on it and file something.
<fullermd> See, this is why I avoid reading docs.  It just leads to more work  :p
<spiv> For that matter, the "Bazaar Release Cycles" doc needs to be updated; it's still written as a proposal, when it's now fact.
<poolie> fullermd: it's true it's out of date but
<poolie> it's real audience know tha
<poolie> you can put up a patch that deletes stuff you're pretty sure is obsolete
<poolie> a lot of it is
<poolie> i share your doubts about the value of bug reports like that
<poolie> vague ones
<fullermd> Yeah, it's tricky.  I know enough to believe there are parts of it that are still useful going forward, but not to be sure which parts qualify (and those that do need updating too).
<fullermd> It probably ends up being not so much even "clean out obsolete", as "take useful bits and make a differently targetted article around them"   :|
<spiv> Right.
<fullermd> Y'know, to occupy all that spare time everybody has going to waste.
<spiv> I mean, in its current state it's barely useful at all; I know I haven't referred to that doc for ages, even though as a developer I am in the target audience for it.
<poolie> right
<poolie> i'd welcome someone being a bit deletionist there
<poolie> we can always get it back if we remember something was useful
<spiv> Agreed
<poolie> igc, blah, the doc/www directory is root-owned
<igc> poolie: yep ;-(
<spiv> Another idea: Twisted IIRC has a 'historical' directory in their docs for docs that aren't worthless but are also nowhere near current.
<poolie> yeah
<poolie> we'll have them on the web in old branches though
<poolie> fullermd: so if you're keen, delete away
<poolie> igc i'll file an rt
<fullermd> Oh, I don't have a dog in it at all   :)
<fullermd> Just struck me as worth mentioning while it was in my brain.
<poolie> igc: rt sent
<poolie> parthm: https://code.edge.launchpad.net/~parthm/bzr/262450/+merge/19483 bounced
<parthm> poolie: I am not quite sure what to make of the error. On my system it appears the sftp tests were skipped.
<parthm> 19 tests skipped
<parthm> bzrlib.tests.blackbox.test_upgrade.SFTPTests.test_upgrade_url is leaking threads among 9 leaking tests.
<parthm> Is this against 2.0?
<poolie> well this was actually an ftp test
<poolie> but they might be skipped because you need an external library to run them
<parthm> poolie: These tests were skipped for me (FTPServerFeature). Installing medusa right now.
<poolie> cool
<poolie> igc, perms are fixed
<poolie> so i now removed the thing i asked you about
<igc> poolie: thanks
<poolie> just fixing the links to 2.0 docs
<parthm> poolie: Its seems the higher perm bits were causing the problem. masking with 0777 fixes this. ie. "target.mkdir('.', stat.st_mode & 0777)" in copy_tree
<poolie> cool
<poolie> well spotted
<poolie> i've got to go now but i'll have a look tomorrow
<parthm> OK. Good day. Will push the changes.
 * igc diinner
<bialix> heya!
<bialix> hi, I have a question about teams and bugs, anybody here?
<Peng> I'm here, but I doubt I know the answer.
<bialix> np, poolie helped me already on #launchpad
<Peng> :D
<Peng> I was right, I didn't know the answer to that question. :D
<bialix> but you know answers on many others, I'm sure
<Peng> :)
<mvo> hm, bzr merge gives me a pretty confusing error message: http://paste.ubuntu.com/378919/ - am I doing something wrong or is bzr in lucid just not handling this correctly?
<Peng> Even "bzr log -r 98 lp:~lifeless/ubuntu/lucid/apt/bug-22354" fails. Perhaps the branch is screwed up?
<mvo> thanks peng, I guess lifeless needs to check, I imported the patch via a download now
<spiv> mvo: I would suspect a damaged branch
<spiv> mvo: perhaps try branching it locally, and using that copy
<spiv> mvo: and if the local copy fails, try 'bzr reconcile' on it
<spiv> mvo: (and please do file a bug)
<mvo> spiv: thanks, reported as #523703
<mvo> spiv: branching locally makes it all work it seems
<slestak> good morning.  Can I discuss a use case with someone before I set this repo up.  We have a src license for our ERP system, so we do our own enhancements and modifications.  This code is not repackaged.  The code is in 3 main dirs, one of which is a vendor branch.
<slestak> the number packages to trac are 1121, 278, and 5359.  The dir with 1121 is the most active
<slestak> for the 1121 and 278 dirs, we have a prod bracnh and test branch
<slestak> i am trying to decide between one repo with 5 dirs or 5 repos
<slestak> any advice is appreaciated
<davidstrauss> How does the Bazaar project itself merge changes into multiple stable branches?
<rubbs> slestak: I know this is a little late, but if you still need help I might be able to give you some advice to your question
<rubbs> davidstrauss: I'm not sure what you're asking. Are you asking how they merge branches into multiple "versions" of bzr? Like if a fix affects 2.0 and 2.1, how do they get the fix into both?
<davidstrauss> rubbs: exactly
<davidstrauss> rubbs: You know, without pulling other 2.0 or 2.1 changes into either.
<rubbs> I'm not a dev with commit access, so I don't know for sure, but my guess is that they keep the originating branch open and merge it in multiple branches. For example: fix_branch is merged into 2.0 and that fix_branch is kept around and then merged into 2.1. When you merge a branch in, you don't automatically lose that branch.
<rubbs> but I'm not sure if that's exactly how they do it, since I don't do it myself ;)
<davidstrauss> rubbs: but if someone branches from 2.1 and writes a fix on it, merging that branch into 2.0 will pull all the missing 2.1 changes, too
<rubbs> ah, good point.
<rubbs> unless they export the changes as patches and apply those patches in manually.
<rubbs> honestly I don't know
<davidstrauss> rubbs: but that's not a merge :-/
<Tak> davidstrauss: you can merge specific revision ranges
<davidstrauss> Tak: I'm trying to avoid cherry picking, which isn't tracked.
<fullermd> No, bzr just always completely merges branches upward.
<luks> davidstrauss: the usual approach is to do it the other way around
<luks> do fixes based on older revisions and merge them to all the necessary branches
<luks> you've probably seen it before, but this page nicely explains an extreme variant of this - http://www.monotone.ca/wiki/DaggyFixes/
<smmalmansoori> hi all, I just installed bazaar and would like to change the location where it looks for the configuration files (by default in /home/username/.bazaar), could anyone help me please?
<Kinnison> Why do you wish to change that?
<smmalmansoori> because i installed bazaar in a usb, so i'd prefer if the config files are in the usb too
<Kinnison> You can set BZR_HOME in your environment to point at the USB stick I suppose
<Kinnison> but you'll have to always do that
<Kinnison> alternatively you try changing bzrlib/config.py on the stick (specifically config_dir())
<smmalmansoori> i see, i'll give the config.py option a try then, thanx :)
<smmalmansoori> Thanks alot Kinnison! worked like a charm :D
<jam> james_w: are you still around?
<jam> I was wondering if you had a response to https://bugs.edge.launchpad.net/udd/+bug/508251/comments/3
<ubottu> Ubuntu bug 508251 in udd "Failure to import when decoding changelog authors" [Medium,Confirmed]
<james_w> hi jam
<jam> I've found the error for gnome-panel
<jam> which is iso-8859-1 data in the changelog portion
<jam> while we are searching for "[AUTHOR NAME]" sections.
<jam> I posted some possible  fixes
<jam> and wondered which you would like to see me implement
<james_w> jam: thanks for the analysis
<james_w> jam: I'm not sure what the best would be
<james_w> jam: we have to decode at some point, but deferring could work.
<james_w> jam: perhaps try: decode('utf-8') except: try: decode('iso-8859-1') except: pass
<jam> james_w: right, I was thinking to do the double try as well
<jam> james_w:  do you think it is reasonable to just do the regex match on the 8-bit string first?
<james_w> and then deferring to after we at least find [ ] would save some effort
<jam> right
<james_w> I think so
<james_w> I think there might be a reason that it is that way
<james_w> not necessarily a correct reason, but...
<jam> I think the idea was to handle re.UNICODE
<jam> but that would only matter if you were using '\w'
<anddam> hello
<jam> rather than [^\]]
<anddam> regex?
<jam> hi anddam
<jam> james_w: ^^
<anddam> hi there
<james_w> jam: sounds about right
<anddam> I'm not used to distributed VCS, can I import from a mercurial repository using bazaar?
<james_w> jam: I think it might have been to UnicodeDecodeError using re.match on 8-bit strings
<jam> anddam: there is a 'bzr-hg' plugin which should let you convert
<anddam> jam: is it a bazaar plugin?
<jam> anddam: yes
<jam> lp:bzr-hg
<jam> you'll need to have mercurial installed as wlel
<jam> well
<anddam> jam: so to me it'd be transparent, wouldn't it?
<anddam> I'm trying to pick up one in the triad and Google project hosting is something to consider
<jam> anddam: I don't think bzr-hg makes it as transparent as we would prefer
<jam> I don't think it yet supports 'round-tripping'
<anddam> thanks, I'll check out
<jam> (pull from hg, commit in a bzr branch; push back to hg; pull back to bzr)
<jam> it probably will eventually
<jam> james_w: would you like to see a trace.mutter (or warning?) if we have to trigger the fallback?
<james_w> why not?
<jam> just wondering if it is helpful or just noise
<jam> and wondering whether mutter or warning is appropriate
<james_w> I'd say mutter it
<james_w> though it probably is just noise
<anddam> bye
<mtaylor> bzr: ERROR: Tree transform is malformed [('unversioned executability', 'new-368'), ('unversioned executability', 'new-367')]
<mtaylor> sigh
<slestak> rubbs: hi, ty for seeing my previous request.  I would like to discuss it if you have maybe 10 minutes.
<rubbs> sure, I'll be in and out, but I'll always respond within a few minutes at most
<rubbs> just a sec while I re-read what you were asking again.
<rubbs> ok, I remember my question now. Do any or all of these projects share similar code and/or history?
<slestak> it is one project, with code divided in 3 dirs
<slestak> 2 of the dirs have a PROD and TEST label
<slestak> the 3rd dir is a vendor branch
<slestak> so that can be taggeed every now and then if we ugrade
<rubbs> ah, I c. so you have the Vender, testing and production branches, but they are all based off of the same "core" code right?
<slestak> yes
<slestak> what I am afraif of if I set this repo to track too many targets, it will be slow for every operation
<slestak> that is why I was thinking about maybe 3 or 5 repos.
<rubbs> then I would suggest doing a shared repo because they are going to share most of the same history. for the most part other operations won't be affected too much.
<slestak> that would make sense, the code is all one erp app
<rubbs> the advantage of having them all under the same repo (with different branches) is saving disk space and merges etc between branches would go pretty quickly
<slestak> yes.  now.  at the beginning, I am the only person motivated to use scm
<slestak> i think that will be ok, I think for a time I will just have commit statements liek "Scale is workign on the website, isse 456"
<slestak> hopefully without all the type, but not likely
<slestak> typos!
<rubbs> haha
<rubbs> I do it all the tie
<rubbs> time*
<rubbs> haha
<rubbs> not intended ^
<slestak> i joke all the time i need a speel checker
<rubbs> heh... me too.
<rubbs> but as far as your question goes, I can't really see much of a downside to setting up a shared-repo.
<lifeless> mtaylor: file a bug
<mtaylor> lifeless: ok.
<slestak> is it sane or advisable to simplify the dir structure with symlinks and version the symlinks?  i.e. instead of versioning /ud/JM/USER-FORMS and /ud/TEST/USER-FORMS.  I would version /usr/local/src/ud/L-USER-FORMS  and /usr/local/src/ud/T-USER-FORMS.  ther eare more that I would add. but i think bring them together under one dir and prefix them with their role?
<rubbs> not sure to be honest. I havne't really used symlinks much, however I know that some do. Bzr will work with symlinks. One thing to remember though is that windows can't really handle symlinks so you won't be able to have a windows user checkout a branch.
<slestak>  oh, that could be a problem
<slestak> this code is edited locally.  it must be built on the aix box, so very rarely will you have it on your workstation (besides me editing with netrw, but that doesnt coaunt.)
<poolie> hello all
<rubbs> yeah, most people don't think about that :(. If you were in a completely UNIX environment, that wouldn't be so bad, but windows doesn't seem to like to play nice with symlinks ;)
<rubbs> hello poolie
<rubbs> slestak: I would still advice against symlinks even if you are just editing on a windows machine.
<slestak> ok
<rubbs> mostly because it will be hard to checkout/branch your code to your local machine.
<slestak> so if these have a common root of /ud, the bzr repo will live in /ud/.bzr?  what if I want to pull in one dir that is outside that tree?
<rubbs> I'm not sure I understand taht question. I'm guessing you mean what do you want to do if you want to verson a directory outside of that root?
<slestak> yes, correct
<rubbs> that I'm not sure about to be honest.
<slestak> k.  ty for you help.  like someone else told me in here, just do it.
<rubbs> haha
<rubbs> always keep a backup
<slestak> get into analysis paralysis designing scm layout
<slestak> whats that.
<slestak> j/k
<rubbs> ha
<rubbs> it took me a few tries before I got everything down right on my end too, but once I got it, it was totally worth it
<slestak> once you decided to reset, how did you blow out the existing repo?  that info isnt google-able
<slestak> removeing .bzr doesnt seem to do it
<lifeless> slestak: if you have a 'shared repo' then there will be a .bzr for the repo *and* for each branch
<slestak> thats right.  i will read the fine manual again before proceeding
<rubbs> sorry, phone, but looks like lifeless took care of you.
<thrashold> Can anyone explain the difference between bzr branch and bzr checkout?
<luks> bzr checkout == bzr branch && bzr bind (more or less)
<thrashold> Thanks
<fullermd> Branch gives you a new branch.  Checkout gives you a new working tree on the existing branch.
<rubbs> branch will give you a directory containing a clone of all the history from the parent branch. A checkout will only give you a working tree (no history) of the revision specified (defaults to the HEAD).
<luks> rubbs: that's lightweight checkout
<thrashold> Which one I want if I want to work on the said branch and push changes?
<fullermd> If you want to work independently of the existing branch, you need a new branch to work on, hence `branch`.
<luks> use bzr branch unless you know you need something else
<thrashold> I don't want to work independently
<thrashold> OK, I'll rephrase my question
<thrashold> If I just pushed a branch, is the local branch binded (a checkout) or not
<rubbs> luks: ok, thanks for clearing that up for me. so heavy weight checkouts also have history, but are just bound to the parent location?
<fullermd> No.
<soren> If a bzr upgrade of a launchpad branch fails, how can I get access to the backup?
<maxb> soren: via sftp
<soren> maxb: What's the trick?
<soren> sftp://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/0.11/backup.bzr/ does not work.
<soren> (i.e. "bzr branch sftp://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/0.11/backup.bzr/" doesn't work)
<maxb> Oh, no, you can't get it via bzr
<maxb> it has to be plain sftp using a sftp client
<maxb> However, for a launchpad branch, it might be easiest to just pull the public copy, which shouldn't have been replaced with a broken copy afaik
<maxb> oh, or perhaps it has, here
<soren> maxb: The web ui certainly looks quite upset.
<soren> and bzr branch does not enjoy it either: bzr: ERROR: The branch lp:vmbuilder/0.11 has no revision None.
<maxb> soren: So, I'd probably use sshfs to mount the directory over sftp, and copy the backup.bzr using cp or even nautilus. That's because I don't know of any sftp clients I like
<rubbs> filezilla isn't too bad
<poolie> lftp is good
<soren> poolie: Does it have a recursive GET?
<poolie> soren, all you need is
<poolie> mv .bzr .bzr.broken
<poolie> mv backup.bzr .bzr
<soren> Heh.. That's true.
<poolie> but actually, it does have recursive get/put, under the mirror command
<soren> poolie: How do I trick launchpad into rescanning the branch?
<poolie> another option is hitchhiker, which uses bzr's transport layer
<poolie> hm
<poolie> that i don't know
<soren> poolie: Never mind. I'll be pushing to the branch in a second anyway, so that'll probably trigger something.
<soren> poolie: I was just curious.
<maxb> You need to do any operation which locks it
<soren> poolie: Access failed: Permission denied: "Cannot create '.bzr.broken'. Only Bazaar branches are allowed."
<maxb> LP is special - use .backup.bzr instead
<soren> maxb: Same. Access failed: Permission denied: "Cannot create '.backup.bzr'. Only Bazaar branches are allowed."
<maxb> oh, sorry, I mean .bzr.backup
<poolie> we really should make it easier to roll back
<poolie> soren: ok the crash is due to a known
<poolie> bug
<soren> poolie: Well, that's good.
<poolie> from where did you install the version you're running?
<soren> lucid, I think?
<poolie> urk
<poolie> i'll target it to lucid
<soren> Hm.. I /may/ have pulled it from Debian.
<poolie> ok 2.1.0-1 is now in lucid, and it has a fix for this.
<soren> Ok, so what do I do? Mirror the backup branch to my local box, and do a bzr push --overwrite?
<soren> It seems a big hammer, but not sure what else to do.
<poolie> let's just ask an admin to fix it on lp
<maxb> soren: mv .bzr .bzr.backup; mv backup.bzr .bzr
<thrashold> If I just branch, I can't do just 'bzr push'. What should I do to be able to do that?
<maxb> thrashold: bzr push :parent the first time, to tell bzr that this branch should push back to where it was branched from
<thrashold> maxb: Thanks, I see
<soren> maxb: That's what I tried above.
<soren> I think.
<soren> maxb: No, that's new: Access failed: No such file: u'/srv/bazaar.launchpad.net/push-branches/00/03/db/7b/.bzr.backup': [Errno 2] No such file or directory
<poolie> soren this is really https://bugs.edge.launchpad.net/bzr/+bug/317732
<ubottu> Ubuntu bug 317732 in bzr "hard to do anything with backup.bzr on a remote filesystem after upgrade" [High,Confirmed]
<soren> poolie: What's hitchhiker?
<poolie> http://packages.ubuntu.com/lucid/hitchhiker
<soren> Oh.
<jelmer> oh neat, I didn't know Jaari had packaged hitchhiker
<rubbs> sounds like an intersting package.
<rubbs> something that could come in handy...
<maxb> ftr, the most lightweight "Launchpad, please remirror my branch" incantation that I have found is:
<maxb> python -c 'from bzrlib.branch import Branch as B; b = B.open("bzr+ssh://bazaar.launchpad.net/~maxb/+junk/wibble"); b.lock_write(); b.unlock()'
<poolie> it is good
<lifeless> maxb: there is an API call to say 'mirror now'
<lifeless> maxb: or so I'm told.
<spiv> I'm pretty sure there is, yeah.
<jelmer> lp-shell should support -c
<jelmer> but it's basically:
<jelmer> lp-shell
<spiv> Although it's possible that an SSH handshake and branch lock/unlock operation is more lightweight than the LP api ;)
<jelmer> lp.people["jelmer"].getBranches()[0].requestMirror()
 * maxb is siding with spiv, unless you can write a shorter python -c '....' using launchpadlib :-)
<jam> james_w: If you are around: https://code.edge.launchpad.net/~jameinel/bzr-builddeb/unicode-author-508251/+merge/19662
<jam> hi poolie and lifeless
<poolie> hello jam
<poolie> lifeless/jam: do we have a monkeypatch-helper in selftest/
<lifeless> yes
<lifeless> two or more I think
<lifeless> there is or was one called 'patch' in the lp plugin tests
<lifeless> and vila put another one together recently - check the changelog
<jam> poolie: self.overrideAttr
<poolie> got it, thanks
<spiv> Oh, that's right.
<spiv> Thanks for the reminder, that's useful :)
<poolie> i'll add it to the testing guide
<spiv> What's the purpose of overrideAttr allowing the 'new' param to be optional?
<poolie> to set it to null?
<spiv> poolie: apparently not!
<poolie> oh, maybe to protect it against being modified later in the test?
<lifeless> so, I argued for a version that can permit deletes etc
<lifeless> jam and vila felt it was yagni; so you should consider this a useful tool but not the last word
<spiv> lifeless: I think that would be potentially nice too
<spiv> lifeless: but I also agree that it might be a yagni
<lifeless> sure, I mean it was not needed at the time
<spiv> poolie: if it's just to protect against later modifications (and that is all I can see it being useful for), I don't think it's terribly clear or convenient.
<jam> spiv: there are times when you want to set up an attribute to override, say in setUp()
<jam> but you don't know the actual value
<jam> until the test itself runs
<jam> we had specific use cases
<spiv> jam: self.overrideAttr(obj, 'attr') isn't much easier or clearer than self.addCleanup(setattr, obj, 'attr', obj.attr)
<spiv> jam: I'll grant that it is a bit easier, but to me it's much less clear.
<jam> spiv: you typed "attr" and "obj" twice, which gets ugly when it wraps over several lines
<spiv> (And the docstring fails to explain this aspect clearly too)
<jam> since the attributes are often not "attr" but "thisIsMyAttributeWhichYouAreOverriding"
<spiv> Sure.
<spiv> I'm not arguing against having a helper for this
<jam> spiv: so once you understand what "overrideAttr" is, it turns into significantly clearer code (at least as we found when applying it to the test suite)
<spiv> I'm just arguing that overrideAttr as it is now is not clear enough to be that helper.
<spiv> I'd prefer a separate "self.preserveAttr" or something
<jam> spiv: I think it falls into bikeshedding on name
<jam> etc
<spiv> And require overrideAttr to have 3 args.
<spiv> It's definitely a bit bikesheddy :)
<jam> spiv: I can see your point, we weren't 100% happy with the name, patches welcome :)
<spiv> But it's not the *name* I mind, precisely.
<poolie> i'll mention it in the guide and add a doc about that
<poolie> it should mention monkeys so you can grep for them
<lifeless> jelmer: please 'merge + commit', not 'push' when landing things in trunks.
<lifeless> jelmer: or series branches.
<jelmer> lifeless: ok
<jelmer> lifeless, oh, you're getting spammed with mainline commits?
<lifeless> jelmer: I love having the detail available, but each trunk commit should be tests passing, intact, correct copyright etc.
<lifeless> jelmer: the spam I don't mind; the left-hand-ancestry having unapproved tree-states I do mind.
<jelmer> lifeless, should I push --overwrite ?
<lifeless> jelmer: no
<lifeless> jelmer: I've done two merges, regrouping trunk appropriately.
<jelmer> k
<lifeless> lossless, you can just pull
<poolie> jam, i'd almost say we should roll back to the last version that did work correctly
<lifeless> jelmer: I keep a checkout of trunk, for the things I'm landing stuff in, so I can do the merge + commit very easily; I encourage you to do the same.
<jam> wow, trying to build the package branch for gnome-panel has so far downloaded 700MB of data
<igc> morning
<BrianBatchelder> I'm seeing a lot of "No handlers could be found for logger "bzr"" in my apache error log.  I'm running the smart server.  Question - where is the server log supposed to be?  In the root of the apache user?  There is a log there, and it updates fine if I run a bzr command as the apache user, but doesn't seem to update when the smart server is used.  Thanks.
<spiv> BrianBatchelder: I guess your apache<->bzr glue isn't configuring bzr's builtin logging
<BrianBatchelder> I think I'm using the standard setup for bzr+http.
<mkanat> spiv: Yeah, I see that error too, actually, on Mozilla's bzr server, when doing checkouts over SSH.
<mkanat> (Actually, when doing any command over SSH.)
<BrianBatchelder> I wonder if there is something missing from the "bzr-smart.py" script.  It's pretty basic.
<spiv> BrianBatchelder: you have a file somewhere that does "from bzrlib.transport.http import wsgi", and then something like "wsgi.make_app(..., enable_logging=True)"?
<spiv> BrianBatchelder: pastebin your bzr-smart.py script?
<BrianBatchelder> Wait, not "enable_logging=True"
<BrianBatchelder> Let me look at bzrlib.transport.http.wsgi
<spiv> See the examples in http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/http_smart_server.html
<BrianBatchelder> Ah, I see.  Don't have either of those last two lines.  Perhaps they came into existence in a bzr rev beyond the one we first installed.
<lifeless> jam: vfs fetching?
<jam> lifeless: downloading orig.tar.gz for every version that uses it
<jam> regardless if it was downloaded before
<lifeless> hah. oops.
<spiv> BrianBatchelder: yeah, could be
<jam> lifeless: https://bugs.edge.launchpad.net/udd/+bug/524123
<ubottu> Ubuntu bug 524123 in udd "import_package re-downloads files multiple times" [Undecided,New]
<jam> Comments on it would be appreciated
<jam> in case I misunderstand something
<jam> the full url is different
<jam> because it is based on a different upstream import
<lifeless> hmm
<jam> but the filename is the same each time
<jam> sorry, not upstream
<lifeless> so the orig tarball can differ between ubuntu and debian
<lifeless> but not within ubuntu or within debian
<jam> but "...ubuntu1" "...ubuntu2" etc
<jam> anyway, time for me to go
<lifeless> a cache by hash would be safe
<BrianBatchelder> spiv: It seems to default to "True", and yet, sill no logging.  Or, at least, VERY sparse logging.  Or I can't find the right log.
<BrianBatchelder> I'm wondering if I need to set BZR_LOG in my apache environment.
<Kamping_Kaiser> are subvertpy questions on or off topic in here?
<spiv> BrianBatchelder: yeah, you may need to set BZR_LOG
<spiv> Kamping_Kaiser: it's probably more on-topic here than anywhere else
<poolie> igc, how are you getting the 'latest blogs' onto the page? manually?
<spiv> BrianBatchelder: but the 'no handlers' warning suggests the log file isn't being opened successfully, IIRC
<spiv> BrianBatchelder: which bzr version?
<BrianBatchelder> 1.17
<igc> poolie: yes. I'm looking into generating those links as we speak
<spiv> BrianBatchelder: Ah ok.  I'd try 2.1; I think there's been some improvements to the way bzr reports problems with logging.
<spiv> BrianBatchelder: so, 2.1 probably won't fix the problem, but IIRC it will give a more informative warning
<BrianBatchelder> I'm planning on doing the upgrade at some point, but I'll need to stage it with the users.  Thanks for the info
<spiv> BrianBatchelder: I expect bzr is trying to open ~/.bzr.log, which might not be something that works depending on how your apache runs
<spiv> BrianBatchelder: but overriding BZR_LOG in your environment should fix that
<Kamping_Kaiser> spiv: i just noticed that despite the subvertpy packaging depending on libsvn >= 1.6, its still trying to build with 1.5, so i guess my question is a packaging bug for jelmer rather thena  real question
<spiv> BrianBatchelder: another option could be to pass enable_logging=False in your script, and then calling the logging setup stuff directly the way you need it
<BrianBatchelder> If I login as the apache user, bzr logs just fine to "/var/www/.bzr.log".  But logging in is certainly different than loading apache.
<BrianBatchelder> spiv: I'll take a look at the 1.17 code and see if I can do that.
<spiv> BrianBatchelder: I'd suggest just reading the source to wsgi.make_app and bzrlib/trace.py if you do that
<BrianBatchelder> That's where I've been looking.
<spiv> BrianBatchelder: sorry I don't remember enough details off the top of my head to be more helpful :/
<BrianBatchelder> This is off the top of your head?  I'm impressed!
<jelmer> Kamping_Kaiser: ?
<jelmer> Kamping_Kaiser: subvertpy can build with svn >= 1.4
<jelmer> Kamping_Kaiser, in your case it probably built against 1.6
<jelmer> but there's no dependencies other than >= 1.4 in the packaging
<Kamping_Kaiser> jelmer: odd. its bombing out. http://paste.debian.net/60441/ "NotImplementedError: Subversion 1.5 does not provide svn_string_from_stream().
<Kamping_Kaiser> "
<Kamping_Kaiser> jelmer: attempting to build the package from testing on stable
<spiv> BrianBatchelder: well, I wrote the bzr http smart server code, but it's been a while :)
<BrianBatchelder> spiv: oh, man, glad I didn't flame the smart server code!  ;-)
<jelmer> Kamping_Kaiser, oh
<jelmer> Kamping_Kaiser, we should probably disable that test
<spiv> BrianBatchelder: :)
<spiv> BrianBatchelder: don't worry, I already know that its logging is crummy :/
<Kamping_Kaiser> jelmer: how would i do that on the package, simply delete the test file?
<jelmer> Kamping_Kaiser: just the test itself
<Kamping_Kaiser> jelmer: removing the test makes it build, thanks :)
<Kamping_Kaiser> hm, python 2.4
#bzr 2010-02-19
<james_w> mwhudson: thanks for the pointer to iolaus
<james_w> lifeless: sounds similar to some of the ideas you were telling me about: http://github.com/droundy/iolaus
 * james_w crashes
<jelmer> \o/ it's in haskell
<lifeless> james_w: yes, there are similarities
<poolie> igc, re bug 524177
<ubottu> Launchpad bug 524177 in bzr "Doc rebuilds are deleting chm files" [Undecided,New] https://launchpad.net/bugs/524177
<poolie> is that some kind of problem with the scripts on escudero?
<poolie> also, when you file bugs, can you please triage them too?
<poolie> no point making someone else reopen the bug to do it
<poolie> spiv, maybe at the end of the eintr thread we should add something about it to the developer guide
<spiv> poolie: yeah
<spiv> poolie: and, assuming we keep until_no_eintr (which I think we need to for reading from pipes at least), put a very clear warning in its docstring.
<spiv> Probably with a pointer to full treatment in the developer guide.
<poolie> hm
<poolie> so until_no_eintr is a bit dangerous because it's highly likely to be needed on functions that can return partial results
<poolie> and you need to loop separately on them too
<poolie> perhaps
<poolie> i suppose it's not actively dangerous, just often not sufficient
<poolie> so a patch that describes the way these things should be handled might be a good way to get to agreement with gzlist
<poolie> just an idea
<poolie> also
<poolie> we could add a test_source for known broken apis
<spiv> Right, so until_no_eintr is right for things that are very close to the underlying syscall, or at least std libc, interface.
<spiv> But as soon as you have any layers between that and until_no_eintr it's probably wrong.
<spiv> And you either need to push the eintr handling down into a lower layer, or use a different API entirely.
<spiv> I think I am converging on agreement with gzlist.
<spiv> There was a disconnect because he wasn't aware of the pipe.read issue being a valid and appropriate use of until_no_eintr, so he was of course sure the right thing was to rip out until_no_eintr, whereas I was of course sure we still wanted it :)
<spiv> I'm not aware of a better alternative for the pipe.read than just wrapping it in until_no_eintr, but if one comes up we can evaluate that.
<lifeless> freetown2: hmm, 350mb apt-get update
<lifeless> erem grade.
<poolie> lifeless: ?
<lifeless> poolie: lucid moving fast
<parthm> poolie: I am going through your review comment https://code.launchpad.net/~parthm/bzr/2.0_376388_dot_bazaar_ownership/+merge/19593
<parthm> Does http://pastebin.com/m4d62c257 seem like a reasonable approach in osutils?
<parthm> I also plan to add osutils.open that optionally takes ownership_src arg. This can then be used succintly for creating files like log and conf.
<poolie> parthm: that looks pretty reasonable
<poolie> parthm: raise just one warning when it fails, and use trace.warning not warnings.warning
<parthm> OK. Thanks.
<parthm> I saw your comment regarding making this patch for trunk. That sounds fine to me. I am thinking that for now I will continue working on the same branch so that review comments are not lost. Then it can be merged up?
<poolie> yep
<parthm> One more question, is there a doc that lists the dependencies we need to have in order to hack bzr? I have been installing packages seperately one at a time as I hit issues (pyrex, testtools, pyftpdlib, subunit etc.).
<parthm> Due to time some tests also get skipped.
<poolie> is this on ubuntu?
<poolie> the easiest way is to say 'apt-get build-deb bzr'
<spiv> Theoretically the INSTALL file should list the dependencies, but that part of it seems to be out of date.
<parthm> Yes. Its ubuntu. build-deb sounds good. Thanks.
<parthm> Yes. INSTALL does look out of date :)
<poolie> parthm: what do you think of http://pastebin.ubuntu.com/379525/
<poolie> are there any other questions it should answer?
<parthm> poolie: This certainly answers most of my. I wasn't aware of the appendpath trick. Maybe we can have pointers for getting further help (irc, mailing list). Specifically I faced a problem getting into irc (i am new to it) as it required a registered nick, I kept getting "cannot send" messages before I googled and realized what was happening.
<poolie> yeah that kind of sucks actually
<poolie> i'll add some pointers
<parthm> Maybe somewhere a tip can be put in regarding avoiding "resubmit merge request" as comments are lost. I made that mistake.
<parthm> The doc looks good.
<parthm> I seem to have hit upon an interesting situation. http://pastebin.ubuntu.com/379534/ Not sure what I did (maybe ^C of some test?), I ended up with some unknown file/dir which don't exist on disk. How do I get rid of it?
<spiv> parthm: that's pretty weird.
<poolie> lifeless: did you or anyone already register #bzr with freenode?
<lifeless> poolie: yes years ago
<poolie> did you register the group too?
<lifeless> don't know what you mean
<poolie> ok, that works
<lifeless> I've just added you to the channel access list though
<poolie> http://freenode.net/group_registration.shtml#groupcontacts
<lifeless> what does that mode do ?
<poolie> allows non-registered users to talk
<poolie> isn't it obvious? ;-)
<parthm> Nice :)
<lifeless> poolie: no, its not :P
<lifeless> poolie: you might like to drop op though; and tell chanserv the mode bits you want, otherwise netsplits can confuse things.
<lifeless> poolie: [dropping op because freenode frown on folk sitting with op on for extended durations, telling chanserv so that it sticks properly]
<poolie> ok
<poolie> >  freenode frown on folk sitting with op on for extended durations
<poolie> why?
<lifeless> something about community spirit; I don't recall really.
<lifeless> http://freenode.net/using_the_network.shtml
<lifeless> Use the chanserv "op" command to obtain channel operator status only when needed. This will help to keep your channel temperature low and reduce conflicts.
<lifeless> </quote>
<parthm> poolie: I plan to send a new merge request for 2.0_376388_dot_bazaar_ownership against the trunk. Its seems overrideAttr are not available in 2.0. I will be using them for writing the tests as you suggested.
<poolie> hm
<lifeless> poolie: /msg chanserv access #bzr list -- thats what I looked at when you asked, and you weren't there so I did
<poolie> yeah, i see
<lifeless> access #bzr add poolie
<poolie> i think all the core devs should have access
<lifeless> I don't know if that makes you fully-capable; I don't  know enough to tell.
<lifeless> I suggest you try adding e.g. jam
<poolie> 'flags #bzr' gives more linenoise
<lifeless> if you can't I'll dig deeper to find out how to make you as-capable as me
<poolie> hang on
<poolie> so you have also sRA bits
<lifeless> I don't know what they mean
<poolie> and f
<lifeless> I didn't want to randomly type stuff in until I check
<lifeless> are you able to add jam ?
<poolie> oh go on :-P
<cody-somerville> +f - Enables modification of channel access lists.
<cody-somerville>  +F - Grants full founder access.
<poolie> send chanserv help flags
<poolie> so i think i can't grant access, but i'll try
<poolie> yeah, i can't grant rights
<poolie> so i think i need you to do
<poolie> flags #bzr poolie +*
<lifeless> poolie: you look the same as me now
<poolie> ew
<poolie> sweet, thanks
<cody-somerville> poolie, lifeless: You guys should get the +F flag from Christel (who is a freenode staff member IIRC).
<lifeless> cody-somerville: thanks for helping out
<poolie> cody-somerville: by asking christel, i suppose?
 * cody-somerville nods.
<cody-somerville> lifeless, Is that a polite way of telling me to bugger off? :=)
<poolie> seems away atm
<poolie> no, seriously, thanks
<cody-somerville> If you guys register yourself as a group, you can get your own cloaks and then you grant anyone with that cloak certain privileges (ie. ops).
<Kamping_Kaiser> jelmer: out of intrest, does that subvertpy test need disabling in testing/unstable or only stable?
<poolie> cody-somerville: right, i was just asking about that too
<poolie> i wonder if we should register our own group or be subsidiary to canonical
<lifeless> cody-somerville: no, its me saying thanks
<poolie> istr some mail about this
<lifeless> cody-somerville: I so rarely look at IRC modes it all pages out.
<lifeless> poolie: I think we should be like ubuntu, or perhaps subsidiary to ubuntu - more than staff can help.
<lifeless> cody-somerville: besides which, I have no politeness chip.
<poolie> their policy seems to prefer a company
<lifeless> whose?
<poolie> freenode's policy
<lifeless> hmm, odd.
<poolie> ok, so it's filed now
<poolie> we'll see
<cody-somerville> poolie, Ubuntu is a registered group.
<poolie> i'm glad that's sorted
<poolie> ok, i tried to register Bazaar c/o Canonical
<cody-somerville> poolie, You have a cloak of canonical/launchpad/poolie
<poolie> and i granted flags to some core devs
<lifeless> cody-somerville: are cloaks like bitmasks ?
<cody-somerville> lifeless, They mask your hostname
<lifeless> yes I know that
<lifeless> but their value
<lifeless> can you have e.g. canonical/launchpad/ubuntu/fsf/bazaar/lifeless
<lifeless> oh, add debian
<poolie> i think they are hierarchical
<lifeless> hmm thats a bit annoying
<lifeless> community membership is more setlike
<poolie> one propeller beanie at a time please
<lifeless> or can you choose amongst many cloaks you have permission to use ?
<lifeless> (at login time I mean)
<cody-somerville> You can only have one but you can combine them - although its a bit awkward.
<cody-somerville> Some people have: pdcp/supporter/ubuntu/member/$nick
<cody-somerville> and what not.
<poolie> k
<poolie> so more to the point is """[+o]  attracts the attention of participants who react negatively to authority. Have your nick added to the channel access list and op yourself only when needed. """
<lifeless> http://web.media.mit.edu/~marcelo/cornucopia/
<mneptok> poolie: OH, LOOK AT *YOU*, MISTER IMPORANT!
<poolie> see
 * mneptok pouts in the corner
 * cody-somerville recommends a script created by Dennis Kaarsemaker, http://www.kaarsemaker.net/downloads/code/chanserv.py
<parthm> I am getting two failures while running blackbox selftest on unmodified trunk http://pastebin.ubuntu.com/379546/ . Is this expected?
<mneptok> IIRC, i had a /canonical/staff Freenode cloak when i was an employee
<lifeless> cody-somerville: sadly its for xchat :P
<lifeless> parthm: no, because pqm selftests trunk on every commit
<mneptok> i think "canonical/staff/bzr" would look sexy on poolie
<poolie> that's pretty strange
<poolie> i pick up my wizard staff and cloak
<spiv> parthm: hmm, both in "expectFailure"
<mneptok> while lifeless should get canonical/staff/i/get/around/more/than/a/monaco/hooker
<spiv> parthm: what version of testtools do you have?
<poolie> k
<poolie> so that's done
<lifeless> mneptok: how much does a monaco hooker get around?
<poolie> now i don't need to document
<parthm> spiv: testtools-0.9.2. I installed it locally from a downloaded tarball.
<poolie> ok, i think this ^^ is exactly what i was reading about inappropriate behaviour :)
<mneptok> lifeless: my memories of that time in my life are kinda hazy ...
<mneptok> wait ... was that out loud?
<poolie> but presumably in their maserati
<spiv> parthm: hmm, that's what I have (well, a deb saying 0.9.2-1, from the bzr PPA IIRC)
<lifeless> spiv: doesn't look like testtools to me ?
<lifeless> its interesting that some extensions are not built
<lifeless> parthm: try running 'make'
 * parthm running tests again after make
<spiv> parthm, lifeless: FWIW, trunk with and without extensions passes those tests for me, as known_failure
<lifeless> ah
<lifeless> could be testtools then, but that version should be fine
<parthm> I see the same failures even after make. :(
<lifeless> parthm: are you sure that version of testtools is being loaded?
<spiv> parthm: what if you don't use --parallel=fork?
<spiv> (and what version of subunit?)
<poolie> parthm: you can vote on https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/19682 if you want; I put in your suggestions
<lifeless> oh, I didn't realise subunit was in there. Smells like an old subunit perhaps.
<spiv> lifeless: neither did I at first, but parthm sensibly included the command line in the paste :)
<parthm> lifeless: Yes. I see the correct path in the error log.
<parthm> subunit is 0.0.2 from packages
<lifeless> poolie: as a potential user, you might like https://code.edge.launchpad.net/~lifeless/testresources/bug-522338/+merge/19684
<lifeless> parthm: thats pretty old
<lifeless> parthm: what platform are you on?
<parthm> poolie: will do. thanks.
<parthm> lifeless: I am using ubuntu 9.10
<parthm> will run again w/o fork.
<lifeless> parthm: you might want to grab the subunit PPA, it has newer subunit, testtools all packaged
<poolie> maybe we should add a version assertion to bzr?
<lifeless> poolie: it doesn't turn up all that often. We can if you like
<poolie> maybe next time
<parthm> yep. subunit was the problem. all tests pass without fork. will install the latest ppa.
<parthm> i agree with poolie, it would be good to have a version check. for someone new to bzr codebase its very helpful if the error message clearly indicates this.
<parthm> thanks for the help
<parthm> got to go. have a nice day!
<Kamping_Kaiser> james_w: bzr-builddeb from testing fails to build on stable ( http://paste.debian.net/60457/ ). Would this be a dependencies issue, or is the setup.py file actually broken?
<quicksilver> Hmm. bzr missing defaults to 80 cols with no terminal on stdout?
<quicksilver> that seems nasty.
<lifeless> quicksilver: it defaults to your terminfo
<lifeless> and if there is no terminal, we use something that will often be sensible
<lifeless> Kamping_Kaiser: possibly a parser change in rst
<quicksilver> I'd hoped --line would default to infinitely long lines
<quicksilver> (if there was no terminal)
<lifeless> we did that for about 3 days
<lifeless> after gigabytes of output in test runs it got changed
<quicksilver> ok :)
<lifeless> I can see your argument, perhaps file a bug - we may have solved our issue the wrong way.
<Kamping_Kaiser> lifeless: rst?
<lifeless> you could mention that other tools defaults to no-apparent-limit (if they do)
<lifeless> Kamping_Kaiser: ReST - restructured text
<Kamping_Kaiser> oh
<lifeless> the language README is written ni
<mneptok> NI!
<Kamping_Kaiser> lifeless: would that be bzr's rest parser? I'll check the changelog incase theres some info
<lifeless> no
<lifeless> python module
<Kamping_Kaiser> ok
<quicksilver> lifeless: what I'm actually doing is writing a command line tool to analyse a bunch of repos with --missing and deduce some things about their topology.
<quicksilver> lifeless: like, which ones have already been merged into "mainline", and which of the non-merged ones shared common parents, etc
<quicksilver> lifeless: are you aware of any prior art?
<lifeless> quicksilver: bzr removable
<Kamping_Kaiser> lifeless: looks like its a stray space. whats the preferred way of submitting trivial changes? patch? bzr branch?
<quicksilver> lifeless: thanks. Interesting. I had slightly more ambitious plans but that's definitely the basic function.
<Kamping_Kaiser> (used a patch :))
<lifeless> Kamping_Kaiser: 'whatever works'
<lifeless> poolie: the apt-cache policy bug is committed to apt trunk
<poolie> great
<lifeless> very small patch for being open for 5 years :(
<poolie> many are
<poolie> i'd like to do a scatterchart of (open_time,close_time)
<ejat> hi .. anyone can help me with this bug 524269
<ubottu> Launchpad bug 524269 in bzr "cant bzr update in development trunk" [Undecided,New] https://launchpad.net/bugs/524269
<naoki_> Hi
<naoki_> http://paste.ubuntu.com/379585/
<naoki_> bzr branch svn+ssh://...  fails on Windows.
<naoki_> I think it isn't a bug of bzr-svn.
<ejat> lifeless: thanks for changing the description .. so confirm its a bugs ?
<lifeless> ejat: doubt it
<lifeless> ejat: I suspect you're missing ca-certificates or something
<naoki_> I read strace. All opened fd is closed correctly.
<naoki_> I can't find a suspect.
<poolie> naoki_: hello!
<lifeless> naoki_: disable your virus scanner
<poolie> the first error looks like one we fixed recently
<poolie> lifeless: you're probably right but that's such a bad thing to have to say :-/
<lifeless> naoki_: its not hooking in at a low enough level, so it is interfering with normal system calls
<lifeless> poolie: it is; I blame microsoft.
<ejat> lifeless: sorry .. after upgrade .. im missing the bzr-svn .. after reinstall bzr-svn .. working fine
<ejat> lifeless: can i change the status to invalid ?
<lifeless> I hope so
<poolie> lifeless: i mean other apps must hit this
<poolie> writing a file then reading it is not such a strange thing to do
<poolie> perhaps we should show a message and block
<lifeless> poolie: sure
<naoki> In linux, strace shows close() correctly.
<naoki> But in Windows, Process Monitor desn't show CloseFile!
<poolie> interesting
<naoki> http://paste.ubuntu.com/379598/
<naoki> In line 86, CreateFile failse. (rename)
<naoki> In line 85, WriteFile happens to pack file.
<naoki> There are no CloseFile between line 85 and 86.
<naoki> http://paste.ubuntu.com/379599/
<naoki> This is strace in Linux.
<naoki> write(7, "E", 1) is writing 1 byte.
<naoki> next, close(7), and then, rename() happens.
<lifeless> poolie: I've fixed the sort performance in testresources
<poolie> mm i saw
<poolie> i wonder if the effort estimates are actually accurate enough that it's worth sorting carefully
<lifeless> poolie: well, it takes 0.02 seconds to sort for u1 now
<lifeless> so there is room to grow :P
<lifeless> anyhow, its not sorting carefully now
<lifeless> its sorting quickly
<lifeless> poolie: you might find http://www.youtube.com/watch?v=1HatEDkNnn8 and the related videos interesting
<poolie> igc, you really don't have to finish the explorer bug tonight
<jelmer> Kamping_Kaiser, it needs disabling when subvertpy is built against svn < 1.5
<Kamping_Kaiser> jelmer: <= or < ? I thought i had 1.5.1, since its a stable system
<jelmer> Kamping_Kaiser, <
<Kamping_Kaiser> hmm. most odd.
<naoki> I want subvertpy binary package...
<jelmer> naoki: for windows you mean?
<naoki> Yes
<jelmer> naoki: Isn't subvertpy included in the windows installer?
<naoki> Yes. But I test bzr-svn with python2.6 and python2.5 I have.
<naoki> Yes. But I'd like to test bzr-svn with python2.6 and python2.5 I have.
<naoki> Wow! I can build subvertpy!
<naoki> I can reproduce svn+ssh: problem with Python 2.6...
<jelmer> which problem?
<naoki> In Windows, bzr branch svn+ssh://.../foo foo fails.
<naoki> svn+http is OK. In Linux, all OK
<naoki> traceback is http://paste.ubuntu.com/379585/
<naoki> strace in Linux is http://paste.ubuntu.com/379598/
<naoki> Procmon in Windows is http://paste.ubuntu.com/379599/
<naoki> In Linux, close() called after last 1-byte write()
<naoki> In Windows, CloseFile() isn't called after last 1-byte WriteFile()
<naoki> So rename() fails.
<jelmer> naoki: that doesn't seem related to bzr-svn
<jelmer> it happens deep down in bzrlib (though it's perhaps masking another error from bzr-svn)
<lifeless> naoki: have you tried turning off your virus scanner? just to see?
<naoki> I've disabled auto-protect feature in AntiVirus. But I can't totally disable AntiVirus because I am using my company's PC.
<lifeless> the lack of a close is interesting though
<lifeless> perhaps a generator in the svn side not completing appropriately
<radoe> jelmer: is the usage of --layout=trunkX (like trunk2) documented somewhere?
<jelmer> radoe: What layouts are available you mean?
<jelmer> "bzr help svn-layout"
<radoe> jelmer: no, I had to used --layout=trunk2 to be able to svn-import a somewhat weird svn repo. And Ihad to look into the source to figure this out, as it is not mendtioned anywhere. bzr help svn-layout only mentions trunk without an additional level.
<radoe> Hm, my connection has some serios lag, sorry for the typos...
<jelmer> the 2 just means two levels of directories before the actual branches
<radoe> jelmer: yes, I figured this out, but had to look into the sources to get it. And I'm not sure why I had to use it anyway, because my trunk/branches are directly below the URL I specified. Let me explain about layout used in SVN a bit...
<radoe> jelmer: The repo root used is svn+ssh://app/svn/instsrv. The repository has a /packages directory, which holds individual packages, like nagios-client
<radoe> jelmer: so I tried to svn-import like "bzr svn-import svn+ssh://somehost/app/svn/instsrv/packages/nagios-client"
<radoe> jelmer: and got the error  "
<radoe> "bzr: ERROR: The specified path is inside a branch."
<jelmer> radoe: svn-import imports all branches in a repo or all branches under a specific directory
<jelmer> radoe, it looks like you're trying to retrieve an individual branch
<radoe> jelmer: i had to specify layout=trunk2, simply trunk did not work (same error)
<jelmer> radoe: for an individual branch, use "bzr branch svn+ssh://somehost/app/svn/instsrv/packages/nagios-client nagios-client"
<radoe> jelmer: well, like I said, the repo is somewhat weired. It holds different packages below /packages, each with trunk and branches.
<jelmer> radoe, what is the repo root?
<radoe> jelmer: svn+ssh://somehost/app/svn/instsrv/
<jelmer> radoe, does it say it's using trunk2 when it starts?
<radoe> jelmer: I had to specify trunk2 explicitly like in "bzr svn-import --layout=trunk2 svn+ssh://rdoering@zsl01/app/svn/instsrv/packages/nagios-client" to get what I want.
<jelmer> radoe: Does the repository also have parts that do not follow the branches/tags/trunk convention?
<jelmer> or perhaps at different levels?
<jelmer> that would confuse the heuristics
<radoe> jelmer: possible, let me check...
<radoe> jelmer: below /packages/*/ there is always a trunk, only some have a branches/ dir
<jelmer> radoe, and packages is the only top-level directory?
<radoe> jelmer: no, I'm lookiong at the others currently.
<radoe> jelmer: ah, in parallel to /packages there are two directories which qualify for trunk1 layout.
<Ng> why would bzr think a file has been removed/added when its md5sum hasn't changed?
<Peng> Because you did "bzr rm" and "bzr add"?
<Peng> Or an equivalent merge?
<Peng> There's more to a file's identity than its contents.
<Ng> I'm merging an update from my pristine upstream branch into my local modified branch, but I haven't explicitly rm'd/add'd these files
<Ng> normally when I do this it just merges in the upstream changes
<beuno> Ng, maybe the merge deletes it?
<Ng> http://paste.ubuntu.com/379718/ that's the pristine branch, with a diff of the revision that relates to the bzr import of the new release zip
<Ng> skipping down to the bottom of that, version.php - after the merge that change shows up as a full conflict
<Ng> not the whole file, just that one line. I'm sure that's within bzr's merging abilities, it always has been before
<Ng> I wonder if this is some subtle, barely visible side effect of bzr import
<beuno> hm
<beuno> james_w may know
<james_w> whu?
<james_w> Ng: I'm not too sure
<james_w> Ng: why do you say bzr thinks a file has been removed/added?
<Ng> james_w: hmm, that might actually just be fallout from trying to correct the conflicts. I just branched afresh and did the merge and it looks more like it thinks that lots of files that are already in the branch have been added
<naoki> I got it!
<naoki> plink.exe have an pack file handle!
<james_w> Ng: can you show me the bzr status of the fresh merge?
<Ng> james_w: http://paste.ubuntu.com/379723/ is the merge itself, http://paste.ubuntu.com/379724/ is bzr st
<moldy> hi
<james_w> Ng: it seems like the root id of your tree changed somehow
<james_w> that's not usual
<moldy> is there decent bzr completion for zsh yet?
<james_w> Ng: I assume that you don't do anything odd on your branch, and the pristine branch just uses "bzr import" each new version?
<Ng> james_w: correct
<james_w> Ng: care to run a couple of bits of python for me?
<Ng> james_w: sure :)
<james_w> Ng: python -c "from bzrlib.branch import Branch; print Branch.open('.').basis_tree().path2id('')"
<james_w> run that in both branches
<Ng> james_w: both say TREE_ROOT
<james_w> oddness
<james_w> Ng: not different tree roots then apparently
<james_w> lets try all the file ids changing
<james_w> python -c "from bzrlib.branch import Branch; print Branch.open('.').basis_tree().path2id('license.txt')"
<james_w> in both again please
<Ng> ok those are different
<james_w> ok
<james_w>  python -c "from bzrlib.branch import Branch; b = Branch.open('.'); rev = b.revision_history()[-2]; print b.repository.revision_tree(rev).path2id('license.txt')"
<james_w> that in the pristine branch please
<james_w> should print the same as the working branch did
<Ng> huh, no, it's still different
<Ng> I can make both branches available if that would be helpful, there's nothing secret in either
<Ng> I hope the answer isn't that I'm doing something stupid ;)
<james_w> I can take a look
<james_w> easier than IRC-RPC
<Ng> hehe
<Ng> http://mairukipa.tenshu.net/~cmsj/bzr-wat.tgz - "www" is the working tree, "wordpress" is the upstream imports
<naoki> Ping: jelmer
<jelmer> naoki: pong
<naoki> I foud ssh client have "upload/xxxxx.pack" handle.
<naoki> I tried cygwin ssh and plink (PuTTY)
<naoki> Both client have pack file handle.
<naoki> bzr branch from svn+ssh success if I kill ssh client before renaming ".pack" file.
<naoki> Is there any way to kill source.transport connection before groupcompress?
<naoki> Or bzrlib should not rename but copy .pack file?
<jelmer> naoki: why would that be necessary?
<naoki> Because commit_write_group() renames .bzr/repository/upload/randomname.pack
<naoki> So ssh client should not have the handle of the file.
<bialix> hi naoki, jelmer
<naoki> hi
<jelmer> naoki: The ssh client doesn't handle the bazaar packs at all
<naoki> I don't know why ssh client have a handle of pack file.
<naoki> But procmon tells me the ssh client have the handle.
<naoki> And I success to branch when I kill the ssh client.
<bialix> naoki, can you convert your patch for unicode Popen to merge proposal?
<bialix> this is related to bzrlib
<naoki> Okey, I'll do. bialix
<bialix> naoki: about SSH: do you have a real reasons to prefer plink over pageant?
<naoki> I use pagent daily. So I set SVN_SSH=plink.
<naoki> Is there way to use paramiko with ssh?
<naoki> I've tried http://sshwindows.sourceforge.net/
<naoki> But ssh.exe also grip a handle of pack file.
<bialix> sorry, I meant paramiko
<naoki> Very very strange..
<bialix> svn has no pack files, right?
<naoki> Procmon tells me only ssh client have the handle when renaming.
<naoki> # I added "time.sleep(100)" in front of rename()
<jelmer> naoki: It's inheriting handles from the parent process perhaps?
<naoki> Oh
<naoki> How libsvn sucks!
<jelmer> naoki: I don't know, just speculating
<naoki> Can paramiko do port forward?
<naoki> sorry, port forward cant convert svn+ssh://remotehost to svn://localhsot
<jelmer> naoki: you can't use paramiko for svn+ssh
<jelmer> naoki: you need to have a ssh executable
<jelmer> naoki: svn and svn+ssh are different protocols
<james_w> Ng: so, there's something a little odd going on here
<james_w> Ng: I can't pinpoint any bugs. Is there a chance you had this happen before and dealt with it?
<maxb> *blink* Why can't you use paramiko for svn+ssh?
<Ng> james_w: it's not impossible, but I don't immediately remember anything obviously weird happening previously
<james_w> Ng: ok
<james_w> Ng: something a bit odd happened when you merged the last couple of versions, but I can't really work out what
<jelmer> maxb: Because we call out to libsvn
<jelmer> maxb: and that just invokes ssh.exe
<maxb> oh, I see
<Ng> james_w: thanks for looking. If it was you, would you manually fix up this merge and keep using these branches, or reconstruct the working one from a fresh copy of the pristine branch?
<james_w> Ng: I'd fix up
<james_w> Ng: have you modified any of the files that it is complaining about?
<Ng> james_w: I don't think so. I can imagine I might previously have removed things like license.txt, but I shouldn't have any changes in the php/css stuff
<james_w> you did remove license.txt :-)
<james_w> in that case it's pretty much in the situation you want moving forwards
<james_w> as merges from the pristine branch should be much more happy now
<Ng> james_w: ok, thanks :)
<naoki> afk
<naoki_> apr_proc_create uses CreateProcessW(bInheritHandles=TRUE)
<naoki_> libapr/threadproc/win32/proc.c
<naoki_> libsvn uses this function.
<naoki_> http://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx
<naoki_> Inheriting handles is required for pipe.
<naoki_> So, libsvn and libapr is not wrong.
<naoki_> One option is killing connections before commit_write_group().
<naoki_> Second option is pooling enough connections before start_write_group()
<naoki_> Any other solutions?
<jelmer> naoki: we shouldn't kill connections before commit write group, there might be more actions the user would like to do
<jelmer> Why would pooling connections before start write group help?
<naoki_> when start write group, bzr creates pack file.
<naoki_> A handle of the pack file is inherited to ssh client process.
<naoki_> When commit_write_group, bzr renames the pack file.
<naoki_> ssh client blocks renaming.
<jam> naoki: if you set BZR_SSH=paramiko it will use pageant as well
<jam> and avoid spawning a separate process
<jam> ah, but jelmer is saying you need an actual ssh process...
<jelmer> you can set BZR_SSH but that will just be ignored :-)
<jam> naoki_: what about a pre-exec function that closes the extra file handles
<jam> all you need is stdin/stdout, right?
<naoki_> libsvn creates ssh process. We cannot control it.
<jam> well, we could have an ssh wrapper
<jam> jelmer: does it need something explicitly called 'ssh' ?
<jelmer> you can set a different executable in ~/.subversion/config
<naoki_> or SVN_SSH environment
<naoki_> But how the wrapper release handles?
<jam> naoki_: so we could set SVN_SSH before we call out to svn+ssh
<jam> naoki_: well, given that there is a program that can ask Windows what program has what files open, I'm sure you can enumerate your own file handles
<jam> I don't know the functions
<jam> this: http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/37dc9843-2583-41fc-8260-b78183aa4bed
<jam> says there is NtQuerySystemInformation
<jam> also: http://stackoverflow.com/questions/733384/how-to-enumerate-process-handles
<jam> naoki_: possibly we could also open the file handle with "DELETE_OK" and possibly a rename-ok?
<jam> it seems surprisingly ugly: http://www.techreplies.com/development-resources-58/enumerating-handles-processes-c-like-procxp-782021/
<naoki_> How about try rename, catch PermissionDenied, and then copy instead of rename?
<slicslak> any macosx users here?  should I d/l bzr or use macports?  i prefer macports but I don't want to use it if the port isn't maintined well (It appears to be a few versions behind atm)
<naoki_> In NewPack.finish()
<naoki_> http://paste.ubuntu.com/379852/
<mobby> Hi, sorry if this is the wrong place to ask this so feel free to point me in the direction (politely ;-) but I would like to know a bit more about co-located branches Bazaar.
<mobby> I don't know anything about co-located branches so you will have to have some patience :)
<mobby> Really my question is... How do colocated branches work? Or more specifically as a developer how would I use co-located branches day-to-day
<rubbs> mobby: I'm not an expert, and I"m not too sure how they would work in Bzr, but colocated branches allow for multiple branches within the same directory
<jam> naoki_: given that the file may be >>GB in size, I'm not particularly happy with that solution, but it would be possible
<jam> when does it get deleted, though?
<rubbs> git does this by having all of the repo information in one directory and you "switch" between the different branches.
<rubbs> mobby: every time you switch you reload the working tree.
<mobby> ah rubbs that the bit that I was really wondering about
<rubbs> mobby: IIRC it would also let you have a project within a project.
<jam> mobby: so the way *I* do it isn't exactly colocated. I set up a shared treeless repository (bzr init-repo --no-trees) and then a single working tree (bzr co --lightweight trunk work)
<jam> and that point you can create new branches cheaply
<jam> and switch between them
<jam> the colo: plugin does something akin to this
<jam> only puts the branches under a new namespace "colo:" and hides them under .bzr/branches IIRC
<rubbs> jam: just curious is this also the answer to the "externals" question?
<jam> the main reason I prefer not having them colocated
<jam> is that I can have *multiple* working trees sharing the same set of branches
<mobby> yeah I saw the colo plugin, which intrigued me but I couldn't find much information for what it was all about and hence me coming here
<jam> which I use fairly often
<jam> I have a 'work' which is my primary action item, and then an 'alt_work'
<jam> So if I work on a bugfix, and submit it for review, I'm on to the next
<jam> but the review needs some minor tweaks before landing
<jam> so alt_work gets switched, fixed, submitted
<jam> without disturbing the current work
<jam> rubbs: do you mean bzr-externals ?
<rubbs> jam: ah, I haven't looked into that recently. I'll go check it out.
<mobby> so I suppose the co-located branch thing works best with branches of the same project rather than branches of differing projects?... I have a feeling I might have asked a stupid question there...
<rubbs> mobby: not a dumb question because I was a little confused. it works best with branches of the same project.
<mobby> ah ok cool. thanks.
<rubbs> np
<jam> mobby: 'it works best' because switching a tree to an unrelated one takes a lot of effort
<jam> otherwise we don't specifically care
<mobby> so rather than having folder upon folder of branches for each bit of work you are doing you can just have one folder which is the working tree and when you swicth branches the working tree files are updated to reflect that branch?
<jam> mobby: right
<rubbs> mobby: correct
<rubbs> jam: you beat me to it ;)
<jam> (with or without the colo: plugin, as mentioned)
<mobby> ah great thanks! Yeah that does sound good.
<rubbs> mobby: I believe it was created to reflect a more git-like workflow.
<rubbs> and that is the way git works (more or less)
<mobby> so I suppose if you had uncommitted changes in the working tree, if you switched you would lose those changes (if it doesn't warn you)?
<jam> mobby: generally it preserves them
<jam> with the idea that you may be switching to a new branch to put those changes
<jam> (like a bugfix, etc)
<rubbs> mobby: if it doesn't do what you want, you could potentially use shelve to get around the default behavior
<mobby> yeah sorry my VCS knowledge is pretty much reserved to CVS and SVN as that is what I've been using in working life. I decided that I would look into others, found Bazaar and think it is really very good. Thus I;ve been trying to improve my knowledge of Bazaar and its capabilities
<mobby> oh that;s cool it preserves them
<mobby> thanks guys for your help.
<rubbs> mobby: don't apologize for learning ;) I just thought I'd point that part out, didn't mean to make you feel ignorant.
<rubbs> np
<awilkins> SVN does switching between branches, but it's merging is painful
<mobby> no you didn't make me feel ignorant at all, I've learnt a lot in just a few mins :)
<mobby> yeah that's the other thing even my SVN knowledge is fairly limited as works process has not required further investigation into features
<rubbs> good to hear! I think I can speak for both jam and myself when I say we like to help people learn about bzr.
<mobby> I started trying to think of better ways of working, started learning about Bazaar, found out what VCS's can do (and realised how little I knew) and I've enjoyed using bazaar. I'm just trying to get as confident with it as possible so I can recommend its use in the compant i work for
<aleksander_m> does 'bzr send -o patch.merge' include always by default the patch preview?
 * awilkins now has to install Vista (sob)
<naoki_> os.O_NOINHERIT avoids HANDLE inheritance
<aleksander_m> the mini-tutorial says that it 'usually' contains the patch preview, but I cannot get it included
<mobby> Thanks again for the help guys. Bye.
<jam> naoki_: I thought you had to inherit handles to get pipes
<james_w> hi jam
<jam> hey james_w
<james_w> I'd like to merge https://code.edge.launchpad.net/~jameinel/bzr-builddeb/changelog-parser/+merge/18557 but I don't understand one of the comments in the file
<jam> k
<james_w> there's a comment in there asking about it
<jam> james_w: the strict=True stuff?
<jam> so the BASE file is used as a reference
<jam> but its content won't ever be put into the final changelog file
<james_w> # BASE lines don't end up in the output, so we allow strict=False
<jam> james_w: so we determine if THIS or OTHER should be used, based on whether they match BASE
<jam> (if one matches BASE, then the other gets chosen)
<jam> however, only THIS or BASE content is ever put into the file
<james_w> right
<jam> my idea was that
<jam> if someone went through and cleaned up old content
<jam> such that it now passes strict
<jam> but didn't used to
<jam> then we can still use the advanced merging
<james_w> I think that makes sense
<james_w> thanks, merging now
<jam> james_w: I'm currently testing the md5sum caching logic
<james_w> I just used the old code in a merge and got confused by it not conflicting on anything
<jam> I have a patch, but want to make sure it works properly
<james_w> great
<james_w> which approach did you choose>
<james_w> the "correct" way?
<jam> download .dsc, compare md5sums for files that are on disk
<jam> I think that was the correct way
<jam> anyway to avoid downloading the .dsc ?
<jam> though probably if it requires an extra round trip, we don't win
<james_w> not really
<james_w> they are small, so yeah, it's just round trip costs
<james_w> we should only download a .dsc once though
<jam> well, once per run at least
<james_w> well, twice for syncs, but yeah, that can't be avoided
<jam> ... why did it delete all of the old downloads?
<jam> is that the cleanup when finished stuff?
<james_w> yeah
<jam>  :,(
<jam> :'(
<james_w> I don't want the entire history of Debian and Ubuntu on jubany
<jam> sure
<jam> messes with my work, though :)
<james_w> you could change it to download in to the updates dir if that's not what it is doing
<jam> well, my testing
<james_w> then when you use --no-push they will stick around
<james_w> and it will then just download the .dsc each time
<jam> it downloads into updates, but even with --no-push they went missing
<james_w> anyway, changelog merge improvements merged, thanks
<james_w> ah, maybe there's a finally block at a lower level too
<james_w> that's probably worth removing once we have the cache
<james_w> that's a win wherever it is used
<jam>         if commit_db.has_commit_started():
<jam>             revid_db.cleanup_last_run(cleanup, push_back)
<jam>             commit_db.finish_commit()
<jam> that cleanup includes an rmtree
<james_w> oh, yeah, so not a win
<james_w> we could make the cleanup smarter then
<jam> james_w: so how does that all work. You have  a global sqlite file, and if you start working on a package import, but don't finish it, the next run you nuke the wohle directory?
<jam> what is the rationale?
<jam> just that you can't trust the intermediate steps?
<james_w> yeah
<james_w> I wasn't confident that the work wouldn't be in some inconsistent state
<james_w> if bzr is atomic, and bzr-builddeb makes use of that in the correct way then we could just carry on
<james_w> but I wasn't confident in that
<jam> genearlly bzr is atomic
<jam> generally
<jam> however, I also see this:
<jam> if push :commit_db.start_commit()
<jam> with *no* matching finish_commit()
<jam> argh
<jam> I missed the else:
<jam> http://paste.ubuntu.com/379881/
<jam> so it seems that when starting, we nuke the old content
<jam> unconditionally
<jam> either we first rollback, and then nuke it
<jam> or we just nuke it
<james_w> cleanup_last_run is misnamed
<james_w> it's finish then cleanup
<james_w> I think
<jam> well, it checks if there are rows in the db
<jam> and if there are or aren't it calls cleanup_cb()
<jam> so all code paths lead to cleanup
<jam> which rmtree(updates/<PACKAGE>)
<james_w> ah, yeah, we always cleanup
<james_w> you're right
<james_w> which would interfere with any caching of the packages
<naoki_> I've made patch and report bugs
<naoki_> https://bugs.launchpad.net/bzr/+bug/524560
<ubottu> Ubuntu bug 524560 in bzr "bzr branch from svn+ssh fails on win32" [Undecided,New]
<jam> well, at least it shouldn't re-download files in a single run
<jam> which is better for me
<jam> but it would be nice to not re-download them between runs, since I'm using --no-push so lp doesn't get updated
<james_w> yeah
<jam> anyway, test is currently running to at least look for double-downloads of a single import
<james_w> ok, all your fixes are on production now
<jam> \o/
<james_w> including the encoding one
<james_w> and it's up and running again
<james_w> it's got 2000 nops to churn through though unfortunately
<jam> james_w: which.. requires getPublishedSources for all of them?
<james_w> yeah
<jam> james_w: https://code.edge.launchpad.net/~jameinel/udd/single-download-524123/+merge/19731
<james_w> jam: merged, thanks
<pynonoir> Hi. If I replace a normal directory with bazaar branches, by a shared repository with the same branches inside (same path for bzr+ssh), will my users have some problems when pulling/pushing ?
<jam> james_w: thanks
<jam> pynonoir: you should be fine
<Kinnison> as long as the urls to the branches don't change, you should be fine
<jam> only possible problems would be perms
<Kinnison> oh true; permissions if this is multiple unix users
<pynonoir> there are indeed multiple users
 * Kinnison typically doesn't expect repositories to be shared between users
<Kinnison> unless you *really* need the space savings, I'd say it wasn't worth the risk
<pynonoir> Kinnison: that was more to save bandwidth
<Kinnison> hmm
<Kinnison> in what sense?
<Kinnison> give me a use-case in which you expect bandwidth to be saved
<Kinnison> (I'm not very well today; so forgive me if I'm a touch slow :-)
<pynonoir> mmm, if there is a branch called A on the distant server. Then one of my users make a clone (bzr branch), do some modifications and then push it as a new branch on the distant server
<pynonoir> maybe only the delta can be sent if it pushed on a shared repo ?
<Peng> If each user has a separate shared repo, you should still get most of the bandwidth savings..
<pynonoir> Peng: good idea, I will do this
<pynonoir> thanks
<Kinnison> and that will negate any user permissions issues too :-)
<Lo-lan-do> Hi all.  What to do if bzr check tells me about sha1 mismatches?
<fullermd> Flip a bit at a time until they match?   8-}
<Lo-lan-do> Haha.
<Lo-lan-do> And seriously?  Should I worry, or is it a harmless warning that should be marked as such?
<james_w> I doubt it is harmless
<james_w> unfortunately I don't know how to dig deeper
<Lo-lan-do> Will bzr reconcile fix them?
<james_w> I'm not sure about that either
<james_w> you could file a bug/question
<rubbs> it wouldn't hurt, but doubt it would fix it.
<lifeless> Lo-lan-do: please file a question
<lifeless> if the data is private, file a private bug
<Lo-lan-do> lifeless: ?
<lifeless> if the error message contains data that you feel is confidential, you can't get privacy on answers.lp
<lifeless> but you can in bugs
<Lo-lan-do> Oh, I see.  Launchpad.
<Lo-lan-do> No questions unless IÂ register?
<lifeless> yes
<lifeless> if you don't want to register, you can mail the list
<Lo-lan-do> I'll do that, thanks.
<mkanat> mwhudson: Have there been any more hangs?
<mwhudson> mkanat: don't think so
<james_w> Lo-lan-do: what are the messages exactly?
<james_w> perhaps others have seen them before or know what they will refer to, but I don't
<Lo-lan-do> sha1 mismatch: ('6500@9d84d37e-dcb1-4aad-b103-6f3d92f53bf6:trunk%2Fgforge%2Fwww%2Fplugins%2Ffckeditor', 'svn-v4:9d84d37e-dcb1-4aad-b103-6f3d92f53bf6:trunk:6500') has sha1 9287ea6b641b2676b769ce316258446d8f20f4fd expected da39a3ee5e6b4b0d3255bfef95601890afd80709 referenced by lolando@debian.org-20090923124104-8gq9ozsdlowgtyue
<_TiN_> Hi, what is the solution to serve bazaar, with apache? I'm trying to add support for bzr-vcs in http://trac.usla.org.ar
<james_w> Lo-lan-do: aha, bzr-svn, that changes things a little. I'm still no closer to knowing if it's a problem or what to do about it though.
<mneptok> _TiN_: http://doc.bazaar.canonical.com/bzr-0.15/http_smart_server.htm
<mneptok> _TiN_: note the strongly worded "this is NOT secure!" bit
<Lo-lan-do> james_w: I'm re-running check, will paste output into a mail if it helps.
<lifeless> mneptok: that warning is gone now
<james_w> Lo-lan-do: good idea, it might clue some people in
<lifeless> mneptok: please ref current docs
<jam> james_w: the packaging script was stopped for a while, right?
<jam> I just ran hottest-100 and got about 5 branches moved from 'ok' to 'packaging-out-of-date'
<james_w> jam: yeah
<james_w> just catching up now
<jam> well, as of 2 hrs ago
<jam> k
<mneptok> lifeless: couldn't find CURRENT for FastCGI setup. but PEBKAC is more than likely to blame.
<_TiN_> mneptok: I'm trying with fcgi and mod_python and doesn't work, I suspect bazaar is not generating correctly the app
<lifeless> mneptok: http://doc.bazaar.canonical.com/latest/en/user-guide/http_smart_server.html
<lifeless> 'fast cgi bzr' into google
<mneptok> _TiN_: is mod_python actually loaded as a module in your Apache configs?
<_TiN_> mneptok: iep, In this tracs i have svn hg git
<mneptok> _TiN_: FYI, i have never set up bzr+apache, so i'm not the best resource. please click that URL lifeless pasted.
<mneptok> _TiN_: if you read that document, it's "the blind being led by the sighted." if you ask my advice, it's "the blind being led by the blind idiot." :)
<jam> lifeless: it looks like we need to strip some zeros out of our sha1 strings (bug #524553)
<ubottu> Launchpad bug 524553 in bzr-windows-installers "Bazaar is getting wrong sha1" [High,Invalid] https://launchpad.net/bugs/524553
<jam> :)
<lifeless> jam: oh did you get an answer to it? my mail is closed...
<jam> lifeless: he was getting "abcd0fgh..." and we were saying "abcd000fgh", of course his sha1 strings were only 35 chars long
<lifeless> ! where was he getting the truncated one from ?
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<jam> I'm pretty sure it amounts to using '%x' versus '%08x' sort of thing
<jam> lifeless: I have no clue, custom code I would assume
<lifeless> heh
<fullermd> It was compressed.  Space savings are important.
<jam> fullermd: of course, the next step is to get a collision under these circumstances
<fullermd> Pshaw.  Everybody knows hashes don't collide.  I checked every file in my home dir, and none of the hashes were even close.
#bzr 2010-02-20
<dabreegster> I'm serving a bzr trunk with serve --directory=.  and attempting to connect with bzr-explorer. bzr://host:4155 doesnt work, nor /branchname. "This branch has no working tree. Last revision is 106" -- the revision's correct, so I know it's talking to the server.
<lifeless> dabreegster: 'does not work' is a little sketchy on details.
<dabreegster> The error message "This branch has no working tree" appears, and I fail to see a file listing
<lifeless> does 'bzr info bzr://localhost/' work ?
<dabreegster> Probably not.. format unnamed, echoes the location. not the same as doing bzr info actual_dir
<dabreegster> If I serve over apache, same behavior. Where is my error?
<dabreegster> bzr info http://... delivers the right format results, but explorer still refuses to read the files
<lifeless> I suspect a limitation of explorer
<lifeless> if bzr info reports format unnamed, thats ok
<lifeless> as long it says 'branch' in the output
<lifeless> file a bug on bzr-explorer I think
<dabreegster> Alright
<dabreegster> I thought this'd be core behavior, letting other people connect to my branch and work
<lifeless> I'm a CLI user, no comment ;)
<lifeless> I'd assume bzr explorer has a 'make a branch' feature though, which is where a remote url would be most useful.
<dabreegster> Likewise, but the other person working with me isnt comfortable with ssh
<lifeless> the core bzr lib doesn't care whether things are local or remote for accessing history
<dabreegster> Right
<lifeless> spiv: run_direct seems to break plugins :(
<lifeless> spiv: in that, commands needing run_direct called, won't have it called from plugins that override run_argv_with_aliases
<lifeless> I wish python has aspects
<spiv> lifeless: :(
<lifeless> spiv: I'm not sure what you could have done differently, as run_argv called run directly, so there wasn't really an existing 'will not be overridden' place to override
<lifeless> and run() is hostile to being overriden because it has argv expanded
<lifeless> I wonder if you can get an lp object by its url
<spiv> lifeless: yeah
<spiv> lifeless: hopefully we won't have reason to change such a fundamental part of the Command interface again any time soon
<lifeless> we need to update loom and other plugins soon though :)
<lifeless> like, before lucid releases.
 * lifeless is still seconded
 * lifeless complains about lp apis
<lifeless> https://edge.launchpad.net/+apidoc/#project
<lifeless> how, looking just at that, are you meant to figure out that lplib will have a .series attribute on project
<wgrant> The two mappings are not documented clearly anywhere. This has been complained about before.
<lifeless> wgrant: hey
<lifeless> wgrant: do you know how to do 'project.series['trunk']
<wgrant> lifeless: project.getSeries('trunk')
<lifeless> _ugh_
<wgrant> series is a sequence.
<lifeless> let me repeat, _ugh_
 * lifeless files a bug
<wgrant> Sort of.
<wgrant> Batching dicts is messy.
<lifeless> meh
<lifeless> thats not a very good answer: launchpad.projects["subunit"] works, so either there is an established way, or an established workaround
<wgrant> Is launchpad.projects iterable?
<lifeless> don't know, don't care :)
 * lifeless has his user hat firmly on
<lifeless> also, while I'm whinging
<lifeless> getSeries("trunk") does not work
<lifeless> bzr: ERROR: exceptions.TypeError: Method must be called with keyword args.
<wgrant> Oh, right, name="trunk"
<wgrant> How stupid.
<lifeless> well the apidoc suggested name_or_version
<lifeless> so I tried that next; boom
<lifeless> bzr: ERROR: exceptions.ValueError: No value for required parameter 'name'
<lifeless> excellent, it works.
<lifeless> only takes 30 seconds; so it is faster than a web browser.
<lifeless> wgrant: spiv: thanks for helping and listening :>
<wgrant> lifeless: You were looking at IDistribution.getSeries. that takes name_or_version.
<lifeless> wgrant: /sigh
<lifeless> there is an implicit bug there about how the api docs are presented
<lifeless> but I don't feel like filing 4 bugs in 10 minutes
<wgrant> I don't think so.
<wgrant> You were looking at the wrong part!
<lifeless> wgrant: it is hard to tell that I am looking at the wrong part
<wgrant> This is true.
<lifeless> wgrant: that is the bug
<lifeless> wgrant: is there some way to avoid traversing the object graph
<wgrant> lifeless: lp.load('https://api.launchpad.net/api/whatevertheyhavedecidedtoversionthistoday/bzr/trunk')
<wgrant> whatevertheyhavedecidedtoversionthistoday is 'beta' now, but that will change soon.
<lifeless> garh
<wgrant> Although it's possible that lp.load takes a relative path now -- try it.
<lifeless> I have the /bzr/trunk/ bit
<lifeless> https://code.edge.launchpad.net/~lifeless/lptools/upstream/+merge/19764 if you're interested in the thing I made
<lifeless> self.launchpad._root_uri
<wgrant> Aha.
<lifeless> print self.launchpad.load(str(self.launchpad._root_uri) + projectname + '/' + seriesname)
<lifeless> seems to work
<lifeless> time to see if its faster
<lifeless> yes, halved the time
<wgrant> This is unsurprising.
<wgrant> But patheitc.
<wgrant> Like my spelling.
<lifeless> wgrant: couple more questions if you have a minute
<lifeless> milestone.delete is present
<lifeless> but what about renames?
<lifeless> do I just assign to milestone.name ?
<lifeless> if so, how do I commit the change?
<wgrant> lifeless: Attribute changes are saved with obj.lp_save()
<lifeless> thanks
<wgrant> I'm not sure how well launchpadlib will like you renaming it, but it will work server-side.
<wgrant> You might just have to watch out for a 404 on the client.
<wgrant> If lp_save naively tries to refresh it afterwards.
<lifeless> wgrant: want to hear something funny
<wgrant> lifeless: Sure.
<wgrant> I have time while the Launchpad test suite runs :P
<lifeless> oh, zomg.
<lifeless> sorry, I assumed milestones were namespaced under series
 * lifeless is not thrilled by this
<wgrant> Everyone thinks that's a bit odd.
<lifeless> even if they aren't unique
<lifeless> it would still be nice to alias them
<lifeless> ah yes
<lifeless> m.delete() -> 404
<lifeless> wgrant: offhand, what module does HTTPError come from
<wgrant> lifeless: Probably httplib2
<wgrant> Hm, maybe not.
<lifeless> lazr.restfulclient.errors.HTTPError
<wgrant> yeah, that.
<lifeless> mapped into launchpad.errors for some reason
<wgrant> Probably for compatibility.
<wgrant> From before lazr.restfulclient existed.
<lifeless> ok, milestone deletion and renaming adding
<lifeless> .rename handled the change fine
<lifeless> .delete was the problem
<wgrant> Interesting.
<lifeless> few things support delete
<lifeless> so I suspect rename has been hit and handled generically
<wgrant> rename might be handled by just reading back the correct self_link from the returned object.
<wgrant> Proper deletion is implemented in lazr.restful, but not yet lazr.restfulclient.
<lifeless> for instance, yes.
<wgrant> (you can expoes a destructor in the interface, but launchpadlib doesn't know how to call it yet)
<lifeless> anyhow, I filed bugs on every glitch :)
<wgrant> Great.
<lifeless> bug 524778 is the delete one
<ubottu> Launchpad bug 524778 in launchpad "milestone.delete() tries to refresh" [Undecided,New] https://launchpad.net/bugs/524778
 * wgrant almost has PPA download counts.
<lifeless> cool
<lifeless> is there a hook point in launchpad lib to allow decorating returned objects?
<lifeless> so that I can fix bugs like 'making a release wants a date for no good reason'
<lifeless> (locally fix that is)
<wgrant> Doesn't that require changing the arguments that you pass to newReleasE?
<lifeless> yes
<lifeless> I want to decorate the milestone object
<lifeless> with one that will take newRelease, and calculate 'now' for me, then pass that to the real milestones newRelease
<wgrant> Oh, right, I was thinking the method was on ProductSeries.
<wgrant> What you really want to do is write two lines of code and get it merged into Launchpad and rolled out to edge on Monday or Tuesday.
<wgrant> I don't know of a way to decorate returned entries.
<lifeless> wgrant: that would be nice.
<lifeless> however, I don't have the space on this box
<wgrant> Ah.
<lifeless> I'm working towards that, but time ;>
<lifeless> deleting stuff is harder than it sounds
<lifeless> hah
<lifeless> check https://edge.launchpad.net/subunit/trunk
<lifeless> note the odd time of release
<wgrant> Yeah, that sort of thing happens through the web UI too.
<lifeless> still, now I can easily delete subunit/test; create subunit/test; release subunit/test
<lifeless> oh, no I can't
<lifeless> because its been released. wt
<lifeless> f
<lifeless> well, for now, manual unrelease.
<wgrant> Also, staging.
<lifeless> meh, that would mean making this code configurable to use staging.
<lifeless> its much less effort to tickle a losa to undo the sort of trivial mistake I can cause with what I'm doing
<wgrant> Heh.
<lifeless> wgrant: any suggestions on this 5 hour thing?
<lifeless> wgrant: actually nvm for now
<wgrant> lifeless: datetime.datetime.now()?
<lifeless> wgrant: already doing
<lifeless> yuck, useless
<wgrant> Hm?
<lifeless> thats not utc; gmtime ftw
<lifeless> huh 503'd it
<wgrant> That's normally a timeout.
<lifeless> yeah
<lifeless> so I'm sending
<lifeless> 2010-02-20-05:47:11
<lifeless> and its creating it 5 hours ago
<wgrant> Awesome.
<wgrant> You're not just getting a cached/slave version in the web UI?
<lifeless> which would be Sat Feb 20 00:53:11 2010 UTC
<lifeless> so I wonder if its ignoring the timestamp
<lifeless> for some _bizarre_ reason
<lifeless> could you perhaps have a peek at the code, if you have it handy
<wgrant> Once the test suite unlags my system.
<lifeless> and yes, I'm pretty sure
<wgrant> So you're calling Milestone.createProductRelease?
<wgrant> lifeless: I can't see anything that would be stripping the timestamp.
<wgrant> The interface is Datetime, and then it just goes straight into a Storm's SQLObject wrapper __init__, and then into a UtcDateTimeCol.
<dOxxx> howdy
<lifeless> wgrant: weird
<lifeless> let me try fresh, /just/ in case
<lifeless> so, I sent 2010-02-20-06:07:45
<lifeless> https://edge.launchpad.net/subunit/trunk
<lifeless> it now claims 6 hours ago
<lifeless> which is consistent with it dropping the minutes
<lifeless> wgrant: ^
<wgrant> lifeless: Interesting. File it, I guess.
<lifeless> doing so :)
<zmcgrew> i'm getting an odd error from bzr (2.1.0) when I try and create a new repo with "bzr init" -- UnicodeDecodeError: 'ascii' codec can't decode byte 0xb4 in position 26: ordinal not in range(128)
<lifeless> usually that means that your locale is not setup correctly
<lifeless> -and-
<lifeless> you have a utf8 or whatever encoding you should be using character in the containing path or nearby
<zmcgrew> encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'en_US.utf8'
<naoki_> zmcgrew: Can you paste .bzr.log?
<zmcgrew> http://devnull.lunar-linux.org/p/1041
<zmcgrew> is that of any help, naoki_?
<naoki_> Do you have non utf-8 filename in your home or subdirs?
<zmcgrew> is there a way to find it if I do?
<naoki_> $ find . > fsdump
<fullermd> Probably not the issue, since it's trying to read things in us-ascii.
<naoki_> And open fsdump with editor supporting utf-8
<lifeless> zmcgrew: run with -Derror, you should get a backtrace
<lifeless> ah yes
<naoki_> Maybe, bzr-init on $HOME is not a good idea.
<naoki_> There are many many nonordinal files...
<naoki_> bzr do sorted(os.listdir(top))
<lifeless> actually
<lifeless> do BZR_PDB=1 bzr init
<lifeless> then you can look at what failed with pdb
<naoki_> os.listdir(unicode) returns list contains unicode filenames if filename can decode with filesystemencoding
<naoki_> But if can't decode, the filename in os.listdir() is byte string.
<zmcgrew> I tracked it down the BZR_PDB=1
<naoki_> sorted([u"unicode string", "\x99 non ascii byte string"]) result in UnicodeDecodeError
<zmcgrew> it's failing when it runs through my music library
<zmcgrew> '02 - Blind Melon - Dear Ol\xb4 Dad.mp3'
<naoki_> # BTW, In Python3, os.listdir(unicode) returns list contains all unicode filename. Py3k converts undecodable filename into special unicode.
<lifeless> naoki_: yes, its terrible.
<lifeless> naoki_: its going to give us lots of grief.
<zmcgrew> short of renaming that file and all other files it may encounter, is there a fix?
<lifeless> zmcgrew: sure
<lifeless> zmcgrew: bzr init tempdir
<lifeless> mv tempdir/.bzr .
<zmcgrew> perfect! I didn't actually want it tracking my music library, I was just going to add my configs
<lifeless> its a bit of a bug that bzr looks at everything when yo do init
<lifeless> it doesn't actually add it regardless
<rocky> jelmer, ping
<jelmer> rocky: pong
<rocky> jelmer, ever see something like ...       bzr: ERROR: A Subversion remote access command failed: MERGE of '/svn/cluemapper': 200 OK (https://dev.serverzen.com)
<jelmer> rocky: I've seen a report about it
<jelmer> rocky: when are yo ugetting this, while pushing?
<rocky> jelmer, yep, just pushed a new branch int osvn
<jelmer> rocky: Did the commit actually end up being pushed?
<jelmer> if so, I wonder if this is a post-commit hook failing
<rocky> i do have a post-commit hook
<rocky> jelmer, although it looks to go away with bzr-svn 1.0.2 (i was using 1.0.1)
<jelmer> can you reproduce the error with 1.0.1 ?
<rocky> yes
<jelmer> it's a pity this is a SSL connection, would be nice to look at the contents of the response that the http server is sending back
<rocky> yeah
<Peng> Eh? You're +o, jelmer?
<jelmer> rocky: interesting that you can't reproduce with 1.0.2
<jelmer> rocky: if you can at some point it would be interesting to look at the children of that error
<Jak_o_Shadows> with bazaar and launchpad, is it possible to just get a copy of the code?
<Jak_o_Shadows> i don't want to commit or push anything yet
 * Jak_o_Shadows is a git user
<lifeless> Jak_o_Shadows: bzr branch lp:projectname
<Jak_o_Shadows> i get
<Jak_o_Shadows> You have not informed bzr of your Launchpad ID, and you must do this to
<Jak_o_Shadows> write to Launchpad or access private data.  See "bzr help launchpad-login".
<lifeless> yes, but as you said you don't want to push yet
<Jak_o_Shadows> all i did wasbzr branch lp:pymeta
<Lo-lan-do> You can also do a bzr checkout lightweight, if you don't care about history.
<Jak_o_Shadows> i probably don't
<Lo-lan-do> Err, I meant "bzr checkout --lightweight lp:projectname"
<lifeless> Lo-lan-do: no, don't do tht
<lifeless> Lo-lan-do: it is bad advice because it performs very slowly
<lifeless> Jak_o_Shadows: you did fine. 'ls pymeta' should show you the code you wanted
<Lo-lan-do> Slower than a full branch?
<lifeless> Lo-lan-do: orders of magnitude slower
<lifeless> Lo-lan-do: only suitable for LAN and local disk usage
<Lo-lan-do> Something is rotten in the kingdom of bzrmarkâ¦
<Jak_o_Shadows> oh, i know waht the problem was
<Jak_o_Shadows> i already had a /pymeta folder
<Jak_o_Shadows> thanks
<meoblast001> i'm going to make a Bazaar plugin for Bazaar servers that notifies my IRC bot when commits are pushed... should i use a network socket or does Bazaar/Python contain some better way to accomplish this?
<lifeless> there is bzr-dbus
<lifeless> which broadcasts revision changes
<meoblast001> what does it broadcast them to?
<lifeless> there's also existing irc plugins
<lifeless> meoblast001: dbus
<meoblast001> lifeless: where could those existing plugins be found?
<mathrick> oh cute, bzr-git trunk requires dulwhich "0.5.0", which hasn't been released yet
<meoblast001> do i want to use the hook post_push
<meoblast001> this is on the server end, so i'm assuming not
<lifeless> meoblast001: you need post_branch_tip_change
<meoblast001> ok, thanks
<meoblast001> then i could simply create a VC-Announce plugin for my bot
<meoblast001> lifeless: is there a post_branch_tip_change_result?
<meoblast001> oh, there's a list of hooks
#bzr 2010-02-21
<lifeless> meoblast001: bzr help hooks | less
<meoblast001> lifeless: do you mean post_change_branch_tip?
<lifeless> probably, yess
<lifeless> meoblast001: http://wiki.bazaar.canonical.com/BzrPlugins is a reasonable list of plugins - most, not all
<lifeless> meoblast001: there is publish-bot which does irc already
<meoblast001> ok, thanks
<maxb> mathrick: *shrug*  bzr branch lp:dulwich
<lifeless> mathrick: I think its reasonable for trunk to have a dependency on trunk of something else
<lifeless> particularly when they have a close relationship
<mathrick> yeah, I know
<mathrick> now it's reasonable to depend on the trunk, but the trunk isn't 0.5.0 either
<mathrick> I guess the root problem is that samba.org repos are down
<toobaz_> Hello... has the "svn-push" command, which is referred in several (old) pages, disappeared? I installed bzr-svn, but I get 'bzr: ERROR: unknown command "svn-push"'...
<mathrick> toobaz_: just use push
<mathrick> it's not needed anymore
<toobaz_> ooh
<toobaz_> that's nice
<toobaz_> thanks
<mathrick> no problem
<mathrick> okay, so it is 0.5.0, but for whatever reason it's 0.4.1 when I build a deb out of it
<lifeless> mathrick: perhaps debian/changelog is stale :P
<lifeless> mathrick: or its been given a pre-0.5.0 version because 0.5.0 isn't released
<mathrick> lifeless: nah, it was eggs installed by bzr-git overriding the system-wide dulwich
<mathrick> okay, now I've got a crasher
<mathrick> http://www.pastebin.com/f187cd9fd
<lifeless> mathrick: can you say my name - testing a script
<mathrick> lifeless: test
<lifeless> great thanks
<mathrick> no problem
<mathrick> any idea what's wrong in my crash?
<lifeless> not offhand
<lifeless> have you looked at bzr-gitbugs?
<Peng> There have been as_dict-related bugs in the past, but I don't remember it being in rio.
<mathrick> lifeless: nope, lemme try that
<Peng> mathrick: How up-to-date are bzr/bzr-git/dulwich?
<mathrick> pulled 30 mins ago
<mathrick> well, bzr-git and dulwich
<mathrick> bzr is 2.1.0
<mathrick> 2.1.0rc2 to be exact
<mathrick> https://bugs.launchpad.net/bzr-git/+bug/489649 <-- what do you know
<ubottu> Ubuntu bug 489649 in bzr-git "Crash in bzr-git during bzr rm" [Low,Triaged]
<mathrick> I reported a similar bug already
<lifeless> mathrick: try again please
<mathrick> somehow I always hit bugs in jelmer's code, I dunno how that works
<lifeless> (my nickname)
<mathrick> lifeless: pokety
<lifeless> \o/
<lifeless> gui notifications setup
<lifeless> I might rewrite it in python at some point, but this is good enough for now
<mathrick> lifeless: oh, so it popups a bubble with what's been said?
<Peng> With me it would usually be an iRPG or spam in #freenode. :-P
<mathrick> preferably without being all stupid and doing seventy things in my tray none of which I care about?
<lifeless> mathrick: yeah
<mathrick> lifeless: can I have it?
<mathrick> and what's it in, if not python?
<lifeless> of course
<lifeless> perl and bash
<mathrick> aha, lemme check if I have perl here
<Peng> But do you have bash? :D
<mathrick> hmm, let's check something first
<mathrick> lifeless: what IRC client? :)
<lifeless> irssi
<mathrick> ah, right, I sort of assumed it'd be xchat
<mathrick> lifeless: hmm, say something to me
<lifeless> http://www.google.com/reader/shared/robert.collins?hl=en - the first link explains it
<lifeless> mathrick: yo
<mathrick> oh nice, it's built into xchat nowadays
<mathrick> thanks
<lifeless> xchat has notifications built in
<lifeless> :)
<mathrick> yah, I'm just used to it being incredibly retarded
<mathrick> but they fixed it it seems
<mathrick> xchat plugins have a long and proud history of doing everything but the things you want
<mathrick> and doing things you don't want too
<lifeless> mathrick: all of xchat fits that description to me :)
<mathrick> yeah, but irssi is even more brain-damaged
<mathrick> so really it's the lesser evil
<lifeless> well, it has a rather compelling advantage
<mathrick> hey jelmer
<mathrick> https://bugs.launchpad.net/bzr-git/+bug/489649
<ubottu> Ubuntu bug 489649 in bzr-git "Crash in bzr-git during bzr rm" [Low,Triaged]
<jelmer> hi mathrick
<lifeless> jelmer: please don't auto-op :)
<mathrick> jelmer: I hit that bug again
<jelmer> lifeless, I'm not doing anything
<jelmer> lifeless, the network has started doing that to me recently
<lifeless> jelmer: its a service setting
<mathrick> jelmer: also, your samba.org repos are down, which I found out trying to get dulwich
<jelmer> mathrick, they seem alright to me
<lifeless> jelmer: I don't know which mode flag in particular, but its controllable
<jelmer> mathrick, http://people.samba.org/bzr/jelmer/dulwich/trunk/
<jelmer> lifeless, I wonder why it's suddenly started giving me ops here though
<mathrick> jelmer: odd, both hang for me
<jelmer> I haven't talked with nickserv or chanserv in ages
<mathrick> I wonder if my ISP is doing something funny
<lifeless> we expanded the nicks with op access
<jelmer> ahh
<lifeless> to be most everyone with commit access
<mathrick> by "both" I mean git and bzr repos
<mathrick> jelmer: also, the github / gitorious mirrors contain no refs, sez git
<lifeless> :>
<lifeless> later
<jelmer> mathrick: I think there's something wrong on your end then..
<jelmer> mathrick: git has no problems cloning the dulwich git repo here either
<mathrick> okay, I'll assume it's whatever my ISP is screwing up then
<mathrick> every once in a while random pages stop responding it seems
<jelmer> mathrick, if you hit this during pull, it is when pulling from a remote git repo into a git repo using bzr?
<mathrick> yes
<mathrick> jelmer: somehow I seem to hit these things in your code all the time
<jelmer> mathrick: bzr-git's working tree support has never really been a focus
<mathrick> by working tree you mean operating on git checkouts with bzr?
<jelmer> mathrick: yeah
<mathrick> I see
<mathrick> it'd be nice to be able to use bzr as a saner UI to git
<jelmer> mathrick: in that case you'd probably want a bzr working tree with a git branch/repo
<jelmer> mathrick: rather than a git working tree, which uses an index - something that doesn't map to bzr's UI very well
<mathrick> jelmer: sure, and does pushing to git work in this case?
<jelmer> mathrick: yeah
<mathrick> so I can just push to github and be a happy man?
<jelmer> Well, ideally
<jelmer> that's also a situation that's not heavily tested
<mathrick> so what is tested then? :)
<jelmer> but I'm keen to fix bugs
<jelmer> mathrick: using bzr-git to push from and to pull git repositories
<jelmer> into native bzr branches
<mathrick> jelmer: push from as in cd git-checkout; bzr push lp:some-project ?
<mathrick> jelmer: I'll give it a go then I guess
<jelmer> mathrick: the other way around generally
<mathrick> then I don't understand "push from"
<jelmer> mathrick: bzr branch git://github.com/bla && cd bla && hackhack && bzr dpush git+ssh://github.com/bla
<jelmer> (or a local git repo rather than a remote one)
<jelmer> mathrick: anyway, that isn't to say we shouldn
<jelmer> 't support working in a git working tree
<mathrick> jelmer: ah, that's the thing I wanted to do, I understood it was what was poorly tested
<jelmer> it's just not something that we've focussed on so far
<mathrick> right
<jelmer> mathrick: that's not what you're doing at the moment
<mathrick> I know that, but I was asking if I can push from a bzr-git branch into a github repo without problems
<jelmer> ah, sure
<mathrick> but speaking of git, any progress on having git-style in-place branches?
<jelmer> well, s/push/dpush/
<mathrick> aha, good to know
<jelmer> mathrick: co-located branches are in progress...
<mathrick> I must say they're hellishly convenient when debugging
<mathrick> because I don't need to update any paths, I just checkout upstream and restart
<mathrick> jelmer: where can I track the progress?
<jelmer> mathrick: nowhere really, it's just branches landing that add more support towards it
<mathrick> I see
<mathrick> so it's not something that can be easily added with a plugin?
<jelmer> mathrick: well, there is a plugin that adds it (bzr-colo)
<jelmer> but I'm working on supporting it in the core
<mathrick> ah
<jelmer> and for e.g. git repositories
<mathrick> how robust is the plugin?
<jelmer> I have no idea
<mathrick> jelmer: http://www.pastebin.com/f37cafafb
<mathrick> I don't think this happened before I updated bzr-git
<jelmer> mathrick: It's because you updated bzr
<jelmer> mathrick: it's fixed in bzr.dev
<jelmer> and 2.1.0
<mathrick> oh
<mathrick> is 2.1.0 out?
<jelmer> yeah
<mathrick> nice
 * mathrick updates
<mathrick> hmm, where am I supposed to get it? PPA stopped updating (policy change as I understand), but karmic doesn't have anything past the rc2
<jelmer> I'm not sure
<jelmer> lifeless: my ops should be fixed now..
<jelmer> \o/
<MTecknology> What does this mean? Fetching revisions:Inserting missing keys:
<Peng> It's...downloading stuff. Or uploading, as the case may be.
<MTecknology> I meant this part "Inserting missing keys"
<jelmer> in this case it is adding keys for ghosts
<jelmer> MTecknology: Is the branch you are pulling down perhaps imported from baz originally?
<MTecknology> launchpad
<jelmer> ah
<jelmer> Launchpad does indeed have a lot of ghosts in its history
<jelmer> I'm not sure why adding dummy keys for them requires so much time though
<MTecknology> what's a ghost?
<jelmer> it's a revision to which references exist in the history, but which is not actually present
<jelmer> ghosts could easily be created in baz
<MTecknology> oh
<MTecknology> so is bzr the reincarnation of baz?
<wgrant> Pretty much.
<Peng> bzr is a completely different codebase, but it was created by the same people as baz..
<Peng> Well.
<Peng> baz is a fork of tla, but still.
<MTecknology> how do git and bzr compare in features?
<mathrick> MTecknology: http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html
<mathrick> IMHO, git is absolutely insane in terms of UI, which is a deal breaker
<mathrick> whereas bzr simply works and does what I want
<MTecknology> nice reading for me
<MTecknology> thanks :)
<spiv> IIRC, "missing keys" refers to the way bzr does fetches: in the first pass it optimistically grabs what is probably most if not all of the data for the revisions being transferred, and then checks if any records (e.g. file versions, parent inventories, etc) that are required for the new revisions are still missing; if there are, it does a second pass small fetch to grab those items the first pass missed.
<spiv> (It's hard to calculate the full set of data up front because that requires inspecting the direct records for the new revisions, but the client can't do that until it has received them, and the server can't do it precisely because it doesn't know exactly what records the client already has)
<MTecknology> So far what I'm seeing is that bzr is simple, easy, flexible and git lets you perform about any task but isn't very friendly
<wgrant> Should a push really be CPU bound? I'm just pushing a Launchpad branch to a local Launchpad instance, and the bzr process doing the push is eating an entire core.
<wgrant> The remote side is also sometimes eating the other core.
<wgrant> (bzr 2.1.0 local, 2.1.0rc2 remote)
<spiv> wgrant: it's a known issue, I forget exactly what the analysis is
<spiv> wgrant: some combination of searching indices, decompressing and parsing records, and recompressing them.
<wgrant> spiv: I see.
<spiv> wgrant: I'd bet jam knows the details
<MTecknology> trying to make this launchpad system run it kicking my butt
<wgrant> MTecknology: It's still not working?
<MTecknology> nope
<MTecknology> make run only throws out one error and one warning
<wgrant> pastebin
<lifeless> spiv: ping
<lifeless> spiv: I've been pondering command cleanups.
<lifeless> spiv: I think there are a few things that can be improved in the current implementation; mainly that a public method (run) is no longer safe to call.
<lifeless> spiv: so I'm wondering if, instead, we should say 'define _run_with_cleanups' for methods that use cleanups, and not support them on 'run' at all
<lifeless> spiv: the calling logic could determine which method to execute, or something like that
<spiv> lifeless: as a way to ease backwards compat for plugins?
<spiv> I think eventually most command implementations will want to use add_cleanup, so it would be good to make sure that end state will be reasonably clean.
<lifeless> to raise it level on rusty's interface safety sacle
<spiv> Yeah.  It does suck that 'run' isn't necessary safe to call right now.
<lifeless> and the end state is that it will usually /not/ be safe to call
<lifeless> so I'd like it to look unsafe
<spiv> Right.
<spiv> If you feel that raising some sort of error that says deprecated/not-implemented/please-use-other-method-instead will be nicer than the status quo, then let's do that.
<lifeless> so I'm proposing that we deprecate run(), add _run() or something more clear
<lifeless> migrate commands over as they want cleanups
<lifeless> or perhaps have
<spiv> Hmm.
<lifeless> add_cleanup error if you used run()
<spiv> Do we need to add a new method instead of using run_direct?  I'm forgetting details already.
<spiv> I think add_cleanup erroring if you used run would be bad.
<spiv> Because then you'll fail to cleanup!
<lifeless> spiv: well, you won't ever ship it to users though :)
<lifeless> spiv: because it would blow up early. [kindof my point]
<spiv> lifeless: haha, I admire your optimism :)
<lifeless> spiv: by 'used run' I mean 'the command was defined with run()' not 'a client of the api called run()'
<spiv> I would rather blow up even earlier (by making run fail to, er, run).
<lifeless> spiv: sure
<spiv> But if you get to the point of the code trying to execute add_cleanup, then it's too late to behave gracefully, because there must be something to cleanup at that point :)
<lifeless> so there are a few questions: should we have an external keyword-function for running a command
<lifeless> its kindof nice for close testing, but I don't think we use it much that way
<spiv> I think for convenience of writing tests it'd be nice.
<lifeless> and its hard for decorating
<spiv> But yeah, check if any of our tests actually need that.
<spiv> brb, baby
<lifeless> because the signature changes between core and plugin, often.
<lifeless> spiv: I can mail you ifyou like
<lifeless> I don't think babies fit into 'right back' :P
<MTecknology> the only thing that really annoys me about bzr is that you can't just have a branch on a server and add users to a group so they can access it, you pretty much have to create a new user and add peoples ssh keys to that user account to let multiple people work on a project
<MTecknology> I'm guessing that's because of it's decentralized nature
<lifeless> uhm
<lifeless> it should work; in what way doesn't it?
<lifeless> I mean, you need a filesystem that will preserve group access properly; and the default umask on unix won't
<MTecknology> lifeless: this is what I came up with the last time I tried - http://profarius.com/content/creating-your-own-bazaar-server
<lifeless> theres also a helper script in the bzr distribution to do group based access I believe
<MTecknology> oh. I'll have to look at that
<lifeless> dunno what it does ;)
<MTecknology> :P
<MTecknology> where can I find that at?
<lifeless> its probably in the package in /usr/li/bzr
<lifeless> otherwise in contrrib/ in the source
<MTecknology> alrighty, I'll try that out
<MTecknology> so far that
<MTecknology> 's the only thing about bzr that I'm not enjoying
<lamalex> would be nice if bzr init-repo had some flags to set those automatically
<lifeless> spiv: also if you felt up to reviewing my subunit  test patch in the bzr merge queue, that would <3 brownie points
<spiv> lifeless: mail is good
<spiv> lifeless: also, I don't really look after any significant plugins myself, so perhaps I don't have the best perspective on what the requirements are... someone on the mailing list may want to chip in
<spiv> lifeless: I'll take a peek at the subunit patch, see if it looks small enough.
<spiv> (small enough to fit between baby moments :)
<lifeless> spiv: its very small
<lifeless> spiv: is add_cleanup in 2.1 ?
<lifeless> [for commands]
<Benathome> hi - can someone help - I think my osx install of bzr is a bit hosed
<Benathome> whenever i try and do a bzr init I get:
<Benathome> bzr: ERROR: No such file: u'/private/tmp/test/.bzr/README': [Errno 2] No such file or directory: '/private/tmp/test/.bzr/README.477.macbook/.gft5rmx1uy.tmp'
<Benathome> anyone got any ideas?
<Pilky> Benathome: what version of bazaar do you have installed?
<Benathome> Pilky: I just reinstalled the lastest version
<Benathome> benrometsch@macbook /tmp/test $ bzr version
<Benathome> Bazaar (bzr) 2.1.0
<Pilky> hmm
<Pilky> is it just in /private/tmp/test that you can't create or have you tried elsewhere?
<Benathome> i have tried elsewhere including in my ~ dir
<Pilky> not sure, beyond uninstalling and reinstalling
<Benathome> I've tried that!
<Benathome> wasn't sure what the best uninstall method was tho
<Pilky> there's an uninstall script
<Benathome> ah ok
<Benathome> where abouts?
<Pilky> https://launchpad.net/bazaar-mac-uninstaller
<Benathome> great thanks
<Pilky> I would maybe try uninstalling
<Benathome> lol - dont say I need bzr to uninstall it :S?
<Pilky> then try installing 2.0.4
<Benathome> ok
<Pilky> http://bazaar.launchpad.net/%7Ebzr/bazaar-mac-uninstaller/trunk/annotate/head%3A/uninstall-bazaar.py
<Benathome> yeah thanks I just downloaded that
<Pilky> you could just copy & paste that into a text file
<Benathome> but I get benrometsch@macbook ~/Downloads $ sudo python uninstall-bazaar.py
<Benathome> ls: /Library/Receipts/boms/org.pythonmac.bazaar*: No such file or directory
<Benathome> should it be running python 2.5 or 2.6?
<Pilky> did you install via the the disk image?
<Benathome> yeah
<Benathome> I had installed it via pip and homebrew
<Benathome> it was all working fine
<Benathome> but suddenly stopped working
<Pilky> depends if you are on 10.5 or 10.6
<Benathome> I tried uninstalling it from pip and homebrew
<Benathome> 10.6
<Pilky> I think on 10.6 bzr runs 64 bit so uses python 2.6
<Benathome> right ok
<Benathome> that uninstaller is looking at 2.5
<Benathome> well I ran that script, installed 2.0.4 and now I get
<Benathome> type object 'Merger' has no attribute 'hooks'
<Benathome> Unable to load plugin 'news_merge' from '/Library/Python/2.6/site-packages/bzrlib/plugins'
<Benathome> something very not right :(
<Pilky> check in /Library/Python/2.6/site-packages/bzrlib/plugins
<Pilky> see if there is a plugin news_merge, and if so moved it to your desktop and try again
<Benathome> ok I rmd bzrlib
<Benathome> reinstalled 2.0.4
<Benathome> and doing an init still gives mebzr: ERROR: No such file: u'/Users/benrometsch/.bzr/README': [Errno 2] No such file or directory: '/Users/benrometsch/.bzr/README.644.macbook/.wkx6ei3uci.tmp'
<Pilky> ok, well then I'm stumped as well, might have to ask one of the more experienced users or the devs
<Benathome> ok thanks for your help
<Benathome> googling it gives me nothing :(
<Benathome> OK well, updating the hostname on my machine fixed it!
<Benathome> very very odd
<jml> jelmer, hi
<jml> jelmer, I'm with the Twisted guys and they're interested in bzr-svn
<lifeless> moin
<mwhudson> jelmer: would https://code.edge.launchpad.net/~vcs-imports/distcc/trunk perhaps be fixed by having the git code imports not bother creating the bzr working tree?
<jelmer> mwhudson, it's fixed in current bzr-svn
<jelmer> mwhudson, that just hasn't been rolled out to lp yet
<mwhudson> jelmer: ok
<meoblast001> lifeless: you around?
<lifeless> yes
<meoblast001> ok, i was talking to you the other day about plugins, and felt it would be best to ask my question to you as you already know what i'm doing
<meoblast001> suppose i have def phook(result):, where is documentation of what would be passed as result
<meoblast001> and what it contains
<meoblast001> for example, if this is a post_change_branch_tip hook
<lifeless> bzr help hooks | less   /branch_top
<lifeless> sorry
<lifeless>  /branch_tip
<lifeless> the docs say what its passed
<meoblast001>  /branch_tip: No such file or directory
<lifeless> you can use pydoc THING to get the docs on a specific type that is mentioned
<lifeless> the /branch_tip is a search within the less
<meoblast001> yes, i'm doing bzr help hooks | less /branch_tip
<lifeless> don't put /branch_tip in the command line
<lifeless> type it after hitting enter
<meoblast001> yes, but it doesn't say what information is passed to the hook
<lifeless> 'post_change_branch_tip is called with a
<lifeless> bzrlib.branch.ChangeBranchTipParams.'
<lifeless> seems to say so to me
<meoblast001> ah, that ChangeBranchTipParams is a data structure? or whatever it's called in Python
<meoblast001> sorry, i'm more of the C/C++ guy
<lifeless> pydoc bzrlib.branch.ChangeBranchTipParams
<meoblast001> ok, thanks
<meoblast001> hm, so there is no information regarding the commit message?
<lifeless> branch.repository.get_revision(new_revid).message
<meoblast001> ah, ok
<meoblast001> lifeless: now that i wrote my bot server, time to write that plugin ;)
<james_w> "creating new compressed block on-the-fly"
<james_w> is that useful information for anyone?
<Peng> It's useful information for...the developers. Maybe. Once.
<lifeless> james_w: yes, but not always.
<lifeless> it should be -D something hidden
<james_w> I find it rather overwhelms the messages that I normally care about
<meoblast001> lifeless: is new_revno an integer (i understand typing in Python is not as strict as in C)
<lifeless> meoblast001: I think so
<meoblast001> ok, thanks
<meoblast001> lifeless: i'm getting the feeling Python is going to mess this all up for me
<meoblast001> :/
<jelmer> 'evening
<mkanat> Okay, so I go back to an old version using "bzr revert" to apply a patch. Now how do I tell bzr to update to HEAD with my patch applied, so that I can see bzr's conflicts instead of "patch"'s conflicts?
<mwhudson> mkanat: 'bzr revert' ?
<mwhudson> with no args
<mkanat> mwhudson: Which deletes my patch?
<mwhudson> oh right durr
<mkanat> I expected a -r argument on up, but there isn't one.
<mwhudson> i think there might be in bzr.dev actually
<lifeless> meoblast001: how so?
<meoblast001> lifeless: i want to send a 4 byte integer over the network
<lifeless> mkanat: rather than going back with revert; do this:
<lifeless> mkanat: bzr branch . ../patch
<meoblast001> after a lovely talk with the people in #python, it looks like it will be painful
<lifeless> cd ../patch
<lifeless> bzr uncommit -r <when patch was made>; bzr revert
<lifeless> apply the patch
<lifeless> bzr commit --author "Who wrote the patch <Whowrote@thepatch.com>"
<lifeless> mkanat: then you have a commit that represents the ptch,and can merge it as normal. And bzr knows who wrote it.
<mkanat> lifeless: Ah, thank you.
<lifeless> I should make a command to do this for you
<lifeless> give it a patch file, a rev spec, and it would import, set author, and pending merge.
<mkanat> That'd be nice.
#bzr 2011-02-14
<poolie> hi all
<poolie> hi spiv
<spiv> Hi poolie
<poolie> how are you today?
<spiv> The cold is lingering more than I'd like, but basically good.
<spiv> My kanban board is gradually having more things move to the right, which is nice, and http://webnumbr.com/bzr-in-progress-bugs and http://webnumbr.com/bzr-active-reviews are both trending in a good direction lately :)
<poolie> good
<poolie> oh, how did you get webnumbr to work for that?
<poolie> i tried but failed because the numbers weren't in spans/divs by themselves
<spiv> poolie: evil
<spiv> poolie: I hand-hacked the xpath expression
<poolie> can xpath pull substrings out of strings?
<spiv> Oh, actually I don't think I did for those
<spiv> But I did need to use https://bugs.launchpad.net/bzr/+bugtarget-portlet-bugfilters-stats as the URl
<spiv> Which is also a bit evil...
<poolie> ah, that would do nicely
<spiv> http://webnumbr.com/bzr-branches-for-ubuntu uses a hand-hacked xpath to get a substring
<poolie> ah so you can
<poolie> nice
<poolie> two things i',m going to do today
<poolie> in fact maybe now
<spiv> It'd be nicer if webnumber didn't need me to write the xpath myself, but I guess it writes half of it for me, so I could be worse :)
<poolie> are to make the kanban script a bit faster
<poolie> let it run anonymously
<poolie> and then run it from peopel.c.c
<poolie> that may be more than two
<spiv> Heh, well all of those, whatever the count is, does sound nice.
<spiv> In a vaguely related vein, have you seen http://twistedmatrix.com/highscores/?
<poolie> i did
<poolie> that was neat
<poolie> somewhere down my personal-hacking yak list is to fix http keepalive in twisted
<poolie> (specifically to try to finish a patch that adds it)
<poolie> which will help wrested
<poolie> which will help suck stuff out faster
<poolie> it's not a strictly necessary depedency
<spiv> And might get your name on the highscore list ;)
<poolie> maybe on page 4
<lifeless> spiv: how easy is it to do those?
<lifeless> spiv: I'd like to graph timeout , oops and critical bug counts for lp
<lifeless> (on the launchpad-project context)
<poolie> lifeless, it's pretty easy if you can hand-hack an xpath expr that will work
<spiv> lifeless: webnumbrs?  Login with OpenID, give it a URL, then click on a number on that web page.
<poolie> if lp put all numbers into tagged spn
<poolie> *spans it would be trivial
<spiv> lifeless: mostly it works well, unless the numbers are loaded via js or embedded in a paragraph without a span or something to isolate it.
<spiv> lifeless: for critical bug counts you'll probably find https://bugs.launchpad.net/launchpad/+bugtarget-portlet-bugfilters-stats is a good URL to use :/
<spiv> lifeless: I'm not sure how you'd feed it timeout and oops numbers, I don't think we publish those publically do we?
<lifeless> spiv: I'm not sure if we do either
<spiv> lifeless: you could also get the Critical bug count off https://bugs.launchpad.net/launchpad/+bugs?field.importance=Critical&batch=1 ;)
<lifeless> ah, we can do tags that way
<spiv> (batch=1 because otherwise when count < 75 I don't think the number is explicit on the page)
<poolie> lifeless,  so https://code.launchpad.net/~mbp/bzr-email/242262-mail-deadlock/+merge/4430 is ok with you?
<lifeless> poolie: last I tried to merge it it was an old format branch needing an upgrade
<poolie> i haven't actually seen that bug for ages but it's be good to flush the inventory
<poolie> and i think it's an improvement
<poolie> oh, that's what you mean by 'update'; ok
<lifeless> poolie: 'upgraded' :P but yes. I think.
<lifeless> anyhow the diff does look fine
<poolie> ok, it's running now
<poolie> spiv, i like the 'like' button
<poolie> well
<poolie> more just i'm interested that it's there
<poolie> on the webnumbr pages
<poolie> 'like' is a bit blunt
<spiv> poolie: I'd never noticed!  I think I've trained myself mentally filter out facebook cruft.  I guess it "likes" the individual webnumbr, rather than the site in general?
<poolie> i think so
<poolie> bit blunt meaning: does it imply "i like that spiv set this graph up" or "i like bzr having 50 bugs in progress" or "i like there being only 50 rather than 80" etc
<spiv> "I like how the graph resembles \m/"
<lifeless> spiv: no, the 1 of 245 results returns 1 as the number
<spiv> lifeless: you need to hack the xpath expression :/
<spiv> lifeless: see e.g. http://webnumbr.com/bzr-branches-for-ubuntu
<spiv> substring-after(..., 'of')
<poolie> \m/ ?
<spiv> poolie: fist of rock!
<poolie> heh :)
<lifeless> http://webnumbr.com/launchpad-critical-bugs
<spiv> lifeless: that's one heck of an xpath  :)
<poolie> lifeless, ok, landed
<lifeless> http://webnumbr.com/launchpad-timeout-bugs
<lifeless> http://webnumbr.com/launchpad-oops-bugs
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=bugs
<spiv> ubot5: nice try
<lifeless> spiv: thanks for the help
<mwhudson> lifeless: you probably want to dial the frequency down from 1 hour
<mwhudson> ... if i remember what this site is like
 * mwhudson vanishes
<spiv> Heh, I've *finally* trained firefox's url bar to suggest https://code.launchpad.net/bzr/+activereviews over https://code.edge.launchpad.net/bzr/+activereviews
<poolie> :)
<lifeless> \o/
<vila> hi all !
<poolie> hi vila
<spiv> Hey vila
<vila> hey hey (hehe) :)
<fullermd> yeh yeh?
<spiv> Argh!  _pretty_need_write_lock breaks symbol_versioning.deprecated_passed
<spiv> Which in turn breaks Repository.search_missing_revision_ids in trunk if you aren't using the fast version of the decorators
<vila> breaks how ?
<spiv> https://bugs.launchpad.net/bzr/+bug/718569
<spiv> vila: see that bug report
<vila> eeeek
<spiv> Yup.
<spiv> I can think of some workarounds, but they aren't very pretty.  Possibly the best approach is to have a dedicated class for those sorts of sentinels that reprs to its python dotted name.
<spiv> i.e. "DEPRECATED_PARAMETER = Constant(__name__, 'DEPRECATED_PARAMETER')" or something
<spiv> Or 'IdentitySensitiveConstant' or something...
<spiv> Anyway!
<spiv> What led me there is that I can now reproduce https://bugs.launchpad.net/udd/+bug/653307 locally, with trunk bzr
<vila> poolie: regarding bug #718483 , did you requeue the packages today ?
<ubot5> Launchpad bug 718483 in Ubuntu Distributed Development "should delay and retry on http 503 from librarian" [Medium,Triaged] https://launchpad.net/bugs/718483
<poolie> vila, yes, i did
<poolie> spiv, well that's good
<vila> poolie: ha, good to know
<vila> poolie: bug updated
<poolie> good night vila
<vila> poolie: g'night
<fullermd> I'll try and keep him in line while you're gone...
<vila> hehe
<dknight> I want to integrate bazaar into enlightenment file manager. Where can I get suggestions about the integration?
<spiv> vila: just proposed a fix for bug 718569
<ubot5> Launchpad bug 718569 in Bazaar "_pretty_needs_read_lock breaks symbol_versioning.deprecated_passed" [Critical,In progress] https://launchpad.net/bugs/718569
<vila> spiv: targeting trunk only ? Does this mean we need trunk for p-i ?
<spiv> vila: the triggering change is only on trunk
<spiv> vila: it's a lurking issue in all the older releases potentially, but so far it hasn't bitten anyone...
<vila> bah, forgive me, was mixing up this bug and the missing chk one
<spiv> Possibly because no-one uses DEPRECATED_PARAMETER + deprecated_passed in a needs_{read,write}_lock method until I did it recently.
<spiv> Anyway, I think I found a tasteful and robust fix.
<vila> spiv: approved
<spiv> vila: yay!
 * spiv sends it off to pqm and heads to bed
<vila> spiv: such fixes should be left un-reviewed before the submitter goes to bed or risk of insomnia are far too high ;)
<vila> grr. s//not be left/
<spiv> Well, perhaps mutating a value from the formatvalue function is a bit sneaky, but otherwise tasteful... ;)
 * spiv finds himself increasingly tempted to make a version of http://twistedmatrix.com/highscores/ for bzr...
<Tak> there needs to be a penalty for submitting a bad ticket as well
* jelmer changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jelmer | 2.3.0 is officially out ! (rm vila)
<fullermd> Sure, vila's a little odd sometimes, but that doesn't mean we need to rm him, does it?   :p
<vila> tsk
* 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: jelmer | 2.3.0 is officially out ! (RM vila)
* 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: jelmer | 2.3.0 is officially out ! (RM: vila)
<fullermd> In other news, I just found a grumpy-making side effect of using reverse merges to undo changes   :|
<jelmer> fullermd, what's that?
<fullermd> The path you hand merge serves the double purpose of "branch to merge from" and "subtree of branch to merge".
<fullermd> So if you're in a subdir and "bzr merge -r5..4 .", it only reverse merges that subdir, not the whole tree.
<vila> meh, the path is just the subdir you want to merge from, the branch is inferred no ?
<vila> worth documenting but does it deserve a warning ?
<fullermd> Well, we really should have a 'bzr reverse-old-rev' command anyway.
<jelmer> fullermd, agreed
<fullermd> But this means that using merge of '.' isn't just "slightly confusing and unintuintive idiom", it's also "mildly quietly dangerous <previous>"
<fullermd> If I hadn't just made the rev I just tried to reverse, and carefully examined the diff beforehand and noticed the output of 'merge' only listed 1 of the 2 files, I'd have never noticed I didn't actually roll back everything I wanted to  :|
<fullermd> And if I came that close to missing it, imagine all the other poor people out there nowhere near as brilliant (not to mention handsome) as myself, and the trouble they can wind up in.
<vila> > bash.org
<vila> bug 718795
<ubot5> Launchpad bug 718795 in Bazaar "LOCATION for merge can be confusing when reversing changes" [Medium,Confirmed] https://launchpad.net/bugs/718795
<mgz> launchpad launchpad launchpad...
<vila> desperate and enthusiast ?
<vila> s/and/or/
<mgz> why are some bug h1 tags now grey for me when they used to all be red...
<vila> ...
<vila> O_o
<mgz> I'd like it if they just had a changelog posted every time they do something, as it is I always wonder if I'm going mad
<vila> Decide you're mad, problem solved
<jelmer> vila: can we have a bug status for that?
<vila> for being mad ?
<vila> or for the reporter being mad ?
<jelmer> for the reporter, I don't see the value in telling the rest of the world *I'm* mad
<fullermd> We're all mad here.  I'm mad.  You're mad.
<vila> . o O (Didn't he just said he was seeing no value in telling that ?)
<mgz> it's just some of us are madder than others.
<vila> Time for a tea ? Where is Alice ?
<fullermd> Well, if there's no value in it, obviously you'd have to be mad to mention it.
 * jelmer thinks coffee is a great idea
 * fullermd perks up.
<vila> perks up as in perkolate upwards ?
<fullermd> Upward, downward, sideways, inward...   pretty much any direction that gets me coffee.
<mgz> bug 330590, meet <http://bugs.gentoo.org/show_bug.cgi?id=343355>
<ubot5> Launchpad bug 330590 in Bazaar "dirstate crc is not both 32 bits and 64bits compatible" [Low,Confirmed] https://launchpad.net/bugs/330590
<beuno> jam1, FWIW, LH has a different color scheme on LP than on trunk so people can tell them apart
<beuno> that was the directive at the time
<jam> beuno: I'll post that to the bug. Can you give any more background? Who gave the directive, etc?
<jam> also, if you have any idea how hard it would be to make it toggleable, so that LP could easily change the color scheme, that would be great
<beuno> jam, yeah, Mark and Kiko at the time. I was never super convinced it was necessary, but, at the time, LP was still closed, so it may not apply anymore
<beuno> jam, well, to do theming properly there is some work to be done, at least to split out the images into a separate "theme" dir, not too much work though, I think
<jelmer> Hi Jam
<jam> hi jelmer
<pindonga> hey, I have a question on bzr-builder, is this the right place to ask?
<poolie> pindonga, here's fine
<pindonga> I see the dput/key-id option pair. However I wanted to ask about the rationale for requiring the key-id... I want to automate the building of source packages, and since I cannot find a way to automate entering the passphrase for the gpg key (which if possible would in some way defeat the purpose of the passphrase) I was suggested not to sign the package
<pindonga> so I wanted to add support for this to bzr-builder
<pindonga> this is for the dailydeb command
<poolie> ok
<poolie> i'm not sure but i would think you should make a key specifically for the daily debs, with no passphrase
<pindonga> that was my other approach
<pindonga> however, I'm not sure what's best tbg
<pindonga> tbh
<pindonga> having a key without a passphrase is as unsecure as not having a key
<pindonga> poolie, I think bzr-builder should not be strongly opinionated on this one, unless there is a good reason
<jam> pindonga: could you set up a gpg agent for your build bot?
<jam> and that isn't entirely true
<jam> one is having a key locally, that validates something you give to other people
<jam> vs, not having a way to secure anything with 3rd parties
<pindonga> jam, yes, I was a bit dramatic :)
<poolie> i tentatively agree it should not be too opinionated
<pindonga> jam, what's the thing with the gpg agent?
<poolie> however, the signature does prove it came from a machine with the key vs somewhere else in the world
<pindonga> poolie, I'll see if I can provide a branch with the change, and we'll see
<jam> pindonga: man gpg-agent
<poolie> seeing as there's no human present to stamp the package with "i approve this build" that seems to be as strong as you can get
<poolie> if you want to make sure no one breaks into that machine that's really out of scope (though worth doing)
<jam> basically, you set up a process that knows the key, for the lifetime of a run
<jam> so that if you shutdown, restart, the information is lost
<jam> you can also configure it to remember only for a specific time, but default of 1 hour doesn't work well with your "run this every day" idea
<jelmer> pindonga: supporting unsigned packages seems reasonable to me
<pindonga> jam, actually it's run this every merge, but yes
<jelmer> pindonga: although its use is limited, what do you plan to do with the source packages built that way?
<pindonga> jelmer, let's say I push them to private ppa's
<pindonga> since this use case is for building packages from private branches
<pindonga> which are not supported by lp's recipes
<jelmer> pindonga: How would the private PPA's authenticate the packages that were uploaded?
<pindonga> so it would make sense to push those to private ppa's
<pindonga> jelmer, well, for starter's I guess you need the user/pass of the ppa to push something to it?
<jelmer> pindonga: The transport isn't authenticated at the moment, the GPG key is used for that at the moment.
<pindonga> ok, that's true for launchpad
<pindonga> however bzr-builder could be used to build packages for debian, right?
<jelmer> pindonga: Debian itself doesn't accept unsigned packages
<pindonga> in which case (which is not my use case) it may make sense to push unsigned content to the serrs
<pindonga> he,
<pindonga> bad utopic use case
<jelmer> you could use it for a private repository where you build the source packages and the resulting binary packages yourself
<jelmer> but even then I think apt-get/aptitude would warn because the packages weren't signed
<pindonga> ok, so the best shot here is to use the gpg-agent?
<poolie> i don't see the _harm_ in having them signed by a low-trusted key
<beuno> jam, re: bug #718978
<ubot5> Launchpad bug 718978 in loggerhead "have an optional search box" [Medium,Confirmed] https://launchpad.net/bugs/718978
<pindonga> in order to achieve the equivalent of lp's recipes but for private branche?
<poolie> just make a key with no passphrase, and don't let people break into the box
<poolie> hello beuno
<beuno> jam, AFAIK, loggerhead does work with bzr-search if it's installed
<beuno> heya poolie!
<jam> beuno: sure. but...
<jelmer> pindonga: just create a separate GPG key without a passphrase - there shouldn't be a need for gpg-agent in that case
<pindonga> poolie, jelmer jam thanks
<jam> beuno: launchpad's pqm version of loggerhead had the search box explicitly disabled
<jam> presumably a scalability thing
<jam> so this got propogated to trunk and 'experimental'
<jam> we'd like to bring it back
<beuno> jam, ah, right
<jam> as a configurable thing
<jelmer> also, g'morning beuno, poolie
<beuno> morning(?) jelmer
<jelmer> beuno: Sorry!  Afternoon?
<beuno> jelmer, well, you're still in .nl, right?  so it's evening for you and afternoon for me  :)
<vila> beuno: nope, it's morning in europe, you're jet-lagged again
 * beuno blinks
<beuno> vila, you confused me there for a second  :)
<vila> yes !
<jelmer> ha :)
<beuno> you guys sprinting and confusing me, aren't you?
<vila> not even ;)
<jam> beuno: vila's just lying to you
<jam> and probably still jetlagged or something
<jam> he should certainly be in bed with his lovely gf by now
<fullermd> Well, _I_ haven't gotten to bed yet.  I don't think he's allowed until I do.
<jelmer> fullermd: You sleep?
<vila> fullermd: but poolie is here now !
<fullermd> Well, I close my eyse when I tpye sometimes to try and impresonate vila.  That's sorta like slepping.
<vila> slapping in your sleep are you ?
<vila> me ? noticing tyops ? without making one ?
<poolie> hi jelmer
<poolie> and vila
<vila> beuno: truth is, jam moved to europe and is trying to make you think I'm the one lying
<vila> poolie: hey ;)
<jam> vila: not for 2 more weeks
<vila> jam: ;)
<vila> jam: just read your mail, welcome !
<poolie> vila, thanks for (it seems) trying to update the doc site and web site
<poolie> did you get stuck or are you still doing it?
<vila> It still is on my radar but couldn't get to it today
<jelmer> hi Noldorin
<Noldorin> jelmer, hi there.
<Noldorin> what's up? :)
<jelmer> spiv, hi
<jelmer> spiv, I'm seeing a weird issue with search_missing_revision_ids()
<jelmer> spiv: revision_id is now deprecated so it's set to symbol_versioning.DEPRECATED_PARAMETER, but symbol_versioning.deprecated_passed() fails, as it's a different string (with the same contents) that's being passed in
<spiv> jelmer: I just landed a fix for that (I hope) in lp:bzr
<spiv> jelmer: it's a bug in the "pretty" version of needs_read_lock/needs_write_lock
<spiv> jelmer: you can workaround it with bzrlib.decorators.use_fast_decorators()
<jelmer> spiv: ah, cool :)
<spiv> jelmer: bug 718569
<ubot5> Launchpad bug 718569 in Bazaar "_pretty_needs_read_lock breaks symbol_versioning.deprecated_passed" [Critical,Fix released] https://launchpad.net/bugs/718569
<spiv> jelmer: I'm a bit amazed this is the first time we've encountered that bug :)
<jelmer> spiv: yes, me too :)
<jelmer> spiv: Great, I can confirm your branch works :)
 * jelmer now has tarmac working for lp:bzr-gtk
#bzr 2011-02-15
 * poolie reads eric's patch
<poolie> hi spiv?
<spiv> Hi poolie
<poolie> hey, how are you?
<spiv> A bit thwarted; it turns out I still haven't got a local reproduction of bug 653307 yet after all.  And earlier today I thought it might be interesting to quickly try make a small update to one of the lpstats graphs and didn't find the relevant code/branch among those listed in the wiki.
<ubot5> Launchpad bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys" [Critical,In progress] https://launchpad.net/bugs/653307
<spiv> So I set my sights a bit lower for today and have bzr-usertest passing tests again and my old outstanding network-suite branch merged with current trunk, and about to see if it still does what it's supposed to.
<poolie> hm, i think you want lp:tuolumne-lp-configs
<poolie> i'm doing some low fruit in kanban at the moment
<poolie> trying to get it running more frequently and faster
<poolie> ah i saw some action there
<spiv> That's what I thought, but I don't see any sign of the CodehostingConnections stats in there.
<poolie> it would be nice if it was easy to reproduce
<poolie> i guess you'd have to ask a losa where it's configured
<poolie> possibly actually tom
<poolie> it might be injected into the database by some other means
<spm> hm?
<spiv> (I did at least confirm that graphs for longer time periods will show misleadingly shallow spikes for brief-but-high spikes because it just collapses multiple data points to the mean)
<poolie> spm, do you know where the code that injects CodehostingConnections into tuolumne is?
<poolie> and hi!
<spm> ah. the collection script probably isn't publically available.
<spm> heh, heya
<spm> it's pretty simple, one sec, will paste.
<spm> spiv: https://pastebin.canonical.com/43318/
<vila> hi all !
<mneptok> When the light of life has gone, no change from the meter. Then the King Of Spivs will come, seeling blood by the liter.
<vila> mneptok: should mention a goat or two when summoning like that ?
<mneptok> vila: do you have something against goats? why would you subject them to that?
<vila> mneptok: nothing against, quite the contrary, they work far better than chickens for my needs
<mneptok> vila: and last i knew, due to problems at an All-Hands in 2006, Canonical has a "no goats" policy.
<vila> oooops, I wasn't aware of this policy, damn
<mneptok> maybe they'll change it now that both Keybuk and i are gone.
<vila> sounds more like it ;)
<poolie> hi vila
<vila> poolie: hey !
<poolie> thanks for your mail
<vila> hmm, which one ?
<poolie> 'wheezy inhaling'
<poolie> nice title
<mrevell> Morning
<vila> Oh, you already got it, cool
<poolie> thanks for putting a summary at the top too
<vila> hehe
<poolie> it would have been a wee bit better if the summary had said what the bottom line was
<poolie> just as an idea for next time
<poolie> ie "we're all done"
<vila> haha, of course ;)
<poolie> or we're not?
<vila> well, yeah, we're done for wheezy
<poolie> i wasn't totally clear
<poolie> ok
<vila> we didn't significantly regress on the number of failures, so it's a nice result
<vila> poolie: I also submitted the script I used to analyze the logs
<vila> well, almost all logs, 28 with one being 5GB uncompressed and one being 300M compressed
<vila> I couldn't uncompress the 300M one but both of them contain mostly 'still active' spam so hopefully nothing valuable was lost
<vila> well, not lost, just not usable so far
<vila> now I can resume my work on making the p-i more robust and mail the list about that and some related ideas (working on it right now)
<vila> poolie: wgrant also mentioned one branch (can't remember which) still using rich-root-pack instead of 2a
<vila> poolie: the branch is probably broken on lp at this point after a failed attempt to stack
<poolie> k
<wgrant> poolie, vila: xserver-xorg-video-voodoo
<vila> right !
<vila> wgrant: can you file a bug for it ?
<wgrant> I'm not entirely sure if it's a bug.
<vila> well, leaving a broken branch on lp is one ;)
<lifeless> we need to upgrad them all
<wgrant> vila: Which logs from jubany are useful?
<wgrant> /srv/package-import.canonical.com/new/logs, but do we also want /srv/package-import.canonical.com/new's old logs?
<vila> ECONTEXT
<wgrant> vila: I filed an RT asking for them to be synced to devpad so launchpadders can see them.
<wgrant> But I have been told that /srv/package-import.canonical.com/new has some logs, and asked if we want them too.
<vila> wgrant: I haven't looked into the new/logs ones, the ones in new itself are related to the controller
<vila> yup
<wgrant> OK, thanks.
<vila> the ones in new/logs are by package
<wgrant> Right.
<pfarrell> hello! I'm using bzr-svn so that I can use bzr with my group's svn repository
<pfarrell> lately when I try to bzr up, I get --
<pfarrell> bzr: ERROR: checksum mismatch: '883d0c2e655f3ad55a1c069193827fff' != 'eb7cf436745e9c4265dcfad3365a8552' in trunk:15475
<pfarrell> any ideas what on earth it could be, or how I could go about debugging it?
<jelmer> pfarrell: what version of bzr-svn are you using?
<pfarrell> the one in ubuntu maverick (1.0.3)
<jelmer> pfarrell: there's an open bug report about that issue
<jelmer> including a workaround, but that requires upgrading to a newer version of bzr-svn
<pfarrell> apologies, I know I should have looked; I was lazy
<pfarrell> ok .. I guess I'll just use svn for now
<maxb> You could try the ~bzr PPA for newer versions
<maxb> james_w: Hello, I was hoping to ask you a question about bzr-builddeb. The following revision seems bogus: http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/revision/482 - given that 2.6 is tagged and uploaded to Debian and Ubuntu.
<james_w> it does
<maxb> Are you fine with simply reverting that, then?
<james_w> maxb, sure
<vila> james_w, maxb: As long as the info.py get updated too :)
 * maxb lols at vila's subject line to u-d-d@
<vila> :)
<james_w> vila, nice investigations, thanks
<vila> james_w: thanks for leaving us a robust tool to play with ;)
<james_w> vila, you said that spm restarted the importer at one point, why was that?
<vila> didn't I mentioned the bug # ?
<vila> bug #719196
<ubot5> Launchpad bug 719196 in Ubuntu Distributed Development "ImportDriver should wait between ThreadedImporter spawns" [High,Confirmed] https://launchpad.net/bugs/719196
<vila> james_w: at least that's what I suspect so far
<james_w> ah
<vila> james_w: a bit surprising but race conditions... are so shy sometimes
<james_w> I missed the connection
<vila> ha, damn, I didn't mention the log excerpt, just a sec
<vila> 2011-02-13 19:56:59,671 - __main__ - CRITICAL - Driver hit database is locked
<elmo> I'm going to ask a random paramiko question here, because I suspect someone will know.. exec_command() appears to be 'ssh foo.example.com bar', what's the equivalent of 'echo bar | ssh foo.example.com' in paramiko?
<vila> elmo: bzr use exce_command() :-}
<vila> elmo: I'm not even sure I understand how 'echo bar | ssh foo.example.com' would work in paramiko speak... this reminds me of the infamous XXX in bzrlib.tests.test_transport.TestSSHConnections...
<vila> i.e. you need to do the plumbing yourself around the paramiko channel
<elmo> vila: yeah, I'm trying that now
<elmo> vila: thanks
<vila> elmo: try again later with spiv, I only slightly changed this test
<vila> (but banged my head on paramiko doing so...)
<vila> james_w: so the exception is stringified and traceback lost but, as said in the bug, I suspect a race condition
<vila> meh, a race condition when spawning the imports
<james_w> vila, sounds reasonable
<james_w> vila, we should probably change it to not lose the traceback too
<vila> that too...
<vila> james_w: bug update
<vila> d
<thrope> i just installed bazaar windows standard installer on windows 2008 server but it doesnt work well
<thrope> it is impossibly slow
<thrope> (~1min to open bzr explorer)
<thrope> about 5 mins after log in the explorer extensions show up
<thrope> but dont do anything
<thrope> oh no they do - it just takes 2-3minutes for the checkout box to pop up
<thrope> is there anything I can do about this?
<vila> thrope: since this does not really match feedback from other windows users, you probably have a setup problem...
<thrope> when I select checkout from the menu I see a tbzrcommand.exe process start with about 2MB
<thrope> the memory usage slowly grows to about 20
<thrope> then the window pops up
<vila> thrope: it could be a anti-virus being overzealous, I'm not a windows expert though
<thrope> but it is not even writing any files yet - this is just opening the dialog
<vila> ha, I'm not sure the usual windows suspects are around, you'd better file a bug report against tbzr
<vila> thrope: https://launchpad.net/tortoisebzr/+filebug
<thrope> ok thanks
<vila> thrope: be sure to mention the version you're using and search around for a .bzr.log file
<vila> thrope: 'bzr version' should tell you where to find it
<poolie> stefanlsd, hi?
<thumper> hi
<thumper> I have a custom virtual transport
<poolie> hi jam
<poolie> hi thumper
<thumper> which is supposed to implement all the public transport methods
<jam> morning poolie
<thumper> but I have a feeling it doesn't
<thumper> and when I tried to do bzr info -v over the transport, it barfed at me
<thumper> how can I test my virtual transport to make sure it does implement all the expected methods?
<poolie> do you get a traceback?
<poolie> running it through per_transport tests ought to do that
<poolie> however it's possible info requires something the tests treat as optional, or something like that
<poolie> which would be a bug
<jam> thumper: if you are registering your transport, you can add a function in the module, and then the per-transport permutation tests will run against it
<jam> let me check a sec
<thumper> jam: my transport gets registered as part of a different plugin
<thumper> jam: it operates very much like the launchpad virtual transports
<jam> thumper: get_test_permutations()
<jam> thumper: the per-transport tests specifically look at what transports are registered
<jam> check what module they are comming from
<jam> and look for a get_test_permutations() function
<jam> if it is present, then they will run the per_transport tests against the result
<thumper> the transport is registered at the start of a smart server process and unregistered at the end
<thumper> poolie: ok, thanks, I'll look into that too
<poolie> thumper, have you got a traceback?
<thumper> in .bzr.log yes
<jam> thumper: so... register it globally under an unaccessible url
<jam> just a thought
<poolie> that should make it obvious...
<thumper> jam: can't really, as it needs to be constructed with a server object
<jam> thumper: that is what the test permutations is about
<jam> setting up a server
<jam> so that the tests can run against it
<jam> considering that is what happens for sftp, ftp, bzr+ssh, etc
<jam> you could also just monkeypatch "bzrlib.transport._get_transport_modules()"
<jam> it just returns a list
<jam> and already has 2 modules hard-coded in it
<thumper> actually, it looks like me
 * thumper looks sheepish
 * thumper hacks
<lifeless> thumper: the memory-1234: urls have the same issue and constraints for testing pretty much
<lifeless> thumper: as jam and poolie are describing
<thumper> yep... thanks
<jam> lifeless: thanks, I was looking at StubSftpServer, but MemoryServer is much more straightforward
<jam> to register a new server, tell the test code what address to use to access it, and shut it down again
<thumper> if I have a chrooted transport, are any clones of that also chrooted?
<thumper> and are they chrooted to the new path?
<thumper> I'd expect so, but just checking
<thumper> abentley: hi, did my bug last night make sense?
<abentley> thumper, I only glanced at at, but it seemed reasonable.
<abentley> s/at at/at it/
<thumper> abentley: ok, cool
<thumper> abentley: if you have any questions, I'd be happy to help
<thumper> abentley: also... I was working in a shared repo, with trees
<thumper> abentley: and reconfigure-pipe worked
<thumper> but when I tried to push
<thumper> my append path policy screwed up the push to launchpad
<abentley> thumper, the idea is that you have uncommitted changes in a shelf, you delete another shelf, that switches you into the first shelf, but you don't get the uncommitted changes?
<thumper> as it was now in .bzr/pipes/whatever
<abentley> sorry, let me try again.
<thumper> s/shelf/pipe/ then yes
<abentley> thumper, yes, that's the sort of mistake I can imagine making.
<abentley> thumper, yes, reconfigure-pipe isn't really suitable for Launchpad work.
<thumper> it wasn't launchpad work
<thumper> but the project is hosted on LP
<abentley> thumper, that's what I mean.
<thumper> hmm...
<abentley> bad for launchpad-hosted work.
<thumper> yeah
<abentley> thumper, it's a basic model issue, because the location of the branch changes when you do reconfigure-pipeline.
<thumper> abentley: yeah... I briefly was thinking of a way around it, but I gave up
<abentley> thumper, we may need a different way of doing that sort of configuration.  For example, if we could append the nick instead of the path.
 * thumper nods
<jam> thumper: cloning a chrooted transport is supposed to keep you in the chroot. Otherwise it wouldn't be much good :)
<abentley> thumper, it's also possible that bzr-colo has solved that (but I doubt it).  I've been meaning to switch to using bzr-colo for bzr-pipeline.
<thumper> jam: what I was meaning... was if I had a chrooted_transport which wraps (/local/path), if I have t.clone('subpath'), is the resulting transport now chrooted inside /local/path/subpath ?
<jam> thumper: no, it is chrooted inside /local/path, AFAIK
<thumper> hmm...
<lifeless> jam is correct
<lifeless> the chroot is a decorated transport, you can clone down and up within that transport as much as you want, but not up above it
<thumper> I think that is OK for my current use
<thumper> we have our bzr server hosting project almost ready to roll out
<thumper> we use a lot of code from LP, ripped and hacked to provide SSH key authentication against SSH key values in our DB
<thumper> but we just have simple file paths with shared repos for each user and project
<thumper> the primary use case is for the local polytechnic (technical college)
<thumper> privacy is there by default for projects and users
<thumper> to stop copying :-)
<lifeless> poolie: jam: bug 437003 is possibly worth doing fairly soon
<ubot5> Launchpad bug 437003 in Bazaar 2.0 "Failure to autopack because of 'missing inventories'" [High,Confirmed] https://launchpad.net/bugs/437003
<lifeless> it caused /lots/ of confusion in the u1 project today
<lifeless> its a very worrying error when it occurs
<jam> well, until you search for a bug with that 'missing inventories' string, and see that you just 'bzr pack'...
<lifeless> jam: they didn't do that
<jam> I would expect when getting a failure for them to investigate, and we can tell them right away what's up, if they just sit and privately worry, there isn't much we can do for any bug that we have
<jam> I'm not saying it isn't worth escalating that particular bug
<jam> but saying it should become Critical for something with a known workaround that happens rarely doesn't seem quite right
<lifeless> mmm, I'm not saying it should be critical
<lifeless> I'm just saying that it cost a couple of man hours today
<lifeless> and that its a very worrying error to encounter
<poolie> definitely a worrying error
<jam> time for me to EOD, I'll try to be back online later
<poolie> hi spiv?
<spiv> Hi poolie
<poolie> how are you?
<spiv> Older today!
<spiv> Hmm, and with intermittent ADSL for some reason.
<poolie> :) congratulations
<poolie> nice to see the arrow of time is still functioning correctly
<spiv> It keeps losing line sync, but I don't recall V grabbing at those cables recently...
 * spiv randomly twiddles a few connections and crosses his fingers
<poolie> i'm moving the kanbans to be on people.c.c. so they can update more frequently
<poolie> do you have a preference about having them public vs having them include private bugs?
<poolie> i'm slightly inclined to the former
<spiv> Me too
<spiv> We don't have enough private bugs to make including them in the kanban worth it, I think.
#bzr 2011-02-16
<poolie> so in the end you couldn't reproduce the mismatched inventory bug?
<spiv> poolie: right
<poolie> so what's next?
<spiv> (ADSL still bouncy.  Gar.)
<poolie> fiddling with that i guess
<poolie> that sucks
<spiv> Yeah, I'll try more fiddling.
<spiv> The large number of odd things in that bug's current status makes it hard to be sure of anything.
<spiv> (e.g. the deleted-but-apparently-not lp branch)
 * spiv -> lunch
<vila> hi all
<vila> . o O (Shudder, I kind of know why I need to reboot after a libssl upgrade, but it's still painful)
<poolie> hi vila
<vila> heya poolie
<bialix> hi poolie
<poolie> hi bialix
<vila> bialix: hey !
<bialix> re Bug 710410
<ubot5> Launchpad bug 710410 in QBzr "ConfigObj is able to write bad branch.conf which is not possible to read back" [High,Confirmed] https://launchpad.net/bugs/710410
<bialix> vila: bonjour!
<bialix> poolie: we need to fix the bug in configobj
<poolie> hi, yes, i saw your comment
<bialix> I'd like to scratch this itch
<bialix> we can have a test as well
<vila> bialix: michael foord is the configobj upstream maintainer ?
<bialix> he's the author
<poolie> sounds good to me
<bialix> according to http://www.voidspace.org.uk/python/configobj.html there are 2 maintainers: Michael Foord  Nicola Larosa
<vila> oh good
<maxb> INFO Upload was rejected:
<maxb> INFO 	bzr-dbus_0.1~bzr47~ppa59~maverick1.dsc: Version older than that in the archive. 0.1~bzr47~ppa59~maverick1 <= 0.1~bzr47~ppa60~maverick1
<maxb> ...weird
<jelmer> maxb: I think thjat's a known issue
<jelmer> maxb: sorry, different issue
<maxb> I mean, weird that the debian branch has apparently been uncommitted from
<jelmer> maxb: I uncommitted a direct commit to the debian branch
<jelmer> I was going to push a merge of a newer upstream, but it seems like the unstable branch is ahead of upstream (r49 vs r47)
<maxb> I'm having trouble understanding that last line
<maxb> oh, hmm, do I suck at maths?
<jelmer> debian/changelog has 0.1~bzr49-1
<jelmer> yet lp:bzr-dbus only has r47
<maxb> yes, apparently I typoed when setting the revno in the changelog
<maxb> oops
<jelmer> ah, ok
<jelmer> I've pushed the newer snapshot merge
<jelmer> it'll still fail until upstream actually makes it up to r49
<maxb> um?
<maxb> no it won't - my changelog failure doesn't affect recipe build versioning
<jelmer> maxb: it does, my change sets the revision number of upstream back to r47
<jelmer> maxb: whereas the currently built packages in the daily builds ppa are at r49
<jelmer> so there will be more failures to upload
<maxb> Yes, but recipe builds ignore what is in the changelog
<maxb> or rather, ours do, since they don't use the debupstream substitution
<jelmer> ah, right - sorry
<maxb> did you mean to delete .bzrignore when merging the upstream?
<jelmer> sortof, it's merge-upstream behaviour
<maxb> I don't really mind, but I think you asked me not to in other packaging branches.
<ccxCZ> any vim guru here? how do I open specific revision of some file?
<jelmer> maxb: I'll revert it, but it'd be really nice to get this fixed in bzr-builddeb :-/
<maxb> jelmer: I'm not sure it's a bug though - bzr-builddeb's assumption that the packaging branch should primarily derive from the tarball's contents seems like a good one
<maxb> Maybe we should just decide we don't really need .bzrignore in packaging branches after all
<jelmer> maxb: except in this case the packaging branch isn't derived from a tarball but from upstream
<jelmer> at the very least it should be optional for export() to exclude .bzr* files
<ScottK> jelmer: I'm interested in seeing an option for somehting like https://launchpad.net/bzr-diff-revid getting included into bzr so I don't have to manually install the plugin.  Any suggestions on who I should discuss that with/how I should go about it?
<jelmer> ScottK: hi
<jelmer> ScottK: I think it would certainly make sense for something like that to be available as an option
<jelmer> ScottK: perhaps even as the default, though we need to watch out for breaking other tools that rely on our current format
<jelmer> ScottK: I would suggest filing a bug about this. If you're interested in hacking on it yourself then myself or one of the other bzr developers should be able to help you get started.
<ScottK> OK.  Will do.
<ScottK> Default isn't that important to me as just having the option as rb-tools can select the option if it's there (I'll need to coordinate with them too).
<jelmer> ScottK: It probably makes sense to have this is one of the available formats for bzr diff
<ScottK> That's my thought.
<jelmer> ScottK: e.g. "bzr diff --format=revid" (or a better name)
<ScottK> works for me.
<ScottK> jelmer: https://bugs.launchpad.net/bzr/+bug/720219
<ScottK> jelmer: Does Canonical require copyright assignment for bzr contributions?
<jelmer> ScottK: yep, see www.canonical.com/contributors
<ScottK> jelmer: OK.  Then I guess it's up to you guys.  Sorry.
<jdobrien> I am having trouble pushing a branch to launchpad after using bzr pipelines. is there a way i can just get rid of the pipeline business in my branch?
<lifeless> AIUI pipeline adds a prev and next key to the .bzr/branch/branch.conf
<maxb> Also, depending on how you started using it, it turns your branch into a lightweight checkout of a branch stored inside .bzr/pipes/
<maxb> jdobrien: What trouble are you having?
<jdobrien> maxb, I figured it out...
<jdobrien> maxb, I think changing the branch nick along with relying on locations.conf confused it
<hallyn> i branched lp:bzr-bisect, and did sudo python setup.py install.  but i can't "bzr bisect"
<zedas> hey folks, has anyone else had problems with bzr running out of ram on OSX 64bit machines?
<zedas> it seems that the C extensions are needed but the don't build with the right architecture on the mac.
<poolie> zedas, i'm not sure, i would have thought they'd be built in 64-bit
<poolie> if you have python installed you can probably rebuild bzr from source
<zedas> poolie: trying that now, it looks like there's some issue with 64 builds on this box and python 2.6 so probably ahve to build it all from source.
<spiv> Good morning.
#bzr 2011-02-17
<poolie> i wonder why 717345 isn't showing up on john's kanban?
<bignose> I'm trying to configure âbzr builddebâ.
<maxb> go on...
<bignose> it has an â--orig-dirâ option; what change can I make to a config file to set that option?
<bignose> I've tried making a â[builddeb]â section in â~/.bazaar/bazaar.confâ with âorig_dir = fooâ
<bignose> but the program ignores it
<maxb> http://jameswestby.net/bzr/builddeb/user_manual/configuration.html
<bignose> thanks.
<bignose> why all-caps for the section name?
<bignose> that doesn't match most other INI file styles.
<bignose> (the â[DEFAULT]â is an intentional exception so it stands out)
<maxb> Someone thought it was a good idea at the time?
<bignose> if Launchpad would accept my OpenID then I would submit a bug report about that.
<bignose> but it doesn't, so I'll just fume quietly.
<maxb> I'm not sure a quirky naming choice constitutes a bug
<poolie> :) hello bignose
<bignose> poolie: heh, I wondered whose attention that would get. hi!
<bignose> maxb: low severity, but it still violates a convention.
<poolie> istr there is a convention of '[DEFAULT] in configobject, but i may be wrong
<bignose> poolie: I think so, yes
<bignose> but the other sections shouldn't be all-caps
<bignose> in the case of Bazaar, I would expect they'd simply be named after the module or command, with no changes to capitalisation
<marvin2> Hi, what's the correct way to change the default parent branch of a branch?
<Peng> bzr pull --remember?
<marvin2> Peng: I just cloned a branch from machine A (to machine B). Now I want the branch in machine B to use machine-A's parent as its default parent (it currently refers to machine-A as its parent)
<marvin2> Peng: So I retrieve the parent of machine-A and do a bzr pull --remember <machine-A's-parent>?
<Peng> Wait I have no idea what we're talking about.
<Peng> If you want to change the "parent branch" listed by e.g. "bzr info", use "bzr pull --remember some-other-branch"
<marvin2> OK
<marvin2> Peng: OK, thanks.
<bignose> I don't think âbzr pullâ is right
<bignose> if it's not already a mirror âpullâ will make it a mirror. that's probably not what marvin2 wants.
<bignose> marvin2: I would do it by editing â.bzr/branch/branch.confâ but there may be a command to do it
<spiv> You can also do "bzr config --scope=branch parent_location=URL" in bzr 2.3
<bignose> marvin2: âbzr pullâ is not what you want in this case
<spiv> (Maybe you can omit the --scope?  Doesn't hurt to be explicit)
<marvin2> bignose: Cool, will give that a try - bzr pull --remember did work, but I don't want to pull from the original location just to set the default parent.
<bignose> marvin2: yes, âbzr pull --rememberâ will âworkâ, if by âworkâ you mean what âbzr pullâ does :-)
<bignose> if you didn't intend to change the view of the branch history, then it's unlikely to have done what you want.
<spiv> pull won't necessarily change the branch history at all, e.g. if the branches have diverged.
<spiv> (But would still update the parent_location with --remember I think)
<spiv> Probably you could use âbzr merge --remember URL; bzr revertâ instead, although in this case you'd lose any local working tree changes you hadn't committed.
<spiv> Anyway, 2.3 has a UI for setting config variables.
<cjohnston> Question.. If I have a branch, merged in some code from a merge proposal, and now want to back out that code from the merge proposal, what the best way to do that? bzr revert, bzr remove-branch, ...? I have not committed the code that I merged in
<poolie> then revert
<cjohnston> so bzr revert <file-name> is the correct syntax poolie ?
<poolie> yes
<poolie> or plain 'revert' to revert the whole tree
<cjohnston> thank you very much poolie
<poolie> you're welcome; have a good night
<cjohnston> thanks.. you too
<vila> hi all !
<maxb> james_w: Thanks for the bzr-builddeb MP approvals - just wanted to note that I can't land them myself, so please let me know whether I should wait, poke someone on IRC, or request the team membership to do so
<quotemstr> Why is bzr complaining about Transport operation not possible: http does not support mkdir()
<quotemstr> ?
<quotemstr> Ah. FAQ.
<james_w> maxb, yeah, sorry for not mentioning it, I'll get to it
<maxb> np, just wanted to be clear what the next step was
<speakman> with bzr annotate I can see which one's responible for a certain line of code
<speakman> but in my case, the last edit of the line was just an uncommenting
<speakman> how can I trace when it was put there in the first place?
<rubbs> speakman: this may not be the easist solution, but you can run bzr log filename to see what revisions it was changed on, then use the revision spec on the annotate to see who did it
<rubbs> not sure if you can see all of the history of jsut one line easily though
<jelmer> speakman: qannotate and gannotate can help you skip to older revisions more easily
<speakman> jelmer: thanks
<bigjools> jelmer: around?
<jelmer> bigjools: hi!
<bigjools> jelmer: hey!  can you do me a favour and take a quick look at this, there's a failing git import and it's kinda old and embarrassing that nobody chased it up: https://answers.edge.launchpad.net/launchpad/+question/122971
<sobersabre> hi
<sobersabre> I have downloaded email hook. and it worked, i.e. sent an email.
<sobersabre> I added configuration to ~/.bazaar/bazaar.conf in [DEFAULT] section
<sobersabre> What is the syntax for addint the rules per branch. is it possible ?
<sobersabre> hm... I think I've found this.
<bigjools> jelmer: did I scare you? :)
<vila> bialix, GaryVDM: Ping
<vila> jelmer: ping, have you ever used dicts as values in config files (don't even try if you haven't please :) ?
<bigjools> jelmer, jelmer_: did you get my reply?
<jelmer_> bigjools: Sorry, my VPS seems to be under a lot of load for some reason
<vila> OMG, we've lost our pilot !
<vila> :)
<jelmer_> bigjools: I did get your reply, I'm digging into the error
<bigjools> jelmer_: great, thanks for looking.
<jelmer_> vila: hi!
<jelmer_> vila: I haven't, I wouldn't have thought that worked...
<vila> jelmer: good, forget about it, I never mentioned it :)
<lifeless> jam: around ?
<lifeless> jam: rousskov here is one of the key contributors to squid and is using lp to host his feasture branches; he is getting a 'lock held' message when running 'bzr update' locally - but there is no stale lock on lp or locally - http://bazaar.launchpad.net/~rousskov/squid/3p1-rock/.bzr/
<lifeless> jelmer_: or perhaps you are around ?
 * lifeless is a bit rusty on this code now
<rousskov> at crowberry [process #10913], acquired 8 seconds ago.
<rousskov> process number changes every "bzr update"; time is always small
<rousskov> "bzr break-lock -v [URL]" does/shows nothing
<maxb> rousskov: Hi, could you run 'bzr info' in your local branch
<maxb> In particular I am interested in whether one of the URLs contains the string %7e
<rousskov> Checkout (format: pack-0.92)
<rousskov> Location:
<rousskov>        checkout root: .
<rousskov>   checkout of branch: bzr+ssh://bazaar.launchpad.net/%7Erousskov/squid/3p1-rock/
<rousskov> Related branches:
<rousskov>     push branch: bzr+ssh://bazaar.launchpad.net/%7Erousskov/squid/3p1-rock/
<rousskov>   parent branch: /home/rousskov/programs/bazaar/repos/squid/3p1-plus
<rousskov>   submit branch: /home/rousskov/programs/bazaar/repos/squid/v3.1
<rousskov> yes, they have %7E
<maxb> right, in that case this seems to be an URL canonicalization bug in bzr, such that it thinks the encoded and non-encoded form of the ~ character reference different repositories, so it tries to lock them both, and ends up fighting with itself
<maxb> The easy solution for now is to replace %7E with ~ in your .bzr/branch/branch.conf
<maxb> Obviously this shouldn't be required, and we need to file a bug and research why this problem is only coming to notice now
<rousskov> I do not have ~/.bzr/branch/branch.conf. Would ~/.bazaar/locations.conf work?
<rousskov> Or do you mean ./.bzr/...
<rousskov> (you do)
<maxb> yes, I do :-)
<rousskov> Tree is up to date at revision 9630 of branch bzr+ssh://bazaar.launchpad.net/~rousskov/squid/3p1-rock
<rousskov> maxb, thank you
<rousskov> lifeless, thank you
<maxb> np :-)
<lifeless> maxb: thanks!
<lifeless> I'd totally forgetten about this bug
<rousskov> FWIW, this is an old branch/setup. I did upgrade bzr recently (v2.3.0)
<lifeless> yah, this was a bzr self incompatability
<lifeless> it had a bug for a bit where it wronte the %7E
<lifeless> and then the url handling in it had a bug that got fixed and the two interacted
<rousskov> makes sense
<jam> lifeless: I'm around now.
<rousskov> While I am here, I recently had a contributor doing "bzr push" to an lp branch (instead of "bzr commit") and essentially overwriting my recent commits with his merged and new stuff. Is that a bug or a feature?
<jam> rousskov: he didn't "overwrite" them, but he likely moved them to be merge commits instead of mainline
<jam> I can draw a graph if you like
<jam> you can set "append_revisions_only = True" in .bzr/branch/branch.conf and it will prevent that
<rousskov> yes, they become hidden, the tags were lost, etc.
<rousskov> I cannot set append_revisions_only on contributor's computer, can I?
<rousskov> (should not that be the default?)
<jam> rousskov: you set it on the branch you are sharing
<jam> bzr config -d lp:$SHARED_BRANCH append_revisions_only=True
<jam> though you need a newer bzr for 'bzr config' to exist
<rousskov> Nice. Will try.
<jam> rousskov: it should not lose the tags
<jam> you should still be able to do "bzr log -r tag:foo"
<rousskov> well, they become invisible in "bzr log"
<jam> you might try "bzr log -n0" to show merged revisions
<rousskov> and revision numbers I recorded earlier got changed, so I think I can argue that it was not totally seamless/harmless operation.
<rousskov> (even if bzr still knows everything I did)
<jam> rousskov: sure. shared branches should generally be used with append_revisions_only = True. It is something we've talked about making default, though people expressed concern over the transition, et.c
<rousskov> sure, as usual. Thank you for explaining what happened. And I do see the tags with -n0.
<poolie> hi all
<mneptok> poolie: hi!
<poolie> hey there
<poolie> how are things at Monty Program?
<jelmer_> hey poolie, mneptok
 * mneptok hands jelmer_ some Chap-Stick and pure, unadulterated fury
<mneptok> sorry, it's all i have handy :/
<poolie> hey jelmer
<poolie> what are you up to?
<jam> hey poolie
<poolie> hi jam
<poolie> jelmer we should get your lazy-hooks things unblocked
<poolie> oh, also, just from looking at the kanban
<poolie> https://bugs.launchpad.net/bzr-hg/+bug/691994 - is that still in progress in launchpad?
<jelmer_> hmm, Chap-Stick, that might come in useful
<jelmer_> hmm, there's still something laggy about my connection
<jelmer_> poolie: Yeah - I'm trying to finish off another fix for bzr-hg that's related which I'd like to land together with that one
<poolie> fairy nuff
<poolie> i just ask because there's an mp that seems to be landed
<jelmer_> I'd like to get the lazy hooks stuff unblocked too, I'm a bit confused about the status at the moment.
<jelmer_> hi jam
<poolie> jelmer, i'll try to review and update them
<jelmer_> poolie: cool, thanks :)
 * jelmer_ is reviewing MPs from 2008.. it's a bit embarrassing
<jml> I just got this in a test that I recently added to Launchpad:
<jml> Exception IndexError: IndexError('list index out of range',) in <bound method _LockWarner.__del__ of <bzrlib.lockable_files._LockWarner object at 0x10f65d50>> ignored
<jml> I have no idea where it comes from or why it happened, and I can't reproduce the error locally.
<jelmer_> jml: Does it actually cause anything to fail or is it just a warning?
<jml> jelmer_: it was printed to stderr during a test where I am trying to make sure nothing gets printed to stderr
<jelmer_> jml: ah, ok - so from bzr's perspective it's a warning
<lifeless> a test before yours isn't cleaning up properly / has found a bzr bug : a gc.collect will likely fix the symptoms, but not help you discover the cause
<lifeless> jelmer_: thats a fail
<lifeless> IndexError('list index out of range',)
<jelmer_> lifeless: I'm not saying it isn't
<lifeless> jelmer_: buggy code
<lifeless> jelmer_: lockwarner isn't meant to crash itself
<jml> lifeless: I'm not sure I want to add a gc.collect() to this test
<jelmer_> I'm not sure what could be raising the IndexError though, given how trivial _LockWarner.__del__ is
<jelmer_> jml: could warnings.warn() be raising an IndexError perhaps?
<jml> jelmer_: how so? (the code I'm executing is sphinx, I don't know it very well)
<jelmer_> _LockWarner.__del__ is as trivial as:
<jelmer_>         if self.lock_count >= 1:
<jelmer_>             warnings.warn("%r was gc'd while locked" % self.repr)
<lifeless> is .repr an attribute ?
<lifeless> or a property
<jelmer_> lifeless: it's an attribute that's being passed into LockWarner's constructor
<lifeless> does *it* have a repr
<lifeless> or a __str__ that can go boom
<jelmer_> ah, sorry
<jelmer_> no, it doesn't - it inherits them both from its base class: object
<lifeless> jelmer_: I mean
<lifeless> what is self.repr.__str__
<lifeless> and self.repr.__repr__
<jelmer_> ah, heh
<jelmer_> that wasn't what you were asking though :)
<jelmer_> the "repr" argument that's being passed in should be a string from what I can see
<jelmer_> as it's just the return value of LockableFiles.__repr__()
<lifeless> ok
<lifeless> that seems unfragile
<lifeless> jml: have you (or your test helpers) fiddled with the guts of warnings ?
<jml> lifeless: not me. I'm inheriting from lp.testing.TestCase and running in zope, so who knows.
<mgz> warnings.warn can certainly throw an index error
<mgz> especially if tests previously have been warnings.filters has been messed with the control/supress warnings for a previous test
<jml> LP has all sorts of warnings fiddling in it.
<mgz> hm... actually, code looks safer than I remember, iterates over it, doesn't index
<mgz> one way to find out, if you can repo
<mgz> is add try/except/printstack
<lifeless> raose
<jml> mgz: I can't. Wish I could.
<lifeless> jml: why can't you?
<lifeless> jml: I mean, if it happens in ec2 reliably, thats reproduction isn't it ?
<jml> lifeless: I've only run it once on ec2. Trying again now.
<jml> lifeless: the feedback cycle is prohibitively long.
<lifeless> its terrible
<lifeless> soon as a ta work item slot turns up we'll do something about that
<poolie> hi mgz, jml
<mgz> hey poolie. man I mangled my sentences just now.
<jml> poolie: hello
<poolie> hi jml
<poolie> so the lep seemed to go reasonably well
<poolie> some constructive feedback
<jml> poolie: cool
#bzr 2011-02-18
<poolie> hi spiv
<spiv> Hi poolie.
<poolie> hi vila!
<vila> poolie: hey ! (Almost there ;)
<vila> poolie: I will submit a first config interpolation today (limited to the same file to start with), I just need to polish the docs
<vila> same file means you can't have {xxx} defined in a file and interpolated in another
<vila> but that will be enough for the package-importer for example
<lifeless> what do you mean by interpolation here?
<poolie> vila, http://people.canonical.com/~mbp/kanban/vila-kanban.html
<poolie> lifeless, i think he means variable expansion
<lifeless> ah
<lifeless> it might be better to refer to that, and document it as that
<lifeless> just a thought
<vila> 'that' ?
<vila> oh variable expansion ?
<vila> hmm, we aren't consistent about 'variable' vs 'option' when referring to configs, I think we should commit to 'option' and update the docs (most of the code if not all use 'option' already)
<vila> poolie: so, it's better than I thought, what is missing is some bugs related to the docs (brz-website and/or bzr-all-docs)
<vila> no big deal but those are ones I
<vila> d like to get rid of today
<vila> then there are the pending bugs still assigned to me
<poolie> vila, do you have an example of one of those bugs
<poolie> i'd like to work out why they're missing
<vila> bug #716450 and the answer is: it's not assigned to me ;D
<ubot5> Launchpad bug 716450 in bzr-website "doc.bazaar.canonical.com updates are not automatic" [High,Confirmed] https://launchpad.net/bugs/716450
<vila> and filed against the wrong project on top of that ;) It should be bzr-all-docs IIRC
<poolie> :)
<vila> there is also bug #716123, already landed but you asked for some more tweaks there
<ubot5> Launchpad bug 716123 in Ubuntu Distributed Development "web page should tell where to get the source" [High,Fix released] https://launchpad.net/bugs/716123
<vila> and then there is 'repair-repo' which should be a wip somewhere
<poolie> vila, i doubt i'm going to get to it today (and maintain familial happiness)
<vila> this one may overlap with Eric's mp I should check that too
<poolie> so could you perhaps help jelmer unblock his two pending mps?
<vila> get to what ?
<vila> and please maintain familial happiness, fundamental underlying assumption that should never be violated ;)
<vila> poolie: the hook ones ? Didn't I already approved them ?
<vila> jelmer: just ask ;D
<vila> lifeless: what's wrong with interpolation ? I thought it was a pretty standard term for replacing a reference by its value, how do you call it otherwise ? (my query is about english not technic)
<lifeless> vila: do you mean taking something like 'lp:$USER/foo/bar' and replacing the $USER with the value of the option USER ?
<vila> yup
<vila> except it will be lp:{USER}/foo/bar
<poolie> if we're going to this, let's be sure to use that style consistently everywhere
<poolie> even beyond configs
<vila> yup
<lifeless> vila: so, thats generally referred to as variable expansion, or macro expansion
<vila> it's already used by bugtracker and mergetools, difftool needs to be fixed
<lifeless> or substition rather than expansion
<vila> ha right I like substitution better, but what does interpolation refer to then ?
<lifeless> I've never (until now) seen it referred to as interpolation - interpolation (to me) is a mathematics technique
<lifeless> you can generate a curve for some data points by interpolation
<poolie> i have seen it called interpolation
<poolie> you're inserting the contents of the variable into the string
<lifeless> extrapolation is when you try to go beyond the edges of the data set
<vila> so, in my mp I introduce a config.interpolate(string), using substitute there... sounds.. weird
<poolie> however i agree that is an uncommon word for it
<vila> config.expand sound better 8-/
<lifeless> huh
<lifeless> http://en.wikipedia.org/wiki/Variable_(programming)#Interpolation
<lifeless> however, the page has no references :) !cite
<vila> ha ! Right, I got it from perl (99% sure)
<vila> single quotes don't interpolate, double ones do
<poolie> i think 'variable substitution' is a pretty clear unambiguous name
<vila> poolie: config.substitute isn't clear though
<vila> expand_refs ?
<vila> still, 2,840,000 hits from google for 'variable interpolation' is a sign that it's not that unusual...
<vila> and s/variable/option/ anyway
<vila> . o O (Or should I just use variable and get a new empty name space for free ;-)
<vila> config.get_variable ftw ?
<vila> no more compatibility problems :D
<lifeless> 7M for variable expansion
<vila> 7M ?
<lifeless> sale for variable substituion
<lifeless> vila: count of google hits
<vila> ha !
<lifeless> 7000000
<vila> so config.expand, and 'option', deal ?
<poolie> expand_variables or something
<poolie> is there a bug for this?
<vila> Hmm, I don't remember
<vila> It's one item in the config doc in devnotes, it became the most urgent one for me in the package importer context
<poolie> oh i see
<poolie> how?
<vila> 1) testing locally requires a couple of additional tweaks, 2) mthaddon filed a bug asking for the log files to be in a configurable dir
<vila> 3) abentley proposed  a mp adding cruft around config POLICY_ which I want to get rid of
<poolie> and you want to use one variable to set the importer base, and then to have others relative to that?
<vila> exactly
<vila> and probably using a p-i specific config file
<poolie> ok
<vila> 4) implement {nick} handling so I can use 'bzr push' in looms with a 'push_location=lp:~{launchpad_username}/{project}/feature-{nick}' or something
<poolie> it's good to add
<poolie> it doesn't seem really on the most direct route, but hopefully it's pretty cheap
<vila> poolie: ?
<poolie> well, it's not strictly needed for getting udd going
<poolie> however, it should be a small change, and i can see it being useful elsewhere
<poolie> do you see what i mean?
<vila> given that I'm testing on a lucid-based setup before deploying to an hardy-based setup and that I want to make *ultra* sure I don't push to lp by mistake, having a single point to check and guarantee that makes testing bearable again (and I don't even mention being ready to get rid of ssh access...)
<vila> s/that makes/that, makes/
<poolie> hm
<poolie> i guess we should separate the configuration out of the tree?
<vila> yes, and make sure we don't need to create lp_creds.txt in every test branch too
<vila> and so on
<vila> there *are* easier short terms fixes but I'd rather implement long term ones before we migrate
<vila> babune switched to jenkins http://babune.ladeuil.net:24842/ \o/
<pfarrell> I love how bzr diff can use meld .. it's really sexy. I have a quick question: is it possible to get bzr to open all the diffs in meld at once (meld can diff trees of files), rather than open up meld once for each changed file?
<jelmer> http://asset.soup.io/asset/1171/4343_1de6_400.jpeg
<vila> jelmer: :-D
<vila> jelmer: by the way, do you need help with your hook mps ?
<jelmer> vila: Yeah, that'd be great. I'm not entirely sure what needs to change, and it'd be great to finish that work.
<vila> jelmer: AIUI, the pt1 is ok to go, introducing a central registry can be done as a further submission
<vila> jelmer: the other one just need some doc and that should go in doc/en/user-guide/hooks
<jelmer> vila: Thanks, I'll land the first and update the second!
<vila> go go go ! LD
 * jelmer also *finally* has coffee. There shouldn't be any more dodgy MPs today
<Tak> coffee? you're well into beer time!
<jelmer> heh, depends on where you are I guess :)
<jelmer> vila: oh, I see jam beat me to your config-expand-options branch
<vila> jelmer: the more the meyer (mayor ?) ;)
<jelmer> merrier?
<fullermd> meilleur?   :p
<vila> fullermd: yeah meilleur but you don't say that in english
<fullermd> Well, I don't say it in French either.  Not so's you could understand anyway...
 * vila bangs head, vbox is randomly killing vms , 3 times in a raw it killed the one I was working on while also killing a babune one it was supposed to properly shut down :-(
<knighthawk> Am I the only one finding the Eclipse plugin extremely buggy? Like I can't even do an update.
<maxb> Which eclipse plugin? bzr-eclipse or qbzr-eclipse ?
<knighthawk> huh I *think* bzr-eclipse which is the lease buggy?
<knighthawk> least
<knighthawk> lest
<knighthawk> yeah least
<maxb> Ah. In my experience bzr-eclipse is just nowhere near finished to an acceptable level of polish
<maxb> qbzr-eclipse is much nicer, but doesn't integrate tightly with eclipse for most things - instead it's some minimal eclipse integratation to make it easy to call out to qbzr to do stuff
<knighthawk> thanks maxb, I'll give qbzr a try. bzr-eclipse isn't working at all really.
<maxb> It's a shame. MercurialEclipse is incredibly good - except for the bit that then I'd have to use Mercurial :-)
<lifeless> :)
<knighthawk> lol - @ maxb - yeah I *just* moved our shop over to bazaar and if I can't figure out an eclipse solution I afraid we may be moving over to mercurial or worst (IMHO) git.
<knighthawk> not that git is bad, just I don't want to have to work with it.
<lifeless> so the qbzr developer is pretty active
<lifeless> qbzr-eclipse its intended to be lightweight and mostly just driving qbzr
<maxb> qbzr-eclipse is currently the best Eclipse/Bazaar solution that I am aware of. It's kind of the only one.
<lifeless> there can be only one
<lifeless> wait, wrong movie.
<knighthawk> lol
<knighthawk> I'll give it a try today. but what i need is a tool that will work more or less like the bzr-svn plugins so developers that won't bother to learn the difference can still checkin / update
<knighthawk> my core team has been learning bzr and working fine with bzr-explorer on all three platforms (Linux, McOS, Win)  but we have developers outside of my team that need access to the repos. my other options is some kind of bzr-svn bridge but that scares me.
<maxb> knighthawk: You mean "like the Eclipse svn plugins" ?
<knighthawk> maxb, right. sorry
<maxb> Regrettably I don't think there is any true Eclipse Team plugin for Bazaar that's actually worth using. bzr-eclipse is an idea not carried through to completion, whilst qbzr-eclipse is good, but a different way of working
<knighthawk> we all use Eclipse (or some sort of Eclipse derivative like Zend Studio or Demandware Studio)
<lifeless> first thing is to try qbzr
<lifeless> first thing is to try qbzr-eclipse
<lifeless> see if its capable of doing what you need
<lifeless> failing that talk to guilermo
<knighthawk> yeah my fear is that is going to push us to hg (now that I've convinced them that we need a DSVC)
<knighthawk> so far my team likes qbzr-eclipse *way* better (I haven't had a chance to look yet) but they aren't really the audience I need to accept it.
<axeld> I'm relatively new to bzr, and have a problem with pending merges - does anyone have a little time to help?
<axeld> I'm using bzr with a SVN backend, after I pulled the latest changes (via "up"), my local commits were converted to pending merges
<axeld> so far so good
<axeld> But my local files are now changed again, and neither push, nor dpush find anything to push
<axeld> Is there anything I can do besides trying to redo the local commits again?
<maxb> axeld: You can't push your local commits whilst they are *pending* merges - you need to commit them first
<axeld> maxb: but how? If I do a "bzr commit", it seems to want to commit all changes at once
<maxb> Yes
<maxb> The change history remains there, in the merged commits
<axeld> How does that work with the SVN backend?
<maxb> Although, hmm, if you want it directly visible on the svn mainline, that won't quite do what you want
<axeld> That was what I was aiming for
<maxb> I'm a little confused, because you said you pulled with "up", yet you ended up with pending merges.... are you working in a local branch or a checkout? Perhaps paste 'bzr info' ?
<axeld> It's on another machine -- anything particular you're interested in?
<maxb> well, whether it's a checkout or a branch, mainly
<axeld> It shows the same address for "checkout of branch", "push branch", and "parent branch"
<axeld> Location: checkout root: .
<maxb> Ah, when you make a local commit, you do 'bzr commit --local' ?
<axeld> Exactly
<axeld> Has this changed recently, or did I setup the repository differently this time?
<maxb> I don't think anything has changed recently
<maxb> Right, so if you want your local commits linearized, you need to use rebase, not update
<axeld> Can I setup bzr always to do local commits, and only push manually?
<axeld> And how do I rebase?
<axeld> (after an update, that is)
<maxb> To always commit locally, change your checkout into a branch with 'bzr unbind'
<maxb> Having unbound, 'update' will no longer attempt to fetch new changes from the remote. You would use 'pull' for that
<axeld> great, thanks!
<maxb> pull will error if the remote has diverged from your local branch
<axeld> Any idea on how I could fix my problem, too? :-)
<axeld> Diverged in what way?
<axeld> The workflow is that there is a central SVN repository with development going on, and I use bzr in order to be able to commit independently from that, and push my changes from time to time
<maxb> Diverged in the sense of the revision graph - i.e. remote has new commits and so do you locally
<axeld> And how would I resolve the issue then?
<maxb> I think 'bzr rebase --pending-merges' might possibly be what you want in your current branch
<axeld> How do I get the rebase extension?
<maxb> What is your OS?
<axeld> It doesn't seem to be part of the base install
<maxb> hmm, have you not been using it before now?
<axeld> Ubuntu 10.10
<axeld> I've never rebased
<axeld> In my old setup, I always used push/pull
<axeld> (with an older release)
<axeld> Now, I used "up", maybe accidently, but since it worked, I didn't question it
<maxb> What did you previously do when there were changes in svn to the branch you were working on locally?
<axeld> AFAIR (it's been some time), I just couldn't push my changes if there were changes on the server, and I had to pull first
<Odd_Bloke> Hello all.  I'm trying to use bzr-builddeb on a Debian sid box but I'm getting API mismatches (bzr 2.3, builddeb wants 2.2).
<Odd_Bloke> james_w: ^
<maxb> axeld: But, you would not be able to pull new changes from the server if you had local commits
<axeld> maxb: my memory might very well fail me, but that's how I remember it
<axeld> maxb: is it possible that rebase is now called rewrite?
<maxb> Yes, the plugin has been renamed (but the command has not)
<axeld> installing it
<axeld> maxb: it says: "no revisions to rebase"
<maxb> What exactly did you run?
<axeld> maxb: "bzr rebase --pending-merges"
<maxb> hmm
<maxb> And what does 'bzr st' say?
<axeld> It shows the files of my local commits as modified, and lists "pending merge tips"
<axeld> okay, just the pending merges when I use -v
<maxb> Hmm. I've never used rebase --pending-merges before. It sounds like it is not doing what it claims
<axeld> How would I look at those with log?
<maxb> look at the pending merges?
<axeld> yes
<axeld> In order to recreate them again manually :/
<maxb> We've not reached the point of that being necessary
<axeld> I hope so
<axeld> But I am clueless
<maxb> First, can you confirm that you have no *uncommitted* changes besides the modifications originating from the merged local commits?
<axeld> BTW on the other topic: how would I resolve the case in an unbound repository if I have local commits and new changes in the server?
<maxb> Normally one would simply merge.
<maxb> Your situation is more complicated because you want to linearize the changes for the sake of how they appear in svn
<axeld> maxb: I'm not 100% sure, but pretty much - at least the changed files do contain the changes I already committed locally
<axeld> And I don't think I made any other changes afterwards
<axeld> exactly
<axeld> I would need to rebase the pending merges, the question is just how
<maxb> OK, well, if you're in doubt, run a 'bzr diff' and save the output somewhere, because I'm about to ask you to do stuff that throws away the existing modifications in this tree
<axeld> alright, I'm ready when you are :-)
<maxb> ok, now we're doing to do something slightly messy because bzr doesn't provide a command to get the revision-id of pending merge tips
<maxb> sed -n 4p .bzr/checkout/dirstate | xargs -0n1 echo
<maxb> will print you the revision ids of the current base of the working tree, plus the pending merge tips
<maxb> I'm assuming there's only one pending merge tip, right? (So you got a count of 2, followed by 2 revids?)
<maxb> You've already run 'bzr unbind' by now, right?
<maxb> If so, 'bzr pull --overwrite -r revid:the-revid-of-the-former-pending-merge-tip . && bzr revert' will put you back to where you were before the 'bzr up'
<axeld> I haven't unbound yet, wasn't sure if it was a good idea yet
<axeld> And yes, I see a "2", and then two lines, which don't really look like revision IDs, but what do I know
<maxb> email@address.tld-stuff is a revid
<maxb> So is svn-v4:stuff
<axeld> that are the two ids indeed
<maxb> The first being a svn-v4 one and the second an email one, right?
<axeld> Just wondered why they look so differently - but I guess one is from me, and the other one from SVN trunk
<axeld> maxb: exactly
<maxb> It's because one is a commit made in svn and translated into bzr, whereas the other is a commit made directly in bzr
<axeld> thanks
<maxb> OK, so, unbind, pull --overwrite, revert, ....
<axeld> which revid is the one I need to pass to pull?
<axeld> the svn one?
<maxb> the second one, the email
<axeld> ok
<maxb> The point is, we are resetting your working branch to the state based on your local commits
<axeld> ah, okay
<axeld> so that's done now, I have no modified files or pending merges anylonger
<maxb> right. Now, I don't know why 'rebase --pending-merges' was being awkward, but from where we are now, we should be able to use plain old 'bzr rebase' with no options, to rebase your local commits on top of the new commits found in the parent branch
<maxb> So, give that a try :-)
<axeld> It says: no revisions to rebase
<maxb> this makes no sense
<axeld> so that's consistent, at least 8-)
<maxb> What does 'bzr missing' say/
<maxb> ?
<axeld> You have 3 extra revisions
<axeld> Those are my local commits
<maxb> by definition you have something to rebase, then :-/
<axeld> Great; looks like the rebase module doesn't like my setup
<maxb> um. so. 'bzr rebase :parent' possibly?
<axeld> still says the same
<maxb> well, gah, 'bzr rebase' behaves just as I expect for me locally :-/
<axeld> In any case, you seem to know a lot about bzr, thanks for trying to help!
<maxb> I'm rather perplexed :-/
<maxb> Unfortunately I can't think of what to ask, and I'm guessing this project is private?
<axeld> yes, unfortunately
<axeld> What would happen if I pull or push now?
<maxb> wait.... you said 'bzr missing' said "You have 3 extra revisions" ... nothing about extra revisions in the remote?
<maxb> gah
<maxb> all this talk of rebasing has blinded me to the utterly obvious
<maxb> You can just 'bzr push'
<maxb> But, if that's so, I still don't understand how 'bzr update' got you to the state of having your local commits as a pending merge :-/
<axeld> If I bzr up again, will that bind my repository again?
<maxb> No
<maxb> 'bzr bind', for that
<axeld> okay
<axeld> well, great, it's done! Thanks a lot!
<maxb> I still don't understand how your revisions got to be a pending merge, but at least they're where they need to be now
 * maxb --> afk
#bzr 2011-02-19
<marwijn> hello all
<jelmer> hi marwijn
<marwijn> I'm really stuck on a problem with bazaar is this a good place to ask for help ?
<jelmer> sure, ask away :)
<marwijn> I'm trying to setup a repository on a windows machine that I want to access through either bzr+ssh or sftp
<marwijn> I've been trying for hours without succes
<jelmer> what doesn't work exactly?
<marwijn> I keep getting access denied errors
<marwijn> when trying sfpt
<marwijn> and when I try bzr+ssh it just gets stuck
<jelmer> marwijn: what version of bzr are you running? what server?
<marwijn> I've tried both the 2.3 and the 2.2.3 standalone installer for windows
<marwijn> Now I'm trying to install it with cygwin, but since I'm not experienced with it might also take some time
<jelmer> marwijn: what sort of server are you running?
<jelmer> (as bzr doesn't come with an ssh server)
<marwijn> I'm trying to setup an windows xp machine to serve as "central repository"
<marwijn> on that machine I installed opensshd
<marwijn> With putty I can connect, with private key authentication
<marwijn> also sftp works
<marwijn> with winscp I can connect and browse
<jelmer> I fear I don't have enough experience with Bazaar on Windows to help, sorry :-(
<marwijn> Thanks for trying anyway
<marwijn> Any idea how I could get some support ?
<jelmer> mailing the list or filing a question using launchpad
* jelmer changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: - | 2.3.0 is officially out ! (RM: vila)
<marwijn> Ok let me try the cygwin install and if that doesn't work I'll try launchpad
<vila> marwijn: http://babune.ladeuil.net:24842/ uses an opensshd server its windows slave IIRC
<vila> s/its/for its/
<vila> marwijn: but there are nasty bits that I never tweaked correctly to allow *multiple* users to connect there
<vila> marwijn: I didn't try to setup the sftp server there because the performances can't be as good as the smart server (bzr+ssh) so it wasn't worth the effort
<vila> marwijn: but jelmer is right, mailing the list is the best way to get the best feedback (I can't dig the details right now but can post them in reply to your mail)
#bzr 2011-02-20
<dev001> hi.  i've added a previously bzr-version-controlled folder underneath my project root to my .bzrignore.  moving forward, the ignore works fine, as expected, what's the bzr cmd to remove/purge that now-ignored-subfolder's version history ?  staring at the silly man page, i'm missing it ...
<bob2> there is none
<bob2> if you mean "I'd like to erase from history going all the way back to the beginning of time", that is
<bob2> if you just want to del it, rm
<dev001> bob2: hi.  rm what?  not the directory, i presume ...
<dev001> or?
<bob2> ?
<bob2> if you want to delete the directory and then commit, rm it
<dev001> no, i want to keep the directory, in place, just not have it bzr-tracked ...
<bob2> bzr rm --keep
<dev001> aha! bingo, i think!
<dev001> perfect, thanks.
<wyvern> i thought bazaar commits were local, but I just committed something and it went straight to launchpad (no push required). What's going on?
<Kamping_Kaiser> how did you branch ?
<wyvern> I did a bzr checkout of the thing I wanted to work on in lp.
<fullermd> Commits aren't "local", they go to whatever branch you're working on.  When you run 'checkout', you're not making a new branch, just a new working tree on the existing branch.
<fullermd> So that's the expected outcome.
<Kamping_Kaiser> fullermd: beat me to it :p
<fullermd> If you want the new revs to not go there, you'll want to make a new branch for them using 'bzr branch'.
<wyvern> hmm
<wyvern> that seems like it would then require me to merge, though
 * fullermd swoops in and ninjas away the credit   :p
<Kamping_Kaiser> hehe
<fullermd> Well, if whatever you do leads to divergeance, there's no way around merging whatever you do.
<wyvern> naturally
<wyvern> but it seems that this requires an extra step... I'd like to just have some commits queued up and then push them
<wyvern> obviously the server would require me to pull and merge if when I push I'm out of date
<fullermd> That would be what you'd do with the new branch...
<wyvern> but then I'd have to have another checkout lying around of the main branch and merge my branch into it, right?
<fullermd> That would be a way to go, yes.
<wyvern> are there other approaches?
<wyvern> I'm hoping there's something I'm missing... I like hg's approach to this
<fullermd> If you don't have divergeance, you could just push from your branch.  If you (and probably more important, the upstream project if it's not just "you") don't care about pivoting the mainline around, you can just merge-push in place.
<wyvern> I see... so if I make a personal branch, I can then push straight into the main branch (and that would save the push location?)
<fullermd> hg's approach is the latter.  The reason it's off the beaten path in bzr is that it screws with the mainline.  hg doesn't use the mainline concept, so the objection there is null.
<wyvern> so what is the 'bzr way'? I'm happy to try a new approach
<fullermd> The bzr way would be to either just push like that if there's no divergeance, or merge/commit into a checkout if there is (or if you want to merge anyway)
<wyvern> I see.
<wyvern> ok, I'll try the 'separate branch and push into mainline' approach. Thanks for explaining.
<wyvern> I recognize your nick from somewhere. perhaps #postgresql?
<fullermd> Probably not.  I've used Postgres for years, but I've never been in an IRC chan about it...
<wyvern> ah, k. Who knows, then. :)
<fullermd> You may find some of the stuff at <http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs> useful.  The RevNumbering and RevHandling docs talk about some of the stuff underlying which way you merge and its effects.
<wyvern> so if there's a branch on lp, let's say lp:~foo/bar/baz ,when I *branch* it is that in effect making a local-only branch of the server-side branch?
<wyvern> but when I checkout, my local state always completely mirrors the server state and that's why checking in causes a push?
<fullermd> Accurate enough, yah.
<wyvern> I see. The 'branch' terminology seemed like the wrong thing to do after my experience with git, svn and hg
<fullermd> You could translate it like a 'hg clone'.  Not an exact correspondence, but...
<wyvern> yeah, i understand that now
<wyvern> ok, next question -- bzr pull takes *forever*. is this because lp is slow?
<wyvern> or is it always this bad
<fullermd> Well, lp isn't per se fast...  Like any server, it's sure to be slow if you're talking over http though.
<wyvern> if the 'parent branch' is what i should be looking at, it's bzr+ssh
<fullermd> Yeah, that would be relatively better.
<fullermd> LP has never been impressively fast for me.  Rarely found it painfully slow.  Though I don't offhand remember the last time I used it for anything but bzr.
<fullermd> Anyway, I gotta go.  I have an urgent appointment with my recliner and not-moving.
<wyvern> sounds good. :) Thanks again.
<spiv> Good morning
<Tsu> Hello
<Tsu> I need advise
<spiv> Hi Tsu
<Tsu> I would like to run Bazaar on a NAS running this: "Linux version 2.6.22.18 (wyc@SWTEST3) (gcc version 4.2.1) #22 Mon Aug 30 19:09:34 CST 2010"
<Tsu> Hi Spiv
<Tsu> Is it possible?
<Tsu> I have python already installed.
<spiv> If you have python already installed, then it should be possible.
<Tsu> I've install Python-2.5.4-2
<spiv> Although do you need to install Bazaar on the NAS?  Bazaar works fine over e.g. SFTP
<Tsu> I would like to run bazaar as a smart server on the nas
<spiv> Ah, ok.
<spiv> That's a new enough Python, so that's fine.
<Tsu> I was checking the available packages...
<spiv> Is the NAS based on Ubuntu or Fedora or something like that?  If it is, I'd probably try a Bazaar package for one of those.
<spiv> Otherwise installing from the source tarball should work fine.
<Tsu> Nope... I don't think so
<Tsu> Yes, I was checking the source tarball...
<spiv> http://wiki.bazaar.canonical.com/InstallationFaq may help you
<jelmer_> hey spiv
<jelmer_> how's your day?
<Tsu> Thank you for the instalation FAQ...
<Tsu> Ok, I don't have Crypto nor paramiko
<spiv> jelmer_: good so far, but it only just started :)
<Tsu> But I have xml.etree.cElementTree..
<spiv> Tsu: paramiko is only needed for the client, not the server, I think.
<spiv> Tsu: ditto Crypto
<Tsu> Hmmm... ok :D
<Tsu> Better that way
<Tsu> :D
<spiv> (paramiko is needed for the client to access sftp:// URLs, paramiko+Crypto is needed for bzr+ssh and sftp if you don't have a system ssh client installed)
<Tsu> excellent
<Tsu> spiv, another question.
<Tsu> Do you know if the mercurial plugin is going to be updated to the latest bzrlib?
<jelmer> Tsu: bzr-hg trunk should work with current bzrlib
<Tsu> ok.
<maxb> jelmer: Hi, what do you think about adding a subvertpy-daily recipe build? (To unblock bzr-svn dailys)
<jelmer> maxb: there is one
<maxb> oh
 * maxb looks closer
<jelmer> although I did only add it recently :)
<jelmer> maxb: https://code.launchpad.net/~bzr/+recipe/subvertpy-daily
<maxb> ah, good
<maxb> Also, I'm wondering what to do about bzr-explorer daily for karmic
<maxb> It's currently broken because xvfb in karmic is broken unless you additionally Build-Depend on xauth
<jelmer_> urgh
<maxb> We could cheat, and add that extra Build-Depend to the unstable branch, or we could add a daily-ppa branch just for this, or we could just shrug, and abandon karmic for this package
<jelmer_> I guess we can add a branch to the recipe that adds that dependency?
<Tsu> hmmm... what's "distcc"?
<maxb> ugh, dependency hell... subvertpy-daily failing because of missing python-pydoctor
<jelmer> maxb: just fixed that :)
<maxb> Tsu: A distributed C compiler
<bob2> Tsu: an neat tool for distributing compilation across multiple machines
<Tsu> I see...
 * maxb fixes bzr-grep to not run its tests under xvfb
<Tsu> running "sudo python setup.py install" is giving me this error:
<Tsu> running install
<Tsu> running build
<Tsu> running build_py
<Tsu> running build_ext
<Tsu> building 'bzrlib._annotator_pyx' extension
<Tsu> distcc gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/ffp/include/python2.5 -c bzrlib/_ annotator_pyx.c -o build/temp.linux-armv5tejl-2.5/bzrlib/_annotator_pyx.o
<Tsu> unable to execute distcc: No such file or directory
<Tsu> which is normal, since I don't have distcc on my NAS :D
<lifeless> wgrant: well, you've got CC=distcc exported then :)
<lifeless> that, or your python was built with distcc and has remembered that
<wgrant> Do I really?
<lifeless> bah
<lifeless> Tsu: ^
<lifeless> wgrant: I was typing something else to you
<spiv> Actually, it might be that distutils is confused on that system.
<Tsu> nice...
<Tsu> :)
<Tsu> python bzr
<Tsu> Bazaar 2.3.0 -- a free distributed version-control tool
<Tsu> http://bazaar.canonical.com/
<Tsu> python bzr is workin :D
<spiv> Tsu: great :)
<Tsu> :)
<Tsu> :/mnt/HD/HD_a2/ffp/home/root/bin/bzr# python bzr serve &
<Tsu> :/mnt/HD/HD_a2/ffp/home/root/bin/bzr# listening on port: 4155
<Tsu> Nice...
<Tsu> :D
<Tsu> ok...
<Tsu> it looks like it's working...
<Tsu> I'll give it some more testing tomorrow
<Tsu> thank you all!
<Tsu> cya all tomorrow :D
<spiv> Tsu: you're welcome
<Tsu> thank you spiv
<Tsu> cya
<Tsu> <close>
#bzr 2012-02-13
<thumper> boo
<thumper> I added a command to allow setting append only in a plugin
<thumper> I have a locations.conf that automatically sets the push branch
<thumper> so used "bzr append-only :push"
<thumper> bzr: ERROR: Unsupported protocol for url "lp:~thumper/unity/test"
<thumper> $ bzr append-only lp:~thumper/unity/test
<thumper> HPSS calls: 54 (30 vfs) SmartSSHClientMedium(bzr+ssh://thumper@bazaar.launchpad.net/)
<poolie> hm, strange
<thumper> so it just seems that we need another deref thing
<poolie> seems like it
<poolie> there is another bug like that
<thumper> $ bzr revno :push
<thumper> bzr: ERROR: Unsupported protocol for url "lp:~thumper/unity/test"
<thumper> same issue elsewhere
<jelmer> thumper: bzrlib.directory_service.directories.dereference()
<thumper> and another problem
<thumper> jelmer: revno isn't mine :)
<thumper> I was testing my append_only tweak
<thumper> pushed branch
<thumper> set remote append only
<thumper> uncommitted locally, followed by revert
<thumper> then pushed
<thumper> $ bzr push
<thumper> Using saved push location: lp:~thumper/unity/test
<thumper> No new revisions or tags to push.
<thumper> however the revno of the LP one is one higher than locally
<thumper> shouldn't it complain?
<jelmer> thumper: it'll only complain if the branches have actually diverged
<thumper> hmm...
<thumper> ok
<jelmer> so if you do a commit locally and then try to push, it should error out
 * thumper does an unchnaged commit
<thumper> yep got diverged
<thumper> but you get that with diverged branches anyway
 * thumper tries --overwrite
<thumper> $ bzr push --overwrite
<thumper> Using saved push location: lp:~thumper/unity/test
<thumper> bzr: ERROR: Server sent an unexpected error: ('error', 'RevisionNotPresent', 'Revision {tarmac-20120212192717-9jmrqx6we7yd8bl7} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(CallableToParentsProviderAdapter(<bound method CHKInventoryRepository._get_parent_map_no_fallbacks of CHKInventoryRepository(\'chroot-95047632:///~thumper/unity/test/.bzr/repository/\')>))], []))))".')
<thumper> HPSS calls: 18 (0 vfs) SmartSSHClientMedium(bzr+ssh://thumper@bazaar.launchpad.net/)
<thumper> oops
<thumper> we should have a "you can only append" message right?
<jelmer> yes
<jelmer> or at the very least, not an error of this kind
<jelmer> if you can file a bug about this, perhaps with a way to reproduce it that would be really great
<jelmer> I think I've seen this error before, but never in a way that was reproducable
<thumper> sure
<thumper> jelmer: https://bugs.launchpad.net/bzr/+bug/931209
<ubot5> Launchpad bug 931209 in Bazaar "error on pushing a diverged branch to append_only target" [Undecided,New]
<vila> good morning bazaar
<mgz> morning!
<vila> mgzorning !
<bialix> hi all
<bialix> mgz,wgz: I'm going to release current state of bzr-explorer trunk as 1.2.2 this weekend
<mgz> bialix: okay.
<mgz> will see if I have an evening free to fix a few things before then.
<mgz> thanks bialix.
<bialix> we have a couple of fixes in trunk already. more fixes will be good, but Ben Finney reminded me that we need a proper release before 2.5 final
<mgz> yeah.
<bialix> ok
<edlinde> how do I get the files in http://igraph.bzr.sourceforge.net/bzr/igraph/0.6-main/files ?
<edlinde> do I need to have bzr installed on my machine?
<jelmer> edlinde: yes, that's probably the easiest way to do so
<LarstiQ> edlinde: though bzr can run from source if installing is difficult (though it will be slower if you can't compile the c extensions)
<gnomefreak> what bzr package contains bzr-notify?
<mgz> gnomefreak: bzr-gtk though you may want to check recently fixed bugs before filing a new one
<gnomefreak> mgz: this is not a new one. i filed a bug on this a while ago. IIRC it was marked a duplicate but dont recall the bug number
<gnomefreak> mgz: thanks
<gnomefreak> thats odd. i cant find it at all. doesnt matter since it is a bzr PPA
<mgz> gnomefreak: bug 903696
<ubot5`> Launchpad bug 903696 in bzr-gtk (Ubuntu) "bzr-notify crashed with SIGSEGV in g_return_if_fail_warning()" [Medium,Confirmed] https://launchpad.net/bugs/903696
<gnomefreak> that looks like the one
<gnomefreak> mgz: ok i commented on it rather than report a new one. thanks
<mgz> it looks from the bug that testing with tip bzr-gtk would be useful to confirm the issue is resolved
<gnomefreak> version 0.103.0+bzr769-1 it is still broken. I removfed the package a little while ago but i will make a note to reinstall it in a few days maybe eraly next week
<jelmer> I guess we'll just need to release and upload 0.104
<gypsymauro> hi
<gypsymauro> there is a way to convert a project from darcs to bzr?
<jelmer> gypsymauro: it should be possible to do so with bzr-fastimport
<gypsymauro> any example somewhere jelmer ?
<gypsymauro> I'm googling but a lot of false positives :D
<jelmer> gypsymauro: I'm not sure, I've never used it myself
<jelmer> gypsymauro: 'bzr fast-export-from-darcs' should generate a fastimport stream for you from the darcs repo
<jelmer> gypsymauro: you can then use 'bzr fast-import' to create a bzr repository from that
<zyga> jml: ping
<jml> zyga: yes?
<zyga> jml: hi
<zyga> jml: I'm an avid user of testtools/testscenarios
<jml> \o/
<zyga> jml: it seems that the only thing that keeps me back in python2.7 now is testtools/setup.py
<jml> zyga: what about it?
<zyga> it seems it wants to use bzrlib to figure out the revision and things like that
<jml> zyga: only if you're using a checkout.
<zyga> jml: so, since I wrote something that resolves this exactl problem once and for all
<jml> zyga: shouldn't do that for released versions
<zyga> jml: (hmm, I recall seeing similar issues with venv/tox
<zyga> jml: anyway, I was wondering if you would consider using versiontools
<jml> zyga: I'll take a look.
<zyga> jml: it's a tiny library that understnads how to do what you do in setup.py, works with all python versions and most sensible VCS systems (and has plugin support to add more via 3rd party packages)
<zyga> jml: I'll push a MP to let you know how it looks like
<zyga> jml: if you are curious: versiontools.rtfd.org
<zyga> jml: I've got a MP hanging that removes the need to use setup_requires if you are scared of things like that (some people found it allergic)
<jml> zyga: thanks.
<zyga> jml: is there any reason you are using distutils as opposed to setuptools/distribute
<mgz> what I do is just hack the test script to fall back to no version if an ImportError gets thrown from bzr
<zyga> mgz: consider using versiontools
<mgz> I swear I put up an mp that did this, but now can't see it
<mgz> why?
<zyga> mgz: it's a bit more clever than that
<mgz> it's yet another annoying dependency
<zyga> mgz: it's implemented right, unlike most one-off copy/paste solutions
<zyga> mgz: works across various vcs'es
<zyga> mgz: it is only a build-time dependency if you use it (your users won't have to)
<mgz> well, it's still something I'd be commenting out before running setup.py like I do with setuptools
<zyga> mgz: it's a dependency but one that is cheerful to work with
<zyga> mgz: nope
<zyga> mgz: why ?
<mgz> build time is what I care about when I'm downloading a branch tip to quickly test
<zyga> mgz: then you don't have to comment anything out
<mgz> I'm not dealing with prettily packaged branches
<mgz> if it's quiet when it's not there then I can live with it
<zyga> mgz: it's not only silent but actually works correctly in such cases
<mgz> historically the junk people use in setup.py isn't very good at falling back to basics
<zyga> mgz: my problem exactly, I had ugly code in each setup.py I wrote
<zyga> mgz: then I decided that I can do better and made a project out of that
<bdmurray> Is there any chance I could get the lucid-updates branch of update-manager updated?
<james_w> bdmurray, something looks broken with one of the update-manager branches unfortunately: http://package-import.ubuntu.com/status/update-manager.html
<bdmurray> james_w: okay, so is there anything I can do?
<james_w> bdmurray, I don't think we can get the importer past that, so it would be a case of tracking down the bug and fixing it
<quicksilver> if I've got a shared report into which I've pulled a toxic revision (accidentally committed large file) is there some way to "garbage collect" the repo and get rid of it, if no actual branch uses it?
<quicksilver> s/report/repo/;
<mgz> not an easy one.
<mgz> with a little scripting, you can just create a new shared repo, then branch everything under the current one into that, then replace the old location with the new one
 * quicksilver nods
<quicksilver> is there a tool to extract a commit message from a revision?
<jelmer> quicksilver: bzr log ?
<jelmer> quicksilver: can you perhaps expand a bit on what you're trying to do ?
<quicksilver> long story :)
<quicksilver> reapply a bunch of commits, preserving commit message
<mgz> that's the kind of thing the rebase plugin *should* make easy
<quicksilver> I can extract a patch for the commit with bzr diff
<mgz> but whether in fact it does may be another issue
<quicksilver> I can probably hack something up with bzr log | sed
<quicksilver> just wondered if there were tools for "field-by-field" access to parts of revisions
<mgz> well, yes, bzrlib.
<jelmer> quicksilver: if you have a XML parser ready, 'bzr cat-revision' could be useful
<quicksilver> jelmer: aha
<quicksilver> mgz: fair enough.
<quicksilver> jelmer: doesn't look like XML to me, looks like colon-separated text
<jelmer> quicksilver: yeah, it's just the repository-internal data
<jelmer> quicksilver: in older versions that was in XML, in newer versions it's bencode
<jelmer> another option would be bzr-xmloutput, it has a command that can spit out the data in XML for you
<zyga> jml: https://code.launchpad.net/~zkrynicki/testtools/use-versiontools/+register-merge
<quicksilver> jelmer: so many possibilities, so many tools to look at. I may stick with perl + sed and a quick hack job :P
<jelmer> heh, that works too :)
<thomi> Hi - how does 'bzr lp-open' pick which browser to use?
<thomi> My default browser is firefox, but ever since I installed chromium it's started using that instead...
<LarstiQ> thomi: it uses webbrowser.open
<LarstiQ> thomi: http://docs.python.org/library/webbrowser
<thomi> LarstiQ: thanks, I'll look there for a solution.
#bzr 2012-02-14
<SoftwareExplorer> I'm trying to use bzr to keep track of changes I make to /etc on my Ubuntu system. The problem is that I got a glob of changes that I would like to split in to a few different commits. The nice thing is that the changes that should be in different commits are in different files. Is there a way to do this?
<lifeless> bzr commit path [path...]
<abentley> SoftwareExplorer: You should also look into using etckeeper for this-- it was designed for maintaining /etc in bzr.
<SoftwareExplorer> lifeless: Thanks!
<SoftwareExplorer> abentley: Cool, another toy to try :)
<vila> hi all
<quicksilver> mgz, jelmer: this is what I did in the end:
<quicksilver> (cd ../tree-with-toxic-file/; bzr diff -r1384..1385) | patch -p0; bzr commit --author "Original author <author@name>"  -m"$(cd ../tree-with-toxic-file; bzr log -r1385 | grep '^ ')"
<quicksilver> repeated multiple times in a shell loop.
<quicksilver> fortunately there weren't any merges to worry about, that makes it much worse.
<mgz> morning
<quicksilver> mgz: aha, I just said something to you before you logged on :)
<wgz> ah, but I have it in the buffer here
<wgz> glad that worked, but we really do need a proper way of doing that
<wgz> enough people run into it that they shouldn't all need to do their own hacks.
<quicksilver> wgz: yeah. also, for the record, my hack is wrong because it doesn't account for added files.
<quicksilver> wgz: I should have added "bzr add $(bzr unknowns)" to each step
<vila> quicksilver: not to mention renames...
<quicksilver> wgz: and most importantly, my method totally fails to record merges correctly. I've done that before and it was a lot more hard work. Our local wiki (where I work) has a long page on how you might fix this kind of stuff
<quicksilver> with various approachs which don't work.
<quicksilver> bzr fast-export and bzr rebase are listed as two of the ones which apparently don't work :)
<quicksilver> vila: yes indeed. renames like merges.
<quicksilver> fortunately this was a fairly short piece of history and it was mostly just changes. I was just pleased to preserve the commit messages and atomicity.
 * vila nods and agrees with wgz about better supporting that kind of operations
<quicksilver> ok, reading my notes from last time
<quicksilver> last time I used 'bzr replay'
<quicksilver> that's pretty much the same as the diff/patch thing but better.
<quicksilver> and for merges I used shelve.
<quicksilver> (taht is, uncommit, shelve, manually copy shelf to dest tree, unshelve)
<vila> +1 on moving shelves from one tree to another (with some care for the needed revisions)
<quicksilver> but shelve only worked for simple merges
<quicksilver> it failed on a fiddly one with multiple conflicts and renames and stuff
<quicksilver> and I never worked out *why* it failed
<quicksilver> fortunately I was able to work around that by, essentially, manually redoing that merge from the revid involved, which wasn't a "toxic" revid so it was OK.
<vila> worth a bug report if you can reproduce but shelving a merge... won't track the merged parent I think (which may be an acceptable limitation)
<quicksilver> vila: I wrote a pretty detailed post about it to the list last time
<quicksilver> it was mostly warnocked. Too much to digest, I fear.
<vila> yeah, I was about to mention this rang a bell
<quicksilver> you helped me last time, yes
<vila> yeah, and bug reports are better to track middle/long terms issues, posting to the mailing list is still valuable  though, thanks for that
<quicksilver> https://lists.ubuntu.com/archives/bazaar/2010q1/066738.html
<quicksilver> the problem was I didn't understand bzr well enough to be clear what a useful bug report was
<quicksilver> I tried to explain in enough detail for other people to understand
<vila> yup, the issue is also that you were using 2.0.3 and some of the things you refer to sound like bugs that were fixed in later version so it was a bit hard to split that into proper bugs
<quicksilver> understood
<quicksilver> I appreciate the difficulties and I've love to be more helpful but I always hit these problems when I'm on tight release schedules myself :(
<vila> some memory issues have been solved, there is now a add.maximum_file_size config option (defaulting to 20MB) which may have avoid the issue entirely
<quicksilver> I'm now using 2.1.0
<quicksilver> what should I be using?
<wgz> 2.4.2 would be nice.
<wgz> but the core issues you highlight in that post are still relevent.
<vila> 2.4 at least, 2.5b6 has just been made available and is the last beta before 2.5 becomes the new stable
<quicksilver> I have a conservative tendency not to upgrade core tools if they aren't broken.
<quicksilver> and now I have a criss-cross merge and I don't know why :-(
<quicksilver> how can I track down where the criss-cross is and break this merge down more sensibly?
<wgz> qlog makes pretties
 * quicksilver inverstiages installing qbzr
 * quicksilver is in a maze of twisty branches all alike
<vila> quicksilver: that's where 'bzr qlog trunk branch1 branch2 branch3' really helps
<quicksilver> if I have a criss-cross trying to merge A and B then each of A and B must have independently merged C, right?
<quicksilver> and the solution is to go via C
<quicksilver> if I can locate C.
<vila> criss-cross merges are generally just a warning, unless you encounter bad merge results, you can probably just ignore them
<vila> and if you encounter bad merge results, fixing them once is also generally enough
<vila> if you do encounter them frequently, you may want to investigate your workflow though
 * quicksilver nods
<quicksilver> quite bad conflicts
<vila> legit or spurious ?
<quicksilver> I thought I might be able to improve things by unpicking
<quicksilver> looks like the same change applied independently in A and B in some cases
<quicksilver> vila: I was mostly intellectually curious as to how we'd got into this situation and if I could simplify the conflicts by unpicking. It's probably a rabbit-hole I should avoid.
<quicksilver> bzr: ERROR: Unable to determine your name
<quicksilver> eh? how could bzr suddenly forget my name?
<quicksilver> where is this normally stored?
<quicksilver> ah, the bzr version upgrade must have lost it
<mgz> ...it should really find the same config file
<quicksilver> upgraded from 2.1.0 to 2.4.2
<mgz> if you run `bzr version` and `bzr config` it should have the same location and contents before and after (probably a bit late to check now)
<quicksilver> Bazaar configuration: /Users/jules/.bazaar
<quicksilver> that directory is empty except for my ignore file
<jml> hey
<jml> I was talking with a git user the other day
<jml> and the way they described interactive commit (incl. diff hunk splitting) sounded really nice
<jml> Does bzr have a diff hunk splitting thingy?
<jml> And does it have an interactive commit? (I use shelve a lot)
<quicksilver> shelve splits by hunks
<quicksilver> you know that if you use it :)
<jml> quicksilver: really?
<mgz> hm. and do you have an existing file in %APPDATA%/bazaar/2.0/ instead?
<quicksilver> I thought it did
<mgz> you can hit 'e' in shelve if you have an editor configured
<jml> quicksilver: as in, can you take an existing hunk and split that up with shelve?
<mgz> it's like, the least discoverable thing ever.
<jml> mgz: interesting, will try that out.
<quicksilver> mgz: there are a couple of places that %APPDATA% might resolve to on a Mac. I'm poking around.
<mgz> I think it needs to actually be as in `bzr config editor=` rather than just EDITOR=
<mgz> quicksilver: whoops, mistook that for win 7 for some reason
<mgz> the osx logic shouldn't have changed
<mgz> it's bascially BZR_HOME or ~/.bazaar
<mgz> so, if you had config in your home dir before bazaar should still see it
<quicksilver> this is peculiar
<quicksilver> I set up bzr about 7 years ago, I don't remember how I told it who I was :)
<quicksilver> probably just by typing bzr whoami without worrying about it
<quicksilver> although I can't remember if I made som eeffort to distinguish work repos from non-work repos
<mgz> yeah, or maybe it just worked?
<mgz> I'd be suprised if you had no config at all though
<mgz> newer bzrs are a little stricter about how they get your identity
<quicksilver> ah you know what, I never did set it up I think
<quicksilver> old commits show my user ID as jules@machine-name.localdomain
<quicksilver> not with a real email
<mgz> ah, yes, that's what the newer versions are trying to avoid
<quicksilver> never bothered me personally since it was obviously me
<quicksilver> but I can see people would prefer a real email address
<quicksilver> would be nice to set whoami for a whole shared repo rather than one branch at a time
<mgz> yup.
<mgz> you can set a sensible global value though.
<mgz> having a mix of different identities for different projects on the same machine is currently somewhat painful though
<quicksilver> I've been compiling since vila convinced me to try qlog at 10:55
<quicksilver> it's still working on Qt
<quicksilver> I hate source distribution :P
<mgz> eheh, surely there's an easier way to get qt there?
<mgz> you're using a platform where you're not expected to do things for yourself.
<quicksilver> mgz: dunno. I usually find macports is the best way to get open source software
<quicksilver> apparently 'brew' is the new kid on the block.
<quicksilver> but they both compile from source.
<mgz> why not just run gentoo in a vm...
<quicksilver> not sure that solves the source problem :)
<mgz> seems like a masochistic approach
<mgz> but I guess trying to do free software packaging on a mac means that's the kind of people they are
<antonh> i am doing 'bzr commit' and my editor is launched. i am about to write a commit message and dont remember what i did so i open another terminal and type bzr status too see what i actually did
<antonh> then bzr complains about bzr: ERROR: Could not acquire lock "/path/to/file"
<quicksilver> yeah.
<quicksilver> that's why the default commit messages reminds you what has changed at the bottom?
<mgz> antonh: bug 98836
<mgz> ...bot?
<antonh> quicksilver, yes only what files has changed, it gives no info about the diff
<mgz> at any rate, that's a known issue with one bit of bzr, but it's not an easy change
<quicksilver> antonh: yes. I now have the habit to always run diff first, and then commit.
<quicksilver> C-x V = and then C-x V c
<quicksilver> then I can compose my commit message browsing the diff in the other window
<quicksilver> mgz: I'll be your bot! https://bugs.launchpad.net/bzr/+bug/98836
<mgz> thanks bot!
<antonh> isn't it possible to perform a write lock on the file and let other processes have read access to the file?
<antonh> isn't 'bzr status' a read-only operation?
<quicksilver> not portably using the simplistic OS locks bzr is currently using
<quicksilver> logically some way of differentiating read and write locks would go some way to solving the problem
<antonh> okay, so there is only one kind of lock at the moment. and that lock covers up for both read and write
<mgz> antonh: read the bug for the messy details, but basically the fancy stat cache can need updating whenever it looks at the tree
<mgz> which is why it needs write access
<mgz> so, entering the commit messsage shouldn't hold a lock, and st shouldn't really need to write lock, but that's how things work currently
<antonh> yeah
<antonh> if it was written in C i might have looked at it right away
<mgz> it's really an issue with the design of dirstate, rather than something that's just a code problem, hence why it's stuck around as a problem
<quicksilver> well I think you could scrap the lcok on starting commit couldn't you?
<quicksilver> or collect the message first, at least
<antonh> i guess your solution is the easiest quicksilver
<antonh> actually it isn't 'bzr status' i want to do, it's 'bzr diff' but i think you realised that :)
<mgz> antonh: the easy thing for you to do is just `bzr alias ci="commit -p"` or similar
<mgz> so you always have the diff
<antonh> oh cool
<kise> Newbie question: In Bazaar, is there any difference between "bzr mv ..." and "bzr rm ...; bzr add ..."?
<jelmer> kise: yes, that would add a completely new file
<jelmer> kise: if you 'bzr rm', then 'bzr add' you can use 'bzr mv --auto' to make it detect renames
<kise> jelmer: Thanks. Ok, then let me explain a problem I have.
<kise> I had a folder named "extra" with many subfolders and did the following:
<kise> 1) I rearranged rearranged them manually into "extra/cpp" and "extra/python".
<kise> 2)"bzr add"
<kise> Now Bazaar shows all the subfolders as "removed" and then "added".
<kise> I thought it would be better if they appeared as "moved" but don't know how to do it.
<kise> "bzr mv --auto" does not detect anything.
<kise> Any suggestions?
<jelmer> kise: hmm, are there more changes to the files than just their move?
<kise> No
<jelmer> I'm not sure why 'bzr mv --auto' doesn't work then
<mgz> `bzr mv --after` will let you fix up stuff now
<kise> jelmer: 'bzr mv --after' means I have to do it for every subfolder I moved manually?
<jelmer> kise: yes
<mgz> if there are hundreds that might be annoying, but if you didn't also rename the dirs it's amienable to scripting
<mgz> bash one liner someone? :)
<kise> I see. Thanks for the suggestion. Will try my hand at Python :)
<kise> Sorry, a related question. While trying to use the "--after" switch I found this:
<kise> bzr mv xtra/unused-cpp xtra/cpp/unused-cpp --after
<kise> bzr: ERROR: Could not move to unused-cpp: xtra/cpp/unused-cpp is not versioned.
<kise> Do I need to add first all directories with "add --no-recurse"?
<mgz> what does switching --after to --auto do in that case?
<jelmer> kise: yep
<kise> Uhm, I see. Anyway tried switching --after to --auto and bzr complained:
<kise> $ bzr mv xtra/unused-cpp xtra/cpp/unused-cpp --auto
<kise> bzr: ERROR: Only one path may be specified to --auto.
<kise> Seems like I will have to do it through scripting.
<kise> Thank you very much, jelmer and mgz ;)
<jelmer> it's a bit odd that 'bzr mv --auto' doesn't work thoughj
<kise> It has happened to me several times. T_T I don't know why either. I use Bazaar 2.4.
<kise> Never anyone had this experience?
<jelmer> kise: 'bzr mv --auto' seems to work fine for me
<jelmer> kise: I don't use it often though, usually I just use 'bzr mv' when I move files
<kise> I see. Thanks anyway! ;)
<jelmer> kise: if you hit this again, please file a bug
<kise> Ok
<quicksilver> vila: qbzr finally installed :)
<vila> quicksilver: \o/
<quicksilver> you know I hate GUI tools
<quicksilver> but I can see some neat things here
<quicksilver> what are the colours in qblame? "freshness" of the change?
<mgz> hue is who, intensity is how recently
 * quicksilver nods
<quicksilver> what would be better, of course, is an emacs mode with the same functionality :) but this is cool.
<quicksilver> hmm no bzr qmerge --preview
<mgz> see bug 415232
<mgz> or the bug linked from there for more.
<vila> quicksilver: AIUI emacs provides something (but we had feature requests to make it faster)
<vila> quicksilver: the default vc mode is where this is defined (IIRC)
<quicksilver> vila: well I use dvc for quite a lot but it doesn't have sepcific support for merge --preview
<quicksilver> vila: however it's simple enough to do M-! bzr merge --preview ../other-branch
<vila> err, sorry, I thought you were talking about annotate
<quicksilver> vila: and then M-x diff-mode in that buffer
<vila> yup
<vila> I use that Heavily
<quicksilver> bonus points for C-x C-q to put it in read-only mode
<quicksilver> which makes the keybindings more useful.
<vila> hmm
<vila> but that means C-c C-s (split-hunk) does not work anymore ?
<quicksilver> didn't know that one
<vila> quicksilver: very handy to revert part of a change
<quicksilver> vila: yes I must admit I generally do that by hand
<quicksilver> vila: and then re-check the diff to see I did it right.
<vila> Yeah, I did that before I discover it, I never looked back ;) Of course it works for *applying* part of a change too (if you M-x cd to the right directory)
<quicksilver> http://search.cpan.org/dist/VCI/ looks interesting
<quicksilver> but I can't see that it's data model knows what a 'merge' is.
<quicksilver> although it mostly supports VCSes which understand merging.
<quicksilver> does anyone know offhand if there is a way to turn a revid into a loggerhead URL?
<quicksilver> /branch-name/changes/34.1.2 is a valid URL for a dotted revision number
<quicksilver> /branch-name/changes/revid:blah doesn't work though
<quicksilver> ah well it turns out we're using a version of loggerhead which has a bug on that kind of URL anyway
<quicksilver> c'est la vie
<tronhammer> halo?
<tronhammer> hey I had a general security question
<tronhammer> I don't feel comfortable with out bzr stores my password in plaintext, so I modified the bzrlib/transport/http/_urllib2_wrappers.py :: get_user_password to grab the password from a file on the system
<tronhammer> the file I made is a c program that when executed, checks the md5 of the bzrlib/transport/http/_urllib2_wrappers.pyc file, and if it matches the one that was given at the creation of the file, it prints out the password
<tronhammer> does anyone see anything glaringly wrong with this approach?
<tronhammer> oh, that's supposed to say "comfortable with how*"
<mgz> tronhammer: I take it you're using https?
<tronhammer> yeah
<tronhammer> also, count out c decompilers of coarse, those aren't a concern
<tronhammer> more issued with lunch time attacks
<mgz> there are some neater password stores that integrate with some OS things
<mgz> but that depends on you using an OS with one of them
<tronhammer> hm, that's a good point, could use keyring for lion
<tronhammer> keychain*
<mgz> tronhammer: http://www.szakmeister.net/blog/2010/mar/9/bzr-keychain/
<tronhammer> awesome, great find!
<tronhammer> thanks
<damd||> d:\repos\emacs-trunk>bzr pull
<damd||> Using saved parent location: bzr+ssh://damd@bzr.savannah.gnu.org/emacs/trunk/
<damd||> bzr: ERROR: Unable to connect to SSH host bzr.savannah.gnu.org; [Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions
<damd||> how do i fix this? :|
<LarstiQ> damd||: can you pastebin the corresponding traceback from .bzr.log? `bzr --version` will tell you where to find the log file
<LarstiQ> !pastebin
<LarstiQ> hmm
<LarstiQ> !paste
<LarstiQ> meh
<damd||> i'm attempting to upgrade bzr, but hold on if you have time, thanks!
<damd||> here is the log: http://pastebin.com/raw.php?i=nYnKvQeM
<damd||> brb
<LarstiQ> damd: that error seems to come from somewhere underlying bzr (either the ssh provider or the os)
<LarstiQ> damd: googling for the "An attempt ..." bit comes up with some hits
<damd> yeah, i figured... i'm using pageant to serve the keys, i'm just guessing that bzr knows that i want plink to take care of SSH
<LarstiQ> damd: yeah
<LarstiQ> damd: do you have a firewall that could cause this maybe?
<damd> no, i don't have a firewall, unless "microsoft security essentials" provides one
<LarstiQ> damd: it does afaik (or builtin to windows itself)
<damd> apparently i had the windows default firewall turned on, but turning it off didn't help
<damd> turning off real-time protection in security essentials didn't help either
<LarstiQ> damd: the other thing that comes up in google hits is that something else is already using the port the application tries to bind to
<LarstiQ> but that doesn't make much sense in this case
<damd> i'll try restarting the computer... :P
<LarstiQ> damd: did that work?
<damd> haven't tried just yet, hold on
<damd> i'm afraid it didn't :/
<LarstiQ> ok
<damd> it's really weird, because it worked the last time i tried it, which was a few months ago
<damd> i really haven't touched bzr since
<LarstiQ> damd: right, might not be bzr itself that changed though
<damd> you're right
<LarstiQ> damd: you mentioned you tried to upgrade it now?
<damd> yeah, i uninstalled bzr 2.3.1 (if i recall correctly) and installed the current 2.3.x stable
<damd> 2.3.4 i think it was
<damd> i used the standalone installer
<LarstiQ> damd: not that I think it would solve it, but any reason not to use 2.4? (Or a 2.5 beta if you want to try that)
<damd> when i tried to start the 2.4 stable installer, nothing happened, when i tried to start it from total commander, total commander just hanged
 * LarstiQ blinks
<damd> so did i :P
<LarstiQ> damd: well, that's a reason :)
<damd> :)
<LarstiQ> damd: could you maybe try a different ssh provider?
<damd> i'm not sure which one that would be, i've only ever used the putty suite
<LarstiQ> paramiko is bundled with the standalone bzr installer I believe
 * LarstiQ looks up how to tell bzr to use it
<damd> my first guess would be BZR_SSH
<LarstiQ> yeah
<LarstiQ> maybe we should just try BZR_SSH=paramiko instead of me reading the code
<LarstiQ> right, 'paramiko' or 'none'
<damd> i can't find paramiko on my system
<LarstiQ> brb
<LarstiQ> damd: it's a python implementation, would be in with the bzr executable afaik
<damd> oh
<damd> well, same error
<damd> d:\repos\emacs>set BZR_SSH
<damd> BZR_SSH=paramiko
<LarstiQ> bah
<LarstiQ> damd: can you ssh in to rule out any problems with putty?
<LarstiQ> or well
<LarstiQ> problems indepedent of bzr
<LarstiQ> 11
<LarstiQ> woops
<damd> in putty i get "network error: permission denied"
<LarstiQ> damd: can we get more verbosity from putty?
<damd> i have no idea to be honest
<LarstiQ> damd: everything I can dig up keeps pointing at firewalls :/
<damd> yeah, thanks a lot for the effort though
<damd> you've done way more than i hoped for
<LarstiQ> damd: np. I wish I could solve it
<damd> luckily it's not that big of a deal
<LarstiQ> damd: ok then :)
<LarstiQ> damd: it occurs to me that perhaps it is a roundabout way of saying the equivalent of the openssh "Permission denied (publickey)."
<Kamping_Kaiser> Hi all. can bzr import{dsc,tar} import only the debian/ directory from a package?
<mathrick> hmm, is it normal that I see bzr 2.5b leaving locks all over the place when I Ctrl+C it?
<mathrick> win32 here
<lifeless> not expected no
<mathrick> then I'm seeing it do that pretty much every time
<lifeless> file a bug?
#bzr 2012-02-15
<poolie> hi all
<wgz> ack, I need to be in bed if I'm gonna make tomorrow morning
<poolie> sleep well :)
<wgz> night!
<poolie> lifeless, did you see http://giovanni.bajo.it/2011/09/golomb-coded-sets/
<lifeless> poolie: interesting!
<poolie> it's a very elegant series of steps
<lifeless> indeed
<poolie> i'd like to have a chat with you some time this week
<AuroraBorealis> https://bugs.launchpad.net/bzr/+bug/847388 i believe this bug is 'solved', but i dunno how to confirm it (that it works on windows/mac)
<ubot5> Ubuntu bug 847388 in Bazaar ""gpg: cannot open `/dev/tty': No such device or address" on Ubuntu when signing commits" [Medium,In progress]
<poolie> AuroraBorealis, solved how?
<poolie> we pass the option, or we give it a tty, or  gpg stopped complaining?
<AuroraBorealis> my 'change' in that branch is literally just adding --no-tty to the gpg arguments
<lifeless> poolie: sure, that would be great. At 1730 my time we start operation cynthia-has-to-go-to-bed, but other than that I'm free whenever my google calendar thinks I'm free
<poolie> oh you're mark?
<AuroraBorealis> that makes it so it WORKs on ubuntu (which was the only OS that had problems), and it still works as intended on mac/windows
<AuroraBorealis> yeah. i should probably use that name here xD
<poolie> if you want to only land it on trunk i think you can just put it in
<poolie> if it's intended for 2.5 we have to be quite careful
<AuroraBorealis> i dunno how to 'put it in' or if its indended for 2.5
<AuroraBorealis> it pretty much makes bazaar explorer unusable if you are signing commits (since you can't commit with it)
<poolie> so you're prettysure that has no (harmful) effect on windows?
<poolie> i don't expect it would
<AuroraBorealis> i tried it
<poolie> oh, great
<AuroraBorealis> i just downloaded my branch and ran the bzr python file, tried creating a repo and commiting with the signing
<poolie> ok so you should just click 'propose for merging' on https://code.launchpad.net/~markgrandi/bzr/gpg_devttynotfound_fix
<poolie> and choose lp:bzr/2.5 as the target
<AuroraBorealis> i mean i 'hope' it worked, it commited and didnt say any errors, i dont think there is a way yet to actualy verify the signatures =P
<AuroraBorealis> ~bzr-pqm/bzr/2.5 that it?
<poolie> that's it
<poolie> yes, http://doc.bazaar.canonical.com/beta/en/user-reference/verify-signatures-help.html
<AuroraBorealis> hmm needs some weird package installed on windows
<AuroraBorealis> i'll try it later
<poolie> ok
<poolie> i would be reluctant to put it in after the last beta unless it was well tested across platforms
<poolie> really only windows is a concern though
<poolie> mm
<poolie> lifeless, ok, 12nz tomorrow?
<lifeless> sure
<mgz> morning all!
<vila> morning mgz et al.
<poolie> hi mgz, hi vila
<poolie> mgz i replied on https://bugs.launchpad.net/bzr/+bug/851834
<ubot5> Ubuntu bug 851834 in bzr (Ubuntu) "bzr crashed with error in _curl_perform(): (35, 'gnutls_handshake() failed: A TLS packet with unexpected length was received.')" [Undecided,Confirmed]
<mgz> poolie: thanks
<poolie> i'm not sure it will help but that's what i'd try next
<wgz> is the kind of thing I was after
<poolie> wgz,  then you can open the pcap file in wireshark
<poolie> with which jelmer is an expert
<wgz> the use of jelmer is also something I'm in favour of
<jelmer> *ahem* :)
<vila> jelmer: so, re-reading http://docs.python.org/library/ssl.html?highlight=cert_optional#ssl.CERT_OPTIONAL
<vila> jelmer: certificates will be required from the other side, i.e. required from the server by the client
<vila> jelmer: that's about the server certificate not about the client root certificates
<jelmer> vila: ah, ok
<jelmer> vila: so I guess we'll need a new option after all
<vila> well, a new value for the option will do in the interim
<vila> what I want to avoid is people setting it in their config file and don't use the default when we change it
<vila> s/I want/I'd like/ ;)
<mgz> something as dumb as ssl.cert_reqs default being 'none' on win and osx and 'required' otherwise would be okay for now
<farblue> morning everyone :) We are evaluating switching from svn to an alternative vcs and can't find any info on whether bzr has support for something similar to svn's --record-only as a way to prevent a commit being merged down from branch to trunk
<Peng> What's --record-only?
<farblue> it is used during a merge to mark the merge as having been done but without actually applying the patch
<farblue> for instance, we have a release branch and trunk and we might have made a change on the release branch we don't want in trunk (a bug that's been fixed as part of larger changes in trunk but then patched in the release branch quickly to prevent problems)
<farblue> we want to merge the release branch back to trunk to prevent regressions but we don't want that particular commit to be merged back
<Peng> You can bzr merge it and then do "bzr revert ." -- note the period -- to throw out the physical changes but leave the merge metadata.
<poolie> thanks Peng
<poolie> night all
<farblue> ok, that's a reasonable option
<farblue> a little less intuitive than the --record-only svn option but at least there is a way :)
<farblue> any other ideas? any plugins that might help?
<farblue> Just gathering support for bzr over other options you see :) Need to put forward a good case :)
<poolie> farblue, that's how it's done at the moment
<poolie> mm
<vila> mgz: works for me, will file a mp doing that
<poolie> you could fairly easily patch bzr to add a --record-only if you want
<farblue> good point :)
<farblue> I see the alternative way to do it might be to add a metadata tag of some sort to the commit so that when anyone tries to merge it it just updates the merge tracking and doesn't apply the patch
<farblue> anyhow, thanks :D
<LarstiQ> vila: do you have any numbers for how much an improvement the config caching is?
<vila> LarstiQ: I will have them shortly for the whole test suite but you can look at the impact on the hpss calls in the revision I recently landed
<vila> ghaa, unity 2D has some rough edges :-/
<mgz> sharp edges, being a planar surface I'd expect.
<vila> hehe
<LarstiQ> vila: ah right. About 1 to 2 less hpss calls in 10 places
<vila> LarstiQ: roughly the actual implementation does: to get an option value: read/parse the config file[s] where the option can be defined, to set an option: read/write the config file
<LarstiQ> mgz: ah hmm, but the regularity of the edge might be pretty bad
<LarstiQ> vila: and within a lock it will only read once?
<vila> LarstiQ: the new implementation will read each file once and cache its content, modifications are cached and flushed when the lock is released, read the file (for concurrent updates), write it
<vila> LarstiQ: almost yes
<vila> LarstiQ: that is, without modifications, it's read only once
<vila> LarstiQ: if there is at least one modification, it needs to be read again (to protect potential modifications made by other processes) and write once
<LarstiQ> vila: right.  So then we'd expect more benefit on longer lived operations
 * LarstiQ nods
<vila> LarstiQ: the main target is to allow reading once for all options (the fallouts are in the tricky update process that requires a lock)
<LarstiQ> aye
<vila> hmm, in fact the unity 2D model when switching wrokspaces is in some way *better* than the 3D one: all desktop are presented with all windows 'exposed' so when you switch to a different workspace you can directly select the windows you're interested in
<vila> it's worse if the windows you're interested in is already visible of course...
<vila> mgz, jelmer: https://code.launchpad.net/~vila/bzr/929179-default-ssl-certs/+merge/93177 is up for review
<vila> mgz: may be you should include that for the 2.5b6 windows installers and get them out of the door :)
<vila> mgz: also see bug #932647 for more info I gathered on the windows native calls
<ubot5> Launchpad bug 932647 in Bazaar "native root certificates should be supported on windows" [High,Confirmed] https://launchpad.net/bugs/932647
<farblue> hi again :)
<farblue> a quick question about revision numbers - I understand the incrementing number and the . separated numbers for branches
<farblue> but are these global for the repo or are they specific to my copy of the repo?
<farblue> e.g. if i refer to revision 1234 will it be the same revision as rev 1234 on a colleague's machine?
<quicksilver> if they're looking at the same branch
<quicksilver> then they'll have the same numbers.
<farblue> I'm assuming 'trunk' here as there are no dots in the number
<quicksilver> if you like revision numbers (we do!) then you will want to make sure you don't "push" onto one of your main trees
<quicksilver> ...from a different branch
<quicksilver> pushing from a different branch can pivot the revision numbers.
<quicksilver> instead, merge + commit into the branch and keep your revnos monotonic.
<farblue> so you mean we should merge our work onto the 'trunk' and then push trunk?
<quicksilver> if you are working on separate branches, yes.
<quicksilver> if you are just working directly on trunk it doesn't matter.
<farblue> ok
<quicksilver> if you *are* working directly on trunk then I recommend a 'bound branch'
<quicksilver> that makes it harder to get it wrong.
<quicksilver> (all your commits go upstream immediately and it complains if you're out of date)
<quicksilver> (1) small fixes directly on trunk, use a bound branch (2) feature development in separate branches, eventually merged into trunk
<quicksilver> is the workflow we use.
<LarstiQ> farblue: you can also set the `append_only` option on trunk
<farblue> Currently we use SVN and are looking at alternatives as part of evaluating whether SVN still does what we need. From what I understand so far, we can have bound trunk and bound branches just like svn's way of doing things then we can start to make use of local, unbound branches for local work
<farblue> append_only means it won't re-shuffle the revisions, I gather
 * LarstiQ nods
<quicksilver> yes although nothing to stop you also periodically publishing those "local" branches to a central server for mutual code review etc.
<quicksilver> (under a different name from trunk, clearly!)
<quicksilver> LarstiQ: thanks, I didn't know about that one.
<farblue> cool :)
<LarstiQ> `append_revisions_only` is the correct name according to `bzr help configuration`
<farblue> We refer to revision numbers quite a lot in tickets, in redmine etc. and changing those to manual tags or long sha1 hashes doesn't appeal :)
<quicksilver> agree farblue
<quicksilver> so do we
<quicksilver> also redmine^Wchiliproject's repo viewer gets confused if revision numbers change.
<quicksilver> LarstiQ: will it also forbid the occasionally bzr push --overwrite where we really *do* need to change history?
<LarstiQ> quicksilver: yes
<mgz> yes, but you can flip the config, push, and flip it back
<quicksilver> nod
<quicksilver> thanks
<jelmer> vila: did your RangeFile.read patch land?
<vila> I think so
<vila> jelmer: found another case where it's not enough ?
<jelmer> vila: yeah
<vila> :-/
<jelmer> I guess you've only fixed it for the size=-1 case?
<vila> details ?
<vila> well, I was testing with an import that used size=16384 or something, may be I didn't run it against the last version
<jelmer> I'm calling read(1024) on a RangeFile returned by HttpTransport_urllib.get()
<vila> and ?
<vila> I mean, how does it fail ?
<jelmer> bzr: ERROR: Invalid range access in http://xwax.org/devel/xwax.git/objects/21/6e47cb4d38615f2e3cb306912fc495e0bdc713 at 2: Can't read 1024 bytes across range (0, 157)
 * vila blinks
<vila> the error is supposed to be raised by a different code path
<vila> so either you're not using the right bzrlib or ... something is broken in the whole file detection (which seems weird since it's based on the 200 error code...)
<jelmer> ah, yeah
<jelmer> vila: sorry, pebkac
<jelmer> I'm indeed using an older bzr version
<vila> no worries, better safe than sorry
 * vila re-runs his test for good measure, blaming unity 2D for making it harder to work with multiple workspaces ;)
<farblue> Can anyone tell me whether bar has support or a plugin to support token locking or binary (unmergable) content? Subversion has locks, for instance.
<farblue> bzr* (autocorrect fail)
<farblue> to help prevent 2 people working on a binary asset at the same time
<wgz> https://lists.ubuntu.com/archives/bazaar/2008q4/050125.html
<wgz> https://lists.ubuntu.com/archives/bazaar/2010q1/067494.html
<farblue> interesting
<farblue> does it work? anyone using it?
<Riddell> congratulations jelmer
<jelmer> Riddell: thanks, what for ? :)
<Riddell> jelmer: the canonical spotlight award!
<mgz> hey, there's a prize and everything. go jelmer.
<jml> +1
<jelmer> wow, thanks! :) I hadn't seen the email yet
<GRiD> congrats jelmer
<vila> cong... ha, I'm late, anyway, just saw it, congrats jelmer ;)
 * quicksilver doesn't know what that is, but congrats jelmer anyway :)
<vila> quicksilver:hehe, sry, he got some company internal award for being our... dude ;)
<quicksilver> jelmer++ # dude
<jelmer> heh, thanks vila, quicksilver :)
<mgz> I think we ought to make congratulate jelmer day a regular thing
<mgz> makes a nice change from why haven't fixed my pet bug yet jelmer days
<vila> mgz: +1
<vila> jelmer: looks like my review got lost on https://code.launchpad.net/~jelmer/bzr/2a-repo-supports-nested-trees/+merge/89919, dunno what happened, just re-did it
<jelmer> vila: merci bien !
<farblue> hi all :)
<farblue> does anyone have experience of dealing with 'vendor branches' in bzr?
<vila> farblue: we are GPL hackers, we don't sell anything, all branches are free ;)
<farblue> lol
<vila> farblue: joke aside, all branches are equal except when social conventions apply
<vila> so a 'vendor branch' is just a branch and how you interact with it depends on your workflow
<farblue> ok, let me rephrase: dealing with developing on top of a third-party source code for which you only see the release versions
<vila> you can maintain a vendor branch with its own set of changes and still merge regularly from trunk
<vila> oh, you mean the release versions are not under version control at all and you get only tarballs ?
<farblue> yep
<farblue> currently we spend ages in svn applying the new source over the top of our 'vendor branch'
<farblue> and it's a pain
<farblue> of course, once done we can merge the changes into trunk and all is rather easier
<farblue> but that initial application of the new source dump over the top of our 'vendor branch' is a real pain
<vila> yup, the crucial point is to track the releases in a bzr branch that share history with *your* stuff
<farblue> anyone got experience of how well bzr handles this?
<farblue> yeah, I mean once we've updated the vendor branch in svn things do work well enough but that initial application of the new vendor code release to the vendor branch working copy is horrible
<farblue> just wondering whether life would be easier when using bzr
<vila> pretty well as long as you can avoid your 'parallel import' nemesis
<farblue> parallel import?
<vila> bzr tracks renames by assigning a file-id when a file is first added
<vila> there is a catch: if the same file is added independently, it gets a different file-id (it is imported in parallel)
<farblue> right
<farblue> so, like with svn, if a file is renamed we need to go hunting for it and tell bzr that, in fact, this new file isn't new but a rename (i.e. apply the rename first to the old file before then replacing it with the updated version)
<vila> if you already have a branch with your stuff, create a new branch from that, untar the upstream source, commit
<farblue> won't that then mark the incoming changes from upstream as 'newer' than our changes?
<vila> well, ideally you start from the upstream source and create a branch for your stuff avoiding the issue, the trick above is for catching up
<vila> 'newer' depends on when you merge this upstream branch into your trunk
<vila> if you maintain the upstream branch separately and always untar there, things will become clearer in the long term
<vila> farblue: the best way to understand is to try and look at the result with 'bzr qlog trunk upstream' to see how the branches are related,  when they merge each other, etc
<farblue> in svn we have a branch for the upstream and then that is merged to trunk. We then develop on trunk (well, feature branches but whatever), making our changes as needed. We do our releases as you usually would etc. For a new upstream release we update the vendor branch to the latest version and then merge this set of updates into trunk, resolving the few conflicts we might have.
<farblue> does this basically sound the same as how you'd do it in bzr?
<vila> yup
<farblue> fine, ok :) For us it is step one - "updating the vendor branch to the latest version" that is the painful bit :(
<vila> the caveat is about *starting* the upstream branch
<vila> really ?
<farblue> well, the projects we are basing our code on tend to get refactored quite often and not released frequently so we have very large differences between upstream releases
<vila> ha
<farblue> a real pain actually
<vila> well, it's hard to get VCS benefits if upstream doesn't use VCS...
<farblue> hmm
<vila> are you sure you can't access their VCS repo ?
<farblue> well, for Roundcube we are considering it but they've also got better at releasing more frequently
<farblue> for other projects there is no public vas available
<vila> java code ?
<farblue> php
<vila> the only tricky part should be renames, unless you're talking about changes to code that is moved from one file to another
<vila> file/dir renames I mean
<farblue> well the worst situation for svn is where a file we have modified is renamed / moved in the upstream project
<LarstiQ> farblue: unpack into vendor branch, and then some combination of bzr add/bzr mv --auto/after?
<farblue> what's the --auto/after stuff?
<vila> guess the renames :)
<LarstiQ> farblue: I'd need to try out the workflow, but I think `unpack; bzr mv --auto; bzr add`
<farblue> guess the renames? cool :) Even if there has been a percentage of the source changed within the renamed file?
<vila> farblue: or more precisely: guess the renames based on the content
<LarstiQ> farblue: `bzr help mv`  doesn't elaborate too much, but --auto tries to guess renames
<vila> farblue: yup
<farblue> very useful :)
<vila> that could fail if the changes are too broad of course
<farblue> in many cases it's just a case of a folder having been renamed or similar but svn still hates this
<vila> but you can focus on those after most of the trivial ones have been handled
<farblue> yes, the ability to attempt to guess at renames is very useful
<vila> I'm not sure --auto handle dir renames but bzr will track them happily
<farblue> sounding good :)
<vila> basically, if you don't have the VCS history, you have to provide the minimal missing bits
<farblue> yeah
<farblue> now I originally considered whether stacked branches would work in this situation and I'm interested to understand why this hasn't been suggested :)
<vila> stacking is for repos more than for branches, avoid ti if you can ;)
<farblue> ok
<vila> s/ti/it/
<farblue> sounds like the advice I give to people enquiring about svn:externals :)
<GrueMaster> Hey.  Semi-noob question.  I have a tree that I maintain on launchpad, and a merge request.  The proposed merge was created by a user that used the source tarball (sans .bzr) and checked into a new tree with changes.  What is the easiest way to merge his changes.  My tree has diverged a little with other changes, but I think I can revert back to a common ancestor.
<vila> well, stacking repos was originally designed to handle access rights, where the feature branches are not allowed to add their revisions to the trunk repo (used by the trunk branch)
<vila> GrueMaster: url for the mp ?
<farblue> vila: yeah, I read that and wondered whether that could apply to a readonly upstream project
<GrueMaster> https://code.launchpad.net/~skydiver38/win32-image-writer/md5/+merge/88565
<vila> farblue: have a look at what a 'parallel import' can cause :-/
<GrueMaster> I also have a local copy of his branch.  I do most of my work in Linux.
<vila> GrueMaster: simpler answer: ask the submitter to start from your branch
<GrueMaster> I've suggested that a few times now.  Apparently Windows devs don't work well with cmdline tools.  :P
<vila> GrueMaster: oh, we have a GUI for them :)
<GrueMaster> I know, I have it on my VM of XP.
<vila> GrueMaster: it's even available in the all-in-one installer for windows at .. ok
<vila> so, more involved answer: pain
<GrueMaster> Doesn't help the current situation.
<farblue> in the situation where upstream do have a vcs in, say, subversion, what would be the recommended approach? Can you create a 'vendor branch' based on the svn release branch and then 'switch' to the new release and merge the changes?
<vila> farblue: use bzr-svn
<mgz> GrueMaster: make a new local branch at the revision he got the tarball from,
<vila> GrueMaster: ok, so the semi-easy answer is to get the proposed branch, copy the files (excluding .bzr) to a copy of your trunk
<mgz> get the diff from launchpad and apply it
<GrueMaster> And manual diff?  ugh
<farblue> so you use bzr-svn to create a 'pull' from, say, release branch 1.0 of the upstream project - what  is the process when they release  version 1.1 on a new release branch or tag?
<GrueMaster> grmbl.
<mgz> do `bzr commit --author {that guy}` ...
<vila> farblue: 'bzr pull'
<GrueMaster> That part I know.  I do that whenever someone just sends a patch.
<vila> farblue: or 'bzr pull -rtag:<tag>'
<mgz> then merge
<farblue> ok, so that pulls the latest from upstream.  then what? merge as normal?
<vila> yup
<mgz> GrueMaster: you should just be able to get his branch, and copy over the changes if you don't want fiddle with patches
<mgz> the trick is knowing what his rev 1 corresponds to in your real branch
<GrueMaster> Since he made changes first before adding them to a new tree, the entire project looks like a diff.
<farblue> vila: thanks :D very interesting that it works for cross-vcs
<vila> the tricky part is to make sure you use the correct file-ids or you'll fall into the same kind of issues GrueMaster is facing
<mgz> sure, but if you ignore the fact he created a branch at all
<GrueMaster> Commit 1 baseline is therefore already a diff.
<mgz> and just copy across the tree
<vila> farblue: yeah, many thanks to jelmer for that ;)
<farblue> quite! and the same for git and hg?
<mgz> presumably he started from some tag or other you released
<vila> farblue: yup, bzr-hg is still beta, but bzr-svn and bzr-git are used in production
<farblue> cool :)
<farblue> thanks for all your help :)
<GrueMaster> So, you are saying make a separate branch from my tree with the starting point before his change, then just copy his files over the top?  I'll give that a try.
<mgz> yup.
<vila> LarstiQ: because I didn't forget, config numbers: https://pastebin.canonical.com/60280/
<vila> LarstiQ: based on the config hooks triggered for the corresponding actions (load -> read file, save -> write file, the other should self-explanatory)
<vila> LarstiQ: the numbers don't match as the changes were introduced along the way (as well as new options), but the overall picture is still relevant
<vila> LarstiQ: oh, and that's from running: BZR_PLUGIN_PATH=-site ./bzr selftest --parallel=fork -Econfig_stats --subunit on all revisions and then using ./tools/subunit-sum
 * vila face palms, wrong paste site
<vila> http://paste.ubuntu.com/843296/
<vila> LarstiQ: instructions to reproduce: http://paste.ubuntu.com/843297/ but be aware I've been catching up when you ask this morning and only had to process ~80 revs (and it just finished ;-p)
<LarstiQ> vila: so a 700k drop in old_config.load for a 50k gain in new_config.load, not bad!
<vila> yup, and that's without caching 'bazaar.conf' and 'locations.conf'
<LarstiQ> vila: an increase of 250k gets though seems quite high?
<vila> LarstiQ: if there are new gets, it means we're using more options ;)
<vila> the point is to make get cheap, not to reduce its usage
<LarstiQ> vila: fair enough :)
<LarstiQ> vila: is it easy to find out where they come from?
<vila> but 250k more for 20.000 tests still is weird, there is probably something worth investigating
<vila> probably by making the hooks collect the option/file names
<friedrich> hello
<friedrich> I am trying to learn about bazaar, but I don't understand shared repos yet: How do i reconstruct if I deleted all folders and files within a shared repo, except the ".bzr" in the top-level ?
<bob2> you can't
<friedrich> but the .bzr in the top-level holds all information (guessing from the file size)
<bob2> it holds much of the information
<bob2> but the dirs you deleted hold the branch pointers
<bob2> afair
<friedrich> hm, ok
<fullermd> You may be able to reconstruct much of it by poking around in 'heads'.
<fullermd> If you don't have a lot of dead heads in your repo (deleted branches, uncommits, etc), it could be fairly easy.
<bob2> true
<fullermd> You've lost any branch config (remembered locations, frex), but you should be able to find the revs at least.
<bob2> helpfully will even have branch names in bzr
<friedrich> don't worry, it was just some test data, while trying to understand bzr
<bob2> friedrich, so .bzr in the repo root holds all the rev data, the 'branch directories' mostly just tell bzr which rev in the repo is the head of that branch
<friedrich> coming from monotone or fossil-scm I thought that there would be some easy way to reconstruct
<bob2> deleting those dirs is explicitly throwing data away
<fullermd> The shared repo is basically a big bucket full of revisions.  No real order or structure.
<abentley> jelmer: I would like automatic nicknames to use the Branch.name for colocated branches.  Does that make sense to you?
<fullermd> The branch dir is what says "these revs are mine", plus some ancillary bits like the saved push/pull/etc locations, possibly a nickname, and more rarely various other stuff.
<fullermd> There's a 'heads' command in bzrtools that will dig through the repo and tell you what 'head' revisions are in there, which are likely to have been the heads of branches.  With that you can make a new branch with that head.
<fullermd> So the history of the branch can be recovered (well, it's already there; made accessible anyway).
<fullermd> If you've got a lot of dead heads (like you'd get from uncommit, or abandoning and deleting a branch), it might take some work to dig out the ones you care about from the noise.
<fullermd> And if you had branches whose revs aren't heads (had descendents), you'd have to pretty much know what they are to get them back.
<friedrich> ok, I will check out bzrtools - thanks
<abentley> friedrich: If you do have a lot of dead heads, --by-date will show what's most recent.
<poolie> hi all
<abentley> poolie: hi.
<poolie> hi there
<poolie> thanks for nc:
<abentley> poolie: no problem.  It was so trivial I nearly didn't announce it.
<poolie> i was going to say maybe you should just merge it
<poolie> but, perhaps defaulting to the bzrdir of . is a bit too weird to support
<abentley> poolie: So I guess if you have a lightweight checkout of a colocated branch, nc: should refer to the bzrdir of the referenced branch.
<abentley> poolie: using the current bzrdir reflects a (not entirely crazy) assumption that your lightweight checkout is colocated with the colocated branches.
<poolie> right
<poolie> anyhow if you wanted to merge it, perhaps with a note in the help that it's experimental, that would be ok with me
<poolie> maybe make it x-nc:
<abentley> poolie: I thought the plan was to get other commands respecting colocated branches shortly, so that nc would not be useful for long.  But if you want it in core, I can do that.
<poolie> i think, generally, if there's a small and not harmful interim improvement, it's better to merge it than to count on the real fix arriving soon
<abentley> poolie: Do we have a user-facing term for Branch.name?
<poolie> i'm not sure
<poolie> not 'branch name'?
<abentley> poolie: I dunno, I just thought it might not be specific enough-- could refer to the basename of the branch or is nickname.  But I've come up with some verbiage I like.  I'll post the merge proposal in a minute.
<poolie> mm
<poolie> well, we should be consistent about it, and put it in a comment next to branch.name, and in overview.txt
<poolie> i agree that may be a bit generic
<abentley> poolie: Does vila's new stuff give us a way of substituting the branch nick or branch name in config files the way we used to do with appendpath?
<poolie> yes
<poolie> it may require some amount of glue to make it available there
<poolie> *small amount, hopefully
<abentley> poolie: I can't find any documentation.  Has it landed yet?
<poolie> looking
<poolie> so it is landed, in Config.expand_options, etc
<poolie> it doesn't look very documented though
<poolie> i'll mail him
<poolie> abentley, i think the short story is that you need to define a config variable for the thing you want to insert, with a default method that calculates the right value
<poolie> then you can just expand that with {foo} inside other values
<abentley> poolie: The default method is provided in Bazaar?
<poolie> you declare and register an Option object, and its default= constructor parameter is a callable
<poolie> hm
<poolie> it seems like it ought to be called with some context
 * abentley is kinda surprised that nickname isn't already registered.
<lifeless> poolie: hi
<poolie> hi there
<poolie> should have pung
<poolie> how about now?
<lifeless> sure
<lifeless> me being online and all :P
<abentley> poolie: This is what I was doing: https://code.launchpad.net/~abentley/bzr/name-nick/+merge/93319
#bzr 2012-02-16
<wgz> okay, that only took me all evening
<wgz> but have a build of pyqt that works with trunk python here so can be used with trunk bzr
<wgz> where is the syntax of BZR_PLUGINS_AT actually documented?
<wgz> http://doc.bazaar.canonical.com/beta/en/user-reference/configuration-help.html#bzr-plugins-at
<wgz> but... bzr-explorer still doesn't want to run inplace for some reason
<wgz> meh, I need the dir named 'explorer' not 'bzr-explorer'... what's the point of the @ then? just take the last dir component.
<wgz> and now it's bed time again.
<wgz> http://paste.ubuntu.com/843793/
<robert_ancell> how do I delete a wrong tag in LP bzr?
<mgrandi> is there a program all you guys use to look at diff files?
<jvargas> hi.
<mgrandi> hi
<jml> sorry, I've forgotten
<jml> how do I fetch a new remote branch into my colo repo?
<mgz> morning
<jml> mgz: hi
<jml> I need some help with colo
<jml> I've forgotten how to fetch a new remote branch into a colo
<jml> And now I'm getting conflicts sometimes when I switch branches
<jml> that doesn't make any sense to me.
<mgz> hey jml
<mgz> it's possible to get conflicts when switching if, for instance, a directory didn't exist but has other contents in your tree
<mgz> or is it something else?
<jml> mgz: hmm. maybe it is that.
 * jml looks
<mgz> I can't remember if there was a fancy way to branch into a new colo dir, but `bzr branch remote file:,branch=newlocal` should work
<jml> mgz: no, it's a text conflict in NEWS and a couple of other files
<jml> mgz: in this particular branch, I'm switching from testtools-0.9.12 to testtools-0.9.13. Am really perplexed by the conflicts.
<mgz> jml: and the tree was in a clean state when doing it? that would be odd.
<jml> mgz: yeah, no text changes etc.
<jml> mgz: http://paste.ubuntu.com/844150/
<jml> mgz: easy enough to reproduce the problem.
<jml> mgz: further, I have no idea what to do when I get a conflict like that.
<mgz> well `bzr revert . && bzr resolve` I guess
<mgz> the basic transform between .13 and .12 works fine here
<mgz> so, I guess there must be a more specific bug, if you would do the honour of filing that jml?
<jml> mgz: sure thing.
<jml> mgz: https://bugs.launchpad.net/bzr/+bug/933362
<ubot5> Ubuntu bug 933362 in Bazaar "Unexpected conflict switching within colo branch" [Undecided,New]
<mgz> ...well, I've just got myself in a weird state trying to replicate your setup
<mgz> I wanted a colo branch, but somehow have "Unshared repository with trees and colocated branches (format: 2a)"
<mgz> and now can't do any operations in that dir, as it's not a branch.
<jml> mgz: huh
<jml> mgz: the pastebin starts from scratch, fwiw.
<jml> incidentally, I wish I knew what public API python-subunit had so I could clean up some of these unnecessary imports.
<jml> hmm, now, to figure out how these tests manage to pass
<mgz> yeah, I was trying to be clever by creating the branches in a slightly different way to see if it was swtich -b at fault
<mgz> but screwed up the first step
<mgz> `bzr branch testtools file:colotesttools,branch=trunk` does the weirdness
<mgz> jml: well, either everything without an underscore, or I guess having a look at what using subunit and being pragmatic
<jml> in general, I think I quite like colo, but one thing it makes slightly harder is opening up the trunk version of a branched file for side-by-side comparison.
<jml> mgz: ISTR subunit deliberately exporting 'content' and 'content_type' from testtools. ICBW though.
<alansaul> Hey guys, I want to merge some changes I accidently made in my trunk branch (but havent yet commited) into a new branch
<alansaul> so ive made the branch, but now I want to commit to that branch, not to my current one, how do I do that?
<mgz> the easy way is just to do `bzr branch trunk new_feature` then `bzr pull --overwrite -r-4 trunk trunk`
<mgz> the starting state of trunk is what you want in your feature branch
<mgz> and then you can just chop off the last N revisions from trunk
<mgz> ...the second command may be wrong, but there is a way of doing that (or you can just uncommit several times)
<leo2007> why can't there be two bzr command running on the same repo simultaneously?
<jelmer> leo2007: there can be multiple commands running on the same repository
<jelmer> leo2007: you can't write to the working tree state file with multiple processes concurrently though
<abentley> jelmer: What do you think of using the colocated branch name as default nick?  I've got an mp up for that, but poolie wanted to see what you thought.  https://code.launchpad.net/~abentley/bzr/name-nick/+merge/93319
<jelmer> abentley: I thought I'd replied, but something seems to have eaten my email
<jelmer> abentley: I think that's a good idea,  I'll review again
<abentley> jelmer: great.  Thanks.
<abentley> jelmer: landing.  At last.
<abentley> jelmer: poolie suggested putting my "nc:" plugin in core, perhaps as "x-nc:" to indicate experimental nature.  Any thoughts?
<jelmer> abentley: I haven't looked at the code yet.I think it would be reasonable to add it as nc: or x-nc:
<jelmer> abentley: Of course the goal is to eventually just support passing colocated branch names to commands
<jelmer> abentley: but in the mean time it would be very useful; plus, I don't think there's a clear disadvantage in supporting it
<jelmer> I'm not sure if "nc" is the best prefix, though I don't really have any brilliant ideas on a better prefix
<mgz> no contest.
<abentley> jelmer: I'd use colo if the plugin didn't use it already.
<jelmer> hmm, yeah
<abentley> jelmer: "ncolo:"?
<abentley> jelmer: "jcolo" ? :-)
<jelmer> abentley: perhaps just "co:" ?
<mgz> kolo would be cooler, and it's jelmer, so, should use
<mgz> jk:
<abentley> jelmer: wfm.
<jelmer> mgz: I didn't realize using a k makes something cooler, let me make a note of that :)
<fullermd> jelmer: It doesn't.  It makes it kooler.
<jono> hey all
<jono> hey all
<jono>  I am trying to branch and keep getting:
<jono>  ConnectionReset reading response for 'BzrDir.open_2.1', retrying
<jono>  Permission denied (publickey).
<jono>  bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<jono>  I imported my public key after I did bzr launchpad-login
<wgz> if you do `ssh yourusername@bazaar.launchpad.net` what do you get?
<wgz> if you still have a key error, that's what needs fixing, if it says no shells, you've done everything right
<wgz> jono: any luck?
<jono> wgz, still no luck
<jono> wgz, we are discussing this in #launchpad
<jono> I think this is a key error
<spiv> "Permission denied (publickey)." strongly suggests a key problem, yse.
<spiv> *yes
#bzr 2012-02-17
<bob2> is bzr-hg maintained upstream?
<lifeless> yesish
<vila> hi all
* vila 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: vila
<frgomes> hello guys :)  I'm trying to import/checkout/branch (whatever works!) a remote SVN branch. But the remote SVN is broken revisions and I get the error message "Unable to fetch revision info". I was able to do it using git. Is there any bazaar command equivalent to "git svn clone -s -r98000:HEAD http://...." ? I mean: Is is possible to tell Bazaar to consider revisions *starting* at revision 98000 ? Thanks a lot :)
<mgz> morning all!
<vila> heya mgz
<mgz> well, the twisted-doc package is pretty useless, api docs are only online
<mgz> meh, need someone who actually understands twisted to look over this code, I've got no idea from their docs or code what idioms make sense
<mgz> http.Request is particularly mysterious, the process() method doesn't deal in deferreds so I'm not sure of the best way of doing error handling in response
<mgz> I guess just in callbacks?
<mgz> currently there's a funny mix of code that runs now and raises exceptions and deferred stuff that may have later issues
<czajkowski> aloha
<czajkowski> was wondering if someone  could help with a https://answers.launchpad.net/launchpad/+question/187958
<jelmer> hi czajkowski
<jelmer> czajkowski: it sounds like they're reverting the working tree locally rather than actually removing history from the branch
 * jelmer adds an answer
<czajkowski> jelmer: thanks
<vila> mgz: special treat for you: http://package-import.ubuntu.com/status/phpbb3.html#2012-02-17%2012:04:16.547398
<mgz> heh
<vila> mgz: can you confirm it's some bad file name encoding and especially which one ? That's the first time I see 'tar' being fooled this way
<mgz> well, it depends what's actually in the tar
<vila> bytes ?
<vila> linux is not supposed to interpret any file name right ?
<vila> and neither is tar AIUI
<mgz> the octal escapes for latin-1 chars seems a little cute, but is that just in the output?
<vila> ok, I'll let you know once I can reproduce locally (I've got  another repro recipe in flight)
<vila> just for the record, I upgraded pristine-tar to 1.20 on jubany (with losa help) and that fixed ~40 of the ~70 previous failures \o/
<vila> but apparently a newer xz|xz-utils is needed for a good chunk of the remaining ones, phpbb3 above is yet another failure but I thought about you ;)
<vila> jelmer: in other news, I also upgraded bzr to current bzr.dev on jubany and I now see deprecated calls for tree.inventory in builddeb
<vila> jelmer: should I file a bug or are you aware of the issue already
<jelmer> vila: a bug report would be great
<vila> ok, will do (and may even give it a try, shouldn't be that hard with all the tracebacks I already have)
<jelmer> vila: I have something already in progress, let me see about pushing that up
<vila> ha even better
<jelmer> IIRC it was still giving some test error that I haven't tracked down
<jelmer> ah, no - I remember what it was
<jelmer> I was going to add Tree.iter_child_entries
<vila> I haven't upgraded builddeb on jubany, still running revno 709
<vila> oh, in bzrlib itself you mean ?
<vila> revno 709 == 2.8.2
<jelmer> vila: Yeah - iterating over children is the main reason we access the inventory nowadays
<jelmer> and it will also be good to have that abstraction for nested trees later on
<vila> iter_entries_by_dir is not enough ?
<wgz> oddly, that seems to be arabic, not german
<wgz> Ø´Ø§Ù
<wgz> makes sense, whereas ÃÃÃ does not.
<vila> >_<
<vila> wgz: you read arabic ?
<jelmer> vila: that yields specific file ids or the entire tree
<vila> k
<wgz> vila: nope, but I can do some search engine wrangling :)
<wgz> http://en.wiktionary.org/wiki/Ø´Ø§Ù
<wgz> amusing word to pick.
<vila> hmm, "truth is out there" comes to mind :) I fail to see why this word would be used in a dir name...
<vila> well, given the german_(formal_honorifics) in front of it that is
<vila> may ask my daughter when she comes back ;)
<vila> jelmer: sorted out my notify issues, 'bzr-notify' is still found in /usr/bin even with sources installed (silly me), how do you run it from sources ? symlink in your $PATH ? Some ppa ?
<jelmer> vila: I use a symlink
<jelmer> we do also have daily builds, but I think the last few builds have failed (and I haven't had time to look into that yet)
<vila> no worries, was just curious, I've been relying on the system-wide install for a few months, but I like notify enough to switch to a symlink for now ;)
<GGhh> hi bzrists. couple of questions: 1) what's the cleanest way to rename a bzr repo, I mean the folder containing the .bzr sub-folder ? --- 2) Can "bzr mv" act on whole directories, i.e. moving a whole tree in another location of the repo? thx
<vila> GGhh: 1) mv, 2) no, 'bzr mv' works *inside* a tree
<GGhh> vila: ok, so the argument to "bzr mv" can only be a single file, right?
<GGhh> vile: I mean, your answer is a bit terse: "inside a tree" I have plenty of (sub) trees...
<GGhh> vila I meant
<GGhh> (from my understanding: "tree == directory")
<vila> sry, was afk
<vila> by tree I meant a bzr controlled working tree
<vila> bzr mv --help gives the details several files can be specified, the final DESTINATION can a dir in this case
<vila> just like 'mv'
<vila> the folder containing .bzr can be moved as you see fit unless you it's used by another folder containing a .bzr, i.e. if you use standalone branches (where .bzr contains the metadata for the tree, the branch and the repo) you can move them as you see fit
<vila> if you use a shared repo, you can move your branches and trees as long as they stay *below* the shared repo
<vila> finally, if you use checkouts that refer to branches then these branches can still be moved but you'll need to fix the references from the checkouts (working trees) afterwards
<vila> GGhh: ^
<GGhh> vila: reading
<GGhh> vila: I think I got it. thx. trying
<vila> GGhh: the best way to check which .bzr dirs are involved is 'bzr info -v'
<vila> bah, scratch -v, just 'bzr info'
<GGhh> vila: ok thx
<jelmer> vila: posted https://code.launchpad.net/~jelmer/bzr-builddeb/no-tree-inventory/+merge/93581
<vila> ouch, just hit AssertionError: Somehow we ended up with too much compressed data, 4108 > 4096, but that seems to be without extensions compiled (too many debug stuff in flight)
<vila> jelmer: approved
<jelmer> vila: dankuwelmerci!
<vila> :)
<vila> jelmer: ping me once it's landed and I'll deploy on jubany
<jelmer> vila: it has landed
<vila> jelmer: it is deployed :)
<jelmer> \o/
<quicksilver> what's the simplest way to --show-id a single file.
<quicksilver> I know I can bzr ls --show-ids the containing directory
<quicksilver> but that seems roundabout
<LarstiQ> quicksilver: `bzr file-id <FILENAME>`
<quicksilver> LarstiQ: weirdly that's missing from 'bzr help commands'
<LarstiQ> quicksilver: it's hidden
<quicksilver> I did bzr help commands | grep id before asking
<quicksilver> why?
<LarstiQ> quicksilver: bzr help hidden-commands
<LarstiQ> quicksilver: because it is of limited use and would clog up the help page I think
<quicksilver> interesting.
<quicksilver> but 'bzr help commands' is the long boring list anyway.
<vila> quicksilver: and also because we try hard to not expose any *-id stuff as they shouldn't be needed
<quicksilver> vila: I don't know any other way to get my head clear about files accidentally deleted and re-added
<quicksilver> or file conflicts incorrectly resolved by moving files around without telling bzr
<vila> which is a bug that should be fixed (deleted/re-added)
<vila> 'bzr resolve --take-{other|mine} file' is expected to help you avoid that :-}
<vila> (conflicts inccorrectly resolved)
<vila> s/cc/c/
<quicksilver> help you avoid getting in that state in teh first place
<vila> yup
<quicksilver> but not help you disentangle that state once you observer you are in it
<vila> right
<vila> hey, I'm not blaming you for suffering from bzr bugs ;) Just explaining the rationales ;)
<quicksilver> :)
<quicksilver> sure. But I thikn a good principle is to always expose the tools to enable users to understand the data model
<vila> for the later case, 'bzr st -C<suspicious> --show-ids' helps
<vila> or 'bzr st -r<right hand>..<merge> --show-ids'
<vila> quicksilver: yeah, the principle is good but... may also lead to exposing internals and let the user deal with the defects
<quicksilver> true
<vila> quicksilver: the simple rule "don't expose *-id" push us to refine the UI
<quicksilver> but without revids you have no unique way to refer to a commit
<vila> conflict resolution is.... hard, let's have a beer :)
<quicksilver> :)
<vila> oh, inside a given branch revno do wonders, even inside a set of branches for a given project with a reasonable workflow
<vila> ... so many assumptions hidden behind 'reasonable' :-/
<quicksilver> sure you can cook up a local naming scheme like "foo-branch:41.2.1"
<quicksilver> but somtimes just being able to say "quicksilver@theboss-12345" is convenient
<vila> my main objections to opaque revids is that... they don't carry any useful info, they're just a token with no ordering
<vila> and in most of the discussions the basic question is: right, is this revid older or younger than that one
<quicksilver> really?
<quicksilver> never had that discussion
<quicksilver> my discussion is more "which branches is that revid in/not in"
<vila> bug reports, irc
<vila> yeah, ancestry checks too
<vila> but if you share a common branch, the revno is also meaningful
<vila> jelmer: wow, just fixed an additional bug with https://code.launchpad.net/~vila/bzr/930182-display-reg-options/+merge/92807 good thing you push me there ;)
<quicksilver> vila: dotted revnos don't have the information you ask for either
<quicksilver> vila: 543.2.16 isn't before or after 832.8.54
<quicksilver> you know the first one *branched* earlier
<quicksilver> btu you don't know anything about when they happened, or if one has merged the other.
<quicksilver> they contain precisely one more piece of information - when they branched from master. That doesn't seem that interesting.
<jelmer> vila: hah, I was just reviewing that mp
<quicksilver> whereas, funnily enough, supposedly opaque revids actually have date and author information in.
<quicksilver> so I conclude that revids have more information in that dotted revnos :P
<jelmer> the ones generated by bzr itself generally are. For example, revisions imported from git are just "git-v1:SOMEUUID"
<jelmer> but yeah, it's very useful to be able to refer to a specific revision by just a globally unique fairly short string
<vila> jelmer: make sure you look at the rev I just pushed !
<vila> jelmer: and thanks :)
<vila> quicksilver: yeah, dotted revnos, <shudder> long and old discussions, there are alternate ways but they aren't trivial
<quicksilver> don't get me wrong, I like dotted revnos
<vila> gtg, friends arrived earlier than expected, have a good week-end all !
<quicksilver> I think they're handy and concise and in some cases more memoryable
<quicksilver> I just think revids have a place too :)
<quicksilver> have a great weekend.
<vila> quicksilver: hehe, I know opaque tokens are useful too ;)
<jelmer> vila: you too vila!
#bzr 2012-02-18
<jono> hey all
<jono> can bzr retain the permissions for files added to a branch?
<jono> namely, I want to ensure my +x remain executable
<jelmer> hi jono
<jelmer> jono: only the executable bit is tracked
<jono> jelmer, do I need to do anything for the +x to be retained?
<jelmer> jono: nope, it should work out of the box - as soon as you change the executability (is that a word?) of a file bzr should pick it up as a change
<jono> jelmer, cool, thanks!
<jono> thanks so much jelmer :-)
<damd> hi.  can i safely remove ~/bazaar from my system?  i'm using windows.
<damd> i'm trying to fix the connectivity problems i described a few days ago.
<damd> i'm using 2.4.2 now.
<damd> well, that didn't help...
<wgz> damd: yes, though you'll lose some settings, and it's unlikely to help
<damd> i can't figure out why this doesn't work
<damd> i tried disabling anything resembling a firewall, but still the same problem
<damd> i wonder if i can successfully branch anything else
<damd> interesting; that works
<damd> bzr branch lp:nxhtml
<damd> that works, but bzr branch bzr+ssh://damd@savannah-blah-blah/emacs/trunk doesn't
<damd> this doesn't work either: bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk
<damd> does anyone have some other non-lp repo that i can try to branch?
<fullermd> What problem do you have going from savannah?
<damd> bzr: ERROR: Connection error: failed to connect to bzr.savannah.gnu.org:4155: An attempt was made to access a socket in a way forbidden by its access permissions
<damd> when i use bzr+ssh, i get this:
<damd> bzr: ERROR: Unable to connect to SSH host bzr.savannah.gnu.org; Unable to connect to bzr.savannah.gnu.org: [Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions
<fullermd> That sounds like a local firewall (local meaning on-system, not on-network; sounds inside the local IP stack).
<damd> i'll try disabling windows firewall again
<damd> same problems
<fullermd> Could also experiment with pulling bzr out of the loop; try just telnet'ing to the host/port.
<damd> i don't think windows 7 even has telnet anymore, i'll see
<damd> Microsoft Telnet> open savannah.gnu.org 22
<damd> Connecting To savannah.gnu.org...Could not open connection to the host, on port 22: Connect failed
<damd> isn't 22 the right port?
<fullermd> Mmm.  I'm probably not much good to you; I don't know Windows.  But with that sort of error, I'd bet heavily it's something in the local system denying the connections from being setup.
<fullermd> For ssh, yeah.  Think you want bzr.savannah.gnu.org though.
<damd> both port 22 and 23 failed on both savannah and bzr.savannah
<damd> "Connect failed"
<fullermd> Right away, or after a few seconds?
<damd> right away
<fullermd> I just get a blackhole trying for savannah (as if it's dropping the packets), and I get the ssh daemon right away on bzr.savannah.
<fullermd> The bare "connect failed" could be a in-stack block, or a firewall somewhere on the network between you and savannah.
<fullermd> But the "attmped to access socket in a way forbidden" just screams in-stack.
<damd> i'm not very familiar with networking in general and certainly not the TCP/IP stack
<fullermd> Unfortunately (well, for you ;) I haven't really worked with windows since '96, so I'm not sure where to look for that sort of ACL.
<damd> i signed up for the bzr mailing list but i have yet to receive a confirmation e-mail
<fullermd> I'd poke around "near" the firewall stuff to see if anything else looks like it may block network stuff per-program.
<damd> i figured completely disabling everything "firewall" in windows should do the trick... :(
<fullermd> That would be my first guess, yah.  But something's still off, so...
<damd> my internet router has something called "firewall protection" as well, but even disabling that doesn't help
<fullermd> It's conceivable that someone at bzr.savannah doesn't like you, and blocked you at that end.  But I'd expect you to still get a blackhole going to the [bare] savannah ssh, like I do.  So my guess is definitely close to you.
<spiv> I agree with fullermd
<fullermd> What if you try to telnet to LP?
<fullermd> bazaar.launchpad.net port 22
<fullermd> That works for you with bzr, right?  See what happens with telnet.
<fullermd> (not that I really know how to interpret whatever result happens, but maybe we'll get lucky)
<damd> when i telnet there i get some gibberish that i can't really interpret
<damd> it starts with SSH-2.0-Twisted
 * fullermd nods.
<spiv> Ok, so that's the expected result: you're connected to the SSH server.
<fullermd> That would be right.
<spiv> That is the sort of thing that should happen when you connect to other bzr+ssh servers
<fullermd> Hm.
<fullermd> How about bzr.sourceforge.net 22?  That gives me an OpenSSH 5.3 banner.
<damd> yep, same there
<damd> i.e., i get the banner as well
<fullermd> So it seems like just savannah.  Weird.
<fullermd> Lesse if we can dig up a bzr-using project on SF, so you can try hitting that from bzr.
<damd> i was just confirmed for the bazaar mailing list btw
 * fullermd hasn't converted his project there yet...
<fullermd> How about `bzr info bzr://bugzilla-de.bzr.sourceforge.net/bzrroot/bugzilla-de` ?
<damd> with that i successfully retrieve the info
<fullermd> Mmph.  So it doesn't seem to be extra-strict on bzr vs telnet on a per-app basis.
<fullermd> So apparently it's just $SOMETHING not letting anything on your system talk to Savannah.  That's...   bizarre.
<fullermd> Apache is running on bzr.savannah.gnu.org.  Can you pull that up in a browser (or via telnet to 80)?
<damd> yes, that works
 * fullermd blinks.
<fullermd> It's apparently running ssh on the https port.  What if you telnet to 443?
<damd> OpenSSH banner
<fullermd> Even better.  So it's letting you get to bzr.savannah on web ports, but not on ssh or bzr.
<fullermd> Whatever "it" is.  I'm short on ideas...
<fullermd> Try hitting bzr.savannah on 22 again.
<damd> instananeously: Connecting To bzr.savannah.gnu.org...Could not open connection to the host, on port 22: Connect failed
<damd> instantaneously*
<fullermd> Wacky wacky.
<fullermd> Well, if it were me, my next step would probably be to try a packet dump to see if the packets are actually hitting the wire (and I'm getting a RST or ICMP unreachable or something else back from somewhere along the way to savannah), or it's never showing up on the wire and it's something in the local stack just refusing to try.
<damd> these are the last parts of the traceback in the bzr log:
<damd>   File "bzrlib\transport\ssh.pyo", line 332, in connect_ssh
<damd>   File "bzrlib\transport\ssh.pyo", line 287, in _connect
<damd>   File "bzrlib\transport\ssh.pyo", line 257, in _raise_connection_error
<damd> return code 3
<fullermd> Yeah, that's probably just telling us the same thing as the telnet; not getting the socket connected.
<damd> i've asked the emacs-devel mailing list now and hopefully they can shed some light
<damd> apparently i can use this as an alternative to the standard host: bzr+ssh://damd@bzr.sv.gnu.org:443/emacs/trunk
<fullermd> Yeah, that's the ssh server listening on the https port.
<fullermd> Doesn't solve your problem (which should be solved; it's too weird to let wander around unsupervised), but it does get you to the code.
<damd> i'm really clueless as to what i'm supposed to do though
<damd> i switch ISP in about two weeks, maybe that will solve it for me...
<fullermd> Possible, I guess.
<LarstiQ_> damd: weird stuff
<jelmer> 'morning all
<LarstiQ> hey jelmer
<frgomes> hello guys. I'm a newbie user of bazaar. I will be migrating my repositories to bzr as far as time permits. Where I work they hava a huuuge svn repository and I've decided to checkout/branch a svn branch. I had problems because their svn repo is broken, then bzr complains that a revision is missing :(   Any idea how I could circumvent this?
<jelmer> hi frgomes
<frgomes> I've used git for this. With git you can specify a revision range.
<jelmer> frgomes: what's the error you are getting exactly?
<frgomes> jelmer: hi :)
<frgomes> Unable to fetch revision info nnnnn
<jelmer> frgomes: oh, that's indeed an issue with a broken svn server :-/
<frgomes> using git I've specified a revision range, like this: -r98000-HEAD
<jelmer> frgomes: if you can get your hands on a local copy of that repository, that would be a good way to work around that
<frgomes> jelmer: do you know if there are plans to support revision ranges?
<jelmer> frgomes: in bzr-svn ? that would depend on support in bzr core
<jelmer> frgomes: you'd need inter-format stacking here; there are some vague plans around that, but nothing concrete as far as I know
<frgomes> jelmer: thanks a lot.
<frgomes> jelmer: I will use git and bzr in parallel for the time being. I don't like those UUIDs git employs. They are absolutely nonsense from the user perspective.
<frgomes> jelmer: thanks a lot for bazaar. it's a great dvcs. cheers :)
<jelmer> great to hear you like it :)
<skelterjohn> how do i update to a particular tag?
<skelterjohn> i've tried "bzr up theTagName" but i think it is ignoring theTagName
<damd> do you really call that "updating"?
<damd> i don't know bzr very well, but i think in git you "checkout" tags
<skelterjohn> checkout was the first thing it ried
<skelterjohn> since it wasn't a branch name i was targeting, it didn't work
<skelterjohn> in hg, you can "hg up aTagOrBranch"
<skelterjohn> so i tried that second
<damd> Revert a working directory to the tree of an existing tag
<damd> The tag name is mapped to a revision id, and the tree is reverted to that revision. This implies reverting the working tree's tag revisions.
<jelmer> skelterjohn: 'bzr up -rtag:aTagName'
<skelterjohn> thanks jelmer
<damd> ignore me
<jelmer> (or 'bzr up -raTagName' should work too)
<damd> "Tags give human-meaningful names to revisions. Commands that take a -r (ârevision) option can be given -rtag:X, where X is any previously created tag."
<jelmer> indeed :)
<jono> has anyone here used jamesh's gpgme Python lib?
<jelmer> jono: yes, a bit
<jelmer> jono: we use it in bzr, and launchpad uses it too
<jono> jelmer, I am trying to figure out how to verify a file
<jono> jelmer, does the lib allow me to verify a file?
<jelmer> jono: it should - I think you might have to load it into memory to do so though
<jono> jelmer, can I verify a file with just a public key with gpg?
<jelmer> jono: yes, I think so
<jelmer> jono: for some inspiration, see bzrlib/gpg.py around line 250
<jono> jelmer, do you have a link to that online?
#bzr 2013-02-11
<Nutter> I'm trying to specify my Launchpad id for Bazaar, so it connects to Launchpad over SSL rather than HTTP. I've generated/set up the cert for my account, but when I try to use it I get an error:
<Nutter> bzr: ERROR: Connection error: curl connection error (SSL certificate problem: self signed certificate in certificate chain)
<Nutter> why would I get this error? It's supposed to be self-signed afaik
<bob2> what are you trying to do?
<Nutter> long story short, I'm trying to pull/merge a repo (kicad), but I'm under Windows and am running into the out-of-memory issue in bzr - and am hoping that if I can use bzr+ssh rather than http it'll be resolved (as per https://answers.launchpad.net/bzr/+question/175127)
<bob2> the above is pretty confused then
<Nutter> yes, yes I am :)
<bob2> since you'd just paste your pub key into lp
<Nutter> and I meant ssh not ssl in the question sorry
<Nutter> yes I have done that
<Nutter> and it shows up just fine in LP - but bzr gives that error for some reason
<bob2> no one else can see your console, so you'd have to bpaste.net the whole thing
<Wiz_KeeD> hey guys
<Wiz_KeeD> any ideea why i get this when trying to push? Error received from smart server: ('PermissionDenied'
<Wiz_KeeD> ErrorFromSmartServer: Error received from smart server: ('PermissionDenied', '/opt/openerp/bzr_repo/.bzr/repository/upload/0f078pdsu80lqutwgm61.pack', ": [Errno 13] Permission denied: u'/opt/openerp/bzr_repo/.bzr/repository/upload/0f078pdsu80lqutwgm61.pack'")
<Wiz_KeeD> To be more precise
<mgz> look at the log on the server side?
<Wiz_KeeD> what log?
<osfd_> Hi there. How do you downgrade to a previous branch ??
<osfd_> say I wanna go fro; 3941 to 3936...
<Wiz_KeeD> bzr revert 3946
<Wiz_KeeD> ?
<mgz> Wiz_KeeD: the .bzr.log from the smart server side
<osfd_> Wiz_KeeD, thank you !
<mgz> grep for that error it sent you back and find the full traceback
<Wiz_KeeD> i have the full traceback it gave me
<mgz> you don't want the client side traceback
<Wiz_KeeD> no problem osfd_
<osfd_> Wiz_KeeD, what if I want to checkout an older rev ?
<mgz> the error wasn't where you ran the command, it was remote
<Wiz_KeeD> mgz would be more qualified to answer that i guess
<Wiz_KeeD> yes
<Wiz_KeeD> http://pastie.org/6116001
<mgz> osfd_: if you actually want a checkout, you just pass -r as with all the other commands that take a revision, see the help
<Wiz_KeeD> mgz, http://pastie.org/6116016
<mgz> that doesn't look like the right log :)
<Wiz_KeeD> which one is then?
<mgz> it's porbably just unix perms on the directory you're trying to push to though
<mgz> neither of those
<Wiz_KeeD> i did locate .bzr.log
<Wiz_KeeD> got only two locations and this is the only one that got updated when i tried to push
<Wiz_KeeD> i've set ownership to my ssh user that pusshes and i get the same error
<Wiz_KeeD> now i also set 777 on the whole dir and tried pushing i get the same error
<Wiz_KeeD> I can even start from scratch creating a new repository if that would be required
<mgz> `ls -l` the directory that the packfile with the error is in?
<Wiz_KeeD> wait one sec
<Wiz_KeeD> damn you were right
<Wiz_KeeD> i wasn't payiing attention at the path
<Wiz_KeeD> and my user is part of the group that owned it
<Wiz_KeeD> This transport does not update the working tree of: bzr+ssh://wiz@dev.esserio.ro/opt/openerp/bzr_repo/aluart/. See 'bzr help working-trees' for more information.
<Wiz_KeeD> what does this mean?
<mgz> when working with remote branches, the tree doesn't get changed, only branch and repo
<mgz> read doc/en/user-guide/core_concepts.txt docs if you're not sure on those terms
<xnox> Wiz_KeeD: there is a push and update plugin, check bzr documentation
<mgz> xnox: so, you should have jubany access now, poke me at any point if you have questions
<xnox> mgz: yeap =)
<Wiz_KeeD> so is that a bad thing?
<mgz> Wiz_KeeD: not generally, as you don't want a remote tree at all.
<Wiz_KeeD> phew :D
<Wiz_KeeD> it updated the revno, i could pull it so i guess it's ok
<mgz> not pull, just update. it's got the changes, the tree is just not updated.
<LantzR> Hiya. I created a new ppa:  bzr push  lp:~lantzr/+junk/cup-pdf-zel which was ok and working. What I do not understand is why it moved to lp:~Ubuntu-Etherpad/+junk/cup-pdf-zel
<LantzR> I'm new to bzr and launchpad
<thumper> LantzR: there are no branches showing for ~lantzr
<thumper> the only way it would move is if that user (I'm assuming you) moved it
<thumper> or if it was pushed to  lp:~ubuntu-etherpad/+junk/cup-pdf-zel
<thumper> and not the lp:~lantzr location
<LantzR> thumper: yes the user was me and I pasted the above from my bash history. With typo. shouda been cups
<LantzR> jumper: I also was able to branch from ~lantzr on a different computer
<thumper> LantzR: launchpad doesn't move branches by itself
<LantzR> ok thank you.
<thumper> I should have pointed out that if lantzr changed the ownership of the branch the url chagnes
<thumper> I forget sometimes that it isn't necessarily obvious
<mwhudson> " I created a new ppa:  bzr push " shows some level of confusion already
<wolter> I have a branch with committed changes I want to have the branch "forget". To do so, I have pulled the parent branch and reverted, but I still can't get matching revision numbers, what can I do?
<mwhudson> wolter: bzr pull --overwrite :parent?
<thumper> yeah, pull without the --overwrite will just make sure that the revisions from :parent are in the ancestry of the current branch
<thumper> with --overwrite it says "make this branch like that one"
<wolter> thumper, mwhudson thanks!
#bzr 2013-02-13
<vedic1> if ssh is running on port other than 22, then how to use bzr+ssh?
<vedic1> I have created a remote repository by pushing my working tree from local system to remote machine. Then I did bzr checkout on remote machine and it gave me files in the repo. But after udpating files on local system, if I push 2nd time to remote machine, checkout is not working on remote machine. Getting error: bzr: ERROR: A control directory already exists:
<vedic1> bzr update worked. :)
#bzr 2013-02-14
<thomi> stupid question: if I did a 'bzr merge <some_other_branch>' without first committing my local changes, is there a way I can back-out the changes pulled in by the merge?
<thomi> 'bzr revert' will undo all my local changes, which isn't what I want
<thomi> and 'bzr revert --forget-merges' just removes the merge marker, not the changes that came with it
<fullermd> merge wouldn't run in the first place unless you --force'd it.
<thomi> fullermd: sorry, I just worked out, it was a 'merge' and then an 'unshelve'
<fullermd> Ah.  Messy.  I'm not sure you could unwind that too easily...
<fullermd> One possibility might be to try doing the merge over again in reverse, in the hopes that it'll squeeze out the 'merge' changes leaving just the 'unshelve' ones, then you can cleanup and retry from there.
<thomi> fullermd: ok, thanks
<fullermd> Another might be to try shelving the whole pile of changes (including the merge, so you're left with a clean tree).  Then do the merge again, and commit it.
<fullermd> Then unshelve; that might leave the merge bits of it "unchanged" (from the now-committed merge) and include just the bits that were on the shelf before.  Or it might blow up messily; not really sure.
<thomi> heh, ok
<thumper> thomi: I'd also suggest what fullermd said, shelve the changes you want to keep
<bob2> imho unshelve should need --force to restore to modified files
<spiv> bob2: +1
<lifeless> bob2: mmm, not merge in ?
<bob2> lifeless, if you --force it, sure
<bob2> otherwise it more or less can lose data
<lifeless> bob2: mmm, or it could make a backup file.
<bob2> it could
<bob2> silently mashing up my data by default like 'svn up' is unfortunate
<spiv> bob2: yeah, mashups are *so* 2009
<bob2> haha
<Zmanu> hello
<Zmanu> i want to do a bzr up on one file, but when i do it, it update all commit file, what is the way to do it ?
<lifeless> Zmanu: there isn't. bzr works on a full tree at a time for update/pull
<Zmanu> lifeless: ok i see, we need to work with revision to be abble to up only some files instead of all files
<Zmanu> lifeless: thanks for answer
<xnox> can I do "merge-into" remotely to get left-right merge history correct
<xnox> instead of cloning trunk, going into it, and doing bzr merge ../my-current-branch
 * xnox simply wants $ bzr merge-into lp:trunk & bzr push :parent
<fullermd> Not really.
<fullermd> Well, I guess you could conceptually do it be [ab]using the terrifying auto-pivoting that bound branches do on divergence.  But I'm confident that will cause more problems than it solves, based on the nigh-infinite ratio of past experience.
<xnox> =)))))
<thumper> abentley: ping
<thumper> abentley: got a question about reconfigure command
<abentley> thumper: pong
<abentley> Sure.
<thumper> with --lightweight-checkout
<thumper> so... I have this branch in my GOPATH
<thumper> something like juju-core
<thumper> and I'm not overly enamoured with cobzr
<thumper> so I thought I'd use my normal layout and switch
<thumper> so... ~/src/juju-core/trunk is a copy of trunk
<thumper> in my normal layout
<thumper> so my locations.conf is all set up etc
<lifeless> branch or tree or both ?
<thumper> lifeless: my ~/src/juju-core is a shared repo with trees
<thumper> Ideally I'd like to work in a similar way I am with a virtual env I have
<thumper> where I just switch the actual work branch
<thumper> :~/go/src/launchpad.net/juju-core$ bzr reconfigure --lightweight-checkout ~/src/juju-core/trunk/
<thumper> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~thumper/juju-core/trunk/".
<lifeless> so what I have is a treeless repo with N branches and a single working tree 'working' with a lightweight checkout of one of the branches
<abentley> thumper: It sounds like ~/go/src/launchpad.net/juju-core is already a checkout and refers to bzr+ssh://bazaar.launchpad.net/~thumper/juju-core/trunk/ .
<abentley> thumper: what does bzr info say?
<thumper> lifeless: I used to work that way a long time back...
<thumper> lifeless: just got into the habit now have having trees in ~sr
<thumper> c
<thumper> the trees in the repo aren't really an issue AFAICT
<thumper> the parent branch for the existing juju-core branch is:
<thumper> http://bazaar.launchpad.net/~gophers/juju-core/trunk/
<thumper> why did reconfigure fail?
<thumper> abentley: standalone tree
<abentley> thumper: There's no reference to bzr+ssh://bazaar.launchpad.net/~thumper/juju-core/trunk/ in the "bzr info" output?
<thumper> not that one, no
<thumper> however...
<thumper> ah...
<thumper> that is the public branch specified for ~/src/juju-core/trunk
<thumper> using my append path policy
<thumper> the parent branch is  bzr+ssh://bazaar.launchpad.net/+branch/juju-core/
<thumper> why is reconfigure looking at the public branch?
<thumper> but ~/src/juju-core/trunk is a repository tree
<abentley> thumper: It's been a few years since I wrote that.  Can you run reconfigure with -Derror so I can see where it's dying?
<thumper> sure
<thumper> abentley: http://paste.ubuntu.com/1653507/
<thumper> abentley: perhaps I should just specify a public branch for the branch at ~/src/juju-core/trunk ?
<thumper> abentley: but I'm not sure why it is even looking
<abentley> thumper: So, I can delve into why, but by specifying --bind-to will override it, and you probably want that anyway.
<thumper> abentley: ah...
<thumper> didn't notice that
<thumper> now it kinda makes sense...
<thumper> oh...
<thumper> NotBranchError: Not a branch: "/home/tim/go/src/launchpad.net/juju-core/~/src/juju-core/trunk/"
<thumper> abentley: I can fix that one by providing a full path
<thumper> but probably a bug
<abentley> thumper: What was the commandline?
<thumper> bzr reconfigure -Derror --lightweight-checkout --bind-to=~/src/juju-core/trunk/
<mwhudson> yay bash!
<abentley> thumper: ~ interpolation is done by the shell, which I guess wasn't smart enough to expand it in this case.
<mwhudson> uh
<mwhudson> no
<mwhudson> oh yes, that is the problem
<mwhudson> but bash is stranger than i thought:
<abentley> thumper: bzr reconfigure -Derror --lightweight-checkout --bind-to= /src/juju-core/trunk/ should work.
<mwhudson> mwhudson@narsil:highbank-support$ echo a=~/.bazaar
<mwhudson> a=/home/mwhudson/.bazaar
<mwhudson> mwhudson@narsil:highbank-support$ echo a-a=~/.bazaar
<mwhudson> a-a=~/.bazaar
<abentley> Or omit the = even.
<thumper> mwhudson: wat?
<thumper> that seems weird
<abentley> i.e. bzr reconfigure -Derror --lightweight-checkout --bind-to /src/juju-core/trunk/
<abentley> grr, where'd the ~ go?
<mwhudson> thumper: i think it's so that you can write "a=~/foo"
<abentley> bzr reconfigure -Derror --lightweight-checkout --bind-to ~/src/juju-core/trunk/
<mwhudson> thumper: but yes, "wat"
<thumper> abentley: ok, ta
<thumper> now I just have the sync question...
<thumper> in #juju-dev
<thumper> $ bzr switch -b help-command
<thumper> Tree is up to date at revision 894.
<thumper> Switched to branch: /home/tim/src/juju-core/help-command/
<thumper> awesome!
<thumper> I love bzr
<thumper> it's all working lovely jubley
#bzr 2013-02-15
<peitschie_> k1ck@ss
#bzr 2014-02-10
<killermoehre> hi. at $COMPANY, we use bazaar for our internal development. now the problem appeared, that some repository needs over 500 seconds to download, while the cli says: "Inserting stream:Estimate 751/2255" with no progress. AFAIK any other repository runs well. any advice?
<fullermd> What's it doing during that time?  Churning the disk, slamming the network, chewing the CPU?
<killermoehre> fullermd: nothing. it takes it RAM share at the repo server (the checkout is via the ssh transport), but the disk and network is idling
<killermoehre> no cpu usage, too
<killermoehre> fullermd: you could think someone stopped the job (no, nobody does this)
<fullermd> Check both server and client side?
<killermoehre> fullermd: both server and client side
<killermoehre> fullermd: would you mind to prefix posts for me with my username, so I get a higlight? this would be really nice :)
<killermoehre> fullermd: at the server side, the .bzr.log with some debug flags says "Adding the key (<bzrlib.btree_index.BTreeGraphIndex object at 0x22e7f10>, 23942126, 8836427) to an LRUSizeCache failed. value 62761550 is too big to fit in a the cache with size 41943040 52428800", client says "inserting substream: texts", after that both went idling
<fullermd> killermoehre: What, to sort it out from all the other conversations happening here?   :p
<fullermd> killermoehre: I'm pretty sure that's more of a diagnostic message than an error, so probably ignorable.
<fullermd> killermoehre: Still, I have a hard time imagining how both sides could be sitting around doing nothing.  Something's waiting on something.2, and that's either because something.2 is feasting on some resource, something is broken, or things are deadlocked.
<fullermd> If (3), then it'll never get anywhere, and points to a ginormous bug.  I doubt it.  (2) is always possible, but is also ginormous bug I haven't seen.  So I'm guessing (1) is the case somewhere.
<killermoehre> fullermd: I don't see the numbers you're referring ^^
<fullermd> killermoehre: Just the 3 things I mentioned in the prior line.
<killermoehre> fullermd: well, I don't see any kind of resource usage, but maybe you can hint me something. the server is a debian7 with bzr 2.6.0dev2, the clients are very different, but features all the same problem, so I think it's a problem with the server.
<killermoehre> and now I see with a test at the server, that a local checkout hangs, too
<fullermd> top for CPU, iostat for disk, netstat for network.  The more other stuff is being done by the system, of course, the harder to sort out what's happening with bzr itself...
<fullermd> If something's memory constrained, there's always the chance it's falling into swap.  That would completely tank performance, but you'd probably notice the pagein/out activity pretty easily.
<killermoehre> fullermd: yeah, 100% cpu! success, I found something
<killermoehre> and constant growing RAM usage
<killermoehre> or not
<killermoehre> but enough RAM usage
<zyga> killermoehre: what is the version of the repository you are branching from?
<zyga> killermoehre: maybe you can upgrade / pack it?
<killermoehre> to be fair, this is a VM with 476MB RAM
<fullermd> Well, 2000-some texts isn't particularly large, so it's probably not a pure history size filling stuff up.  Big files in the history?
<killermoehre> fullermd: how can I check? I'm only the admin, I don't use bzr very often
<fullermd> That _is_ a bit tight RAMwise by modern standards.  'course, it's enough if it's not paging in and out of swap, but it probably can still kill your page cache etc...
<fullermd> killermoehre: Well, by just knowing what's in the code/whatever is being versioned.  Images, binaries, ISO's, core dumps, etc?
<killermoehre> fullermd: should be just php code
<fullermd> 2000 texts of program source code is tiny, but if it's multi-meg images, that's a whole 'nother matter.
<fullermd> After doing a branch, you should have a repo with a single pack in it.  How big is that pack?
<killermoehre> fullermd: pack?
<fullermd> ll .bzr/repository/packs/
<killermoehre> fullermd: 32MB
<fullermd> OK, even a 2002-era memory size shouldn't have too much trouble with _that_.
<fullermd> So let's look at zyga's first suggestion; format mismatch.  Look at 'info' on the source repo, see what format it says it's in.
<killermoehre> fullermd, zyga: format says 2a
<fullermd> Well, that should be OK, unless you're branching it in _to_ an old format repo, which is pretty unlikely.
<fullermd> (would probably take some conscious effort to squirrel things up)
<killermoehre> fullermd: I don't think so I do this with a new checkout
<fullermd> killermoehre: Well, that's all my particularly good ideas.  It's not a tiny repo, but it's not huge either, so I wouldn't expect massive waits on it putting stuff together.
<fullermd> Of course, VM does mean all kinds of constrained environment, so "all the CPU available for a long time" might not really be all that much in larger terms...
<killermoehre> fullermd: as I said, I don't see anything in vmstat, too
<killermoehre> zyga: do you have another idea?
<zyga> killermoehre: not really
<zyga> killermoehre: try bzr pack on the remote end
<zyga> killermoehre: see if that helps
<fullermd> VM as in virtual machine; the CPU churnings in top.
<zyga> killermoehre: use a shared repo locally to avoid the traffic in the first place
<killermoehre> zyga: well, we have multiple developers and they want to checkout the repo first to have it local ^^
<fullermd> For comparison, here's a local repo I have of a project full of PHP and SQL files, but with a bunch of images thrown in too.  The history is about 37 megs.  pack takes about 30 seconds.
<killermoehre> fullermd: I can't see the cpu utilization if I do a remote checkout
<zyga> killermoehre: doing a checkout or a branch?
<zyga> killermoehre: checkouts are pretty crap IMHO
<killermoehre> zyga: checkout
<killermoehre> funfact: a lightwight checkout runs fast
<zyga> killermoehre: checkouts are horrible, don't use them unless you really have to
<zyga> killermoehre: everything about them is wrong IMHO
<killermoehre> zyga: it's the way the devs work here
<killermoehre> I can't change this
<killermoehre> I'm just the admin
<fullermd> Checkouts are awesome.  Lightweight checkouts, now, of non-local branches, are nutso.
<fullermd> The CPU burning may be on the server side, not the client.
<killermoehre> fullermd: the bzr pack takes 100% cpu at the server
<killermoehre> funny
<zyga> killermoehre: it runs once and then stops
<fullermd> Well, yeah; pack is CPU bound, unless you have _really_ slow disks.
<zyga> killermoehre: recommend your developers not to use checkouts, they probably don't need them and are just used to "svn"
<fullermd> And most VM hosts don't have ESDI controllers, so yours probably aren't that slow   ;p
<fullermd> A heavy checkout ain't gonna be any slower than a branch.
<zyga> fullermd: the point with checkouts is that they are against the spirit of distribution, just do a local branch, use a shared repository to get local, low-cost branching, push branches back, that's the most efficient bzr workflow
<zyga> centralized checkouts are all evil, no way to CI, single point of contention, I cannot understand why people even use that
<killermoehre> zyga: right now the workflow is "checkout â developing â merging with the local checkout â after developing is done, merging with the repo"
<zyga> killermoehre: branch, hack, merge || rebase, push, have CI merge it
<zyga> killermoehre: (push to new branch on the far end)
<fullermd> Pfui.  Checkouts are an _excellent_ mechanism to coordinate work on shared branches.  The only rational alternatives are just manually implementing the checkout workflow, and that's silly.
<zyga> killermoehre: anyway
<zyga> fullermd: I have yet to see a case where a checkout is worth anything over CI gatekeeper
<zyga> fullermd: but perhasps in some specal cases that makes sense
<killermoehre> zyga: CI?
<fullermd> "not being nutso"   :)
<zyga> fullermd: for me checkouts are slow and crappy
<zyga> killermoehre: http://en.wikipedia.org/wiki/Continuous_integration
<killermoehre> zyga: ah, ok
<killermoehre> zyga: I don't think this is appliable right now here
<zyga> killermoehre: well, you have what you have then
<zyga> killermoehre: slow stuff
<killermoehre> fullermd: the pack now hangs at "\ repacking texts:texts 147/650"
<killermoehre> can I see which file this is?
<killermoehre> or what bzr does there?
<fullermd> It's not hung, it's just digesting.
<killermoehre> fullermd: hanging := no visable output of success or computing
<zyga> killermoehre: it's not hang, it's just compressing, wait
<killermoehre> zyga: any way to see what it's compressing?
<killermoehre> hmm â¦ lsof
<fullermd> Won't tell you anything useful.
<killermoehre> right -__
<killermoehre> right -__
<killermoehre> right -_-
<killermoehre> argh!
<fullermd> It's extracting the texts out of the existing packs, and re-compressing them into new.  Maybe verbose logging can tell you text ids, but without a lot of digging that still won't tell you anything too useful.
<killermoehre> fullermd: so this is an internal action and probably the problem can only be solved by throwing more resources at the machine?
<fullermd> Probably.  How long did the pack take?
<killermoehre> fullermd: if I read the ~/.bzr.log right, it took  810 seconds
<killermoehre> well, I have multiple debug flags enabled, so this value could be a little to high for production use
<fullermd> 810 seconds?  For a 36 meg repo?  So 24 times as long as on my workstation here?
<fullermd> I guess it's possible the contents could be pathological somehow.  But yeah, I'd guess the more likely answer is "time to retire that Pentium II".
<killermoehre> fullermd: again, it's a VM. two cores at 3GHz
<killermoehre> brb, coffee wants to come out
<fullermd> Well, pack isn't multithreaded, so 2 cores wouldn't be much different from 1.
<fullermd> But either it's _really_ busy with something else, or that's a 3 GHz single-issue in-order core with no cache, 'cuz I'm only on a not particularly awe-inspiring 3.7.
<fullermd> Or, as above, possibly an ultra-pathological set of contents.  But I'd be pretty surprised at that sort of disparity.
<fullermd> I do love VM's, but the species does generally describe an animal that's oversubscribed to heck and back, and gets really cranky when subjected to much load.  And, absent aforementioned magic, that repo really shouldn't be much load.
<fullermd> A lot of possible pathologies could be come up with to explain things running like molasses, but they're a pretty far reach.  Running out of suds is endemic to the VM world, and accounts for it.
<killermoehre> fullermd: well, the hosting server has 8 cores and 8 GB RAM, summed up the machines uses 10 cores and 7.5 GB RAM.
<zyga> killermoehre: re-do that operation on your $laptop
<zyga> killermoehre: (just before the pack)
<zyga> killermoehre: if you wonder about virtualization impact
<killermoehre> zyga: the "bzr pack" at the checkout I did?
<zyga> killermoehre: not at the checkout
<zyga> killermoehre: you need the original branch, if you still have it
<fullermd> The checkout will do fine.
<fullermd> (assuming it's not a light one, of course.  But that's silly anyway)
<killermoehre> fullermd, zyga: started a bzr pack at my $laptop in the checkout I did. seems to "hang", too
<killermoehre> I will see how long it takes
<killermoehre> still running â¦
<killermoehre> I like how bzr is logging everything
<killermoehre> and still running â¦ six minutes now
<fullermd> That really sounds excessive.  It's got the CPU nailed the whole time?
<killermoehre> fullermd: yes
<killermoehre> fullermd: sorry for the delay. sometimes other work interferes ^^
<fullermd> .bzr.log probably has some info about the counts of things being dealt with.
<fullermd> On my ~37 meg repo here, I've got numbers like
<fullermd> 0.158  repacking 8809 revisions
<fullermd> 3.278  repacking 8809 inventories
<fullermd> 4.600  repacking chk: 8717 id_to_entry roots, 1426 p_id_map roots, 41320 total keys
<fullermd> 14.405  repacking 30226 texts
<fullermd> 29.317  repacking 0 signatures
<fullermd> (and there it's done)
<killermoehre> fullermd: http://sprunge.us/MMMK
<killermoehre> fullermd: I'm killermoehre and /home/killermoehre/tmp/repository/ is the directory where the checkout is
<fullermd> Almost 10 minutes to repack 251 texts?  Crazymuffin.
<fullermd> The cache overflows aren't _good_, but having 3 of 'em in the whole process doesn't seem like it would make a sizable difference.
<killermoehre> fullermd: what are those "texts"?
<fullermd> Versions of files, basically.
<fullermd> So 219 revisions and 251 texts means you're changing roughly 1.15 files per commit.
<killermoehre> fullermd: the devs did
<killermoehre> fullermd: I never touched the source
<fullermd> Of course, OTOH, they're obviously pretty big.  251 texts compressing down to 36 megs means (assuming revs etc take up no space, which to a first approximation they do) means that each text after delta compression is taking up about 143k.  That's hyuge.
<fullermd> Compare my ~37 meg repo with 30k texts, so each is taking up about 1k.
<killermoehre> fullermd: so what do you suggest? delete the history of this repository?
<fullermd> So I suspect there's some significant churn on big files, which usually either means binary or generated stuff (as human-maintained text hardly ever gets THAT big and mobile)
<fullermd> Well, that would hack around the issue, certainly.
<fullermd> I don't s'pose it's a sharable repo.
<killermoehre> fullermd: sharable repo?
<fullermd> As in you can give somebody else access to it.
<killermoehre> fullermd: no. it have to stay in-company
 * fullermd nods.
<killermoehre> I would be killed (at least fired) if I would give access to it for extern
<fullermd> Hey, you gotta sacrifice sometimes   ;p
<killermoehre> fullermd: with a whole checkout I can go back to any previous revision, right?
<fullermd> At any rate, that sorta size sounds a couple sigma off the norm, but I'm still a bit surprised it's that slow.
<fullermd> Even accounting for my workstation, while not all that screamingly fast, being almost certainly significantly gruntier than your laptop, a factor of 20 difference seems well outside the lines.
<fullermd> (how's that for tortured sentence construction?)
<fullermd> Yes, you can.
<killermoehre> fullermd: (I'm german. we invented tortured sentence constructions ;) )
<killermoehre> fullermd: how can access previous revisions?
<fullermd> Depending on particulars, usually via update or revert.
<fullermd> update being more for things like "shuffle my whole WT over to this revision for experimentation", revert more for "slam this file back to the state of that rev for committing a backout"
<fullermd> (as a first approximation; endless details and special cases of course)
<killermoehre> fullermd: well, I want to find out, which file is why causing this behavior
<fullermd> How big is the existing working tree?
<killermoehre> fullermd: I can't tell the devs "you fucked this up, live with it"
<fullermd> (a quick mental 'du .' - 'du .bzr' will give you a working approximation)
<killermoehre> fullermd: 252kB
<fullermd> Basically, there are 2 possible extremes.  One is that it's a bunch of big files and/or massive changes in each commit.  In that case, well, there's nothing much you can do, it's just how your project goes.
<killermoehre> fullermd: echo $(($(du -s . | awk '{print $1}') - $(du -s .bzr | awk '{print $1}')))
<fullermd> The other is that somewhere back in history, somebody accidentally committed a giant .iso or .core or the like, and then later noticed and removed it because it shouldn't have been there.  In that case, you can in concept rewrite the history without it, and get rid of the deadweight.
<killermoehre> fullermd: any easy way to find the biggest file in bzr history?
<fullermd> Well, that's not huge.
<fullermd> Not directly.  You could try pulling up a 'bzr log -v' then looking through it for 'removed' lines and seeing if any of the files that have been removed look suspicious.
<fullermd> It sounds like the latter, really.  252k of size, if it were completely changed every one of the 219 revs, would total up to 55 megs before compression, which is only twice the size of your fully compressed repo.
<fullermd> So there's probably some big stuff piled up in the history.
<killermoehre> fullermd: seems like in the first revision some sql dumps were added, which were removed in the second revision
<fullermd> Sounds like a likely culprit.  A "bzr diff -c1 | diffstat" could confirm it.
<fullermd> (giving you a quick eyeball of the size of the files)
<killermoehre> fullermd: 45 files changed, 7351 insertions(+)
<killermoehre> fullermd: at -c2, I got "41 files changed, 1 insertion(+), 6731 deletions(-)"
<fullermd> And SQL dumps often have ultra long lines, so those ~7000 lines can mean a _lot_ of data.
<fullermd> Yep, I'd call that a safe bet for the bloatsource.
<fullermd> Getting rid of it would mean redoing the history without those files.  That means everyone's branch/checkouts would need redoing, and anybody's outstanding work in unmerged branches would have to be rebased on top of the redone history.
<fullermd> Which may be anything from "trivial" to "fiendishly involved", depending on your particular workflows etc.
<killermoehre> hrmpf
<fullermd> Doing it will probably involved some invocation of something in the rewrite plugin, possibly on top of a little manual setup.  But that gets deep into details; I don't have a recipe offhand, so it would probably take some experimentation.
<killermoehre> fullermd: well, experimentation would be â¦ bad
<fullermd> Well, obviously you'd make a scratch branch for the experimentation.  It would be _bad_, just potentially time-consuming.
<killermoehre> fullermd: so I have to say the devs "a other dev not working here anymore screwed off. you're out of luck". i CAN LIVE WITH THT
<killermoehre> sorry for the caps
<fullermd> That's why god made devs-who-left-the-company   ;)
<killermoehre> fullermd: at least it's not my or the machine fault
<killermoehre> fullermd: thank you very much for your time and help and the insight into bzr. should you ever need help with xfce, don't hestiate to ask in #xfce :D
<fullermd> np   :)
<fullermd> Though I'm afraid ctwm would be terribly disappointed in me if I left it for some newfangled upstart wm   ;>
<fullermd> vila: Hey, you won First Commit Of 2014.  Does that come with a trophy, or just a little brass nameplate?  ;)
<vila> fullermd: hehe, no nothing, pure glory ;) (And even there...)
<fullermd> Not even a cake?  Jeez, what a buzzkill.
#bzr 2014-02-11
<leonardo1> Hi guys. Can you help me? http://stackoverflow.com/questions/21698362/bazaar-error-cannot-commit-to-branch-branch1-it-is-bound-to-branch2-whic
<zyga> leonardo1: try unbinding your branch first
<zyga> leonardo1: I'm not quite sure what you did to get that error (bzr commit or bzr switch?)
<zyga> leonardo1: remember that bound branches are _branches_ not _checkouts_
<zyga> leonardo1: so it needs to commit to the bound branch before committing to the local branch
<zyga> leonardo1: I have never tried double bound branches before
<leonardo1> zyga: I did try by unbinding the 2 branch (the local trunk checkout) and commit in the checkout of the local trunk. The commit works, goes to the local trunk, but when I try to rebind the local trunk it doesn't commit the new revision and if I try to force it with bzr commit it says that the local trunk is out of date and I need top update (even though the remote trunk is actually out of date)
<zyga> leonardo1: ok, try pushing that to both branches
<zyga> leonardo1: so that you are back in consistent state
<zyga> leonardo1: then try binding to the 1st remote and doing a test commit (feel free to do it on a seprarate repository)
<zyga> leonardo1: so that you don't commit junk to your tree
<zyga> leonardo1: remember that even with bound branches you can do --local commits
<zyga> leonardo1: and that can probably confuse the system (just guessing)
<bob2> you may be happier just not using bound branches
<superfly> I have a problem with some tags which someone accidentally added to our repository on Launchpad, and now I can't seem to get rid of them. Does anyone know how I can, once and for all, remove a tag in such a way that it cannot be added again?
<jelmer> superfly: you can't - tags are not versioned so a pull or merge can bring them back again
<jelmer> superfly: you can remove them from the launchpad repo though
<superfly> jelmer: I have the repo checked out from LP, so I did a bzr tag "..." --delete which removes it, but then someone does some work, and we get it back again :-(
<superfly> I'll try to see if I can get everyone to make a concerted effort to delete the tags
<jelmer> superfly: that ds the onry way to deal with it at the moment :(
 * superfly sends a mail out to the developer mailing list
<superfly> thanks jelmer
<smw> hi all, I am stuck in lock hell. Anyone know how to fix it? Removing the entire folder didn't seem to work ERROR: Cannot lock LockDir(file:///path/to/repo/.bzr/branch-lock): lock was renamed into place, but now is missing!
<smw> I am getting this error when I try to bzr clone
<smw> I did my best. I gave up. It was a vagrant box so I am remaking it
<smw> there is something horribly wrong here
#bzr 2014-02-12
<rozzin> Mm. There's an advertisement for git tutorial on that stackoverflow page.
<rozzin> I think I tried the `nested branch-binding' thing at some point, and found that it indeed didn't work.
<jelmer> mutt
<SDGathman> bzr hangs when I try to commit my changes.  bzr-2.1.1
<jelmer> SDGathman: please try a new version
<SDGathman> jelmer: I have 2.5.1 on Fedora.
<SDGathman> jelmer: I am working with 2.5.1, and I checked out a repo on CentOS with 2.1.1
<SDGathman> The .bzr directory seems to have all the code on my Fedora "client".
<SDGathman> Can I just break the link to the repo I checked out from?
<SDGathman> Also, when I do the commit, it is 2.5.1, and it doesn't run the 2.1.1 bzr that I can see.  It seems to just use sftp.  Is there a better kind of url to use for a shared repo?
<SDGathman> Both nodes pass "bzr check" and say "Branch format 7"
<jelmer> SDGathman: yes, you can break the link to the branch you checked out from
<jelmer> SDGathman: "bzr unbind"
<jelmer> SDGathman: bzr+ssh is much faster than sftp, but you'll need to have bzr installed on the remote server
<SDGathman> jelmer: reading about bind/unbind, maybe I can just change the url and see if 2.1.1 works on the server with bzr+ssh.
<SDGathman> Thanks for the pointers, BTW.
<SDGathman> I do like the idea that if the server implodes, I still have a complete copy locally - that is why I am working on switching to bzr (from CVS).
<DylanC> Anyone free to help a man out of misery? :S
<DylanC> Please
<SDGathman> I'm a bzr beginner, but just ask your question.
<DylanC> Well I do like Bazaar but I HATE setting it up. Its always pain
<DylanC> So I have set it up again on the same machine but a new ubuntu install
<fullermd> I sorta specialize in going the other way, but...
<SDGathman> jelmer: So if the central repo is down, I can just unbind and continue committing locally?  Then bind again and push when the server is up again?
<DylanC> So I had to create a new gpg key
<DylanC> a new ssh key
<DylanC> and register both on Launchpad.net
<DylanC> but when I go to do anything in Bazaar it gives me message saying ssh not registered
<SDGathman> DylanC: You could alway use your old ssh key.
<DylanC> :S
<DylanC> Old one is removed at this stage unfortunately
<DylanC> Damn
<DylanC> Well I have the old one I think on an old hard drive
<DylanC> I might try reverting
<SDGathman> DylanC: I always use LVM, and allocate a new LV for each OS install.
<fullermd> Well, you'd generally have a different ssh keypair for each system anyway.
<fullermd> PGP would generally be more universal.  Though I've never used it with bzr anyway.
<DylanC> My old ssh no longer works :/
<DylanC> Why does this always make me want to run into walls honestly
<DylanC> So frustrating
<fullermd> I'm a little surprised that you'd be pushing to LP from so many systems that ssh key manglement is a notable task.
<DylanC> Launchpad user 'dylan' doesn't have a registered SSH key Permission denied (publickey). ConnectionReset reading response for 'BzrDir.open_2.1', retrying Launchpad user 'dylan' doesn't have a registered SSH key Permission denied (publickey). bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<DylanC> That is the error ^
<DylanC> When it says Launchpad user "dylan" where does it get it from? Shouldn't it be my Launchpad iD perhaps?
<fullermd> I presume it _is_.
<DylanC> Can this be changed locally somewhere or with a command?
<fullermd> lp-login
<DylanC> huh?
<DylanC> If you are talking about changing it on the web. Its not editable.
<fullermd> That's the command.
<DylanC> command not found
<DylanC> :S
<fullermd> bzr lp-login   :p
<DylanC> xD
<DylanC> Oh right
<DylanC> This might be the problem x)
<DylanC> "No Launchpad user ID configured."
<fullermd> That would tend to compromise the effectiveness of things   :p
<DylanC> LOL
<DylanC> Yes
<DylanC> Right added that, lets try again. *crossed fingers and toes*
<DylanC> All sorted omg woot! xD
<DylanC> Thanks guys!
<fullermd> Using lp-login before using lp is a helpful thing indeed  ;p
<DylanC> Seriously this made my day!
<DylanC> I will remember that next time!
<fullermd> Awesome.
<DylanC> ^_^
<fullermd> That means I can go kick kittens the rest of the day, and my karma will still balance out!
<DylanC> ahaha
<DylanC> I should probably celebrate this with a beer ;P
<DylanC> (any excuse) :D
<DylanC> This was much better than Ubuntu Forums in which my thread got no response x)
<fullermd> Oh, well, they're full of people using Ubuntu; what do THEY know?
<DylanC> How to push the Windows key! :D
<DylanC> Just kidding though, can't joke since im using Unity myself. x)
<DylanC> Gotta go but thx again for being helpful guys
#bzr 2014-02-13
<mattyw> is anyone able to help me debug a problem with the colocated branches plugin? It has suddenly started saying I don't have any colocated branches after I did a bzr switch
#bzr 2015-02-14
<JohnRL> anyone able to use bzr to checkout from launchpad?  haven't been able to for a full day, can't figure out why not.
<fullermd_> I can talk to it via my existing checkouts OK...
<fullermd_> Oh, you're gone.  Nevermind.
#bzr 2015-02-15
<mr_george> I would like to review a log of an old files, ideally with qlog, but the file was deleted several revisions ago, and the containing dir has since been renamed. I am having a hard time figuring out how to reference it, eg. bzr qlog dir/old-path.rb results in "bzr: ERROR: Path unknown at end or start of revision range". Does anyone know how to do this?
<fullermd_> Do an 'update' to bring your WT to a rev where it exists, then you can log it.
<jelmer> mr_george: what fullermd said
<jelmer> mr_george: alternatively, "bzr help log" has some details on referencing deleted files. that might apply to "bzr qlog" too
<fullermd_> What the...   I answered something faster than jelmer?  Are...   are you sick?
<mr_george> fullermd_: jelmer: thanks, I also finally paid closer attention to the error message, and realized that if I specified a revision span that either starts or ends with the file still existing, it will give me useful info.
<mr_george> btw, is there some easier way to find such a spot? I just took a wild guess at a revno when it still existed, and did bzr log -r$GUESS..-1 and found my endpoint that way and then did bzr qlog -r1..$NEW ENDPOINT, but is there a better way if I couldn't provide the initial $GUESS as easily?
<mr_george> $NEW_ENDPOINT there is the revision where the file was deleted.
<fullermd_> Not that I know of.  I've always just done a 'log -v' and then searched it for the file being deleted.
#bzr 2016-02-15
 * fullermd stabbies bug 1072513
<ubot5`> bug 1072513 in Bazaar "log can show too few revs" [High,Confirmed] https://launchpad.net/bugs/1072513
#bzr 2016-02-16
<quicksilver> can you run bzr cat on a remote repo?
<LeoNerd> I would imagine so
<josharenson> Anyone have bzr-rewrite working on ubuntu xenial? Its not in the archive, and when I install from source, bzr doesn't recognize the plugin.
<rwilbur> @josharenson:  Are you using bzr-2.7.0?  If so, try changing bzr-rewrite/info.py:bzr_compatible_versions to include (2, 7, 0) and see if that helps.
<josharenson> rwilbur: I'm using 2.7.11, will 2,7,0 still work?
<josharenson> nm, I see
<rwilbur> josharenson:  I'm guessing you're using Python 2.7.11 which should support bzr 2.7.0 just fine.  bzr-rewrite is more worried about the bzr version (2, 7, 0), in this case.
<josharenson> rwilbur: yeah I saw that :-p I added 2,7,0 and rebuild/installed but bzr plugins still doesn't show it
<josharenson> rwilbur: oh  I got it working.. had to rename the directory so bzr would like it
<rwilbur> josharenson:  Good job!  I've found that bzr prefers plugins to have underscores instead of dashes in the directory name.  Another option would be to make a symbolic link using underscores.
<josharenson> rwilbur: :-) noted. thanks
<vila> rwilbur, josharenson: plugins are loaded in the python namespace bzrlib.plugins.<plugin_name>, the directories have to be valid python identifiers
<josharenson> vila: makes sense... its just interesting that the launchpad url for the plugin is broken out of the box
<vila> Or you need to use BZR_PLUGINS_AT=<plugin_name>@<plugin_directory> to assist
<vila> josharenson: histerical raisins :-/
<rwilbur> vila:  Thanks for that explanation.  Now it makes a lot more sense.
<josharenson> vila: yeah, bummer that can't be changed
<rwilbur> I didn't know about BZR_PLUGINS_AT.  Is that in the configuration file?
<vila> rwilbur: sorry, environment variable
<vila> bzr help env-variables
<vila> BZR_PLUGINS_AT      Plugins to load from a directory not in BZR_PLUGIN_PATH.
<vila> hmpf, a bit short to understand how it can help here :-/
<rwilbur> vila:  Yeah, I like your explanation better than the bzr help;>)
<vila> http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/configuration-help.html#bzr-plugins-at is lisghtly better
<vila> *slightly (probably a freudian slip for lightly ;)
<vila> josharenson: the lp url is not broken, the project name can't avoid prefixing with bzr- (think bzr-svn for svn), so it's a friction between bzr and launchpad. One idea that was discussed in the past was to find some way to configure (instead of inherit) the local branch name from the remote branch name. But it's an edge case. Every plugin hacker runs into it, understand the issue and... swallow it. That leaves little work force to fix it ;-)
<josharenson> vila: :-) gotcha
#bzr 2016-02-17
<quicksilver> how do I pick a version of a file and record that?
<quicksilver> if I bzr revert -r123 file.txt
<quicksilver> I belive it will rever the text contents of file.txt to the text contents as of revision 123
<quicksilver> but it won't reset the rev-id of that file to the revision called 123
<quicksilver> does that even make sense
<fullermd> What "the rev-id of that file"?  Files don't have revisions, revisions have files.
<quicksilver> fullermd: when I do a later merge into another branch
<quicksilver> fullermd: I want it to think "this file is current as of rev-id X, so there is nothing to do"
<quicksilver> fullermd: and I want it to use X as the basis for the diff it will build when merging
<quicksilver> does that make sense?
<fullermd> As in forgetting the history and all the changes to it since then?
<quicksilver> effectively yes
<fullermd> No such thing.
<quicksilver> I can make my situation more concrete if you like
<fullermd> You'd have to recreate the whole history from that point.
<quicksilver> file is in a good state in rev-id A, say
<quicksilver> in rev-id B it received massive formatting only changes
<quicksilver> in one particular branch, in rev-id C, those formatting changes were accidentally undone
<quicksilver> so rev-id C is textually identically to rev-id A
<quicksilver> now all the other active branches have the file correctly formatted (B)
<quicksilver> if I simply correctly format and commit I believe I will generate a new revision (D)
<quicksilver> which might 'look like' B
<quicksilver> but because it has more history, it will conflict with branches from branch point B
<quicksilver> if they ever make changes to affected lines (which is lots of them)
<quicksilver> fullermd: does that sound like it makes sense?
<fullermd> Not necessarily; 3 way merge should ignore all the stuff in the middle and just look at the LCA and end products.  Weave merge would probably blow beets on it, to be sure...
 * quicksilver googles LCA
<quicksilver> common ancestor?
<fullermd> But you're essentially talking about changing the contents of a file in a revision [multiple, but same difference].  You can't do that without changing (i.e., replacing) the revision, and you can't do that without replacing all the revisions that follow.
<fullermd> So the only feasible way would be recreating some amount of branch history to eradicate the traces of such things.
<fullermd> Latest Common Ancestor
<quicksilver> nod
<quicksilver> I know how to recreate the history, done it before for worse issues than this one
<quicksilver> I'll try the text revert and see if I get conflicts!
<fullermd> If you're needing to dispose of 2 revs from earlier today that aren't published, that's trivial; if it's 500 revs from the last 6 months that are all over the world...
<quicksilver> or even if they're just all over 30 branches in this office it's still a pain :P
<fullermd> Quite.  The pain goes all nonlinear as soon as there's more than one copy...
<quicksilver> thanks
<fmccann> Hey bzr folks, Iâm trying to configure bzr to use vim for resolving conflicts. Is this possible? Iâm tring to config either bzr.mergetool or external_merge for the extmerge plugin and Iâm not getting anywhere :D
#bzr 2017-02-18
<alkisg> Hi, can fast-import directly import from remote git to local bzr, or do I first need to clone the remote git branch locally?
#bzr 2018-02-12
<LeoNerd> That thing that `bzr merge` can do on conflicts, where it outputs .orig and .rej pair files, so you can inspect content in either case and fix it up yourself... Does anyone know what that's called, and how I can get git to do the same?
<fullermd> "acting sensibly", and "hahahaharight"?    :)
<fullermd> Looks like there's a mergetool.writeToTemp config var that's probably applicable.
#bzr 2018-02-17
<gour> morning
<gour> i see that brz-git is merged into brz, does it mean there is no need for brz-git plugin?
<jelmer> gour_: Hmm, it's not merged into brz
<jelmer> gour_: where did you see that?
<gour_> jelmer: https://bazaar.launchpad.net/~jelmer/brz/bundle-git/revision/6665
<jelmer> gour: sure, there's a branch I maintain that has brz-git merged into brz, but that's not trunk
<gour> jelmer: i see...still, i fetched brz-git and i get: "brz: ERROR: No module named git.mapping"
<gour> do i maybe need dulwich's trunk?
<jelmer> you will need dulwich trunk, but I think it's unrelated to that error
<gour> i've 0.18.6
<jelmer> gour: this is running what exactly, and what's the full backtrace?
<gour> jelmer: https://pastebin.com/FyDxS9Js
<jelmer> gour: oh, I see what it is now
<jelmer> gour: the plugin's name should be 'git', not 'brz_git'
<gour> jelmer: that helps, but now complains about the repo: https://pastebin.com/qmyy33fy
<jelmer> gour: that's not a valid URL, you'd want something like git://github.com/restic/restic.git
<gour> jelmer: now i get this: https://pastebin.com/UZv07TrN
<jelmer> gour: hmm, I can't reproduce that
<jelmer> but I am getting errors because one of the directories in the repo has non-utf8 characters in it
<jelmer> gour: yeah, the error you're seeing is likely due to an old dulwich
<jelmer> gour: the problematic filename is test latin1 umlï¿½ï¿½tï¿½nï¿½nll
<jelmer> gour: fetching from git -> git seems to work, from git -> bzr fails on that problematic filename
<gour> jelmer: ok, will try with the new dulwich
#bzr 2018-02-18
<gour> morning
<gour> jelmer: i've installed dulwich from the trunk, but with every git repo i try, git --> brz fails with: brz: ERROR: ValueError: too many values to unpack (see e.g. https://pastebin.com/z9RXgPs9)
<jelmer> gour: you also need an update to brz-git
<gour> jelmer: i've r1757 installed?
<gour> ahh, r1759 does work, it seems
<gour> jelmer: nope, another error: https://pastebin.com/4BCZxPSS
<jelmer> ah, that one I have a fix for
<jelmer> gour: pushed a fix to lp:brz-git
<jelmer> (sorry, already had that locally but never pushed)
<gour> jelmer: what about this one: https://pastebin.com/8Pr5vznd
<jelmer> ah, right - yes, I have a fix for that to brz that hasn't landed yet
<jelmer> gour: lp:~jelmer/brz/fix-import-stacked
<jelmer> ... and that should be it
<gour> jelmer: thanks a lot, now it worked!
<jelmer> \o/
<gour> even pull from restic worked ;)
<gour> any raw estimation when brz-3.0 might be released?
<jelmer> gour: no idea, it's basically just me and mgz hacking on it at the moment
<jelmer> we're down to ~300 out of 1800 brz-git tests failing
<jelmer> and to ~9000 tests (out of 25000) passing with python3
<jelmer> gour_: did you see my last three lines?
<gour_> jelmer: yes, i did
#bzr 2020-02-11
<DalekSec> jelmer: Hrm, so a while back I was talking about fastimport, bzr (with patches) vs brz.  I just had to convert a repo and ended up with unexpected results with brz, so tried Ubuntu's version of bzr-fastimport instead and got expected results.  So it looks like that merge request is still missing after all.
<jelmer> DalekSec: which version of breezy?
<DalekSec> Hrm, you're right.  3.0.1-6 looks a bit dated.
<DalekSec> I did it on a Debian testing box.
<DalekSec> Jumped to experimental, got traceback.  Going with unstable.
<DalekSec> 3.0.2-4 still has unexpected results, jelmer.
<DalekSec> https://bazaar.launchpad.net/~brz/brz/trunk/revision/7465 likely fixes it.
<jelmer> DalekSec: can you remind me what the original bug was?
<jelmer> That revision should just be improving performance for fastexport, it wasn't intended to fix any bugs..
<DalekSec> jelmer: There was also a "NameError: name 'kind' is not defined" in the version that is in experimental.  Right, so the 3 bugs are referenced in https://code.launchpad.net/~unit193/bzr-fastimport/deletion-fixes/+merge/258178, I'm working on lp:xubuntu-website.
<jelmer> ah :-/
<jelmer> this should make its way into 3.1.0, if that helps
<DalekSec> I just used wget on exporter.py from the bzr repo (is it still technically a bzr repo?) and tried that version, no traceback but still have the zombie files.
<jelmer> mixing files from different versions is a recipe for disaster; if you can reproduce this with lp:brz I can try to help
<DalekSec> Heh, yeah.  Figured it'd be worth a shot though.
<DalekSec> (I'll have to get to updating the package snapshot another time.)
#bzr 2020-02-15
<LeoNerd> Where did  bzr rebase  end up?
<jelmer> LeoNerd: rebase has been merged into Breezy core as of 3.1
#bzr 2020-02-16
<jelmer> LeoNerd: is there an upstream repository for e.g. https://metacpan.org/pod/List::UtilsBy ?
<LeoNerd> There's my bzr repo.. I don't tend to really publish it as such, or people might actually rely on it
<LeoNerd> But it's on public http(s) if people happen to be curious
<LeoNerd> Whyso?
<jelmer> LeoNerd: just curious - trying to find matching upstream repositories for a number of packages in Debian
<LeoNerd> Ah hmm
<LeoNerd> Unsure then what you might want to do... I guess it partly depends what users think those are for
<jelmer> they're mostly meant for package maintainers - https://wiki.debian.org/UpstreamMetadata
<LeoNerd> Could you use the CPAN location of it..?
<LeoNerd> As that's the sort of official "upstream"
<LeoNerd> jelmer: aww, debian only has breezy 3.0.2.. so no rebase for me
<LeoNerd> but it's OK; I'm only one commit ahead. I'll do the "uncommit; shelve; pull; unshelve; commit" dance
<jelmer> LeoNerd: I'm planning to push for 3.1.0 soonish, once nested trees and rename tracking work
<LeoNerd> ð
