#bzr 2007-11-19
<lifeless> what do CVS users do? their version ids are N-length - e.g. 1.1.1.1.1.1.1.1.1
<lifeless> this can't be a new challenge
<pattern> "For the purposes of this module, a version "number" is a sequence of positive integer values separated by one or more decimal points and optionally a single underscore."   http://search.cpan.org/~jpeacock/version-0.74/lib/version.pod
<pattern> however, the standard is to just have three digits, separated by decimal points
<lifeless> heh
<lifeless> you could just do MAJOR.revno
<lifeless> for use case 1).
<pattern> but i'm not going to want to release a new minor version every time i do a commit
<lifeless> so
<pattern> and skipping minor version numbers might be confusing for users
<lifeless> you were talking about tagging every commit
<lifeless> this would have had the same behaviour
<pattern> yes, but they'd be tagged with X.Y.revno
<lifeless> A branch might be a better way to tackle this.
<pattern> not with X.revno
<lifeless> if you have two branches
<lifeless> one branch, call it 'releases'
<lifeless> every commit there is a release you are doing.
<lifeless> another branch, your trunk or mainline
<lifeless> every commit there is just a commit
<pattern> hmm
<lifeless> then, to do a release, merge to the release branch and commit
<pattern> i actually haven't worked with multiple branches of a single project in bazaar
<lifeless> X.Y.revno in the release branch will go up slowly
<pattern> so i'm not sure i understand how this would work exactly
<lifeless> or even X.revno
<lifeless> well, have a play
<lifeless> make a scratch project, follow the tutorials
<lifeless> get a feel for it
<pattern> ok
<pattern> thanks for your help, lifeless
<lifeless> np
<pattern> what you're describing might be something like what's on this page...  https://www.fmios.org/wiki/Discussions/BzrLayout
<pattern> under the "Package Versioning" section near the bottom of the page
<pattern> "The hope is that future development for each package will follow a milestone path, where milestones are set for a specific release, and when the milestones have been achieved in dev, the branch will then be copied off to the release version for that package. At that point the package is considered released and no further enhancements will be allowed to the release branch, only bug fixes. Enhancements and such will be allowed to continue in the dev branc
<pattern> h of the package."
<pattern> so, would i do something like this?  "mkdir myproject/dev ; cd myproject/dev ; bzr init ; vi my_perl_module ; bzr add my_perl_module ; bzr commit" etc... and work in "myproject/dev" and then when i have a build ready for release do "cd myproject ; bzr branch dev 1.0" to create a copy of the dev branch?
<pattern> or i guess that's what that fmios.org page is suggesting
<pattern> you seem to be suggesting doing "cd myproject ; bzr branch myproject releases ; cd releases ; bzr commit"
<pattern> i'm not sure what advantage either of these approaches gives over simply tagging revisions with "X.Y.revno"
<pattern> that seems much more efficient... why have these superfluous copies of the main development branch sitting around when all the important information in the copies would already be in the main development branch to begin with?
<lifeless> well
<lifeless> they are not superfluous; and a shared repo means you don't have copies either
<pattern> when the files are checked out, isn't the information copied?
<lifeless> depends
<pattern> i guess i could delete the files after the release, but then that would defeat the purpose of having a separate release branch
<lifeless> what info you mean. your working files yes.
<pattern> yes, the working files
<lifeless> the historical data base - optionally no. See bzr help init-repo.
<lifeless> and you could use zap-tree to remote teh release tree temporarily.
<lifeless> still, if you haven't actually sat down and simulated with a trial project, I urge you to do so
<pattern> well, i did just try it
<lifeless> things become much clearer when you have actually worked with 'bzr merge' and multiple branches etc
<pattern> with very basic files
<pattern> i haven't tried merging them
<pattern> but if i'm only going to be using a separate branch for release purposes, i shouldn't need to merge branches
<pattern> and i'm still not sure what advantage i'd get from having a separate release branch
<pattern> over and above what i'd get from simply tagging the development branch with a version number
<lifeless> I think you just need to choose something and run with it
<lifeless> if it turns out not to work, change your mind
<pattern> good idea
<lifeless> the only thing you should do right now is to make sure that you will be able to change your mind without too much trouble
<lifeless> e.g. by how you allocate x.y and z.
<pattern> yep.. that makes sense
<pattern> thanks again, lifeless
 * ig1 food
<AfC> I've been noticing `bzr serve` instances staying in CLOSE_WAIT a long time.
<ig1> abentley:ping
<abentley> ?
<ig1> let's try that again - ping abentley
<ig1> hi
<abentley> Hi.
<ig1> re switch ...
<ig1> looking at cmd_update ...
<ig1> is it appropriate to refactor most of that into a module ...
<ig1> that switch uses instead of its own update function?
<abentley> I don't know.
<ig1> in particular, jameinel had some feedback re pending merges ...
<ig1> that seem to be better thought though in cmd_update
<abentley> I've advocated that there should be no "switch" command.  Update should just take a branch, like it already takes a revision.
<ig1> also, I'm thinking about future -r support for update
<ig1> interesting
<abentley> Okay, maybe it doesn't already.
<abentley> But people think it's counterintuitive.
<ig1> conceptually, I've always thought of switch as bind+update
<abentley> OTOH, update has some pretty weird behavior, if the working tree is out of date with the branch, and the branch is out-of-date with the master branch.
<ig1> but there is next to no code from bind or update used in switch currently
<abentley> Switch isn't bind at all.
<abentley> So that part makes sense.
<abentley> The implementation of bzrtools.switch.switch and bzrtools.switch._update is reasonably short, but if we can get more code reuse, that's usually a good thing.
<ig1> ok, so bind sets the master branch attribute ...
<ig1> which switch ties a tree to a branch, yes?
<ig1> s/which/while/
<abentley> Right.
<ig1> any thoughts on pending merge handling?
<abentley> I don't remember John's comments.
<ig1> is it ok for switch to fail and tell the user to revert pending merges before switching?
<ig1> or commit of course
<ig1> i.e. tell them to commit or revert
<abentley> Yes, I think that would be fine.
<ig1> thanks
<poolie> hello ig1, abentley
<ig1> hi poolie
<ubotu> New bug: #72227 in bzr "bzr fails when run within certain Python code trees" [Medium,In progress] https://launchpad.net/bugs/72227
<lifeless> I's back
<beuno> mornin' lifeless
 * ig1 food
<vila> pattern: regarding perl modules version numbers, notice that 'version' itself has always used X.Y revions numbers (as most of packages on CPAN do)
<vila> then, if you  use MakeMaker, there is a dist target in the makefile, use it to define your version when you produce a new release (Module::Build certainly provides the same target)
<vila> finally if you look at various packages you will see that the revisions are not always consecutive so using X.<bzr revno> will be perfectly acceptable and understood by users
<pattern> vila, when you say "'version' itself", what are you referring to?
<pattern> the version module?
<vila> the 'version' package which is now part of perl itself
<pattern> ah
<vila> http://search.cpan.org/~jpeacock/version-0.74/
<pattern> yes, it uses an X.Y version string
<pattern> some modules use X.Y and others X.Y.Z
<vila> so X.Y.Z is *not* mandatory
<pattern> that's true
<pattern> but the point is that it's not just a single integer version string
<pattern> it's either X.Y or X.Y.Z
<pattern> but bazaar only provides a single integer
<pattern> so i have to create at least X.Y myself
<vila> as long as you provides monotonically increasing numbers you'll be fine
<vila> you can use 0.<bzr revno>
<pattern> well, nothing will break if i do that
<vila> that's the point
<pattern> but it might be a bit confusing for the users when i jump from 0.23 to 0.198
<vila> kiss principle
<vila> hmmm, you'll have to check that but if you add you own code to create the release (dist target in makefiles) you can address that
<pattern> it's not just a matter of having the dist target being numbered correctly
<vila> and most package writers handle their release numbers manually anyway
<pattern> an internal version number for the perl module itself is also necessary
<pattern> so that module users can check and request particular versions of my module
<pattern> so that version number needs to go in to the perl module itself
<pattern> i'm probably going to do that using a templating system (probably Template Toolkit)
<pattern> so i'll just have "$VERSION = [% VERSION %]" in the perl module, and in Makefile.PL i'll run some command to fetch the version number from bzr and substitute it in to the perl module
<vila> fine
<pattern> so the development will be on mymodule.pm.in and Makefile.PL will turn that in to mymodule.pm
<pattern> and only mymodule.pm.in will be versioned
<vila> you may also look at creating your own template for bzr version-info
<pattern> i don't understand
<pattern> what kind of template?
<pitti> hi
<pitti> first, congrats for knitpacks! I just did some experiments, and it cut down the initial push time from 80 seconds to 46
<pitti> but I have troubles with pushing some additional revisions
<pitti> bzr: ERROR: Could not understand response from smart server: ('error', "<bound method KnitPackRepository.leave_lock_in_place of KnitPackRepository('chroot--1218286772:///tmp/pack800/.bzr/repository/')>")
<pitti> (both sides are running bzr 0.92.0 final)
<pitti> is this known?
<vila> pattern: look at bzrlib/cmd_version_info.py
<lifeless> pitti: check the packs tag on malone :_
<pitti> ah, good hint; seems to be https://bugs.edge.launchpad.net/bzr/+bug/156546
<ubotu> Launchpad bug 156546 in bzr "unable to push to packs-based smart server" [High,Triaged]
<pattern> vila, ah, you mean some kind of script that will interface with bazaar to get the version information i want to use in my perl module?
<vila> yes
<pattern> unfortunately, i don't know python
<pattern> does bazaar have a perl interface?
<vila> not yet :)
<pattern> i mean to learn python someday
<vila> try bzr version-info --format=python
<vila> pattern: python has good surprises for you coming from perl :)
<lifeless> or write a perl formatter :)
<pattern> yep :)
<bignose> How do I undo a 'bzr pull'?
<bignose> I mistakenly pulled from foo to bar, and now I want bar to go back to its revision level before the pull
<bignose> similar to 'bzr uncommit'
<fullermd> If you know what revision used to be the head, you can just pull it.
<bignose> and that will cause the current branch to lose the revisions after that point?
<bignose> 'bzr pull -r82 .'  =>  "No revisions to pull."
<fullermd> You need --overwrite since it's not going strictly forward.
<bignose> (current branch is at r87, I want to lose everything after r82 because they came in from the mistaken pull)
<fullermd> The revs will still be in its repository, of course.  But the branch won't refer to them, so...
<bignose> that's fine, I'm using a central repository.
<bignose> okay, that seems to have done the trick
<bignose> fullermd: thanks.
<bignose> next question:
<bignose> the reason I wanted to undo it was because I wanted to pull only *some* changes from foo into bar
<bignose> eventually, all of foo will be pulled in, but not yet
<bignose> so how can I pull specific revisions?
<fullermd> Well, you can pull up to a given rev rather than the head with -r...
<bignose> right, but that's exactly the situation I wanted to undo
<bignose> I want to specify "pull revision 87 and no other revision from foo into bar"
<fullermd> You can approximate it by gettings its changes with a cherry-picked merge.  But there's no way to get rev 87 itself without getting its antecedents.
<fullermd> That may or may not lead to extra fun down the line when you merge the rest of the revs.
<bignose> mmm. a cherrypicked merge will result in forever-divergent history, won't it? I want to be able to later align the histories fully with a pull.
<fullermd> Well, if you don't make changes other than the equivalent of r87, you can later just do a pull --overwrite and discard that new rev you made.
<bignose> I hear the spectral voices of my darcs friends laughing and pointing...
<fullermd> (as long as nothing else is based on it, of course)
<fullermd> They're not laughing and pointing.  They will though, as soon as their history finishes resolving itself.  Might want to budget some time in 2015 to deal with the embarassment.
<bignose> I don't fully understand that, but I assume it's a comment on the performance speed of darcs merges.
<bignose> fullermd: by "discard that new rev you made", do you mean the rev created by the cherrypicked merge? Discard it because, with a 'pull --overwrite', the change will effectively be made anyway?
<fullermd> Well, you're wanting code that does a certain thing.  After you do the cherrypick, that code will be in both r87, and your newly-created cherrypick r83.
<fullermd> So if you then want to re-duplicate the other branch, a --overwrite will toss away your cherry-83, but since you'll have that 87 anyway at the point, it doesn't matter.
<fullermd> Assuming no work is ever based off that cherry-83, that is.
<bignose> fullermd: thanks, you've at least improved my understanding of what I'm asking :-)
<keir_> http://blogs.gnome.org/newren/2007/11/17/adoption-of-various-vcses/
<lifeless> night all
<lifeless> keir_: be good to find out what the date: thing they hate is
<keir_> yes
<keir_> lifeless, we need to get some big projects on board!
<fullermd> Packs for local and more SS for remote are probably 2 of the biggest steps to take there.
<wam> Hi, is it possible to branch / merge / push / pull to/from not-mounted samba shares?
<mwhudson> wam: you mean push smb:///whatever ?
<mwhudson> wam: i'm not aware of anything that would let you do that
<wam> mwhudson: would it be easy to write a plugin for that?
<wam> mwhudson: bzr is python-only, so maybe I could look at this.
<wam> (as I know python ;))
<mwhudson> wam: it's probably possible, yes
<mwhudson> i mean, there's a webdav plugin that mostly works and samba can't be that painful :)
<wam> mwhudson: ok, thanks. So I'll see if I have a use for it and maybe code it. A customer of mine works on windows and the working-dir is smb only. So I'd like to install a branch there and have merges as smoothly as possible ;)
<mwhudson> wam: good luck :)
<vila> hi all
<vila> abentley: is BB down ? Firefox timeouts trying to connect
<vila> or is it times out ? ;)
<fullermd> You trying to connect via htpps?
<vila> fullermd: not even :)
<ubotu> New bug: #163849 in bzr-eclipse "display revision log on uncommit" [Undecided,New] https://launchpad.net/bugs/163849
<jelmer> sigh
<jam> jelmer: ??
<jelmer> where are the days when you could hit Ctrl+C to abort the commit if you changed your mind
<jam> I do that now
<jelmer> now I have to use uncommit all the time :-)
<jam> the commit happens to fast?
<jelmer> yup, somewhat like that :-)
<jam> the price of progress, I guess
<jam> You could not use "-m" so that you can cancel without saving from your text editor
<jelmer> yeah, I may give that a try - thanks
<jam> personally, I would just 'bzr uncommit --force"
<mwhudson> good reason not to use checkouts, that
<mwhudson> less embarrassing
<jam> mwhudson: bzr uncommit removes it from the bound location, too
<jam> as long as nobody goes spelunking with "bzr heads"
<mwhudson> jam: true, but it might send email, etc
<jam> mwhudson: yeah, but my client always sends email
<jam> even for local stuff :)
<jam> well, I have a .../private/* directory
<jam> for stuff I don't advertise
<ubotu> New bug: #163860 in bzr "feature request: script to generate consistent copy of shared repository ('hot-backup.py in svn terminology)" [Undecided,New] https://launchpad.net/bugs/163860
<woei> I'm playing around a bit with bzr and I'm wondering if this error is expected behavior ? : http://pastebin.com/d24d654d5
<Kinnison> woei: blergh, even if it were an error to try and do that, you shouldn't get that kind of report
<woei> indeed
<mwhudson> does anyone know a way of doing this: http://paste.ubuntu-nl.org/45128/ without requiring a checkout ?
<jam> mwhudson: I don't believe the Merge code works without a limbo directory from a WT
<mwhudson> jam: what i want to avoid is the lengthy tree-building process for launchpad
<jam> mwhudson: have you tried it with an empty WT?
<jam> ah, but that wouldn't work either
<jam> wait a second
<jam> why are you doing a 'show_diff_trees' of revtree versus basis_tree
<mwhudson> jam: won't that take all the history of merge_source_branch?
<jam> don't you want the diff of the on-disk tree ?
<jam> (after the merge)
<jam> to its basis?
<mwhudson> jam: that's what i'm getting, it seems
<mwhudson> basis may not be a good name here
<jam> ah
<jam> ok
<jam> yeah, basis_tree is usually: tree.basis_tree()
<jam> which is the last committed version
<mwhudson> oh
<jam> I would just call it "tree"
<mwhudson> so revtree = basis_tree.basis_tree() is shorter and equivalent?
<mwhudson> jam: let me rename somethings and repaste :)
<jam> mwhudson: and for DirState working trees is faster
<mwhudson> jam: fine, but the slow part is create_checkout
<jam> because it has already written things down for faster comparisons
<jam> mwhudson: sure.
<jam> I understand your difficulty
<jam> I'm pretty sure the merge code doesn't have a way to work "lazily" and only extract texts for files that it is going to think of as modified
<jam> It might be possible to patch it in
<jam> as a "LazyWorkingTree" or something like that
<mwhudson> jam: http://paste.ubuntu-nl.org/45130/
<mwhudson> jam: right, i wondered about that
<mwhudson> jam: TreeTransform seems to hit the disk reasonably directly though, which worried me for this approach
<jam> yeah, but I think you could hide the real working files
<jam> Let me look at the code for a bit
<mwhudson> jam: thanks
<jam> mwhudson: it depends on how much you want to spend writing up a LazyWorkingTree, but it seems possible
<jam> you would still need to hit disk
<jam> but the idea is you would  create an object that doesn't extract text contents until it needs to
<jam> and it could track the list of files which were modified
<mwhudson> i don't care about hitting the disk
<jam> mwhudson: I could certainly help walk you through it if you want.
<mwhudson> i care about doing O(changes) rather than O(changes+tree) work
<jam> sure
<mwhudson> jam: how much work would you expect this to be?
<jam> I'm saying more: how much time do you want to spend coding this up :)
<jam> I'm actually thinking it wouldn't be that much effort
<jam> You only need to override a few key places
<mwhudson> i dunno, i don't want to spend a week on it
<mwhudson> but a day is probably just about reasonable
<jam> so some quick pointers...
<jam> you wouldn't use "target_branch.create_checkout()" obviously
<jam> instead you would init a new WT type
<jam> on that branch
<jam> and then you would override WT.get_lines() or it looks like you might need to also do WT.get_file()
<jam> (I don't know for sure why TT uses get_file().readlines() rather than get_lines()
<jam> might just be hysterical raisons)
<mwhudson> i should subclass WorkingTree ?
<jam> mwhudson: I think subclassing WT4 might be a good way to go
<jam> bzrlib.workingtree_4.WorkingTree4
<jam> as it has better "diff" code
<jam> All you are really adding is a list of things that have been modified
<jam> so your 'get_lines()' implementation knows to read from disk
<jam> rather than going to the repository.
<jam> (and get_file_sha1() also needs to be overridden)
<jam> and probably get_file_size()
<jam> mwhudson: If you want, I could probably try hacking something together
<mwhudson> jam: that would be cool
<jam> I'll give it an hour or so and see where I get
<mwhudson> jam: awesome
<jam> actually, it almost fits in with an idea Robert had
<jam> to make commit/diff/etc extra fast
<jam> by requiring the user to explicitly mark things changed
<jam> It just goes an extra step and doesn't bother creating the other files
<lifeless> mwhudson: so you want a tree where the user can't introduce changes, only merges can.
<mwhudson> lifeless: what i want is described by the docstring of the function
<mwhudson> lifeless: but yes, something like that sounds like a reasonable approach
<lifeless> mwhudson: which function?
<mwhudson> lifeless: http://paste.ubuntu-nl.org/45130/
<lifeless> jam: I think a working tree is the wrong approach for mwhudson's request; I'd look at subclassing merger myself
<lifeless> jam: then passing in two revtrees
<lifeless> so the output instead of being back into a working tree would go forward as iterable output
<jam> lifeless: you would have to keep the contents of all modified files in memory for the full length of the merge
<lifeless> jam: nope
<jam> i think I see where you are going with it
<jam> but I don't think Merger is really cleanly capable of it
<lifeless> This is a design I prepared earlier FWIW :)
<mwhudson> which reminds me
<mwhudson> what's the relationship between Merge3Merger and Merger ?
<lifeless> merge logic
<jam> what to do when you have files that need to be combined (merged)
<mwhudson> i am perpetually surprised by the fact that there is no subclass relationship here
<lifeless> mwhudson: me too looking at it
<lifeless> still; patches kthxcontribute
<jam> I believe Merger is the 'metaprocess'
<jam> and it takes a merge_type as a helper class
<jam> which at the least are poorly named
<mwhudson> lifeless: i don't feel competent in this code
<lifeless> ok, time for some pb luv
<jml> hi everybody.
<lifeless> LarstiQ: ping
<lifeless> hi jml
<jml> I think I am going to spend some time making Trial able to run the bzr tests.
<lifeless> aren't you on leave ?
<jml> lifeless: yes.
<jml> ok, so if you can trick trial into running on the return value of bzrlib.tests.test_suite(), rather than doing discovery then it works quite well.
<jml> modulo our TestResult objects not supporting TestSkipped and TestNotApplicable.
<bagueros> hello. is there a way to push just individual files into other branches?
<LeoNerd> Not really.. "individual files" don't really exist in discrete form.
<LeoNerd> A branch isn't a collection of files. It's a collection of revisions.
<LeoNerd> Revisions contain changes to (additions/modifications/renames/deletes) files.
<bagueros> well
<bagueros> i have a bunch of different branches and in each one, i want to take some files out of those
<LeoNerd> (As compared to the RCS/CVS/SVN view of the world, that says files exist, and revsisions exist within files)
<bagueros> and put them into a branch called stable
<bagueros> because a bunch of different developers have all been working on different things
<LeoNerd> Do you want to preserve all the history so far, or just "carry on" from here?
<bagueros> and each of them have *some* files which i want
<lifeless> 'bzr merge branch/FILE' will merge just hat file.
<bagueros> lifeless: ah! interesting
<lifeless> we don't currently remember later that we did that. But it will work. Also works for directories.
<bagueros> well i mean, how is this "done right" ?
<bagueros> i got a bunch of different people who are working on different branches..
<bagueros> the guy doing Feature A has old files for Feature B
<bagueros> the guy doing Feature B has new files for Feature B and old files for Feature A
<bagueros> so in stable, i want the new files for Feature B from the Feature B guy
<bagueros> and the files for Feature A from the Feature A guy
<dato> bagueros: oh, but you want to merge the full FeatureA and FeatureB branches, one after another, or just specific changes from them?
<bagueros> I don't want Feature B guy's old Feature A files to overwrite Feature A guy's new Feature A files
<bagueros> you know what i mean?
<dato> yes
<lifeless> bagueros: oh, just bzr merge
<dato> if you merge FeatureA, and then merge FeatureB, all changes will get merged.
<lifeless> we clearly need some documentation improvements here
<bagueros> indeed
<bagueros> and merge will figure out who has the latest version for each file
<bagueros> and use that one?
<dato> yep. even if both developers touched the same file, but different parts of it, will do an intelligent merge and combine both changes.
<lifeless> bagueros: it will integrate the changes made.
<jml> and trial misses exactly 777 tests. hmm.
<bagueros> ok
<dato> jml, what's trial?
<jml> dato: a unit testing framework that twisted uses.
<dato> ah, okay.
<jml> which is the number of tests that I have in my various plugins :)
<jam> jml: do you know about "bzr selftest --list-only" ?
<jam> It might make it easier to figure out what is and isn't being found
<jam> You could use "bzr selftest --list-only | sort" and compare the output
<jml> jam: I didn't know about that -- thanks.
<RainCT> hi
<RainCT> wasn't there a Â«bzr cdiffÂ» option some time ago, or did I dream that? :P
<jam> RainCT: from bzrtools
<RainCT> ah ok, thanks
<lifeless> jam: ping
<lifeless> jam: I'd like to sanity check a refactoring goal with you.
<lifeless> I want to make pb a bit simpler. heres how I think it might look
<lifeless> firstly, I want to decouple 'progress' and 'display'. Nesting is about progress not display. So I'm thinking of adding a Task concept
<lifeless> this will have message, current, total.
<lifeless> now, I don't think we care about estimating time for all tasks. Only the overall one. So there will be a subclass TimedTask that adds in the eta calculations etc.
<lifeless> now, our pb abstraction for users really needs __init__, update, clear, message and finished
<lifeless> oh, and tick
<lifeless> which is 'doing stuff'
<lifeless> having a trivial display-a-task as *ProgressBar is the goal, but throttling makes this a little hard
<lifeless> if we show the message from e.g. the bottom task as well as the top, that may thrash
<lifeless> but we do want to always show a top level message change.
<lifeless> and to complicate things, some commands will have a top level task that goes e.g. 0->2, where the first level is really the one that we want to change reasonably often.
<lifeless> the reason throttling doesn't hide messages, IIRC, is that we have a message that indicates the start of a slow operation, and it then sits for ages.
<lifeless> so I'm proposing to change it to ignore message, and add in a 'force' parameter to update if needed
<lifeless> so anyhow the big picture rapidly:
<lifeless> Task tracks tasks
<lifeless> TaskStack is a stack of tasks
<lifeless> TimedTask is a timed task
<lifeless> TaskStack is a Task itself.
<lifeless> _BaseProgressBar is for display logic only, it displays a Task
<lifeless> bars that want to dispaly many bars concurrently can expect/require a stack and work with the stack
<lifeless> nested_progress_bar stays, it returns a Task though
<lifeless> Task has update/clear/message/tick/finished, because task changes trigger display changes
<lifeless> fini
<lifeless> hmm
<lifeless> actually I think there is a differnet concept in there
<lifeless> which is progress
<lifeless> so a Progress object -> update/clear/tick/finished. Calling these delegates as appropriate to either the Bar for UI, or the Task for tracking.
<Vantage> hi, is there a way in bzr to take two repos and merge them into one (including history)?
<Vantage> I know there's split to separate a repo, but what about bring them together?
<lifeless> e.g. update is 'if self.task.update(message, current, total): self.bar.tick()'
<lifeless> Vantage: repositories are just a history database
<lifeless> Vantage: perhaps you mean 'branch' ?
<Vantage> lifeless: right, and I'd like to merge the history databases :)
<lifeless> Vantage: just branch into the repository then, it will bring in any needed history.
<lifeless> Vantage: 'split' does /not/ affect repositories. I really think you are confused about something.
<Vantage> lifeless: so if I had a repo called frontend and a repo called backend (because I thought it'd be better to keep them separate) and later I decide it's better to have it as one project
<Vantage> lifeless: I'm always confused about something :)
<lifeless> Vantage: repositories don't have names. I *really* think you mean 'branch'.
<lifeless> Vantage: if you can run 'log' on it it is a branch.
<Vantage> lifeless: sure, at their essence they are branches, but of different code bases
<lifeless> then just merge them.
<Vantage> lifeless: even if they never shared any history before? (or even files)
<lifeless> you'll need to tell bzr you really want to do this - 'bzr merge -r 0..-1 otherbranch'
<Vantage> lifeless: so if I have two code trees in bzr that I initialized separately into two directrories (a/ and b/) I could just cd a/ bzr merge ../b ?
<lifeless> Vantage: of course. try it - you'll need the -r parameters I gave you
<Vantage> lifeless: very cool.  btw what do those paramters actually mean?
<lifeless> Vantage: for future reference, 'Repository' is just the database. Its like asking 'how do you merge two mysql databases' - its a no-op, theres nothing to do, they are just data.
<lifeless> if you want to talk about your projects or your code, its *always* 'Branch'.
<lifeless> Vantage: the -r 0..-1 says 'merge from the beginning of time (0) to the most recent commit (-1)'
<Vantage> lifeless: cool.  I knew that they were branches, but I thought that they had separate repositories was an issue.  i guess not :)
<thumper> lifeless: do you know about bug 152746?
<ubotu> Launchpad bug 152746 in bzr "bzr commit to bzr+ssh hangs on 'No handlers could be found for logger "bzr"'" [Undecided,Confirmed] https://launchpad.net/bugs/152746
<lifeless> Vantage: nearly all branches have separate repositories, even when the code in them is the same.
<thumper> lifeless: I'm trying to help someone in #launchpad, but I don't really know what is going on
<lifeless> Vantage: e.g. bazaar-vcs.org's bzr.dev has a repository. I have a separate repository here that has a copy of bzr.dev.
<Vantage> lifeless: good point.  Does it make a difference if you're using a shared repo?
<lifeless> Vantage: dealing with separate repositories is a back-end data transfer problem, not a user-task problem.
<lifeless> Vantage: nope.
<lifeless> thumper: I don't, no.
<thumper> lifeless: ok
<lifeless> I can peek, one sec
<Vantage> lifeless: nice.  So if I have two projects that happen to share *some* files, can I merge changes in files between them?
<lifeless> Vantage: yes. It will try to merge the whole projects though, as normal.
<lifeless> Vantage: you can merge branch/FILE-OR-DIR too though, once you've done the initial sync-up merge.
<Vantage> lifeless: anyway to only merge changes to a particular file?
<lifeless> thumper: it looks like there is a patch for lp
<lifeless> thumper: they might try break-lock I guess
<lifeless> thumper: or sftp
<thumper> lifeless: it has stalled in review
<thumper> lifeless: break-lock didn't help (break-lock done over sftp)
<lifeless> thumper: try pushing over sftp then
<thumper> lifeless: pushing over SFTP worked for him
<lifeless> ok
<bagueros> hey so
<bagueros> i had one of these developers do the merge
<bagueros> and it found 12 conflicts
<bagueros> what does he do with these conflicts?
<bagueros> is there something automatic he can do?
<lifeless> that means that two people made different changes to the same region of those files. He needs to integrate the two pieces of work.
<lifeless> and then commit the result
<bagueros> hmm
<bagueros> what about this bzr resolve ?
<bagueros> does he have to run that ?
<lifeless> after integrating the work, yes. I thought this was all in the tutorials.
<bagueros> well, i'm just making sure
<bagueros> because http://doc.bazaar-vcs.org/bzr-0.8/tutorial.html this tells me that there are automatic utilities for doing that
<bagueros> kdiff or something
<lifeless> sure; I want to make sure this is discoverable without having to come and ask ;)
<lifeless> wow, are you using 0.8 ?
<lifeless> what bzr version are you using (bzr --version)
<bagueros> no, i'[m using 0.16
<lifeless> http://doc.bazaar-vcs.org/bzr.0.16/tutorial.htm is more applicable then
<lifeless> I encourage you to upgrade to 0.92 though
<bagueros> so, when he did this merge, it had 12 conflicts
<bagueros> and when i go look in stable, i dont see some of the files he has in his branch that i hoped would be merged into stabl
<bagueros> *stable
<bagueros> is it because the conflicts are holding up the merge?
<Odd_Bloke> bagueros: Merges have to be committed.
<bagueros> oh. but he is just working out of his branch
<bagueros> when he does the commit, it will also update stable?
<Odd_Bloke> Only if committing to his branch would normally update stable.
<lifeless> bagueros: you should go to stable, then merge his branch
<lifeless> bagueros: or you can merge from him after he commits.
<ubotu> New bug: #163908 in bzr "upgrade should tell you where to upgrade" [Undecided,New] https://launchpad.net/bugs/163908
<bagueros> lifeless: i see
<james_w> vila: It seems to me that the .debs of bzr should depend on ca-certificates, otherwise there is no CA to allow https access to launchpad. Does that seem sane to you?
<james_w> vila: or, I can't access https://code.launchpad.net/ as it complains about a CA cert error, and I don't have that package installed.
<poolie> james_w, ah, does that fix it?
<poolie> forcing use of urllib seems to also fix it, though that's a bit clumsy
<james_w> hi poolie
<james_w> you are seeing it to?
<poolie> i did see that the other day
<poolie> well, a week ago
<james_w> maybe its a widerspread problem then
<james_w> I haven't installed that package yet, just working it around it currently to try and get that code.
<james_w> poolie: yeah, that fixes it.
<poolie> would you file a high-priority bug on the package, if there isn't one?
<james_w> poolie: filing it now.
<lifeless> poolie: would like a reply - doesn't need to be deeply considered, surface reaction is fine - to my just sent pb redesign mail
<lifeless> also, quick call ?
<keir_> I just had a very frustrating experience because bzr lacks universal newline support. lets please get that fixed :(
<vila> james_w: .debs for ubuntu or debian ? Also, depends may be a bit strong, can't you use recommands ?
<james_w> vila, yeah, that would be better of course, thanks.
<vila> using urllib is a workaround for now, implementing proper  certificate verification is on my TODO list though, so it will ultimately fails too
<vila> james_w: in what kind of config do you see that ?
<james_w> vila: with no CA certificates in /etc/ssl/certs I think.
<james_w> or at least not whatever issues lp's.
<vila> :) I meant, all my ubuntu had ca-certificates installed why yours doesn't ?
<james_w> vila: I don't know, let me see.
<james_w> any of mutt, fetchmail, openssl, sendmail-base, w3m libcurl3-gnutls will install it, but it doesn't appear to be part of gutsy default install.
<vila> Ha ! I did an update... that explains it.
<james_w> yeah, must have been dropped.
<siretart> james_w: I think a recommends on the ca-package is the way to go
<james_w> siretart: yeah, me too.
<lifeless> poolie: 1.0 branch up
<Odd_Bloke> What's the best way to get a list of files that were touched by a given revision?
<lifeless> repository.find_fileids_altered_by_revision_ids(revid)
<lifeless> this gives file ids which have lines ascribed to them by annotation,
<lifeless> the difference between that and e.g. log -v is that log -v will show things that were not altered in the revision but merged into a branch in a revision.
<lifeless> i386: ping - give me a ring ?
<i386> lifeless: yep
<i386> could you message me your no?
<i386> lifeless: cool
<i386> Ill call in a sec
<lifeless> thanks
<igc> morning all
<lifeless> hi igc
<igc> hi lifeless
<lifeless> igc: leslie hawthorn says 'come to her soc talk'
<igc> I'm planning to
<lifeless> :)
<lifeless> man, enough of the russian spam
<abentley> vila: I'm not aware of it going down today.
<keir_> did you guys see the post from the intel engineer on the bzr list?
<jam> which one would that be?
<keir_> there are two posts from wichmann, who is from intel
<keir_> he's having big performance problems
<keir_> and the 2nd msg is about a corrupted repository
<keir_> i feel like someone should respond to the performance complaints. it looks bad when messages like this go unanswered on the ml...
<lifeless> thank you for pointing it out
<abentley> mwhudson: Are you sure that diffing against the least common ancestor isn't good enough for your purposes?  That's what I use for the preview patches of merge directives, for example.
<lifeless> abentley: yes; showing the result of the merge shows up conflicts
<lifeless> abentley: and for assessing whether something is ready to merge, and in good shape, this is very useful.
<abentley> Ah,  I assumed he didn't care about conflicts because he was ignoring the conflict count.
<abentley> Yeah, it seems like you would want to subclass either Merger or TreeTransform.
<abentley> The idea of true "undo" has also pushed me at the idea of generating Trees from Transforms without hitting disk.
<abentley> Because Transforms are our most detailed representation of changes.
<Peng> Wow, you have an official IANA-registered port. Cool.
#bzr 2007-11-20
<abentley> Yeah, we be hardcore.  But how come it's not listed in Gutsy's /etc/services?
<jroes> how do I revert to a specific revision?
<lifeless> revert -r revno
<jroes> where would that be documented? :)
<lifeless> bzr help revert
<AfC> bzr help revert
<lifeless> as well as the man page and IIRC users guide too
<AfC> "Come join #bzr, the channel with attitude for the tool with attitude"
<lifeless> :)
<jroes> cool :)
<jroes> thanks guys, not sure why I couldn't find it
<Rotund> I have some questions.
<Rotund> Is it costly to push from a repository (init-repo) to a branch not in the repo?
<radix> Rotund: you mean, push a branch which is sitting in an existing repository to somewhere else? yep
<radix> Rotund: you can push it anywhere you want, including other shared repositories
<radix> oh. I should read *all* the words
<Rotund> Would that be more expensive than pushing from one branch not in a repo to another that is not in a repo
<radix> Rotund: so, if you're pushing to an existing branch, only the new revisions will be sent
<radix> so it can be very fast
<radix> if the other side has most of the revisions already
<Rotund> I'm not finding that to be the case
<poolie> igc, hi?
<radix> and you can even push into remote repositories, so even if you're creating a new branch it can be fast if the repository has most of the revisions.
<igc> hi poolie
<Rotund> I have a collection of drupal sites I'm managing with bzr
<Rotund> I have a "base install" and each site gets a branch.
<Rotund> I make changes to the base.  Go to each website and merge
<Rotund> FAST great (they are in a shared repository).
<poolie> igc, would 9am tomorrow be ok for a standup meeting?
<Rotund> Now pushing those changes to an already created repository is pretty costly
<poolie> actually, 9am daily starting tomorrow?
<igc> poolie: my 9am or your 9am?
<poolie> yours
<igc> yes
<poolie> cool
<igc> I was expecting one today :-)
<Rotund> I've tried sftp, bzr (running a server), and bzr+ssh.  All seem to take 2+ minutes to push just a module change
<radix> so you've got something like site-repo/{base,website1,website2,website3} ?
<igc> poolie: this channel?
<Rotund> radix: exactly
<radix> Rotund: and it gets slow when you push what to where?
<Rotund> I now need to push from my local (my computer) branch to the server's branch
<radix> Rotund: ah, do you have this structure mirrored on your local computer and on the server?
<Rotund> yup
<Rotund> I don't have it bound (is that the term?)
<radix> Rotund: ok. and are you extra-sure that both sides have the shared repository in the parent directory? there should be a .bzr there
<Rotund> would that help?
<radix> Rotund: binding shouldn't matter
<radix> i.e. site-repo/.bzr
<Rotund> only one side has the shared-repo
<radix> Rotund: I'm not exactly sure what kind of operation you're doing, but making both sides shared can vastly increase speed of some operations
<Rotund> is there an added penalty for having one side shared and the other not?
<radix> notably, pushing up new branches
<Rotund> I'm just pushing changes though (version 8->9 for instance)
<radix> hm. to an existing branch?
<radix> in that case, it should be fast no matter what your shared repo setup
<Rotund> That's what I would've thought
<radix> 2 minutes definitely sounds weird, for just one revision. are the revisions large?
<Rotund> 933K
<radix> Rotund: is it made up of many small files?
<Rotund> it is 42 files
<radix> 933k isn't exactly a light revision, but I guess this is the point where my knowledge reaches its limit
<Rotund> I've done things like 1 big file and it'll end up 20 min +
<radix> Rotund: what kind of bandwidth and latency do you generally get between these hosts?
<Rotund> big = ~3 MB
<Rotund> I'm not sure.  It's dreamhost
<Rotund> gonna test... one sec
<Rotund> ouch.  50KB.
<Rotund> Hmmm.  That's awful.
<radix> that's plenty fast for uploading 3MB :)
<radix> way faster than 20 minutes, anyway
<Rotund> Though, I'm still getting the file in ~6 min
<Rotund> (Testing a 25 MB one)
<Rotund> I just walked away for that
<Rotund> It's typically the fetch stage that kills me
<Rotund> (stage 1)
<Rotund> Is that the actual transfer?
<Rotund> If so, I guess I could live with it.
<radix> I assume it is
<Rotund> okay.  Well, thanks
<Rotund> BTW: I'm all hyped for PyCon this year =)
<radix> Mph. I guess I'm probably not going to be there.
<Rotund> They have a week before and after for sprinting, right?
<Rotund> Why not?
<warren> How good is the bzr to CVS export tools?
<warren> Can they relied upon in an automated way...
<abentley> You mean converting from bazaar to CVS?
<warren> Yes.
<Rotund> That was my question
<radix> Rotund: a friend of mine (who would also be at pycon were it not for this) is getting married :)
<Rotund> radix: were they there this year?
<abentley> Okay, well, I have no idea about that.
<Rotund> Man, I may have to find someone else to bug all the time now =(  ;)
<radix> Rotund: glyph was.
<radix> Rotund: heh. it was pretty good convo last year.
<Rotund> glyph's getting married?
<radix> righto.
<radix> Rotund: I hope your game projects are going well, btw :)
<Rotund> radix: Wow.  And he chose PyCon to do it during?  Why am I hearing the cracking of whips over and over ;)
<radix> heh heh
<Rotund> radix: so is most of the Twisted guys gonna be MIA?
<radix> I imagine there will be a weakened presence this year.
<Rotund> radix: I wish... unfortunately, real world work is taking all my time
<radix> Rotund: stupid real world.
<Rotund> radix: Though, I've been doing quite a bit of Python training and evangelism
<Rotund> radix: Many of our customers are switching to python
<radix> excellent
<jam> warren: are you saying the conversion tools, or the one that lets a CVS user checkout files from a Bazaar branch
<warren> jam, conversion
<jam> (AFAIK they are readonly, but reasonably good)
<warren> ah, didn't know the latter existed
<jam> I don't know of any specific converters that start with Bazaar and go to CVS
<warren> oh
<jam> I suppose Tailor would be an any-to-any
<Rotund> radix: Honeywell, Rockwell Collins, (testing for both) and most of the tools used for the 787 are Python (though I don't think I've seen Twisted)
<jam> https://launchpad.net/bzrcvsserve
<Rotund> radix: well, that real world thing is calling.  have a good one.
<radix> you too man. take it easy.
<jam> Rotund: fun to hear about Rockwell Collins, I interned there for a summer for the Large Format Displays on the 767
<jam> IIRC they were looking at Python because its license was better than Perl
<jam> (being BSD rather than a form of GPL meant it was more obvious that it wouldn't invade accidentally)
 * igc lunch
<ubotu> New bug: #163995 in bzr "Re: bzr register-branch is undocumented in manpage" [Undecided,New] https://launchpad.net/bugs/163995
<AfC> So notwithstanding the email thread on the topic, should I be telling people to `bzr branch` or `bzr clone` when downloading the sources (for the first time)?
<lifeless> branch
<lifeless> here's how I describe it
<lifeless> 'if you want a mirror that you won't edit, do 'bzr checkout''
<lifeless> 'if you want to start a new line of development, to hack on the code yourself, do 'bzr branch''
<lifeless> (for the former, use bzr update to keep the mirror up to date, for the latter use bzr merge to incorporate changes from the origin)
<jamesh> I wonder if people would complain if "bzr fork" was an alias for "bzr branch"?
<fullermd> fork should do more than just branch, though.  It should send of a fiery "screw you guys, I'm going home" mail to the project's mailing list.
<fullermd> Obviously another address we need to store in branch metadata...
<AfC> lifeless: (actually I was asking about `clone` vs `branch`, not `checkout` vs `branch`) abentley was pretty adamant that clone and branch behave differently, which was rather an interesting surprise.
<AfC> Meanwhile, you know how you look at the generated Index listing on a web server for a directory with a Bazaar Branch present, but no Working Tree, and it looks to a lay person like nothing is there? I had some fun this afternoon and scratched an itch:
<AfC> http://research.operationaldynamics.com/bzr/java-gnome/mainline/
<mwhudson> AfC: neat
<mwhudson> for launchpad we were thinking of running codebrowse from the same url space as the branch
<AfC> mwhudson: yeah, that works too
<lifeless> AfC: abentley said that the internals differ for the 'sprout' and 'clone' apis.
<AfC> mwhudson: I had a darcsweb installation before, but at a different URL space
<lifeless> AfC: at the ui clone is an alias for branch.
<AfC> lifeless: oh. Ok. I will stick with clone, then.
<lifeless> AfC: saying 'branch' is really better IMO
<AfC> lifeless: (he really made it sound like there was some difference having to do with Working Trees or soemthing)
<lifeless> AfC: it indicates the semantic action that takes place.
<fullermd> 'get' is the one that always throws me for a loop.
<AfC> lifeless: personal reasons: 1) I find the term branch getting overloaded, especially with new users:
<AfC> "run the bazaar branch command to get a branch of the bazaar branch which is then a branch that you can branch yourself"
<fullermd> AfC: I did a mini-rant on that Way Back When...
<AfC> lifeless: personal reasons: 2) many of my new potential hackers at the moment are Git aficionados; making the very first command they see a bit more familiar helps get them going. It's a little thing, but it seems to help.
<AfC> [and I'm hyper conscious of trying to present them a good impression]
<lifeless> fair enough
<AfC> lifeless: had a really interesting run through that with Carl Worth via phone the other day. He'll be down at LCA in Melbourne; I'd like to encourage you and Martin and whoever else to have a chat with him then using him flailing at [as it happens my project] as a case example for someone who is _really_ deep into Git but not a shit when dealing with other people.
<mwhudson> i alternate between get and branch randomly i think
<mwhudson> more likely to use 'get' on a remote branch
<AfC> mwhudson: that makes sense too
<LarstiQ> lifeless: pong
<lifeless> LarstiQ: where is your subtrees branch ?
<lifeless> LarstiQ: It keeps coming up, and no-one knows where to go to get your current state.
<lifeless> LarstiQ: so I'd really love it if you made it visible - it doesn't matter if its not functional, just making it accessible++.
<LarstiQ> lifeless: https://code.edge.launchpad.net/~larstiq/bzr/nested-trees may not be entirely up to date, just a sec
<lifeless> thanks!
 * LarstiQ needs to fix the pending work and actually commit something
<lifeless> small commits++
<LarstiQ> lifeless: I'm spending 2 hours on that now
<lifeless> LarstiQ: yay!
<lifeless> I'm about to sleep, so gnight!
<LarstiQ> lifeless: I cognitively entirely agree with small commits++
<LarstiQ> lifeless: good night
<jayesh_> i think bazaar don't have many starting level tutorial !
<jayesh_> i really struggled to start with
<AfC> jayesh_: what are you having trouble with?
<jayesh_> to understand DRCS
<jayesh_> i am an svn user
<matkor> Hi. Is it possilbe to downgrade branch/checkout to given revision ? How can I do it ?
<fullermd> What do you mean by 'downgrade'?
<fullermd> Change the files?  Change the basis tree?  Discard later changes semi-permanently?
<matkor> fullermd: checkout source is now under -r 100
<matkor> I did bzr update
<matkor> but no I want have checkout at revison 50
<matkor> becouse sth went  wrong
<AnMaster> http://bazaar-vcs.org/ConfiguringBzr#head-8b89e546875b2447e015c0b83e423ef4d99ce6e0 refers to "when-required"  "Sign newly committed revisions only when the branch requires signed revisions."
<AnMaster> how does one set a branch to require it
<AnMaster> I can't find it
<fullermd> matkor: Well, still, kinda a question of what you're trying to accomplish.  Are you wanting to just look at/play with the files as of rev 50?  Are you wanting to craft up a rev 101 that looks just like r50?  Are you wanting to throw away r51-100 and start over from 50?
<matkor> I want temporarly have rev 50
<matkor> until I fix problems and commit more
<matkor> revisions
<matkor> lets say 105 which fix poblems
<fullermd> Well, sounds like using 'revert' is probably your closest bet.  That'll just change your WT files, not anything else.
<AnMaster> anyway what about the signing?
<AnMaster> :)
<fullermd> AnMaster: Search me.  I think there's some branch config option that may do it, but last I heard the gpg code had a lot of exposed innards and spiky edges in those places.
<AnMaster> I see, I searched all docs, googled and so on
<AnMaster> I really need to enforce signing however :/
<fullermd> Might try asking jam when he shows up (couple hours, probably); I think he knows that part of the code reasonably well.
<AnMaster> hm, couple of hours, argh. not here then probably
<mwhudson> i think you edit gpg_policy or something in locations.conf
<AnMaster> hm? isn't locations.conf for the old way of storing parent branch and such?
 * AnMaster thought it was stored in the branch nowdays
<AnMaster> if it matters: I'm using a shared repo for all my branches with the format "dirstate-tags"
<AnMaster> (and I do use tag feature)
<matkor> fullermd: Thank you very much ... revert seems ok
<matkor> fullermd: To get latest reviosion again. I do : bzr revert ; bzr update, right ?
<fullermd> matkor: Just the 'revert' by itself should do it (unless more new revs showed up in the branch of course)
<jayesh_> i just created an experimental branch in bazaar.. and i am trying to push to that.why it is taking long time?
<jayesh_> is it not pushing a diff ?
<AnMaster> fullermd, hm you there?
<AnMaster> how long until that "jam" shows up do you think?
<jonny2> hi, can use a command to use my version of all conflicts?
<lifeless> moin
<jelmer> hey lifeless
<thumper> morning bizarre dudes
<lifeless> hi
<floam> is the push-and-update plugin still the "right way" to maintain a working tree on a sftp remote location?
<lifeless> floam: yes
<floam> ok. I thought maybe it was replaced by something smarter since I've been getting deprecation warnings every time I use it since 0.90 and I've seen no updates to it
<lifeless> perhaps you could file a bug on it then ?
<floam> well, it works fine
<floam> I just get this every time:
<floam> /Users/floam/.bazaar/plugins/push_and_update/push_and_update.py:119: DeprecationWarning: bzrlib.transport.split_url was deprecated in version 0.90.
<lifeless> yup, please file a bug.
<floam> ok.
<Peng> check_signatures = always is invalid, right?
<Peng> Arrgh.
<Peng> I mean create_signatures.
<Peng> check_signatures uses always but create_signatures uses "require".
<Peng> Oh. I do mean check_signatures.
<Peng> Apparently I needed more sleep.
<Peng> Anyway, I was asking because the configuration.txt doc gives an example of check_signatures = always once but usually uses "requires" and only lists "requires" as valid.
<Peng> Err, "require". no s.
<igc> morning
<jam-laptop> igc: good morning
<igc> hi jam-laptop
<jam> silly Colloquy won't let me change the default username
<jam> ... :(
<jam> I blame Mac's "don't have an Ok button" design philosophy
<jam> lifeless, igc:  so are we getting ready to do the conference call?
<jam> i don't see poolie
<thumper> jam: there he goes ^^
<jam> hi poolie
<jam> bye everyone
<jam>   thumper: will you be joining us?
<thumper> jam: no, got to go and collect my daughter
<jam> pfff, weak
<jam> you make a big deal about sitting in
<thumper> :)
<jam> and then back out :)
<thumper> I was just checking
<jam> poolie, igc, lifeless: Are we meeting now? It was supposed to start 10 minutes ago
<jam> well 13 by my clock
<igc> jam: we did :-)
<jam> shoot
<jam> i pinged at 3minutes till and nobody said anything
<jam> I'm glad it went quickly, though
<igc> it was a conference call - just finished
<jam> sure, but I don't like calling phone numbers cold...
<jam> when I know there are people online
<jam> anyway, sorry I missed it
<igc> poolie is waiting for lifeless to arrive so there may be a follow-up shortly if you're still around
<jam> was there a conference code number?
<igc> jam: anyhow, for me today: 1. blackbox tests for switch; 2. User Guide
<jam> or is that just Martin's room
<jam> #
<jam> I think we need to address the community pushback about 1.0
<igc> yes
<jam> which probably isn't a 15-minute phone call
<igc> agreed
<jam> anyway, I actually need to get going
<jam> I'll thank you in advance for all your help
<jam> (since I'm gone for Thanksgiving :)
 * jam => away
<lifeless> ola!
<lifeless> jamesh: enjoy!
<lifeless> jam: Enjoy!
<jamesh> enjoy what?
#bzr 2007-11-21
<lifeless> jamesh: thanksgiving ... tab-completion
<floam> tab-completion? being python it can probably use optcomplete and get it for free
<floam> assuming it uses optparse
<sabdfl> moin all
<poolie> sabdfl, hi
<sabdfl> howdy poolie
<poolie> sabdfl, if you're free i'd like to talk to you later
<sabdfl> sure
<lifeless> floam: we derive from it
<Peng> Oh, bundle is a hidden command? Why? Because of send?
<lifeless> floam: but we have subcommands and stuff
<lifeless> Peng: yes
<floam> now just make completions for fish..
<floam> (yes, I'm a weirdo)
<thumper> lifeless: ping
<thumper> lifeless: unping
<lifeless> thumper: ?
<Peng> Hmm. I just noticed that a couple small branches of mine haven't been converted to packs yet. And I messed up their shared repo situation.
<alla> Hello! Bzr is great, all hail bzr.. But.. there's this feature I noticed on the darcs wiki which looks pretty neat: http://wiki.darcs.net/DarcsWiki/SpontaneousBranches  ... in bzr is there a way to merge in a bunch of patches that all have a log message starting with a common identifier eg: RT#3242  ?
<alla> at the moment I'm sort of doing: bzr log -m "9036"
<alla> to get the revision numbers, and then merging the patches in manually..
<Peng> Well, you shouldn't use patches.
<Peng> Hmm, I don't think you can do that.
<alla> Sorry perhaps my terminilogy is off.. er s/patches/bundles/  ?
<alla> *terminology!
<beuno> alla, how is this solved in Darcs?
<Peng> If you mean bundles, then okay.
<Peng> I don't think you can do that with bzr.
<Peng> I don't think that's even compatible with bzr.
<alla> Well to my mind the way to solve it would be to extend the revisionspec to include matches against log file messages.. but I don't know squat :D
<poolie> alla, you could get the revision numbers from log and then cherrypick-merge them
<Peng> Oh.
<poolie> it won't be as slick as on darcs, because they just treat branches as a bag of patches
<poolie> alla, that might be interesting
<poolie> you could write a python script to merge them all
<Peng> What I was just talking about was with exactly what bzr was talking about.
<Peng> Not what you were talking about.
<alla> poolie: is cherrypick-merge a special plugin/functionality? Or does that just refer to the process of merging with revision numbers?
<sabdfl> i seem to have badly locked my central server repo
<sabdfl> bzr break-lock works, but then the next invocation of bzr complains about another lock
<Peng> sabdfl: Packs?
<sabdfl> this server has 0.17
<sabdfl> nope
<Peng> Oh.
<Peng> Shouldn't hurt to upgrade.
<sabdfl> not my server
 * beuno used to delete the lock/ dirs manually when 0.17 locked itself that way
<Peng> bzr+ssh?
<sabdfl> beuno: how do i do that?
<sabdfl> oh, heck, didn't see the time, got to run
<sabdfl> thanks for any help typed here!
<beuno> sabdfl, if you've got ssh, you should be able to delete the folders inside .bzr
<alla> hmmm.. is there a way to merge in multiple revisions in one go..? Something like bzr merge ../somerepo/ -r 3..4,10..12
<beuno> ah, np, good evening/morning  :D
<alla> Which would give you revision 4, 11 and 12 I guess.
<alla> Because subsequent merges, require subsequent commits...
<alla> Where are a bzr merge ../somerepo/ -r 10..12   .. pulls two revisions over, but only requires one commit.
<beuno> alla, you want to merge each revision individually?  because otherwise, normal merging will bring in all of the revisions
<alla> beuno: Yes individually.. cherry picking only the relevant changesets across.
<alla> Ie, if there are 10 changeset (10 commits) in the branch, and I want to only grab the changesets with revision numbers: 3, 6, 8, then from what I can see I need to perform three separate merges and three separate commits.
<alla> Whereas ideally, I would perform 1 merge consisting of three changesets, and 1 commit.
<Peng> Ideally with Bazaar, I guess you should change your workflow to not use so many cherrypicks.
<beuno> alla, you could use PQM to solve that
<beuno> alla, http://bazaar-vcs.org/PatchQueueManager
<beuno> (the workflow, maybe not the specific case)
<beuno> and/or something like bunddle buggy: http://bundlebuggy.aaronbentley.com/
<lifeless> sabdfl: bzr break-lock centra-server-url
<alla> beuno: I don't think my workflow / use case is particularly exceptional. I just want to merge in a bunch of changes from a fellow developers branch. Ie pull over the relevant changesets into my branch, and merge them in.
<baijum> hi all
<baijum> While pushing my branch to bzr in launchpad I am getting an error like this:
<baijum> No handlers could be found for logger "bzr"
<baijum> Is this related to https://bugs.edge.launchpad.net/bzr/+bug/152746
<ubotu> Launchpad bug 152746 in launchpad-bazaar "bzr commit to bzr+ssh hangs on 'No handlers could be found for logger "bzr"'" [High,In progress]
<baijum> any work around for this problem ?
<lifeless> baijum: you can replace bzr+ssh with sftp for now/
<baijum> lifeless, with sftp, I am getting an error like this:
<baijum> bzr: ERROR: Can't rename /srv/sm-ng/push-branches/00/00/1a/46/.bzr/repository/lock/6cwjx3rh21.tmp to /srv/sm-ng/push-branches/00/00/1a/46/.bzr/repository/lock/held: /srv/sm-ng/push-branches/00/00/1a/46/.bzr/repository/lock/held already exists
<lifeless> baijum: thats probably due to hitting ctrl-C on the previous operation
<lifeless> baijum: bzr break-lock sftp://.... will fix that
<baijum> lifeless, thank you very much, that worked  !
<baijum> lifeless, Can I switch back to bzr+ssh later ?
<lifeless> probably right now if you like
<baijum> lifeless, thanks !
<sabdfl> lifeless: i've done that a couple of times
<sabdfl> both remotely, and locally on the server
<alla> Hi, is there a way to merge in multiple non-sequential revisions in one go..? Something like bzr merge ../somerepo/ -r 3..4,10..14
<lifeless> sabdfl: is it devpad, or bazaar.lp.net ?
<lifeless> alla: no; but you can do 'bzr merge ../somebranch/ -r 3..4'; 'bzr bzr ../somebranch/ -r 10..14 --force'
<sabdfl> lifeless: devpad
<Peng> Gaack!
<lifeless> what branch is giving you trouble ?
<Peng> I'm frequently getting "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format." when trying to bzr upgrade.
<Peng> In this case, it was switching from dirstate-tags to dirstate to see what would happen.
<lifeless> Peng: I don't think we have a downgrader written for that; there is nearly no reason to do so.
<sabdfl> lifeless: my /code/mark/launchpad/project-news branch
<Peng> It was after reading a mailing list message in the rich-root thread that said "Our framework for conversion doesn't handle the case of "might be compatible, depending on features used" very well.".
<Peng> I was curious what the error would be.
<lifeless> Peng: dirstate and dirstate-tags both have the same repository format; you can't trigger what aaron talks about between the two
<Peng> ...
<lifeless> Peng: you'd need knit3 and knit, for instance, but don't have knit3 exposed as its not supported yet
<Peng> They're a different branch format?
<lifeless> dirstate and dirstate-tags differ only in branch format
<lifeless> sabdfl: ls project-news/.bzr/branch/lock/held -ld
<lifeless> drwxr-sr-x 2 mark lpteam 4096 2007-11-21 03:53 project-news/.bzr/branch/lock/held
<lifeless> sabdfl: its definately held; and your repository isn't locked
<sabdfl> held?
<sabdfl> nothing should be accessing that branch/repo right now
<lifeless> sabdfl: when you break-lock, does it error ?
<sabdfl> no, it asks me twice, i say y both times
<sabdfl> the next operation says it can't get the lock
<sabdfl> rinse and repeat
<Peng> lifeless: If they're a different branch format, why does it just mention the repository format in the error, then? It gives me the impression that it only checked the repository and not the branch or working tree.
<sabdfl> i have a flaky connection from here (:-)) and had to ^C a push earlier
<sabdfl> btw, what's /var/lib/misc/passwd.db and why does bzr try to access it?
<Peng> sabdfl: Google says "[PAM] [c]aches name service directories (passwd and group) locally in /var/lib/misc/passwd.db and /var/lib/misc/group.db."
<Peng> Hmm. I guess it's just a UI issue with the error message.
<lifeless> sabdfl: getent
<lifeless> sabdfl: I would guess that is.
<lifeless> sabdfl: please break-lock, and don't do anything else. Tell me when you've done so.
<sabdfl> locally on the machine, or remotely?
<lifeless> give bzr the remote url
<lifeless> as in, do what you have been doing so far
<sabdfl> i did it locally
<alla> lifeless: My desire is to be able to merge in multiple non-sequential changesets that are functionally related. The changes will conflict when running the second merge with --force.
<lifeless> alla: it will only conflict if it would have conflicted in a single command
<AfC> Has anyone else observed `bzr serve` instances leaving connections in CLOSE_WAIT for a *long* time?
<alla> lifeless: ok maybe I didn't test it right.
<lifeless> AfC: I don't think so; jml is son leave and he'd know for sure from the supermirror
<AfC> lifeless: want a bug report for the observation? I only noticed because (obviously) we get low traffic and it's really obvious...
<lifeless> AfC: please
<AfC> Launchpad is borked. I'll try to do it later.
<lifeless> AfC: thanks
<lifeless> AfC: borked how ?
<AfC> +filebug reporting error page
<alla> Is this a bug?: If the revision that you specify to merge, occurs after the point of divergence then the actual changesets seem to get lost. For example:
<alla> Say you had two branches that diverged at revision 300. Then both branches had another say ten different commits added to them both.
<alla> If I'm in one branch and I run: `bzr merge ../otherbranch -r 305..306`, then run `bzr status`, it does _not_ report that there are pending merges awaiting commit.
<alla> Whereas if I had run the merge command from the point of divergance: `bzr merge ../otherbranch -r 300..306`,then `bzr status` reports pending merges. bzr ver 0.92.0
<igc> bbiab
<lifeless> alla: this is documented I believe on our cherrypicking web page.
<lifeless> alla: basically, we allow you to *do* cherrypicks, but not to *record* them. We will be fixing this in the future, hopefully shortly after correcting our network performance.
<Peng> How is network performance going to be improved. I mean, what are you planning to do?
<lifeless> two main things
<lifeless> streaming push and pull fine tuning
<lifeless> in hpss, this is largely there but not all the way
<floam> the network performance seems not too bad to me anymore, with the newest type of storage
<lifeless> secondly, the negotiation to decide what is being pushed/pulled will be tuned
<floam> worst part for me is waiting for SSH to connect
<lifeless> reduce round trips
<lifeless> send relevant data, that sort of thing
<floam> and then a second time, to update. takes 3-4 seconds usually just to establish a connection typically
<alla> lifeless: Ok cool. Thanks for the info.
<ubotu> New bug: #164288 in bzr "bzr serve leaves connections in CLOSE_WAIT a *long* time" [Undecided,New] https://launchpad.net/bugs/164288
<Peng> Yuck. Pushing a 1.6 KB pack on a 100 KB repo took like 20 seconds. Whee round-trips.
<vila> can someone confirms that james_w here is james westby in RL, I want to get in touch with him
<dato> vila: yes
<vila> dato: thanks
<lifeless> Peng: interesting; we try to optimise out round trips by reading 64KB at a time; did something else happen? how many packs do you have in the repo? was there a progress bar and what did it say was happening ?
 * lifeless sleeps
<Peng> lifeless: There were about 4 remote packs, the largest 20 KB and the rest about 2.
<Peng> lifeless: Several more local packs from things I've uncommitted.
<Peng> lifeless: No progress bar.
<theSoftMan> hello :-)
<theSoftMan> there is somebody ?
<theSoftMan> how does it work ?
<theSoftMan> hello
<theSoftMan> fgsd
<dato> theSoftMan: just ask your question, and if somebody who knows the answer is around, they will answer you.
<theSoftMan> ok thanks ( it's the first time i use an irc chat )
<theSoftMan> my question is :
<theSoftMan> what GUI can i use for bazaar on windows system ?
<theSoftMan> what's the most user friendly ?
<theSoftMan> like the winCVS program then i use actually.
<mwhudson> theSoftMan: i hear that QBzr is ok
<mwhudson> (don't use a gui for bazaar or windows myself, so take this with a pinch of salt)
 * mwhudson files bug 164324
<ubotu> Launchpad bug 164324 in bzr "pushing to non-ascii url breaks both with bzr+ssh and sftp" [Undecided,New] https://launchpad.net/bugs/164324
<ubotu> New bug: #164324 in bzr "pushing to non-ascii url breaks both with bzr+ssh and sftp" [Undecided,New] https://launchpad.net/bugs/164324
<theSoftMan> thanks for answering... i see the last version was released on november 2007, i try it immediatly
<Peng> Bazaar has pretty frequent releases.
<Peng> Usually just about monthly.
<jelmer> hey schierbeck
<schierbeck> hi jelmer :)
<schierbeck> jelmer, am i the only one who thinks that the development of bzr-gtk has come to an abrupt halt?
<schierbeck> it's been more than a week since the last new revision in trunk, despite there being so much work to do...
<jelmer> nope :-) I'm busy with some other things at the moment, don't have time to look into bzr-gtk
<schierbeck> jelmer: what about phanatic?
<jelmer> the same appears to be the case for Szilveszter
<jelmer> do you have some open merge requests?
<jelmer> abentley: ping
<schierbeck> well, the menubar branch for starters
<schierbeck> it contains a lot of improvements
<schierbeck> and i have other branches based on that
<schierbeck> but i never seemed to get a definitive answer on whether it was approved or not
<jelmer> schierbeck: Can you bring it up on the mailing list again?
<jelmer> I'll see if I can get bundlebuggy for bzr-gtk back up
<panosl> New bzr user switching from svn. Single developer on multiple machines.On svn I stored the main repository on a server and did checkouts. Can the same accomplished with bzr's shared repository, but without losing the ease of local branching?
<Lo-lan-do> Hi all
<Lo-lan-do> For once, I'm not coming to report a bug :-)
<schierbeck> jelmer: okay
<jelmer> hey Lo-lan-do
<jelmer> hi panosl
<Lo-lan-do> I'm looking for insights about rebasing.
<Lo-lan-do> If I rebase a branch of mine, and some people have branched off it, will then encounter problems?
<jelmer> panosl: If I understand you correctly, yes.
<jelmer> Lo-lan-do, bzr will consider your branch to have diverged
<jelmer> so they'll have to "bzr pull --overwrite"
<Lo-lan-do> jelmer: Hm.  And if they did commits on their branch, they'll have to rebase too, right?
<jelmer> yes
<Lo-lan-do> Okay.  I'll probably reserve my rebasing to local, temporary branches then.
<Lo-lan-do> Thanks!
<Lo-lan-do> Also, I need to thank you again for bzr-svn: I haven't had a problem with if for weeks :-)
<jelmer> cool, that's great to hear :-)
<panosl> jelmer: a project has already branched. If I want to move that a shared repository, can I do so without it having prior knowledge that is was branched? Since i will do a checkout from each machine after that point.
<Lo-lan-do> Although the setup isn't quite simple: I work in lightweight checkouts of branches stored in a shared repo, one of which is bound to the upstream SVN repo
<Lo-lan-do> But "cd ~/debian/gforge-trunk ; bzr pull ../gforge-sid" does exactly the right thing, and that's very very nice.
<jelmer> panosl: Shared repositories are just a storage optimization - they don't change what you can or can't do with a branch
<Lo-lan-do> Ah, question: is there a way to have "bzr missing" use --line by default?
<jelmer> Lo-lan-do, you can define a new alias
<jelmer> something like "[ALIASES]\nmissing=missing --line\n" in ~/.bazaar/bazaar.conf
<jelmer> schierbeck: also, garyvdm seems to have disappeared :-/
<Lo-lan-do> Yay :-)
<scorpioxy> Hey guys. I have a general question regarding some source code from bzr. For communication over ssh, If i launch it with serve --inetd, it uses pipes exclusively right? Otherwise, it opens up a socket for its communication. Is that correct?
<jam-laptop> lifeless, sabdfl: I'm pretty sure I know what is happening. You are trying to push over bzr+ssh to a locked location. This starts a bzr process, which starts attempting a lock. You ^C and run break-lock, which breaks the original lock
<jam-laptop> but the process is still there
<jam-laptop> and sees that now it can grab the lock
<jam-laptop> and then immediately stops
<jam-laptop> so you actually need to "bzr break-lock" 2 times
<jam-laptop> once to clean up the really stale lock
<jam-laptop> and a second after the process you spawned realizes it
<Peng> Does this have to do with pushing packs over bzr+ssh?
<jam-laptop> the process would clean itself p after about 5 minutes
<jam-laptop> Peng: no, pushing knits
<jam-laptop> Peng: the bug with packs is something else entirely
<Peng> Okay.
<jam-laptop> though if we fixed the current pack problem
<jam-laptop> we would then run into this as well
<Peng> Nice.
<jam-laptop> with the caveat that packs don't need to hold the lock as long
<jam-laptop> so it would be harder to trigger
<Peng> Oh. So it's not like you knock down one brick wall and run straight into another. It isn't always triggered.
<jam-laptop> Peng: correct
<jam-laptop> this only happens if you try to push to a branch which is already locked
<jam-laptop> it then takes 5 minutes
<jam-laptop> or 2 break-lock commands to clean it up
<jam-laptop> (5 minutes + 1 break-lock, or 2 break-locks)
<elmo> Committing revision 4 to "/etc/".
<elmo> modified postfix/main.cf
<elmo> Committed revision 4.
<elmo> when did bzr become that verbose?  and is it staying that way?
<Odd_Bloke> elmo: Which part are you talking about?  The location line, or the status line(s)?
<Odd_Bloke> (Or both)
<elmo> Odd_Bloke: it's till me twice it's committing/committed to revision 4.  I suppose I'm mostly talking about the first line, which is new (to me and/or 0.92)
<Odd_Bloke> It's reasonably new, though I can't remember exactly which version it was introduced in (as I tend to track bzr.dev).
<Peng> 0.92, I think. Maybe 0.91.
<ubotu> New bug: #164370 in bzr-eclipse "first 5 lines are missing from old version in diffview" [Undecided,New] https://launchpad.net/bugs/164370
<scorpioxy_> Hey guys. I have a general question regarding some source code from bzr. For communication over ssh, If i launch it with serve --inetd, it uses pipes exclusively right? Otherwise, it opens up a socket for its communication. Is that correct?
<mwhudson> yay for running "bzr selftest" instead of "./bzr selftest"
 * mwhudson reads abentley's latest mail with interest
<mwhudson> abentley: interesting how the TransformPreview tests you sent me fail with "AttributeError: 'PreviewTree' object has no attribute 'inventory'"
<mwhudson> abentley: thanks a lot for that mail, by the way
<jelmer> abentley: have there been schema upgrades for bundlebuggy recently?
<jelmer> abentley: I'm getting the following error:
<jelmer>     raise exceptions.InvalidRequestError("This SchemaItem is not connected to any Engine or Connection.")
<jelmer> sqlalchemy.exceptions.InvalidRequestError: This SchemaItem is not connected to any Engine or Connection.
 * jelmer isn't quite teh turbogears guru
<Peng> Oh, BB is TurboGears too?
<jelmer> yup
<lifeless> Peng: interesting
<Peng> What is? Slow pushing?
<Peng> Hmm. "bzr send -o foo" == "bzr bundle >foo"?
 * Peng has fun with locations.conf.
<schierbeck> jelmer: have you looked at the signing features of bzr?
<jelmer> schierbeck: yes
<schierbeck> i'm trying to implement a ui for it, but it seems i'm only able to get the raw signature text
<schierbeck> it'd be nice with some helper methods...
<schierbeck> like signature_is_valid()
<schierbeck> are such helpers planned?
<jelmer> they are planned, but nobody has worked on them yet
<lifeless> hi coffeedude
<jelmer> I think there should be a spec or two up on launchpad
<lifeless> all hands was frenetic, I haven't fixed that bug yet sorry.
<schierbeck> jelmer: darned!
<lifeless> schierbeck: Would love it if you worked on validation
<schierbeck> lifeless: i've been looking at PyMe, which is mentioned on the bzr wiki, but it seems overly complicated
<lifeless> there may be better bindings now
<lifeless> I think jamesh wrote something
<schierbeck> perhaps i should ask him, then
<jelmer> schierbeck, https://blueprints.edge.launchpad.net/bzr/+spec/bzr-gpg-keysigning
<schierbeck> i can't seem to find any good bindings
<schierbeck> :)
<lifeless> options
<lifeless> http://py-gnupg.sourceforge.net/
<lifeless> http://www.amk.ca/python/code/gpg
<jelmer> I looked at one for pqm that was quite nice
<jelmer> can't remember the name though
<schierbeck> i've looked at both solutions, but neither seem perfect
<lifeless> pyme
<lifeless> and obviously :)
<coffeedude> lifeless: hey.  Busy channels today.  Didn't see you pop up.
<schierbeck> http://www.amk.ca/files/python/GPG.txt seems promising
<schierbeck> at least it's simple
<schierbeck> i think i'll hook it up directly with the ui -- if it works well, i'll send in a patch to bzr
<woei> Is this error known, or is there something wedged in my python setup ? http://pastebin.com/m7f87cd35
<jelmer> woei: That's definitely a bug, one way or another
<jelmer> are you sure revision 1 contains that particular file?
<woei> I've also had python core dump when using bzr gannotate, so I suspect it's not completely bzr's fault: http://pastebin.com/m6ceb218f
<woei> jelmer: when doing bzr -ci, it said 'added bar/baz\nCommitted revision 1.' So I'd reckon it should be there
<jelmer> the identity of the file has changed though
<lifeless> coffeedude: :)
<jelmer> I guess this is why the svn folks have "peg_revision"
<jelmer> woei: the file bar/baz in r1 is not the same file as bar/baz in r3
<jelmer> bazaar tries to find revision 1 of the file bar/baz in r3
<woei> jelmer: you mean you can't delete a file, add it (or another file with the same name) later and then get back at the contents of the first file ?
<lifeless> woei: you totally can
<lifeless> jelmer: thats an internal error, not NoSuchFile
<jelmer> lifeless: yes, I think the bug is that the error is unclear
<jelmer> lifeless: it shouldn't mention the file ids
<lifeless> jelmer: and look at the inventory
<lifeless> baz', parent_id='bar-20071121194931-1hkhbeykywwxmvhz-1',
<lifeless> bar', parent_id='TREE_ROOT'
<lifeless> bar/baz is there
<lifeless> jelmer: users won't see that error
<lifeless> this is something different
<jelmer> hmmok
<lifeless> jelmer: though I *may* be wrong
<lifeless> jelmer: we normally search out for all file ids in all the trees given
<woei> would the trackback in ~/.bzr.log be of any help ?
<lifeless> woei: looking still more closely; "baz-20071121195029-sf17yppaiamx4ul0-1" != 'baz-20071121194944-ypbqg5bh6okxs8fc-1'
<lifeless> woei: so jelmer's initial comment is probably the right answer; this is a genuine bug
<lifeless> woei: could you please file a bug
<lifeless> woei: that pastebin is enough
<woei> trackback: http://pastebin.com/m797641e5
<woei> ok, I'll file a bug on launchpad
<schierbeck> jelmer: okay, i've got a working implementation
<schierbeck> http://bazaar.launchpad.net/~dasch/bzr-gtk/signatures
<schierbeck> lifeless: would this be a start?
<jelmer> schierbeck: I think this is a start
<jelmer> schierbeck: but it would be nice if you could also show the key id
<jelmer> trust level, etc
<schierbeck> i'm thinking that we could add a more comprehensive description below the first paragraph
<schierbeck> jelmer: yeah, i'll look into it
<jelmer> I can now create a key with uid that matches your email address
<jelmer> and it will the revision has a signature
<lifeless> there are two key things to validating signatures
<lifeless> 1) is the signer the author
<lifeless>   - you want a trust level from gpg that is high enough to assert this. baz has all the code to do this, written for gpgme.
<lifeless> 2) is the author authorised to push code to that branch
<jelmer> we already discussed a little bit of this on the bzr-gtk list
<jelmer> going for just (1) first would be the easiest thing to do, and all the required things for that are already present in bzr core
<lifeless>   - this requires mapping identity to policy; doesn't really apply when checking revisions you are merging from etc, its mainly a policy thing for fetch, but it could be expanded etc
<lifeless> yes, agreed
<jelmer> (except for some utility functions for checking signatures, etc)
<schierbeck> jelmer: this is by no means ready for the public -- i'm incrementally making it secure
<schierbeck> jelmer, lifeless: could i get you guys to sign your future commits to bzr and bzr-gtk?
<jelmer> schierbeck, do you know 'bzr sign-my-commits' ?
<schierbeck> jelmer, i do, but i would like other signatures, besides my own
<schierbeck> and i'm too lazy to set up a test branch with 'fake' signatures
<jelmer> schierbeck, If you need an example, bzr-svn has most revisions signed
<ubotu> New bug: #164395 in bzr "Unclear error message instead of NoSuchFile" [Undecided,New] https://launchpad.net/bugs/164395
<schierbeck> i'd like to have some test data when making the ui
<schierbeck> jelmer: great
<lifeless> schierbeck: most of mine should be signed already
<jelmer> I think I've signed most of my revisions for bzr-gtk
<lifeless> and all pqm's should be signed
<jelmer> but there's no way to push signatures atm afaik
<schierbeck> lifeless: did you say that bzr already had support for some of these things?
<lifeless> hmm ?
<jelmer> schierbeck: no, baz - the previous incarnation of bazaar
<schierbeck> shoot
<schierbeck> can it be easily ported?
<lifeless> its in C
<lifeless> and it uses gpgme
<lifeless> but it might be useful for inspiration, or not.
<schierbeck> lifeless: well, there is PyMe, although i haven't quite figured out how to use it for our purposes
<schierbeck> the implementation i added seems to work pretty well -- we could customize it for bzr
<schierbeck> that is, the one from http://www.amk.ca/files/python/GPG.txt
<lifeless> I'm not trying to tell you how to do it
<lifeless> I was just letting you know what prior art I know of
<schierbeck> i don't mind inspiration at all :)
<schierbeck> i haven't used gpg much, so some things are not obvious to me
<komputes> is anyone able to do http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
<komputes> i tried the tutorial but ran  into a few errors
<lifeless> komputes: could you pastebin them somewhere ?
<komputes> will do
<schierbeck> does any of you guys know how to deal with custom icons in the application?
<schierbeck> i guess they need to be installed in a special place and stuff
<schierbeck> *do
<komputes> lifeless, http://pastebin.com/m15942a13
<Jug> what is the recommend way of setting up the bzr server? using the dedicated ot bzr over ssh?
<lifeless> bzr+ssh is the most secure
<lifeless> komputes: ah!
<lifeless> komputes: so, do you have an sftp account at gmail.com
<lifeless> ?
<lifeless> komputes: you need an sftp server running and an account on it, to push to sftp somewhere.
<arjenAU> Jug: ssh works well for me.
<lifeless> its also the simplest.
<komputes> lifeless, tutorial on that?
<komputes> i dunno does gmail do sftop?
<komputes> sftp
<komputes> do i need an acct for ssh?
<radix> no, gmail does not do sftp :)
<lifeless> komputes: well you need a server to push to; if you don't have one already you can use a free hosting service like launchpad
<lifeless> morning poolie
<poolie> hello
<poolie> is it still the case that we don't have dapper debs?
<lifeless> yes
<lifeless> we have no bananas
<ubotu> New bug: #164423 in bzr "test_fetch should be per-inter-repo" [High,Triaged] https://launchpad.net/bugs/164423
<pygi> yo
<igc> morning
<poolie> hi
<igc> hi poolie
<pygi> poolie is here! Long time no see :)
<poolie> hello
<poolie> i was on holiday last week, and at UDS and the canonical conference before that
<lifeless> I'm in
<igc> me to
<pygi> :)
<abentley> lifeless: plenty of us are bananas :-)
<abentley> mwhudson: Yes, you correctly guessed what got me started on the diff update.  It would be nice if PreviewTree didn't need an inventory at all.
<schierbeck> hi guys
<schierbeck> has anyone here played with the visual studio integration?
<Acro> LarstiQ> You there?
#bzr 2007-11-22
<mwhudson> abentley: so previewtree will still need an inventory at some point without more diff refactoring?
<abentley> No, I mean I hope that PreviewTree won't need an inventory, but until it's finished, we can't be sure.
<lifeless> abentley: so, my diff suggestion, do you think its baked enough ?
<abentley> Yeah.  The main thing it's silent on is how to handle kind changes, but I've got my own ideas.
<lifeless> abentley: oh, hmm kind isn't in the signature is it?
<abentley> Well, I was going to put it there anyhow.
<lifeless> though if each Diff is contructed with the trees, at the start of TreeDiffer
<lifeless> you don't need to extend the signature; cross-kind diff could just be a wildcard at the end of the [Diff, Diff, Diff..] list
<mwhudson> abentley: fair enough
 * mwhudson goes to bed
<abentley> lifeless: Sure, but the larger issue for me is, what should CrossKindDiffer do?
<abentley> My current idea is that it represents it as an add + delete, and uses the existing list of differs to do it.
<lifeless> oh, in the UI ?
<abentley> Well, the output.
<abentley> So if you change a symlink to a file, it shows deletion of a symlink, and a unified diff that adds a file.
<lifeless> so here's a corner case
<lifeless> wjhat about subtree -> directory
<lifeless> (with the same contents under both)
<lifeless> but other than that I think it makes sense as you propose; presumably just call diff twice, once as a delete once as an add
<abentley> I think the nested-trees code hides tree references from diffs, and presents the referenced directory instead.
<lifeless> k
<abentley> There's room for improvement, but that's good enough for nested-trees to go beta.
<mtaylor> statik: have you actually started programming in erlang? or are you just interested in it?
<ubotu> New bug: #164436 in bzr "permissions tests need to be parameterised too" [Medium,Triaged] https://launchpad.net/bugs/164436
<poolie> lifeless, hi,
<lifeless> poolie: oh, had you pung before I rung ?
<lifeless> mtaylor: erlang is quite nice
<jelmer> that would be the ultimate tool
<jelmer> a distributed vcs that can run distributed
<Odd_Bloke> :D
<jelmer> ah well, g'night
<schierbeck> good night :)
<warren> hmm, somebody sent me a .patch file that is a bzr bundle
<warren> I haven't merged this kind of thing before
<warren> any pointer to docs of how to do this?
<warren> (can I merge it into my tree keeping his metadata?)
<Odd_Bloke> warren: You can, by and large, treat the file as a branch. (i.e. bzr pull bundle.patch, bzr merge bundle.patch)
<warren> Odd_Bloke, ah
<warren> Odd_Bloke, for future reference how do I create this kind of bundle myself?
<Odd_Bloke> warren: 'bzr send' is the command you want to look at.  To create the file, use 'bzr send -o bundle.patch'.
<Odd_Bloke> There are craftier ways to use it, but I haven't fully plumbed their depths.
<poolie> (lunch)
<abentley> warren: what platform are you on?
<warren> abentley, Fedora
<abentley> if you have xdg-utils installed, bzr send will automatically launch your preferred mail client, with the bundle as an attachment and everything.
<warren> cool
<poolie> ** launchpad is down for maintenance - upgrade to the next version
<pygi> poolie: in this time of night ... :)
<poolie> i mean, for an upgrade to the next version
<poolie> it's midday here...
<poolie> i think it's designed to correspond with the lowest daily usage - US and EU nighttime
<abentley> poolie: It's okay.  I'm amazed you aussies can stand on your heads all day...
<lifeless> poolie: patch mailed
<lifeless> poolie: its not 'done', but this is a reasonable snapshot of progress; I think the vast ermaining bulk is the smart server verb
<floam> Is it possible for me to have one file in my repository that sort of mirrors some single file from someone elses repository of a completely separate project?
<poolie> floam, sorry, no
<poolie> well,
<poolie> what i suggest you do is make it a symlink to a file in a checkout of their project
<lifeless> poolie: you can set up a branch with that one file merged, and other files will just conflict / could do partial merges all the time
<poolie> that too
<poolie> reading your patch
<lifeless> thanks
<lifeless> I'm folding now
<abentley> floam: btw, what you're calling a "repository" we call a "working tree".
<floam> abentley: sorry, I've used cvs/svn up until three months ago
<abentley> We use "repository" more in the CVS sense.
<floam> I assume the heart in the right place with the nomenclature wrong is better than the other way around :)
<abentley> Sure.
<poolie> folding?
<mtaylor> lifeless: I've been looking at an erlang project, but I'm looking around for motivation to actually learn erlang :)
<mtaylor> lifeless: do you know anything about extending erlang with c libraries? (like if I already had one and wanted to wrap it)
<abentley> lifeless: ping
<ubotu> New bug: #164443 in bzr "can't branch bzr.dev from codehost over bzr+ssh" [Critical,Confirmed] https://launchpad.net/bugs/164443
<ubotu> New bug: #164447 in bzr "bzrlib.info.describe_format should be a BzrDirFormat method." [Medium,Triaged] https://launchpad.net/bugs/164447
<ubotu> New bug: #164450 in bzr "should show a message when pushing(overwriting?) tags" [Low,Confirmed] https://launchpad.net/bugs/164450
<ubotu> New bug: #164453 in bzr "bzr using way too much memory for large file fetch" [Undecided,New] https://launchpad.net/bugs/164453
<lifeless> abentley: pong
<lifeless> abentley: I'm guessing you are asleep at this point, but if it was re Differ's, I've replied - I think it's looking good.
<poolie> thumper, ping?
<thumper> poolie: pong
<poolie> thumper, do you want to come to this call?
<thumper> whose number?
<poolie> conference centre?
<thumper> I'm there
<LarstiQ> Acro: I wasn't, and I'm going to class now again, but leave a message and I'll try to get back to you
<ubotu> New bug: #164466 in bzr "rename packs from knitpack-experimental " [Undecided,New] https://launchpad.net/bugs/164466
<AfC> Eeek!
<AfC> I punched up http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk and it says "Not Found The requested URL /00/00/05/32 was not found on this server."
<mwhudson> yes, that sucks
<fullermd> That'll teach ya.
<AfC> fullermd: :)
<lifeless> mwhudson: whats the problem? missing / ?
<mwhudson> lifeless: yeah, you get internally redirected to a url that you can't access, or something
<lifeless> mwhudson: that should be trivial to fix;
<lifeless> ... pretty please?
<mwhudson> lifeless: it's an apache config issue, and i really don't know much about that
<mwhudson> lifeless: file an RT?
<theSoftMan> Hello, is Qbzr a complete GUI for bzr ? giving the possibility of add, commit, create branch,... ?
<theSoftMan> and other question is : how to lauch it ?
<lifeless> mwhudson: you need a redirect that matches the non/ - ...$ -> .../
<lifeless> mwhudson: its maintained by the lp-bzr folk as part of the codehosting config
<lifeless> theSoftMan: I'm sorry, I haven't used it myself, but yes I understand it to allow those operations
<mwhudson> lifeless: so redirect ~blah/blah/blah to ~/blah/blah/blah/ before considering anything else?
<AfC> mwhudson: yes
<ubotu> New bug: #164476 in bzr "packs should be the default format" [Undecided,New] https://launchpad.net/bugs/164476
<theSoftMan> lifeless : i have made the installation on my windows system but i can launch it ? ( thanks for you previous answer )
<VSpike> hi folks - quick question probably.  I tried my first merge (woo!) and it was OK except while resolving some conflicts i had the case where the working tree had deleted the files and the merge source had made changes since the base ...
<VSpike> except that I didn't understand what it was trying to tell me and so marked them as resolved because i knew the files had been deleted
<VSpike> How can I get the .BASE and .OTHER files back for those items (I can remember which files they were), or how can I check the changes in the merge source against the base that was chosen, given that I don't know what the base chosen was?
<fullermd> Maybe something with remerge?
<VSpike> fullermd: I was wondering that too, but didn't want to try it without knowing what it might do :)
<VSpike> I'm doing it manually and learning how bzr diff and bzr log work properly, so it's all good
<fullermd> Well, it's unlikely to make demons fly out of your nose  ;)
<VSpike> au contraire :)
<VSpike> he
 * Peng strangles bzr.
<fullermd> Ack!  You squeeze all the vowels out!
 * Peng strangles rubygems too.
<Peng> I renamed foo/ to bar/. Bzr thinks everything in foo was removed and everything in bar is unknown. :(
<fullermd> Isn't that what you'd expect?
<Peng> Noo.
<Peng> The directory was renamed.
<dato> but how would bzr know?
<Peng> As in 'bzr mv'.
<fullermd> Well, yeah.  But if you didn't tell bzr about it...
<Peng> Yes I did.
<dato> on, `bzr mv`?
 * fullermd blinks.
<Peng> Well, it wasn't done by 'bzr mv'
<Peng> But I ran 'bzr mv' afterwards, and it does know about the rename.
<Peng> I think I give up.
<dato> maybe you wanted `bzr mv --after`?
<Peng> dato: I might've done that.
<LeoNerd> Or just manually mv it back, then bzr mv it again
<fullermd> Did you have the trailing slash on bar?
<LeoNerd> "mv foo bar" oh oops I forgot; "mv bar foo; bzr mv foo bar"
<fullermd> Yah.  That can be simpler when you're dealing with dirs.
<Peng> @_@
<Peng> Okay, I give up.
<Peng> How do I bzr rm a directory that I've already rm -rfed?
<dato> bzr will mark it as deleted automaticcally
<fullermd> I don't think you have to...
<Peng> Oh, that's right. I forgot.
<Peng> Hmm.
<Peng> I think something else is screwy.
<fullermd> This would be the week for it.
<Peng> Oh, never mind. The something else was user error.
<Peng> Forgot I was in a different directory.
<Peng> Hmm.
<Peng> Part of this whole mess was probably user error because of that. Not all of it, though.
<TeTeT> how to remove the changes of a specific revision? I'd like to get rid of rev 83, but this doesn't work: bzr merge . --r-83..-84
<dato> bzr merge -r 83..82
<TeTeT> says nothing to do
<TeTeT> dato: ah, thx, made a mistake!
<TeTeT> dato: I tried 83..84 ...
<gioele> hello
<gioele> is it dangerous to have a directory /a managed as a tree by bzr and another directory /a/b/c managed as another tree by bzr?
<gioele> (/a/b/c would be on the ignore list of /a)
<Peng> I don't think it's dangerous.
<james_w> gioele: no that's fine.
<gioele> thanks for the info
<TeTeT> i'm currently pushing a 93MB branch to LP, it's running since once hour and I don't see much progress, still at Fetch phase 0/4
<TeTeT> how can I check if anything is still happening?
<james_w> TeTeT: ~/.bzr.log might have something
<TeTeT> james_w: states 'fetch up to rev {spindler@...}'
<TeTeT> james_w: and before that 'Using fetch logic to copy between KnitRepository(....)'
<james_w> I thought it might say what it was doing as it worked, but it doesn't.
<TeTeT> james_w: just finished :)
<james_w> \o/
<james_w> TeTeT: did you ever get bzr-builddeb working for you?
<TeTeT> james_w: I honestly haven't tried, the packages I patched were not in bazaar anywhere
<TeTeT> james_w: but I'll give it a whirl on a package for training I'm supposed to do
<james_w> that's cool. I was being pretty useless trying to help you anyway, so I can't blame you.
<TeTeT> you were most helpful, it just took a while to figure out where the problem was
<james_w> well, if you need any help you know where to find me.
<TeTeT> thanks for the offer :)
<lifeless> 'lo
<james_w> hi lifeless
<woei> hmm, I've merged a branch, it added some revisions, great. How do I get the log message and the diff of the new (but not yet committed) revisions in chronological order ?. Something like svn log|diff -rBASE:HEAD.
<james_w> woei: if I understand what you mean 'bzr diff' should give you the diff. 'bzr status' will show a summary of each merged revision.
<james_w> If you want the full log then that is a bit harder, one easy way that might not work would be 'bzr missing --theirs-only .../otherbranch'
<dato> .oO( bzr commit; poke; bzr uncommit ;)
<james_w> There will be a way to get the log with the log command, but my brain fails me once again.
<woei> I'm looking for something like gitk, where you can see the log and the diff of what happened at each commit
<woei> bzr diff does give me the diff, but it gives me the diff of all the revisions I just merged
<woei> when getting revision 3, 4, 5, I'd like to see the log of rev.3, the patch of rev.3, the log of rev.4, patch of rev.4, etc.
<dato> woei: after you've committed the merge, it's easy to do that with bzr log and bzr diff, or visually with `bzr viz` (from bzr-gtk)
<gioele> woei: maybe you're looking for bzr gtk (olive)
<dato> woei: without committing the merge, I don't think you can, at least I wouldn't know how.
<woei> ok, so I'd branch a working copy, merge from upstream, use a graphical tool to go over each patch, and then merge that pulled branch back to the real working copy
<james_w> woei: that would work.
<james_w> woei: there is a bug to allow you to access the merged revisions, but no-one has worked on it yet.
<woei> hmm, and is there an easy way to refer to the revision prior to the last merge ? So bzr log and bzr diff only shows that interval ?
<james_w> also bzr-gtk doesn't deal with merged in stuff at all.
<james_w> woei: the last merge in which direction?
<woei> the stuff I pulled from upstream
<woei> and then committed
<woei> prior to merging it back to the real working area
<james_w> so you want to see the stuff that you did in your branch since the last time you merged from the other branch?
<woei> after committing, bzr log does show the new revisions indented, but how do I tell it to show only those revisions with bzr log ?
<dato> woei: try bzr log -r -1
<dato> it will show them still indented, but *only* them. if I understood correctly.
<woei> no, I made a branch to merge in changes from upstream. I did a bzr merge. I'd like to see the log and patch for each commit. That's not possible (yet) on the command line. Okay, so I commit that merge (from upstream). How can I get just the log (and diff) from the point where I branched from my working copy (to receive new revisions from upstream), and the head of what's in the (now synchronized) branch ?
<woei> dato: excellent, bzr log -r -1 does just that
<woei> but bzr diff -r -1 does not
<dato> for the diff, bzr diff -c -1 will give you the whole diff
<AmanicA> or bzr diff -r -2..-1
<woei> dato: ok, great
<james_w> woei: bzr-gtk will now be able to give you diff for each commit. For the command line you can use bzr diff -c x.y or bzr diff -c revid:xxx
<woei> ok, I'm starting to get the picture on why I needed to commit
<dato> woei: also, it's not strictly necessary that you make a separate branch and merge there; you could merge in your branch, commit, and if for some reason you don't like the result, do `bzr uncommit`
<woei> and that extra branch to receive new revisions is not really needed, if you use bzr commit; bzr viz; bzr uncommit
<woei> dato: exactly :)
<dato> :)
<woei> ok, thanks all for pointers
<ubotu> New bug: #164567 in bzr "FTP push does not work without specifying password" [Undecided,New] https://launchpad.net/bugs/164567
<jelmer> abentley: ping
<jelmer> odd, I seem to be missing emails on bazaar@lists.canonical.com :-(
<keir> is there a way use a GUI of some sort to go through a diff, and accept or reject chunks?
<lifeless> keir: at commit time ?
<keir> so, what i have done, is checked in an external library into my tree, and made several changes
<keir> but now upstream has moved forward
<keir> so what i've done is just copied upstream over top of my working tree
<keir> when i do diff, my changes show up as -'d
<keir> i want to revert just those chunks, then check in the changes
<lifeless> do you know of 'bzr shelve' ?
<keir> i thought that is just for uncommitted changes?
<keir> in my case, i committed my changes ages ago
<lifeless> these are uncommitted changes :)
<lifeless> you have an uncommitted reversal of your change
<keir> oh, i see
<keir> now, the slight problem, is that these changes are close in proximity to mine
<lifeless> ok
<dato> keir: for some other time, why don't you apply the new version in a separate branch, and merge that?
<keir> so in multiple places, the hunks show up as a single hunk, with an add and a remove
<lifeless> heres a different and more scalable approach
<lifeless> branch -r <when you imported the code> upstream
<lifeless> cd upstream
<keir> ah yes, i see
<lifeless> unpack upstream stuff; bzr add; bzr commit
<lifeless> cd your-branch
<lifeless> bzr merge upstream
<keir> yes, ok.
<keir> wait, but i only want to merge the particular changes to the extern/ lib; not the other changes
<keir> so isn't this a cherry pick?
<lifeless> no
<lifeless> what other changes will be in that branch than those to lib from upstrea?
<keir> hmm
<keir> sorry, thinko, i got it
<keir> dist vc is so nice :)
<keir> i'm itching to implement the faster index layer... stupid RL
<lifeless> yah
<lifeless> same
<lifeless> :)
<keir> an aside: why is it that bzr 'detects' deletions?
<lifeless> there is a bug
<keir> rather than svn's behaviour
<lifeless> it should be a flag like -A to automatically add and delete new paths
<lifeless> and by default error on deletes
<keir> yeah, i totally agree. though there is a case that it is the 'wrong' way to use a vc, i like in svn that if i do something silly, i can just delete and svn up
<keir> i know that's what revert is for
<keir> yet somehow i prefer delet and update
<lifeless> its really very strange for me that svn update restores files rather than preserving your changes - its inconsistent.
<keir> on a completely logical level, i agree
<keir> yet somehow, i feel like the vc is my 'barrier against stupidity'... if i go and delete stuff, without informing bzr, i probably didn't mean it
<AfC> And lord knows preserving the broken behaviour of previous generations of tools is not the primary goal around here
<fullermd> On the other hand, if I delete stuff, I do mean it...
<dato> fullermd: alias commit=commit -A ;)
<dato> (when that exists)
<fullermd> But just because a file exists, doesn't mean I want to add it.
<keir> fullermd, i feel the same way about deletes :)
<dato> yeah, I'm not sure why lifeless mentioned additions for commit -A
<keir> perhaps commit -D
<dato> yeah
<keir> or bzr delete --missing
<lifeless> A for automatic
<lifeless> commit --automatic
<keir> lifeless, but it may be the case that you want to delete missing files, but not add unversioned files
<lifeless> keir: so the question is
<lifeless> is it worth having two flags
<lifeless> the main use case for commit --automatic is automated scripts
<keir> lifeless, aah, i see
<lifeless> but bzr rm --missing/--gone etc is a good way to have the equivalent of 'bzr add'
<lifeless> OTOH why not have 'bzr rm' do what bzr add does :)
<lifeless> but in reverse - rm everything that is not here
<keir> lifeless, exactly, that's what i meant by bzr delete --missing. i guess there is no bzr delete. heh
<lifeless> abentley: patch reviewed
<keir> does bzr internally support a status which is 'file is missing from WT' without having the 'delete at commit' bit set?
<fullermd> I don't think the delete bit is set until commit runs.
<keir> so status just shows it as a pending delete?
<fullermd> Yah.  Put a file back on that name, and it'll just show up changed (or unchanged, if the file's the same).
<keir> but it would involve extending WT model to allow a new 'state' for deleted files which is missing, but not deleted?
<fullermd> You lost me...
<keir> i'm trying to think of how hard it is to implement the following:
<keir> 1) deleting a file in local repo does not mean it will be deleted at commit
<keir> 2) files which are to be deleted must be explicitcly bzr rm'd
<keir> 3) bzr st supports showing either explicitly deleted, or missing but not deleted, states
<keir> 4) bzr rm --missing does what you expect
<keir> i don't know anything about the WT's data model so that's why i'm asking these qns
<fullermd> I imagine 1/2 are just changes in commit, and 3 is just a change in status.  The file isn't _deleted_, as putting it back will show.  It just says it's deleted.
<keir> this would make rm consistent with add
<keir> would a patch to do this be rejected immediately because it changes behaviour?
<fullermd> Rejected?  Doubt it.  But it probably calls for a list discussion.
<keir> alrighty.
<lifeless> keir: 1) I would not like unless you mean 'will error at commit'; 2) would be good as long as there is an option for ocommit to get deletes back. 3) is already done I thought, 4) would be nice
<lifeless> I'd send an RFC, get some consensus, then patch
<lifeless> there is a bug already as I mentioned
<lifeless> abentley: ping, is there a inventory delta to iter_changes adapter around somewhere ?
<lifeless> abentley: I'd like to make bzr-email use the inventory delta generated by commit
<cbx33> hi guys
<cbx33> I've been happily push changes to my branch on LP
<keir> lifeless, ok. i'll probably wait.. realistically, if i'm going to do bzr hacking i should write the index layer
<cbx33> today I merged with someone, did some chages, pushed them successfuly, did some more changes....now I get an error that the branch has DIVERGED?
<cbx33> what is going on?
<cbx33> it suggests trying a merge then a push
<cbx33> but who do i merge with....my own older branch?
<cbx33> it doesnt make sense
<lifeless> cbx33: did you do the second set of changes in your branch ?
<cbx33> yes
<lifeless> what command gives you the error ?
<cbx33> bzr push
 * fullermd suggests checking 'missing'.
<cbx33> it committed fine
<lifeless> cbx33: as fullermd says, what does 'bzr missing URLYOUPUSHTO' do ?
<cbx33> i was missing a merge
<cbx33> with myself
<cbx33> ok fixed
<cbx33> but not sure why;)
<lifeless> did you push there from more than one place ?
<cbx33> hmmm
<cbx33> possibly
<cbx33> yes that may have been it
<cbx33> thanks lifeless
<igc> morning all
<lifeless> hi
<poolie> hi
<poolie> call in 2m?
<igc> yes
<poolie> lifeless, igc: ping
<abentley> lifeless: I don't think we have an adaptor like that.
<abentley> jelmer: pong
<lifeless> abentley: ok
#bzr 2007-11-23
<Odd_Bloke> If a bug has inadvertently been fixed since it was filed, should I mark it "Fix Released" or "Invalid"?
<jelmer> abentley: did anything change in bundlebuggy's storage format recently?
<jelmer> I'm getting schema errors now
<ubotu> New bug: #164613 in bzr "``bzr check`` cannot be run on a repository" [Undecided,New] https://launchpad.net/bugs/164613
<lifeless> orospakr: fixed, and the releasse it was fixed in as the tag
<lifeless> meh
<lifeless> Odd_Bloke: ^
<orospakr> heh.
<lifeless> sorry orospakr
<orospakr> YOU'VE RUINED MY LIFE
<lifeless> its true
<Odd_Bloke> Heh.
<lifeless> Odd_Bloke: bug 64783 is not fixed
<ubotu> Launchpad bug 64783 in bzr ""bzr check" returns unhelpful "No WorkingTree" error" [Medium,Fix released] https://launchpad.net/bugs/64783
<lifeless> Odd_Bloke: and I'm not working on it :)
<Odd_Bloke> lifeless: It's happy to check branches without a working tree (removing one of the instances of the error) and reports that there isn't a branch when run directly on a repository.  I've filed bug #164613 for the lack of repository checking.
<ubotu> Launchpad bug 164613 in bzr "``bzr check`` cannot be run on a repository" [Undecided,New] https://launchpad.net/bugs/164613
<Odd_Bloke> lifeless: And I assigned it to you as it was fixed (or so I thought :p) in one of your branches.
<lifeless> Odd_Bloke: well the initial bug report covers the repository case
<lifeless> so I think a new bug report is just noise
<lifeless> part of the initial report is corrected, but not all of it.
<Odd_Bloke> lifeless: Sure.  I've invalided bug #164613.  Apologies for taking your time.
<ubotu> Launchpad bug 164613 in bzr "``bzr check`` cannot be run on a repository (dup-of: 64783)" [Undecided,Invalid] https://launchpad.net/bugs/164613
<ubotu> Launchpad bug 64783 in bzr ""bzr check" returns unhelpful "No WorkingTree" error" [Medium,Triaged] https://launchpad.net/bugs/64783
<lifeless> Odd_Bloke: no problem, I appreciate you putting time into bug database management
<lifeless> its prompted me to cleanup bug 64783 to be more clear about what it really represents
<ubotu> Launchpad bug 64783 in bzr ""bzr check" does not handle our split up .bzr layout properly (Errors if there is no branch)" [Medium,Triaged] https://launchpad.net/bugs/64783
<poolie_> lifeless: text:tar_exporter.py-20051114235828-1f6349a2f090a5d0 corrupt: line-delta from stream references missing parent jaq@spacepants.org-20051229032631-adc1a9413791860f
 * igc lunch
<ubotu> New bug: #164626 in bzr "branching from hpss doesn't preserve repository format" [Undecided,New] https://launchpad.net/bugs/164626
<ubotu> New bug: #164628 in bzr "branching from hpss doesn't preserve repository format" [High,Confirmed] https://launchpad.net/bugs/164628
<abentley> jelmer: yes.  I replied to your email.
<abentley> Run the "migrate" script.
<lifeless> time for turkish
<somerville33> How do I clean a branch?
<somerville33> ie. remove all the uncommitted changes
<poolie_> somerville33, 'bzr revert'
<somerville33> I tried that
<somerville33> Does it get rid of "unknowns"?
<poolie_> no, it doesn't
<poolie_> you can use, on unix,
<poolie_> bzr ls --unknown |xargs rm -v
<poolie_> or install the bzrtools plugin, and use the 'clean-tree' command
<somerville33> What does this mean? bzr: ERROR: Generic bzr smart protocol error: <Fault 8002: 'error'>
<ubotu> New bug: #164637 in bzr "hpss data_stream from pack repository has deltas out of order, fails with KnitCorrupt exception" [Critical,Confirmed] https://launchpad.net/bugs/164637
<poolie_> somerville33, is that coming from launchpad?
<poolie_> somerville33, i'm not sure but i think it may mean the path is wrong
<poolie_> https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/145894
<ubotu> Launchpad bug 145894 in launchpad-bazaar ""Fault 8002" when pushing a branch to an unregistered project" [Medium,Fix released]
<ubotu> New bug: #164639 in bzr "rich-root format should use packs" [High,Confirmed] https://launchpad.net/bugs/164639
<jamesh> mwhudson was doing some work to improve the error handling to produce better error messages.  I think that is due for the next rollout
<jamesh> so hopefully it'll be live on Monday
<poolie_> yay
<jamesh> If it is pushing to a branch that does not exist, it should actually display "Product foo does not exist." to the user
<jamesh> s/branch/product/
<jamesh> garr - that should be "Project foo does not exist." :(
<acuster> Hey all, having trouble getting started with a repo setup. I have an svn checkout that i'd like to use within bzr
<acuster> i'm currently avoiding bzr-svn because it seems to require hitting the network
<acuster> I'd like to init-repo and then add trunk/
<acuster> if i do (1) init-repo (2) cp trunk . (3) init trunk/ I get two .bzr directories
<acuster> one in the repo and one in trunk/
<acuster> is that expected?
 * acuster tries without the repo
<fullermd> Yes, that's expected.
<fullermd> The top-level .bzr/ contains your repo, and the .bzr/ in trunk contains the branch and WT metafiles.
<acuster> thanks
<acuster> what do I branch and checkout from then, the repo or the branch?
<fullermd> The branch.
<fullermd> Repos are just used to share storage.  You don't refer to them directly (except when making them, of course).  You don't particularly need to use them, especially with only one branch (doesn't gain you anything until you have two with shared history)
<acuster> thanks
<igc> night all - have a good weekend
<dato> if I have a bug reported in Debian's BTS (Debian #452503), can I automatically import it into launchpad?
<ubotu> Debian bug 452503 in bzr "bzr: gets confused when editor is killed" [Minor,Open] http://bugs.debian.org/452503
<dato> or do I have to enter it by hand, and link them by hand as well?
<Kamping_Kaiser> iirc you have to file a new bug and link it
<acuster> The --trees/--no-trees command when making a shared repo only affects the behaviour of the bzr branch command?
<acuster> to get rid of a branch we merely rm -Rf it?
<acuster> what impact does that have on the shared repository?
<dato> its revision will stay, unaccessible
<acuster> no way to clean that up?
<dato> but there is no way to clean them up, at the moment
<acuster> thanks
<acuster> am I right that the 'trees' flag in shared repos only affects whether branch also checks out a working tree?
<dato> I believe so
<fullermd> It probably affects (and if it doesn't, it should) other stuff that makes a branch, like init and push.  I know push was fixed recently...
<acuster> wow bzr-svn is way faster now
 * bitmonk wonders if there area reasons bzr would be especially resistant to working on alternative python implementations..
<bitmonk> er s/area/are/
<jelmer> it doesn't rely on any C extensions to be able to work (though it will be faster if they're available)
<jelmer> so nothing I can think of immediately
<bitmonk> does it require setuptools?
<jelmer> no, it uses distutils
<bitmonk> hm.
<jelmer> what sort of things are usually problematic?
<bitmonk> well, my target is pypy on mono.
<bitmonk> you can't use setuptools or distutils on mono really.  it's a whole 'nother world.
<bitmonk> at least i can't quite fathom how to.  i'm sure it's possible, but it sure doesn't work today.
<jelmer> you should be able to use bzr out of the source directory
<bitmonk> yeah i imagine so..
<bitmonk> distutils and setuptools are just friendly helpers.
<bitmonk> well, thanks.  i will give it a shot next time i'm looking for fun ;d
<mwhudson> i doubt pypy-cli has gzip/bz2 support yet
<bitmonk> maybe run some benchmarks
<bitmonk> mwhudson: it may not.
<bitmonk> but i bet i could access gzip/bz2 support via the cli, even if with a penalty.
 * bitmonk is looking more for a 'fathomable project' than a 'working today solution'
<mwhudson> can't think of anything else that shouldn't work
<bitmonk> awesome
<bitmonk> i probably should spend some more time with bzr on cpython first, so that i know how to recognize odd behaviour ;d
<ubotu> New bug: #164714 in bzr-eclipse "Whitespace in directory name" [Undecided,New] https://launchpad.net/bugs/164714
<TeTeT> is there a way to reduce the disk footprint of a branch? The shared repository with the ubuntu-desktop-course branch occupies 720MB right now
<keir> so is 1.0 really going to be released next?
<chx> hi
<chx> I visited http://bazaar.launchpad.net/~vcs-imports/drupal/main and was surprised.
<chx> The requested URL /00/00/0a/af was not found on this server.
<chx> oh. i guess wrong channel. moving to #launchpad...
<ubotu> New bug: #62249 in bzr "merge from bundles should support io redirection" [Undecided,Incomplete] https://launchpad.net/bugs/62249
<ubotu> New bug: #62521 in bzr "bzr should run without bzrlib.tests installed." [Undecided,Incomplete] https://launchpad.net/bugs/62521
#bzr 2007-11-24
<elijah> How would I determine how much space the svn-bridge information takes under .bzr?
<elijah> (For a repository imported via bzr-svn.)
<lifeless> what do you mean 'svn-bridge' ?
<elijah> If I import with bzr-svn, I may want to later do an incremental update.
<elijah> Does bzr-svn store any information to make later updates easier?
<elijah> If so, how much space does such information take?
<elijah> (i.e. it's not fair to compare svn storage requirements to bzr storage requirements using bzr-svn on an existing svn repository if bzr-svn is storing extra information about bridging to an alien repository)
<elijah> From poking around under .bzr, it appears the answer is not much, if anything...but I just want to be sure.
<lifeless> elijah: the mapping data you are talking about goes in ~/.bazaar/
<lifeless> elijah: and is regenerated on demand
<elijah> ah, so if I have a svn checkout of foo in foo-svn and a bzr-svn checkout of foo in foo-bzr, then it is fair to compare 'du -hs foo-svn' and 'du -hs bzr-svn', yes?
<elijah> (Well, keeping in mind the fact that bzr stores all information on the branch instead of just a copy of the latest version)
<james_w> elijah: yes.
<elijah> cool, thanks.  :)
<james_w> elijah: however it may not be representative of what you would have with a pure bzr branch of the same revisions, as bzr-svn may have some overhead, but it is all mixed in with the .bzr metadata
<elijah> doh
<elijah> well, I probably can't measure that easily, so I guess I'll have to do without.
<lifeless> also
<lifeless> we have annotations cached in .bzr
<lifeless> some formats make them optional, if storage is a premium
<lifeless> and in about 2 months we're expecting a 50% size reduction in .bzr
<elijah> with the knit-pack format?
<beuno> lifeless, would you have a few minutes to talk about the XML/Output Abstraction patch?   We're still unsure on to procede...  :(
<lifeless> beuno: yes, but not right now sorry
<lifeless> elijah: with a successor based on it. new delta logic and ordering
<lifeless> elijah: its a minor tweak now we have the infrastructure in place.
<lifeless> later all
<beuno> lifeless, np, tnx anyway
<elijah> lifeless: cool
<elijah> thanks for the help, lifeless and james_w
<AfC> Does[n't] Launchpad have a bzr:// server running?
<jamesh> AfC: no
<jamesh> just http: and bzr+ssh: at the moment
<jamesh> and sftp:
<jamesh> you can access all branches via http and bzr+ssh
<AfC> jamesh: yeah, but http:// is deadly slow
<jamesh> try bzr+ssh then
<AfC> I'm surprised at them for not running a Bazaar server. Hello, dogfood.
<jamesh> we are running a Bazaar server
<AfC> There are some pretty evident differences between invoking a single bzr serve for a short duration over an SSH tunnel, and having a bzr serve daemon running.
<jamesh> AfC: we did have bzr+http set up a while back, but it seems to have bit-rotten
<AfC> jamesh: (yeah, I gave up trying to make that work)
<AfC> (too)
<jamesh> there do seem to be some bugs in Bazaar related to closing connections
<AfC> jamesh: Incidentally, in reply to your response of "try bzr+ssh://" to "my http:// is deadly slow", my comment was really more directed along the lines of "everyone is publicly being told (by Launchpad itself, and everything else)
<jamesh> AfC: well, we're looking at changing those instructions to "bzr branch lp:whatever"
<AfC> jamesh: to do bzr clone http://whatever ... and thus the very first impression they get of Bazaar as a result is pathetic performance. We observed an improvement of the order of 22 minutes to ~105 seconds by switching to a public bzr:// instance
<AfC> jamesh: yeah, I filed one myself about CLOSE_WAITs.
<jamesh> AfC: sure.  http or sftp are not really comparable to bzr or bzr+ssh
<AfC> [which is usually a pretty clear flag or such]
<AfC> s/or/of
<AfC> The Bazaar hacker crew it talking about 1.0 any day now; it's things like what we've been speaking about which I would encourage be cleaned up lest the marketing opportunity they are hankering after be wasted.
<AfC> s/it/is
<AfC> Apparently I haven't had enough coffee yet today
<jamesh> I wonder if we have a bug for adding plain bzr:// protocol support
<AfC> I'll file one if you want, but that's really your internal business.
<jamesh> please do so
<jamesh> AfC: how many squares were on the senate ballot paper for you?
<AfC> jamesh: Zero. I'm not an Australian citizen.
<jamesh> ah.
<jamesh> you should fix that :)
<AfC> [This is almost, but not quite a bitch for me. Same problem in New York. I lived there years. I PAY TAXES. And yet I am unable to exercise representation. Taxation without representation has been the singular most dominating issue driving western politics in the last 300 years. Even religious conflict is usually cover for this issue]
<jamesh> I remember one of my former colleagues who moved states in Canada
<jamesh> the two states had different enrollment rules, so he got taken off the roll in the old state, but had to wait a while before they'd put him on the roll in the new state
<jamesh> so he missed the election
<AfC> uh huh
<jamesh> (can't remember which type of election it was though)
<AfC> I'm pretty much a permanent expatriate now. It's ok. I kinda like it that way.
<AfC> I love how when I try to report a bug in launchpad it crashes my web browser.
<AfC> jamesh: https://bugs.launchpad.net/launchpad/+bug/164790 filed
<ubotu> Launchpad bug 164790 in launchpad "Launchpad should run a Bazaar server and advertise bzr:// URLs." [Undecided,New]
<jamesh> with the changes I did to the launchpad plugin for Bazaar, it'd be trivial to get people using bzr:// instead of http:// for lp: URLs purely through changes on the server
<AfC> jamesh: that makes sense
<AfC> jamesh: I'm mostly an outsider on all this, but we made an early commitment to Bazaar for what we believe are the right reasons. My colleagues and I just want to see Bazaar put forward as successfully as possible as a result.
<AfC> ie removing cruft, etc
<jamesh> AfC: yep.
<jamesh> hopefully you'll find some of the new Launchpad features in the coming months useful
<AfC> [IMO (nothing humble about it) merely calling it "1.0" has little to do with achieving that. I know that'll bring more users, but on the other hand
<AfC> there are so many warts (and the two competitors are improving in usability rapidly enough) that it's really quite underwhelming as a result. Little things matter.
<jamesh> 1.0 is not the end by any means though
<AfC> But the nature of leadership making is that people make input and then a decision is taken. Martin has made his call, fine]
<AfC> jamesh: I know. But all you're setting yourself up for is to get FUCKING PANNED in the trade press. Why would you invite this?
<jamesh> you'd have to ask one of the Bazaar guys about release planning -- I'm primarily a Launchpad developer
<AfC> Sure
<AfC> s/you/Canonical/
 * AfC is used to getting panned and mocked when he makes releases. Alas.
<AfC> That's Open Source for ya.
<fullermd> AfC: That's why I take great care to get my code ALMOST ready for release, and then never touch it again.  It's not laziness, it's careful PR!  ;)
<AfC> fullermd: ha
<fullermd> Having spent the last couple days working on code in mtn, I'm reminded of how much I prefer bzr.
<fullermd> But I do agree that a current 1.0 isn't just tempting fate, it's slapping a 'Kick Me' sign on yourself.
<Owner> hello, I've got a question about using bazaar with asp.net+IIS projects, anyone around?
<fullermd> I dunno what the question is, but I'll bet the answer involves holy water...
<bp> :) it's not as bad as you think, infact I kind of actually have a solution to the problem, but I wanted to know if bazaar supports the fix "officially"
<bp> The problem is that IIS seems to reject applications that contain directories with a "." (period) in their names. I.E. the .bzr folder
<bp> there seems to have been a bug report filed back in 2006: http://bazaar-vcs.org/UnderscoreControlDir   but I can't find any recent mention of it.
<fullermd> What, it ignores the whole directory because there's one file like that in it??
<bp> not ignores, per say, just acts wierd in certain situations
<bp> renaming .bzr to _bzr (or anything else for that matter) fixes the problem, but of course this breaks the repo.
<fullermd> That's fwacky.
<fullermd> I do remember the _bzr discussion, but it's certainly not currently there.  I don't remember if it just petered out, or got voted down for some reason, though.
<bp> yup, so basically I'm asking if bazaar supports renaming the repo folder.
<fullermd> AFAIK, no.
<fullermd> You might be able to put a wrapper around all bzr commands that mv it from _bzr to .bzr, do the bzr stuff, then mv it back.
<fullermd> Or just keep the VCS separate from the deployment.
<beuno> under apache, he means  :p
<fullermd> The former has its problems, but may work.  The latter's how I do stuff, but it does mean a little more infrastructure work.
<fullermd> Well, obviously, apache is the Right Answer  ;)
<bp> hmm, yeah those are valid solutions, but I think I might just attempt to apply the patch in the aforementioned link. Thanks for your help.
<fullermd> Well, the actual changes are probably a lot more involved than that suggestion there.  I'm pretty sure that only gets one place of the number that look for .bzr.
<bp> oh, well. I guessed as much, especially since that was back in 2006. Meh, no big deal, just a minor annoyance.
<beuno> bp, you could serve it through ftp
<beuno> anonymous ftp if you need public access
<bp> oh, no I'm not trying to make the repo public. Just trying to run the project (asp.net) in my dev environment.
<beuno> bp, well, you can serve bzr through ftp then
<beuno> you can push/pull through ftp
 * fullermd blinks.
<fullermd> I don't think bzr access is in any way his problem...
<beuno> oh, I might of understood it wrong then
<fullermd> It's that for whatever stupid reason, IIS goes nutty simply because of the presence of a '.bzr' directory, even if it's never accessed.
<beuno> aaah, sounds like fun
<fullermd> Which sounds insane to me.  Even for IIS.
<beuno> I was under the impression he wanted to branch from http
 * beuno reads it through again and realizes it was pretty clear
<beuno> no more IRC for me after 4am
<bp> :) thank's for trying beuno. hmm, just noticed Martin Pool (poolie) and Robert C (lifeless?) are on the channel, I think I'll just lurk for a few hours and hope they see the convo
<fullermd> Pshaw.  That's the best time   ;)
<fullermd> Well, it's Saturday night for them.  They may check in, but...
<lifeless> bp: I've seen that you had one, but not the content, and I'm on the way out to dinner
<lifeless> bp: mailing the ist would be a good thing to do
<fullermd> lifeless: asking after _bzr support
<fullermd> Did that discussion just peter out, or did we decide against it?
<lifeless> I think its got enough UI problems we are more against than for
<lifeless> but its not an impossibility; whats the reason - broken webserve or 'dont want an empty dir' ?
<lifeless> actually, I have to go; sorry
 * fullermd nods.
<bp> np, thanks lifeless, I think I'll put this issue on the lists
<fullermd> bp: Yeah, a summary to the list is probably the best thing.
<bp> yup
<ubotu> New bug: #164810 in bzr "knit chunk should contains inside all meta information that index has" [Undecided,New] https://launchpad.net/bugs/164810
<ubotu> New bug: #164814 in bzr "osutils.splitpath lose info about root directory" [Undecided,New] https://launchpad.net/bugs/164814
<ubotu> New bug: #164825 in bzr-push-and-update ""pushed 0 revisions" incorrect" [Undecided,New] https://launchpad.net/bugs/164825
<dennda> Hi there. I have a problem that isn't bzr-related at all, but maybe you can help me. I heard bzr uses ElementTree a lot. Is that correct?
<dennda> I parsed a svg-file (which is xml) with ElementTree and without altering it saved it back to the disk. the result is: http://pastebin.ca/795717 <- I want to know how to get rid of ElementTrees namespace-behaviour. It adds them automatically, which is not what I want. (It breaks the svg.) - If anyone has an Idea I would be glad if you shared it (maybe in query. Don't want to spam your channel)
<fullermd> Well, I'm no developer or expert.  But I was under the impression that bzr didn't use ElementTree to write the XML; just to parse it for reading.  I think the writing is done manually.
<dato> oh, no jam.
<dato> ah, weekend. right. :)
<rto> Are some of you well versed in the bzrlib?
<rto> Ok, i'll just try asking a question.
<rto> The thing is, i would like to find out which revision are "local" to a branch.
<rto> That is, when a branch is branched from another branch, i would like a way to find the revision commit'ed on the new branch - rather than all the branches from both the new branch and the branch i branched from.
<rto> Basically i want a bzr log --local command or something similar
<james_w> rto: bzr missing --mine-only otherbranch?
<rto> james_w: That seems to be somewhere along the lines of what i want, but it only lists revisions that differ between the two branches.
<james_w> so you want all revisions that were committed to the local branch and not another branch.
<rto> james_w: Yep, that is basically it. Something like bzr log --local
<rto> And preferably something where you don't have to give it another branch (or more) to compare with.
<rto> Up til now i have been able to use branch-nick to something along the lines, so local revisions are the ones where the branch nick on a revision is the same as the branch's nick.
<rto> But nick's can change, and i think there should be some way to tell revisions committed on the branch from revisions gotten from another branch.
<james_w> rto: well what you are asking for is not that easy to define. All the information required to do this is certainly not stored by bzr.
<james_w> the nick is the closest you can probably get, but as you say it's not perfect.
<james_w> also bzr log --short is kind of like that too, but again it depends on the situation.
<rto> Hmm, it just seems like something you would want to know, for instance bzrweb could show more relevant information by only showing the revisions on the particular branch.
<james_w> rto: well you normally define that in relation to another branch, as missing does.
<rto> james_w: But won't you end up with having to list all the branches that you have ever merged from in the past to show just "your changes"?
<abentley> rto: No, merges don't show up in the lefthand ancestry.
<abentley> That is, the revisions you merge don't show up there.
<james_w> rto: yes, it doesn't scale to many branches.
<abentley> So all you need to know is when your branch started.  Everything on the lefthand ancestry since your branch started is stuff you committed.
<rto> abentley: Ok, so i only need to list the branch i branched from
<abentley> Yes.  Or know the revision you branched at somehow.
<rto> abentley: Now _that_ sounds like something bzr should be able to tell me, the point at which i branched, or whether this branch is a branch of something else in the first place.
<abentley> It would make sense to store that, I agree.
<abentley> Some of our early decisions were based on the assumption that we wanted "cp -a" to be the standard way of branching.
<abentley> That's why we don't have a branch ID or a branch-point marker.  Those things are useless if copied verbatim.
<abentley> Since cp -a is not commonly used for branching, we could revisit that.
<rto> abentley: Ahh, that makes sense.
<pygi> hello all
<pygi> would anyone be interested in writing a bzr adapter for rvcs? estimate is that it's around 500 lines of code =)
<james_w> pygi: the Road Vehicle Certification System?
<pygi> james_w: actually, it's not :)
<pygi> Ruby Version Control System Abstraction Layer
<james_w> pygi: what does it take?
<pygi> james_w: what do you mean?
<james_w> you need a ruby mapping to all concepts? Or just a way of getting the latest version of the code for build scripts or what?
<james_w> and where's the code?
<pygi> james_w: gimme a second :)
<pygi> svn checkout http://rvcs.rubyforge.org/svn/trunk
<james_w> ah, ok. Doesn't look too hard, but I don't know ruby, sorry.
<pygi> james_w: it's not too hard ... I'd implement it myself, but currently playing with the abstraction code itself
<pygi> I think that's a good way to bring bzr to ruby community =)
<loswillios> hej
<loswillios> I'm having some problems with bzr, seems that something isn't in its correct path: http://pastebin.com/m4eb18ec3
<loswillios> can somebody help me with that?
<james_w> loswillios: how did you install bzr?
<loswillios> aptitude install bzr
<loswillios> I have bzrlib in /usr/lib/python2.4/site-packages/ and /usr/share/pycentral/bzr/site-packages/, I guess I need to put that in some $PATH
<james_w> loswillios: python --version?
<loswillios> python -V: Python 2.4.4
<loswillios> urgs
<loswillios> Version: 0.11-1.1
<loswillios> I guess that's way too old right?
<pygi> is that bzr version loswillios? :P
<pygi> yes, that's way too old :D
<loswillios> debian...
<loswillios> thanks james_w
<loswillios> hmmz
<liw> I'm doing a "bzr add" in a source tree that happens to contain sub-directories which contain .svn dirs, and bzr-svn (I assume) wants to connect to the svn server -- is this expected behavior?
<loswillios> even with 0.91-2~bpo40+1 from backports.org I have that problem
<loswillios> weird stuff
<loswillios> anyone another idea on that?
<pygi> so anyone knows a bit of ruby and willing to write a bzr module? ^_^
<abentley> loswillios: It sounds like bzr thinks you're trying to add files to the svn checkout.
<abentley> sorry, I meant liw
<james_w> loswillios: can you run python and then run import sys; print sys.path
<liw> abentley, that perhaps be a reasonable assumption, I guess
<liw> (why people put .svn dirs in release tarballs I do not know; I only put CVS ones in by mistake, but some people do it intentionall, go figure)
<loswillios> james_w: ['', '/usr/lib/python24.zip', '/usr/lib/python2.4', '/usr/lib/python2.4/plat-linux2', '/usr/lib/python2.4/lib-tk', '/usr/lib/python2.4/lib-dynload', '/usr/local/lib/python2.4/site-packages', '/usr/lib/python2.4/site-packages', '/var/lib/python-support/python2.4']
<abentley> liw: It means that you can immediately start working on the code from the tarball.
<abentley> I was actually going to propose that bzr export start doing that.
<liw> abentley, ugh
<abentley> A lightweight checkout doesn't require very much space.
<loswillios> james_w: bzrlib is in /usr/lib/python2.4/site-packages/
<abentley> And it means you can update to the latest code if you want.
<abentley> Or convert it to a branch with "bzr reconfigure --tree"
<james_w> loswillios: so can you do 'import bzrlib'?
<liw> abentley, as long as you make it optional, I won't mind
<loswillios> james_w: nope, ImportError: No module named bzrlib
<liw> if I want a branch, I'll make a branch; I use "bzr export" to make release tarballs, and I don't want any vcs metadata there
<james_w> loswillios: weird.
<loswillios> indeed
<abentley> liw: You aren't the person who will be using the tarball.
<liw> abentley, yes I am
<abentley> Really?  No one else uses your software?
<liw> there are other users (at least sometimes), but that doesn't mean I don't use the tarball myself
<abentley> Well, I am thinking of software that has many users who are not the author.
<liw> abentley, I am not opposed to having an option to include .bzr/ in the export, if the user wants it
<liw> abentley, but if you don't retain the current behavior, then I think you're making a mistake
<abentley> All I'm talking about is bringing it up for discussion.
<abentley> But I think that it's in-line with open-source ideals to make it easy to start hacking on the software you've just downloaded.
<liw> and therefore you want to make it difficult to not include the .bzr stuff even for people who don
<liw> 't want it?
<abentley> liw: I think that it might be nice to make it a lightweight checkout by default.
<abentley> Because I think that in the common case, the author will not be the tarball user.
<liw> and I think having any vcs metadata in a release tarball is bad, since it messes up with the downloader's ability to set up their own version control
<abentley> Could you expand on that?
<liw> I've never had any use for any .svn, .bzr, .git or other such metadata included in a release tarball; rather, they interfere with things when I want to import the sources into a new branch I've created myself
<liw> or prevent me from creating such a branch before I clean up
<liw> if I want to branch off upstream's branch, I already have tools for that; putting extra stuff in tarballs does not give me new functionality, but does make more work for me
<liw> (further, not all bzr branches are for software projects, of course; the .bzr stuff is of zero use for, say, when I create a zip of a document project to send to my father)
<nekohayo> hello, is there any reason for my 3 bugs with patches (for example, https://bugs.launchpad.net/bzr-gtk/+bug/151824 ) still lying around, in an unconfirmed state, after one month?
<ubotu> Launchpad bug 151824 in olive "use single click for bookmarks" [Undecided,New]
<nekohayo> did I file them on the wrong components?
<pygi> hello
<pygi> anyone with at least little ruby knowledge willing to write bzr adapter for rvcs??
<beuno> nekohayo, let me take a look. It might be due to 1.0 release being so close by
<beuno> a lot of attention is diverted toward that
<beuno> nekohayo, seems filed correctly, maybe you could email the list with the bug numbers so they can be looked at?
<pygi> anyone? :P
<nekohayo> beuno: wha, 1.0 already? of bzr or bzr-gtk you mean?
<jelmer> nekohayo: manpower mostly
<beuno> nekohayo, bzr
<jelmer> nekohayo: there's only a couple of us working on bzr-gtk, and we're quite busy with other things as well
#bzr 2007-11-25
<loswillios> hah!
 * loswillios waits for james_w to appear
<nir> What can cause this error on bzr merge ../other
<nir> bzr: ERROR: [Errno 1] Operation not permitted
<nir> both branches are local, both owned by me
<nir> I merge changes in main in the other branch, but I can merge changes from other in main
<nir> solved :-)
<nir> One file was locked (mac os x feature) I don't have any idea why
<nir> anyway, the error message is not helpful - it should show the path that failed
<lifeless> nir: good point; its likely though that its an OSerror being raised rather than a bzr internal error that we can format and show useful data on
<lifeless> we can certainly fix this particular case if you can provide the traceback and info for reproduction
<minghua> Hi, I wonder if there is a way to combine multiple commits into a single one when doing "bzr rebase".
<jelmer> minghua: not at the moment, no
<minghua> jelmer: Thanks.
<jelmer> minghua: Why would such a feature be useful?
<minghua> jelmer: I am a translator.  I commit my work every day.  But it makes little sense to push or send patch of multiple changes when the translation is sent to upstream.
<minghua> jelmer: If you read the bottom of http://wiki.debian.org/Teams/Dpkg/GitUsage you'll see the Debian dpkg upstream developers require translators to combine their changes before pushing.
<jelmer> minghua: that's specific to git though
<jelmer> when upstream merges your changes with bzr, there is only one additional revision on mainline
<minghua> jelmer: Yes.  That's why I am asking if bzr has something similar...
<jelmer> minghua: I don't see how it clutters mainlines revision history with zbr
<minghua> jelmer: Oh, maybe that's the case.  I am a quite new bzr user.  But I just did a "bzr rebase", and I got an empty commit for "merge from upstream".
<minghua> I did some translation changes in my branch, then I "bzr merge" with upstream, then I "bzr commit" as revision #n, finally I decided to do "bzr rebase".  And the revision #n is rebased as an empty commit.
<jelmer> there shouldn't be a reason to do a rebase at all there
<minghua> Hmm.  Maybe there isn't.  I should just run "bzr diff" across two branches.
<jelmer> in general, if you do a merge of upstream+commit there's no need for a rebase and vice-versa
<jelmer> minghua: If you don't use rebase at all, you won't clutter upstreams mainline
<jelmer> and there will simply be one revision in mainline where your branch was merged
<jelmer> no matter how many revisions it has
<jelmer> "bzr log" will then show your revisions indented below that merge revision
<jelmer> or not at all, depending on what you ask it to show
<minghua> jelmer: I see.  Thanks for the explanation.
<jelmer> minghua: what are you trying to do exactly? Are you submitting a patch to dpkg?
<minghua> jelmer: No.  I was doing man-db's translation work, and upstream uses bzr.  I did some small incremental changes to the translation.
<minghua> There were also upstream changes in between, and I merge and commit them once in a while.
<minghua> Today I want to see how many changes I've made and what they are, so I did rebase, now all my local changes are on top.
<minghua> I'll probably send a patch to upstream since I can push into the upstream repo, but that's not really relevant to the discussion.
<minghua> jelmer: So in summary, what I was trying to do is to see my changes over the past months (which are acutally on a single file).  "bzr diff" across two branches should do that.  It would be nicer to see them individually, though, and I don't know how to do that yet.
<jelmer> bzr diff -c <revno> should show you the changes in an individual commit
<minghua> jelmer: But that requires me to go through "bzr log" to get the revno of my commits, doesn't it?
<jelmer> yep - you're looking for something that will present a concatenation of all those patches?
<jelmer> I guess something like "for I in `seq FROM-REVNO..TO-REVNO`; do bzr diff -c $I; done" can do that, but I'm not aware of any command in bzr that can
<minghua> Wouldn't that include changes I merged from upstream as well?
<minghua> I am looking for a way to see individual patches of my commits, and my commits only.
<jelmer> ahh, ok
<minghua> Then say if I'm doing both translation work and code changes, I may want to put all my translation changes in one commit to upstream, but separate the translation and the code.
<minghua> I admit that's quite a corner case, of course.  And I probably should use two different branches for that.
<radix> are you trying to maintain a branch long-term?
<radix> because indeed, you're probably much better off using specific, task-oriented branches.
<minghua> It will be long-term if I don't have much time to work on it...
<lifeless> minghua: rebase destroys history and collaboration; if you don't plan to collaborate on the translations, you can rebase safely. But if you plan to collaborate, rebasing is a significant negative.
<minghua> lifeless: No, no collaboration so far.  Thanks for the warning, though. :-)
<lifeless> np
<lifeless> its a significant part of why rebase isn't a common workflow in bzr land; and one of the things I find most weird about the git culture
<minghua> I am from SVN land.  Both cultures are new to me, I am just trying to figure out what is the best way to construct my workflow.
<lifeless> ok
<dato> if I `bzr pulled`, and then I decide eg. I pulled something I didn't want in my branch yet, is there a way to go back that isn't `bzr uncommit; bzr uncommit; bzr uncommit` ?
<fullermd> pull from yourself at the chosen rev?
<dato> `b pull -r 1284 --overwrite . ` did the trick, thanks fullermd
<loswillios> james_w: hej
<loswillios> james_w: I fixed it
<loswillios> turns out, /usr/lib/python2.4/site-packages/bzrlib was missing __init__.py and such stuff
<james_w> loswillios: wow. good catch.
<loswillios> the debian package is missing some symlinks here. manually symlinking the stuff works now
<james_w> loswillios: you're running a backported version?
<loswillios> yep
<loswillios> but the package in etch was missing the symlinks also (bzr-0.11, lol)
<loswillios> I begin to think, that something with this debian installation is wrong
<james_w> it sounds like something funky might be going on with python-central
<dato> loswillios: how are you installing the .deb?
<dato> loswillios: the .deb itself won't have the symlinks, they are created at instalation time
<loswillios> yes.. they symlinked each file seperatly. symlinking the whole /usr/share/pycentral/bzr/site-packages/ to site-packages did the trick
<james_w> dato: I believe he said aptitude yesterday.
<loswillios> dato: yeah, I thought so. with aptitude / apt-get
<dato> ok
<ubotu> New bug: #165014 in bzr "IPv6 support" [Undecided,New] https://launchpad.net/bugs/165014
<jelmer> lifeless: ping
<james_w> jelmer: congratulations on your DM advocation.
<jelmer> james_w: thanks!
<mwhudson> bzr: ERROR: Installed bzr version 0.93.0.dev.0 is too old to be used with bzr-svn, at least 1.0 required
<mwhudson> jelmer: where do i get bzr 1.0 ? :)
<fullermd> We're keeping it in svn.  Just use bzr-svn to check it out...
<Odd_Bloke> ^_^
<mwhudson> heh
<jelmer> mwhudson: whoops :-) Fixed now, thanks.
<jelmer> mwhudson: btw, that bug you hit pushing pydoctor should be fixed now
<jelmer> mwhudson: although pushing should still be somewhat slow
 * mwhudson tries
<mwhudson> "finding branches" is still pretty slow
<jelmer> mwhudson: yeah, I hope to fix that for 0.4.5
<jelmer> its result can be completely cached, with a little bit of work
<mwhudson> jelmer: will it get cached once it's completed?
<jelmer> mwhudson: bits of it, but not completely
<mwhudson> i see
<jelmer> it uses svn metadata to find those branches and that metadata already gets cached
<mwhudson> puh, conflicts
<jelmer> mwhudson: during svn push?
<mwhudson> yeah, but legitimate ones
<mwhudson> how i wish svn had uncommit
<mwhudson> pushing again, let's see how that goes
<mwhudson> !paste
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<mwhudson> jelmer: hee! http://paste.ubuntu-nl.org/45816/
<mwhudson> radix: you are being mailbombed, sorry about that
<jelmer> :-(
<jelmer> mwhudson: this is with subversion 1.4?
<mwhudson> jelmer: it's whatever's in gutsy
<mwhudson> jelmer: it looks like 11 commits actually ended up in svn though
<mwhudson> jelmer: i'm trying again after 'ulimit -c unlimited'
<lifeless> jelmer: pong
<mwhudson> wth
<mwhudson> i accidentally ^Ced it
<mwhudson> and this: http://paste.ubuntu-nl.org/45819/ happened
<jelmer> lifeless: 'morning
<jelmer> lifeless: I was wondering if you could advocate my application to become a Debian Maintainer?
<lifeless> sure
<jelmer> It should be a matter of replying to the thread in debian-newmaint
<jelmer> http://lists.debian.org/debian-newmaint/2007/11/msg00157.html
<mwhudson> hi lifeless
<mwhudson> there was something i wanted to ask you, but i can't remember what it was
<dato> jelmer: if you'd bounce him the mail, replying would keep the threading
<jelmer> dato: good point - just did so
<lifeless> mwhudson: :)
<samiam> morning all
<samiam> I have a really quick and possibly stupid question
<samiam> is it possible to change a log entry for a commit, post-commit?
<samiam> I just realized I had made an error and would like to correct it
<dato> nope.
<dato> but if it's the last commit
<dato> you can `bzr uncommit` it
<dato> and commit again, with a fixed message
<samiam> good point
<samiam> it isn't the last
<samiam> its no big deal, I just thought that this might come up from time to time and felt I should investigate now
<samiam> its a single-user repo anyway
<samiam> thanks dato
<mwhudson> at least in conception, bazaar revisions are totally immutable
<samiam> mwhudson: I had never really seen this capability in other vcs' so I thought I would ask just in case
<samiam> truthfully, that would be a really bad thing to have in a vcs, because you'd lose the integrity or value of the commit logs
<mwhudson> samiam: right :)
<mwhudson> samiam: you can use rebase in situations like this, if it's really important
<mwhudson> (probably not for a commit message, tbh)
<samiam> it isn't important at all
<samiam> just exploring bzr right now and using it for personal work
<mwhudson> cool
<samiam> thanks for the feedback mwhudson
<mwhudson> np
 * mwhudson stares at merge.py
<radix> mwhudson: heh
<radix> mwhudson: when are you going to start using bzr? :)
<mwhudson_> jelmer: so that run got nixed by my machine crashing :)
<jelmer> not due to bzr-svn, I hope ? :-)
<mwhudson> jelmer: don't think so :)
<abentley> hey mwhudson, how goes?
<radix> _there's_ the spam :)
<radix> mwhudson: use Launchpad!
<fullermd> Hm.  I think progress bars on check are a little squirrely.
<lifeless> radix: mwhudson is using bzr. merge.py is in the guts
<fullermd> Unless checking versionedfile 0 really does take about 10 times as long as the other 200-some, I suspect it's doing something other than it claims at that time.
<lifeless> fullermd: enumerating the versionedfiles requires a table scan in packs
<fullermd> I'm using good old-fashioned knits.
<lifeless> ah, then its disk IO
<fullermd> All in cache.
<lifeless> bleh
<lifeless> hit ctrl-\ and type bt CR
<fullermd> python's getting 100% CPU while it's doing whatever it's doing there...
<fullermd> Inner frame at the bottom?
<lifeless> yes
<lifeless> but look up the stack for the relevant function names
<fullermd> Seems to be spending a lot of time in xml_serializer stuff.
<lifeless> so look up
<lifeless> some function will probably have iter or some hint in the name
<fullermd> Seems to be mostly in repository._generate_text_key_index()
<fullermd> It probably spends about 20 seconds in that versioned file 0/xxx on a branch where check runs in under a minute.
<lifeless> ok
<fullermd> Lemme halt it a couple times for a sampling...
<lifeless> so that is scanning all the inventories
<lifeless> it's meant to do a progress bar for that
<lifeless> but it's reasonable for it to be expensive, its the dominating data structure of bzr
<fullermd> It seems new, though.  Nowhere near that much time elapsed between the revision checking and versionedfile checking last week or so.
<fullermd> It used to just start counting as soon as it was in versionedfile.
<fullermd> A few samplings within the process: http://paste.ubuntu-nl.org/45844/
<mwhudson> radix: >:)
<mwhudson> abentley: good thanks, about to have dinner
<fullermd> Wait, "unreferenced text versions" can't possible be right.  It's within 1% of total revisions * file-ids; that's more texts than should exist period.
<abentley> lifeless: The thing about KindChange is that it must appear in the list at the end, and diff_text must be second.
<luislavena> hello guys.
<lifeless> abentley: KindChange I can understand; why Text ?
<lifeless> hi luislavena
<luislavena> quick question: anyone using bzr-gtk on windows?
<luislavena> hi lifeless
<lifeless> fullermd: have you reconciled this repository with 0.92 or bzr.dev ?
<lifeless> luislavena: I know people have managed to get it to work, and bzr-tortoise incorporates parts of it
<abentley> Difftext must be second-last, because it's a catch-all.  If it's early, more specialized diffs will never be used.
<luislavena> lifeless: I'm using Olive without problems, but the diff it generates aren't colorified :P
<lifeless> abentley: I don't think it has to be second-last. I think it has to be after anything else that would diff the same files
<lifeless> abentley: same with DiffSymlink
<lifeless> abentley: if I had a variation on that, I have to put it before DiffSymlink
<lifeless> abentley: in fact, *all* of these have an ordering. I don't think there is a problem in allowing a certain amount of rope though :)
<abentley> Yes, but diff_text is an instance and can't appear in the factory list at all.
<abentley> So it must either appear before all registered factories (disaster) or after (safe).
<abentley> And KindChange must appear after diff_text.
<fullermd> lifeless: Yep.  http://paste.ubuntu-nl.org/45846/
<lifeless> abentley: oh; I must have glitched on this. I thought it would still be a factory
<lifeless> abentley: let me check the patch again
<abentley> No, its construction depends on what parameters are passed to show_diff_trees.
<ubotu> New bug: #165061 in bzr "bzr branch http:// with a pack repository takes too long" [High,Triaged] https://launchpad.net/bugs/165061
<lifeless> abentley: so the old and new label parameters seem applicable to all Diff classes
<abentley> I don't think they are.
<lifeless> abentley: and the internal_diff parameter is indeed a touch tricky
<abentley> It's purely a unified diff formatting quirk.
<abentley> It's so that patch -p1 works.
<lifeless> abentley: they change the path prefix don't they ? we should be showing that on e.g. symlink changes too
<abentley> patch can't understand symlink changes.
<lifeless> thats true
<lifeless> but humans will be weirded out by something like:
<abentley> We've never used them for anything except unified diff formatting.
<lifeless> old/text   new/text
<lifeless> ...
<abentley> We don't use them in the === modified message.
<lifeless> base/link  changed/link
<lifeless> oh hmm
<lifeless> well.
<lifeless> Like I said, if you don't agree - and it seems like there is good reason that its not trivial to do the entire thing I suggested, its fine as is
<lifeless> I still think having Diff.__init__(self, a_diff_tree): would be good
<abentley> Okay.  So now we let poolie decide whether it's 1.0-worthy.
<lifeless> because it opens the door to doing the rest later with less of an API change
<abentley> I've done that change.
<lifeless> sweet
<abentley> Or rather, I created a real factory.
<lifeless> I'm confused. Do you have a further tweak beyond your latest mail?
<abentley> So that we can still construct the Diff classes in a straightforwardway.
<abentley> I have a further tweak, if we want it.
<abentley> But it doesn't allow us to put DiffKindChange in the factory list, which was the reason for your suggestion.
<lifeless> right
<lifeless> Do you think it looks nice other than that? If so, lets do it.
<abentley> Sure.
<lifeless> I'll be on the phone with poolie in 1.5 hours
<lifeless> I'll raise this patch to his attention if it's not already there.
<lifeless> brb
<lifeless> luislavena: I would suggest filing a bug on bzr-gtk
<luislavena> lifeless: I'm googling for something like this before, maybe I missed something, but guess not.
<cbx33> hey all
<lifeless> hi
<luislavena> cbx33: hi
<cbx33> hi luislavena
<luislavena> lifeless: done, there is no info about this on the web, so submited a new bug report to bzr-gtk team. thank you.
<abentley> fullermd: versionedfile data and the inventory data are stored along different axes.  So doing the first versionedfile requires reading most inventory revisions.  That data's then cached.
<lifeless> abentley: my lower memory reconcile changed check too
<fullermd> Well, but it seems new, though.  It used to just count up through the revisions, then count up through the vf's, without the big pause there.
<lifeless> abentley: so it no longer incrementally generates a inventory->text cache at all.
<lifeless> fullermd: it should be faster overall
<fullermd> That might do it.  When the vf numbers do start counting, they seem to go a lot faster than they used to.
<lifeless> fullermd: if you run check with -v you should get a list of the text versions that are not referenced
<lifeless> fullermd: and we can dig into why they are not being cleaned up
<fullermd> It's not the existence; it's the wildly extreme number.  I don't recall doing anything special in the history of these branches; there shouldn't be that many texts ever existing, much less unreferenced.
<fullermd> There were some uncommits or discarded branch revs, but those would still be ref'd, AIUI.  And this is a fresh branch, so it wouldn't bring those along.
<fullermd> -v doesn't output anything different.
<dato> jelmer: that was fast, eh? (re joeyh's mail)
<lifeless> fullermd: ok thats weird. Is this a repo I can get access to ?
<fullermd> Probably not...   I can make a nothing-branch that starts showing up unref'd text versions, though...
<lifeless> fullermd: if its in the same repo thats why
<fullermd> No, in a fresh standalone.
<jelmer> dato: wow, that /is/ fast
<dato> :)
<fullermd> lifeless: http://paste.ubuntu-nl.org/45848/
<fullermd> lifeless: It seems to need the second file; just stuffing text in foo and committing more revs doesn't make it show up.
<lifeless> dato: what happened ?
<lifeless> fullermd: blarh. please file a bug
<lifeless> fullermd: (I reproduced it, just need a note to track it)
 * fullermd nods.
<fullermd> Probably a check bug, and not that we're actually making extra texts?
<dato> lifeless: he was already added to the debian-maintainers keyring
<fullermd> Filed.
<lifeless> dato: rofl
<ubotu> New bug: #165071 in bzr "check reports spurious unreferenced texts" [Undecided,New] https://launchpad.net/bugs/165071
<jelmer> hmm, the quick reference doesn't contain any info about "
<jelmer> bzr send"
<jelmer> I wonder whether that should be considered a bug?
<lifeless> jelmer: yes
<sdh> can anybody tell me a good resource to learn how to use bzr in a mixed-type environment
<sdh> so i have a central repos, and can branch onto my laptop, say, commit there, then commit all back later?
<sdh> e.g. when on plane
<sdh> probably not explaining well :)
<lifeless> sdh: the tutorial probably is enough
<sdh> lifeless: just realiesd that wasn't one of the docs i read, heh. thanks. :>
<lifeless> :)
<lifeless> please do ask for more details and hints once you've given it a shot
<sdh> thanks... i did read lots... of blog posts ;)
<sdh> so far today i've tried git, hg and now bzr... bzr "feels" good so far :)
<lifeless> excellent
<sdh> i watched a video of linus talking about git at google and learnt two things
<sdh> 1) git is supposedly fast
<sdh> 2) linus is even more arrogant than i thought
<sdh> :)
<fullermd> Pfft.  Obviously, you are Ugly And Stupid   :p
<sdh> haha, that's the one ;)
<ubotu> New bug: #165080 in bzr "Quick Start Guide doesn't document "bzr send"" [Undecided,New] https://launchpad.net/bugs/165080
<sdh> is there a way to push to the parent branch without specifying it explicityly?
<sdh> explicitly, even
<abentley> sdh: just "bzr push".
<abentley> That will push to the remembered branch.
<mathrick> hiya
<abentley> Which is actually a different location.
<abentley> But you don't have to specify it explicitly each time.
<mathrick> what is the right foo to get a working tree in a treeless branch?
<sdh> it didn't work for me, i got:
<abentley> mathrick: bzr checkout .
<sdh> oh it works after the first push :)
<abentley> sdh: right.
<sdh> thanks
<abentley> sdh: np
<abentley> mathrick: or on recent Bazaars, "bzr reconfigure --tree".
<mathrick> oh, already checkouted :)
<mathrick> and yes, it's 0.93, so recent
<fullermd> Mmp.  We probably need a good section in the docs on reconfig (and that alias).  I like to think I have a reasonable knowledge of bzr, but I couldn't guess what "Reconfigure to a tree" means.
<mathrick> small inconsistency: bzr status takes -V, but bzr ls doesn't
<mathrick> you have to use --versioned
<lifeless> mathrick: yah, IIRC we put -V in for ui friendliness with svn
<mathrick> it's a good alias
<lifeless> please file a bug about -V for ls
#bzr 2008-11-17
<lamalex> mwhudson: does it look like an ok bug/patch though?
<slangasek> jelmer: any luck?
<jelmer> slangasek, Yeah, I've managed to reproduce it
<jelmer> And I think I've got a clue as to why it's failing
<slangasek> jelmer: so did I screw something up? :-)
<lexrupy> hello all...
<lexrupy> I read in some documentation that bzr serve "is" an in development feature.....
<lexrupy> but those docs are outdated I mean.. about version 0.16
<lexrupy> is this now fullfeatured and functional?
<lexrupy> I am using 1.9 of course
<spiv> Current docs are at http://doc.bazaar-vcs.org/latest/
<lifeless> lexrupy: its not finished, but then software never is
<spiv> bzr serve is certainly functional, and everything that works with direct file access should work via a bzr server.
<lexrupy> yes I know, but I can use it in production as well?
<spiv> It's still in development, but so is the rest of bzr ;)
<spiv> Yes, it's ready for production use.
<lexrupy> spiv: thank you, and, I already read the latest documentation... I use Bazaar since version ~ 0.90 I think
<lexrupy> I am already using via bzr+ssh... I am asking just because I will write an article about this and I want to make sure that it is "stable"
<lexrupy> ok, I think you can help-me a little bit more
<lifeless> lexrupy: launchpad hosts bzr using bzr-serve
<lexrupy> in my tests I got bzr+ssh about 20% faster than sftp... these numbers are reliable or you have more precise numbers?
<evarlast> we have been using serve in production at work for months.
<spiv> lexrupy: it depends on a lot of variables, like the latency of your network connection.
<lexrupy> spiv: ok, in my tests I use my laptop in a LAN environment with server
<jelmer> slangasek, it seems it's similar to bug 295416
<ubottu> Launchpad bug 295416 in bzr-svn "branch root moving breaks missing and push" [Medium,Triaged] https://launchpad.net/bugs/295416
<slangasek> hmm, ok
<spiv> lexrupy: and also on which operation you're measuring; some operations are optimised more over bzr serve, others will be about the same as SFTP.
<jelmer> you didn't have a branch root, but in your case the first revision in svn history is not the first revision in bzr history
<lexrupy> spiv: humm
<jelmer> slangasek, it shouldn't be too hard to fix, let me have a look
<lexrupy> spiv: I tested checkout and branch commands
<spiv> The optimisations so far have mostly focused on those and on push.
<rockstar> lifeless, I didn't merge the branch, but it's good to have around.
<lexrupy> spiv: in a tree with just some files (3.8Mb) with 152 revisions and I take about 11secs to sftp and about 9 secs to bzr+ssh
<spiv> 20% certainly sounds believable, but I can't give you a single number that will be universally true :)
<lexrupy> ok
<lifeless> rockstar: its in trunk
<lifeless> rockstar: *someone* merged it
<rockstar> lifeless, yea, I asked beuno to merge it.
<rockstar> Was it not ready to be merged?
<lifeless> it was
<lifeless> it would be nice not to disable concurrent request processing
<lifeless> but I need to know more about the paste contract to do that
<lifeless> it would also be nice to record the url
<lifeless> e.g. trunk_changes_foo_bar-1-stats.callgrind
<rockstar> lifeless, yea, I also think that, now that I've been inspecting results.
<rockstar> The number isn't so helpful.
<lexrupy> I was thinking about how launchpad manage that groups of Developers to have access to a branch
<lexrupy> But I cannot spot that... is each launchpad user a Unix User on server?
<lifeless> lexrupy: no, they are not
<rockstar> lexrupy, nope.
<lifeless> rockstar: its a start; better than embedding callgrind data in a .jpg :)
<lexrupy> huh, so How can I setup my server to behave like that?
<rockstar> lifeless, :)
<rockstar> lexrupy, behave how specifically?
<lexrupy> I can for example create a branch on server belong my user.... bzr push sftp://myserver/~/mybranch
<lexrupy> at this poiint mybranch will belong to my user on server...
<lexrupy> and another user cannot push changesets there if I not..... forget
<lexrupy> I have pointed that now
<lexrupy> :)
<lifeless> lexrupy: you need to use a replacement ssh server to do this; or use bzr+http and use apaches auth support
<lexrupy> I put my ssh public key on server.... I have forgot that :)
<lifeless> lexrupy: bzr works fine with groups; just have both users in the same group
<lexrupy> I in fact can have a bzr user on server and create all repos in that account
<lexrupy> then authenticate users via ssh public key
<lexrupy> sorry, it was a "stupid" question
<rockstar> lexrupy, I put my branches in /var/lib/bzr/<project>/<branch-name>
<Peng_> lifeless: In bzr-search, did you mean to change group_size from 2500 to 50?
<lifeless> Peng_: yes
<Peng_> That lowers memory use, right?
<rockstar> lexrupy, So I make the <project> folder owned by a group called developers, which I am a member of.
<lifeless> Peng_: yes
<Peng_> lifeless: Does it affect speed?
<Peng_> (effect? bah)
<lifeless> Peng_: somewhat
<lexrupy> and you have an user for each develpper at yhour server?
<Peng_> lifeless: How long is it supposed to take to index a copy of bzr.dev?
<lifeless> Peng_: a few minutes
<Peng_> lifeless: I've had it running for 20 minutes and it's barely halfway done. :)
<lexrupy> I already have a setup with asingle bzr user, and each user push and pull from server using something like bzr+ssh://bzr@server/bzr/branch
<lifeless> Peng_: hmm, roll back the push and try again; I'd like to know if it is faster for you
<rockstar> lexrupy, yes, each developer on the system is a member of developers.
<Peng_> You mean waste 20 minutes of work? Heh.
<lifeless> Peng_: yes
<lexrupy> rockstar: and I already have public keys there so, users no need to enter bzr password on server, but I was thinking about sftp protocol, but since spiv said me before that launchpad use the Fast Server the launchpad setup seems like my setup
<Peng_> FWIW, the copy of bzr.dev is using btrees, and I ran it with -Dmemory, but that shouldn't have an impact.
<lexrupy> rockstar: but in fact I add a public key for each people I want to do access to *all* branches... and launchpad do it "per branch"
<lifeless> Peng_: if the index time is substantially different for you before/after that patch, I will fix; if its not, then I'll get you to give me a lsprof trace.
<lifeless> bbs, lunch
<Peng_> lifeless: Right now the progress bar is on step 2/9 and it's only been running for 1.5 minutes, so I think it is substantially faster.
<dryahetzeph> Is it possible to use bzrlib from a standalone bazaar installation on win32?
<Peng_> lifeless: Now it's at 4/9. It's definitely much faster.
<Peng_> Haha, woah, it's using 400 MB of RAM. I like group_size = 50 better. :P
<Peng_> lifeless: Using the previous revision of bzr-search, it took 7 minutes and 42 seconds to index the whole thing. That's definitely a lot faster.
<hydrapheetz> Hm, I wonder if I can just use the bzrlib module from the sources instead.
<Peng_> hydrapheetz: Sure, you can. Some things will be a bit slower if you don't compile the extensions, but it'll work.
<Peng_> (As long as it can find its dependencies.)
<hydrapheetz> Ah
<hydrapheetz> I tried doing that and importing it, I haven't tried anything else with it yet
<lifeless> Peng_: ok, there are two possibilities
<lifeless> Peng_: I bet its the type detection misfiring
<lifeless> Peng_: put the patch back, then bump the batch size up, if you would
<lifeless> Peng_: I bet its still slow
<kumi> Is there any way to update a working tree after a remote client push? The remote client only has bzr+ssh:// access
<Peng_> kumi: Does it have plain-old-ssh access?
<Peng_> kumi: Well, anyway, the push-and-update plugin might work.
<kumi> nope, just bzr
<Peng_> lifeless: Will do
<kumi> push-and-update require plain old ssh access
<lifeless> Peng_: thanks - appreciate this
<lifeless> kumi: bzr+ssh is layered on plain old ssh
<kumi> yeah but the remote client is limited to the 'bzr' command
<Peng_> push-and-update just runs "bzr update".
<Peng_> So unless it's limited to "bzr serve", it should work.
<Peng_> Anyway, try it out. It only takes 30 seconds.
<kumi> It's using the bzr_access script, it won't work
<Peng_> Oh.
<Peng_> lifeless: It's running now. I'll get back to you in 7 minutes, I guess.
<spiv> If it's restricted to "bzr serve", then there's not much you can do.  You could write a plugin to install on the server that installs a post_branch_tip_changed hook to update a working tree.
<lifeless> Peng_: thanks
<kumi> not many of the built-in hooks are server side, maybe pre_change_branch_tip
<kumi> post*
<Peng_> lifeless: Actually, it's already on step 2/9, so it seems to be going pretty fast.
<kumi> I'll check that ouut
<spiv> Or you could configure a cron job on the server to run "bzr update".
<lifeless> Peng_: oh
<kumi> spiv: yeah maybe that too
<spiv> kumi: with new enough client and server (1.7?) post_change_branch_tip (or whatever it's called) will occur server side.
<Peng_> lifeless: Yeah, it's definitely not going to take 20 minutes.
<lifeless> Peng_: so tip with batch_group of 50 is slow, with 2500 is fast?
<lifeless> Peng_: ok. I was hoping to reduce the massive memory spike mysql causes
<kumi> spiv: I've got 1.9 on both ends
<Peng_> lifeless: group_size, yes.
<spiv> kumi: ok, that's definitely new enough :)
<Peng_> Too bad. I was hoping to reduce memory usage too!
<spiv> kumi: or tweak the bzr_access script to allow "bzr update"?
<kumi> I don't think I could handle that (unless I have a 2nd copy associated with a 2nd ssh key). I'll try writing a hook
<lifeless> kumi: why would you need a 2nd ssh key?
<kumi> I think that's how it would have to work with authorized_keys
<kumi> if ssh key #1 logs in, run the bzr_access (bzr serve) script. If ssh key #2 logs in, run the bzr_access (bzr update) script.
<lifeless> kumi: ah, I see
<lifeless> I thought it was more like sudoers
<kumi> the authorized_keys command parameter only accepts one argument
<Odd_Bloke> It wouldn't take much hacking to allow the script to optionally call 'bzr update' after the 'serve' was done.
<lifeless> Odd_Bloke: it won't know what path to update
<lifeless> a plugin is the best option
<kumi> It might work if the branch directory is the same as the working tree directory
<grettke> Hi folks. I've got a shared repository of format "rich-root-pack". I would like to upgrade it to the 1.9 equivelant, but I'm not sure if that is "1.9-rich-root" or if, in fact, there is nothing to upgrade path at all.
<lifeless> grettke: its 1.9-rich-root
<grettke> lifeless: Understood. Thanks.
<Peng_> lifeless: BTW, do you have any use for the search indexes I created while timing it, or can I delete them?
<lifeless> Peng_: unless you suspect a bug, no
<lifeless> Peng_: but you could keep them, to use :P
<Peng_> Wait.. it creates a new pack each time it hits the group_size? When the group_size is really low, that means it'll do a bunch of autopacks, right?
<Peng_> That wouldn't help performance.
<Peng_> What does bzr-search do if not all of the revisions in a branch are indexed? (E.g. I hit Ctrl+C halfway through the indexing.)
<lifeless> Peng_: autopacking is small; only 10% hit or so
<abentley> spiv: around?
<lifeless> Peng_: also search has a different autopack trigger than bzr
<lifeless> Peng_: because of slightly different uses
<spiv> abentley: yeah
<abentley> spiv: So I tracked down a cause of stacked push over HPSS slowness: RemoteRepository.get_parent_map wasn't stacking.
<spiv> abentley: ah!
<abentley> spiv: Yeah, that caused it to try to push ~ the whole history.
<spiv> So the walk_to_common_revisions would walk a *long* way...
<spiv> Hmm.
<abentley> spiv: I have a fix that does the stacking on the client side in RemoteRepository.
<Hydrogen> walk five thousand miles...
<spiv> You mean the server-side is doing the wrong thing, or the client?
<abentley> spiv: Server-side doesn't have fallback repositories, so it can't be expected to do the right thing.
 * spiv nods
<abentley> So I figure this has to be done client-side, which is pretty in-tune with lifeless' choices.
<abentley> i.e. that we don't want to require stacking on the server side.
<abentley> spiv: I'm looking at RemoteRepository.get_parents, and I don't understand why it's implemented that way.
<spiv> RemoteRepository.get_parent_map, you mean?
<abentley> spiv: yes.
<spiv> There's a bit of ugliness there to handle falling back to less optimal methods, but I'm not sure if that's what you're referring to.
<abentley> It's doing caching itself instead of using CachingParentsProvider.
<spiv> I suppose it could, although it'd require a bit of mucking about to create a suitable object to construct it with.
<abentley> Is there a reason for that?  Or a reason not to do it in _make_parents_provider?
<spiv> If I implement a RemoteVersionedFiles class to handle the .revisions (and .texts/.inventories/.signatures) I could just pass that I guess.
<abentley> spiv: Oh, it's because the caching is happening at a tuple level?
<abentley> There's nothing about CachingParentsProvider that requires the keys to be strings.  Tuples should work just fine.
<spiv> Short answer: no particular reason.
<abentley> spiv: Okay, I'll hack on it tomorrow and there should be a patch on the ML when you wake up.
<spiv> Although I don't think any other Repository uses CachingParentsProvider in its implementation of get_parent_map.
<spiv> It seems to be used via _make_parents_provider by get_graph.  And get_parent_map is the primitive that that is built on.
<abentley> spiv: Nothing should be using get_parent_map directly.  They should be using get_graph, and other repos use it for that.
<spiv> Hmm.
<spiv> I don't think that's actually what's happening, even if that's what should be done.
<spiv> There's places like Repository.has_revision and InterPackRepo.fetch that call it directly.
<abentley> spiv: Doing it directly kills opportunities for optimization.
<spiv> Why not allow get_parent_map to cache automatically, rather than forcing things to go via get_graph?  Because that gives us more room to tweak the caching policy in future?
<abentley> Because you get a really easy way to manage the lifetime of the cache.
<lifeless> abentley: OTOH you have to manage the lifetime, or else differnet parts of bzrlib end up using different caches
<spiv> get_graph() strikes me as a bit weird, basically because of what lifeless just said.
<poolie> hello friends
<abentley> lifeless: This is a memo, not a true cache, so we can't keep using it for the whole bzrlib lifetime.
<abentley> poolie: hi.
<lifeless> hi poolie
<spiv> There's only one graph per repository object (or should be...), because the data should be cached just once.  So it's not a very separate object.
<lifeless> abentley: because it will grow too big?
<abentley> spiv: There are as many graphs as you create.
<abentley> lifeless: yes.
<lifeless> abentley: so I think there are two separate things here; the cache does reset when the lock count drops to 0, so its not entirely a memo, but as you say there is no ejection policy
<spiv> Hmm, I thought I'd seen a get_graph somewhere that returned the same graph object, or at least effectively the same one.
<abentley> lifeless: I am talking about CachingParentsProvider, not the cache in RemoteRepository.
<lifeless> abentley: oh right
<abentley> spiv: No, and it's impossible, because get_graph takes a repo parameter.
<spiv> There's other, related caching that happens in repository that is managed by lock lifetimes, i.e. index caching.
<spiv> Hmm.  The other thing with RemoteRepository.get_graph is that it expects to receive more results than it asked for.
<abentley> spiv: The parents provider for an individual repo *could* be always the same, but isn't because the client was meant to manage that object's lifetime.
<spiv> I suspect that returning those extra results, rather than just filling a cache with them, would break some callers in surprising ways.
<spiv> It's too easy to assume that "if len(foo.get_parent_map(keys)) != len(keys): # something must be missing" will work.
<abentley> get_graph just returns a Graph.
<spiv> But if those extra results sent by the server aren't cached, then RemoteRepository is going to be unnecessarily slow.
<spiv> So, if the question is "why change RemoteRepository.get_parent_map to reuse the cache logic in CachingParentsProvider?", then sure, we can do that.  (it's not a huge amount of code duplication, but reuse is typically a good thing)
<spiv> But if the question is "can we make RemoteRepository.get_parent_map not do any caching?", then I think the answer has to be no.
<abentley> spiv: So this means that RemoteRepository can't be its own parents provider.
<abentley> And the original reason that repositories had get_parent_map was so that they could act as parents providers.
<spiv> Or at least, "not yet, and changing that will need some careful thought."
<lifeless> abentley: why can't it be its own parents provider?
<spiv> Why do you say that?  I'm not sure what part of the contract it doesn't satisfy?
<spiv> (Is there a written description somewhere?  A quick grep isn't finding one for me.)
<abentley> spiv: In order for RemoteRepository.get_parent_map to use CachingParentsProvider, there must be an object that provides uncached access to parents via a get_parent_map method.  Which means it can't be RemoteRepository.get_parent_map.
<spiv> I can see that it would be redundant to use CachingParentsProvider with RemoteRepository.get_parents_map, but I don't see why it *can't* use it.
<lifeless> what spiv said
<abentley> spiv: Calling get_parents_map would give infinite recursion.
<spiv> Huh?
<lifeless> abentley: cached provider -> rr -> cached provider (remote content only)
<abentley> RemoteRepository.get_parents_map -> CachingParentsProvider.get_parents_map -> RemoteRepository.get_parents_map.
<spiv> But there is no "RemoteRepository.get_parents_map -> CachingParentsProvider.get_parents_map".
<lifeless> abentley: ah I see
<lifeless> spiv: abentley is saying that the CPP needs a callable to get the backend data over the wire, and that that can't be RR.gpm
<abentley> spiv: If we use CachingParentsProvider to implement RemoteRepository.get_parents_map, there will be.
<spiv> abentley: sure.  But if we write "def f(): f()" there will be infinite recursion too, and we don't do that either ;)
<spiv> I mean, obviously we can't make RemoteRepository.get_parent_map use a CachingParentsProvider(self).
<spiv> But there are other ways to reuse that caching logic without doing that infinite recursion.
<abentley> spiv: in other words, it can't be its own parents provider.
<spiv> (refactor CachingParentsProvider slightly, or provide another object than self to CachingParentsProvider that will fetch the data)
<abentley> The other object will be the parents provider.
<spiv> Well, it is its own parents provider at the moment, as the implementation of RemoteRepository._make_parents_provider hopefully demonstrates :)
<abentley> But it is upsetting to me that I need the other object, since the purpose of sticking get_parents_map on repos was to allow the repos to be parents providers.
<spiv> But RemoteRepository already is a parents provider, as I understand the term.
<abentley> spiv: Yes, but it's one that doesn't stack.
<spiv> It is an object that implements get_parents_map, what else is there?
<abentley> And adding stacking would ideally be done using _StackingParentsProvider
<abentley> But it's the same story as CachingParentsProvider.
<lifeless> abentley: huh? lost me
<lifeless> abentley: why can't you use SPP with a RR and its fallback repositories
<abentley> lifeless: I thought we weren't supposed to do server-side stacking.
<lifeless> abentley: on the client
<abentley> lifeless: Misunderstood.
<spiv> Why wouldn't _StackedParentsProvider([remote_repo, other_repo]) work?
<abentley> lifeless: You can't do SSP with a RR and its fallback repositories, because that will give infinite recursion.
<abentley> spiv: The StackedParentsProvider must be used in the implementation of RR.get_parent_map
<spiv> I think there is a lot of confusion because you're talking about a hypothetical version of RemoteRepository, and we're talking about the current actual RemoteRepository.
<spiv> Ok.
<abentley> spiv: I'm talking about one where we have fixed this problem.
<abentley> That stacking is broken.
<spiv> Until the patch is published, it's hypothetical ;)
<abentley> And ideally, killed the duplicate code.
<abentley> spiv: Are you saying you don't want me to discuss how to fix this problem?
<lifeless> abentley: so it seems to me that caching in RR is unrelated ot the core issue which is that RR.get_parent_map doesn't know how to retrieve data from fallback repo's
<spiv> So it seems to me that it's unnecessarily inconvenient to construct a FooParentsProvider from a callable.
<abentley> lifeless: The common thread is a lack of use of existing ParentsProvider code.
<spiv> Which means that you can't do e.g. _StackedParentsProvider([remote_repo._private_get_parent_map, ...]), you have to create an object with a get_parent_map attribute.
<abentley> spiv: It's an interface.
<lifeless> abentley: what I'd be inclined to do is consider the current get_parent_map as the binding to the remote server, and rename it to _get_parent_map, then have get_parent_map which is built on a self._pp, which is a SPP([self._get_parent_map, fallback1.get_parent_map, ...])
<spiv> Which seems more like a flaw in the *ParentsProvider(...) APIs than RemoteRepository.
<spiv> That said, it's easy to construct a helper to adapt a callable to an object with that attribute.
<spiv> Robert's suggestion sounds fine as well.
<spiv> Well, I guess lifeless's suggestion still needs to address the "there needs to be an object with a 'get_parent_map' attribute that is the underlying non-stacked get_parent_map"
<abentley> spiv: You wouldn't consider the commit code flawed because it expects a branch to have a last_revision_info method.  Why would StackedParentsProvider be flawed because it expects a parents provider to have a get_parent_map method?
<spiv> But that's easily solved either by making a new class to hold it, or by making an alternative constructor for SPP that takes callables rather than objects with get_parent_map.
<spiv> Because it only demands a single attribute of the object, a callable one.  So it could just as well take the callable directly, which makes problems like this one less messy.
<abentley> I was responding to "it's unnecessarily inconvenient to construct a FooParentsProvider from a callable", and the suggestion that StackedParentsProvider take a callable instead.
<lifeless> spiv: its easy enough to write CallableParentsProvider, to adapt; though as get_parents_map is critical path for log and other deep history operations that may be problematic
<spiv> Man, I make a lot of typos sometimes.  "it seems to me that it's unnecessarily inconvenient to construct a FooParentsProvider from *an object when all it needs is a* callable"
<spiv> lifeless: right
<spiv> (If it's that much of a critical path those classes would be holding references to callables rather than parents providers already, though...)
<jml> hi
<jml> igc:  hello :)
<igc> hi jml
<jml> lifeless, abentley: I have a loom problem.
<jml> I just did combine-thread on the wrong thread
<jml> how can I undo this?
<lifeless> jml: is your loom recorded?
<jml> lifeless: I probably hit record some time in the distant past
<lifeless> jml: ok then thats not so easy
<lifeless> jml: plan b, create-thread to recreate the thread you deleted
<lifeless> and use pull -r to reinstate its top
<spiv> You could use "bzr heads" to find the old tip of that thread.  The head with a nick of the old thread's name is probably the one you want.
<lifeless> *tip*
<spiv> Wow, lifeless's accent is now leaking on to IRC ;)
<jml> spiv: heads doesn't find it.
<lifeless> spiv: its not a head
<lifeless> jml: log --show-ids on the thread above
<jml> lifeless: it was the top thread.
<lifeless> jml: if it was the top thread it will be a dead head
<spiv> lifeless: oh right, he probably had it merged into the parent loom
<spiv> s/loom/thread/
<jml> ahh there we go.
<spiv> s/parent/higher/
<jml> thanks
<jml> lifeless: incidentally, how would you feel about a loom patch that aliased up-thread to "up" and down-thread to "down"?
<lifeless> jml: fine
<spiv> abentley: did you have any thoughts on http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081114060525.GJ31377%40steerpike.home.puzzling.org%3E ?
<spiv> abentley: did you have any thoughts on http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081114060525.GJ31377%40steerpike.home.puzzling.org%3E ?
<gour> igc: hello. have you seen the latest activity in bug #232177 ?
<ubottu> Launchpad bug 232177 in bzr-fastimport "Better darcs support needed" [Undecided,New] https://launchpad.net/bugs/232177
<gour> darcs-fast-export makes bzr's fast-import really slow in comparison with git's :-(
<igc> hi gour
<gour> igc: how are you?
<igc> gour: so bzr-fast-import is working, just slow, is that it?
<igc> gour: not too bad at the moment thanks
<gour> igc: yes, i tried it with smaller repo, cause it took too long for e.g. darcs-unstable
<gour> *repos
<igc> gour: almost recovered from one lot of surgery with another lot coming later this week
<gour> igc: i'd like that LP people add darcs import to LP
<gour> igc: i'm glad you are doing fine. we pray that everything will be good
<igc> gour: be sure to raise that then as a bug against LP
<igc> gour: thanks
<gour> igc: i added comments to https://answers.launchpad.net/launchpad-bazaar/+question/41438 if some of You (bzr devs) think it is good thing, it would be nice to comment
<gour> igc: is question enough or better to create a bug?
<igc> gour: create a bug please
<gour> igc: ok
<gour> igc: done. bug #298933
<ubottu> Launchpad bug 298933 in malone "support for darcs import" [Undecided,New] https://launchpad.net/bugs/298933
<igc> gour: thanks
<gour> igc: do you take care about your diet?
<igc> gour: very much so
<gour> igc: good boy ;) that's VERY important...
<army> bazaar 1.9 bzr-svn 1.45 , macosx 10.5 macports;  bzr checkout from a svn trunkï¼bzr co http://www.prestashop.com/publicsvn/trunkï¼ï¼error occured ;bzr: ERROR: footer.php is already versioned
<army> is it a bzr-svn's bug?
<asabil> hi all
<asabil> is there a way to get bzr-git work over http ?
<visik7> I need to remove some files that lives in my history that are HUGE and when I mean huge I mean 600mb  that is not anymore in the tree, they are introduced at revision 4 and removed at revision 8,  hmeland told me to use rebase but I really dunno how to do it
<Odd_Bloke> asabil: I suspect it involves writing the code to do that.  jelmer will know more.
<asabil> oki thanks
<hmeland> visik7: I haven't use rebase much myself, but I think something like this should work: "bzr branch -r 3 big-branch new-branch; cd big-branch; bzr rebase -r 5..7 ../new-branch; bzr rebase -r 9.. ../new-branch"
<hmeland> If revisions 4 and/or 8 do anything else than add/remove the now-unwarranted files, you'll have to do some manual merge-trickery to retain those interesting bits.
<asabil> visik7: I think you can also use bzr replay
<vila> hi all
<lifeless> hi vila, was your flight back pleasant?
<tetha_> oh dear. someone pushed me into really crazy ideas -- extending literate programming to large software using event streams and dotfiles to chain things together
<vila> lifeless: Pleasant may too strong a word :) Delayed 7h at Brisbane broke all connections adding a day in Singapore... luckily I avoided French pilots strike
<vila> lifeless: be careful what you wish for... I should not have wish to stay longer in Australia :)
<spiv> vila: heh
<spiv> vila: bad weather at Brisbane?
<vila> lifeless: so, pleasant... yes, but having only slept ~12h (cumulated) since last Friday ...
<spiv> Ouch!
<spiv> Go to bed :P
<vila> spiv: not even, some "noremal" delay of 2 or 3 hours at first. but then a verification requiring some pieces to come from Sidney
<spiv> That's pretty crummy.  I'm glad you eventually made it home!
<vila> It was interesting to see how they were able to find an hotel for the ~300 people concerned and re-book all the flights  (with the same numbers 24 hours later)
 * spiv -> bed
<vila> I arrived a couple of hours ago, but my I doubt I will work today (or produce anything deserving to be called work :)
<vila> spiv: I hesitate to do the same :) I'd like to find back the right schedule :)
<asabil> would it be possible to have the bzr-svn in the bzr PPA usable ?
<jelmer> asabil, see bug 293009
<ubottu> Launchpad bug 293009 in bzr-svn "Bzr-svn conflicts with bzr in the PPA" [Undecided,New] https://launchpad.net/bugs/293009
<asabil> jelmer: ok thanks, but what about a fix ?
<asabil> it is just an
<asabil> organization issue
<jelmer> asabil, not sure, John is doing most of the PPA uploads
<asabil> I guess it would make everyones life easier if the uploads were made in sync
<jelmer> asabil: The releases of bzr and bzr-svn aren't made in sync
<asabil> hmm ok
<fullermd> It's all a sneaky underhanded method of tracking how many people the the PPA.
<fullermd> WTF?  s/the/use/.  Who stole my typing fingers?
<jelmer> Perhaps we should pull bzr-svn from the PPA unless somebody volunteers to maintain it
<jelmer> s/unless/until/
<asabil> is it that hard to maintain ?
<jelmer> It means 4 uploads to the PPA
<jelmer> *per package*
<jelmer> I maintain ~10 bzr-related packages in Debian, so uploading to PPA as well would be quite some overhead
<cprov> jelmer: have you tried auto-ppa (from jkakar) ?
<jelmer> cprov, Yes, but it has several issues that would need to be fixed first
<cprov> jelmer: uhm, are they *hard* ? maybe I could help you guys.
<cprov> jelmer: also, are you absolutely sure you need rebuilds in all ubuntu series ?
<jelmer> cprov, Yeah, it's a nontrivial amount of work to fix autoppa
<jelmer> cprov, the bzr PPA itself has builds for all Ubuntu series
<cprov> jelmer: yes, I know we do build for all series, my question was if you know that you need to or it was done just because it was easier.
<jelmer> cprov, I'm not sure, I know we do still get complaints if e.g. something breaks or is out of date for dapper
<cprov> jelmer: it's not easier to answer (I'd not be able to do that myself) it requires inspecting the evolution of the build-depedencies.
<cprov> jelmer: right, dapper is quite old compared to hardy
<cprov> jelmer: maybe we would be good building for dapper and hardy only and copying binaries to intrepid & jaunty
<cprov> jelmer: we could do the test in a separate PPA, I'm sure users would spot problems very quickly if they exist.
<jelmer> yeah, that would certainly help, but still means it's a nontrivial amount of work
<johncc> Hello folks.  Just to let you know, I think the bzr-bash-completion plugin on the site is rather broken. You may want to move it to the obsolete section
<johncc> It doesn't work with the current format of the help output
<johncc> It's pretty hideous anyway :)
<cprov> jelmer: half of the non-trivial work if we don't need to rebuild for intrepid & jaunty.
<cprov> jelmer: also consider that the debian source can be uploaded as it is to hardy.
<cprov> jelmer: leaving the non-triavial work only for the dapper packages.
<jelmer> cprov: Doesn't the version string have to be fixed?
<cprov> jelmer: no, if you are not rebuilding
<cprov> re-upload debian source to hardy, wait it to build, copy source and binary to intrepid & jaunty.
<jelmer> cprov: Ah, ok - that's new?
<jelmer> cprov, How does PPA know what series an upload is targetted?
<cprov> jelmer: dput upload path
<cprov> jelmer: the changelog will be target to 'unstable' but you would upload to ~jelmer/ubuntu/hardy/
<cprov> jelmer: then oddness would be isolated in the dapper packages, which would probably need tweak in python-central/python-support, anyway.
<jelmer> cprov: I think I'll leave dapper alone for now, uploading hardy and friends should already make a lot of people happy
<jelmer> cprov, Thanks!
<cprov> jelmer: great, ping me if you have problems, i'm more than happy to help you solving those issues with bzr-ppa.
<jelmer> cprov-lunch, It seems if I upload a source package to hardy I can no longer upload it to intrepid?
<james_w> jelmer: correct. you can copy it, but that requires copying the binaries as well.
<jelmer> james_w: ah, ok - thanks
<jelmer> seems like a silly restriction to me though...
<james_w> jelmer: it's a requirement of the pool structure, which is vital for real archives. PPAs don't have to use that structure though.
<jelmer> james_w, ah, makes sense
 * jelmer isn't a big fan of web interfaces, would be nice to see that be a bit more flexible for PPAs
<jelmer> james_w, while you're here... :-)
<jelmer> james_w, any bzr-builddeb news ? :-P
<james_w> have you looked at the launchpad API?
<james_w> it's not there yet, but will satisfy all your needs eventually I expect
<james_w> not yet, sorry. I should have the time to do all the merges this week.
<jelmer> ah, cool
<jelmer> james_w, It would be nice if ubuntu-dev-tools had a tool for that sort of thing, using the Launchpad API
<james_w> I'm sure it will in time
 * jelmer wonders how politically complicated it would be to upload ubuntu-dev-tools to Sid
<james_w> hmm
<derekS> hello all. i have a really n00b question. I am looking through this and _something_ doesn't look right. is it true that i don't need a true bazaar server, i can just use my sftp server?
<derekS> it will only be me checking in and out...
<derekS> so i don't care _that_ much about permissions
<lamalex> derekS: that is true
<derekS> lamalex: is there any downside to it?
<lamalex> downside to what
<derekS> to only using an sftp server?
<lamalex> no..? I mean, there's no such thing as a "true bazaar server"
<lamalex> that's the whole point of dvcs
<lamalex> if more people are working on it, then having a centralized location can be handy, but it's not required
<jdong> derekS: if there's a "downside" it's that it's not quite as fast for network operations.
<lamalex> so the only downside to using sftp is it's a little bit slow iirc
<jdong> but that's a really minor downside compared to the convenience
<jdong> bzr is really one of the last VCSes that support serverless operation well
<jdong> and that's one of the things that makes it my favorite VCS
<derekS> lamalex, jdong: sweet!
<derekS> now, i guess kinda important, i use windows for home, linux for work, how well is windows support? i have the cygwin version, is there a gui type client
<lamalex> http://bazaar-vcs.org/WindowsDownloads
<thrope> are you supposed to be able to add files with tortoisebzr? I only have a very few options on existing files (diff) - no option to add a new file
<derekS> lamalex: thanks!
<derekS> lamalex: 2 last questions... i use tortoisesvn, how does tortoisebzr compare? is it as stable? Also, is there an easy svn to bzr conversion?
<lamalex> derekS: you can use bzr to talk to svn via the bzr-svn tool, I also think you can convert svn to bzr easily, but im not sure
<lamalex> i have no idea how tortoisebzr is, I don't use windows
<jelmer> derekS, you should be able to convert from svn to bzr with bzr-svn's "bzr svn-import" command
<derekS> lamalex: thanks :)
<derekS> jelmer: i assume i have to install a plugin?
<jelmer> derekS, yes, the bzr-svn plugin
<jelmer> it's included with the bzr setup on windows
<thrope> derekS: I haven't had much luck with tortoisebzr
<thrope> I was hoping to use it to collaborate with some windows users, but I don't think it is in a usable state
<thrope> it looks very promising - not trying to be negative - just saying its not there yet
<Sidnei> hello there, i remember seeing a tutorial about how to keep your main branch in bzr and mirror it to subversion, but google can't find it, anyone remembers where that is?
<derekS> thrope: i might try it out, i will let you know :)
<jelmer> Sidnei, It should be very simple - just "bzr push <svn-location>"
<Sidnei> jelmer: i get "bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
<Sidnei> '
<jelmer> Sidnei: You can't push to the repository root, only to /trunk
<jelmer> Sidnei: For the first push, use 'svn-push'
<jelmer> bzr svn-push, that is
 * Sidnei tries
<Sidnei> jelmer: great, i re-did it and it worked this time. i think i had messed up some command before.
<jelmer> cool
<Sidnei> fwiw, what i did: bzr branch <svn>; bzr merge <bzr-main-branch>; resolve conflicts; bzr svn-push <svn>
<Sidnei> may or may not be the right way, but achieved what i wanted to do :)
<rockstar> beuno, now it's leaking about 4 mb/request
<bkuhn> Is it ok to show up and ask newbie questions here?
<beuno> rockstar, so caching isn't to blame?
<beuno> bkuhn, it absolutely is!
<beuno> we love easy questions
<rockstar> beuno, this is a vanilla checkout.  No changes at all, except my implementation of the MemoryMiddleware
 * Sidnei doesn't want to know what's leaking 4mb/request 
<bkuhn> I am trying to set up a bzr instance that many developers can push and pull from.  I have it working so that zr branch bzr+ssh://user@HOST/PROJECT works.
<rockstar> Sidnei, loggerhead
<bkuhn> but I cannot get it to push
<bkuhn> It says: "Transport operation not possible: readonly transport"
<rockstar> bkuhn, do you have write permissions in the folder?
<bkuhn> I find conflicting information online about whether or not bzr+ssh can be used for pushing.... it seems like it can.
<bkuhn> yes.
<rockstar> bkuhn, it can be used for push, yes.
<bkuhn> I'm using a single uid currently.
<bkuhn> BTW, it's bzr 1.3.1-1ubuntu0.1
<bkuhn> (on both client and server)
<beuno> rockstar, it went from 100kb to 4mb?
<kumi> that's a pretty old version
<beuno> bkuhn, that should work
<bkuhn> kumi: it's what's in hardy. :)
<beuno> bzr+ssh isn't a readonly transport
<beuno> unless the user can't write
<bkuhn>  ah, this may be pertinent:  Cannot lock LockDir(chroot-140973836:///PROJECT/.bzr/branch/lock)
<bkuhn> the appropriate UID has write on that dir though
<beuno> bkuhn, right, so it can't write
<bkuhn> (in fact, it's the owner)
<rockstar> beuno, well, I think the 400k was the kernel doing some clever things to change reporting, but the RSS increases 4 megs every request.
<beuno> bkuhn, can you ssh into it and try to write that exact same fil?
<rockstar> beuno, it'd be nicer if I could read directly form /proc/<pid>/mem
<bkuhn> beuno: I don't want the user to be able to get a shell generally, so I was having it call the bzr command directly with command=.  I should have mentioned that.
<bkuhn> I will try it without the command=
<kumi> are you using bzr_access?
<bkuhn> kumi: not yet, but I want to.  Is there a package that builds easily for hardy for it?
<kumi> bzr_access is just a python script
<bkuhn> kumi: URL?  (net.search doesn't seem to give a canonical place in the first few hits...)
<Sidnei> rockstar: if you are using some sort of caching there, making sure your cache key is computed correctly would be my guess. i've been bitten before by computing a cache key that would change for every request.
<bkuhn> beuno: ok, so I turned off command= ... if I log in, these commands work fine:
<bkuhn> touch /path/to/project/.bzr/branch/lock/test
<kumi> I'm just using bzr_access from the bzr.dev branch. In the contrib/ folder
<bkuhn>  
<bkuhn> rm /path/to/project/.bzr/branch/lock/test
<bkuhn> kumi: thanks
<beuno> bkuhn, maybe it's trying to write to the wrong paths?
<kumi> bkuhn: maybe try "bzr break-lock"
<jelmer> bkuhn: The path in the URL is interpreted relative to the fs root
<rockstar> Sidnei, I don't think it's a cache issue now.  I see the kernel doing its best to clean up memory, so, while the number is generally climbing, it drops now and then.
<bkuhn> jelmer: yeah, I tried to fix that by using bzr serve --directory /path/to in the command= in authorized_keys
<rockstar> There's a leak somewhere.
<visik7> anyone who know how to use rebase ?
<bkuhn> I wish there were a tutorial somewhere about setting up one's own server.
<rockstar> Usually, the kernel cleans it up after a jump of 32Mb in one request.
<jelmer> bkuhn, I suspect that bit just works if you make it run on a specific TCP/IP port
<Sidnei> rockstar: maybe you have some sort of cycle that is preventing objects from being garbage collected? that's common with in-memory caching too.
<bkuhn> jelmer: how does it do auth in that case?
<jelmer> bkuhn, It doesn't, that's usually just used for readonly access
<jelmer> bkuhn: Are you specifying --allow-writes ?
<jelmer> bkuhn, that may actually be it
<bkuhn> jelmer: yeah, it seems to work, now, actually, but I still get this error: his transport does not update the working tree of: bzr+ssh://USER@HOST/PROJECT/. See 'bzr help working-trees' for more information.
<lamalex> bkuhn: because you're pushing to a working tree vs. a repo
<beuno> bkuhn, that is correct
<kumi> I don't think that's an error
<beuno> remote trees don't get updated
<beuno> remote _working_ trees that is
<bkuhn> lamalex: ah, how do I make it a repo on the server?  I just bzr init...
<beuno> bkuhn, just pushing it
<beuno> it won't create a working tree
<beuno> create it locally, and push it
<lamalex> indeed
<lamalex> bzr rules :)
<bkuhn> beuno: so you are saying, do a bzr init on the client side, then push it?
<jelmer> bkuhn, or on the server, run "bzr remove-tree" toi remove the working tree
<derekS> hi guys, another question, is it possible to branch subfolders/files, but not a whole checkout?
<jelmer> derekS, not yet
<Sidnei> is there any kind of caching on the client-side of bzr? i moved a branch around in my remote server to the location of another branch i just deleted and now trying to branch on my local machine I get 'ERROR: no such file' for one of the files
<derekS> jelmer: hmm ok, is that coming in the near future?
<kumi> Sidnei: bzr info -v will show you the cached locations
<bkuhn> jelmer: thanks, remove-tree worked great!
<jelmer> derekS, it is planned, not sure how soon though
<derekS> jelmer: thanks!
<visik7> hmeland: hi I'm still digging with rebase
<kumi> Hm... BzrLog is a cute little app
<visik7> hmeland: I've followed your advice:"bzr branch -r 3 big-branch new-branch; cd big-branch; bzr rebase -r 5..7 ../new-branch; bzr rebase -r 9.. ../new-branch"
<visik7> hmeland: but on the last command I get bzr: ERROR: Requested revision: u'12' does not exist in branch: BzrBranch6('file:///home/visi/Desktop/big-branch/')
<visik7> hmeland: don't worry I've backups but I can't get forward
<bkuhn> Thanks everyone, I have things working now well with bzr+ssh:// using bzr_access.  Now, to figure out how to give anonymous http:// access w/ apache.  If anyone has a tutorial URL handy, I would appreciate it. :)
<beuno> bkuhn, use loggerhead
<beuno> launchpad.net/loggerhead
<jelmer> bkuhn, If you mean anonymous access to clone the bzr branch, just make sure the branch is accessible over http somehow, no special configuration required
<beuno> ah, right
<bkuhn> jelmer: yes, perfect!
<beuno> that's probably what he meant  :)
<bkuhn> beuno: loggerhead looks interesting, but I'm already working with Trac and am used to it.  I've been looking at the Trac Bzr plugin.
<bkuhn> Thanks again for all your help.  You got me up and running: http://code.softwarefreedom.org/projects/podjango/wiki/WikiStart
<bkuhn> later
<Sidnei> not good. i think i messed up my repo :(
<Sidnei> is there a way to clean up all bzr:xxx properties from an svn repo and start fresh?
<rockstar> beuno, do you find that much of loggerhead is overly complicated?
<beuno> rockstar, sometimes, but I guess I don't get as lost now
<beuno> I really had a hard time at first
<beuno> it's not so much complicated as it is a bit spread around
<visik7> hmeland: if you would help me I'm here :)
<lifeless> jelmer: ping
<jelmer> lifeless, pong
<lifeless> I'm making changes to commit again
<lifeless> I'd like to know what will work better and worse for you, from my options
<lifeless> Sidnei: I don't know, jelmer may know.
<lifeless> jelmer: so, the change I'm starting is to stop touching all paths
<lifeless> jelmer: and instead have an entirely delta orientated interface
<jelmer> Sidnei: the bzr: properties are used by bzr-svn
<jelmer> lifeless: Cool
<lifeless> jelmer: internally, xml inventory commit builders will need to touch all paths
<jelmer> lifeless,  if the interface is designed properly, bzr-svn won't have to
<lifeless> jelmer: I don't know what bzr-svn will need to do
<lifeless> jelmer: the reason xml ones have to, is to set last-changed fields during merges.
<jelmer> so that could be a nice performance improvement for large trees
<lifeless> conceptually they don't actually touch every path, rather its delta(p1, p2) and delta(p1,p3) etc, and then for every different path do a ancestry check
<lifeless> jelmer: would getting an iterator in the builder be better for you than having the builder called once for every altered path ?
<jelmer> lifeless: What exactly do you mean by having an iterator in the builder?
<jelmer> providing an iterator with the changes to the builder?
<jelmer> It's easiest for me if I can discover the changed paths
<lifeless> jelmer: builder.here_is_a_delta(tree.last_revision(), tree.iter_changes(tree.basis_tree())
<lifeless> vs
<lifeless> for change in tree.iter_changes(tree.basis_tree()): builder.changed_path(change)
<jelmer> the first would be preferred
<jelmer> since the order in which I have to report changes to SVN is somewhat strict
<lifeless> so you'll have to buffer either way I guess
<lifeless> as iter_changes can jump around
<mwhudson> lifeless: so what did you want to say about paste?
<lifeless> mwhudson: s/say/know/
<mwhudson> 'talk about'
<lifeless> mwhudson: lsprof seems to be working fine on single requests
<lifeless> but we miss the top of the stack because we profile a bit of middleware; and we have to exhaust the generate from the app below us
<lifeless> if we take a single thread lock and define close, it seems to me that we could let the generator be
<lifeless> but what would the framework do
<lifeless> would it try to reenter a new request in the same thread
<lifeless> etc
<lifeless> etc
<mwhudson> paste's httpserver is a one-thread per request with a threadpool thingy
<jelmer> lifeless, if "delta" is not the full delta at once, I'll indeed have to buffer either way
<mwhudson> lifeless: so i guess you'd mess up the ability to be processing more than one request at once, but hey, cpu bound anyway
<lifeless> jelmer: iter_changes(selected=foo) will give you foo, but then jump to bar, or in corner cases even jump to to the root
<lifeless> jelmer: it is the full delta at once, but its an iterator not a list
<lifeless> mwhudson: the debug middleware uses a lock
<jelmer> lifeless: right, so that means buffering
<lifeless> mwhudson: so its single threaded
<mwhudson> lifeless: i guess another fun thing is that loggerhead doesn't return a generator anyway, it calls the 'write' function returned from start_response
<lifeless> mwhudson: uggle. Ok, I'll leave it as-is.
<Sidnei> lifeless: it was a small repo, just stomped-fixed it: svn export; svn rm; svn import
<jelmer> Sidnei, if the properties are a problem, use "bzr dpush" to import the changes
<derekS> does anyone have bzr installed throuhg cygwin
<Sidnei> jelmer: don't quite get what that means. the problem was that i had some ghosts and missing parents due to trying different things, so i could checkout or branch from the svn repo but trying to branch from that branch would complain about missing files or revisions
<jelmer> Sidnei, Was this with bzr-svn >= 0.4.15 ?
<Sidnei> jelmer: latest from ppa, so i guess yes
<jelmer> Sidnei, latest from PPA from a couple of hours ago?
<jelmer> otherwise it's a much older version
<Sidnei> jelmer: about 6 hours ago i think
<Sidnei> svn 0.4.15dev0
<Sidnei>     Support for Subversion branches
<jelmer> Sidnei, Can you be a bit more specific wrt to  the errors you were getting? What errors after which commands, etc?
<Sidnei> jelmer: let me see if i can get it back into failing, hold on
<markh> Sidnei: hi! :)
<Sidnei> hey markh !!
<lifeless> derekS: I think that that is a 'no'
<derekS> lifeless: i take it you are right :)
<Sidnei> jelmer: will you be around in 30?
<jelmer> Sidnei, not in 30, but probably in about an hour from now
<Sidnei> jelmer: ok. i will try to get some more info for you
<jelmer> Sidnei, cool, thanks
<derekS> lifeless: when i try to do a push to my sftp server i get: bzr: ERROR: exceptions.IOError: [Errno 0] Error
<lifeless> derekS: interesting; please file a bug, you can get a backtrace from the end of ~/.bzr.log
<derekS> lifeless: let me look around a little more :) then i can file a bug AND fix it
<lifeless> ok
<derekS> lifeless: i am wondering if it is the format of my sftp statement. I have bzr push "sftp://[user]@[domain]/[directory]"
<derekS> that _should_ work
<lifeless> derekS: that looks fine
<derekS> should the directory be relative?
<derekS> because it is relative to my home
<lifeless> yes, thats fine
<lifeless> erm no
<lifeless> /~/ is relative to home
<derekS> same error with that :)
<thrope_> does anywhere other than launchpad offer bazaar hosting?
<LarstiQ> thrope_: anything where you can upload files in principal
<thrope_> LarstiQ: I mean with a nice interface for diffs etc. as well
<thrope_> LarstiQ: anything like these nice services, github, bitbucket etc (other than launchpad)
<LarstiQ> thrope_: I'd assume so, but I don't know.
<LarstiQ> maybe I should start one if they don't exist, hmm
 * LarstiQ goes to bed now though
<lifeless> savannah has bzr support
<lifeless> though they seem, odd, about actually embracing loggerhead etc
<mwhudson> spiv: something has gone wrong here, right? http://pastebin.ubuntu.com/73525/
<visik7> anybody knows how to remove a file inside the bzr repo ?
<visik7> a plugin ? I'm not able to do it using rebase ( probably I dunno how to use it)
<dobey> bzr delete file?
<spiv> mwhudson: sure looks like it
<spiv> mwhudson: please file a bug
<visik7> dobey: no I mean from the repository
<mwhudson> spiv: any chance of a fix today?
<mwhudson> (this is blocking 1.9 getting into the next release of lp :()
<spiv> mwhudson: It's probably easy to fix, although that said the code looks correct at a glance...
<mwhudson> hm, i think launchpad is probably constructing permissiondenieds a bit strangely
<spiv> mwhudson: ah, hmm
<spiv> mwhudson: the code expects ('PermissionDenied', 'path', 'extra info in English') on the wire
<mwhudson> also...
<mwhudson> mwh@grond:a$ bzr -Dhpss push bzr+ssh://localhost/hope
<mwhudson> bzr: ERROR: Permission denied: "None": : [Errno 13] Permission denied: '/hope'
<spiv> You seem to be sending the last two parts reversed.
<spiv> Right.
<mwhudson> that isn't striking in it's beauty
<spiv> The serialisation and deserialisation in 1.9 seem to agree that the order should be ('PermissionDenied', path, extra).
 * mwhudson tries some things
<spiv> Are you sure you're constructing your PermissionDenied exception correctly?
<mwhudson> no
<visik7> jelmer: where is your bzr-remove-revisons plugin ? I can't find it on your samba.org
<jelmer> visik7, http://people.samba.org/bzr/jelmer/bzr-remove-revisions/trunk/
<spiv> mwhudson: I'm pretty sure the code in bzr is correct, so at this point I think the confusion is in your code.
<mwhudson> spiv: the Permission denied: "None" think is odd though
<mwhudson> (and that doesn't require launchpad to be involved)
<visik7> jelmer: is empty
<visik7> jelmer: and branching from it return an error
<jelmer> visik7, it's a bzr branch
<visik7> oh
<jelmer> visik7, works fine here
<visik7> in another branch there was the log so I thought that was the same for this
<visik7> jelmer: does remove-revision clean up my .bzr ?
<jelmer> visik7, no, it allows you to remove explicitly mentioned revisions from your repository
<visik7> yes, I mean: I've a huge file erroneously committed
<spiv> mwhudson: hmm, that is odd.
<jelmer> visik7: You don't want to use it on a revision that's still part of branch history, since bzr's ghost handling has some issues atm
<mwhudson> spiv: where is the deserialization code?
<jam> spiv, lifeless, poolie: Sorry I missed the standup. Today was mostly about catching back up with mail, etc after getting back home.
<visik7> jelmer: :(
<spiv> mwhudson: bzrlib/remote.py
<spiv> mwhudson: apparently a "if len(err.error_args) >= 2" needs to be "... >= 1".
 * spiv goes off to find the gap in the multiple unit tests that already exist for this code path
<mwhudson> spiv: well, no?
<mwhudson> depending on what get_path() does
<spiv> mwhudson: get_path is an independent issue to the optional extra info.
<visik7> jelmer: could you suggest me a way to remove a huge commit of files introduced at revno x and removed at revision x+7 ? the whole commit includes only the files I want to remove the are no changes at other files
<spiv> mwhudson: the server may return just a ('PermissionDenied', path), or a ('PermissionDenied', path, extra).
<jelmer> visik7: Simply uncommit those revisions?
<visik7> jelmer: but I'm at revizion x+84
<visik7> revision
<Sidnei> jelmer: sent via email
<mwhudson> spiv: it seems that context in _translate_error is {'path': None}
<spiv> mwhudson: and the client deserialiser might ignore the path if it already knows it from the context passed to _translate_error (which should be most of the time now, except when PermissionDenied happens very unexpectedly)
<mwhudson> spiv: which doesn't seem rightr
<spiv> Ah, so it is.  That seems to be a bug in RemoteTransport
<jelmer> Sidnei, thanks
<visik7> jelmer: and if I run bzr uncommit -r x it will uncommit from now to x-1
<spiv> RemoteTransport didn't exactly handle PermissionDenied gracefully before 1.9 either...
<mwhudson> spiv: yes, that's what i'm finding
<mwhudson> mkdir calls _call2 calls _translate_error without passing on relpath
<jelmer> visik7, you can use rebase or replay to replay all revisions except for the problematic ones
<mwhudson> spiv: anyway, clearly a client problem, SEP field activated :)
<mwhudson> spiv: want me to file a bug though?
<spiv> mwhudson: please do, but your server is still sending crack
<mwhudson> spiv: not in my local copy it's not :)
<visik7> jelmer: I'd try but I don't understand how I've tried to run this sets of commands suggested by hmeland " bzr branch -r 3 big-branch new-branch; cd big-branch; bzr rebase -r 5..7 ../new-branch; bzr rebase -r 9.. ../new-branch"
<jelmer> visik7, I would suggest something like:
<jelmer> bzr branch -r3 big-branch new-branchj
<visik7> jelmer: but on the last command I get the error saing that big-bransh has no revno 9
<jelmer> cd new-branch && bzr replay -r9.. ../big-branch
<mwhudson> spiv: https://bugs.edge.launchpad.net/bzr/+bug/299254
<ubottu> Launchpad bug 299254 in bzr "when RemoteTransport.mkdir raised PermissionDenied, the path is always None" [Undecided,New]
<spiv> mwhudson: thanks
 * spiv heads off to the dentist
<visik7> jelmer: how could be possible that there's a confilt on a file that isn't touched in the 2 commits ?
<jelmer> visik7, hard to say without looking at the specifics
<visik7> mmm
<jelmer> visik7: you'd want different revisions than in my example though if you want to exlucde just two commits
<visik7> sure
<jfroy|work> jelmer: I was hoping a clean checkout (with clean caches) of a svn branch I could not branch from would fix the problem, but unfortunately not. I still get a missing revision exception.
<jfroy|work> bzr: ERROR: Revision {<user email>-20081015184449-6l6y2bc2tjkl22dg} not present in "6604@be02940b-5f7b-422b-ba6c-1eb93f4884eb:<path>".
<jelmer> jfroy|work, also in a new repository ?
<jfroy|work> This occurs when I try to push the branch into a different repository, or when I try to use qbrowse from bzr-qt
<jfroy|work> jelmer: yes, brand new everything, pretty much
<jelmer> jfroy|work, and directly branched from svn ?
<jfroy|work> correct
<jelmer> jfroy|work, what's the full backtrace?
 * jfroy|work pasted http://pastie.textmate.org/317310
<jelmer> jfroy|work, was that particular revision perhaps pushed with a bzr-svn prior to 0.4.15 ?
<jfroy|work> Possibly
 * Sidnei detects a possible pattern :)
<visik7> jelmer: but should I reply also revisions from after the introduction of big files until removed and then after the commit where I remove them ?
<jelmer> jfroy|work, does the branch path perhaps have bzr:text-parents set but not bzr:test-revisions ?
<jfroy|work> No idea what those are -- I wouldn't have set those manually, in any case.
<jelmer> jfroy|work, they should be file properties set by bzr-svn on the branch root
<jelmer> visik7, yes
<jfroy|work> jelmer: interesting, flushed the svn-cache directory, subversion.conf file, and made a new checkout without a repository.
<jfroy|work> e.g. a standalone branch
<Sidnei> jelmer: that seems to be the case on my repo
<jfroy|work> Trying to push that also failed, but the bad revision is different
<jelmer> Sidnei, and that particular revision was pushed with pre-0.4.15 bzr-svn ?
<jfroy|work> Actually no, I take that back.
<jfroy|work> The revision number (the number before the @) is the same, and so is the UUID (or is it a checksum?)
<jfroy|work> The <path> component of it is different however
<Sidnei> jelmer: 0.4.15dev0 afaict
<jfroy|work> But the left-hand side is different
<jfroy|work> It says {svn-v4:be02940b-5f7b-422b-ba6c-1eb93f4884eb:<path>:7882} instead of {<email>-20081015184449-6l6y2bc2tjkl22dg}
<jelmer> Sidnei, ah, "bzr diff" broke for you?
<jelmer> jfroy|work, It looks like you're using bzr-svn trunk again
<jfroy|work> jelmer: bzr:text-revisions is set to an empty string
<visik7> I can't get rid of those commits
<jfroy|work> jelmer: I am not, using 0.4
<visik7> I'm going mad
<jelmer> jfroy|work, only trunk will write svn-v4:.. style commits
<jfroy|work> That may have been in the past
<jfroy|work> I did make a few pushes / commits with bzr-svn trunk a month ago or so
<igc> morning all
<Sidnei> jelmer: bzr branch from a bzr branch broke for me
<jelmer> Hey Ian :-)
<jelmer> jfroy|work: That's most likely the cause of this :-(
<jfroy|work> jelmer: best option would be to wipe all bzr:* properties from the repository
<jfroy|work> *would probably be to
<jelmer> jfroy|work, Yeah
<jfroy|work> But yes, also bzr:text-parents is set, while bzr:text-revisions is empty (but present)
<Sidnei> jelmer: i *might* have checked in with 0.4.14 on that revision
<Sidnei> jelmer: but im mostly confident it was 0.4.15dev0
<jelmer> Sidnei, The issue with "bzr diff" is a known bug in bzr
<jelmer> Sidnei, does that particular revision have bzr:text-parents set but not bzr:text-revisions?
<Sidnei> jelmer: yes
<Sidnei> http://paste.plone.org/24999
<rockstar> abentley, is there a test class in the bzrlib test suite that will give me a branch with more than a few revisions?
<jelmer> Sidnei, so bzr:text-revisions is set but empty?
<Sidnei> jelmer: yup
<visik7> jelmer: no way .bzr becomes huge despite reply
<visik7> replay
<Sidnei> was about to say that
<jfroy|work> jelmer: I'm seeing that too
<jelmer> visik7: After you've run this, you need to clone the branch to get rid of any unreferenced revisions
<jfroy|work> If that's of any help :p
<visik7> jelmer: oh
<jelmer> jfroy|work, Sidnei: Thanks
<visik7> anyway I can't understand why I get the conflict
<jelmer> visik7, it's hard to say anything about it without looking at specifics
<jelmer> jfroy|work, Sidnei: does either of you perhaps have an easy way to reproduce this problem?
<visik7> jelmer: how could I do ?
<jfroy|work> jelmer: I don't even know what the problem is :p
<visik7> jelmer: how could I show you the repo ?
<Sidnei> jelmer: not easy no
<visik7> jelmer: I even can't give you a branch becouse of the size of the repo
<jelmer> visik7, well, what sort of file is ending up in a conflict? When is it changed, etc?
<visik7> jelmer: it exists from revision 1 and wasn't change until the conflict
<jelmer> Sidnei, this particular file (models.py), what happened to it during that particular revision? was it changed in some way, merged from another location?
<Sidnei> jelmer: i believe i did a reverse merge to revert it to a previous revision
<visik7> jelmer: and the conflict edit the source like that : http://dpaste.com/91601/
<visik7> jelmer: and the diff of the revision that produce the confilct is: http://dpaste.com/91602/
<jelmer> visik7, and the revisions you're skipping don't touch *any* of the other files in any way ?
<jelmer> (bzr log -v on those revisions shows *only* those files?)
<visik7> jelmer: let me check for the 4th time :)
<visik7> I was using diff , log -v is much better
<visik7> yes there is a modification
<visik7> any way to import it ?
<jelmer> visik7, only manually
<visik7> :\
<visik7> so
<jelmer> (this particular modification, that is)
<jelmer> after you've applied that modification manually on top of r3, you should be able to replay the rest
<visik7> so I make a commit before the reply from X+1 Y-1 ?
<jelmer> yes
<visik7> ok
<visik7> I try
<jelmer> if not, you should be able to resolve the conflict manually and run "bzr rebase-continue". Hopefully there aren't too many conflicts
#bzr 2008-11-18
<visik7> but if a replay fail due to a conflict there is no replay continue like rebase
<jelmer> visik7, yes, you can use "bzr rebase-continue"
<jelmer> ah, no
<jelmer> nevermind
<visik7> :\
<jelmer> you can commit and run "bzr replay" again though from the point where it aborted
<visik7> nevermind seems it's working
<visik7> ok I think is ok
<visik7> now I need to clean it up branching again ?
<igc> poolie: I'd like to rename the (about to be released) diffinternals plugin to crosscheck. Is that ok with you?
<poolie> igc, that sounds better to me
<igc> poolie: cool. me too.
<jelmer> visik7, yeah, branch it to a different location
<jelmer> visik7, (replay wasn't really designed for this sort of thing)
<visik7> jelmer: I see anyway it worked so, thanks for the help and hope soon we will have something like git-filter-branch
<jelmer> visik7, cool
<p_masho> can anyone give me a helping hand.. bit confused as used to svn and cvs(spits).......
<visik7> good night thank you again jelmer
<jelmer> p_masho, hi
<p_masho> hi jelmer.. late at night here in wales.. and got this zim on my ubuntu box - http://bazaar.launchpad.net/%7Epardus-cpan/zim/pyzim/
<p_masho> so I been hacking away... and have already modified and not creaed a branch...
<p_masho> I'm looking for 1) - equivelent of svn copy foo.x bar.x ?
<jelmer> p_masho, copying a branch or a file/directory ?
<jelmer> p_masho, to copy a branch, use "bzr branch <old-branch> <new-branch>"
<jelmer> to copy a file, simple copy it using cp and then add it
<p_masho> Ok. advice.. am used to svn.. so be gentle.. please
<p_masho> I go this branch bzr branch lp:~pardus-cpan/zim/pyzim = /home/zim/pyzim on my machine
<p_masho> so I hacked that a bit and got a diff file.....
<jelmer> p_masho, what are you trying to copy? a file?
<p_masho> What I want to know is how I can create a new "version" on my machine copying all the mods I got
<p_masho> and then restore the master branch to tha release from launchpad...
<p_masho> sorrry if this sounds confusing...
<p_masho> Suppose the question really is.. first ..
<jelmer> sorry, phone..
<p_masho> How do I branch off the mods I already done and restore the "main/HEAD" to main repos
<lifeless> p_masho: to make a new branch, 'bzr branch'
<lifeless> p_masho: e.g. 'bzr branch . ../new-branch'
<lifeless> p_masho: if you haven't committed your changes, do so first
<lifeless> p_masho: I don't know what you mean about the main repos, you haven't altered the mainline afaict
<p_masho> thats the problem (as sv user) I made changes to head...
<lifeless> you have?
 * Sidnei is away: I'm busy
 * igc lunch, etc. - bbl
<jelmer> poolie1, hi
<poolie1> hi jelmer
<poolie1> spiv, thanks for that note!
<spiv> poolie1: you're welcome :)
 * spiv -> lunch
<poolie> spiv, still here?
<poolie> to build on that mail, i'd like to get a page like the smart push analysis, that for each scenario says what operations we _should_ be doing
<poolie> in other words: we have a list of what is done at the moment and we have some vectors we can apply to them but i'd like to see where the expected endpoint is too
<Peng_> Yay. "bzr heads" + ack + sed + bash == easy upgrade from subtrees to rich-roots.
<Peng_> "bzr upgrade' would've been even easier, of course. Whinewhine.
<jelmer> since lifeless doesn't appear to be here...
<jelmer> Peng_: "Patches welcome" :-)
 * Peng_ cries
<Peng_> Wait, I was upgrading a copy of bzr-svn, so I can blame you for putting me in this situation in the first place! :P
 * Peng_ hides
<beuno> Peng_, recursive-upgrade?
<Peng_> That was actually pretty painless. :)
<Peng_> beuno: ?
<beuno> I know jelmer doesn't want you to know about it
<beuno> but he wrote a plugin
<beuno> http://people.samba.org/bzr/jelmer/bzr-recursive-upgrade/trunk
<Peng_> Oh?
<jelmer> Peng, subtrees is more than just a version string
<jelmer> Peng, the inventory format is also different afaik
<Peng_> jelmer: So? I don't care. I just want to be able to convert my repos easily. I can live with it burning some extra CPU.
 * Peng_ gets grumpy when thinking about this. :P
<jelmer> Peng_: I wasn't sure what you were doing exactly, but just editing .bzr/repository-format isn't sufficient
<Peng_> jelmer: Yeah, I know. I didn't do that.
<jelmer> Ok, I'll shut up then :-)
<Peng_> I used "bzr heads" to grab all of the heads, created a new repo and a branch, and used "bzr pull --overwrite -r revid:..." to copy all of the revisions into it.
<Peng_> And...let's see...frozenset(bzrlib.branch.open_containing('.')[0].repository.all_revision_ids()) to verify it went well. :)
<poolie> lifeless: can you point me to a mail about dev3 making some loggerhead pages much faster?
<lifeless> poolie: no, there isn't one
<lifeless> poolie: there is a branch with a merge request in LP that makes lh compatible with bb-core
<lifeless> poolie: and its --development4 that works for lh, fwiw
<beuno> lifeless, about that, I didn't quite understand what you meant
<beuno> it breaks with the current bzr
<beuno> what is it that I'm missing?
<lifeless> beuno: works for me
 * beuno tests again
<beuno> lifeless, hrm, it seems to as well now for me...
<beuno> I'll run the tests and merge
<spiv> (back)
<lifeless> beuno: :P
<poolie> lifeless: but it has been measured to make some pages faster? the diff display, i'd presume?
<beuno> lifeless, so I had a b0rked copy of bzr?
<lifeless> poolie: unscientifically yes
<lifeless> poolie: revision display for instance
<beuno> lifeless, merged. Thanks for the patch
<beuno> 101  branches owned by 24  people and 1  team, 75  commits by 12  people in the last month
<beuno> ^  Loggerhead
 * beuno dances
<poolie> :)
<lifeless> beuno: no probs
<hydrapheetz> Hm, tempting to write a bazaar branch browser django app, but laziness D:
<lifeless> reuse loggerhead?
<hydrapheetz> I should try that.
 * beuno thinks "loggerheadlib" and looks at thumper 
<thumper> why me?
<thumper> beuno: JFDI
<beuno> thumper, sure sure, and world peace, and all that
<beuno> BUT
<beuno> there are some interesting opportunities to work on that
<beuno> like re-writing the log FILE bit which leaks billions of litres of memory
<beuno> maybe during UDS
<beuno> lifeless, poolie, will you guys be at UDS?
<beuno> ah!  you are!
 * beuno starts ploting on how to take advantage of their presence
<AfC> Memory being measured in terms of three dimensional volume. Neat.
<thumper> AfC: if you squeeze memory enough, you can get liquid out
<lifeless> silicon-juice?
<Peng_> Hm..what do btree indexes do for Loggerhead?
<poolie> they should make it faster
<poolie> lifeless: do you know if brisbane-core with vila's changes is now passing all tests, or not quite?
<lifeless> poolie: its either close or all passing
<lifeless> which isn't really helpful, sorry
<poolie> it's approximately helpful :)
<lifeless> he made all the intertree ones pass; I don't know about the entire test set though
<poolie> me either
<Peng_> No, it's not all passing.
<Peng_> Um, there were 6 errors and 5 failures total, in test_merge, test_pack_repository and test_repository.
<poolie> Peng_: thanks!
<poolie> you should fix them :)
<Peng_> What would be the use of upgrading bzr.dev to the 1.6 format?
<Peng_> Does doing "bzr branch --stacked" require the source branch to support stacking?
<abentley1> Peng_: No, but default stacking policies, which Launchpad uses, require that.
<Peng_> Oh
<vila> hi alla
<vila> ?? Hi all :)
<Peng_> ...What are default stacking policies, exactly? "bzr branch" will stack by default?
<vila> poolie: I think it's "quite close" if merged with a recent bzr.dev, but the failing ones are still a bit hard to fix (I can dig to more precise if you will)
<vila> poolie: I think it's "quite close" if merged with a recent bzr.dev, but the failing ones are still a bit hard to fix (I can dig to be more precise if you will)
<jml> Peng_: bzr push will.
<jml> Peng_: tbh, I haven't tried branch.
<Peng_> Oh.
<Peng_> ...http://bazaar-vcs.org/bzr/ needs that?
 * spiv finishes for the day
<spiv> abentley1: I don't have time to give your remoterepo stacking fix a proper review atm, but at a glance it looks good
<spiv> abentley1: if it hasn't already had a review by the time I start tomorrow I'll certainly review it then.
<abentley1> spiv: Cool
<poolie> hi abentley!
<abentley> poolie: hi!
<lifeless> ciao
<lifeless> I'm on leave now ;), I may drop by and chat when playing with pet projects, but I'll be focusing on relaxing and zoning out mainly :)
<abentley> lifeless: have fun.
<Peng_> lifeless: I know I'm saying this just after you left, but what are you planning to do about group_size in bzr-search?
<lifeless> Peng_: right now? nothin
<lifeless> abentley: tanks
<Peng_> Heh, okay.
<igc> night all
<Peng_> Good night.
<Peng_> Ehhh?
<Peng_> I think I may have just figured out the cause of my weird Loggerhead issues: a simple typo. That's what I get for not reading the error messages well?
<Peng_> Oh, no, the typo is new, I think.
<lifeless> jml: right, one less TUIT; testresources now sorts properly
<Peng_> Hm...what's the right way to get a patch into Loggerhead? Usually I just bug someone on IRC. :P
<lifeless> push a branch to lp
<lifeless> file a merge request in lp
<Peng_> :)
<mwhudson> man i wish i could just click a button to land that branch
<Peng_> Hi. :)
<Peng_> See? Bugging people on IRC is more efficient. :P
<mwhudson> Peng_: merged, ta
<mwhudson> and ooh, the merge proposal is automatically marked merged :)
<Peng_> Thanks. :)
<mwhudson> Peng_: do you want to join ~loggerhead-team?
<Peng_> mwhudson: Meaning I could push to the trunk without needing to go through you?
<Peng_> Or just to have a neat badge?
<mwhudson> the former
<mwhudson> (i don't think ~loggerhead-team has a badge...)
<Peng_> No badge? That's no fun. :P
<mwhudson> heh
<mwhudson> i guess we'd also want you to commit to being happy to assign (c) Canonical on your work
<Peng_> I dunno. I don't contribute enough code to be a major review burden. If I ever contributed something large, I'd want it to be reviewed anyway, and my small things aren't really high-priority.
<lifeless> mwhudson: I wouldn't tie the things together; surely a committment to stay under the paragraph limit when pushing (until a cc assignment is done) is enough
<lifeless> mwhudson: can always uncommit after all
<mwhudson> lifeless: true
<Peng_> Honestly, I dislike copyright assignments, but I never contribute anything large enough to be worth caring about the rights of anyway. :P
<Peng_> (That doesn't mean I'd be unwilling to sign one.)
<Peng_> Then I get to the part where I'm not even an adult, so I don't know if I legally *can* sign one, and then I decide to put it off and go watch TV. :\
<lifeless> Peng_: adult is a state of mind
<Peng_> So when I turn 18, I still won't be an adult? Damn. :(
<mwhudson> i don't _think_ there's an age thing with copyright is there?  maybe there is
<Peng_> I don't think so either, but copyright assignments are legal document thingies, right? so there might be one there.
<mwhudson> hmm
<Peng_> lifeless: FYI, I let a "bzr index" of bzr.dev with a group_size of 50 run to completion. It took 54.5 minutes. :D But it peaked at only about 115 MB of RAM. :)
<Peng_> lifeless: Also FYI, group_size = 100 took 33:00.01 and used 122 MB of RAM.
<rocky> hey... i understand what the push and pull branches that a remembered are, but what is the "submit" branch?
<Peng_> rocky: For "bzr send".
<rocky> so the first time i pull in merge info from a particular source branch, it gets remembered as the "submit" branch?
<lamont> bzrlib/_dirstate_helpers_c.c:7704: warning: dereferencing type-punned pointer will break strict-aliasing rules
<lamont> shame on bzrlib
<lamont> (one of many, grabbed at random)
<Peng_> lamont: Shame on Pyrex.
<lamont> ok
<lamont> only 104 occurances of type-punned in the log :-(
<Peng_> lamont: There are generally fewer warnings with newer versions of Pyrex.
<lamont> yeah, that's building 1.9 on hardy
<Peng_> But I don't remember ever seeing "type-punned".
<lamont> google will tell you what gcc really means there.
<lamont> "ZOMG this might not do what you want in some strange corner-case"
<lamont> or something like that
<jdong> it's a clever feature, not a bug (tm)
<lamont> jdong: DENIED
<Kinnison> the warning is completely valid
<Kinnison> just compile -fno-strict-aliasing if you don't want it
<darkness51> Hola a todos, como les va?
<darkness51> tengo una duda, cuales son los comandos para usar bzr en forma distribuida
<Kinnison> darkness51: ingles?
<Jc2k> morning thumper_laptop
<darkness51> Kinnison: i am understand english, but i don't write fine
<darkness51> what command use form distribute work
<Kinnison> darkness51: 'bzr push' can be used to upload your branch to another location. E.g. bzr push sftp://my-fileserver/home/me/projects/mything
<darkness51> what is the use of bzr pull??
<Kinnison> The 'pull' command lets you fetch changes from a remote branch into your local one. E.g. Pretend I have a project 'proj' and I work on my laptop and my desktop. I have a server and I keep a branch on there for synchronising.
<Kinnison> I make a change on my desktop and push it to the server with 'bzr push'
<Kinnison> Then on my laptop I can do 'bzr pull' to get the change onto my laptop
<Kinnison> Naturally this requires you to tell it the location of the server first time. After that it will remember for itself.
<darkness51> ok, thank's Kinnison
<elmo> tuna 17:13 ~/scratch % bzr branch lp:~ubuntu-core-dev/livecd-rootfs/trunk/
<elmo> You have not informed bzr of your launchpad login. If you are attempting a
<elmo> write operation and it fails, run "bzr launchpad-login YOUR_ID" and try again.
<elmo> can't it tell? :-P
<fullermd> Well, not with the brain of a tuna   :p
<Odd_Bloke> My Launchpad login isn't the same as my local login.
<beuno> Odd_Bloke, maybe you need to set it in .ssh/config
<beuno> Host bazaar.launchpad.net
<beuno> User Odd_Bloke
<beuno> or whaeva'
<elmo> Odd_Bloke: I meant, can't it tell if it's a write operation
<Odd_Bloke> elmo: Ah, I see.
<Odd_Bloke> Not easily, IIRC. :)
<james_w> not with the current layering
<jam> morning vila
<jam> morning #bzr
<jam> markh: what are you still doing up? :)
<jam> elmo: We can know that "bzr branch" is a readonly operation. I believe the problem is that people often do a readonly operation, and then shortly thereafter do a write operation which fails, but we have lost the info about the LP url they used to get the branch.
<jam> The most common one is:
<jam> "bzr co lp:foo"
<jam> cd foo
<jam> bzr commit -m "this will fail, because of something about HTTP"
<vila> jam: morning jam, evening jam (jetlag making me falling asleep again :-/)
<jam> vila: sorry to hear that. I do believe I had a harder time coming home than I did going to Sydney
<jam> I'm not sure if it is heading East
<jam> or if it is coming home to a baby with an ear-infection
<jam> my guess is the latter
<abentley> Odd_Bloke: if you're using bzr 1.9, you don't need to configure ssh.  At most, you need to launchpad-login again, but any lp: lookup will do that for you.
<vila> baby's ear-infections are bad for dad's sleep for sure :-/
<abentley> elmo: And no, it can't tell.  We don't "open for write" or "open for read".  We just open, and after that we're dealing with real URLs.
<vila> jetlag seems better than last week though, but I have a lot of sleep to catch up since I almost *not* sleep from Saturday morning to Monday morning (including the full day in Singapore as an added bonus for delayed flight :)
 * elmo trollingly proposes rich-rich-root which records the original lp: url
<elmo> abentley/jam: fair enough :-p
<jam> abentley: then again, that may change in the future. We are looking at having a Branch.open_or_create_locked() which would allow us to know that we will be writing to it.
<jam> elmo: And yes, we've discussed recording the original lp: url rather than its redirection
<jam> vila: ouch on the extra day. I at least managed ~4 hrs of sleep on the plane, and I arrived home at 9pm, which is a great time to reset your internal clock and go straight to bed :)
<vila> jam: well, I did sleep well last night, so hopefully I will too this night and be ok tomorrow :)
<jam> So did you manage to get out of the Airport in Singapore, or was it just 24-hours of airport-chair pain?
<mthaddon> hi folks, I'm getting the following error from config manager - "bzrlib.errors.TagsNotSupported: Tags not supported by BzrBranch5('file:///blah/blah/blah); you may be able to use bzr upgrade." using bzr 1.6.1 - should I "bzr upgrade" that directory?
<jam> mthaddon: It sounds like you have a remote source with a newer format than the local source.
<jam> And the remote source also has tags included.
<jam> (which we are failing to fetch)
<jam> I would recommend upgrading to whatever the remote format has.
<jam> (You can upgrade even further, but the safe bet is to just stay in step)
<mthaddon> jam, how to I verify the remote format version - bzr info?
<jam> I'm not sure about how CM works, but perhaps just deleting the branch will recreate it at the right format.
<jam> bzr info URL should work, IIRC
<mthaddon> thx
<beuno> if it's a remote branch, just with http to get the proper format
<beuno> bzr+ssh always says nonsense
<Peng_> You could use nosmart+bzr+ssh to get the real info.
<mthaddon> bzr info bzr+ssh says "Standalone branch (format: unnamed)", bzr info nosmart+bzr+ssh says "Standalone branch (format: pack-0.92)"
<Peng_> mthaddon: Run "bzr upgrade" in your local branch then.
<vila> jam: well, the airport-chair pain was in Brisbane where they announced 1-hour delay... 7 times :-)
<mthaddon> Peng_, that seems to have fixed it - thx
<jam> vila: what airline?
<jam> and yeah, ouch
<jam> if they told you in advance it was going to be 7 hours, you could have at least done something
<jam> I guess you at least weren't already *on* the plane
<vila> when we finally got to Singapore, the connecting flights were long gone so they transfered us to an hotel and re-book the same flights only 24h later
<jam> There was something about JetBlue in the states doing that
<vila> Quantas from Brisbane
<jam> http://gettingtomaybe.blogspot.com/2007/02/jet-blue-delay.html
<jam> Quote: News broke last week that passengers on Jet Blue flights were subjected to 10 hour delays inside the plane, while on the runway.
<tetha_> ouch, thats even worse than my regular train delays
<jam> It was a big deal, as they didn't even have food for the passengers, etc.
<jam> Since they are budget flights
<vila> The hotel were nice, but I was so sleep deprived already that I only half enjoyed the sight-seeing in Singapore :-)
<vila> Quantas did pretty well, giving vouchers in Brisbane for refreshments and so on, the hotel was nice too (even if I ended up in a smoking *level*, ha ha the irony)
<tetha_> oops, now I did it. my proof for tomorrows algorithm class finally brake apart
<jelmer> jam, What happened to your "This week in Bazaar" posts?
<lamalex> anyone experience with LP here
<lamalex> nm, i'll go to #launchpad
<lamalex> sorry
<jelmer> crap, I just realized I'm halfway through reimplementing Subversion in Python..
<LarstiQ> jelmer: ai
<fullermd> A painful realization, to be sure.
<fullermd> 'course, you could always reimplement half of git in python to recover  :p
<dobey> or you could just fix bugs in bzr and make it fast
<jml> lifeless: sweet
<jml> lifeless: does it solve the TSP or what?
<jml> bzr alias upll="pull"
 * LarstiQ has bpvl aliased
<thumper> LarstiQ: to what?
<LarstiQ> thumper: bzr pull -v | less
<mwhudson> jelmer: because writing libsvn bindings is too painful?
<thumper> jelmer: how is the bzr-git work going?
<jelmer> thumper: Pretty good; I'm working on two things at the moment - getting more familiar with git's pack format to be able to implement that for bzr-git and factoring out code that is shared by bzr-svn and bzr-git
<james_w> jelmer: I found git's pack format to be pretty clear when I looked, how are you finding it?
<jelmer> james_w, Yeah, it's quite simple
<jelmer> btw, I was thinking of renaming the python-git code you originally wrote to "Dulwich"
<jelmer> (after the Monty Python sketch about a cocktail party there featuring a Mr and Mrs Git)
<james_w> heh :-)
<thumper> jelmer: have you talked with Jc2k about git and python?
<thumper> jelmer: I think he did something...
<thumper> jelmer: or perhaps he was working in C, I'm not entirely sure
<jelmer> thumper, Yeah, we talked about it a bit during the summer
 * thumper nods
<jelmer> thumper, That was indeed in C - based on the upstream git code
<thumper> ah ok
<eydaimon> Unable to obtain lock chroot-14417232:///srv/bzr/ ... If you're sure that it's not being modified, use bzr break-lock chroot-14417232:///srv/bzr/.... $ bzr break-lock chroot-14417232:///srv/bzr/ ... bzr: ERROR: Unsupported protocol for url "chroot-14417232:///srv/bzr/... that's not terribly useful
<eydaimon> how can I get it to break this lock?
<jelmer> eydaimon, I think the error message may be a bit clearer in newer versions of bzr
<jelmer> eydaimon, generally, you should be able to run "bzr break-lock" on the URL that was giving you problems
<abentley> jelmer: Really?  I thought it was still leaking underlying paths in the latest versions.
<eydaimon> jelmer: but it says unsupported protocol for url
<eydaimon> how do I deal with that?
<jelmer> eydaimon, You should be able to run "bzr break-lock" on the URL you were trying to pull from/push to/branch from/etc
<eydaimon> ok
<abentley> eydaimon: You ignore the URL it specifies.  Use the normal URL for the branch.
<jelmer> abentley, Sorry, I must be mistaken then
<jelmer> ISTR some patch for this going in
<eydaimon> jelmer: thanks, that fixed it
<jelmer> eydaimon: You're welcome. Hopefully the URL in that error message will get fixed at some point.
<eydaimon> that's probably helpful :)
<Lethalman> hello
<Lethalman> I have commit A -> B locally, then pushed to the remote repository
<Lethalman> I then uncommitted B and committed C
<Lethalman> when I push it says of course that branches diverge
<Lethalman> how can I force to push A -> C?
<beuno_> Lethalman, push --overwrite
<bob2> push --overwrite
<bob2> if you're sure
<Lethalman> ah
<Lethalman> yes i'm sure
<bob2> or merge from then push to
<Lethalman> thanks very much
<rockstar> abentley, can you give me a rundown of the proper way to push a loom to launchpad?
<abentley> rockstar: the loom must be in format 6.  Then pushing it should work, but won't stack.
<rockstar> abentley, I apparently forgot to record before I pushed.  So I deleted the pushed branch, recorded, and pushed again.
<rockstar> But when I pull from another system, the loom appears to only have one thread.
<abentley> rockstar: I'm the wrong guy to answer this, because I never push looms on purpose.
<rockstar> abentley, :)
<jfroy|work> jelmer: do I need to set some things up to run bzr-svn's unit tests?
<jfroy|work> I'm getting failures across the board
<jelmer> jfroy|work, no, just run "bzr selftest --starting-with=bzrlib.plugins.svn"
<jfroy|work> jelmer: eh, it didn't even make it to the end :p
<jfroy|work> OSError, "too many files open"
<jelmer> I've never run the testsuite on Mac OS X, so I'm not sure how well it works there
<jfroy|work> Apparently it massively fails.
<jfroy|work> Hum, any known issues with Python 2.6?
<jelmer> oh, yeah, python2.6 still has issues
<jelmer> sqlite3 has slightly different behaviour, for example
<jfroy|work> right
<jfroy|work> I'll try to run the tests on 2.5
<jelmer> I'll be back in ~45 minutes
<markh> jam: you here and got a sec?
<jfroy|work> jelmer: sent you a merge bundle as the first parter of a workaround for my situation
<thrope> is it possible to use local svn repo with bzr-svn
#bzr 2008-11-19
<jfroy|work> thrope: sure, probably just use a file:// URL
<thrope> got it with the svn+file
<thrope> how can I push to a seperate branch with no shared histroy
<thrope> I'm trying to push to an empty branch
<meoblast001> hi
<meoblast001> how do you delete a project in launchpad?
<lamalex> meoblast001: you have to request it in launchpad answers
<lamalex> there's no way to do it yourself
<meoblast001> ok
<meoblast001> thanx
<lamalex> #launchpad would be the place to ask though
<lamalex> ;)
<Peng_> beuno: ping
<jelmer> jfroy|work, thanks, just replied
<jfroy|work> jelmer: and I sadly just spammed you with the same merge bundle...
<jfroy|work> Apparently send -r respec doesn't mage a merge bundle for the specified revisions...
<jfroy|work> I'm not sure how to send you a separate merge bundle for the foo fix, and another one with the test suite changes.
<jelmer> jfroy|work, you probably have to recommit the changes on separate branches
<jfroy|work> :sigh:
<meoblast001> i always forget this specific bazaar command when i dont commit changes often
<meoblast001> i think it's bzr -ci but im getting error
<bob2> bzr ci
<meoblast001> ah thanx
<meoblast001> oops.. how do i register a folder as a branch.. havent done that in a long time
<jelmer> meoblast001, bzr init
<beuno> Peng_, pong
<Peng_> beuno: Hi.
<Peng_> Err, wait, I wanted to go watch TV in 3 minutes.
<Peng_> beuno: Anyway, I wanted to poke you about the traceback Googlebot likes causing.
<Peng_> beuno: Ignoring the part about how Googlebot found a bad link (and if it really should be a bad link), there's a second traceback that looks to me like a bug, but I dunno. http://paste.pocoo.org/show/91709/
<Peng_> ...Bye.
<beuno> Peng_, thanks, enjoy
<Peng_> Thanks.
<meoblast001> why am i getting Launchpad user 'braden' doesn't have a registered SSH key
<meoblast001> it works on my other projects
<meoblast001> this makes no sense
<beuno> meoblast001, can you ssh into bazaar.launchpad.net?
<meoblast001> ok
<meoblast001> wait.. i think i figured it out
<meoblast001> i forgot meoblast@
<beuno> right
<beuno> you can set that up in .ssh/config
<beuno> set a rule for the bazaar.launchpad.net host
<meoblast001> nah its ok
<meoblast001> beuno: would you be interested in helping out with my day old project?
<meoblast001> with many bugs
<meoblast001> welll... 1 bug
<beuno> uhm, I should probably try and keep up to date with my current projects before getting into new ones   ;)
<Peng_> With bzr 1.9 you don't need the user in bzr+ssh://bazaar.launchpad.net/ URLs (and in previous versions, you can probably edit authentication.conf to set it up.)
<poolie> spiv, hi, are you around?
<spiv> I am.
<thumper> abentley: I'm having problems with bzrtools with the nightly bzr ppa
<thumper> abentley: 'module' object has no attribute 'diff_writer_registry'
<poolie> are you busy today? i'd like to talk about the Ideal hpss stuff
<abentley> thumper: it sounds like your bzr is too old.
<thumper> abentley: it says 1.10 dev
<thumper> poolie: I'd like to talk this afternoon about it
<thumper> poolie: perhaps in an hour or so?
<poolie> thumper, sure, together with the three of us, or pairwise?
<thumper> poolie: sorry, I thought you were talking to me :)
<spiv> I'd be happy to chat about ideal hpss stuff.
<spiv> Although I'm starting to get hungry, so perhaps after lunch?
<poolie> ok so the three of us in one hour at 2:00 utc
<abentley> thumper: you need revno 3838
<thumper> poolie: or 2:30 utc
<thumper> abentley: how can I check the revno?
<thumper> is the nightly ppa building?
<thumper> I haven't seen an update for a few days
<abentley> thumper: I see it when I do bzr --version
<thumper> abentley: mine just says 1.10dev
<spiv> thumper: if you installed from a PPA, I guess look at the version of the package, and/or maybe the changelog in /usr/share/doc/bzr
<abentley> thumper: Sorry, I don't use a PPA.  It might be in the description or something.
<thumper> abentley: package says 3837
<abentley> Yeah, 3838 is from Nov 17
<thumper> :(
<thumper> abentley: how can I downgrade my bzrtools branch a few revisions?
<thumper> abentley: as I use a bzrtools from trunk
<abentley> thumper: bzr revert -r 681
<thumper> abentley: that leaves me with modifications in the tree
<thumper> abentley: then just plain revert?
<abentley> thumper: no, if you want to unpull, do bzr pull -r 681 --overwrite .
 * thumper tries that
<thumper> abentley: dude, you are a walking bzr man page
<thumper> abentley: notice I didn't ask "could it be done", I just assumed that it could and I didn't know how
<abentley> hehe
<jml> what's the complement of 'bzr revert --forget-merges'?
 * jml remembers: "bzr revert ."
<abentley> jml: right
<Peng_> Heh, using "pull --overwrite" like that is a bit of an evil way to avoid "uncommit"s prompts and verbosity.
<jam> markh: I wasn't, but I'm around a bit now
<markh> hi jam - in bug 298013, the reporter notes "When adding new plugins to the standalone version of the installer many expect certain python modules to be available. Be they are not due to the fact that the standalone ships only a minimal python distribution"  Do you have any thoughts on that?
<ubottu> Launchpad bug 298013 in bzr "latest release of tbzr spoils command line" [Undecided,New] https://launchpad.net/bugs/298013
<jam> markh: I believe xmloutput has that "solved"
<jam> in that it packages the stdlib it expects to have available
<jam> I'm not 100% sure on that, though
<jam> I don't *think* we want to include a complete python install
<jam> and it doesn't address plugins that go outside the stdlib anyway
<jam> (bzr-gtk, for example)
<markh> jam: you mean xmloutput nominates the set of the stdlib it includes rather than ones that are strictly needed by it?
<jam> markh: no, that the packaging for xmloutput (as a separate installer from bzr-setup.exe) also includes the stdlib it needs
<markh> I think the point of that report might be that if you try and add a plugin to the plugins directory in the win32 standalone binary installer, it is likely to fail as some module it uses, but we don't, isn't packages in py2exe
<markh> I expect xmloutput finds itself in the same basic situation?
<jam> markh: the original point of the bug report was for people that use a plugin by putting it in BZR_PLUGIN_PATH
<jam> often  don't find it works
<jam> because it doesn't have the necessary stdlib
<jam> or even 3rd party
<jam> xmloutput, IIRC, needed more of the XML parsing and generating libs
<jam> from stdlib
<jam> basically, it ends up that if you use the standalone installer
<jam> you need to have "proper" installers for the plugins as well
<jam> contrast that with when you install things into C:\Python25
<jam> then it becomes much more straightforward that a plugin can run
<jml> please come up with different ways to say branch(n) and branch(v). kthxbye
<jam> and where you need to install any dependencies.
<jam> jml: branch'n branch'v ?
<markh> jam: I'm a little confused - that bug report doesn't make any reference to BZR_PLUGIN_PATH or xmloutput.  IIUC, our windows installer explicitly leaves plugins on the file-system rather than in the .zip so additional plugins can be plonked there.  Am I misunderstanding?
<jml> jml branches a branch to make a new branch branched from the old branch.
<jam> markh: they can also plunk them in APPDATA/bazaar/plugins, IIRC
<jam> but the point is plonking them somewhere that gets auto-loaded
<markh> correct - but if they fail due to some stdlib module not existing, how should they proceed?
<jam> APPDATA/bazaar/plugins and $INSTALL/plugins are both on the default BZR_PLUGIN_PATH
<jam> markh: if you use a standalone installer for bzr, you need an installer for your plugin
<jam> I don't think we can do better than that
<jam> We *could* package all of python
<jam> we could even just bring in the python .msi file
<markh> so what would we recommend that installer do?
<jam> I wouldn't necessarily change the bzr installer
<jam> aside from helping plugins build their own installers
<jam> possibly just documenting how to do it
<jam> as it seems that xmloutput "solved" the problem for plugins
<markh> but if the "official" answer is "you can't use a plugin on windows unless it ships with bzr, or the author has made a special installer for it", I'll be happy to spread that word.
<jam> markh: well, what are our alternatives?
<jam> I would rather see a python-based installer, but it is hard to make that slick
<markh> I'm still not clear how that plugin installer would install a missing stdlib module - I guess they could ship it - but many plugins shipping copies might be somewhat strange.
<jam> and not necessarily better than documenting how plugins can install the stdlib they need
<markh> jam: an easy alternative may be to nominate parts of the stdlib we include - possibly even all of it.  What is your concern there?
<markh> size?
<markh> obviously we sould avoid the subdirs that don't make sense
<jam> well, "du -ksh" seems to say that stdlib is approx 22MB
<jam> but that includes .py, pyc, and .pyo
<jam> It also says my site-packages is 97MB
<jam> interesting, bzrlib is 2x the size of PyQt4, but I bet it compresses a lot better
<jam> :)
<markh> its a cost-benefit tradeoff - istm the benefit of having more plugins work is greater than the cost of including the stdlib - especially given the number of plugin authors who would create a special installer will be approx. zero.
<jam> however, the installer is already getting enormous (14MB so far?) what's another 5MB or so
<markh> just before you disconnected I said:
<markh> its a cost-benefit tradeoff - istm the benefit of having more plugins work is greater than the cost of including the stdlib - especially given the number of plugin authors who would create a special installer will be approx. zero.
<markh> and yeah, for 5mb, that cost isn't high at all
<jam> (I'd rather see a 5MB installer *total*, but that seems to not be possible.)
<markh> yeah, long term there are a few nice things we could do
<vila> hi all
<igc> hi vila - sorry to hear about your lousy trip home
<vila> Hi Ian !
<vila> Bah, don't worry that much, it makes for some nice memories and I learned a few lessons :-)
<eferraiuolo> I'm looking to understand something about checkouts compared with svn
<eferraiuolo> in SVN you can do a checkout of a sub-directory
<eferraiuolo> in bzr is seems you can only checkout a branch
<eferraiuolo> but what if I just wanted to checkout a sub-folder in a branch?
<eferraiuolo> for ex. in my local repo --no-trees I have a /trunk/ branch with two folders /trunk/foo and /trunk/bar
<eferraiuolo> I want to bzr co /trunk/foo .
<RAOF> eferraiuolo: You can't really right now.  Or at least, last time I checked; this _may_ have changed with bzr 1.9.
<Peng_> It may have changed in 1.9?
<eferraiuolo> RAOF: anyone using some combination of branching?
<eferraiuolo> ...I'm using 1.9 and can't seem to get this work
<RAOF> Peng_: I know there's _some_ work on support for subtrees like this, and I haven't followed 1.9 dev...
<Peng_> I don't think anything new happened.
<RAOF> eferraiuolo: There's the 'bzr split' command, which goes about half way to what I guess you want.
<RAOF> That takes a subtree of a branch and converts it to a separate branch.
<eferraiuolo> so I would first have to create a new branch outside my shared no-trees repo to run the split cmd on
<RAOF> Oh, tell a lie.  As long as you don't mind hitting buttons marked "experimental", a combination of bzr split and bzr join --reference looks like it'll do what you want.
<RAOF> You split out trunk/foo and trunk/bar into two separate branches, then join foo & bar into trunk; if the documentation doesn't lie, you'll have a trunk/ with sub-branches foo and bar, and commits on trunk will recurse into foo & bar.
<eferraiuolo> hmmm... interesting. I'll give it a try
<RAOF> I suspect you'll need to upgrade your branch to the latest-greatest-experimental subtree variant first.
<eferraiuolo> it's on --1.9-rich-root already, which seems it should work
<eferraiuolo> Looks like I will have to branch my trunk outside my repo since my repo is set to no-trees
<RAOF> If it doesn't work first time, I'd guess you'll need to upgrade to whatever the relevant -subtree variant is.  rich-root gets you the ability to 'bzr split'; I think you need -subtree to 'bzr join', though.
<Peng_> eferraiuolo: If a branch doesn't have a working tree, you just need to use "bzr co" to create it..
<eferraiuolo> It's odd... bzr split is create the sub-branch, but I can't checkout or branch against the newly created sub-branch, it pulls down the whole parent branch (trunk)
<hmeland> eferraiuolo: I think it's by design that the sub-branch produced by the split command will include the entire history of the parent branch.
<vila> I have a repo with empty inventory sha1s 8-/ Thoughts ?
<hmeland> eferraiuolo: That way, if someone commits new stuff to a pre-split version of the parent branch, you stand a reasonable chance of having "bzr merge" just do the right thing.
 * hmeland . o O ( Oops, that doesn't sound good. )
<eferraiuolo> So I ended up just splitting my repo for that project into to main, but separate branches and dealt with the issue that way.
<eferraiuolo> thanks all for the help and insights
<igc> poolie: did you want ~mbp/bzr-usertest/277376-strict reviewed & merged?
<igc> poolie: it looks ok to me at first glance
<Peng_> Oh my god! "bzr check" finally finished!
<Peng_> Nothing was wrong. :
<Peng_> \
<jelmer> you sound disappointed
<Peng_> jelmer: Well, it was an anticlimactic ending.
<EarthLion> hey how can i ignore specific files. I have added .DS_Store to my .bzrignore file and that shows up under bzr ignored but the other lines e.g. database.php don't get picked up
<Peng_> Maybe database.php is already versioned?
<EarthLion> yeah it is already versioned
<EarthLion> so i have to remove it first?
<Peng_> Yes.
<Peng_> Ignore rules don't apply to things that are already versioned.
<Peng_> You could "bzr rm --keep database.php" to stop versioning it without physically removing the file. (commit too, of course)
<EarthLion> Peng: thanks :)
<awilkins> jelmer: Who's building the python-flavoured 1.9 windows installers, because it doesn't have the C extensions for bzr-svn  ?
<jelmer> awilkins, jam or markh I think
<jelmer> or maybe Alexander
<awilkins> Hmmph, maybe LP should list who uploaded a given file :-)
<arnarl> Is there any way to do something like svn:externals with bazaar? and point to a web address or a subversion repository something similar?
<arnarl> googling didn't yield anything obvious and there were a few references to "when the stacked branches" lands
<Peng_> That's not what stacked branches are for.
<arnarl> there is ConfigManager, but it seems a bit abandoned with no checkins since march 2006
<arnarl> ok, then I have searched for the wrong thing :-)
<Peng_> That's what, uhh, by-reference subtrees (or by-reference nested trees? I forget the terminology) are for, and they've been in an experimental state for ages.
<arnarl> not sure I follow
<Peng_> There's work on stuff similar to svn:externals, but I don't think there's been any progress for ages.
<arnarl> anyway, what I would like is a way to point to a file in subversion so that it is updated when a user branches or that I can automatically keep it up to date in my own branch.
<jelmer> only 2 more failing tests away from bzr-svn 0.5rc1 \o/
<Peng_> Congrats :)
<awilkins> \o/ \o/ \o/
<awilkins> jelmer: Does 0.5 still carry the "eek, metadata may change" warning (esp for branches managed on 0.4 series) ?
<jelmer> awilkins_food: yaeh, it does at the moment (though it's pretty stable)
<awilkins_food> jelmer: The "pretty stable" part is the best ; I'm more interested in the actual risks rather than the warning message per se  :-)
<awilkins_food> jelmer: So can it operate on branches with 0.4 bzr:properties?
<jelmer> awilkins_food: still there?
<jelmer> awilkins_food: it will fetch 0.4 branch correctly
<jelmer> awilkins_food: I would recommend using the v3 (0.4) mappings for now though
<jelmer> awilkins_food: by settings the default mapping to 'v3' in mapping.py
<awilkins_food> jelmer: Using the v4 mappings presumably is the secrete sauce that makes it work better with truly horrible repository histories and layouts though?
<jelmer> awilkins_food: yep
<jelmer> awilkins_food: and which allows not using file properties when roundtripping
<awilkins> jelmer: I think I'll build it up and try it on my "monster repo" here -this one always kills 0.4 just before it finishes branching trunk
<awilkins> KeyError
<jelmer> oh, that should never happen, not even with 0.4..
<jelmer> is there a bug open about that?
<awilkins> yes
<awilkins> I've mailed you stack traces in the past
<awilkins> Specifically for this one ; opening the repo would not be practical alas, it's about 1.5GB as SVN FSFS I think
<awilkins> jelmer: I'm not certain there is a bug for it ; stack trace is in a mail dated 6th September
<jelmer> awilkins, any chance you can forward it to me again?
<awilkins> Sure, no problem.
<awilkins> I'm going to built the tip of 0.4 and try it out on the branch that throws it ; but not necessarily a good test, because the branch might be in a bad state which is causing the error (it has most of the revisions pulled into it by now).
<awilkins> For a rigorous test I'll have to pull the branch from scratch I suppose ; but that isn't fast, it takes at least 10 hours. I'll have to dump the repo and unload it at home because the IT drones have imposed a "drop into standby" policy on all desktop machines here unless you push the right button at 1900
<awilkins> So I can't leave it going overnight
<awilkins> Because I leave at 1700 :-)
<jelmer> re
<jelmer> it should be a lot faster these days, maybe that helps..
<jelmer> how many revisions is it?
<awilkins> Around 10,000 revisions and 1.5GB
<awilkins> Of revisions
<awilkins> Medium to large binary files, enormous number of paths
<awilkins> And horrible branch layout ; I tried pulling a branch that should have been a v.small revision size but it turned out to generate a rather large revision (I stopped it before it finished as it was clearly not right)
<awilkins> Hence enthusiasm for 0.5
<awilkins> The prospect of this repo actually switching to bzr is slim but it would be nice to have options :-)
<awilkins> And I like to use it for the other, more reasonably sized, repos that I access. Being able to cope with a horrible monster improves my confidence :-)
<jelmer> :-)
<awilkins> This repo has upward of 42,000 paths
<awilkins> Would split inventories improve it's performance characteristics?
<jelmer> awilkins: yeah, that would certainly help I think
<jelmer> awilkins: 10k revisions isn't that much for bzr-svn anymore these days
<jelmer> especially for local repositories
<awilkins> Is split-inventory in --1.9 ?
 * awilkins reads release notes
<jelmer> awilkins: no, not yet
<jelmer> awilkins: with which version of bzr-svn did that KeyError last occur?
<awilkins> jelmer: The version in the log is the last version I tried it with
<awilkins> jelmer: I'm packing up that repo so I can take it home and test it there.
<awilkins> jelmer: I still have the partialluy-pulled branch lying around, do you think a newer version may fix it?
<jelmer> awilkins: I would rather just try a new pull
<jelmer> awilkins: It may well be significantly faster than two months ago..
<awilkins> I'm going to try a new pull tomorrow (via the ra-local layer rather than http or svn)
<awilkins> I could try it here as well.
<awilkins> I'll try both - a pull on top of that partial pull, and then a new one (I'll trash the branch, and the svn metadata cache first)
<balor> Given a diff generated by "bzr diff".  How can I apply that diff to a source tree?
<awilkins> balor: gnu patch ?
<balor> awilkins: bzr diff is in a different format AFAIK
<luks> no, it isn't
<balor> ah, ok
<awilkins> AFAIK it's udiff
<awilkins> If it's a bundle, it's easier to use "pull" or "merge"
<awilkins> As long as your target is a bzr branch ( I presume it is not)
<balor> awilkins: My target is a bzr branch
<luks> why not use bzr send then?
<awilkins> Yes, use send or bundle
<balor> luks: I should have used bundle.  But I can make do with the diff.  Thanks.
<luks> don't use bundle, it's a hidde command not meant to be used anymore
<luks> hidden
<awilkins> My bad advice ; I hadn't noticed it was hidden
<balor> luks: So diff is my only option on a Windows machine with no network connection?
<LarstiQ> balor: no, bzr send -o thing.patch
<LarstiQ> balor: well, I assume you can get the patch of the machine, if not typing over the diff is probably the least work :)
<balor> LarstiQ: thanks
<awilkins> jelmer: Upgrading to tip of 0.4 has 2 obvious effects i) It seems to be working, it pulled that revision it got stuck on previously ii) The "determining changes" stage was a lot faster
<awilkins> I'll try it fresh and see how it does when it catches up with the tip
<awilkins> Does it still repack every revision?
<jelmer> no, only every 500
<Peng_> Is it just me, or does the "determining changes" step often run twice, the second time much slower than the first?
<Peng_> Why is that?
 * LarstiQ on occassion sees it running much more than two times
<LarstiQ> Peng_: I assumed it was per-file
<Peng_> Oh?
<awilkins> Meh, I can't use "1.9-rich-root" as a format
<Peng_> What? Why not?
<awilkins> Ah, that's better
<awilkins> I think it may be a "quirk" of my shell
<Peng_> Oh.
<awilkins> It wasn't taking the parameter
<jam> morning vila, how was your night?
<vila> jam: hi ! Pretty good, woke up at 5h30 only :)
<vila> otherwise, slept like a baby :)
<jam> well, my son woke up at... 2130, 0030, 0130, 0530
<jam> so I hope you slept better than that :)
<jam> but I guess you got up together :)
<jam> (and no, that isn't actually UTC)
<jam> vila: have you had a chance to look at the merge issue?
<vila> jam: ouch, poor daddy :-/
<vila> jam: yes, ready to chat about that and also about empty inventory sha1s...
<vila> and running the test suite under a solaris VM with my third hand :)
<jelmer> 'morning Vincent, John
<jelmer> LarstiQ, Peng_: "determining changes" runs once to find the branch history and then once per tag
<Peng_> jelmer: Oh, okay.
<LarstiQ> jelmer: what tag, svn tags and branches?
<LarstiQ> moin vila, jam
<jelmer> LarstiQ: yeah
<vila> hi LarstiQ !
<LarstiQ> jelmer: right, that could explain it. We have more of those than I'm fond of :)
<jelmer> ok, with bzr-svn 0.5 importing vala (2319 revisions) over the svn:// protocol takes 258 seconds now
<LarstiQ> doesn't seem to bad to me?
<jelmer> yeah, that's pretty good
<uws> Heya
<uws> I'm getting errors when committing to launchpad
<uws> bzr: ERROR: Repository KnitRepository('bzr+ssh://uws@bazaar.launchpad.net/%7Euws/winwrangler/winwrangler.uws/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///home/uws/Computing/Projects/winwrangler.uws/.bzr/repository/')
<uws> ...
<LarstiQ> uws: rich-root vs non rich-root?
<uws> guess so
<uws> how do I fix it?
<jelmer> uws: upgrade repository that is not yet rich-root to rich-root(-pack)
<uws> jelmer: how? I tried
<uws> bzr upgrade lp:~uws/winwrangler/winwrangler.uws/   doesn't work
<uws> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<uws> same for  bzr upgrade --rich-root-pack lp:~uws/winwrangler/winwrangler.uws/  btw
<LarstiQ> uws: unfortunately, try sftp:// instead of lp:
<uws> LarstiQ: ok, seems to do something
<uws> LarstiQ: thanks, worked
<awilkins> jelmer: 0.4 isn't exactly slouching
<awilkins> It's done 6000 fairly hefty revisions in a couple of hours so far
<awilkins> Pretty much CPU limited, I'm sure using the SVN protocol as opposed to HTTP wouldn't help much
<jelmer> 0.5 should be better in that regard
 * jelmer starts a KDE import
<awilkins> I'll be trying it later, barring any nasty surprises trying to build it on win32
<awilkins> I'll be interested to see if it passes the "branching a tag should produce a tiny increase in pack size, not 100MB" test
<jelmer> awilkins: ? was there anything that didn't pass that test then?
<awilkins> jelmer: This repo has a somewhat horrible branch layout and some moves as well
<awilkins> jelmer: I tried it with an older version and branching a tag that the repository should already have had the parent revision for made a rather large new pack.
<awilkins> A few hundred K for the inventory, yes, over 100MB, no.
<jelmer> in that case, it would just end up using a different branching scheme and copying most of the history again
<awilkins> I messed about with the branching config a bit but never really got a satisfactory result (again, this repo is horrible)
<awilkins> Since 0.5 does not use the same mechanic, I shall see how it works :-)
<Kobaz> allrightey... so i'm moving from svn
<Kobaz> is there a way to have a svn-esque authentication system on a central bzr server
<Kobaz> ie: bob has hsi own password, joe has his own password
<Kobaz> rather than a shared ssh account where everyone pushes to
<awilkins> Kobaz: You can use HTTP methods of auth if you use the HTTP server
<awilkins> Kobaz: Whatever IIS and Apache support at a minimum
<Kobaz> ah
<Kobaz> it would be apache.. okay, that makes sense
<awilkins> Kobaz: No path-based auth like SVN but it's rather silly in a DVCS because everyone can commit to the whole tree if they can commit at all
<awilkins> Kobaz: You could probably arrange matters so that distinct ssh accounts could all push to the same repo - after all, Launchpad does this
<awilkins> Bazaar itself has no authentication but the transports it uses may do, is the quick answer
<Kobaz> k
<awilkins> I'd like to see it do client-certificate auth over http, but I can't grok how to get curl to do it.
<dobey> Kobaz: the ssh is just a method. you don't have to have a shared account
<LarstiQ> Kobaz: in fact, at work we use multiple shared repositories over bzr+ssh, with everyone using their own account.
<LarstiQ> Kobaz: and acl (setafcl \o/) to control who has access to which branch.
<LarstiQ> Kobaz: (which boils down to: everybody, but it could be more complex :)
 * LarstiQ hops off to jitsu
<Kobaz> nifty
<emmajane> In CVS I can run a diff against the last update... cvs diff -up original.php > filename.patch in bzr I would have to check my revision numbers first to see what "original" was? I read bzr --help diff, but I didn't see a syntax that matched what I use in CVS.
<beuno> emmajane, bzr diff -r -2
<emmajane> that's "two revisions ago"?
<beuno> I don't quite know the rationale for -2 instead of -1
<beuno> actually
<beuno> I think it's, "show me the difference between the end of 2 revisions ago and now
<emmajane> Let's say, for example, I was working on a branch and when I downloaded it was at revision 159... and now I'm at revision 178... I want to send a patch back because politics are weird... james_w suggested bzr send as well.
<emmajane> (and the branch is 500M because of images so pushing will not be fun)
<james_w> "bzr send --mail-to person@place.com"
<beuno> bzr send is *the* tool to send a patch for the differences between branches, yes
<james_w> another is "bzr diff -r ancestor:http://server/path/to/branch"
<emmajane> james_w, and it's just the diff that gets sent?
<james_w> no, it sends the diff + bzr meta-data.
<emmajane> james_w, what does bzr diff spit out? is it like the patch file that cvs diff gives?
<beuno> emmajane, diff + bzr metadata (commit information)
 * emmajane nods
 * beuno waves at james_w 
<james_w> you can "bzr merge" from the file that "bzr send" produces, much like if you pushed this to a branch
<james_w> hey beuno, how are you?
<emmajane> that popping noise? that was my brain exploding... just a second. :)
<emmajane> ok. I'm back.
<beuno> james_w, pretty good, how are you?
<james_w> beuno: good thanks.
<beuno> emmajane, bzr send generates a file which is the diff plus bzr data, so you can "merge" in the file with all its commits
<emmajane> *nod*
<beuno> so it's different than a plain diff, because you can send them around, and you'll get branches with the same revisions in them (sort of, but let's say yes)
<beuno> james_w, will I see you at UDS?
<james_w> beuno: of course :-)
<emmajane> it's a diff on bzr steroids. :)
<beuno> james_w, fantastic, looking forward to it. I want to talk to you about package branches over beer!
<beuno> emmajane, you got it!
<emmajane> gotcha.
<james_w> beuno: of course :-)
<emmajane> How are the email addresses configured?
<emmajane> i.e. if the mailing list is subscriber posting only...
<emmajane> do I have to change my whoami?
<beuno> well, that's kinda out of bzr's realm
<emmajane> i.e. what email address is announced when you use send?
<beuno> so, you can send it to any email address
<beuno> the whoami is used for the "from" IIRC
<emmajane> heh. so I can fake someone's email? :)
<beuno> well, you know how email works...
<emmajane> :)
<fullermd> I always just have send output to a file, then write the email and attach it manually.
<fullermd> The work isn't ever where the mail client is anyway.
<beuno> me too
<emmajane> fullermd, as in bzr send > file_to_send_later.txt ?
<vila> fullermd: It really depends on your mail client and your workflow, I generally prefer to have send spawns my mail client with the patch already attached, a subject roughly correct and To already set
<emmajane> vila, that sounds clever... will it work with thunderbird?
<vila> But I also had workflows where *sending* the mail directly was even better suited
<vila> emmajane: I'm pretty sure yes, you have to find the the right mail_client setting in bazaar.conf
<emmajane> ahh, ok.
<vila> bzr help send
<vila> mentions thunderbird :)
<fullermd> Well, when my branch is on this machine here, and my mail client is on that machine there, it's out of the question anyway   ;)
<emmajane>   Mail is sent using your preferred mail program.  This should be transparent
<emmajane>   on Windows (it uses MAPI).  On Linux, it requires the xdg-email utility.
<vila> fullermd: bah, my branch is always there or one  mounted file system away :-)
<beuno> vila, you use emacs, it's a different universe all together  ;)
 * vila discovered the joy of auto_master recently when configuring a new OS X.5 laptop :)
<vila> beuno: hehe, true, but not relevant here :)
<beuno> whenever I see "email" and you in the same phrase, it becomes relevant!
<vila> lol
<emmajane> hmmm.
<beuno> you're the only person I know who uses non-standard way of replying to emails
<beuno> which I blame on emacs, of course
<emmajane> apt-cache search xdg-email
<emmajane> xdg-utils - desktop integration utilities from freedesktop.org
 * emmajane contemplates wondering if the documentation should say that or if it's just an Ubuntu thing...
<vila> beuno: what do you mean by non-standard ?
<vila> citations ?
<beuno> vila, yes
<beuno> emmajane, is there anything else?  :)
<emmajane> beuno, well...
<emmajane> beuno, I don't thinks so....
<vila> well, the supercite engine is... older than me I guess, so I'd be surprised to be the only one using it...
<emmajane> beuno, I had a friend tell me about this "VSD" thing once? Or was it BSD? ;)
<beuno> emmajane, they do all kinds of odd experiments with operating systems
<emmajane> beuno, crazy! :)
<beuno> emmajane, so, FWIW, the documentation is in the bzr tree  ;)
<emmajane> yeah, yeah.... ;)
<beuno> not that I'm implying anything, of course...
<emmajane> nono, of course you're not.
<emmajane> but this is me resisting the urge to screen cast instead of eating before a meeting.
<vila> beuno, emmajane : You should try opensolaris (just to be reminded on the huge work made by distros....)
<emmajane> vila, I read about solaris in the documentation for GNOME accessibility.
<emmajane> vila, I can't remember if it was all things they COULD do, or could NOT do. :)
<vila> opensolaris: 1465 packages and counting !!! All prefixed nu SUNW to make them easier for you to understand what they contain ! SUNWman : the man pages ! ulimit.1 contains sorry guy, we didn't provide the man page in that release, try again later :-(
 * emmajane chuckles.
<fullermd> It's a pathetic attempt to regain the heights Solaris once held, when they installed a compiler that told you they wouldn't give you a compiler without more $$$$.
<vila> I mean, I respect Solaris (a bit less than SunOS, but that's not the point), after all, that was the first house for most of the GNU utilities
<vila> fullermd: full agreement
<vila> But bashing aside, opensolaris 08.11 is better than os08.05, at least there *is* a package manager now
<emmajane> heh
<vila> fullermd: and the day they stop providing the compiler is the one I consider the worst day in Sun history
<vila> they obviously didn't realize how they shot themselves in both feet
 * emmajane quietly tiptoes out for lunch while y'all discuss Solaris compilers. :)
<vila> emmajane: enjoy your lunch :)
<emmajane> vila,  thanks :)
<verterok> hi!
<sinelaw> does bzr have default ignore rules?
<sinelaw> and where can i see them
<beuno> sinelaw, yes, pyc files and other common generally unwanted ones
<sinelaw> where can i see the full list
<beuno> that's a good questions
<sinelaw> bzr ignore has only "--old-default-rules"
<sinelaw> ah
<luks> any launchpad people here? can you please check why is https://code.launchpad.net/~luks/bzr-pager/pager "Disabled"?
<sven_> hi! bzr log crashed for me when selecting a specific revision in mysql 6.0, using --forward : http://pastebin.com/m7b7b1659
<sinelaw> nope,
<fullermd> You can see them in the ignore file bzr creates if it doesn't already exist.
<sven_> is this a known bug? it doesn't crash for arbitrary revisions, so i don't know how to reproduce it with a smaller tree
<beuno> luks, mwhudson would know
<sven_> would be very good to know if this is a bug in bzr's algorithm or something corrupt in mysql's revision history
<beuno> but I'm not sure if he's around yet
<beuno> if not, open up a question in answers.launchpad.net/launchpad
<sinelaw> fullermd, there bzrignore file doens't list the built-in ignores
<mwhudson> luks: "a bug"
<sinelaw> there doesn't seem to be a bzr command for viewing them
<luks> thanks, at long as it's not an error on my side, I'm fine :)
<luks> or can I do something to enable it?
<fullermd> sinelaw: ~/.bazaar/ignore
<sinelaw> fullermd, thanks. that should be documented in the bzr command somewhere though :)
<mwhudson> luks: specifically https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/297448
<ubottu> Launchpad bug 297448 in launchpad-bazaar "Launchpad will not do initial mirror of a branch that's the development focus of a project" [High,Fix committed]
<mwhudson> luks: i'd recommend deleting it, reregistering it, waiting until it's mirrored once, then making it the dev focus
<luks> mwhudson: thanks, will do
<mwhudson> np
<beuno> Peng, any ideas on how google got to the URL http://bzr.mattnordhoff.com/loggerhead/bzr/configobj-4.5.2/files/1185.1.29?file_id=http-20060113083522-fa806bfc2aca663c
<beuno> ?
<mathrick> hi, what gives? http://pastebin.com/m64d5e87d
<mathrick> I thought that's was the point of mv --after
<luks> event.list is removed
<luks> er
<vila> sven_: sounds more like a bug in index manipulation than in revision history to me
<vila> sven_: can you retry the command without --forward (that will  clearly draw the line)
<sven_> vila, ok, good to know. i reported https://bugs.launchpad.net/bzr/+bug/300055
<ubottu> Launchpad bug 300055 in bzr ""bzr log --forward FILE" crashes for specific revision" [Undecided,New]
<mathrick> luks: no, I moved it
<mathrick> I just didn't use bzr mv
<sven_> vila, without --forward i don't see any crash
<luks> I *think* it would work if src/event.lisp wasn't "bzr add"ed
<mathrick> luks: it complained about that before, too, that's why I added it
<sven_> vila, also, without the file argument, i don't see any crash
<mathrick> but lemme try
<vila> sven_: ok, shouldn't be hard to fix then, I'll look into it tomorrow
<sven_> vila, thanks!
<mathrick> luks: nope, no cigar
<luks> mathrick: are the files also changed or only renamed?
<mathrick> luks: at least event.lisp is changed because of a merge
<mathrick> hmm
<luks> well, if it's not manually edited I'd suggest to revert and start over
<luks> and if it is, backup the files, revert, move, put the backups back in place
<hydrapheetz> :3
<hydrapheetz> oops
 * hydrapheetz shouldn't switch channels at high speeds D:
<mathrick> luks: http://pastebin.com/m29a5bf0d <-- huh?
<mathrick> I don't get it
<mathrick> I reverted that, and now it says that event.lisp is both removed and unknown
<luks> mathrick: that is after running "bzr revert"?
<luks> no extra arguments?
<luks> it can't be, because "src/" is still added
<mathrick> luks: with arguments
<mathrick> I moved it back from src/ to ./
<mathrick> I reverted event.lisp, and now it's all confused again, albeit differently
<luks> well, I can't help other than to suggest to do "bzr revert" (not selectively, but the whole tree) do the renames and put the original files back
<mathrick> ooh, because I did bzr pull instead of merge
<mathrick> I get it now
<abentley> poolie: ping
<mib_aevfas> how do I publish a branch to an FTP server that requires identification (user: foo, pass: bar)?
<beuno> mib_aevfas, bzr push ftp://user@host:/path/to/repo
<beuno> and bzr will ask you for a pass
<mib_aevfas> beuno: thanks!
<beuno> mib_aevfas, you're very welcome
<philsf> I'm having a little trouble with bzr: 'No handlers could be found for logger "bzr"'
<beuno> philsf, are you running 1.9 and bzrtools?
<philsf> From what I gather, this is a fixed bug, so I must have done something wrong that left a lock file. How can I debug this?
<philsf> bzr 1.3.1-1ubuntu0, from ubuntu 8.04
<beuno> philsf, can you pastebin the output of "bzr plugins"?
<beuno> also
<beuno> take a peak in ~/.bzr.log
<philsf> this is a local-only branch. I usually develop in the laptop, and rsync the full dir to my desktop. I only see the warning in the desktop. Is the rsync of the full dir the probable cause?
<philsf> http://paste.ubuntu.com/74493/
<beuno> that seems like a problem with bzr, not the branch
<philsf> http://paste.ubuntu.com/74495/
<philsf> beuno: that's what I thought, since the warning appears in whatever dir I call bzr from
<beuno> philsf, is .bzr.log writable by you?
<philsf> well, no... it has root ownership, dunno why
<beuno> that's probably it
<beuno> change the permissions, the error should go away
<philsf> cool, it was!
<beuno> :)
<philsf> thanks, beuno!
<beuno> philsf, you're welcome
<philsf> beuno++
<beuno> w00t!  I've been increased!
<w00t> huh?
<w00t> ack
<beuno> ah
<beuno> uhm
<fullermd> Great, now there's two of them.
<beuno> what are the chances someone would have "w00t" as their nick...
<w00t> beuno: if i'm around - fairly high! i've been using it for the past ~10 years now :) </offtopic>
 * jdong wonders if stdin has even more problems with his nick :)
<beuno> good, now I have autocomplete for w00t
<beuno> we should get more people with words in their nicks in here
<beuno> just having "revision", "branch" and "push" would save a lot of typing
<LarstiQ> beuno: you do know irssi can do completion from dictionaries? :)
<beuno> LarstiQ, really????
 * beuno googles
<fullermd> And if we got people choosing dirstate-tags and pack-0.92 and rich-root and rich-root-pack and 1.6 and 1.6.1-rich-root, we could have some good arguments about whether some of them should be kicked off the channel!
<poolie> abentley: pong
<abentley> poolie: I've done some work on your branch, to try getting pack to heal these repo-spanning-deltas.
<poolie> oh thanks
<poolie> as i said in the bug, i found out yesterday evening it doesn't handle all cases in fetch
<abentley> poolie: Mainly what I've got so far is a failing test.
<poolie> so unless something more important comes up in our standup, i was going to keep working on that today
<poolie> ah :) that's still useful
<abentley> poolie: I'll push the work-in-progress, and you can keep going on it.
<abentley> poolie: http://code.aaronbentley.com/bzr/bzrrepo/288751-pack-deltas
<abentley> poolie: As you can see, I was going to try inserting missing records.  But I'm thinking fulltexts is probably saner.
<abentley> poolie: Inserting the records could mean making an Inventory referenceable without making the corresponding files referenceable.  Which violates our longstanding policy.
<jam> poolie: call?
<Kobaz> what's the recommended method for setting up a series of central bzr repos
<Kobaz> i've been trying to get the webdav stuff going without success
<Kobaz> i tried the mod_python method too
<Kobaz> that doesn't work either
<Kobaz> or should i just run bzrserv and shove all the projects in one repo
<awilkins> Kobaz: I've suceeded on IIS using the WSGI application, so that method should work on Apache also. What problems are you having?
<Kobaz> with webdav, i get...
<Kobaz> bzr init-repo https://bzr.local/newrepo
<Kobaz> bzr: ERROR: Transport operation not possible: http does not support mkdir()
<Kobaz> i have the webdav plugin
<Kobaz> but it's not being used
<Kobaz> and there's no docs
<awilkins> Kobaz: Try bzr+http:// instead and see if that works
<Kobaz> if i try the mod_python approach, everything is a 404
<awilkins> I'm not sure you can initialise a repo over HPSS though
<Kobaz> yeah
<Kobaz> i've tried that too
<Kobaz> zr: ERROR: Generic bzr smart protocol error: Invalid http response for https://bzr.local/newrepo/.bzr/smart: Unable to handle http code 404: Not Found
<awilkins> Have you seen http://doc.bazaar-vcs.org/bzr-0.15/http_smart_server.htm
<Kobaz> ah okay
<awilkins> It looks like it's not catching /smart URLs and redirecting them to the application
<Kobaz> yeah
<Kobaz> i was using the mod_python spot in there
<Kobaz> lemme uncomment the python stuff
<awilkins> I think your RewriteRule is absent or fubar
<Kobaz> RewriteRule ^(.*/|)\.bzr/smart$ /home/web/bzr.local/scripts/bzr-smart.py
<Kobaz> i think the rewrite rules aren't kicking in at all
<Kobaz> i tried a simple rewrite, and it doesn't do anything
<Kobaz> hmm
<Kobaz> ah
<Kobaz>     RewriteEngine on
<Kobaz> had to add that
<Kobaz> should have looked into that before
<Kobaz> okay, now that rewrite is working
<Kobaz> where do i get bzr-smart.py
<Kobaz> it's not in the source, and i can't find any download links at all
<lifeless> jml: see the code :P. It's not a TSP solution, its what I postulated would work way back and hadn't had time to code
<jml> lifeless: ahh ok
<lifeless> jml: I don't think the problem is actually NPC though, because it has no shortcuts
<lifeless> given ABC A->B is never more expensive than A->C->B
<Kobaz> do de do
<Kobaz> so would anyone know where one would get bzr-smart.py
<poolie> hi lifeless
<lifeless> hi poolie
<Kobaz> is it a plugin?
<lifeless> Kobaz: there is no such file, its just what is described in the docs
<jml> lifeless: I'll need to refresh my graph traversal knowledge to make the connection between that and NPC
<Kobaz> lifeless: what would i use then?
<lifeless> Kobaz: what is described in the docs, it gives the code as I recall
<Kobaz> hmm
<lifeless> spiv: ^ kobaz could do with a hand, I think
<Kobaz> i didn't see any code
<Kobaz> there was a download of the fastcgi code
<Kobaz> but not the bzr-smart
<Kobaz> and there's some wsgi code
<Kobaz> oooh
<Kobaz> there is some code
<Kobaz> hmm
<Kobaz> wow, that's not obvious at all :P
<lifeless> jml: well Travelling salesman is np-complete, as its got no known solution that isn't polynomial; because there is no way to be sure that AB is better than ACB in the above example, without calculating both
<lifeless> jml: it is possible that the solution I have is actually polynomial overall because of the setup
<lifeless> jml: but anyhow; it works for all the tests we have today. So I'm happy.
<Kobaz> ImportError: No module named modpywsgi
<Kobaz> mmm
<jml> lifeless: so, like I said, I want to refresh my graph traversal knowledge to make the connection between the shortcut thing and NPC :)
<lifeless> jml: :>
 * jml suspends and resumes, to see if that fixes a thing.
<beuno> things usualy break when I do that
<beuno> *never* fixes them
<epper> Hi all
<Kobaz> so now i need the modpywsgi module... the link is a 404 and the site is really really slow
<epper> I'm a svn user and, looking ad distributed VCS I come to Bazaar
<epper> I don't really understand the real difference between the "Decentralized with shared mainline" and "centralized with local commits" workflows
<epper> Could someone tell me?
<epper> (here's where i found that names: http://bazaar-vcs.org/Workflows)
<Kobaz> epper: i've trying to move to bazaar from svn too... it's been a bit of a pain so far, but hopefully it will be worth it
<epper> Really we don't need to make a switch, we have to choose a VCS for a new project ;)
<epper> So... It will be hopefully easy... both ways :)
<Kobaz> ditto
<Kobaz> heh
<Kobaz> all i'm trying to do, is set up a webdav style repo so it can be accessed from anywhere with a password
<Kobaz> been fighting it all day
<Kobaz> with svn it took all of 5 minutes
<epper> right
<epper> Hope one single day will be enough for Bazaar :)
<Kobaz> okay, i found a copy of the modpywsgi somewhere else, the script isn't barfing anymore at least
<Kobaz> bzr init-repo bzr+https://bzr.local/bzr/newrepo
<Kobaz> bzr: ERROR: Transport operation not possible: readonly transport
<Kobaz> now what?
<Spaz> you shouldn't be using https to do that.
<Spaz> use bzr+ssh
<Kobaz> i thought you were supposed to be able to have write access with the mod_python setup?
<Kobaz> hmm
<Kobaz> for creating the repo?
<Spaz> using the bzr_access script (it's easy to set up)
<Kobaz> or for all write operations?
<Kobaz> k
<Spaz> for all write operations
<Kobaz> hmm
<Kobaz> so i should use ssh for everything then?
<Kobaz> i don't really want to use one for reading and one for writing
<epper> "Centralized with local commits" and "Decentralized with shared mainline" workflow aren't in fact two different ways to get the same result?
<Kobaz> no idea... sounds the same to me
<epper> so: developers working alone on their tasks and commiting to the main repository when ready?
<Kobaz> yeah
<bob2> they're all different ways to get the same result, more or less
<Kobaz> that's the advantage of a decentralized vcs
<bob2> Kobaz: you can just use ssh for everything, and it is a lot easier to get going than webdav + mod_python + ...
<Kobaz> subversion: commit new feature... commit fix for new feature... commit fit for the fix... commit documentation
<fullermd> All the smart server protocols are capable of writing, if writing is enabled.
<bob2> assuming you have the infrastructure to easily manage accounts etc
<epper> Yes, I agree... It's a huge advantage... even with the ability to commit to someone else working copy without touching directly the main trunk
<Kobaz> distributed: checkout repo, commit commit commit commit (to local)... and then when you finish all your work... commit that batch to the central repo
<Kobaz> fullermd: oh, that's good
<Kobaz> fullermd: how would i enable writing?
<Kobaz> bob2: i dont really want to have to give out ssh accounts for each developer
<fullermd> Kobaz: The examples given in the docs all set things to read-only.  Just flip the boolean value of the readonly setting, and it should work.
<fullermd> (this is educated guesswork, since I've never used the HTTP smart server variants, but I'd expect it to Just Work)
<Kobaz> oh, i didn't notice the readonly setting
<fullermd> "Centralized with local commits" involves treating checkouts as half-checkouts, either via commit --local or unbind, which I consider to be an all-around Bad Idea.  IMO.
<epper> fullermd: I'm really new to bazaar (but i use svn)... Why are they a Bad idea?
<Kobaz> bzr init-repo bzr+https://bzr.local/bzr/newrepo
<Kobaz> bzr: ERROR: No such file: None
<Kobaz> oooo
<Kobaz> i did a mkdir newrepo on the server
<Kobaz> and that worked
<Kobaz> heh, the error reporting isn't very good
<epper> fullermd: Seem to me that the other way get the same result... Is it better? why?
<fullermd> That's a long question.  The short version is that they mean treating a checkout (which isn't an independent branch) as an independent branch.  It's a basic impedence mismatch.  It's aggravated by some suboptimal tool behavior in certain of the cases, but even with those fixed, it's riding Roman.
<fullermd> Basically, the purpose of checkouts is to work in lockstep on a single branch from multiple working trees (e.g., the _only_ way CVS/SVN/etc work).
<fullermd> Whereas making independent branches via 'branch', and then moving changes back from them via 'merge', is operating more in the distributed mold.
<fullermd> Local commits in checkouts (either via ci --local, or via unbind/bind hoops) is using the former tool to achieve basically the latter behavior.
<Kobaz> okay so now that i have a remote shared repo
<fullermd> I mean, it _works_, and it's there intentionally.  And there are people who are perfectly happy with it.
<Kobaz> how do i add to it, or do a checkout from it
<Kobaz> bzr branch bzr+https://bzr.local/bzr/newrepo
<Kobaz> bzr: ERROR: Not a branch: "bzr+https://bzr.local/bzr/newrepo/".
<fullermd> But it's kinda skating on the edge in a way.  And it's double evil, since the behavior can end up being really confusing if you're not already familiar with using bzr in both types of workflows, so considering it when you're in an "intro" mode is particularly egregious.
<fullermd> Kobaz: You don't checkout or branch or work in repositories in bzr; the main unit is the branch.
<fullermd> So you'd have to `bzr init bzr+https://bzr.local/bzr/newrepo/trunk` (or whatever you want to call it) before you can work on it.
<Kobaz> k
<epper> fullermd: So you suggest to take the second approach
<epper> "Decentralized with shared mainline"?
<Kobaz> okay, i think i have it working now
<fullermd> Roughly, yah.  I think it's less confusing, because it means you always _know_ whether you're dealing with the [shared] trunk, or a [non-shared] local branch.
<Kobaz> what's a good way to do a live backup of a bzr repo
<Kobaz> i know svn has svnsync
<epper> fullermd: Understood, thanks very much ;)
<epper> And... Other options for a free Bazaar hosted repositories than launchpad?
<fullermd> There's nothing in bzr that copies around repositories.  You could "pull" all the individual branches in it.  You could grab up the repo with FS-level tools (tar, rsync, etc).
<fullermd> There are things like bzrtools' "multi-pull" that can help with automating the former choice.
<Kobaz> but with using rsync, is there any issue of copying over a half written file
<Kobaz> there are issues with svn (and others) about just backing up the raw files
<Kobaz> when you do a pull, does it pull down just the latest data, or does it pull all history
<bob2> former, such that you end up with all
<Kobaz> k
<Kobaz> so if you wanted to back up the repo with history
<Kobaz> you would need to rsync
<Kobaz> or would the multi-pull accomplish that?
<Kobaz> $ bzr st
<Kobaz> modified: a
<Kobaz> $ bzr push
<Kobaz> Using saved push location: ...
<bob2> multi-pull should do
<Kobaz> No new revisions to push.
<fullermd> You can certainly copy over a half-written file, but it wouldn't be in a place bzr would look for it, so it doesn't much matter.
<bob2> sure, pull only gets /history/ ie things that are commited
<fullermd> multi-pull pulls a set of branches.  Nothing pulls a _repository_ as such.
<Kobaz> k, that was the question
<Kobaz> and umm... so i modified a file, and the push isn't sending it up
<fullermd> You didn't commit it.
<fullermd> push/pull only deal with commits.  Uncommitted changes never go anywhere.
<Kobaz> ooooh
<bob2> just like in svn, y our uncommited changes exist only in the working tree
 * Kobaz initiats an svn excersisim
<Kobaz> s/initiats/initiates/
<Kobaz> yeah
<Kobaz> i was thinking push would auto commit, because with svn there is no differentiation
<fullermd> One way of thinking about it (which is subtly incorrect, but can be a useful mental crutch) is the differentiation between recording and publishing.
<fullermd> In SVN, there isn't any; commit is both for recording what you're doing, and publishing it to the world.
<Kobaz> yeah, i know what it means
<fullermd> With a distributed system, they're different; commit records it, and push publishes what's recorded.
<Kobaz> yeah
<fullermd> (it's technically wrong of course because it all depends on what branches are where and what branches you're committing to.  But it's close enough for a rule of thumb)
<Kobaz> yeah, if someone is working off your branch directly
<Kobaz> then you don't need to push
<Kobaz> the use of only one .bzr directory is pretty awesome
<fullermd> Or if you'd done a "bzr checkout bzr+https://wherever/newrepo/trunk", then the branch you put things into when you commit actually is the bzr+http://... one (since you have a checkout, rather than an independent branch)
<Kobaz> yeah
<Kobaz> bzr push
<Kobaz> bzr: ERROR: No push location known or specified.
<Kobaz> bzr lost my push location
<Kobaz> it just had it
<fullermd> What's bzr info say?
<Kobaz> it has it now, i specified a specific push path
<bob2> bzr push doesn't default to the place you bzr branch/pulled from
<Kobaz> lemme do what i dod again
<bob2> once you specify a push location once, though, it will be remembered
<Kobaz> s/dod/did/
<fullermd> There are automatic aliases for the various saved locations too, so if you wanted to push to where you pull'd from, you could "bzr push :pull"
<Kobaz> it was working
<Kobaz> and then it lost it
<nevans> fullermd, I didn't know you could do that... what "bzr help" topic didn't I read?  :)
<fullermd> nevans: Well, lots of them probably   :p
<Kobaz> hmm, can't seem to reproduce it
<nevans> which one is the ":pull" -- "branch location meta names" in?  :)
<fullermd> nevans: But I don't think it's particularly documented anywhere...
<Kobaz> i definitly did a push earlier from that directory
<fullermd> Oh, I guess it's :parent actually, not :pull
<nevans> fullermd, I would have expected that to be in urlspec.
<Kobaz> hehe
<Kobaz> any time i want to do a bzr command, i keep typeing svn
<fullermd> Mmm.  Not really, since they're not URL types.  They'd deserve their own topic.
<fullermd> AFAIK, the only place you'd actually see them referenced is in NEWS, and you end up having to check the source for the list of what choices there actually are.
<nevans> hmmm...
<fullermd> Kobaz: That's nothing.  Use bzr for a year or so, and you'll be totally unable to type 'bzr'.
<fullermd> Aarg!.  'bar'!
<fullermd> See?
<Kobaz> heh
<Kobaz> bzr bzr bzr bar
<Kobaz> mmm
<fullermd> A guy walks into a bzr...
<Kobaz> two guys walk into a bzr
<Kobaz> you would think the second one would have noticed
<Kobaz> okay, so next question...
<Kobaz> what's a good windows client
<Kobaz> for those other people
<fullermd> markh would be the guy to talk to about that, I think.
<markh> a good bzr windows client?  There is only 1 available for each version, so take your pick :)
<markh> iow, there's not alot of choice really
#bzr 2008-11-20
<Kobaz> heh, k
<epper> fullermd: Just a question to check that I've understood correctly how bazaar works:
<epper> In svn, when you've to implement a new complex feature you usually create a branch, commit partial changes to it (updating the branch periodically)... And then merge it into the trunk again.
<epper> In bazaar a working copy is in fact a branch... So you just create your workingcopy ("local" branch), make your changes and then commit them into the trunk with the full history
<epper> Right? I think that this is the key of the two systems... Am I right'
<epper> ?
<bob2> you can do that.  you could also create a branch next to the public "trunk" and work in that, so people can see your changes as they happen (or as you push).
<freewilly1> you can also use looms instead of branches, afaik
<freewilly1> I still haven't played with that
<bob2> the key difference is that branches can be anywhere, rather than just all together in some central repository
<freewilly1> although they can share a repository for efficiency sake ;)
<fullermd> Well, looms are (IMO) more aimed at the case where you have a larger number of layers.
<epper> looms... googling... I never saw this word in the svn world :)
<fullermd> svn 1.5 has (AIUI) much better merge tracking than previous versions, so using branches like that probably works better there now.  But the branches all still have to be in one single repository.
<fullermd> Well, that's becaues it doesn't exist in the svn world.  Or anywhere else, for that matter   :p
<fullermd> It's a method for automating some of the housekeeping involved when you have a stack of branches, for implementing layers of features.
<epper> ah, ok... Because I've not found any usefull information
<epper> But...
<fullermd> e.g., you have an "upstream" branch, based on which you have a "feature1" branch to add feature1, based on which you have a "feature2" branch that takes everything from feature1 and adds feature2 on top, based on which you have a 'feature3' branch that needs feature2 and adds feature3 on top, based on which...
<fullermd> As opposed to doing all the above in a "allmyfeatures" branch.  It lets you keep them separate, even though each builds on the other.
<fullermd> You could do the same thing with just having N branches, but loom automates a bit of the bookwork in keeping them stacked and synced.
<epper> ... in bazaar... When you worked on you working copy (that's a branch) with your commits (aka push?)... And than you commit your final work to the main repository... Do all the changeset get transferred to the main repository too?
<bob2> yes
<epper> Good, I thought so... But I needed a confirm ;)
<fullermd> In bzr, you'd do that by merging [the changes in] your local branch into the trunk.
<fullermd> So the answer is "yes, but your phrasing doesn't really fit what you do with bzr"   :)
<igc> morning
 * fullermd waves at igc.
<epper> fullermd: Yeah, I'm not comfortable with bazaar words yet... :D I'm steel a svn supporter for now ;)
<igc> hi fullermd
<fullermd> epper: Oh, don't worry about THAT; we've got re-education camps to solve that problem...
<epper> lool
<fullermd> The first step, really, is to work at thinking in terms of branches, rather than repositories.  In SVN, the repo is a sharp boundary for a lot of things; in bzr, it doesn't affect much of anything conceptually.
<fullermd> Conversely, in bzr, a branch if a boundary from inside, and a unit from outside, whereas in svn, it's a weird construct of a conventional subpart of a repository.  Wacky.
<epper> Yes, but I think that this way of handling branches would be usefull adding new complex features and removing all the not-so-stable commits that I could find very often in SVN repositories every day.
<fullermd> Of course, that also means that in svn you can branch a file within a branch, then branch the branch with a branched file in the branch, and then branch the two branches, one a branch of the other, both with a branch of the file in the branch...
<epper> Lost in branches
<epper> But probably staying here only analyzing bazaar without trying it will not reveal other intresting uses of its featuers... sure of that
<epper> Thanks again fullermd, now I've a better view of bazaar... Maybe better than subvesion one day ;)
<epper> It's time to go to sleep here, thanks... and good bye ;)
<thumper> poolie: did you know that the nightly ppa isn't updating?
<poolie> thumper: i did not
<poolie> statik runs it
<thumper> yeah, I have pinged statik but no answer yet
<statik> thumper: i lost my hard drive in the computer that was running the nightly bzr sourcepackage builds, i've moved things to a slicehost machine and just haven't finished. i'll finish now
<thumper> statik: thanks
<thumper> statik: I'd also like to talk to you about LP reviews if you have a few minutes
<statik> thumper: np. funny, this is the first time i've signed onto freenode in a long time
<thumper> statik: you have been missed :)
<statik> thanks man, i will try to connect to freenode more
<statik> thumper: give me 10 minutes to finish this, then i we can talk code reviews
<thumper> statik: ack
<halstead> hopefully easy question: is there a way to show all logs relating to any file/directory in a tree of directories?
<statik> poolie, thumper: nightly bzr package build seems to be safely back in cron, and packages should hit the PPA in 15 minutes or so
<thumper> w00t
<poolie> thanks
<halstead> 'bzr diff directory' does show the differences in all files in directory 'bzr log directory' only shows logs from when the directory itself was altered. Can I make bzr log behave like bzr diff?
<halstead> Ah I guess I found the answer: https://lists.ubuntu.com/archives/bazaar/2008q3/046146.html
<halstead> :(
<freewilly1> :( indeed
<rocky> hm, are the milestones not being updated on https://launchpad.net/bzr  ?
<beuno> rocky, they look like the are
<rocky> looks pretty bare   https://launchpad.net/bzr/+milestone/1.9.1
<beuno> rocky, 1.9.1 hasn't been released yet
<rocky> oh i thought it had
<rocky> bah
<rocky> sorry
<rocky> which branch is active dev happening on now?
<rocky> just lp:bzr?  when will that get branched as 1.10 ?
<thumper> rocky: normally when 1.10 goes into release candidate
<rocky> gotcha
<dstanek> i merged changes from a svn working copy to my bzr branch with the the svn plugin - they are showing up as pending merges - what does that mean?
<rocky> dstanek: you still need to do a bzr commit to your local branch
<dstanek> ah i c
<dstanek> rocky: yep thanks,that was it
<rocky> thumper: does everything that goes into bzr go through a blueprint first?
<thumper> no
<thumper> rocky: most go through bugs
<thumper> rocky: but certainly not all
<rocky> blueprints are mostly about more sweeping changes?
<thumper> rocky: I'm not sure how much the blueprint feature is used
<thumper> for bzr
 * rocky is trying to understand bzr and it's use in and for launchapd
<rocky> *launchpad
<rocky> thumper: this looks like it's being neglected (which would support your comment)  ...  https://blueprints.launchpad.net/bzr/+spec/0.10-release-process
<thumper> rocky: if you want to talk about launchpad, we could go to #launchpad
<rocky> well, this is about how bzr uses launchpad ... so i dunno where i should talk ;)
<thumper> :)
<thumper> I think bzr uses bugs more than blueprints
<rocky> is there a non-automated roadmap someplace i could look at?
<rocky> i just realized i was mistaking 0.10 for 1.10
<poolie> rocky: what kind of question specifically?
<rocky> i just want to see what's planned for the next major release of bzr
<poolie> the best place to look is here: http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html
<Peng_> beuno: Sorry, but I have no idea how Google found the broken URL.
<poolie> spiv, still around, want to talk before I finish up?
<vila> Good morning all
<elmo> oh hai
<elmo> why haz bzr log not to be having useful (i.e. portable) revision identifiers even with -v?
<AfC> elmo: the argument --show-ids is what you want.
<AfC> (assuming "revid"s are what you are looking for, but you _rarely_ need them)
<elmo> AfC: it's what I'm looking for - I was put off by the "internal use" in the --help output
<elmo> AfC: how else should I specify the revision I'm talking about with someone who has the same history, but not the same tree, so revnos don't match?
<AfC> if you have a copy of the branch the revnos will be the same up to the point of divergence.
<elmo> I don't quite now what I have vs what barry has.  it's launchpad, so pqm managed if that makes a difference.  all I know is that he has the same history, so I could specify the revid and it worked for him, but his revnos were completely divergent
<elmo> sorry, same history probably isn't accurate in VCS speak
<elmo> I mean, he has at least all the changes I have, I guess
<luks> elmo: if you have a shared mainline, anything on the mainline can be considered stable
<vila> elmo: revid are globally unique identifiers, so you can use them across different branches, if "he" doesn't have "your" revid, "he" misses part of "your" history
<AfC> elmo: also, after you've cloned his branch, doing `bzr missing --line ../path/to/his/branch` can be very useful.
<elmo> right, sorry for wasting your time
<elmo> apparently barry did have the revno after all, and I'm just a muppet (too) and didn't notice him saying so (later)
<AfC> Hooray for the Muppets!
<AfC> http://www.evula.org/solarsystem/Resources/muppet.jpg
<SteveA> poolie: ping
<awilkins> I seem to be having a problem with authentication.conf ; it's not being read at all as far as I can mak eout.
<awilkins> Hold on, test a little more I wil
<awilkins> Ok, I'm trying a pull from a smart http server, it's throwing back a 401, and bazaar is just stopping there.
<awilkins> It's not even trying to access authentication.conf (confirmed by using a filesystem debugger)
<fullermd> awilkins: At one point, http wouldn't even try auth unless the username were given in the URL.  Maybe that's still the case?
<awilkins> fullermd: The documentation says otherwise, but I'll try it
<awilkins> Yes, it reads the file and uses the password
<awilkins> Bah
<awilkins> Well, that's just NAUGHTY, not doing what the docs say.
<awilkins> Looks like _SharedConnection() needs to try matching authentication.conf in transport/_init_
<alum> Hi, is trigger plug-in included into bzr? I saw https://lists.ubuntu.com/archives/bazaar/2006q1/007285.html, but it seem to be a little bit obsolete.
<jam> alum: I haven't heard anything about trigger since that 2006 thread
<alum> jam: I'll appreciate it in main bzr. Is there any plans?
<jam> alum: as I haven't heard of it for 2 (almost 3) years, nobody seems to be pushing to get it included.
<jam> If you are interested, you could put together a patch for it
<jam> and we would review it like everything else
<jam> personally, I find the functionality fits very well as a plugin
<jam> I'm willing to be persuaded as to why it should be a core feature, though.
<gotgenes> I need to create a copy of a file, but there's no bzr copy command. What should I use instead?
<awilkins> cp file new-file
<awilkins> bzr add new-file
<gotgenes> but will the revision history follow the copied file?
<awilkins> No
<gotgenes> That's unfortunate
<beuno> gotgenes, bzr manages renames, but not copies
<awilkins> But there is no feature that will make it, alas.
<awilkins> Why do you need to copy the file?
<gotgenes> It's my CV
<awilkins> (just to get a better idea of what alternatives may be pertinent)
<gotgenes> I need to pare it down to a resume
<awilkins> Would a "resume" branch of the main "CV" branch be more useful?
<gotgenes> Mmm, let me think.
<awilkins> Then changes to CV could be merged to "resume" (but you'd probably get a reasonably ;arge conflict set)
<NfNitLoop> (CV?)
<gotgenes> probably would get a large conflict set
<awilkins> Curriculum Vitae
<awilkins> Commonly used UK (Europe) term for what 'mercans call "Resume"
<gotgenes> awilkins: I suppose I'm probably not going to merge the two ever, being practical and forward thinking.
<awilkins> I'm presuming it's even in a format that merges well :-)
<NfNitLoop> Huh, yeah, I've never heard it called that here.
<gotgenes> awilkins: LaTeX
<awilkins> That would count :-)
<awilkins> You in the molecular biology field then?
<gotgenes> awilkins: Yeah
<gotgenes> well, bioinformatics
<alum> jam: From my point of view it could be very interested, because I wit it I can automatically re-create source package after commit. This is something I need. Or it can send me notification e-mail with changes.
<gotgenes> but I started in molec. bio.
<awilkins> I got turned down for a bioinformatics research post once :-)
<gotgenes> awilkins: Where? Hopefully not here.
<awilkins> Manchester Uni
<gotgenes> (VBI)
<jam> alum: I would look closely at the post-branch-tip-changed plugin hook, or bzr-email
<gotgenes> awilkins: Ah, yeah, they have a big outfit there.
<jam> but it depends on what level you want to be implementing your custom work, I guess
<awilkins> I didn't have enough propellor-headed C for them
<awilkins> Loong tme ago
<gotgenes> They probably have more money now
<gotgenes> It seems demand doesn't go down.
<awilkins> Does LaTeX support the means to hide bits of your CV by applying anything like a stylesheet?
<gotgenes> Too much data.
<gotgenes> awilkins: I think it does actually.
<gotgenes> That's how Beamer works at least.
<awilkins> I don't use mine enough to do this, but I always think about writing it in XML and using XSLT on it
<gotgenes> But it's not something I know how to do at the moment and being pragmatic, I should at least get it done now, then go back and do it "right" when time's on my side.
<alum> jam: Thanks, I'll look at it
<jam> awilkins: well, considering that Tex is Turing complete (IIRC) I'm pretty sure you could do lots of things with it
<awilkins> Anyway ; anyone want to comment on https://bugs.launchpad.net/bzr/+bug/300347
<gotgenes> Yeah, I have no idea what the best format to do it in would be.
<ubottu> Launchpad bug 300347 in bzr "HTTP transport does not use authentication.conf unless you supply a user name." [Undecided,New]
<jam> alum: I also seem to remember a plugin that extended plugin hooks to allow it to run shell scripts
<jam> vila: ^^ bug 300347 seems right up your allye
<ubottu> Launchpad bug 300347 in bzr "HTTP transport does not use authentication.conf unless you supply a user name." [Undecided,New] https://launchpad.net/bugs/300347
<awilkins> Thought vila was the man for this one
<jam> well he did write the authentication.conf support
<awilkins> He seems to be the go-to guy for anything transport related
<vila> at first read that sounds really strange... do you use the pycurl or the urllib based http client ?
<awilkins> urllib
<awilkins> pycurl causes worse problems for me
<awilkins> (my other problem is proxy settings - neither of them understand PAC scripts and it seems to be impossible to use environment variables to tell them to NOT use a proxy)
<awilkins> They take the default IE settings and fail. :-(
<Kobaz> is it more worser
<jam> awilkins: isn't there a "none_proxy" or something equivalent
<jam> to explicitly list hosts that shouldn't be proxied
<awilkins> jam: Hmm, I'll look through the urllib source
<awilkins> jam: I was looking for values of HTTP_PROXY like "DIRECT" (which is what PAC scripts return)
<awilkins> (magic values)
<vila> awilkins: PROXY env vars *are* magic (as in never specified and implemented in gazillion different ways by all browers and their sister)
<jam> looking at urllib.py
<jam> I see it has code to read the magic registry entries on windows
<awilkins> vila: I got that feeling but I'm only looking for magic that works with Bazaar :-)
<vila> which python version are you using ?
<awilkins> jam: Yes, it does, it does a reasonable job of reading the IE proxy values, but they are a problem
<awilkins> vila: 2.5
<jam> though it has both "getproxies_environment()" and "getproxies_registry()"
<jam> from the look of it
<jam> env vars override the registry
<jam> as long as they have something defined
<awilkins> jam: ENV overrides the resgitry, but I want NO proxy
<jam> set http_proxy=''
<jam> isn't enough to get that?
<jam> I also see a "getproxy_bypass"
<awilkins> jam: Problem is that IT services force proxy settings on use via group policy - the server is available direct from both sides of the network so no proxy is required
<jam> which looks at the ProxyEnable and ProxyOverride settings in the registry
<awilkins> And their proxy setting is a PAC script anyway, so Python can't use it
<awilkins> Hmm, I've been setting the env variable from the shell, maybe I can set an empty value from the GUI
<vila> awilkins: use no_proxy=host:port
<jam> ProxyOverride seems like something worth exploring
<jam> ProxyOverride="host;<local>" seems like it might work
<vila> awilkins: did your patch fixes *your* problem ? Because it looks a lot like  code already in _urllib2_wrappers (in get_user_password)
<awilkins> vila: Yes, it fixes my specific problem ; I did peruse the code in _urllib2_wrappers before I wrote it
<awilkins> It's all rather complicated, hence not sending a merge to the list.
 * vila scratching head
 * fullermd scratches vila's head too, for luck.
<vila> awilkins: you can use -Dauth to see which sections are accessed in auth.conf
<awilkins> With and without patch?
<awilkins> Without patch I'm afraid it never touched auth.conf
<vila> Can you try, without patch, with -Dauth and -Dhttp and send me the .bzr.log (sanitize appropriately depending of your auth scheme, etc)
<vila> then, some thing but *with* your patch
<vila> s/some/same/
<vila> bug #300055
<ubottu> Launchpad bug 300055 in bzr ""bzr log --forward FILE" crashes for revision range if first revision is not mainline" [Medium,Confirmed] https://launchpad.net/bugs/300055
<awilkins> vila: I've attached a log to the bug at http://launchpadlibrarian.net/19813229/auth-conf-http-log.zip
<awilkins> vila: Watching the file with a filesystem monitor, the process does not attempt to access auth.conf at all during the session.
<awilkins> And some combination of your "no proxy" tips PLUS me realizing that I'm a moron with the wrong IP in his hosts file has fixed my problem.
<awilkins> (with proxies)
<awilkins> I shall have to clean it all up and see which tip is most effective for least effort
<Kobaz> anyone familiar with loggerhead?
<Kobaz>   File "./start-loggerhead.py", line 3, in ?
<Kobaz>     import pkg_resources
<Kobaz> i can't start the server
<jam> do you have the dependencies installed?
<Kobaz> heh
<Kobaz> which dependencies?
<Kobaz> there's none noted in the docs
<vila> awilkins: thanks for the log, I'll look into fixing the bug asap, keep your patch if it suits you for the time being
<jam> beuno: ^^ ?
<jam> I don't remember the exact ones
<jam> but simple-tal comes to mind
<NfNitLoop> Kobaz: looks like setuptools...
<NfNitLoop> (aka: easy_install)
<Kobaz> k
<beuno> Kobaz, we have noted them on the README
<beuno> you need python-paste and python-simpletal
<Kobaz> # grep -i setuptools README.txt
<Kobaz> #
<beuno> It's actually the first thing the readme says  ;)
<beuno> right, READ the README
<beuno> 11 GETTING STARTED
<Kobaz> i did, there's nothing in there about deps
<beuno>  12 ---------------
<beuno>  13
<beuno>  14 Loggerhead depends on.
<beuno>  15 1) SimpleTAL for templating.
<beuno>  16    on Ubuntu package `sudo apt-get install python-simpletal`
<beuno>  17    or download from http://www.owlfish.com/software/simpleTAL/download.html
<beuno>  18 2) Paste for the server. (You need version 1.2 or newer of Paste.).
<beuno>  19    on Ubuntu package `sudo apt-get install python-paste`
<beuno>  20    or use `easy_install Paste`
<Kobaz> which readme are you reading?
<beuno> Kobaz, where did you get loggerhead from?
<Kobaz> https://launchpad.net/loggerhead/+download
<beuno> version?
<Kobaz> erm
<Kobaz> 1.2.1
<beuno> right
<beuno> I'd say, either get 1.6.1
<beuno> or trunk
<Kobaz> yeah, that is trunk
<Kobaz> which is why i downloaded it, thought it was the stabl
<beuno> right, it's confusing
<beuno> let me delete those...
<beuno> there
<beuno> now, get 1.6.1  :)
<vila> beuno: LOL
<Kobaz> heh, k
<beuno> or branch from trunk, which is pretty close to a release  :)
<beuno> sorry about that Kobaz
<Kobaz> hehe
<Kobaz> okay
<Kobaz> now i see the dependencies
<beuno> :)
<Kobaz> is there a way i can use it to serve all repos automagically
<beuno> this reminds me why we changed *everything*
<Kobaz> instead of configuring each thinger seperatly or spawning a new daemon for each one
<beuno> Kobaz, sure, just run "serve-branches", and it will server anything in that dir
<Kobaz> oh okay
<Kobaz> so what was the reasons behind the design decision to make it an independent daemon rather than a series of web scripts and let apache handle the rest
<beuno> well, we sort of inhertied the project, so a lot of the decisions came pre-made
<beuno> but I think we wouldn't want people to need mod_python
<beuno> and we really wanted loggerhead to be standalone
<beuno> apache is an overkill in many cases
<beuno> you can still use apache though
<Kobaz> yeah
<Kobaz> well it's like... reinventing the wheel versus using an existing codebase
<beuno> in what way?
<Kobaz> ie: not having to worry about keeping track of client connections, etc
<beuno> right, paste does that for us
<Kobaz> oh
<Kobaz> playu
<Kobaz> er
<Kobaz> off the home row
<Kobaz> ah, okay
<Kobaz> mmm
<Kobaz> it's working
<Kobaz> yay
<beuno> :)
<Kobaz> is there a nice way to have the daemon write a log file
<Kobaz> instead of dumping everything to stdout
<Kobaz> i can do a redirect to a file, but then you can't rotate the log file without restarting the daemon
<beuno> it should log by default as well
<beuno> and rotate logs
<Kobaz> hmm
<Kobaz> where does it write the logs
<beuno> Kobaz, you can also do --log-folder=LOG_FOLDER
<Kobaz> k
<Kobaz> that's not in --help :P
<beuno> it is here!
<beuno> not 100% sure if maybe that wasn't released in 1.6.1
<Kobaz> 1.6.1?
<Kobaz> heh
<beuno> so, again, I'd recommend branching trunk
<beuno> bzr branch lp:loggerhead
<Kobaz> oh, that's what you mean
<Kobaz> okay so.... i have the apache proxy going
<Kobaz> all my links point to 127.0.0.1
 * Kobaz pokes beuno 
 * beuno pokes Kobaz back
<Kobaz> oh, you weren't here when i wrote
<Kobaz> okay so.... i have the apache proxy going
<Kobaz> all my links point to 127.0.0.1
<beuno> did you install python-pastedeploy?
<Kobaz> hnmm
<Kobaz> apparently not, installing it now
<beuno> :)
<Kobaz> okay
<Kobaz> the links work now
<Kobaz> kinda
<Kobaz> i have a https url
<Kobaz> and all the links are the right hostname, but http
<beuno> ah
<beuno> you may have to tinker with loggerhead itself to get it to work with http
<beuno> patches welcome  :)
<Kobaz> heh
<Kobaz> k
<Kobaz> so next question
<Kobaz>     <Location /webbzr/>
<Kobaz>         ProxyPass        http://127.0.0.1:8082/
<Kobaz> that setup
<Kobaz> doesn't seem to work, and i get this:
<Kobaz> File does not exist: /home/web/bzr.local/static
<Kobaz> in my error logs
<Kobaz> if i do...
<Kobaz> <Location />
<Kobaz> then it works out
<Kobaz> oh wait, is static a dir in loggerhead
<Kobaz> i may need to alias that
<Kobaz> okay, aliasing it worked nicely
<Kobaz> beuno: what chunk of code makes the links
<Kobaz> your code isn't really commented, heh
<beuno> Kobaz, off the top of my head, apps/config.py or apps/branch.py
<beuno> heh, well, again, it's partially because it was inherited
<Kobaz> yeah i'm looking at apps/branch.py
<Kobaz> i found the url function
<vila> Kobaz: newcomers are the best comment writers ! I'm sure beuno will love your patches :)
<Kobaz> yeah but
<Kobaz> i've never written python in my life
<Kobaz> so this may be a little painful
<beuno> Kobaz, python is fun!
<vila> Kobaz: for comments, python is quite simple and pretty much like bash: start with a '#' and add poetry :)
<Kobaz> yeah
<Kobaz> i'm a c/c++/perl/php/bash/tcl/asm guy
<vila> Kobaz: I was a perl guy for ~10 years before trying python, the transition is *not* painful, once you get rig of ';' and the sigils, things are even pretty fun
<Kobaz> heh
<LeoNerd> You just have to banish the very thought of "variables" out of your head.
<Kobaz> whitespace dependency has always weirded me out
<LeoNerd> And lose a whole load of other concepts while you're at it
<vila> Kobaz: whitespace dependency worried me for a couple of days... until it just stopped worrying me leaving me confused about *why* I was worried ;-)
<LarstiQ> beuno: can loggerhead and bzr branches live at the same location? (so that I can branch from the url of what I'm looking at in loggerhead)
<beuno> LarstiQ, they can, yes. And, there's a bug open for displaying the "public location" on the web UI
<beuno> if you're feeling hackery-ish  :)
<LarstiQ> maybe tomorrow :)
 * LarstiQ is starting to get hungry, and should head home
<Kobaz> bzr push bzr+https://user:pass@bzr.local/bzr/repo/
<Kobaz> that works fine
<Kobaz> but then i do a "bzr push"
<Kobaz> Using saved push location: push bzr+https://user:pass@bzr.local/bzr/repo/
<Kobaz> bzr: ERROR: Generic bzr smart protocol error: Invalid http response Unable to handle http code 401: Authorization Required
<Kobaz> it doesn't save the user/pass
<Kobaz> so hmm, does noone know how to preserve the login to a repo?
<Kobaz> anyone home
<thrope> how long is bzr vis supposed to take? I just tried it on three small branches (latex document - 1 text file, ~25 revisions) and the cpu's been at 100% for 3 minutes
<thrope> my bad - its apple x11 playing up not bzr
<luks> that's way too long, it should be faster
<thrope> it only seems to show one branch at a time though (the last one on the command line)
<thrope> how can I see the relations between them?
 * luks can't help with that
<luks> (but I can recommend bzr qlog ;))
<thrope> ah much nicer
<thrope> thanks
<Kobaz> do de do
<Kobaz> when i do: bzr push bzr+https://user:pass@bzr.local/bzr/repo/
<Kobaz> it doesn't save user:pass in he branch.conf
<Kobaz> beuno_: i fixed the url problem
<beuno_> Kobaz, it a "submit a patch
<beuno_> way?
<Kobaz> well
<Kobaz> it's not really patched
<Kobaz> but
<Kobaz>     def get_history(self):
<Kobaz> in that function
<Kobaz> er
<Kobaz> not that one
<Kobaz>     def url(self, *args, **kw):
<Kobaz> in that function
<Kobaz> in branch.py
<Kobaz> there's: return request.construct_url(....
<Kobaz> i dont know where that function is, i can't find it in the source... so it's either a python builtin... or it's part of some lib
<Kobaz> that auto puts a http:// on it
<Kobaz> and i can't find out how to make it not to that
<Kobaz> sooo
<Kobaz> instead of return request.contruct...
<Kobaz>         return '/webbzr' + self._url_base + '/'.join(args) + '?' + qs
<Kobaz> my root url is mysite/webbzr/
<Kobaz> i don't know how to get the current url in python, but
<Kobaz> that works for me
<Kobaz> i dont even know how to print out data structures... so i just hard coded the bit... heh
<beuno_> right
<beuno_> we probably need to find the rigth paste knob
<beuno_> mwhudson knows about these things
<beuno> but he's in new zealand, so it may take him a while to get coffee and pop in
<Kobaz> ah
 * mwhudson is here but not yet coffeed
<beuno> see  :)
<Kobaz> okay so
 * Kobaz loads up gump
<Kobaz> gimp
<Kobaz> bunches of suggestions...
<Kobaz> "compare with another revision" in the /revision/ page... doesn't do anything
<beuno> it's obscure
<Kobaz> and here's some suggestions for the /revision/ page
<beuno> you can then go to another revision
<beuno> and click COMPARE THESE TWO
<beuno> or something along those lines
<Kobaz> oh
<Kobaz> it should pop up a new window ore something
<Kobaz> and say, pick a new rev to compare to
<Kobaz> anyways... accept my file :P
<Kobaz> s/ore/or/
<Kobaz> http://www.kobaz.net/misc/diff.jpg
<Kobaz> okay well
<Kobaz> you don't have to accept it anymore, i put it up
<beuno> accept what?
<beuno> DCC!
<beuno> I haven't seen that in years
<Kobaz> the file i just tried to send you
<Kobaz> hehe
<Kobaz> anyways... so
<Kobaz> it's not obvious which revisions you are comparing in the viewer
<Kobaz> so, it would be good to add two bits of text... one for each side, of which rev you're comparing
<beuno> I know, there's a bug about that somewhere in bugs.launchpad.net/loggerhead
<Kobaz> and then at the bottom... the prev/next seems backwards to me
<beuno> and. you're not comparing as much as looking at the diff
<Kobaz> previous goes to more recent in the history
<Kobaz> and next goes older in the history
<Kobaz> well, yeah hmm
<Kobaz> but it would be good to note, which rev it's going to jump to
<Kobaz> because prev/next are unintuitive
<beuno> right, there's a bug about that too
<beuno> AND
<Kobaz> but i mean... if you use it for more than 5 minutes, you would realize what it does
<Kobaz> k
<beuno> you can file new ones :)
<Kobaz> hehe
<Kobaz> okay
<beuno> it takes us a bit, but eventually we fix them
<Kobaz> just pointing some stuff out
<Kobaz> yeap
<tgunr> I'm new to bzr and tried last night to use bzr get lp:bzr-svn and am getting an error about "Server does not understand Bazaar network protocol 3" Does the Launchpad server have an older version maybe?
<rockstar> tgunr, what version of bzr are you using?
<tgunr> Bazaar (bzr) 1.9 on Mac OS X 10.5.5
<rockstar> tgunr, lemme try this out.
<rockstar> tgunr, I'm on 1.9 and it worked fine.
<tgunr> I was looking for a way to find out what the lp server uses and maybe force bzr to use a different protocol. Is that even possible?
<tgunr> hmm, on my side then
<tgunr> actuall, I get 2 more lines of errors
<tgunr> Server does not understand Bazaar network protocol 2, reconnecting.  (Upgrade the server to avoid this.)
<tgunr> bzr: ERROR: Generic bzr smart protocol error: Server is not a Bazaar server: Received bad protocol version marker: "Not allowed to execute '/usr/local/bin/bzr serve --inet --directory=/ --allow-writes'.\r\n"
<Tak> what the hell: $ bzr status -S README
<Tak>  M  README
<Tak> C   Text conflict in README
<Tak> wtf not just: CM  README
<LarstiQ> probably because noone like the short status format? ;P
<LarstiQ> tgunr: do you have a BZR_REMOTE_PATH set?
<Tak> it would be ever so helpful for reading the output programmatically
<LarstiQ> *brrr*
<LarstiQ> Tak: I'm of the opinion that it's better to use something really intended for programmatic use.
<LarstiQ> Tak: but I do think it makes sense to list CM
<Tak> sure, but bzrlib's not really an option for me
<Tak> I would really prefer to use it
<tgunr> in fact i do!
<tgunr> is there a option to ignore the setting?
<LarstiQ> tgunr: unsetting it isn't feasible?
<tgunr> just awkward as I usually am working with my bzr server on another machine
<tgunr> what is odd is that I had eralier did a bzr get  lp:~pilky/bazaarx/pilky which worked fine
<LarstiQ> tgunr: if it used http:// instead of bzr+ssh://, that would make sense
<tgunr> i presume the lp: would use the http: protocol, if so, why did it fail on the svn and not the other?
<LarstiQ> svn?
<LarstiQ> tgunr: lp: is either http:// or bzr+ssh://, depending on wether you have set launchpad-login
<tgunr> yes, the call was lp:bzr-svn
<LarstiQ> tgunr: if you can get the correct bzr in the path on your server, you wouldn't need to specify BZR_REMOTE_PATH
<LarstiQ> tgunr: do you have write access to the one, but not the other?
<tgunr> I just installed it from the Mac OS X disk image and it puts it in /usr/local/bin
<LarstiQ> aha
<thumper> tak: file a bug :)
<thumper> poolie: ping
<poolie> hi thumper
<thumper> hi poolie
<poolie> abentley: hi, are you still here?
<thumper> I just sent you an email
<abentley> poolie: Yes.
<poolie> want a call?
#bzr 2008-11-21
<abentley> poolie: I'm up for a call.
<poolie> hi
<poolie> on skype or something, if you like?
<abentley> poolie: http://code.aaronbentley.com/bzr/bzrrepo/288751-pack-deltas
<jbalint> how do i handle "Contents conflict", the file has been renamed in the current tree
<thumper> how do I change the format of a branch from BranchFormat7 to BranchFormat6?
<jbalint> maybe bzr upgrade?
<spiv> jbalint: see "bzr help conflicts"
<spiv> jbalint: a contents conflict is when bzr sees conflicting changes to a non-text file.
<awilkins> Or the addition of a file with the same path
<jbalint> hrm, these shouldnt be nontext
<awilkins> In two seperate branches
<jbalint> one is .h, its the exact files taht are renamted
<spiv> awilkins: Hmm, "bzr help conflicts" suggests that would reported differently.
<spiv> Note that symlinks and directories count as non-text files...
<awilkins> I've never seen a "path" conflict, only content ones
<awilkins> And these are for ASCII text files
<awilkins> Maybe it's a windows thing?
<spiv> Maybe, I wouldn't know.
<kingfishr> what is the shortest sequence of commands to give me the equivalent of hg addremove?
<spiv> kingfishr: something like "bzr add; bzr commit" IIRC  (commit will automatically remove missing files by default, I think).
<kingfishr> oh really?
<kingfishr> that's convenient
<kingfishr> i wasn't aware of that
<spiv> I think --strict will disable that behaviour.  Try it out, it's easy to experiment :
<spiv> :)
<poolie> jam, are you still around? did you do a patch towards bug 300177, i don't remember
<ubottu> Launchpad bug 300177 in bzr "get_record_stream/ContentFactory should expose compression parents" [High,Confirmed] https://launchpad.net/bugs/300177
<synic> I want to write a clone of gitosis for bzr, I'm just wondering if anyone is already doing this (other than bzr_access)?
<james_w> I had heard tell that gitosis may support bzr
<james_w> or maybe I'm thinging of something else
<synic> hrmm, not in it's current state
<spiv> bzr_access is the closest I know if.
<spiv> s/if/of/
<synic> ok, cool
<vila> Gooood morning all
<spiv> vila: good morning.
<spiv> vila: you seem to be around early today :)
<vila> spiv: no, check your clock :)
<vila> kidding, I dropped my girlfriend to the airport :)
<army> hi ,i have a problem with bzr-svn,
<army> bzr 1.9 bzr-svn 0.4.15, check out http://www.prestashop.com/publicsvn ,error
<kisielk_home> As a new user to bazaar, I have a few question about repositories. In order to use an sftp:// repository, does bazaar actually have to be installed on the host?
<kisielk_home> or is it enough to have it just on the client?
<luks> kisielk_home: no, it doesn't have to be on the server
<luks> kisielk_home: only for bzr+ssh or bzr+http protocols
<kisielk_home> nice
<kisielk_home> yeah, I just want to keep some configuration files on my web server
<kisielk_home> and sync them to the machines I use
<kisielk_home> but it's shared hosting, so no bzr installed there
<luks> should work fine
<kisielk_home> cool
<vila> jam: When you'll come online, have a look at the last comment in bzrlib.tests.test_log.TestShowlog.test_simple_log :-/
<robsta> hi
<robsta> what's the best changelog script with bzr, prepare-ChangeLog.pl seems not to handle it
<robsta> jelmer: thanks for the fresh bzr-svn deb on the ppa, i can now clone my svn repo and `bzr check' works
<jelmer> robsta: n/p
<jelmer> robsta: what's prepare-ChangeLog.pl exactly, is it GNOME-specific?
<robsta> nothing, it doesn't do bzr at all
<robsta> (my version at least)
<jelmer> I think there was a plugin that could write GNU-like ChangeLog entries
<robsta> interesting
<robsta> i'm really only using the script to create commit messages
<jelmer> ah, it creates commit messages from the changelog rather than the other way around?
<jelmer> in that case, the plugin won't be of much use to you
<robsta> i run prepare-ChangeLog.pl, then paste it when committing
<robsta> the changelog is just a side-product of that
<asabil> robsta: you probably want to use moap instead of prepare-ChangeLog.pl
<asabil> I have a patched version of moap that produces the exact same output
<robsta> asabil: with function names?
<asabil> ah, no I don't think so :/
<robsta> :(
<robsta> seems like maintainer.py doesn't to bzr either
<asabil> well, I only used moap with Vala, so I don't know if it tries to extract function names for C code
<robsta> heck, how hard can it be to hack prepare-ChangeLog.pl ...
<Sadr> Bazaar is mainly designed for code, correct? But, could it be also used for, say, model/asset revisions tied up with a web-based GUI?
<Sadr> second try... any examples of Bazaar being used for *files* (e.g. a .blend or .max) ?
<Sadr> we're looking into maybe using Bazaar as an advanced file manager for our open source website
<jelmer> Sadr: hi
<jelmer> Sadr: The obvious problem with binary files is merging - bazaar does line-based merging
<jelmer> other than that, it should work fine
<Sadr> I see
<awilkins> Ok ; here's a talking point ; tags
<awilkins> All tags are replicated between branches on a push, pull, branch, even if they are on dead revisions
<awilkins> e.g.
<awilkins> bzr init one ; cd one ; echo one > one ; bzr add ; bzr commit -m "One ; bzr tag ONE ; bzr uncommit --force ; bzr commit -m "Two" ; bzr tag TWO ; cd .. ; bzr branch one two ; cd two ; bzr tags
<awilkins> Dang, missing a quote
<jelmer> awilkins: I think it's intentional to keep those
<awilkins> jelmer: But then you have a tag that marks a revision that potentially does not exist in the target branch / repo
<awilkins> jelmer: Dead revisions are not branched to the other branch, what's the sense in identifying them.
<awilkins> In my case, I then ran into tag conflicts with new revisions (the tags are being generated by a script for metadata purposes)
<Odd_Bloke> awilkins: 'bzr branch -rtag:dead-revision <original branch>'?
<awilkins> Odd_Bloke: 'spose... :-)    it does seem rather marginal
<Odd_Bloke> awilkins: Sure, but if the tag disappears, you don't know that you haven't got all of the revisions that were tagged.
<Odd_Bloke> And presumably the tag still existed for a reason.
<awilkins> I shouldn't run into it again, my script now overwrites the tags ; and people shouldn't push before they are sure they are not going to uncommit.
<awilkins> The tag exists to identify live revisions that represent places to do a fancy diff report
<jelmer> wow, has_revision() really profits from the 1.9 formats..
<vila> jam: ping
<derekS> hi all. just a quick question. what is the difference between committing to a local branch and pushing to a local folder?
<derekS> not used to this dvcs :)
<Odd_Bloke> derekS: You push commits.
<Odd_Bloke> You commit changes.
<Odd_Bloke> So push recreates your branch wherever you push to.
<Odd_Bloke> Your branch doesn't include anything that hasn't been committed.
<derekS> Odd_Bloke: so pushing a commit just merges it upstream?
<awilkins> derekS: pushing only works if no merge is required :-)
<Odd_Bloke> Nope, merging is a different concept.
<derekS> so, pushing just puts my branch upstream?
<derekS> so it copies my branch to the one i pushed to?
<Odd_Bloke> What do you mean by 'upstream'?  Pushing just puts your branch wherever you're pushing to.
<awilkins> pushing sends your revisions to the target branch, if it has no revisions that are children of the common ancestor you share
<derekS> hmm gotcha
<derekS> sorry, i am gjust trying to figure out how i can switch my svn to bzr
<derekS> the owrkflow part
<derekS> i use svn right now as a pseudo document management system :)
<derekS> for my personal files
<awilkins> Heh, I found it liberated me from the workflow of svn :)
<awilkins> No having-to-be-in-the-office or on-the-vpn
<awilkins> Started off with SVK and when that had a major oops, moved onto bazaar
<derekS> awilkins: yeah :) i like it
<derekS> just trying to create my workflow
<awilkins> That reminds me... I was going to have a crack at bzr-svn 0.5 on this monster repo to see how it does compared to 0.4
 * awilkins gets busy downloading stuff
<derekS> have fun!
<pickscrape> Is it possible to create a patch using bzr send which is against an earlier revision on the branch without having to bzr branch -r that revision out temporarily?
<pickscrape> e.g. I have a branch that I submitted at r50, and I commit 5 more changes (to r51) and want to submit those 5 changes as a new patch but not including the work up to r50.
<LeoNerd> Presumablly -r50..51 ?
<pickscrape> Doesn't defining a range like that create a cherry pick?
<LeoNerd> Yes. But that's what you're doing here
<pickscrape> OK, asking my colleague to try that. Thanks :)
<pickscrape> Related question, but when using a loom is there a simple way to say "send this thread" or does that also require looking at log and specifying the relevant revisions?
<jam> vila: pong, sorry about the delay
<vila> jam: np, just a quick chat about but #300055
<vila> jam: np, just a quick chat about bug #300055
<ubottu> Launchpad bug 300055 in bzr ""bzr log --forward FILE" crashes for revision range if first revision is not mainline" [Medium,In progress] https://launchpad.net/bugs/300055
<vila> gee ubottu, can't you see that I mixed up your nick and bug ?
<vila> jam: So, as said in the bug comments, I commited 2 fixes already, cleaned up the tests (finding a semi-bogus one on the way)
<vila> And I'm now to the point where I realized there are still problems lying around
<jam> well, making things better than they are now is worth merging
<jam> even if you don't have an absolute solution
<vila> That was my feeling but I wanted to discuss a bit to clarify my mind, I want to send the submission with some explanations to start the discussion
<vila> Roughly, we tend to enlarge the revision ranges to include the mainline revisions
<vila> I think this is motivated by two facts: 1) that made the programming easier (wrong reason :), 2) we display dotted revnos *after* the mainline revisions they are merge into
<vila> 2) does not play play well for several reasons
<vila> a) it makes the code *harder* as soon as the revision ranges are not "complete" (as including the mainline revision and all its merged revisions)
<synic> what is the equivalent of "bzr checkout" in bzrlib?  WorkingTree doesn't have a 'checkout' method
<vila> b) the display is ill-defined when the range is not complete
<jam> synic: Branch.create_checkout, IIRC, you can look in 'builtins.py' for the 'cmd_checkout' class
<synic> ok
<vila> The root cause being that reverse_by_depth works in one direction only and this went unnoticed until now, so many cases are not covered
<vila> err, scratch that
<jam> so let's start at the beginning
<vila> The root cause being that reverse_by_depth works in one direction only, this went unnoticed until now but it was used in several places ignoring that fact
<jam> "we tend to enlarge the revision ranges to include the mainline revisions"
<vila> ok
<jam> we want to go from a revision in the ancestry
<jam> and track where it was merged until we get down to mainline
<jam> merge-sorted revisions have this information easily available
<jam> reversed... not so much
<jam> I couldn't actually work out an obvious answer once they have been reversed.
<vila> I argue that we may not want to do that unconditionally
<jam> vila: perhaps, but for now it was chosen as the best trade off
<jam> between showing all cases where the change was merged into
<jam> and showing none
<jam> it is logically an optional thing
<jam> but to make it *actually* optional
<jam> requires updating the UI
<jam> and passing the parameters across the stack
<jam> which is generally non-trivial
<jam> It most certainly *can* be done. It wasn't worth my time
<jam> and I would argue it isn't worth your time *right now*
<jam> changing log so that it doesn't have to access as much ancestry would be a better thing to work on
<jam> and that may restructure the code anwyay
<jam> anyway
<vila> jam: sorry, phone, back in a few minutes
<vila> jam: back
<jam> np
<vila> Ok, I see your point. Yet, the case reported, starting at a dotted revno and fixed as of today allows to avoid showing a bunch of revisions (~50 or 100) so there is some motivation to handle it to respect user request
<vila> But, you're right, I may submit the actual fixes and just add a note that some more work may be needed, the fixes themselves provides a better solution but doesn't address all the cases either
<vila> Oh, re-reading your comments, I don't argue that we must not include the mainline revs, just that we don't have to include them if they are outside the requested range, i.e. at start/end only. But doing so raises some problems in the way we display them:
<vila> We can display hanging revisions (without their mainline) at start, but we can't to that at end, because there isn't a mainline rev to aggregate them there
<jam> vila: I don't quite see how you can get a revision that is in the ancestry that never ends up merged to a mainline revision
<jam> it... wouldn't be in your ancestry if that was the case
<vila> So doing 'log x.n.m..y.p.q' and 'log x.n.m..y.p.q --forward' can't display the same revisions
<vila> the revision *is* in the ancestry but the range *excludes* it
<jam> well, we only do the projection to mainline revs if you are logging a file
<vila> Look at lp:~/vila/bzr/300055-log-forward, bzrlib/tests/test_log.py TestGetViewRevisions.test_file_id_for_range for an example or try the reported case with my fix
<vila> in the reported case, the first required revision is 1616.70.54 which was merged in 1627
<vila> Yet, with my fix and --forward, we don't display 1627
<vila> but we display it *without* --forward
<vila> A bit hard to explain :-/
<jam> no, I understand what you mean
<jam> IMO being consistent would be nice
<jam> and I would probably go for "always show it"
<jam> because I think it would be easier
<vila> :-)
<vila> Right, now, we understand each other I think :-) Easier for the dev may not be what the user is wanting, but the user may want other things first ! Does that summarize the discussion ?
<jam> vila: yep
<jam> Getting a "correct if suboptimal" result for log
<jam> is the most important
<jam> and getting other stuff done is better than optimizing the rest of log
<vila> ok. I call it a day then (started a 6h30 this morning :)
<vila> have a nice week-end !
<LarstiQ> vila: you too!
<jam> you too vila
<jam> does anyone know if LP can handle 1.9 format branches yet?
<beuno> jam, IIRC, it only has up to 1.8
<beuno> actually, it's on 1.7.1rc1
<beuno> so... only if used through sftp maybe?
<beuno> I don't know how picky the smart server is about formats it doesn't know
<jam> I don't think it can mirror branches from sftp => http side if it doesn't understand them
<jam> and I don't think it can mirror a branch on my webserver if I upgraded it to 1.9 either
<beuno> right, the puller will probably b0rk
<jam> you would be able to *push* to bzr+ssh the first time
<jam> and then future access will likely give "Unknown Format" errors
<Peng_> Yeah, the puller can't mirror from 1.9 branches.
<Peng_> (on external web servers, I mean)
<jam> Perhaps if you used nosmart+bzr+ssh or some other crazy workaround like that
<jam> which I suppose isn't terrible considering if you were using 1.9 it would trigger the auto-stack from LP, and we know that is a little bit buggy right now
<jam> I'm trying to finish up Martin's fix and get it merged.
<beuno> oh, that would be great
<beuno> then we just push everyone to use nightly
<jam> well, I think Martin wants to make sure things are going smooth
<jam> and then have it all in 1.10rc1  which will be on Friday
<jam> (1 week)
<synic> how can I create a hook that only runs when a certain branch is pushed to?
<freewilly1> Client-side? Use post_push. For server-side, you'll have to use post_change_branch_tip
<freewilly1> I bet there's a way to check which branch is being operated on, but I don't know enough to answer that
<synic> ok, yeah, that's what I'm looking for is which branch it is
<synic> jam: ping
<jfroy|work> Anyone here has setup some manner of automated Subversion Bazaar mirroring solution?
<jfroy|work> Curious about people's experience, solutions, gotchas, and so on.
#bzr 2008-11-22
<alecwh> Hello, I'm trying to get bzr to work as an easy way to change my website (ex: bzr push will update my website homepage, if modified in the last commit). My branch is here: http://alecwh.com/test/. The problem: the .bzr directory (http://alecwh.com/test/.bzr/)exists, but none of the files (index.html) are. Also, the .bzr directory is "Forbidden", even though the permissions clearly allow the public to view the folder.
<alecwh> I am pushing to the website via FTP, and as far as I know, bzr support is not natively supported on my host.
<synic> alecwh: have a look at bzr help working-trees
<synic> it mentions a 'push-and-update' plugin
<Raht> let me ask, how does bazaar handles source downloads?
<Raht> as regular files or as diffs?
<AfC> "source downloads"?
<Raht> i mean checkouts or how it is called here...
<AfC> Are you asking what format is used when Bazaar streams revisions over the wire?
<Raht> yeah, putting it in those words works well
<alecwh> synic: thanks for your help, but unfortunately, SSH is not enabled on my hosting account. =(
<alecwh> Is there another solution?
<AfC> alecwh: you might try the "upload" plugin, https://launchpad.net/bzr-upload
<synic> who is Balint Aradi ?
<hiredman> is there some way I interact with a git repo using bzr?
<rey4> does anyone know where the original bazaar a.k.a baz can be downloaded?
<fullermd> rey4: http://bazaar-vcs.org/releases/src/obsolete/
<rey4> thanks!
<hiredman> is there a way to pull a single file from a bzr repo?
<fullermd> hiredman: Depends on what you're asking.  Do you mean something like `bzr cat`?
<Spaz> does bzr support partial checkouts yet?
 * Spaz hasn't been paying attention
<Spaz> basicaly what hiredman asked
<jelmer> Spaz, not yet
<Spaz> mmk
<_juri> i have an old tree i haven't touched in a while, can't recall exactly what version i was using the last time i touched it
<_juri> accessing it with 1.8 or 1.9 tells me 'Bazaar development format 1 (needs bzr.dev from before 1.6)\n'
<_juri> i tried 1.5, it tells me 'Bazaar Branch Format 7 (needs bzr 1.6)\n'
<_juri> 1.6.1 is willing to give it a go, but bzr upgrade fails (after "repository converted" message) with bzr: ERROR: Cannot convert to format <class 'bzrlib.branch.BzrBranchFormat6'>.  No converter
<_juri> i'm next going to give a go with 1.6 and after that a 1.6beta version, but if anyone can give any helpful suggestions they would be appreciated
<_juri> on a related note, it might be a good idea to have a link from the bazaar-vcs.org download page to https://launchpad.net/bzr/ for access to old versions
<_juri> 1.6 and 1.6b3 give the same error message about BzrBranchFormat6
<_juri> oh yay, 1.6.1 with bzr upgrade --1.6 seemed to work
<_juri> now let's see if 1.8 is happy with it
<_juri> well, wen't directly to 1.9, doesn't seem to complain
<luks> hm, dpush of multiple revisions does weird things
<leefmc> Question: Does bzr come with a server of some sort? I want to run a bzr server on a local box to keep my projects private for now, i assumed this is possible. But where is the server? I'm not seeing a specific server package in the ubuntu repositories
<beuno> leefmc, comes with a "smart server", which is just to optimize operations
<beuno> you don't really need something other then ftp/sftp/ssh
<leefmc> beuno: Well how would i set it up so i can push to my local server?
<beuno> leefmc, just make sure that bzr is installed on both ends, and that you have, say, ssh access
<beuno> and just do something like:  bzr push bzr+ssh://user@host/path/to/branch
<leefmc> beuno: Righto, thanks :)
<leefmc> beuno: That would explain why i was having trouble finding server information heh
<beuno> leefmc, heh, yeah. Although maybe our documentation isn't very clear either
<leefmc> beuno: Boy i hope the project lead chooses bzr/launchpad.
<beuno> leefmc, let us know if we can help with anything to tip it in our favour ;)
<leefmc> beuno: Its coming down to Merc/Bitbucket (i believe) and Bzr/Launchpad. Luckily launchpad made some headway given that the bug reporting is now pretty clean.
<leefmc> beuno: Well he was going with Google Code & SVN, but all the people who joined this project cried for a DVCS heh
<beuno> leefmc, this may be of interest: http://bazaar-vcs.org/BzrVsHg
<leefmc> beuno: Well although i will post that, a DVCS is all any of the programmers really care about (we all have our prefs, git/bzr/hg), but the project lead will most likely be choosing entirely on the host, Launchpad vs other. Initially he chose Google Code over launchpad because of the bug tracking, even though he himself dislikes SVN
<leefmc> beuno: Though i showed him they are nearly identical now, so i believe he was used to an older version of launchpad that required multiple bug reporting steps
<beuno> right
<beuno> you also have APIs for Launchpad now
<leefmc> beuno: That might be interesting aswell. Could it allow CMS' (and plugins for that CMS) to check for updates?
<beuno> absolutely
<beuno> https://help.launchpad.net/API
<leefmc> beuno: Also, are there any key ways for launchpad to show a good strong relation between projects? Ie, if we have a CMS, and have 50 plugins for that CMS each having their own project, it would be very nice to have a way for users to visit the root CMS project page, and somehow browse the plugins available for that CMS.. which would all be projects hosted on launchpad. Thats a big one aswell, and because of that were also looking at using
<leefmc> some custom software with hg repos
<beuno> leefmc, yeap, super-projects
<leefmc> (hope you got all that, some irc clients cut off paragraphs that big)
<leefmc> beuno: So google super-projects?
<LarstiQ> leefmc: it's usually the irc server that truncates messages
<beuno> (it got cut off ar: ...looking at using)
<beuno> leefmc, https://edge.launchpad.net/bazaar
<beuno> that's a super-project
<beuno> which has bzr, and all it's plugins as part of it
<leefmc> beuno: Ah, under "projects" correct?
<beuno> leefmc, rightr, although to create one, you need to request it via answers.launchpad.net/launchpad
<leefmc> beuno: Thats usually an easy process though right, we couldn't be "rejected" correct?
<beuno> leefmc, very easy, and you'll get it approved as long as it's open source
<leefmc> beuno: Ofcourse :), k thanks
<leefmc> beuno: Is there a documentation page to grab info about these super projects?
<beuno> and, if you run into any problems, you can always ping me, or ask in #launchpad, which is full of developers
<leefmc> yea
<beuno> leefmc, I can't find any docs on super-projects at the moment :/
<beuno> they're basically used to group projects
<beuno> although we do have plans to extend their funcionality
<beuno> functionality even
<markwaters> I've never used a rcs sytem before but after watching the ubuntu irc lessons recently though I'd have a look at bzr and want to ask a few beginner questions
<markwaters> I would like to use bzr to look after my remote /var/www directory
<markwaters> can I pull down a copy , work locally , commit and then push the updates back via ssh / sshfs ?
<markwaters> id also like to create a copy of the servers /etc directory and record changes in that too
<markwaters> so I can see server config file changes and be able to roll back from mistakes etc
<beuno> markwaters, is this for web development?
<beuno> if so, you have a plugin which may suit you better called bzr-upload
<beuno> which basically lets you work locally on your files, and use bzr-upload to just upload the files that have changed since the last upload
<markwaters> beuno: exactly , that's what I was wondering
<markwaters> thanks
<markwaters> so , if I had a web app , like say laconica , I could perform an 'upgrade' on my local code , then push the changed file up to the server after having a look at the changes
<markwaters> and any problems would allow me to roll back and push up the old version again
<beuno> yes, you can push specific revisions
<beuno> with the -r option
<markwaters> nice
<markwaters> this sounds cool
<markwaters> ok , and about monitoring /etc , not a problem either I gues
<markwaters> so long as I connect as the root user via sshfs to send or receive the changes
<beuno> well, you do have to commit to preserve the changes
<beuno> but yes
<markwaters> so its fine to have the files as me locally for the commit and then push them back as the root user
<markwaters> excellent
<beuno> :)
<markwaters> thanks beuno , I`ll leave you guys alone and start playing
<beuno> markwaters, good luck!
<leefmc> Question: I am trying to branch from a local server and am getting an "Server does not understand Bazaar network protocol 3, reconnecting." error. Now when searching for this.. im finding it comes up a lot, anyone got any ideas how to fix it so i can branch?
<leefmc> both my bzr should be the same versions, due to them both being from the ubuntu repo.
<LarstiQ> leefmc: it shouldn't prevent you from branching. But to get rid of the notice you could upgrade the version of bzr on the server.
<synic> it should work anyway
<LarstiQ> leefmc: are you sure about that?
<LarstiQ> leefmc: one other instance this could happen is if you have BZR_REMOTE_PATH set and it's content doesn't actually exist on the remote side, but it will yell at you for that
<leefmc> Hmm.. actually thinking about it, i spose they could be different. Im using Intrepid, and my server is on Hardy. Perhaps they have different versions on the repo?
<LarstiQ> yes, they do.
<leefmc> well crud heh
<leefmc> so i have to upgrade my server to use bzr?
<LarstiQ> that is, maybe I understood your question wrong.
<leefmc> LarstiQ: Well my question is, how do i make this work, without getting this error.
<LarstiQ> leefmc: as far as bzr is concerned, your server is already usable, it's only a warning notice but doesn't stop things from working.
<leefmc> LarstiQ: Ah, well its stopping me
<leefmc> LarstiQ: It continously asks me for the password.. perhaps thats the problem? Does bzr have some special password?
<LarstiQ> leefmc: do you mean it's not actually branching? If so, something else is wrong.
<leefmc> because i never set one for bzr haha, maybe its empty
<leefmc> *retries
<LarstiQ> leefmc: no, it's the password of the user you're trying to login as.
<leefmc> LarstiQ: Ok, well thats what i assumed
<LarstiQ> leefmc: and with it trying to reconnect, you will have to enter your password a second time.
<leefmc> then yes, something is wrong, it repeatedly asks me the password.
<LarstiQ> leefmc: if you want to upgrade bzr on hardy, you can use the bzr ppa.
<leefmc> LarstiQ: Well i think the most i tried was 4 times
<LarstiQ> leefmc: ok, that doesn't sound right.
<LarstiQ> leefmc: I presume you can login if you just ssh directly?
<leefmc> LarstiQ: and i doubt i can type it wrong the 12 times total i've tried it heh (with different variations on my workflow).
<leefmc> LarstiQ: Yup
<leefmc> LarstiQ: Never have trouble with that, logged in right now infact
<LarstiQ> leefmc: hah, don't be too sure, I had a horrible password at work that did that to me ;)
<LarstiQ> leefmc: ok
<LarstiQ> leefmc: does ~/.bzr.log provide any insight?
<leefmc> LarstiQ: On which system, the server, or the client
<LarstiQ> the client, but the server wouldn't hurt either.
<LarstiQ> leefmc: https://edge.launchpad.net/~bzr/+archive for the ppa btw
<leefmc> LarstiQ: Not really, lemme try somethin else
#bzr 2008-11-23
<Kobaz> how would i perminantly remove a file/dir
<Kobaz> and not just mark it deleted
<Byrnison> bzr rm --force
<Kobaz> k
<Kobaz> and then... anyone know any good email notification hooks
<Byrnison> I think. I just looked at the output of 'bzr rm --help' real quick.
<Kobaz> i've been using svnnotify for subversion
<Kobaz> Byrnison: i dunno about --force... i think --force will delete local files that aren't commited
<Kobaz> kinda like svn delete --force
<Byrnison> I haven't used Subversion for a while...
<Kobaz> i've read in some comparisons that bzr has a perm delete
<Kobaz> in other vcs's it's called obliterate
<Byrnison> I'm testing --force
<ia> hello, everybody. i have a question. if i want to create "trunk/branches"-model via bzr, i should run bzr init-repo my-repo, then create in my-repo directory trunk and branches directories manually and then run bzr add trunk branches, right?
<Byrnison> Yep.
<Byrnison> I think that is how, yes.
<Kobaz> k
<Kobaz> Byrnison: do you use any email hooks?
<Byrnison> ia: But... add --no-trees to the command line.
<Byrnison> No. I don't use Bazaar for anything complicated, or often at all, really.
<hiredman> ia: you could create a repo, and, infact, bzr branch it, to create branches
<Byrnison> I don't even really know how to use hooks.
<hiredman> just to toss that idea out there
<ia> well, then another question. from man page for bzr init-repo --no-trees and init repo/trunk said, that "create a shared repos holding _just_ branches". _just_ means that such repo couldn't be also working tree, right?
<Byrnison> That is the purpose of --no-trees.
<Byrnison> You could leave the option off if you wanted to use it like that.
<Byrnison> But --no-trees would be useful if you were sharing the repo between other people, or if it was on a shared server.
<ia> Byrnison, hiredman: thanks :-)
<Kobaz> beuno: poke
<mamatat> hi, i suddenly have this weird error when i run bzr status: http://pastebin.com/d1a77bd98
<mamatat> any ideas what's going on?
<Peng_> I wonder how you have a sys.version_info that isn't valid?
<Peng_> Hmm, bzr 1.9 handles invalid plugin version tuples better. I wonder if that applies to sys.version_info too?
<Peng_> No, it doesn't.
<mamatat> bzr version bugs too
<Peng_> mamatat: Out of curiosity, run this: python -c "import sys; print sys.version_info"
<mamatat> (2, 5, 2, 'alpha', 0)
<mamatat> 4th can't be 0 according to bzr code
<mamatat>     elif __release_type in ('alpha', 'beta') and __sub != 0:
<mamatat>         __sub_string = __release_type[0] + str(__sub)
<Peng_> Yeah, you're right. (2, 5, 2, 'alpha', 1) is handled fine.
<mamatat> argh
<Peng_> Ehh, according to the docstring, that's intentional. "alpha 0" releases aren't "reasonable".
<mamatat> yeah... figured out... it's explicitly forbiden by code... kinda makes sense but sucks that it happens now like that... it's not my server :(
<mamatat> switched back to good'ol 2.4 but still get the first half of the errors (until 32)
<Peng_> Yeah. I concentrated on the silly version formatting bug instead of the important part. Sorry. :P
<mamatat> hehe...
<Peng_> ISTM your working tree's state file got corrupted, but I'm not a developer. It could be some other sort of issue.
<Peng_> You should wait for someone who knows that code to answer.
<mamatat> hmm... thx for the help
<mamatat> i hope things don't get corrupted too often too badly :S
<Peng_> Like I said, I'm not sure. It could be a bug in the parser.
<Peng_> mamatat: Um..mind if I send a patch to change the _format_version_tuple thing?
<Peng_> (a (trivial) patch..)
<mamatat> well it seems like a good thing not to run alpha0
<Peng_> Heh.
<Peng_> 2.5 is a stable branch; I doubt there would be issues.
<mamatat> i'd rather file a ticket to hosting...
<mamatat> need to figure out other bug... will try creating other working tree... need to remember how :S
<Peng_> You could rename .bzr/checkout to something else and run "bzr co", but it might clobber changes you have in the working tree.
<Peng_> You could also just make another branch.
<mamatat> pff, now i get "bzr: ERROR: [Errno 5] Input/output error" on bzr status... not my day i guess
<mamatat> Peng_: you know where this error might come from?
<Peng_> Nope.
<mamatat> not a very debuggeur friendly error... :(
<LarstiQ> that sounds like a fs problem
<LarstiQ> mamatat: see ~/.bzr.log or try with -Derror
<mamatat> LarstiQ: http://pastebin.com/d18f1414f
<mamatat> 'bzr status' seems to be not working well at all here and corrupted the branch... all other commands seem to work fine
<Peng_> mamatat: Are you using a strange OS or file system? NFS?
<mamatat> nfs i think... it's a hosting server not mine
<mamatat> support says things work fine as long as bzr status is not used...
<Peng_> Oh. Well, that shouldn't cause corruption, but NFS does have issues with locking.
<Peng_> Hmm, isn't dirstate like the one case where bzr relies on OS locks, the very things that don't always work in NFS?
 * Peng_ shrugs.
<mamatat> i guess... apparently bugs have been filed to bzr about it and have been open for quite some time...
<mamatat> how do you tell bzr to finally ignore a file that has been version controlled in the past
<Peng_> mamatat: Stop versioning the file. ("bzr rm" or "bzr rm --keep" if you don't want to delete it.)
<mamatat> thx
<mamatat> hadn't thought of a 'rm --keep' command
<BUGabundo> hi
<BUGabundo> how do I restore just a file from an old revisionÂ»
<BUGabundo> ?
<james_w> "bzr revert -r rev filename"
<BUGabundo> thanks james
<BUGabundo> thanks james_w
<BUGabundo> thanks you so much
<BUGabundo> you are a life saver
<mamatat> hi, i'm thinking of using bzr to merge and sync online and offline db. i would need to have a bot deal with running bzr for the online server. does anyone have experience or comments about something like that?
<Peaker> why does bzr install a system tray icon in Ubuntu?
<Peaker> it has nothing interesting, just a whoami configuration dialog...
<mamatat> what's the easiest way to check from a script that everything has been commited (knowing that status crashes my branch)?
<Peaker> mamatat: status crashes??
<mamatat> yep :(
<mamatat> some bug with nfs
<Peaker> NFS sucks :-(
<Peaker> Maybe sshfs is better
<mamatat> well not my choice...
<Peaker> mamatat: surely you can use an alternative mount?
<mamatat> not sure... it's shared hosting... and not a big deal for status... but i do need to check things are commited
<Peaker> mamatat: what kind of crash do you get with status?
<mamatat> branch becomes broken
<Peng_> Peaker: Earlier he put a traceback up at http://pastebin.com/d1a77bd98
<Peng_> (he? she? it? anyway...)
<Peaker> arrg, someone didn't wrap a %x  with %(x,) !!
<Peaker> though that's the least of the problems
<Peaker> (still worth a fix in bzrlib/__init__.py, probably)
<Peng_> Oh, you're right. I didn't notice that one.
<Peng_> ...It's been fixed.
<Peaker> mamatat: probably best to solve the problem rather than the symptom
<mamatat> what's the pb?
<thumper> mamatat: bzr revno <remote branch>
<thumper> mamatat: isn't exact, but useful and fast
<thumper> mamatat: well, by exact, it doesn't tell you anything except the revno
<mamatat> lol, ok thx
<Peaker> mamatat: do you know Python?
<mamatat> Peaker: hmm, depends...
<mamatat> Peaker: won't get into bzr coding but am using it with django...
<Peaker> mamatat: I'd debug that traceback
<Peaker> mamatat: with pdb.pm() or such
<Peaker> xpdb, maybe (shameless plug)
<mamatat> i hear bugs have been filed about it...
<mamatat> long time ago apparently
<mamatat> https://bugs.launchpad.net/bzr/+bug/122106
<ubottu> Ubuntu bug 122106 in bzr "UserWarning: lock on ... .bzr/checkout/dirstate ... not released" [Medium,Confirmed]
<mamatat> https://bugs.launchpad.net/bzr/+bug/108605
<ubottu> Ubuntu bug 108605 in bzr "dirstate locks can fail on nfs" [Medium,Confirmed]
<Peaker> mamatat: hmm, how do you reproduce the bug?
<mamatat> i've tried to avoid doing that until now... :S might be everytime i run status but not sure
<mamatat> on my machine, status works fine... bug is only on server
<mwhudson_> is there a supported way to uninstall a hook?
<spiv> mwhudson: Hmm
<mwhudson> it sure doesn't look like it
<spiv> ISTR raising this on the list, and it being decided as a YAGNI so far...
<mwhudson> well i NI
<spiv> :)
<spiv> It doesn't seem hard to implement.  Basically it'd just do the equivalent of "Thing.hooks['pre_foo'].remove(callable)", plus removing the associated entry in _callable_names.
<mwhudson> right, currently my code does this "Branch.hooks['transform_fallback_location'] = []"
<luks> huh, "NoSuchFile: No such file: None"
<spiv> mwhudson: this is outside a test, I assume?
<mwhudson> spiv: yes
<spiv> luks: over hpss?  I think I may have fixed that bug
<spiv> mwhudson: interesting :)
<mwhudson> spiv: i want to do
<mwhudson> install_hook()
<mwhudson> try:
<mwhudson>    stuff
<mwhudson> finally:
<mwhudson>    uninstall_hook()
<luks> spiv: yes, I'll try to pull from bzr.dev
<spiv> That seems a bit weird, tbh.
<mwhudson> (i only need to do this to make tests pass, mind)
<spiv> Although having an unconditionally installed hook function that then looks at some (effectively) global state to decide what to do (if anything) is probably just as odd.
<mwhudson> spiv: right
<mwhudson> it's a bit of an odd hook, perhaps
<mwhudson> the problem i have is that i want to use this hook to detect stacking loops
<luks> spiv: thanks, current bzr.dev works
<spiv> luks: great
<spiv> luks: it was a bug introduced in 1.9 (#299254).
<mwhudson> so having it installed for a long time tends to result in spurious loop errors
<spiv> Well, I have no objection to adding an uninstall_name_hook or similar, and I see from the mail archives that jam agrees.
<spiv> (The thread had the subject "[MERGE] Extend -Dhpss to emit a count of HPSS calls to stderr" if you care, although not very much was said on that topic)
<mwhudson> spiv: is there a bug or patch or something
<mwhudson> ?
<spiv> None that I know of.
<spiv> Feel free to submit a bug or patch or both :)
<spiv> or something ;)
<mwhudson> does a post it stuck to my monitor count?
<spiv> If it results in a bug or patch, sure :
<spiv> :)
#bzr 2009-11-16
 * lifeless watches the dustweeds
<lifeless> spiv: bug 457952
<ubottu> Launchpad bug 457952 in bzr "pqm does not use subunit because bzr selftest --subunit reports errors" [Medium,Confirmed] https://launchpad.net/bugs/457952
<spiv> lifeless: what about it?  I guess the question is "what precisely should the 'check' target do?", and then just land that.
<lifeless> spiv: I proposed an idiom earlier in the bug report
<spiv> lifeless: feel like proposing an actual patch? :)
<lifeless> I think something like tee test.log && subunit-stats < test.log
<lifeless> spiv: or subunit-filter --no-skip < test.log | subunit2pyunit
<spiv> lifeless: sure, the idea sounds fine.  But it seems to me that you're the best person to decide on the details.
<lifeless> spiv: I'll add it to my queue
<lifeless> spiv: possibly in the weekend
<lifeless> spiv: I may be the best person; I don't think it needs the best person.
<spiv> Well, partly I'm a bit hesistant because last time I turned on subunit things broke.  But that change was also simpler... and I haven't got all the various subunit-* utils paged in, so discovering the options for achieving this and evaluating them is not trivial effort.  If you propose a patch I can pilot it though ;)
<lifeless> its not really on my radar workwise
<lifeless> spiv: I guess what I'm thinking is that : it will help folk landing stuff; having at least one other person happy with the tool chain is important :)
<stewart> hi! i'm having issues with a plugin I wrote. it's trying to commit.run with author= as a parameter, but i'm getting "author: s, t, e, w" etc instead of "author: stewart@"  any clues?
<stewart> running bzr 2.0.2
<stewart> (this used to work okay)
<spiv> stewart: a commit can have multiple authors
<spiv> stewart: so IIRC you need to pass a list of author strings, not just a single author string.
<stewart> ahh...
<stewart> let's try that
<spiv> That feature was added in 1.13 according to the news file.
<stewart> subtle API change :)
<spiv> Yeah.  It would have been nicer I guess if the API had renamed that param.
<spiv> And also calling it 'authors' would be clearer, really, but I think that's a limitation of our command-line processing infrastructure.
<stewart> as i don't think i'm that important that each character in my email address should be listed :)
<stewart> i should actually rip this plugin out of the internal mysql tree and just publish it.... was the original intention.
<spiv> Probably ListOption should grow a feature where the name of the --option does not have to precisely match the param in the API, because the CLI will have a singular word (possibly repeated), but the API ideally would have a plural.
<RenatoSilva> verterok: hi
 * fullermd slaps lying 'merge' around.
<fullermd> Is it actually expected that merge bleats about being unable to find a common ancestor when there are two of 'em?
<lifeless> fullermd: thats a criss cross
<lifeless> and it recurses deeper in that case
<fullermd> Well, no, it just dies.
<lifeless> fullermd: you may have a special case.
<lifeless> bug filed?
<fullermd> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<lifeless> theres no sign of two common ancestors there
<fullermd> Well, I know.  But there are two.
<fullermd> bug 483388
<ubottu> Launchpad bug 483388 in bzr "merge lies about lacking common ancestors when it has multiple choices" [Undecided,New] https://launchpad.net/bugs/483388
<fullermd> (adding an explicit merge type doesn't change anything; I conjecture that it blows up before it gets to anything merge-type varies)
<RenatoSilva> verterok: hope you read this later, I've got the new update site, but it works only if extracted. Some users like me get confused because update sites usually work as a zip. But anyway, I've extracted it and got bzr-eclipse installed without errors
<RenatoSilva> verterok: however, when I try to get a lp branch as new project, it's not working if I put a non-ascii path :(
<RenatoSilva> verterok: org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: <class 'xml.parsers.expat.ExpatError'>:not well-formed (invalid token): line 1, column 302
<RenatoSilva> verterok: iirc that error is related to xmloutput
<verterok> RenatoSilva: Hi
<RenatoSilva> verterok: hi
<verterok> RenatoSilva: yes, there is a bug with the bundled xmloutput in windows :/
<verterok> RenatoSilva: I'm working on a fix ATM
<RenatoSilva> verterok: ok let me know if I'm still here, so that I can test it
<verterok> RenatoSilva: ok, probably I'll finish it by tomorrow, I need to sleep a few hours before go to work ;)
<RenatoSilva> verterok: ah ok :)
<RenatoSilva> verterok: just to note: I think there are remaining encoding problems in xmloutput
<verterok> RenatoSilva: oh, that's bad :(
<RenatoSilva> verterok: do you remember a bug when I said about 2 approaches about the XML Header? Always declare and  UTF-8 vs. detect system encoding?
<verterok> RenatoSilva: yes
<RenatoSilva> verterok: I've noted that your fixes to the encoding problems I've reported tend to go to detecting, but as I said, we must be careful about valid entries. For example, we can't get <?xml... encoding="cp850"?> because cp850 is an invalid entry for an XML document.
<RenatoSilva> verterok: besides, I wonder if the fixes you've committed are adding more issues. In a nutshell: we need to take a better look at xmloutput. Feel free to ask me for testing :)
<verterok> RenatoSilva: regarding, bzr-eclipse, in the preference page, try adding the path to the bzr plugins directory to the plugins path , e.g: in my winxp vm, it's: C:\Documents and Settings\guillermo\Datos de programa\bazaar\2.0\plugins
 * RenatoSilva checks his xmloutput bugs
<verterok> RenatoSilva: and click the Recheck button after setting it :)
<RenatoSilva> verterok: but the bundled xmloutput is the same as trunk
<RenatoSilva> verterok: or is it for something else?
<verterok> RenatoSilva: yes, but there is a bug in bzr-eclipse, the code that builds the BZR_PLUGIN_PATH value is broken for windows paths
<verterok> RenatoSilva: it's trunk
<RenatoSilva> ok but why does it need to be aware of that path?
<verterok> RenatoSilva: to override the path of the bundled xmloutput...I didn't testted :/
<verterok> RenatoSilva: looks like adding the path to plugins dir works, at least in my spanish win xp :)
<RenatoSilva> override the path?
<verterok> RenatoSilva: in the bazaar preference page, there is an option to add plugins path
<verterok> RenatoSilva: bzr-eclipse trunk, don't handle windows paths ok, and so the BZR_PLUGIN_PATH used contains a wrong path.
<verterok> RenatoSilva: in order to use trunk build, you need to add the plugins path manually
<RenatoSilva> verterok: ok but I mean, why does bzr-eclipse need to know that plugins path? to override the bundled's? but what's that?
<verterok> RenatoSilva: bzr-eclipse trunk, bundle xmloutput so users don't have to install it...basically to simplify the install process
<Peng> What's the right way to make push default to --no-strict? An alias?
<verterok> RenatoSilva: but to do that, it need to set BZR_PLUGINS_PATH when it launchs the xmlrpc service
<verterok> Peng: probably that's the way to go :)
 * RenatoSilva installing bzr-eclipse again
<verterok> RenatoSilva: or you can wait until tomorrow night, for the new build ;)
<RenatoSilva> verterok: you said I could set the path manually, do you think it may be cause of the parse error I mentioned above?
<Peng> verterok: Eh, ok
<verterok> RenatoSilva: don't know :/
<RenatoSilva> verterok: ok will test now
<verterok> RenatoSilva: that error is the same we were getting in hudson a few days ago...
<RenatoSilva> verterok: I remember that error as being something regarding encoding for sure
<poolie1> spiv, how did the pilotage go?
<RenatoSilva> verterok: there's no executable set, can't get how it was finding it...
<verterok> RenatoSilva: it will look for it in PATH
<RenatoSilva> ah ok, just added bzr's plugin path, will test
<RenatoSilva> verterok: bah, same error, even setting the path manually :(
<verterok> RenatoSilva: :(
<RenatoSilva> verterok: org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: <class 'xml.parsers.expat.ExpatError'>:not well-formed (invalid token): line 1, column 302
<RenatoSilva> verterok: would be easy to find out what's happening if I debug, but I'm afraing not getting the source code debug working
<RenatoSilva> afraid
<verterok> RenatoSilva: bzr-eclipse code?
<verterok> RenatoSilva: it should bo ok now, I updated all deps in the pom(s).xml
<RenatoSilva> verterok: yes, and we'd need bzr-java-lib too...
<verterok> *be
<spiv> poolie1: it's going pretty well, although it's a bit tedious figuring out who has signed the contributor agreement
<poolie1> there's an lp team for it?
<poolie1> i think?
<RenatoSilva> verterok: but bzr-eclipse does not come configured to work with the source code of bzr-java-lib
<spiv> There is, but a) I'm not confident it's up to date, and b) I don't see any way to go from a team page to a complete list of members.
<verterok> RenatoSilva: yes, it will pull bzr-java-lib from the maven repository
<spiv> Or rather, I see a way that *should* do that, but doesn't.
<spiv> You can go backwards, from the lp user check their team memberships.
<RenatoSilva> verterok: if the problem is not with xmloutput, it is with bzr-java-lib likely, so I will need the source of that too
<verterok> RenatoSilva: oh, ok
<RenatoSilva> verterok: I've got it working before, let me try again (feaaaar)
<verterok> RenatoSilva: /me needs to get some sleep :)
<RAOF> Hm.  How can I tell if a bzr-git dpush is actually going to finish or not (halting problem notwithstanding)?  This one seems to have pushed ~400MiB of data, which is substantially larger than the repository.
<RenatoSilva> verterok: ok see you, thanks
<verterok> RenatoSilva: np, thank you :-)
<verterok> seey'a later!
<RenatoSilva> Is there any issues related to running two bzr.exe instances at the same time?
<RenatoSilva> I suspect I have one or more
<poolie1> spiv: seriously? that seems like quite a gap
<RAOF> Oooh.  2GB ram & 600MiB upload later it seems that dpus is almost done :)
<poolie1> spiv, in theory one can write a bot that marks mp depending on whether the contributor is a member of the team or not
<spiv> poolie1: yeah, just filing a bug on that now.  There's an "All members" link, but it leads to disappointment rather than the information I seek.
<poolie1> https://edge.launchpad.net/~contributor-agreement-canonical/+members#active
<poolie1> oh because it doesn't expand ubuntuone-hackers?
<poolie1> it's safe to assume they're all staff
<spiv> poolie1: that page says "54 people are members in total", then only lists 9 people
<fullermd> "New bug filed: Plz delink disappointment"
<spiv> Hmm, I'm not sure if that's a correct assumption.
<spiv> Anyway, I think that means that page isn't complete, given that there are many more on the internal wiki page.
<poolie1> i still think it's a bug
<poolie1> that's true too
<poolie1> we should pull them across
<poolie1> can i suggest you mention this in a mail about the pilot project sometime
<poolie1> hm
<poolie1> actually it might just be flamebait
<poolie1> we probably should reconcile that team with the other list/s though
<spiv> Yes, a single canonical (hah!) list would be nice.
<poolie1> if only there was a massive sql db guaranteed to have the precisely correct schema and data
<fullermd> You can just use the web as one.  First, you become Google...
<spiv> That's just begging for another joke about the word "canonical" :P
<poolie1> we only give you $5 for lunch? that doesn't go far...
<spiv> poolie1: for breakfast
<lifeless> hmm, I need to do expenses too
<lifeless> we did what, three group meals? mon, wed, friday
<poolie1> and also thursday, without you
<lifeless> yes :)
<bialix> Hi GaryvdM
<maxb> Where is the correct place to discuss a compatibility-breaking UI change? Namely, I would like to propose dropping the 'bzr rebase --always-rebase-merges' option and making its behaviour the default
<balor> Is there a nice linux GUI tool for resolving conflicts?
<bob2> meld
<bob2> if you use emacs, smerge-ediff is very nice, too
<bob2> (aside from the ridiculous colours)
<balor> bob2, How does meld help? do I diff3 the BASE OTHER and THIS files?
<gioele> balor: yes, also try kdiff3
<balor> gioele, Thanks.  Meld worked brilliantly well.
<balor> meld foo.c.BASE foo.c.OTHER foo.c.THIS, make them all agree then cp foo.c.BASE foo.c, bzr ci
<gioele> balor: no "bzr resolve"?
<Peng> "bzr resolved" is for telling bzr that the conflicts have been resolved, not for actively resolving them (unlike hg, which always bites me).
<gioele> Peng: yes, but I thought that you needed "bzr resolve" before "bzr commit"
<Peng> Oh oh, that's what you meant. Yes, you're correct.
<Peng> Sorry I misunderstood.
<gioele> spiv: (pilot) could you help me with <https://code.launchpad.net/~gioele/bzr/forgot-commit-message>? Is there something missing or wrong?
<RenatoSilva> what is .bzr\checkout\lock\releasing.ed3xwzvx48mik4q2lqhl.tmp?
<RenatoSilva> and .bzr\checkout\lock\held?
<RenatoSilva> and how access denied errors are related to such files?
<bialix> RenatoSilva: break-lock is your friend
<RenatoSilva> sorry?
<RenatoSilva> bialix: this is happening in unit tests, *randomly*
<bialix> RenatoSilva: windows?
<RenatoSilva> procmon is my friend and gives the this info about the error: Path "C:\Documents and Settings\Renato\ConfiguraÃ§Ãµes locais\Temp\bazaar_client_tests8941769694356864996\working_copies\localBranch\original\.bzr\checkout\lock\held"
<RenatoSilva> Detail "ReplaceIfExists: False, FileName: C:\Documents and Settings\Renato\ConfiguraÃ§Ãµes locais\Temp\bazaar_client_tests8941769694356864996\working_copies\localBranch\original\.bzr\checkout\lock\releasing.rcgp0djgibyborcys2tx.tmp"
<RenatoSilva> * gives me, and yes WinXP SP3 updated
<bialix> I'd suggest to using shorter path for temp directory
<RenatoSilva> I don't know what ReplaceIfExists and the related FileName means though
<bialix> something like C:\TMP
<RenatoSilva> Already tried
<RenatoSilva> I probably tried anything that you can imagine :P
<bialix> this is test for smart server? or dumb server perhaps
<RenatoSilva> sorry?
<bialix> I'd say this is race condition
<bialix> RenatoSilva: bazaar_client_tests
<bialix> the name of this tests suggest me that some sort of server is tested
<bialix> perhaps some code runs in thread
<RenatoSilva> what's that I'm sorry? The test errors are with bzr-java-lib project, only in my Windows XP
<bialix> therefore race condtion
<bialix> so what?
<bialix> .bzr\checkout\lock is lock
<bialix> if you have file with lock info still opened/read by one process you can't delete it by other
<RenatoSilva> a dir right? and releasing.*.tmp?
<bialix> RenatoSilva: there is file inside, named info
<bialix> text file with info about lock
<bialix> *.tmp is fancy_rename trick
<bialix> see bzrlib/osutils.py fancy_rename
 * RenatoSilva has no idea on what could be causing this problem, he's into this since days
<Peng> Something that doesn't release locks, perhaps?
<bialix> if you say it's random failures then I'd say it's either path length limit or race condition
<bialix> or you have aggressive anti-virus
<RenatoSilva> bzr-java-lib uses an XML-RPC server started with "bzr start-xmlrpc", then it sends commands to the server and reads the response. The tests work the same way
<bialix> so you have 2 concurrent processes. race condition?
<RenatoSilva> I'm currently running one specific test in Eclipse, and I'm catching the above error in procmon, it seems unreleased lock but has no sense (why? how? when? who? etc)
<bialix> perhaps raised error
<bialix> logs are you friends
<RenatoSilva> bialix: I don't understand how my anti-virus would be causing this without notifying anything....
<RenatoSilva> bialix: besides I tried disabling it...
<bialix> anti-virus monitor can start reading/checking new files therefore effectively blocking file deletion
<RenatoSilva> bialix: 2 processes? why? what processes?
<bialix> XML-RPC server = 1st process, client = 2nd process, right&
<bialix> XML-RPC server = 1st process, client = 2nd process, right?
<RenatoSilva> bialix: but if I disabled the monitor for a while, it would stop monitoring and therefore stop blocking, however shutting down the anti-virus didn't work :(
<bialix> that's bad if it won't help
<RenatoSilva> bialix: client does not access the temp repo afaik, it only sends commands to xml-rpc server and handles response
<bialix> do you have some pastebin to show?
<RenatoSilva> I don't know if it serves as a clue, but during the test, procmon reports 3 executions of bzr.exe with different command lines, let me see
<RenatoSilva> bialix: I can give you may pastebins, you just have to choose of what exactly :D
<bialix> I have no idea about your code
<bialix> why you need to run bzr.exe 3 times?
<RenatoSilva> I'm just an user/contributor
 * bialix is not user even
<bialix> RenatoSilva: sometimes tests written in linux way, so it's hard to understand what's wrong
 * bialix don't understand Java either
<RenatoSilva> bialix: I don't --need-- 3 times, I've --found-- it
<bialix> so maybe this is error?
<bialix> sometimes one strange error masked actual error
<RenatoSilva> I wonder if for any reason and somehow another bzr.exe tries to do something in the same branch
<RenatoSilva> The question is why it was working perfectly a few days ago....
<bialix> oh, my favorite question
<RenatoSilva> anything that I've done of different I tried to revert back
<RenatoSilva> I reverted windows back to a previous state, before insatlling AVG9 (over 8.5) and updating windows
<RenatoSilva> I had problems with that, but after fixing them, I've got it wroking
<RenatoSilva> then while I was here talking to verterok a thsi week, it stopped working again
<RenatoSilva> the only thing I could figure out have done different was that I cancelled mvn test in cmd line, and that verterok pushed a new lib version to repo that was dowloaded
<RenatoSilva> So I tried to change permisssions of mvn, c:/program files, ~, etc....
<RenatoSilva> tried to reinstall bzr and mvn, tried many things...and nothing....
<RenatoSilva> I even installed recent windows updates one by one, like one of them was causing this, but no
<RenatoSilva> Therefore, I don't even know what action caused this starting to happen
<bialix> sorry, it seems I can't help here
<RenatoSilva> I'm looking for someone with mvn + winxp sp3 updated [+ avg9] to try at least reproduce the problem
<RenatoSilva> is bzr.exe.Local a bzr stuff?
<bialix> bzr.exe.Local? no
<RenatoSilva> bialix: there are mainly 2 kind of errors that randomly happen, first one is access denied about the lock
<RenatoSilva> bialix: not sure but seconde one seems to happen when first one passes
<RenatoSilva> bialix: 2nd is  unknown command "C:\Arquivos de programas\Bazaar\bzr.exe"
<RenatoSilva> which is absolutely non-sense, the file exists
<bialix> do you have this file?
<RenatoSilva> it's bzr!
<bialix> yes, I see it's bzr
<bialix> if this string process be something like shlex.split you'll have a problem
<bialix> much better if there will be forward slashes using
<RenatoSilva> I mean, it's the one that works all the time, and exists all the time, it can't say it's unkonw (and worse, tell that *sometimes*)
<RenatoSilva> about the bzr.exe count, don't know the right order but they are "bzr xmlversion --short", "bzr xmlplugins", and "bzr start-xmlrpc"
<RenatoSilva> verterok: ^^^ does this give you any clue?
<RenatoSilva> god, fatal error in procmon itself o.O
<verterok> RenatoSilva: hi
<RenatoSilva> verterok: hi, good morning :)
<verterok> RenatoSilva: bzr-java-lib need to check the if xmloutput is installed and the version, and after that it starts the xmlrpc service
<RenatoSilva> verterok: I've sent you a few emails
<verterok> RenatoSilva: yes, reading them ATM :)
<verterok> RenatoSilva: I just finished a deploy of bzr-java-lib snapshot to the maven repository, the snapshot num. is: bzr-java-lib-0.5.3-20091116.142139-1
<verterok> RenatoSilva: actually, the connection timedout..hang on :)
<RenatoSilva> verterok: man, 0.5.3 is in sync with the code? I don't understand how can bzr-eclipse bundle not work, but when you get the source code, it does
<RenatoSilva> verterok: I mentioned this file in email:  http://verterok.com.ar/maven-repo/org/vcs/bazaar/client/bzr-java-lib/0.5.3-SNAPSHOT/bzr-java-lib-0.5.3-SNAPSHOT-sources.jar,
<verterok> RenatoSilva: probably because of how it's started when executed from inside eclipse
<verterok> RenatoSilva: hmm, that file shouldn't exists in the repository...
<RenatoSilva> verterok: that file is not the latest code, and its related binary is expected to not be either
<verterok> RenatoSilva: I'll delete all -SNAPSHOTs files
<RenatoSilva> verterok: so you mean these source jars are not generated by the same process than the one for the binary version?
<verterok> RenatoSilva: maven deployed snapshots use a timestamp
<verterok> RenatoSilva: yes, but I missed the source generation (an extra parameter to mvn :/)
<verterok> RenatoSilva: remvoe all -SNAPSHOT from your local maven repo and run 'mvn compile' in bzr-eclipse again :)
<RenatoSilva> verterok: about the xml enc detection, cat is not done through xmlrpc, right? but there's no detection involved right, because it's not xml...
<verterok> RenatoSilva: right, there is no xml
<RenatoSilva> verterok: source code is working, I don't use bzr-java-lib jars in it
<RenatoSilva> verterok: ok so I think for cat we'll have no problem, need to check just if there's any xmloutput command that is not run with XMLRPCCommandRunner
<verterok> RenatoSilva: xmlplugins & xmlversion for sure
<RenatoSilva> hmmm ok...
<verterok> RenatoSilva: is the xmloutput plugin installed in a path with non-ascii name?
<verterok> RenatoSilva: or bzr itself?
<RenatoSilva> no
<RenatoSilva> just spaces
<verterok> RenatoSilva: run xmlversion in a cmd.exe, probably the log file is in your user dir
<verterok> RenatoSilva: is there any non-ascii path?
<RenatoSilva> verterok: bzr log seems ok, no error
<RenatoSilva> verterok: non-ascii path where? you're talking about which email specifically? :)
<RenatoSilva> oh xmlversion? let me see
<verterok> RenatoSilva: no email :) the output of xmlversion
<RenatoSilva> humm no, it is ascii-only
<verterok> RenatoSilva: and xmlplugins?
<RenatoSilva> the output is bigger, not sure how to check it, looking....
<RenatoSilva> seems ascii-only too
<aguafuertes> Hi, is somebody here who has 5 minutes to explain some Bazaar concepts that I could not figure out by reading the documentation?
<RenatoSilva> maybe
<aguafuertes> :) great
<RenatoSilva> I said maybe :)
<aguafuertes> ;)
<aguafuertes> I try to set up a branch that I want to work an with one colleguae
<aguafuertes> we are a Windows environment, I'm the only Ubuntu user
<aguafuertes> I installed an ssh server on my machine
<aguafuertes> my colleague tries to branch my work, but always receives the error "bzr: ERROR: Not a branch:"
<aguafuertes> interestingly, when branching directly in the file system, everything works fine
<Peng> Your colleague has SSH access to your machine?
<aguafuertes> yes, I set up an extra user for him
<aguafuertes> interestingly, I can branch via the file system without problrm
<Peng> Huh. Um. Note that bzr+ssh:// paths are relative to the root, not the user's home directory (though you can use ~ for that on recent versions. Probably.)
<aguafuertes> mm, ok, that is a good hint
 * Peng goes /away again
<aguafuertes> I'll try that first
<aguafuertes> Peng, thanks so much!
<aguafuertes> that was it :)
<Peng> Really? It was? I'm surprised. Well, I'm glad it's fixed. :)
<aguafuertes> yes, I simply assumed that the it would be relative to the ssh user's login
<aguafuertes> is that somewhere in the documentation?
<aguafuertes> if not, maybe it can be added for people like me, coming from a web developer background
<aguafuertes> were we deal more with document roots ;)
<mgedmin> bzr 2.0.2 (karmic ppa) burns and crashes (TooManyConcurrentRequests) if I try to bzr pull over ssh from a server running bzr 1.13
<Peng> TooManyConcurrentRequests: The most useless error message ever, aside from "Segmentation fault".
<mgedmin> nah, segfault is very informative
<mgedmin> TMCR is ... interesting
<mgedmin> hm, maybe this is because I'm using a checkout
<Peng> You're trying to "bzr pull" inside a checkout? Don't do that. Use "update".
<Peng> Although it obviously shouldn't fail with such an error...
<Peng> File a bug?
<mgedmin> I don't want to update
<mgedmin> I'm pulling from a different branch, not the one I'm bound to
<mgedmin> bug filed here: https://bugs.launchpad.net/bzr/+bug/483661
<ubottu> Launchpad bug 483661 in bzr "bzr pull bzr+ssh fails with TooManyConcurrentRequests" [Undecided,New]
<mgedmin> "don't do that" sounds like something to suggest to people who say "I'm trying to use bazaar"
<LarstiQ_> Peng: hmm, it's valid if you want to pull into the branch you're bound to
<mgedmin> fwiw bzr pull over http worked fine
<mgedmin> I wonder if pull over ssh would work if the two branches lived on different hosts
<mgedmin> hm, bzr pull over ssh works now that there are no changes to pull
<mgedmin> lemme update the bug
<mgedmin> anyway, found a workaround (pull over http), got ideas for other workarounds (bzr unbind; bzr pull; bzr push; bzr bind), hope you get the bug fixed sooner or later
<mgedmin> cheers!
<jam> is there a losa about that can create a bzr-2.1 branch for me?
<mthaddon> jam: sure
<jam> basically, just "bzr branch lp:~bzr-pqm/bzr/bzr.dev lp:~bzr-pqm/bzr/2.1" should be sufficient.
<jam> thanks mthaddon
<mthaddon> jam: is there an RT for this, or could you give me a quick run down on why it's needed?
<jam> and, of course, setting up pqm to allow access to that (if anything needs to be done there)
<jam> mthaddon: No rt (yet), needed because I'll be releasing 2.1.0b3 ~ today
<jam> I'm going to try to use a 2.1 branch rather than 2.1.0b3 so that we don't have to pester you every month
<mthaddon> jam: ok, should be good to go
<jam> mthaddon: thanks. I did end up sending an RT request
<jam> #36509
<jam> if you want to tick off that you already finished it
<mthaddon> thx
<maxb> Is there a shortcut way to deal with merge conflicts where both sides added the same file with the same text content independently?
<jelmer_> maxb: not really, the two files will have different file ids
<jelmer_> and there is no way to join file ids
<maxb> ok.... I was hoping for a "bzr resolve --obvious" :-)
<vila> maxb: bzr resolve <file> should do it
 * Tak bzr resolve --duh
<maxb> How do I ask bzr to show me the log of a file according to the merge-source branch?
<dOxxx> maxb: have you tried using kdiff3 as an external merge tool?
 * maxb tries installing
<maxb> bzr log a-filename -r branch:../../the-merge-source  makes bzr crash :-/
<dOxxx> maxb: make sure you have the extmerge plugin for bzr installed if you want to use kdiff3
<dOxxx> maxb: try bzr log -n1 filename ?
<maxb> bzr: ERROR: Path unknown at end or start of revision range: debian/patches/svn2cl-upstream
<dOxxx> hmm that one's out of my league :)
<dOxxx> maybe try bzr log filename --include-merges
<maxb> Sorry, this is an uncommitted merge in progress
<dOxxx> oh...
<bialix> bzr qlog shows pending merges
<dOxxx> I suspect there isn't really an easy way to do it other than constructing a URL to the file using the merge-source URL
<dOxxx> I stand corrected.
 * maxb tries that
<maxb> also, what do I do when bzr erroneously decides a file is binary?
<bialix> maxb: there is opposite problem
<bialix> maxb: do you still compare bzr and hg?
<maxb> Yes. We are currently doing "should we switch from svn and if so what?" at work
<bialix> any results so far?
<Meths> maxb: Is your choice between anything other than git, hg and bzr?
<maxb> Well, I seem to be the only person with truly strong opinions, so I'm driving the whole thing
<bialix> maxb: many people likes bzr-svn plugin to work directly with svn and to soften the transition
<maxb> Meths: Not really - we acknowledge that other things exist, but we don't really have any knowledge of others in house, so it's tricky to evaluate anything else without a lot of effort
<maxb> bialix: Sadly, bzr-svn gets really very slow when all your company's code resides in a single svn repository
<maxb> Meths: Why, is there something else that we should keep on the table? :-)
<bialix> understand
<Meths> maxb: NAFAIK.  They seem to be the only sensible options going forward, similar command sets, private sector supporters, Internet project space...
<jam> bialix, garyvdm: Hey guys, I'm getting ready to put together 2.1.0b3 and wanted to know what qbzr version to bundle
<jam> mthaddon: I just tried to submit to 2.1.0 and it tells me I'm not authorized to commit to that branch
<jam> it is http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1.0 right?
<dOxxx> looks like it's 2.1, not 2.1.0 ?
<dOxxx> jam: bzr branch lp:bzr/2.1 works for me
<jam> dOxxx: looks like you're right
<jam> good enough I guess
<jam> Probably the right thing anyway
<jam> though I wish PQM's messages were better
<jam> (not allowed to commit, versus branch doesn't exist)
<dOxxx> I'm going by the Series 2.1 page on LP
<dOxxx> it lists lp:bzr/2.1 as the branch
<jam> dOxxx: yeah, and *I* just updated that :)
<jam> just didn't notice the .0
<jam> or lack thereof
<jam> dOxxx: thanks for the pointer, it seems to be going now: http://pqm.bazaar-vcs.org/
<dOxxx> cool :) I'm looking forward to being able to install 2.1.0b3 here so I can get the proxy fixes.
<jam> dOxxx: well, those are also in 2.1.0b2 I believe
<jam> and you only *need* 2.1.0b3 if you are running python2.4
<dOxxx> jam: were there windows installers built for 2.1.0b2?
<jam> yep
<jam> not announced, but they are available
<dOxxx> oh! I never saw them announced anywhere.
<dOxxx> Where can I find them?
<jam> I thought I would have 2.1.0b3 last Monday
<jam> https://launchpad.net/bzr/2.1/2.1.0b2
<jam> should have them
<jam> though 2.1.0b3 will be out in the next day or two
<dOxxx> I don't mind reinstalling ;)
<KhaZ> Sorry if this is a basic question, but I just want confirmatino on what I'm about to do.  I've commited my 10th revision to a repository, but I'd like to temporarily bring my working tree back to revision 9.  Do I use bzr revert -R 9 to do this?
<dOxxx> -r9
<dOxxx> lowercase
<KhaZ> OK, but revert doesn't actually force a commit, or revert in the repo or anything?
<dOxxx> I believe so.
<dOxxx> As I understand it, bazaar has a policy of not automatically committing changes.
<KhaZ> Sweet.  The word 'revert' scares me.  :)  I'm used to Perforce lingo for syncing to a particular revision, so my first inclination was to bzr up, but that didn't seem to take a -r parameter.
<dOxxx> yeah, that's update. I'm not actually sure when one would use update. checkouts?
<KhaZ> I believe you use update when you want to pull chnages from the repo that someone has pushed
<dOxxx> how does that differ from pull then?
<Tak> update is for updating a working tree from the branch to which it's bound
<Tak> pull is for pulling changes from one branch into another
<dOxxx> bound is not the same as have a push branch set, right?
<Tak> right
<KhaZ> Stupid question, can I recursively revert somehow?
<KhaZ> Oh, bzr revert * works for some reason, but I have to be down a level.  Weird.
<Tak> doesn't `bzr revert` with no arguments do that?
<KhaZ> I haven't the foggiest.  I'll try it out next time I need to do that. ;)
<KhaZ> I wonder if that works with bzr add as well
<KhaZ> I find bzr add * is nice to recursively add files, but it doesn't seem to respect files that are in bzr ignore
<KhaZ> Maybe bzr add will respect that.. Hrmm.
* jam changed the topic of #bzr to: Bazaar version control system | 2.0.2 and 2.1.0b3 have gone gold! time to build those installers | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Current pilot: spiv
<jam> KhaZ: if you explicitly name a file with "*" then add will always add it
<jam> bzr add .
<jam> or bzr add
<jam> will recurse from current dir down, or everything respectively
<jam> respecting ignores
<KhaZ> Ah, awesome.  SO bzr add or bzr add . will respect the ignore list?
<jam> and yes "bzr revert" no args should revert the whole tree
<jam> KhaZ: yes
<KhaZ> Yeah, I figured bzr add * would not respect the ignore list, since technically I"m explicitly saying "add this!".
<KhaZ> Awesome.  Good to hear.
<dave_> I have a problem where I installed bzr on a windows comp and put some things under bzr, then the comp crashed. I can access the drive from linux, is there a way to get at those files?
<jam> dave_: well, if you can get access to the drive, then generally you'll have access to the .bzr directory
<jam> and you can "bzr branch /path/to/win32/"
<jam> etc
<dave_> and the .bzr directory isn't in the root directory, though, yes?
<dave_> well, thanks
<stuartpb> Uh, how am I supposed to install Bazaar on Slackware?
<dOxxx> stuartpb: download the source distribution and 'python setup.py install' I think?
<bialix> hi jam: please use qbzr 0.16 for 2.1.0b3
<jam> bialix: sure
<bialix> you're asked, me answered
<bialix> gnight
<dOxxx> I just got a very odd error when pushing to lp:
<dOxxx> http://pastebin.com/m23fbb00c
<dOxxx> when creating a local branch of bzrtools, I created it in a 2a shared repository
<dOxxx> I guess bzrtools is not a 2a format branch and so stacking on it doesn't work?
<jam> dOxxx: right, though if you do "bzr push -r -1" again it will push without stacking
<jam> probably more accidentally than anything, but it should work
<dOxxx> I'm trying to recreate my feature branch with the correct format
<jam> I think bzrtools is in 1.9-rich-root, which means it should be able to merge any changes from a 2a format repo
<dOxxx> yup, success :)
<dOxxx> lp:~doxxx/bzrtools/shell-dir
<fullermd> jam: Hey, I've got a Q or two...
<jam> fullermd: QQ ?
<fullermd> Nono, that's perl   8-}
<jam> more pew-pew, less QQ fullermd
<fullermd> Somewhat re that merge thing.  I was under the impression that when we merge3 on a criss-cross, it bleats at you and tells you to lca or weave.
<jam> not exactly
<jam> it still tries merge3
<jam> it just bleats at you
<jam> however, for the tree-shape info, etc
<jam> we still use a common base
<fullermd> But when I use -r0..-1 to force that merge to go through, it doesn't.  Is that because I explicitly -r'd, or because of the null LCA in that case, or something else?
<jam> fullermd: you actually want "-r1..-1"
<jam> but it doesn't bleat when you supply a base
<jam> because it doesn't search for one
<jam> yes
<fullermd> Ah.  Should it?  In the real case, the criss-cross caused a lot of really ugly spurious conflicts.
<fullermd> (using weave left it with 2 real ones)
<jam> fullermd: so if you used "-r 1..-1" I would expect fewer conflicts
<jam> though possibly you'd still end up with a bunch from side-2
<fullermd> That wouldn't work in the real case, because r1 on both sides are totally unrelated.
<jam> fullermd: sure, but supplying 0 is probably saying also look at all the changes from this side
<jam> at least 1 skips that initial import
<jam> anyway, only --weave and possibly --lca will work in this case
<jam> since there is clearly no "clean" base
<jam> fullermd: in case you didn't get my joke: http://www.urbandictionary.com/define.php?term=less%20qq%20more%20pew%20pew
<fullermd> Anyway.  *I* know that, because I know (or would have known had I pondered it) that it was a criss-cross.
<fullermd> It feels like bzr probably should have known to prompt me, though.
<jam> well, it did warn you :)
<jam> I've really wanted to get merge3 to use per-file merge bases
<jam> which might get you out of this as well
<jam> if the code bases were truly disjoint
<fullermd> Not as such, it just dumped me a big pile of conflicts...
<jam> ENOTUITS
<fullermd> Actually, I thought the plan was just to make lca the default.  Did that just fall in the tuit hole, or are there reasons not to?
<jam> well, if you specifically request -r0 we'll give you -r0
<jam> at *this* point, *I* prefer --weave to --lca
<jam> but I worked on --weave
<jam> abentley worked on lca
<jam> We've talked about changing
<jam> but people also like getting .THIS .OTHER .BASE files
<jam> which is why people like mysql use --merge3 most of the time
<fullermd> Going back and retrying the real branches with 1..-1 instead of 0..-1 doesn't make any visible difference on the conflicts.
<fullermd> 8 conflicts encountered.   one way and   20 conflicts encountered.  the other.
<fullermd> (and actually, I think one of the real ones is spurious, but I s'pose it's possible bzr can't really tell.  1 of them is real.)
<fullermd> Anyway.
<fullermd> I also got an eye-twitch at that btree padding change.  Could that trip up pre-2.1 versions?
<jam> fullermd: shouldn't
<jam> we never read those bytes
<fullermd> (I have no reason necessarily to believe it does, it just caught my eye as something that played in that court)
<jam> we allow a single page to be <4096 bytes
<jam> we reserve 120 bytes at the start
<jam> but if it is less than that
<jam> we write the info right away
<jam> and pad at the end to make up the loss
<jam> and generally we just throw away those bytes anyway
<jam> so the change was to just not write the
<jam> them
<fullermd> Good 'nuff for me.
<fullermd> Danke.
<jam> fullermd: any more Q.Q ?
<jam> or :,( :)
<jam> :'( I mean
<fullermd> Well, I'm massively piled up and way behind at work.  Does that count?
<fullermd> But I'm hopeful that if I can get a good long day in today, I can take care of the stuff we need for the Oct 30 deadline and start looking at what we need for the Nov 16 one...
<jam> fullermd: could you put that in the form of a QQ?
<jam> fullermd: so only 2 weeks behind?
<jam> I've certainly been far worse than that
<fullermd> Well, so far...
<fullermd> We've still got almost a month until the hard deadline when the whole thing has to be done.
<lifeless> fullermd: what are you working on?
<jam> morning li
<jam> lifeless:
<jam> ^^
<fullermd> Oh, it's just $CURRENT_PROJECT.  The client has their big annual convention thingy in December, and we're supposed to have this all ready for them to show off then.
 * fullermd is losing optimism.
<vila> fullermd: yeah, next time I have to debug some ntp stuff, I'll be sure to not ask you (two weeks... and you were criticizing my VMs getting some *hour* skew... sheesh)
<vila> :-p
 * vila refocus on the session :)
<fullermd> Hey, *I* know what time it is.  's not my fault my clients are getting ahead   :P
<kfogel> is there any documentation on tags in bzr?  Google turns up pages about their existence, but http://doc.bazaar-vcs.org/latest/en/search.html?q=tags gives pretty thin results...
<lifeless> kfogel: bzr help tag
<spiv> Good morning.
<igc> morning
<lifeless> aloha
<spiv> Hey wow, a bug report about TooManyConcurrentRequests that's actually due to bzr attempting to make concurrent requests on an HPSS connection.
<Peng> ...Wow.
<Peng> And I joked about that bug this morning. Whoops.
<poolie1> biab
<poolie1> hello jam, vila
 * spiv boggles as a bug search for "hpss upgrade" fails to find a bug with tags of "hpss" and "upgrade"
<fullermd> jam: (btw, looking back at it, merge -r1..-1 would have been a really bad idea, since it's a cherry pick)
<spiv> Or any bugs, in fact.
<fullermd> Hey, cool, that means the hpss upgrade is perfect!
<spiv> fullermd: 107173 disagrees :P
<fullermd> Pfft.  Who you wanna believe, 107173 or LP?
<dOxxx> spiv: going through bzr merge proposals?
<spiv> dOxxx: yup
<dOxxx> must be a pile of work
<spiv> Yeah, but we get bug fixes and other improvements out of it :)
<spiv> Which is going to be work one way or another ;)
<dOxxx> yep
<poolie> hi spiv
<poolie> spiv, it might be good to send a brief reply to the pilot thread just saying you're doing it and how it's going
<spiv> Yeah, that's a good idea.  Although I did just send a similar mail in reply to a related thread.
<poolie> i saw
<poolie> but people don't read all mail
<poolie> sending _more_ mail is a questionable fix :-) but i think worthwhile here
<spiv> :)
#bzr 2009-11-17
<poolie> more seriously i think it will create more of an impression that this is actually something that's going to happen as an ongoing custom
<poolie> not just you randomly doing reviews
<dOxxx> poolie: just read your reply about outf and the UIFactory stuff
<poolie> i'll put up the branches soon
<poolie> that'd be better than describing them
<dOxxx> poolie: cool. code is good :)
<dOxxx> I think once I've adapted my changes to the updated UIFactory, I'm definitely going to need a review of what should be going through the normal message methods vs make_output_stream. Some of it is obvious like diff and log, but for others it's more of a grey area.
<dOxxx> do the blackbox tests run out-of-process?
<lifeless> dOxxx: some do
<lifeless> dOxxx: most don't, too slow.
<lifeless> dOxxx: run_bzr is in process. run_bzr_subprocess is out of process
<dOxxx> gotcha
<dOxxx> I had to do a lot of tweaking of the tests for my initial set of changes because quite a few of the messages moved from stdout to stderr as a result of using trace.note
<lifeless> dOxxx: what were you changing?
<lifeless> dOxxx: by which I mean, generally, we've chosen stdout or stderr, so that sounds like a set of bugs.
<dOxxx> lifeless: I started out fixing a bug for the mv command not obeying the --quiet option
<dOxxx> lifeless: when I noticed that a lot of the other commands were using self.outf.write directly instead of trace.note and thus ignoring the --quiet option too
<dOxxx> lifeless: so I thought I would clean it up and make sure everything that wasn't bulk data, as poolie describes it, was using trace.note
<lifeless> so, its not 'bulk data' but rather 'the output of the command'
<lifeless> that should be using outf.write
<dOxxx> yeah
<lifeless> bzr 2>/dev/null should never hide data the user needs
<dOxxx> like the output of log or diff
<lifeless> or the list of files moved
<dOxxx> now that's where I'm talking about grey areas
<dOxxx> the purpose of the mv command is not to output a list of moved files. it's to actually move the files. the list of moved files is incidental to it's actual purpose.
<lifeless> mmm
<dOxxx> but I don't feel like I have the right to make those sorts of judgement calls :)
<lifeless> dOxxx: so, a progress bar would be definitely incidental
<dOxxx> yes
<lifeless> dOxxx: the list of files moved is more important, to me.
<dOxxx> hmm
<lifeless> its the return value
<lifeless> if you think of mv as a function call
<dOxxx> perhaps it's the difference between the primary output of the command and out-of-band information
<lifeless> thats right, we use stderr for out of band
<dOxxx> hmm
<lifeless> stuff that isn't needed for scripting
<lifeless> or capturing
<dOxxx> yeah
<poolie> dOxxx: btw did you do the contributor agreement http://www.canonical.com/contributors
<dOxxx> Oh, no I haven't.
<dOxxx> I'll have a look at that now.
<dOxxx> hmm legalese :P
<dOxxx> I'm glad #11 is in there ;)
<dOxxx> poolie: agreement signed and emailed
<maxb> There doesn't seem to be any command for "just merge the WT back to r9"
<maxb> er, ignore me, scrollback fail
 * maxb was attempting to jump into a conversation from 3 and a half hours ago
 * igc lunch
<spiv> dOxxx: still around?  I like the sound of a more general fix, but in the meantime how about just changing cmd_mv to check is_quiet as some other commands already do?
<dOxxx> spiv: I was just about to reply that I agree. For the purposes of fixing that bug, I'll change it back to use self.outf.write but check is_quiet first.
<spiv> dOxxx: great.  Thanks!
<dOxxx> spiv: what should I do about your added bits? do I just apply that patch to my own branch?
<spiv> dOxxx: you can either 'bzr merge lp:~spiv/bzr/271790 && bzr commit -m "Merge from spiv."', or just build on your own and I'll merge them before I land.
<lifeless> spiv: I was a little surprised you'd sent merge 14812 to pqm
<lifeless> spiv: given it only had one core review
<maxb> Is there any way to ask bzr to diff against the pending merge tip?
<maxb> or indeed, any way to get the revid of the pending merge tip
<lifeless> via python
<lifeless> we need a rev spec
<fullermd> I'm kinda grumpy that stat --show-ids doesn't show 'em...
<lifeless> fullermd: patchit :P
<fullermd> Right, in my CFT   :p
<maxb> Hrm. The Ubuntu Distributed Development initiative seems to be a great way to run straight into file-id conflict nightmares.
 * maxb wishes for bzr diff --ignore-file-ids
<elnovato1> Help!!
<elnovato1> different rich-root support  << i got this error when i push
<bob2> what are you pushing, and to where?
<spiv> lifeless: well, it looked so simple...
<lifeless> spiv: Personally,  I'd only submit something without 2 core +1s if I'd be willing to do it with no other review at all
<spiv> lifeless: and the patch had been lingering for several days.
<lifeless> spiv: sure; thats nag for a review space isn't it?
<spiv> Well, it looked safe enough when I reviewed it and tested it.  PQM proved me wrong, of course.
<lifeless> spiv: I'm not talking about safety per se
<spiv> Well, by "safe" I guess I mean "trivial"
<lifeless> well, +1 for experience :)
<spiv> :)
<lifeless> all the same, I think the only things I'd land that have only one core review would be docstring and whitespace fixes.
<lifeless> because anything else that I wrote, I'd want a second eyeball on.
<lifeless> and I don't trust folk that aren't core to have the experience of the library etc to catch corner concerns in a review.
<spiv> elnovato: what are you pushing, and to where?
<elnovato> got it, they are diff versions
<jdub> is it possible to get loggerhead to dump tracebacks if it dies?
<jdub> every now and then the process barfs, would love to file bugs
<lifeless> in principle yes
<lifeless> there is wsgi stuff around
 * jdub just flicked his eyes over this window and read "barFS"... oh dear.
<AfC> jdub: you need to get out more, mate
<AfC> [but if you do come up with a bar-fs, I want to use it for my /home partition]
<dOxxx_> spiv: are you around?
<dOxxx> well maybe somebody else knows this... I've made some changes in my branch as suggested in a review of my merge proposal and I've pushed these changes up to the branch I made the proposal for. Do I use the Resubmit proposal link or is it handled automatically?
<spiv> dOxxx: I am
<dOxxx> hmm
<dOxxx> ok it seems to have updated  by itself
<spiv> dOxxx: the diff will be automatically updated, but I think use resubmit if it needs a fresh round of review.  In this case I don't think it's necessary, because I'll just send it in now.
<dOxxx> ok
<spiv> Although I'll have to fix the NEWS conflict, but that's easy.
<dOxxx> yeah I just noticed that
<dOxxx> I suppose I should get into the habit of pulling before I push :)
<dOxxx> I've just dealt with the conflict locally. If you haven't done it yet, I can push it up.
<fullermd> Well, if you wait 5 minutes, NEWS conflicts un-resolve themselves again   :p
<spiv> dOxxx: Ah, thanks, I already did that, just waiting for PQM now. :)
<spiv> Ah, there it is: http://pqm.bazaar-vcs.org/
<dOxxx> thanks, I'll get the hang of this :)
<poolie> spiv, nice work with the patches
<dOxxx> he's been very helpful :)
<spiv> poolie: Thanks.  Next one I'm dealing with is https://code.edge.launchpad.net/~slyguy/bzr/bug-440952-bzrdir/+merge/13431, which I'd actually promised to finish off a while ago before we thought of patch pilots, just because the submitter had obviously put a bunch of good work in that I didn't want to waste.
<poolie> k
<spiv> That's part of why I volunteered, so I'd have a good excuse to get to it sooner rather than later :)
<poolie> :)
<poolie> you can ask me or others for help too
<poolie> though i wouldn't recommend asking me in particular today :)
<spiv> :)
<dOxxx> bzr has an astounding number of tests.
<dOxxx> I wish the --parallel selftest option worked on windows.
<spiv> dOxxx: patches welcome :)
<dOxxx> hehe
<dOxxx> maybe I will have a look
<dOxxx> do I need to install testtools into my python site-packages?
<spiv> Yes, I think so.
<dOxxx> ah, subunit is the problem. not ported to windows I guess?
<jelmer_> dOxxx, at least the python bits of subunit should work without problems on Windows I think
<dOxxx> jelmer_: but aren't they just bindings into the c library?
<jelmer_> dOxxx, no, they don't rely on the C library in any way
<dOxxx> oh!
<poolie> hi jelmer
 * poolie tries to fix doc builds again
<jelmer_> moin poolie
 * jelmer_ waves from UDS
<mwhudson> hello jelmer_
<poolie> hello
<poolie> did you get my pm?
<jelmer_> hey mwhudson
<jelmer_> poolie: mwhudson or me?
<mwhudson> jelmer_: you i presume :)
<poolie> you
<poolie> you, jelmer
<dOxxx> lifeless: are you here?
<lifeless> somewhat
<lifeless> don't ask to ask, just ask ;)(
<dOxxx> heh ok
<dOxxx> lifeless: I was wondering if there was any particular reason why reinvoke_for_tests manually executes bzr instead of reusing the run_bzr_subprocess code?
<lifeless> not offhand; possibly trust issues
<RenatoSilva> dOxxx: hi
<dOxxx> RenatoSilva: heya
<dOxxx> lifeless: right...
<RenatoSilva> dOxxx: is bug 398997 really fixed? it's more than one test error...
<ubottu> Launchpad bug 398997 in bzr-xmloutput "Test failures and errors on Windows" [Medium,Fix committed] https://launchpad.net/bugs/398997
<dOxxx> RenatoSilva: when I was testing it, I was only getting the test_version failure
<dOxxx> RenatoSilva: are you still getting errors?
<RenatoSilva> dOxxx: will pull the changes and check, but I can't recall how to run it :(
<dOxxx> RenatoSilva: if you have it in the correct location to be picked up as plugin by bzr, 'bzr selftest xmloutput' should do it
<RenatoSilva> dOxxx: error: QtHelp4.dll not found
<dOxxx> RenatoSilva: Hmm...
<RenatoSilva> Anyone knows how to solve this?
<spiv> RenatoSilva: I wish I did
<RenatoSilva> there's the bug 448389 about it
<ubottu> Launchpad bug 448389 in bzr "[win] 2.0 selftest fails, missing Qt dll" [Undecided,New] https://launchpad.net/bugs/448389
<dOxxx> yes, I see that too
<dOxxx> I thought it was just a screwed up setting in my environment
<dOxxx> RenatoSilva: but otherwise, that bug is fixed as far as I can tell.
<RenatoSilva> dOxxx: I have to confirm that
<RenatoSilva> dOxxx: after clicking ok in the qt error message, the test go on, and I'm getting a lot of errors here :(
<RenatoSilva> dOxxx: Ran 82 tests in 49.125s, FAILED (errors=14, known_failure_count=1)
<dOxxx> RenatoSilva: wow...
<dOxxx> RenatoSilva: could you pastebin the errors?
<RenatoSilva> dOxxx: do you get the QT dll error too? winXP?
<dOxxx> RenatoSilva: yes I do. on vista 64.
<dOxxx> RenatoSilva: I suspect it's something introduced with bzr 2.0.2
<RenatoSilva> dOxxx: so you get the qt error, click on, then all tests pass?
<dOxxx> yes
<RenatoSilva> dOxxx: there is stdout and stderr, will paste stdout
<RenatoSilva> dOxxx: http://pastie.org/702167.txt
<RenatoSilva> dOxxx: same errors of bzr-java-lib tests...
<RenatoSilva> dOxxx: I think it's a bug with bzr in Windows
<dOxxx> RenatoSilva: yeah... I think you've got something wrong with your environment.
<RenatoSilva> dOxxx: I think something wrong with bzr, I tried everything possible to solve this problem
<RenatoSilva> dOxxx: do you have wXP or some vm there?
<RenatoSilva> dOxxx: I would like at least to understand what happens exactly, beyond "something regarding locks"
<RenatoSilva> dOxxx: if I knew bzr internals maybe I could undertsand better the error and be working on a fix
<dOxxx> RenatoSilva: my guess would be that it has something to do with non-ascii characters in the paths
<lifeless> RenatoSilva: you have a locked working tree
<RenatoSilva> dOxxx: what paths?
<lifeless> thats not getting unlocked.
<dOxxx> RenatoSilva: the paths to the temp dir
<RenatoSilva> lifeless: hi, in bzr-java-lib I used procmon to get track of the problem. I watched bzr.exe and found one access denied error about lock/held file/dir (mentioned yesterday here, don't know if you saw). The most interesting thing in that line is that in the details column, there's a random text about another file, lock/*.tmp
<RenatoSilva> dOxxx: if it was non-ascii paths, the problem would be fixes with changing it, and it is not
<RenatoSilva> *fixed
<RenatoSilva> lifeless: I would like to understand why the xxx.tmp file is randomly reported as detail for the access denied in lock/held
<dOxxx> RenatoSilva: I do use bzr at work on winxp sp3 box
<RenatoSilva> dOxxx: can you test now?
<lifeless> RenatoSilva: I don't understand why you say its random
<RenatoSilva> lifeless: random because it does not explain the relation
<lifeless> we use temporary files a lot, because many network file systems don't have an atomic write to a file
<dOxxx> gimme a few minutes, gotta vpn and it breaks my net connection here
<RenatoSilva> lifeless: random like saying the sky is blue in details column for a given error
<lifeless> what details column, you've lost me
<RenatoSilva> lifeless: there's a too called procmon for windows
<RenatoSilva> lifeless: you can watch what a process does
<RenatoSilva> http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
<RenatoSilva> * tool
<lifeless> RenatoSilva: I don't have windows
<RenatoSilva> lifeless: I tell the full to watch bzr.exe, and the I run the test in bzr-java-lib that fails randomly
<RenatoSilva> I tell the *tool
<RenatoSilva> lifeless: it lists all files accessed, dlls loaded, registry keys accessed, all the bz.exe activity, including the files in the temp dirs for the tests
<spiv> RenatoSilva: the lockdir code will attempt to perform operations like "rename RANDOM.tmp held" and "rename held releasing.RANDOM.tmp"
<RenatoSilva> lifeless: there's one entry saying that there was an access denied in lock/help
<lifeless> well, that could well cause problems in the tests
<RenatoSilva> lifeless: and there's a detail column for that where you expect to hrrr get details about it
<spiv> RenatoSilva: where "RANDOM" is a string of random letters and digits, obviously.
<spiv> RenatoSilva: perhaps that's what procmon was reporting?
<RenatoSilva> lifeless: now imagine the detail column says "nice day today", it doesn't give detail about anything right? the same way, the actual text there in just the file path to lock/*.tmp
<RenatoSilva> spiv: oh so the error was about renaming files, hum...
<spiv> RenatoSilva: so, it appears it is giving relevant detail :P
<RenatoSilva> spiv: at least for me that had no idea :P
<dOxxx1> RenatoSilva: I don't get the permission errors running the xmloutput tests on winxp
<dOxxx1> RenatoSilva: sorry to say but I think it's just you :P
<RenatoSilva> dOxxx1: is it updated?
<RenatoSilva> dOxxx1: what's your antivirus
<dOxxx1> RenatoSilva: symantec corporate thingy
<RenatoSilva> spiv: what could make bzr not release a lock
<dOxxx1> RenatoSilva: checkout of branch: bzr+ssh://bazaar.launchpad.net/~verterok/bzr-xmloutput/trunk/
<dOxxx1> switching back
<RenatoSilva> oh sorry just /cleared the screen, what one jsut told me?
<spiv> What makes you ask that question?  From the information you've given here I'm not sure that's the right question to ask.
<RenatoSilva> spiv: why
<RenatoSilva> spiv: what's the right question to ask
<lifeless> RenatoSilva: generally, not calling 'tree.unlock()' will cause a lock not to be unlocked.
<spiv> I think you want to be asking "why am I getting 'access denied' errors when bzr is attempting to release (or acquire?) that lock?"
<RenatoSilva> lifeless: or maybe tree.unlock() failing? e.g. an external os error?
<lifeless> bzr should be reporting any errors like that that might turn up
<RenatoSilva> where's the log for this channel?
<lifeless> something is messing with the reporting/output, *or* you're simply not unlocking it
<lifeless> race conditions and finalizers can be to blame too,
<lifeless> and as you're testing some java lib stuff, I'd look there first
<RenatoSilva> lifeless: the above link is just stdout, I can't recall how to mix stdout and stderr to send to a file in Windows, let me try...
<spiv> RenatoSilva: there's some at http://irclogs.ubuntu.com/2009/11/17/%23bzr.html, not sure how frequently they are updated
<dOxxx1> RenatoSilva: command > file 2>&1
<RenatoSilva> lifeless: http://pastie.org/702167.txt
<RenatoSilva> dOxxx1: thanks
<dOxxx1> how long does it take for an old nick to timeout
<dOxxx1> from the irc server?
<RenatoSilva> dOxxx1: /msg nickserv ghost <pwd> iirc
<dOxxx> woot... got bzr selftest --parallel=subprocess working on windows
<lifeless> RenatoSilva: then as it says, something has the held file locked
<lifeless> dOxxx: +1
<dOxxx> lifeless: and I think it might even still work on unix ;)
<lifeless> RenatoSilva: figure out what process that is (sysmon all processes probably - including system)
<lifeless> dOxxx: well, I surely hope so :)
<RenatoSilva> lifeless: so I watch the file, not the process, ok let me try...
<dOxxx> lifeless: it's pretty noisy. far more output than the normal selftest
<RenatoSilva> spiv: thanks for the log link
<dOxxx> lifeless: lots of stuff like this: successful: bzrlib.tests.per_tree.test_path_content_summary.TestPathContentSummary.test_file_content_summary_executable(DirStateRevisionTree,WT5)
<lifeless> dOxxx: thats subunit output, it shouldn't show up unless you supply --subunit
<RenatoSilva> is the qt dll in the error about the qt ui?
<lifeless> dOxxx: and you should pipe it through a subunit filter. e.g. subunit-stats
<lifeless> bbiaw
<dOxxx> lifeless: I'm using --parallel=subprocess because fork doesn't work on windows, at that seems to have implied --subunit
<dOxxx> anyway, I gotta hit the sack
<dOxxx> seeya guys later
<RenatoSilva> dOxxx: see you
<poolie> igc, why does only doc/ja have a sphinx configuration file?
<RenatoSilva> lifeless: even including System, there are only two process invloved with lock/held: bzr.exe and avgchsvx.exe (AVG real time scanner)
<RenatoSilva> lifeless: so ok, the antivirus is the problem, what I don't get is why still doesn't it work when I turn it off :(
<poolie> well, i see it came in inada's recent mail
<igc> poolie: I'll take a look
<poolie> nevermind, i'll look into it
<poolie> i thought it was your change
<poolie> so, really, don't worry
<spiv> igc: if you're in the mood, feel like taking a look at https://code.edge.launchpad.net/~amanica/bzr/325618_log_returns_too_much/+merge/14275 ?
<poolie> i think they're not actually needed?
<igc> poolie: I think sphinx_conf.py is redundant
<igc> spiv: I'll take a look tomorrow
<igc> poolie: maybe it was there for bootstrapping or it proceeded the shorter conf.py approach
<spiv> igc: cool, ta
<poolie> OK
<RenatoSilva> Hey folks what antivirus do you use? I'm thinking about abandoning AVG9 as it seems to be locking Bazaar
 * wgrant uses Ubuntu.
 * RenatoSilva too
<RenatoSilva> I want to install an antivirus that is friend of Bazaar
 * RenatoSilva will restart the computer and come back soon
<AfC> Uh, "av that's a friend of a dvcs"? weird
<poolie> afc: i think he means "that doesn't hold locks on files"
<poolie> spiv/igc: verbal +1 to remove it and fix the builds?
<AfC> poolie: ah!
<AfC> poolie: (that would be reminiscent of Tracker using inotify and blowing out the kernel's hard limit of monitorable files)
<spiv> poolie: remove what, doc/ja/sphinx_conf.py?  Sure, if that fixes builds then +1 from me.  I guess you'd need to tweak doc/ja/conf.py to import bzrlib.doc_generate.sphinx_conf instead?
<poolie> oh good point
<spiv> The improved consistency makes sense.
<poolie> yep, i just did a two-way merge against the english version
<RenatoSilva> lifeless: removed ABG and the lock errors stopped
<spiv> RenatoSilva: that's good to know
<spiv> Although a shame that it interacts so poorly.
<RenatoSilva> it who, bzr or avg? or both :P
<poolie> both
<poolie> though
<RenatoSilva> avg9 is weird, you deactivate the watch dog, but the process is still active
<poolie> i think the onus is on the scanner not to interfere with applications
<RenatoSilva> it was active in lock/held, although less than before, but it was
<RenatoSilva> poolie: I tired to exclude my profile dir and bzr dir from runtime scan but didn't work, and as I said above the realtime scanner doesn't really stop working it seems
<RenatoSilva> poolie: do you know of any "friend" antivirus?
<RenatoSilva> poolie: if I don't find one, I think I'll just reinstall AVG and live with these failures... at least we --know-- what's the problem now
<RenatoSilva> bzr-java-lib tests are ok now too
<RenatoSilva> this is normal output for bzr selftest xmloutput right? http://pastie.org/702237.txt
<RenatoSilva> the xfail is the known failure?
<poolie> yes
<poolie> poor name, we should change it
<RenatoSilva> ok, waiting for the qt dll fix then
<lifeless> poolie: what do you thinkof the idea of turning language translations into branches
<lifeless> doc language translations, I mean.
<poolie> i'm not sure what you mean
<lifeless> well, seems to me that each language is kindof like a branch, of the docs
<fullermd> I've thought on that sort of thing.  The big problem is that every merge is just a giant pile of conflicts.
<lifeless> 'bzr cp' + merges from those files on an ongoing basis would model it too, if we had copies
<poolie> mm
<poolie> interesting in theory
<poolie> the assumption under this is that folks do a diff on the english text to see what needs to be translated?
<poolie> s//newly translated
<lifeless> well, that they need to figure out what has gone on to update the translation, yes.
<lifeless> a conceptual diff, for sure.
<poolie> i guess i'd like to know more about how people actually do doc translation
<lifeless> yeah
<lifeless> it was a drive by thought based on the ja branch
<lifeless> which had one of the conf files we had initially
<RenatoSilva> spiv: maybe bzr does something that makes AVG angry
<RenatoSilva> spiv: would you recommend to try 2.1 beta? (using 2.0 and previously 1.18)
<fullermd> Presumably, "making the file and then trying to delete it pretty quickly before AVG gets done screwing with it"
<fullermd> Go the other way.  Try 0.11 or something.  That may be slow enough for AVG to finish up in time.
<lifeless> RenatoSilva: no, its not bzr
<lifeless> RenatoSilva: avg is taking a read lock rather than opening share_delete or whatever it is. We've had this problem reported before - as I said days ago, 'probably your virus scanner'
<RenatoSilva> lifeless: well I'm not sure. but why would AVG suspect of bzr as a potential problem?
<lifeless> RenatoSilva: who says it thinks bzr is a problem
<RenatoSilva> fullermd: 0.11?
 * fullermd was being a little facetious...
<lifeless> RenatoSilva: fullermd was making a joke. bzr 0.11 was a lot slower, so it might not collide with avg as much
<RenatoSilva> fullermd: so the problem is that bzr creates a file, then AVG starts to scan it, then in the meanwhile bzr wants to delete or rename the file, and so the error
<lifeless> yes
<fullermd> 's my guess.
<RenatoSilva> then why does AVG8 has no problem with it?
<lifeless> different versions of software behave differently
<lifeless> see my comments on locking above
<RenatoSilva> ok just was, I see
<RenatoSilva> *saw
<poolie> pyc files lingering after the source removed strikes again
<poolie> spiv: you were right btw
<RenatoSilva> lifeless: I think it's the .0 problem
<poolie> about fixing conf.py
<lifeless> RenatoSilva: what do you mean?
<RenatoSilva> lifeless: maybe it's the right thing to do, imagine the file is a virus, and another softwate deletes it after AVG detecting, maybe AVG 9 will always behave this way
<RenatoSilva> lifeless: i.e. not the .0 problem (foo bar 2.0, 3.0 etc)
<lifeless> RenatoSilva: I don't understand
<RenatoSilva> lifeless: AVG locks the file to scan it right? then bzr tries to delete/rename it and can't (it could in AVG8)
<RenatoSilva> lifeless: I think that's the right thing to do
<lifeless> thats our working theory.
<lifeless> RenatoSilva: I don't see why its right.
<RenatoSilva> lifeless: the file can't be deleted while being scanned
<lifeless> virus scanners should not change system behaviour
<RenatoSilva> lifeless: maybe it should just copy the file and scan the copy
<lifeless> RenatoSilva: avg could hard link it and scan. Or it could lock it share_delete and handle client code deleting the file.
<lifeless> RenatoSilva: that would be bad if the file is large.
<lifeless> RenatoSilva: I think its very clearly a bug in AVG
<RenatoSilva> hard links in windows?
<lifeless> yes
<lifeless> been supported for a while
<RenatoSilva> one more reason to not use .0 software :-/
<RenatoSilva> but thank you all you guys for helping me, I think I'll live with this error while waiting a fix
<lifeless> RenatoSilva: you realise AVG probably don't know there is a problem, and its not a bzr problem...
<lifeless> RenatoSilva: you really should tell them :)
 * poolie spams out the review queue
<maxb> Does bzr ever discard dead heads? Is there a command somewhere for that?
<beuno> maxb, dead heads?
<beuno> (I'm pretty sure the answer is no)
<beuno> like when you uncommit?
<maxb> yes, heads not referenced by any branch
<beuno> maxb, there is no way to clean them up
<henninge> Hi, I have a conflict situation that I don't know how to resolve.
<henninge> A file was created both in my current branch and the branch that I am merging from, with different content.
<henninge> Merge looks like this: http://paste.ubuntu.com/320877/
<henninge> I want to keep the file as it is and discarded the merged version, so effectively renaming the .moved file to the original name.
<henninge> I just don't know how. I tried a few things but they did not work.
<NfNitLoop> henninge: you should be able to bzr revert <filename> to revert just that file (without blowing away your merge)
<NfNitLoop> if you commit that merge, then, that has rejected the remote change.
 * henninge tries
<henninge> NfNitLoop: Great! that worked! http://paste.ubuntu.com/320879/
<henninge> NfNitLoop: thanks a lot
<NfNitLoop>  henninge you're welcome.
<NET||abuse> hey guys. i'm trying to push a repo of graphic work, from windows, over  to a samba share on a linux box, but i'm getting errors.
<NfNitLoop> NET||abuse: such as...?
<NfNitLoop> (please  use pastebin if they're large)
<NET||abuse> bzr: ERROR: [Errno 22] Invalid argument
<NET||abuse> that's it.
<NET||abuse> weird stuff.
<NfNitLoop> what command did you use to do the push?
<NET||abuse> bzr push P:\projects\sitegraphics\
<NET||abuse> I had a dir with 800MB of graphics work, i did bzr init in that directory
<NET||abuse> bzr add *; bzr commit ;
<LarstiQ> NET||abuse: could you try `bzr push P:/projecs/sitegraphics/` instead?
<NET||abuse> yeh, i could.
<LarstiQ> might be paranoid, but worht a try
<LarstiQ> if note, check the .bzr.log
<NET||abuse> just trying to branch to a local directory right now.
<LarstiQ> _not_
<NET||abuse> seemed to work wen branching..
<NET||abuse> right trying to push,, i need it up on the share so other people can get at the graphics.
 * LarstiQ nods
<NET||abuse> i could try branching while in the P: drive.
<LarstiQ> that's an option
<LarstiQ> or just copying the folder should work too
<Tak> export?
<NET||abuse> hmm, copy,, seems like cheating ;)
<NET||abuse> maybe it's timing out.
<NET||abuse> trying to branch now,,, it's saying "Fetching revisions:Get stream source
<LarstiQ> that's ok
<LarstiQ> NET||abuse: which version of bzr is this btw?
<NET||abuse> i'll check.
<NET||abuse> python25.dll version  2.5.4, bzr 2.0 seems to be what it's saying,,
<NET||abuse> no wait,, bzr 1.18.1
<LarstiQ> NET||abuse: ok
<phoenixz> I have two projects based on the same framework in BZR. They basically share libraries and I want functionality from project one shared with project 2 and vice versa.... Is it possible to only merge the libraries directory of these two projects, and leave the other directories untouched?
<GaryvdM> phoenixz: Have you been visioning these 2 projects in bzr allready?
<GaryvdM> phoenixz: The idea is that you have 3 branches. 1 for the framework and 1 for each project.
<GaryvdM> phoenixz: then you use nested trees (Which is not complete)
<phoenixz> GaryvdM: actually, thats where I want to go to, yes
<phoenixz> GaryvdM: nested trees? thats like a BZR tree inside a BRZ tree?
<GaryvdM> phoenixz: untill nested trees is finished, you can use scmproj
<NfNitLoop> Hrmm, https://bugs.launchpad.net/bzr/+bug/81844 seems to be keeping me from checking out an upstream SVN repo.  >.<
<GaryvdM> phoenixz: http://bazaar-vcs.org/NestedTreesDesign
<ubottu> Launchpad bug 81844 in bzr-svn "Handle backslashes in filenames more gracefully" [Low,Invalid]
<GaryvdM> phoenixz: https://edge.launchpad.net/bzr-scmproj
<phoenixz> GaryvdM: reading...
<clemente> NfNitLoop: me too. It is one of the bugs with most duplicates
<NfNitLoop> apparnetly svn is interpreting backslashes as directory separators.
<NfNitLoop> apparently*  (Guh, this keyboard!)
<NfNitLoop> but bzr-svn isn't cool with that.
<NfNitLoop> soooo, no bzr for this codebase.  :~(
<jelmer> NfNitLoop, that's not the problem, there are backslashes in filenames
<jelmer> NfNitLoop, and bzr doesn't support backslashes in filenames
<NfNitLoop> Oh, hrmm.   I'm seenig backslashes as file separators in SVN.
<NfNitLoop> let me double check that.
<NfNitLoop> yeah, they're directory separators, I can browse the directories in the svn checkout.
<NfNitLoop> bzr: ERROR: Unable to convert Subversion path eclipse/plugins/a.b.c\src\x\y\z because it contains characters invalid in Bazaar.
<NfNitLoop> I can cd into eclipse/plugins/a.b.c/src/x/y/z
<NfNitLoop> Oooh.  Hrmm.
<NfNitLoop> Looking at the log of the directory, apparently it was copied from a directory with backslashes in its name.
<NfNitLoop> so they fixed it, but it's not fixed in history.
<NfNitLoop> >.<
<NfNitLoop> Is there any workaround other than blowing away the history?
<jelmer> NfNitLoop, no, there's no way around that at the moment
<NfNitLoop> aww, ok.  Thanks.
<clemente> jelmer: the importer could convert the \ in 'file_id's and leave names with \, right? It was suggested in bug 81844 comment 6 but there's no specific bug for it
<ubottu> Launchpad bug 81844 in bzr-svn "Handle backslashes in filenames more gracefully" [Low,Invalid] https://launchpad.net/bugs/81844
<jelmer> NfNitLoop, it basically needs a fix in bzr
<jelmer> clemente: we can't leave \ in names because bzr doesn't allow it
<clemente> jelmer: the comment I mentioned also suggests allowing \ in names in bzr
<jelmer> clemente, yes, that's the way to go
<jelmer> clemente, there's a separate bug in bzr for that I think
<clemente> True, bug 163858. I will link to it from the former bug
<ubottu> Launchpad bug 163858 in bzr "backslashes in filenames not allowed (dup-of: 81844)" [Medium,Triaged] https://launchpad.net/bugs/163858
<ubottu> Launchpad bug 81844 in bzr-svn "Handle backslashes in filenames more gracefully" [Low,Invalid] https://launchpad.net/bugs/81844
<Peng> "Fatal Python error: deletion of interned StaticTuple failed" \o/
<Peng> I wonder if SimpleSet is thread-safe?
<mgedmin> http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html is a very nice and convincing document
<Peng> jam: ping
<jam> hey Peng
<Peng> Hi. :D
<pickscrape> Is it possible to get back the message of a commit that failed?
<pickscrape> i.e. I don't want to have to type it again :)
<Peng> jam: I wanted to pester you about StaticTuple, as usual. Today, Loggerhead crashed with "deletion of interned StaticTuple failed". Any idea why that would happen? Is interning/uninterning thread-safe?
<jam> Peng: I don't include any locking primitives
<jam> however, I also don't release the GIL
<jam> Looking at the code:
<jam> if (SimpleSet_Discard(_interned_tuples, (PyObject*)self) != 1)
<jam>     Py_FatalError("deletion of interned StaticTuple failed");
<jam> It would indicate that the interned dict claims to not have the st present
<jam> but the tuple itself claims to be interned
<jam> well, the SimpleSet (vs dict)
<Peng> Or there was an exception of some sort.
<jam> note that right after that
<jam> self->flags &= ~STATIC_TUPLE_INTERNED_FLAG;
<jam> so it shouldn't be possible to try and remote it twice
<Peng> Plus... I don't think it's worth throwing a fatal error if the st wasn't present. Maybe a warning, but it's not actually *dangerous*, though it does mean something has gone wrong.
<jam> Peng: correct, some sort of failure while removing the st from the dict
<jam> Peng: internal state being inconsistent seems dangerous to me
<Peng> Yeah, but this specific error isn't hard to recover from. Meh, I could go either way, I guess.
<jam> Peng: and you can't raise exceptions from _dealloc
<jam> so you have to PyErr_Clear if there is a real failure
<jam> etc.
<Peng> Equivalent to __del__ in Python code?
<jam> Peng: basically
<jam> except it doesn't cause the gc to puke
<Peng> Ah, ok.
<Peng> (The gc pukes?)
<jam> you can reclaim objects with _dealloc
<jam> gc can't reclaim objects in a refcycle that have __del__
<jam> you *could* reclaim objects in a refcycle with _dealloc
<jam> as it is done at a different level, I guess
<Peng> What did SimpleSet_Discard return, -1 (exception) or 0 (wasn't present)? Either one?
<jam> Peng: I don't know. Something other than 1 did exist
<jam> bbiab, getting lunch
<Peng> jam: Have fun. :)
 * Peng has fun causing crashes by manipulating _interned_tuples.
<jam> Peng: manipulating?
<jam> that sounds seriously bad
<jam> certainly you shouldn't (even be able) mutate these once their created
<jam> and definitely not after you've called .intern() on them
<Peng> jam: _interned_tuples.discard(something_in_it) causes the dealloc crash. :)
<Peng> jam: It's not like I'm doing that in real code; I just think it's funny (I'm easily amused).
<Peng> python -c "from bzrlib._static_tuple_c import _empty_tuple, _interned_tuples; _interned_tuples.discard(_empty_tuple)" -> crash
<jam> Peng: if you are going to do something like that, I'm going to hide _interned_tuples from you
<Peng> jam: Yes sir :(
<jam> certainly you can crash things easily by something like that, though
<jam> I suppose I could expose it as
<jam> _peng_you_really_dont_want_to_touch_these_interned_tuples
<jam> Peng: would that be better?
<fullermd> I'd rather have API's with specific injunctions against me than a statue   :p
<Peng> jam: It would make the line-wrapping in _static_tuple_c.c a pain.
<jam> Peng: :) I wouldn't change the C name, just the name exposed to python
<Peng> Ooooo, clever.
<jam> fullermd: meaning... you'd rather be able to shoot yourself in the foot than not be given a gun?
<Peng> Just out of curiousity, is it possible to mutate a StaticTuple from C code, if you're evil?
<fullermd> Well, obviously.  But I just think of it as a fitting tribute of me to send down through the ages.
<fullermd> Centuries from now, archaeologists will try to reconstruct my life from fragments of code berating me for my use of them.
<fullermd> It'll be awesome!
<jam> Peng: raw pointers can do anything in C
<Peng> Good point.
<jam> StaticTuple_SetItem specifically should not be called for any object that has been exposed to python
<jam> same as PyTuple_SetItem
<jam> but you have to have *some* api for creating them in the first place
<Peng> Anyway... that Loggerhead crash isn't good. Sure, it's only happened once, but if there's a race condition, users who get significant traffic (Launchpad) might experience it frequently.
<Peng> But it's also probably not easy to track down. :\
<jam> Peng: I understand from mwhudson that loggerhead crashes regularly on LP regardless of StaticTuple
<jam> bzrlib itself isn't particularly threadsafe
<Peng> Haha.
<Peng> Since 2a, it crashes for me every day or two cuz it runs out of memory. :)
<Peng> I really need to set something up to restart it automatically... I wonder what LP uses?
<jam> In mooloolaba mwhudson mentioned that he had it fairly stable for a while ~6 months ago
<jam> and just hasn't had much time since to maintain that
<jam> Peng: cron, I believe
<mwhudson> jam: sysadmins
<jam> mwhudson: ah l-o-s-as what can't they do :)
<Peng> Unlike losas, I sleep sometimes, so it's often down for many hours. Fortunately, nobody uses it so it doesn't matter!
<jam> mwhudson: so how often does it crash? And how does that get reported for a restart. Is it manual?
<mwhudson> jam: a few times a day, nagios
<mwhudson> it usually doesn't crash per se, but go unresponsive
<jam> mwhudson: I also had a question that I was hoping you might have some knowledge to answer
<jam> if you look at bug #423804
<ubottu> Launchpad bug 423804 in bzr "Failure to saturate bandwidth downloading lp:bzr" [High,Confirmed] https://launchpad.net/bugs/423804
<jam> You can see that streaming data off of launchpad has a very strange shape
<jam> (see the last .png file: http://launchpadlibrarian.net/35795705/get_stream_lp.png)
<mwhudson> jam: that's a little odd
<jam> I was wondering if it might be something with LP, but I'm not really sure how to test
<jam> also, what is the deal with 'staging'
<mwhudson> jam: how does it compare to say bzr+ssh off chinstrap?
<jam> mwhudson: I haven't tried that yet, but I'll go there next
<mwhudson> jam: please do
<jam> mwhudson: how does one get a new ssh key onto chinstrap?
<jam> file an rt request?
<mwhudson> jam: "what is the deal with 'staging'" <- more pls?
<jam> mwhudson: back to staging... does it have any data from lp: ?
<jam> or is it only new stuff you upload?
<jam> (It looks like the latter to me)
<mwhudson> jam: i think there's some magic email address you can email, look on wiki.c.c?
<mwhudson> jam: it has a few branches from production
<jam> mwhudson: as for other comparisons, http://launchpadlibrarian.net/35795404/get_stream_babune.png is from Vincent's server
<mwhudson> but not many
<jam> though he seems to have a 100k download cap
<jam> sorry upload cap
<jam> which is 1/3rd my download cap
<jam> mwhudson: ok, does staging run a newer bzr?
<jam> (my last test suggested that both live and staging were running 2.0.0)
<mwhudson> jam: only when we land a newer bzr in rf
<mwhudson> which we haven't done for a while for a variety of bad reasons
<mwhudson> it doesn't track bzr.dev or anything like that
<jam> k
<jam> babune has 2.0.2 as does chinstrap
<Peng> Think it's worth filing a bug about the crash?
<jam> but I don't think there is anything significant there versus 2.0.0
<jam> Peng: it is worth *something*, but without being able to reproduce it, I'm not sure what a good answer is
<jam> If you want to create a patch that just improves debugging
<jam> like, perhaps writing out the actual response from the set
<jam> checking if there is an exception
<Peng> Oh wait, my StaticTuple branch hasn't even landed in LH's trunk yet.
<jam> if so, debugging that
<jam> I'd be willing to land that in bzr
<jam> mwhudson: ahh local bandwith. Chinstrap is downloading a copy of bzr at about 1.8MB/s
<jam>  /glee
<mwhudson> jam: running bzr get lp:bzr on chinstrap?
<jam> mwhudson: yeah
<mwhudson> sounds a bit slow :)
<jam> course, it almost seems hung at the "Inserting missing keys" stage
<jam> which is a bit strange
<jam> mwhudson: well, interestingly enough "time bzr branch lp://staging/~jameinel/bzr/bzr-test" on babune was 1m49s, on chinstrap was 3m4s
<Peng> mwhudson: Do graphs in the revgraph cache ever get mutated? If a new revision is added to the branch, is the graph regenerated from scratch?
<jam> so it doesn't seem to be network speed that matters at that point
<wadesworld> hi guys...looking for some advice...using the latest bzr, both myself and my colleague have expereienced bzr hangs when trying to merge from our shared repository....I went so far as to upgrade the shared repositories OS last night to see if it was perhaps a bug in OpenSSH
<mwhudson> Peng: yes, regenerated from scratch
<mwhudson> Peng: which is terrible
<mwhudson> jam: crowberry is fairly heavily loaded basically all of the time
<wadesworld> the symptom is, you type in your ssh passworld and bzr just sits there....been sitting there for 45 minutes now
<mwhudson> (crowberry == bazaar.launchpad.net)
<jam> mwhudson: hm... this won't be exactly identical as I have to go through 'openssh' to access chinstrap, rather than paramiko
<Peng> mwhudson: OK, thanks.
<jam> wadesworld: do you happen to be on Windows using plink as your ssh implementation?
<jam> (I expect not, but figured I'd start with that)
<Peng> Stupid question: does each thread have its own revgraph cache?
<wadesworld> nope...we're both on Macs, and the "server" is OpenBSD 4.6
<wadesworld> using sftp as the access method
<jam> wadesworld: generally sftp is slow, but I wouldn't expect indefinite hangs
<jam> are you sure it isn't doing a cross-format conversion?
<jam> (bzr info $REMOTE; bzr info $LOCAL should help tracking that down)
<wadesworld> positive, everything is 2a
<jam> mwhudson: ah wait, chinstrap *is* the forwarding host, right?
<jam> so I don't actually require a double connect
<mwhudson> jam: yes
<jam> mwhudson: chinstrap is a lot 'flatter' than crowberry, I'll upload in a bit
<jam> though also, this source is a freshly packed repo
<jam> rather than the organic version on lp:bzr
<jam> I may try to use lftp and see if that makes a difference
<mwhudson> jam: would be interesting to quantify the differences
<mwhudson> jam: the main ones i would suspect are (1) twisted.conch rather than openssh (2) system load on crowberry
<jam> mwhudson: quantify the diff between crowberry and chinstrap?
<mwhudson> jam: perhaps not the word i really meant
<mwhudson> understand
<mwhudson> and yes, difference in the details of the repo being served
<mwhudson> jam: did you say branching from staging was faster?
<mwhudson> the staging codehost is much less loaded than the prod once
<jam> mwhudson: I haven't tested download-to-local
<jam> I was going to try download from staging as part of all this
<jam> and just noted that staging => chinstrap was 3m+ while staging => vila's babune was 1m50s
<jam> which is probably local cpu load on the target machine
<wadesworld> hmm...actually, I just noticed something...this project was a conversion from CVS...it appears that it created a 2a branch at project, but it created another branch at project/branches/HEAD which has a format of "unnamed"
<jam> wadesworld: if you use 'info -v' I would guess you'll find the repo is the same format, but the Branch at HEAD is different
<mwhudson> jam: so yes measurements of identical repos from staging chinstrap and prod would be very interesting i suspect
<jam> this doesn't really matter for what you're doing
<jam> mwhudson: hmm... looks like paramiko versus openssh might also play a significant role
<jam> (locally)
<mwhudson> jam: oh
<wadesworld> yeah, HEAD is branch format 6, meta directory format 1
<wadesworld> was the "doesn't matter" comment direct at me or mwhudson?
<jam> mwhudson: well, it didn't make a big difference in the 'total time spent'
<jam> paramiko was actually slightly faster in that regard
<jam> 236s vs 240s
<jam> mwhudson: I've uploaded 2 more graphs
<mwhudson> jam: i'm not sure i have any time to spend on this today
<mwhudson> jam: happy to look when you have some conclusions though!
<servilio> hi! I am reading on how to track multiple svn branches of a project in one source tree from https://lists.ubuntu.com/archives/bazaar/2008q3/047779.html
<wadesworld> jam - should I run upgrade on HEAD?
<servilio> wouldn't it be the same to do a bzr pull for the main parent?
<servilio> instead of a merge, I mean
<jam> wadesworld: I think you can without any problems
<jam> wadesworld: doesn't matter is for you
<jam> servilio: I don't know why he is recommending 'merge', I would have thought "pull" would have been better
<jam> however, that is 2008, so it may just be old info
<servilio> jam: I know, that's the other reason for asking here
<jam> servilio: so *I* would say keep the branches pristine at those locations
<jam> and only run 'bzr pull'
<jam> and then do other things manually
<jam> however, from what I can tell
<jam> he is talking about merging a feature into the 'trunk' branch
<jam> and once you've done a local action
<jam> you can no longer 'pull'
<jam> you have to 'merge'
<servilio> jam: the source tree wouldn't contain any changes, is a hosting location
<jam> servilio: if you are just tracking 'trunk' and not doing any local changes, I'm pretty sure 'bzr pull' is what you want
<servilio> jam: great, thanks! will give it a test
<jam> mwhudson: interestingly, things are looking pretty shoddy with the 'real-world' repo from chinstrap
<mwhudson> jam: aha!  your problem :)
 * mwhudson runs away dodging to avoid the gunfire
<jam> mwhudson: :)
<jam> mwhudson: lots of "245.277  creating new compressed block on-the-fly" lines in .bzr.log on chinstrap
<wadesworld> as predicted, rununing upgrade on HEAD had no effect - bzr merge still hangs
<jam> wadesworld: right, the only change I would expect is that 'bzr info' will show you 2a now
<wadesworld> yep
<MTecknology> launchpad source code was only recently released publicly
<MTecknology> ^wrong chan
<wadesworld> still hanging as soon as I enter my password after bzr merge though :(
<jam> wadesworld: just to confirm 'bzr info' locally also says 2a, right?
<wadesworld> correct
<MTecknology> I'm going to start a pretty big project. I plan to have a core branch then sub branches for each "module". For example, the core will only check if a module exists if the page is requested. If the module exists then it's loaded. I want different users working on each of these modules. I think LP is organized dlike this, but I have no idea how to setup branches liek this. The last I knew, bzr can handle these types of branches.
<MTecknology> Any suggestions how to setup branches like this?
<jam> MTecknology: well, if you just do "bzr init" in the subdirectories first, things generally work ok
<jam> but in the parent tree it will show as "unknown" and not let you add them (though you can ignore them)
<jam> you may want to look at the project 'scmproj'
<jam> which is an initial attempt at making something like "bzr checkout" grab all of the branches needed, and build the whole collection
<jam> there is also "bzr-externals" though that code base is quite new
<MTecknology> jam: when I make a commit on the parent, will that commit all the changes in the others or just parts required to pull?
<MTecknology> I think bzr-externals is what I heard of
<jam> MTecknology: I'm pretty sure scmproj uses a "project-commit" to do a recursive commit
<jam> bzr-externals was just announced ~last week
 * GaryvdM is away: I'm sleeping
<MTecknology> stu mentioned something a while ago about it
<MTecknology> jam: is bzr-externals something I could use with launchpad?
<MTecknology> jam: I'm looking at this - http://bazaar-vcs.org/NestedTreesDesign
<jam> MTecknology: I'm pretty sure both bzr-externals and scmproj can be used with Launchpad, I think they mostly define stuff as regular branches
<jam> MTecknology: NestedTrees is not fully implemented
<jam> It may get specific priority in the next 6 months, depending on how it relates to some of the other stuff we are working on.
<MTecknology> ok, thanks :)
<MTecknology> iteresting...    michael@panther:~$ aptitude search bzr
<MTecknology> Bus error
<MTecknology> this is wierd.......
<jam> I wouldn't have expected that from aptitud
<MTecknology> jam: even after reboot.... and aptitude update - trying to upgrade w/ apt-get :S
<wadesworld> jam any suggestions on other help I might get for troubleshooting this merge hang?  I copied my local repo over to a completely different machine and still get the same hang....should I file a bug or hit a developer mailing list?
<MTecknology> !info bzr-externals
<ubottu> Package bzr-externals does not exist in karmic
<jam> wadesworld: you said you are using sftp, rigth?
<jam> I would make sure that you can sftp data off that machine
<wadesworld> correct
<jam> MTecknology: given that bzr-externals is < 1 week old
<jam> I'm sure it hasn't been packaged yet
<jam> bzr branch lp:bzr-externals should get you the code, though
<jam> mkdir -p ~/.bazaar/plugins
<jam> bzr branch lp:bzr-externals ~/.bazaar/plugins/externals
<jam> *I* have not audited the code, etc. And given its age, I wouldn't trust it a whole lot yet
<wadesworld> jam...the hang is only happening on a merge...bzr branch/pull with sft work fine
<wadesworld> er, sftp
<MTecknology> jam: thanks - I'll try it soon
<wadesworld> and push works fine too
<jam> wadesworld: well, then a workaround is "bzr branch sftp://... temp; cd trunk, bzr merge ../temp"
<pickscrape> Is it possible to get back the message of a commit that failed without having to type it in all over again?
<jam> merge not working is quite strange
<jam> pickscrape: given that you're asking, I'd probably say no
<wadesworld> agreed - that's what we've done so far - but I'm just trying to figure out who can help me get to the bottom of it
<jam> some things like 'qcommit' stash the message and try to use it again
<jam> wadesworld: you can try starting merge
<jam> and then doing Ctrl+|
<jam> to interrupt the process, which should drop you into a debugger
<jam> and then you can do "bt" to get a backtrace to see what it thinks it is trying to do
<jam> The only problem is that ^| may interrupt the ssh connection
<jam> (It is SIGQUIT)
 * pickscrape adds to the "MyTopUiComplaints" page
<mwhudson> poolie: mildly curious why you nominated me as a reviewer on https://code.edge.launchpad.net/~mbp/bzr/remove-logging/+merge/14942
<wadesworld> jam http://pastebin.org/54668
<poolie> because it might break your integraiton
<thumper> who is working on the daily ppa builds?
<poolie> if you don't rely on logging, no problem
<jam> wadesworld: that would hint that we may be trying to open a directory as a file, and your sftp server is letting open it, but not return any content
<thumper> or 2.1b3 into the beta ppa?
<jam> which is a bit strange
<jam> thumper: dailies are from james_w I though
<jam> thought
<jam> johnf is doing the releases
<jam> but IIRC has not built any of the 2.1 releases
<jam> because of concerns about getting a coherent set of plugins into the ~bzr-beta-ppa
<wadesworld> hmm...that actually makes a little sense, since the sftp server is the only commonality in the problem
<poolie> jam: it's ctrl\
<jam> poolie: sure, though whatever it is worked for wade :)
<jam>  \ and | are on the same key at least
<wadesworld> hmm...I was hoping for a permissions problem, but don't see anything obvious...still looking
<wadesworld> strange that pull works though and merge doesn't - one would think they would use the same sftp functionality
<jam> wadesworld: I'm not positive if pull allows 'mergeables' which would be a bundle, and thus a file to read
<jam> I thought it did, though
<jam> the underlying sftp implementation is identical for sure
<jam> wadesworld: so looking at the code, both call read_mergeable
<jam> wadesworld: one possiblity is to do "bzr merge" rather than "bzr merge location"
<jam> as if you don't supply a location, we don't try to read mergeable
<jam> which may be why "bzr pull" is working for you
<jam> since I assume you did "bzr branch $location" at some earlier time
<jam> and then just plain "bzr pull" to update it
<jam> can you try "bzr pull $location" ?
<jam> wadesworld: ^^
<wadesworld> sure thing - and you're correct
<bpierre> Hi
<jam> wadesworld: so I think we've seen this in the past...
<jam> and we had a workaround that if the path ended in '/' we wouldn't try to read it as a file
<jam> but that code path got updated
<jam> and people thought that was hackish, etc.
<jam> and apparently nobody has been using sftp as much recently
<bpierre> I'm trying to debug one of my plugins, and even when using -Derror, not all stack traces get outputted to stderr, is this normal?
<jam> hmm.. that said, everything works here even with sftp
<jam> bpierre: I would think that with -Derror things should get written, however I wouldn't say it always works
<bpierre> so it's a bug?
<jam> bpierre: I don't know the details, but sounds like one
<bpierre> jam: I modified it like this: http://pastie.org/703349
<jam> bpierre: I'm not sure that "print exception(..." is the same as displaying the traceback. I'd have to dig into the code a bit more to understand your patch
<wadesworld> jam, you're right - it appears that bzr pull $location is suffering the same hang
<bpierre> this move the code from 'report_user_error' to 'report_exception'
<bpierre> I'll make a merge request, and we'll see
<jam> bpierre: did it give you the tracebacks you expected?
<jam> wadesworld: I'll note that I'm unable to reproduce the hang here
<jam> are you on Mac?
<jam> (I think I remember that)
<wadesworld> yep
<jam> I tried paramiko, and openssh as the local connection
<jam> both worked
<wadesworld> happens on both my Intel Mac and PowerPC Mac
<jam> my old laptop used to be a Mac PPC
<jam> so it may be something with mac's openssh
<jam> well, whatever ssh they use
<jam> though I would have thought the server would matter more than the client
<wadesworld> openssh
<jam> wadesworld: try "export BZR_SSH=paramiko"
<jam> and then try again
<wadesworld> OK
<jam> bzr pull $location
<bpierre> bpierre: yes
<bpierre> ...
<bpierre> must be tired, obviously I meant to respond to you jam!
<wadesworld> appears to not have any effect...one thing I can do later tonight is copy the shared repo on the server over to a different box running Ubuntu rather than OpenBSD and see if that makes a difference
<jam> wadesworld: so the *server's* sftp implementation would make a lot of sense
<jam> my server is a really old FC3 box running OpenSSH_4.2p1
<jam> please report a bug about sftp trying to read a directory as a file
<jam> and include your ssh implementation versions
<jam> we might just restore the old "if this really looks like a dir, don't try it" code path
<wadesworld> Ok, will do
<jam> but I remember abentley objecting because "http://.../" could be a file
<jam> even though, we actually try to read from ".../foo" always in the current code path
<jam> (rather than .../foo/)
<wadesworld> hmm...there's no call to determine if it is a dir before trying to read?  (I guess not, or you would have used it)
<jam> bpierre: ahh, I see the issue. The formatting of your patch hid the '_' from me
<jam> print_exception does indeed print the traceback
<jam> do you have apport installed?
<jam> looking at the code
<jam> IOError, KeyboardInterrupt, and MemoryError are never given full tracebacks
<jam> and report_bug which is the catchall for unknown errors
<jam> will try to use apport first
<jam> and then falls back to showing a traceback, etc.
<jam> bpierre: so you may want to clarify the bug with "when a plugin raises IOError" or something like that
<jam> depending on what exception you are actually getting.
<spiv> wadesworld, jam: IIRC, BSDs tend to allow you to open directories as if they are files
<jam> spiv: which is fine, as long as trying to read them would return something other than a hang
<spiv> The results are rather nonsensical, but the open syscall doesn't actually fail.
<jam> if it raised an error
<jam> or returned no content
<jam> but this seems to just hang indefinitely
<spiv> Yeah, that's odd.
<jam> spiv: I thought you could always open() a directory, since that lets you fchdir()
<spiv> Well, I've also seen read on the opened directory work.
<wadesworld> I'll file a bug tonight with complete details - I'm also happy to give whomever works it access to my server for testing
<jam> spiv: orig_dir_fd = open(".", O_RDONLY, 0) is what we do in _readdir_pyx.pyx
<jam> so it better work :)
<spiv> "work", in that it gave the on-disk representation of the directory!  But my first-hand knowledge of BSDs is rather old.
<jam> wadesworld: mua ha ha
<jam> spiv: well, that would be fine too, as we would realize right away that it wasn't a bundle
<wadesworld> thanks so much for your help jam - I'll file the bug tonight
<wadesworld> this has really been hurting my efforts to bzr-convert my colleague :)
<jam> wadesworld: also, if you could give the result of something like manually doing
<jam> sftp host
<jam> get directory
<mwhudson> bugs like https://bugs.edge.launchpad.net/launchpad-code/+bug/484197 make me want to cry
<ubottu> Launchpad bug 484197 in launchpad-code "Branches stacked on another project report errors" [Undecided,New]
<bpierre> jam: ok, done: https://code.launchpad.net/~benoit.pierre/bzr/fix-error-debug-flag/+merge/14971
<bpierre> thanks
<jam> mwhudson: I've shed my tears for stacking. Now I just soldier on
<mwhudson> jam: probably wise
<jam> bpierre: I'm pretty surprised that ValueError wasn't being reported correctly.
<jam> also, your patch is going to cause double-tracebacks in some cases
<jam> so I don't think it is quite the right answer
<bpierre> which cases?
<jam> bpierre: noted in a review of your patch
<jam> bpierre: I'm pretty sure that report_bug(exc_info, err_file) always displays the traceback
<jam> def report_bug_legacy(exc_info, err_file):
<jam>     """Report a bug by just printing a message to the user."""
<jam>     trace.print_exception(exc_info, err_file)
<jam> so if you don't have apport installed
<jam> we always print the exception traceback
<jam> I realize this is only with -Derror, but it is still a bit ugly to see it twice
<bpierre> but report_bug is not going to be called, no?
<bpierre> I do return before the bulk of report_exception's body, where different functions get called depending on the type of exception
<bpierre> or am I missing something obvious?
<poolie> igc, hi, good morning?
<lifeless> poolie: call over?
<jam>  bpierre, then I'd have to review your code more thoroughly. I should have stopped working 15 min ago
<bpierre> :)
<jam> bpierre: I would quickly caution that I don't think print_exception calls log_exception_quietly which dumps the data into .bzr.log
<jam> which I think we want
 * jam runs away
<mwhudson> um, sanity check please? http://pastebin.ubuntu.com/321152/ <- this is insane, right?
<spiv> mwhudson: that does seem crazy, and I can reproduce using lp:subvertpy
<spiv> mwhudson: bug report please :)
<spiv> mwhudson: at a quick guess it's pushed the working tree with tip's contents, but then set the parent revids correctly.
<mwhudson> spiv: yes, the wts are the same
<spiv> Yeah, and diff -r tag:subvert-0.7.0.. gives the same diff as found in the new tree
<mwhudson> spiv: push -r3 is even stranger
<mwhudson> spiv: https://bugs.edge.launchpad.net/bzr/+bug/484516
<ubottu> Launchpad bug 484516 in bzr "bzr push -r $revspec ../foo creates branch with working tree from tip, not that of $revspec" [Undecided,New]
 * mwhudson upgrades things
<mwhudson> oh good (?) it happens with everything upgraded to 2a too
#bzr 2009-11-18
<igc> morning
<mwhudson> lifeless, spiv : how close is lp:~spiv/bzr-builder/refactor to landing?
<spiv> mwhudson: hmm
<mwhudson> also, what does it do?
<lifeless> mwhudson: james_w needs to get back from UDS :)
<mwhudson> lifeless: that makes sense i guess
<spiv> mwhudson: that branch has some simple refactoring on top of lp:~lifeless/bzr-builder/bug-469874 that is used by lp:~spiv/bzr-builder/merge-subdirs-479705
<mwhudson> sounds like a fun stack of not-landed branches
<spiv> mwhudson: basically a replaces a list of 2-tuples where (*, None), (None, *) and (None, None) all mean different things, and replaces them with objects
<spiv> mwhudson: and replaces case statements about that with good ol' polymorphism
<lifeless> mwhudson: why do you ask?
<mwhudson> lifeless: just poking at bzr-builder
<spiv> The names I gave to the objects and methods can be improved, but the shape is certainly much nicer (and made merge-subdirs-479705 fairly straightforward).
<spiv> Hmm, I guess I should make some merge proposals for those, not sure why I hadn't done that yet.
<lifeless> spiv: you get to use the new dependent branches feature ;)
<Kamping_Kaiser> does bzr have something like gits add --interactive? (allows commiting chunks of your current diff)
<spiv> lifeless: indeed :)
<spiv> Merge requests filed.  That should keep james_w busy for a while :)
<spiv> Kamping_Kaiser: "bzr shelve", you can shelve the parts you don't want to commit yet, then bzr commit, then bzr unshelve.
<Kamping_Kaiser> spiv: thanks, I'll have a go
<poolie> igc: still around?
<poolie> hi spiv, mwh
<mwhudson> poolie: hello
<Kamping_Kaiser> spiv: that works a treat, thanks.
<lifeless> spiv: so you proposed the branch to my branch, not to trunk?
<lifeless> spiv: oh nevermind, LP confused me
<poolie> !!!
<poolie> :-)
<lifeless> yeah, news @ 11
<bob2> lol
 * GaryvdM is back (gone 07:00:57)
<RenatoSilva> is there a way to bzr diff all non .xyz files?
<bob2> you can use filterdiff (not part of bzr)
<RenatoSilva> ok thanks anyway
<tumbleweed> so, I've got a bot that's polling bzr branches on lp, and I'm getting RevisionNotPresent exceptions sometimes http://paste.pocoo.org/show/nHK9f5k22Vt40innuE6i/
<tumbleweed> code in question: http://bazaar.launchpad.net/%7Estefanor/ibid/icecast/annotate/head%3A/ibid/plugins/bzr.py
<tumbleweed> should I just ignore the exception and try again in a bit?
<lifeless> tumbleweed: yes, I guess.
<MvG> Hi! Trying to push a branch to lp failed at fist try ("different serializers") but succeeded at second try: http://pastebin.com/m27e603bb
<MvG> Is this a bzr issue or a launchpad issue?
<Peng> That's clever! The failure on the first push leaves enough around that the second push doesn't try to auto-stack. I'll have to remember that!
<Peng> MvG: *Probably* a bzr bug, but I'm not going to set something equivalent up off-LP to verify it.
<Peng> Note to self: File a bug about stacking being broken on staging...
<MvG> So basically it is known current behaviour that auto-stacking doesn't work (due to some difference in repo formats?), and the fact that it worked the second time is more like a bug? Should I file anything?
<Peng> MvG: What format is your local branch? If it's 2a, than yes, it's known behaviour that stacking fails.
<Peng> MvG: Err, I mean, *not* 2a.
<MvG> Format is 2a, according to "bzr info ..", where .. is the shared repository.
<Peng> MvG: Oh, my mistake. You're using 2a, but lp:~trac-bzr-team/trac-bzr/trunk is on an older format.
<Peng> MvG: What happened is that the first push created some of the control directories before it realized the format difference and exited. On the second push, since they existed, it didn't try to stack, so you didn't run into the format issue.
<MvG> I understand.
<Peng> MvG: Umm, I think it's worth filing, although I'm not sure it's worth fixing. :P
<MvG> OK. will do so.
<MvG> Peng: How do you tell lp:~trac-bzr-team/trac-bzr/trunk is older format? bzr info doesn't seem to help me there.
<Peng> MvG: The error message said it was a KnitPackRepository. 2a is CHKInventoryRepository.
<MvG> Ah, I see.
<Peng> MvG: FYI, in bzr.dev, "bzr info -v" gives useful format information for branches accessed over the smart server.
<Peng> MvG: In older versions, you can prepend "nosmart+" to the URL to force VFS access, e.g.: bzr info nosmart+lp:~trac-bzr-team/trac-bzr/trunk
<Peng> MvG: (I mean, you can do it in bzr.dev too, you just don't need to...)
<MvG> All of these give me info about the branch, but not about the repository format...
<Peng> MvG: It included all of it.
<MvG> In the Format section it says "repository: bzr remote repository"
<MvG> Ah, works now...
<MvG> Had been using an older bzr setup here without realizing it...
<MvG> filed https://bugs.launchpad.net/bzr/+bug/484685
<ubottu> Launchpad bug 484685 in bzr "Failed auto-stacking on first push from 2a branch with non-2a trunk" [Undecided,New]
<Glenjamin> hi guys, after running the bzr check command, i'm told there are ghost revisions and inconsistent parents
<Glenjamin> is there a way to resolve these somehow?
<Glenjamin> did those messages get blocked by the network for not being registered?
<bob2> no
<Glenjamin> ah good, the freenode error message isn't all that clear :)
<bob2> 'bzr reconcile' should fix the inconsistent parents, I think (backup your branch/repository first)
<Glenjamin> right, is there anything i can do about ghost-revisions? (and what are they?)
<Peng> Glenjamin: Ghosts are revisions that your repo doesn't actually have a copy of.
<Glenjamin> i was having issues with bzr-svn in a 2a repository
<gioele> Glenjamin: what kind of branch is that? A git or svn import?
<Glenjamin> i started again with 1.14-rich-root and it seems fine now
<Glenjamin> i did checkout(from svn) branch(locally) push(to svn), and it have an error about parent revisions
<gioele> Glenjamin: is it happening every time?
<Glenjamin> it was with the 2a format, yes
<Glenjamin> cheers for the help guys :)
<bialix> hi, any core devs here?
<spiv> I half am
<bialix> ho! spiv!
<bialix> hello spiv
<bialix> I have 2 problems
<spiv> Good evening :)
<bialix> for you evening, for me afternoon :-)
<bialix> 1) We have a problem with reconfigure of light checkout of bzr:// branch
<bialix> spiv: I've fwd'd mail from qbzr ML about this problem
<bialix> spiv: if you have any ideas how to debug this problem I'll be very appresiated
<bialix> spiv: if you have any ideas how to debug this problem I'll be very appreciated
<bialix> 2) it seems 2a (or rich-roots) broke merge -r0..-1 when files have the same file-id
<spiv> 1) Interesting!  That seems quite weird.
<spiv> As for 2), I would have expected that would get conflicts with or without 2a, or does it fail worse than merely conflicting?
<bialix> spiv: 2) doesnot happens with pack-0.92 aka poor-rootsz
 * bialix pastebins
<bialix> spiv: see Makefile: http://pastebin.com/m1324b1ae
<bialix> spiv: with 2a format I've got path conflict
<bialix> with pack-0.92 I've got good merge
<bialix> and with rich-root-pack too
<bialix> rich-rot-pack -> conflict
<bialix> bug https://bugs.launchpad.net/bzr/+bug/484706
<ubottu> Launchpad bug 484706 in bzr "merge 2 unrelated branches in rich-root format cause path conflict for the same file-id" [Undecided,Confirmed]
<spiv> Yeah, I think it's a rich-root thing.  I think a conflict is reasonable in that case, I'm not sure why non-rich-root wouldn't conflict (in fact I'm tempted to think that's the bug, not the rich-root case).
<spiv> I don't see a good reason for it to be inconsistent, so there's certainly some sort of bug there.
<bialix> spiv: I think non-rich-root behavior is *right* actually
<bialix> there is good reason to split big branch into 2 and then merge between them
<bialix> spiv: if you have any ideas about 1) I'd like to get some hints
<spiv> Well, I cna see an argument for allowing it, for the same reason we treat a merge that applies the exact same change as being clean.
<spiv> I don't have a strong opinion either way, but my initial expectation was that it should conflict.
<bialix> spiv: all this file-ids thingy is good only for 1 reason -- to track renames. But there is a lot of other reasons when file-ids only bad thing
<bialix> parallel imports et al
<spiv> And if the content isn't identical it certainly should.
<bialix> should -> what?
<spiv> Should conflict.
<bialix> if content is not identical it produce text conflict (for pack-0.92 format) and this is very good
<bialix> but path conflict is not good
<spiv> For 1), I think I see the bug in remote.py
<spiv> It doesn't look like RemoteRepositoryFormat.initialize copes properly with a non-RemoteBzrDir argument, even though there's some code to try handle that case.
<spiv> It's getting late here, but I'll send an email summarising what I see.
<bialix> ok, thanks
<RenatoSilva> is there any work/registered idea anywhere about "semantic/smart" diffs?
<RenatoSilva> for example, diff ignoring white spaces
<RenatoSilva> another example, CSS diff
<bob2> already possible
<bob2> bzr diff --using=whatever
<bob2> '--using=diff --diff-options=-w' will ignore whitespace
<RenatoSilva> great :) but that's just an example
<bob2> sure
<bob2> if a semantic css diff program exists, bzr can use it
<RenatoSilva> I have had trouble with comparing css, and I thought it would help me if the diff algorith was "smart"
<RenatoSilva> bob2: ok I'm being sort of offtopic because I don't know a right channel to ask, as the subject is cross-channel
 * RenatoSilva trying to remember a use case for a "semantic" css diff
<RenatoSilva> * recall
<RenatoSilva> hum, ordering, for example p {\n color: #333;\n margin: 0px; \n} should be considered the same as p {\n margin: 0;\n color: #333;\n}
<spiv> bialix: sent
<spiv> RenatoSilva: sure, but bob2's answer still seems applicable
<RenatoSilva> this becomes annoying when you have a lot of stuff like this and among these lines only 1 or 2 that really matter
<RenatoSilva> spiv: ok sorry, will stop now :)
<spiv> RenatoSilva: that is, bzr can already cope with that, you just need to tell it to use a diff program that knows how to do the diff you want.
<spiv> And if that diff utility doesn't exist yet that isn't exactly a bzr issue :)
<spiv> (Although if there's some way in which bzr might help, then that would be worth discussing, but from what I see so far probably not)
<spiv> Anyway, bedtime for me.
<RenatoSilva> spiv: ok, actually I want those programs, which I'm afraid to exist
<RenatoSilva> I'm afraid to not exist
<bialix> spiv: many thanks
<jam> morning all
<bialix> hello jam
 * bialix akways enjoys reading jam's articles
 * beuno remembers jam's "this week in bazaar"
<jam> beuno: blame statik, he left me and TWiB fell apart
 * beuno looks at statik with disapointment
<bialix> beuno: ya, this week journal was very cool
<henninge> Hi! I am using bzr-pipline for the first time.
<jam> wadesworld: ping if you get some time to help debug the sftp stuff
<henninge> I had made some changes in the last pipe and then switched to another pipe w/o committing the changes.
<henninge> Now show-pipeline displays the "U" next to this pipe.
<henninge> I returned to that pipe (so show-pipeline show "*U") but I don't see the uncommitted changes, at least not with "status" or "diff". Do I need to restore them somehow?
<gioele> henninge: try "bzr shelve --list", maybe the uncommited changes have been shelved
<henninge> gioele: "No shelved changes"
<henninge> gioele: rockstar also explained to me last week that pipelining is different from shelving.
<rockstar> henninge, bzr unshelve
<rockstar> henninge, when you change to another pipe, bzr automatically shelves the changes for you.
<henninge> rockstar: but does not automatically unshelve when I return?
<jam> henninge: I believe that is true
<gioele> rockstar: but "bzr shelve --list" says that there is nothing to unshelve
 * henninge hasn't used shelve/unshelve before either
<jam> switch-pipe shelves but does not unshelve
<rockstar> henninge, so shelving is part of pipelines, but last week, the discussion was about shelving doing the same as pipelines, which is untrue.
<jam> partially because "bzr merge --uncommitted ..." is able to pull stuff out of the shelf
<henninge> ah
<rockstar> henninge, I use shelves when I have some changes I'd like to keep instead of revert, but I need to commit something else before I commit those changes.
<rockstar> It's kind of like limbo for changes.  Not heaven or hell.
<henninge> rockstar: bzr unshelve also says, there is nothing on the shelve.
<henninge> rockstar: ;)
<rockstar> henninge, when you do bzr pipes, what does it say?
<rockstar> Er, bzr show-pipeline
 * rockstar always forgets that he has aliases
<henninge> pipes works, too ...
<henninge> rockstar: "*U pipename"
<rockstar> henninge, and bzr status
<henninge> rockstar: nuttin'
<rockstar> abentley, ^^
<henninge> rockstar: I have to say that I added and deleted a pipe and had a conflict which I resolved
<rockstar> henninge, that shouldn't affect your changes that should have been shelved.
<rockstar> henninge, I must consult the pipeline gods.
<abentley> jam: switch-pipe also unshelves.
<henninge> I also tried "merge --uncommitted" (because I read that in the help somewhere) and it failed
<rockstar> abentley, I thought it did.
<jam> abentley: would make sense to be symmetric
<jam> what if you have multiple shelved patches?
<jam> just the last one?
<abentley> jam: There's only one.
<rockstar> abentley, it sounds like something's wrong with how changes got shelved.
<jam> abentley: so 'bzr shelve' doesn't interact with the actual 'shelf' that is being used?
<henninge> here is the failure: http://paste.ubuntu.com/321609/
<abentley> jam: Indeed.
<henninge> oh, that is mostly explanatory text
<abentley> jam: The shelved changes are stored in the branch, not the working tree.
<rockstar> Ah, that's clever.
<rockstar> So bzr unshelve shouldn't actually unshelve the changes.
<henninge> here is the crash file: http://paste.ubuntu.com/321612/
<abentley> rockstar: Right, and I also try to avoid referring to it as shelving.
<rockstar> henninge, try switching away from the pipe and switching back.
<rockstar> abentley, yes, I can see why now.
<abentley> henninge: doing "switch-pipe" to return to the pipe with the stored changes should restore them.
<abentley> henninge: The crash you're getting is because you didn't specify a pipe to merge from.
<henninge> rockstar: yup, that helped
<rockstar> henninge, so it's working now?
<henninge> rockstar: yes, bzr status show my changed files again
<henninge> show
<henninge> s
<rockstar> henninge, great
 * rockstar scurries off to find a quiet hacking place
<henninge> rockstar: thanks
<henninge> rockstar: go to your room!
<henninge> ;-)
<henninge> abentley: thanks, too.
<abentley> henninge: I have filed bug #484846 about the merge issue.
<ubottu> Launchpad bug 484846 in bzr-pipeline "pipeline dies when location is not specified with merge --uncommitted" [Undecided,New] https://launchpad.net/bugs/484846
<abentley> rockstar: btw, "pipes" is an automatic alias for show-pipeline now.
<rockstar> abentley, hooray!
<abentley> henninge: Is it possible that when you originally returned to the pipe, you used "switch", not "switch-pipe"?
<rockstar> abentley, actually, I found out last week that basically everyone at the lazr-js sprint using pipes were using my aliases.  I thought about submitting a patch to make those aliases official.
<abentley> rockstar: Well, I'm not sure about all of them, but just submit your aliases and I'll look them over.
<henninge> abentley: "history | grep switch" only return switch-pipe ...
<henninge> rockstar: pdiff and pstatus? Very useful.
<rockstar> abentley, cool.  Well, now that I see the aliases I use, they shouldn't all go up, but EVERYONE was using next and prev.
<rockstar> ...as well as pipes, which is now upstream anyway.
<henninge> rockstar: where do I find "your" aliases?
<abentley> henninge: Okay, I'll look into why it didn't restore the changes.
<abentley> rockstar: I don't get "next" and "prev".  I use switch-pipe :last at least as often as switch-pipe :next.  So I've aliased "switch-pipe" to "swp".
<rockstar> henninge, http://theironlion.net/blog/2009/08/26/5-must-have-aliases-bzr-pipeline/
<rockstar> I have a few more now, but they aren't anything special.
<rockstar> And send-pipe is silly to have now anyway, since Launchpad ignores the bundle you send through email now.
<rockstar> abentley, maybe there should be a bzr last then as well.
<abentley> rockstar: Anyhow, "next" and "prev" can't be automatic aliases.  Only command name abbreviations can be automatic.  But they could go in "help pipelines".
<rockstar> abentley, ah, yeah.  You're right.
<rockstar> abentley, okay, so it's more a doc patch now.  I can live with that.
<abentley> rockstar: It doesn't ignore the bundle.  It just has a tendency to fail to apply it correctly.
<abentley> rockstar: i.e. to give an incomprehensible oops.
<rockstar> abentley, well, as far as the UI is concerned, it ignores it, because the preview diff is what's displayed.
<rockstar> abentley, it's a moot point with pre-req branches though.
<abentley> rockstar: The diff was never part of the bundle, it's part of the merge directive.
 * rockstar facepalms
<rockstar> That's what I meant.  I blame UDS and lack of sleep.
<abentley> rockstar: actually, I tell a lie.  In bundle format 0.9 and earlier (bzr 0.18 and earlier), the diff *was* part of the bundle.
<abentley> rockstar: Anyhow, there's a new lp-submit in the very latest pipelines that uses the LP API to create merge proposals.
<abentley> rockstar: You get prerequisite branches automatically.
<rockstar> abentley, wonderful.
<rockstar> abentley, and the diff is generated correctly?
<abentley> rockstar: Yes.
<rockstar> Niice!</borat>
<Peng> Is there a 2a copy of MySQL somewhere for those too impatient to spend 2 days converting it? :D
<henninge> abentley: I have another crash for you ... http://paste.ubuntu.com/321629/
<Peng> (I don't really care what branch; I just want it for testing.)
<brmassa> guys, show can i create a patch between 2 revisions?
<Peng> brmassa: What for?
<abentley> henninge: Your bzr C extensions are not up to date with your bzr.
<henninge> abentley: how do you see that and how do I fix that?
<abentley> henninge: You're running bzr from a package, right?  If so, only the packager can fix it.
<henninge> abentley: from the nightly ppa.
<brmassa> Peng: well... i created a branch for each x.x.x, 1.x.x and 1.1.x version of my app. now i submited some some to the minor branch (1.1.x), i want to generate a patch to apply into higher levels/versions
<abentley> henninge: I know that it's a C extension problem only because I've experienced it myself, and since I run from source, I did "make" and it fixed it.
<henninge> Woa! bazaar-vcs got a new look!
<Peng> brmassa: You should have done it the other way around so you could "bzr merge".
<Peng> brmassa: Make the change to the oldest branch, then "bzr merge" it into the newer branches.
<abentley> jam: henninge's running from the nightly PPA, but his StaticTuple is incompatible with his bzr.  Who takes care of that packaging?
<jam> Peng: I don't believe there is. I think they've talked about upgrading, and I believe 'drizzle' has switched to 2a, but I'm not sure if drizzle is the full mysql history, etc.
<abentley> henninge: Perhaps you can switch to the bzr beta PPA temporarily?
<jam> abentley: the daily just needs to be rebuilt, there was a fix for that which has been around since 2.1.0b3
<jam> I thought james_w was doing dailies
<jam> afaik, none of the 2.1 series was built into bzr-beta-ppa
<jam> johnf didn't have enough tuits
<Peng> jam: Thanks.
<abentley> jam: I suspect james_w will be busy this week...
<henninge> abentley: that is not 2.1 yet, I tried that first. bzr-pipeline only works with 2.1, so it told me ...
<Peng> jam: MySQL's history is about 2000 revisions longer than Drizzle's, so I guess it doesn't. Darn.
<henninge> abentley: I am running bzr-pipeline from source
<brmassa> Peng: well... at one point all 3 branches were the same, but since 1.1.x is focused on bug fixing only and the other 2 includes new features, the codes might diverge...
<henninge> maybe I should just run bzr from source, too
<abentley> henninge: lp:bzr-pipeline/stable works just fine with 2.0
<jam> Peng: well, you really need to compare via "bzr ancestry" and not "bzr revno"
<jam> but yeah, they might have started with a fresh codebase
<henninge> abentley: ah, I could change that
 * Peng didn't know about "bzr ancestry".
<Peng> jam: Ehh, true.
<Peng> brmassa: OK, um, commit your changes to the bugfix branch, then "bzr merge" that branch into your newer branches.
<jam> brmassa: you can alwyays do "bzr diff -c REVNO" or "bzr merge -c REVNO", or .. create a daggy fix as Peng mentions
<brmassa> thanks guys... its just matter of getting used to the commands and concepts.
<Peng> "bzr merge -c" does a cherrypick?
<CoffeeIV> how can I tell what will change from a bzr up command before actually doing it ?  bzr up doesn't seem to take the --dry-run option
<brmassa> Peng: its working. now, is there a way to use the same commit messages used in the original branch while commiting the merge?
<brmassa> of course without manually writting it...
<Peng> brmassa: You can copy and paste... :D
<brmassa> Peng: yep. i was wondering about a parameter to to this automatically
<skx> what do I need to install to get bazaar explorer? I'm on ubuntu
<skx> got it
<skx> wow, you really managed to hide that info ;)
<LarstiQ> we did?
<Peng> Augh! "bzr pull" on MySQL died after almost 2 hours and 200-300 MB of bandwidth, losing all of hte progress it had made! :(
<mrooney> hey, I ran into an initially confusing situation, I just wanted to see if it was a bug or expected behavior
<mrooney> if I have a directory under VC foo, and I do bzr mv foo bar/baz when bar doesn't exist, I get the error "bar is not versioned"
<mrooney> so I spent a while trying to figure out what that means, because it was obvious to me it wasn't versioned since it doesn't exist
<LarstiQ> mrooney: while correct, I agree
<LarstiQ> "bar doesn't exist" would be more helpful
<mrooney> yes it would have been much more helpful
<LarstiQ> mrooney: mind filing a request for that?
<mrooney> sure
<LarstiQ> thanks
<mrooney> it would be great if there was an option to create the directories if needed
<mrooney> I keep hitting it over and over when restructing projects, "oh this file needs to be in a directory"
<LarstiQ> what kind of restructuring is that?
<LarstiQ> in my use I usually need a directory when I have multiple files already
<mrooney> what is your fear of automatically creating directories? people typoing a mv when they expect the dir to exist, and silently getting a new one?
<LarstiQ> I haven't thought it through
<LarstiQ> but my fear is overloading mv even more than it already is
<mrooney> any sort of cleaning up a project, where I accumulate too many files in a directory and want to mv them to new directories
<LarstiQ> mrooney: do you move more than one file at once to a directory that doesn't exist?
<mrooney> it isn't obviously that painful to bzr mkdir first, it is just a thing I have to keep in my head
<LarstiQ> right
<mrooney> no just one in these cases
<LarstiQ> mrooney: it's an alien proces to me :)
<LarstiQ> mrooney: how would the ui look?
<mrooney> the ui?
<LarstiQ> mrooney: of mv making dirs that don't exist
 * LarstiQ checks mkdir -p behaviour
<LarstiQ> mrooney: so one question that arises
<LarstiQ> mrooney: `bzr mv file non/existing/path`
<LarstiQ> mrooney: would that be non/existing/path/file or non/existing/path ?
<LarstiQ> hi LenzGr
<LenzGr> Hi!
<mrooney> LarstiQ: haha yes, that is ambiguous, I assume it becomes non/existing/path unless you did bzr mvfile non/existing/path/
<mrooney> I'd follow 'mv' there
<mrooney> though mv doesn't have a -p option like mkdir does
<LarstiQ> mrooney: right
<mrooney> LarstiQ: I got bug 484985 for you :)
<ubottu> Launchpad bug 484985 in bzr "bzr mv'ing something to a folder which doesn't exist results in unspecific error" [Undecided,New] https://launchpad.net/bugs/484985
<LarstiQ> mrooney: thank you :)
<mrooney> that would definitely at least make it obvious to the user what they need to do
<ibrandt> Greetings All.  I'm having an issue with bzr join.  I started a repo in /etc/httpd some time back.  Now I'd like to version /etc as a whole.  I ran bzr init in /etc, and added and committed everything but /etc/httpd.  Now I'm trying to join /etc/httpd by running bzr join httpd from the /etc directory.  I get "bzr: ERROR: An inconsistent delta was supplied involving u'httpd', 'tree_root-20091113022148-a0u1zuvcke3o9vtb-1' reason: Path alread
<ibrandt> versioned".  Am I misunderstanding how join is supposed to be used?  Bzr 2.0.1 and repo formats are both 2a.
<gioele> ibrandt: add https to .bzrignore
<gioele> s/https/httpd
<ibrandt> Thanks for the help.  I just ran bzr ignore and got, "Warning: the following files are version controlled and match your ignore pattern: httpd These files will continue to be version controlled unless you 'bzr remove' them.", so apparently my statement that I added everything but httpd was incorrect.
<ibrandt> Looks like I need a "bzr forget"
<gioele> ah, no, wait. I don't think you can't you can do what you think
<ibrandt> Ah, "bzr remove --keep httpd"?
<gioele> "bzr join" can only join branched created with bzr split
<ibrandt> Oh, I see.
<ibrandt> Any way to push the root of httpd up one dir, keeping history?
<gioele> from the help of join Â«Such trees can be produced by "bzr split", but also by running "bzr branch" with the target inside a tree.Â»
<gioele> ibrandt: I don't know
<ibrandt> I saw that.  Okay, thanks, I'll keep poking at it.
<gioele> I already asked for a new join (and a new split) that could do what you want but that proposal did not find the support of the core devs.
<gioele> while you are at it, could you expose your case to the mailing list?
<ibrandt> Sure, do you have a thread link or a Launchpad bug I could comment on?
<ibrandt> I got my ignores in order, and remove --keep'd httpd, and you're right, still no luck with join.
<gioele> ibrandt: I will try to find the link to a gmane thread later
<ibrandt> It's strange because how is bzr branch into an unversioned subdir of a parent tree all that different from bzr init on the same?
<gioele> now I'd like to understand why it does not work
<gioele> ibrandt: what about /etc/httpd/.bzr*?
<gioele> do you have just .bzr or also a .bzr.retired directory?
<ibrandt> just /etc/httpd/.bzr
<ibrandt> My thought was the join was all about merging the history for that into /etc/.bzr
<gioele> ibrandt: I see the problem
<gioele> ibrandt: join is not the culprit
<gioele> ibrandt: when you first added the files in /etc (including /etc/httpd) some paths have been stored in /etc/.bzr. Now that you are trying to join it, bzr sees conflicts between the recorded paths and the new paths
<ibrandt> makes sense
<gioele> ibrandt: can you start with a brand new /etc branch?
<ibrandt> I can, just getting started, so no history there yet.
<gioele> ibrandt: so just remove /etc/.bzr
<gioele> and do a bzr check in /etc/httpd, just to be sure
<gioele> abentley: I am using git to contribute to a project. Now I really appreciate bzr-pipeline behavior of shelving local uncommited changes when switching pipe
<abentley> gioele: Cool.  I certainly find it handy.  There might be a way to automate it in git.  Don't think they have a concept like shelving, but you could do temporary commits, I expect.
<gioele> abentley: "pipe" switching is basic part of git. Shelving is called stashing. and it must be done manually when switching branch
<gioele> obviously the command to switch branch is called "checkout"...
<Peng> \o/ I have a ~375 MB "upload" file that hasn't been touched for 1.5 hours. What are the chances this pull crashes and burns?
<abentley> gioele: Ah, I'll remember that it's called "stashing".
<abentley> gioele: The git stuff with colocated branches is similar to the pipeline thing, but pipes are ordered, while git uses "stacked git" to do an ordered series of patches.
<gioele> abentley: I know. Luckily in this case I am working on parallel branches, not stacked branches so I didn't try stgit (or any of its relatives).
<mwhudson> Peng: what project is that for?
<gioele> I wonder whether the future branch colocation feature of bzr will suffer of the same problem (no auto shelving): http://doc.bazaar-vcs.org/developers/colocated-branches.html
<ibrandt> gioele: Huh, same problem.  bzr check in httpd reported no errors.  I rm'd /etc/.bzr and .bzrignore.  In /etc did bzr init, bzr ignore ./httpd, bzr add *, bzr commit (which I verified didn't include httpd this time).  But then bzr join gives the same error.
<dahoste> wow -- that's how awesome #bzr is.  I came in here prepared to ask a question, and I solved it without even asking.   woot!
<dahoste> Shine on, you crazy diamonds!
<jelmer> :-)
<gioele> ibrandt: did you use exactly "bzr add *"?
<gioele> ibrandt: well, I can replicate your problem
<ibrandt> I did, assuming httpd would be ignored
<ibrandt> I'm trying join now prior to adding anything
<gioele> ibrandt: the * got expanded by the shell and bzr sees that you are _explicitly_ adding an ignored file so it lets you add it :)
<gioele> ibrandt: if you used bzr add . it would be ignored correctly
<ibrandt> Ah, makes sense
<Peng> mwhudson: Trying to "bzr pull" nearly all of lp:mysql.
<mwhudson> Peng: ah
<Peng> mwhudson: And yes, I am doing an on-the-fly conversion. :D
<mwhudson> Peng: oh
<mwhudson> Peng: how long has this been going for?
<Peng> Oh, I suppose this is the incredibly-long "convert everything" step.
<jam> Peng: I really wouldn't do it on-the-fly
<Peng> I had assumed the downloading was stuck.
<jam> 48hrs is a bad thing to have fail
<Peng> jam: Luckily I don't care that much! :D
<jam> ISTR that bzr branch foo; cd foo; bzr upgrade
<jam> will probably be faster
<lifeless> poolie: adsl will benefit from http://staff.psc.edu/mathis/MTU/index.html#pmtud
<lifeless> jam: it shouldn't be any faster
<lifeless> jam: we stream deltas over the network, with common code
<jam> lifeless: the converter is different
<jam> the tests I had done with spiv
<lifeless> jam: spiv put a lot of time into unifying them
<jam> showed that while his new streaming code was a lot faster when streaming
<Peng> Oh aye?
<jam> it was still much slower thna converting locally
<lifeless> jam: even the final version?
<jam> lifeless: ISTR there was a problem with still extracting too many full texts and comparing them over-the-wire
<jam> yeah, I believe so
<jam> at least for the "bzr serve ; bzr branch bzr://localhost" style of conversion
<jam> maybe that was only for push ?
<jam> bzr serve; bzr push bzr://localhost/2a/repo
<lifeless> Dunno. I will note that that is still one-machine :)
<jam> sure, but doing "bzr upgrade" locally was faster than doing it over the loopback
<Peng> mwhudson: FYI, I just checked cache speed with LP's graph in my LH StaticTuple branch. Set is about the same speed, but I slowed get down from ~277 ms to ~1.4 secs. :(
<jam> hence, shuold be faster than doing it over the network
<lifeless> jam: how many cores do you have in your test machine?
<jam> 2
<mwhudson> Peng: boo
<mwhudson> i have some other thoughts but they are incoherent and a bit angry :)
<mwhudson> and there are emails to write
<jam> mwhudson: can you check for me if 'lp:bzr-svn' is accidentally stacked on itself on the http side?
<jam> I just got a very strange recursion failure
<jam> lifeless: I thought we had a fix for not trying to open self if you screwed up the stacking rules
<jam> 'bzr info lp:bzr-svn' hangs indefinitely for me
<jam> well, probably until stack depth is exhausted
<lifeless> jam: We fixed creation of that I believe
<lifeless> and have a bug open for handling
<mwhudson> jam: it's stacked on ~jelmer/bzr-svn/1.0 i think
<mwhudson> ah
<mwhudson> which is stacked on lp:bzr-svn
<jam> and then 1.0 is stacked back on the other?
<jam>  /cry
<mwhudson> is one of them a mirrored branch, i wonder
<mwhudson> jam: yes
<jelmer> I just changed bzr-svn to be hosted on launchpad
<jelmer> but pushing with --no-stacked didn't seem to have much effect
<jam> jelmer: just to let you know, nobody can branch it now :)
<mwhudson> jelmer: bzr reconfigure --unstacked lp:bzr-svn maybe?
<jam> well, except for you, probably
<mwhudson> or i can do that
<jam> mwhudson: would that trigger an update to the mirrored side?
<mwhudson> jam: probably
<jam> I'm wondering if the hosted side is fine, but the mirrored side is broken
<mwhudson> :)
<jam> note that you can't actually "Branch.open()" the mirrored side
<jam> because it goes into infinite recursion
<jam> so the branch puller may be dead as well
<jam> at least that doesn't mean I configured the EC2 machine incorrectly :)
<jelmer> I'll change it back to the original branch for now
<lifeless> jelmer: just run bzr reconfigure --unstacked lp:bzr-svn
<lifeless> or sftp in and zerg the setting ;)
<jelmer> lifeless: reconfigure doesn't work,  maximum recursion depth
<lifeless> mwhudson: does mirroring know to propogate stacking changes?
<jam> mwhudson: On ~bzr-svn/bzr-svn/1.0 I see: stacked_on_location = /~jelmer/bzr-svn/1.0
<lifeless> mwhudson: bzr pull doesn't :)
<mwhudson> lifeless: yes
<jam> same for ~bzr-svn/bzr-svn/trunk
<mwhudson> jam: suggests the puller isn't coping too well
<mwhudson> lifeless: the puller does a possibly surprising amount more than just 'bzr pull'
<jam> and then in ~jelmer I see /~bzr-svn/bzr-svn/1.0
<jam> so it isn't trunk => 1.0 it is 1.0 => jelmer/1.0 => 1.0
<jelmer> jam: ~jelmer/bzr-svn/1.0 is mirrored, the original is not stacked
<jelmer> jam: but perhaps the lp mirror is
<jam> jelmer: mirrored branch are auto-stacked IIRC
<jam> so that theydon't have to download the whole history versus the dev focus
<mwhudson> i think i see what happened
<mwhudson> jelmer/1.0 was the dev focus, and mirrored
<mwhudson> jelmer pushed bzr-svn/1.0 which was stacked on the dev focus, jelmer/1.0 at the time
<mwhudson> then bzr-svn/1.0 was made the dev focus
<mwhudson> the next time the puller  processed jelmer/1.0 it restacked it on bzr-svn/1.0
<mwhudson> --> pain and suffering
<mwhudson> jelmer: i think you can probably unset the dev focus, delete bzr-svn/1.0, push it again and reset the dev focus
<jam> bug #485069
<ubottu> Launchpad bug 485069 in bzr "open_fallbacks with a cycle loops forever" [High,Confirmed] https://launchpad.net/bugs/485069
<mwhudson> as to how to stop this happening again, pfffff
<mwhudson> no real idea :(
<lifeless> jam: I thought there was a bug already. ce la vie
<jam> lifeless: I had only seen one about a branch stacked on itself
<jam> this is a bit more complex
<jam> mwhudson: fail early with an exception rather than failing late
<mwhudson> jam: yes, but my brain is refusing to think about how to do that
<jam> mwhudson: well it is easy to do it for "Branch.open()" as you could just pass down 'seen_branches = [url1, url2]'
<jam> I'm not sure how to do that for "set_stacked_on_location" unless we open that location, and check its fallbacks
<jam> or we make "set_stacked_on..." always take a real Branch to start with.
<mwhudson> that last feels a bit sane, at least
<ibrandt> gioele: Hit another road block.  So I started fresh in /etc with just bzr init, bzr join httpd.  No errors, so I tried to commit that before adding everything else in /etc.  I get, "Committing to: /etc/ ; renamed  => httpd ; bzr: ERROR: An inconsistent delta was supplied involving 'httpdconf', 'conf-20091113022153-bk8us11fvhuf0cre-1' ; reason: working tree does not contain new entry"
<lifeless> jam: http://staff.psc.edu/mathis/MTU/index.html is worth a read
<lifeless> jam: I /really/ think upping the send and receive buffer size is important
<jam> lifeless: Some interesting "hasattr() is evil" traceback: http://paste.ubuntu.com/321940/
<lifeless> before changing the orderinging and compression logic
<jam> This is the error I got trying to branch bzr-svn
<jelmer> mwhudson: lp:~jelmer/meta-lp-deps/bzr-svn-reqs adds libapr1-dev and libsvn-dev to the dependencies (required for subvertpy)
<jam> My guess is that hasattr() is suppressing the StackOverflow exception
<lifeless> yes
<jam> and it ends up as an attribute error failure
<mwhudson> jelmer: ah
<mwhudson> jelmer: can you propose a merge?
<jelmer> mwhudson: Sure - Should I do that already, before the bzr-svn code has landed?
<jam> lifeless: so I feel like I might have a handle on how to possibly do it on the client side, I don't have a good feel for what to do on the server
<mwhudson> jelmer: i don't really know how launchpad-dependencies works right now
<mwhudson> jelmer: now is good
<mkanat> mwhudson: Just wanted to let you know that I'm on the loggerhead stuff today.
<mwhudson> i guess i should file an rt asking for it to be installed on the slaves...
<lifeless> jam: well, if we start with bzr:// and test on that we can eliminate ssh interactions
<mwhudson> mkanat: woooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo!!
<Peng> Loggerhead stuff?
<gioele> ibrandt: I have no clue about that :( especially so late at night ;)
<mkanat> Peng: I was contracted to fix some loggerhead issues.
<gioele> ibrandt: but many devs are here, fell free to bug them ;)
<Peng> Coool.
<mkanat> One's the memory leak issue, the other one I have to go look up to remember.
<ibrandt> Sure thing.  Thanks for the help.  Definitely made some headway.  Either join isn't baked, or more likely I'm just not understanding how it is supposed to be used.
<Peng> mkanat: I love you.
<mkanat> lol
<mkanat> Oh, right, the other one is bug 118625.
<ubottu> Launchpad bug 118625 in loggerhead "codebrowse sometimes hangs" [High,Triaged] https://launchpad.net/bugs/118625
<Peng> Ah.
<mkanat> mwhudson: Could you assign that bug and bug 156453  to me?
<jelmer> mwhudson, done
<ubottu> Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,Confirmed] https://launchpad.net/bugs/156453
<Peng> mkanat: lp:~mkanat?
<mkanat> PengYep.
<mkanat> *Yep
<mwhudson> mkanat: done
<mkanat> mwhudson: Thanks!
<Peng> mwhudson: You're quick. :)
<mwhudson> mkanat: you could probably join ~loggerhead-team i guess
<lifeless> jelmer: still around?
<mkanat> mwhudson: Yeah, possibly. Let's see how these two bugs go first, I think.
<jelmer> lifeless, jep
 * mkanat tends to be very conservative about being assigned privileges or responsibilities. :-)
<lifeless> jelmer: did you see the reviews I did?
<mwhudson> mkanat: does https://bugs.edge.launchpad.net/launchpad-code/+bug/118625/comments/12 make sense to you?
<ubottu> Launchpad bug 118625 in loggerhead "codebrowse sometimes hangs" [High,Triaged]
<lifeless> jelmer: bzr-gtk doesn't have ~bzr as a member, or something - I can't actually approve or land things there.
<mwhudson> also https://bugs.edge.launchpad.net/launchpad-code/+bug/118625/comments/13
<jelmer> lifeless: ah, yes
<mwhudson> mkanat: basically i think the problems revolve around the revision graph cache
<lifeless> jelmer: so you need to land em :)
<jelmer> lifeless: I thought we made you a member of bzr-gtk some time back ?
<mkanat> mwhudson: Yeah, that makes sense.
<jelmer> or was that just in bundlebuggy?
<mwhudson> mkanat: if you can confirm that, it would be great to make building it and accessing it less all or nothing things
<mkanat> mwhudson: I'm going to do my best to reproduce it, yeah.
<mkanat> mwhudson: Okay.
<lifeless> jelmer: bb I suspect
<lifeless> jelmer: I'd add ~bzr
<lifeless> unless you really want a partition
<mwhudson> mkanat: cool
<jelmer> lifless: My main reason for not doing that yet is that everybody in ~bzr-gtk can commit directly to lp:bzr-gtk
<mkanat> I'm already pretty sure I can repro the memory leak, because it happens on my own servers.
<mwhudson> mkanat: let me know if you want some logfiles to poke at
<jelmer> lifeless, and I wasn't really sure what the membership policy for ~bzr was
<mwhudson> mkanat: although local reproduction would be better of course
<lifeless> jelmer: you could ask :)
<mkanat> mwhudson: Yeah, I totally will. Do you have a logfile analyzer for loggerhead or anything (since they get pretty big)?
<lifeless> jelmer: also, I hear you can uncommit things that shouldn't be landed
<lifeless> there is also a '~bzr-core' team, I believe
<jelmer> lifeless: Yes, but that would have taken *effort* :-)
<lifeless> though ~bzr-core includes bzr
<lifeless> which is odd/inverted
<mwhudson> mkanat: i've written a bunch of crappy python scripts over the years :)
<mwhudson> they're big but not totally crazy
 * mkanat nods.
<jelmer> lifeless: Wasn't either one invented because people didn't want to receive email about other projects than lp:bzr ?
<lifeless> yes, I think that is -core
<lifeless> its not core in the sense that other projects use -core
<lifeless> jelmer: https://edge.launchpad.net/~bzr/+members#active looks fairly sane
<lifeless> nevertheless, I don't really care. I've reviewed all outstanding bzr-gtk merges, you need to land em :)
<jelmer> lifeless: I've added ~bzr to ~bzr-gtk
<lifeless> cool
<mwhudson> mkanat: have you seen the launchpad-loggerhead glue?
<mkanat> mwhudson: No, I haven't.
<mwhudson> mkanat: https://code.edge.launchpad.net/~launchpad-pqm/launchpad-loggerhead/devel
<mkanat> mwhudson: README should mention pygments too, shouldn't it (just as a side note)?
<mkanat> mwhudson: Thanks.
<mwhudson> mkanat: i guess so
<mwhudson> mkanat: do you have a launchpad dev environment?
<mkanat> mwhudson: I don't, at the moment, no.
<mkanat> mwhudson: I may need to set that up for the hangs one.
<mkanat> mwhudson: The memory leak one is independent of launchpad, for sure (since I experience it), so I can test that one separately.
<mwhudson> mkanat: i don't _expect_ either to be launchpad specific
<mwhudson> mkanat: although we do have scary thread killing code on launchpad
<mkanat> mwhudson: Do you know about this? AssertionError: Attempt to set headers a second time w/o an exc_info
<mkanat> mwhudson: I get that a LOT if I htdig a local loggerhead.
<mwhudson> you get that if rendering fails somehow
<mwhudson> and oh man getting simpletal to tell you where something went wrong is ****ING ANNOYING
<mkanat> lol
<mkanat> Yeah, I'm getting various tracebacks for that assertion.
<mkanat> I seem to be reliably making the process grow, though.
<mwhudson> mkanat: we stream the output so the headers are set by the time rendering is happening
<mwhudson> (and we don't want to change that)
<mwhudson> mkanat: time to break out meliae!
<mkanat> mwhudson: Indeed!
<mkanat> I'm just taking a bit of time to see if I can get it as big as it was on my servers, or if it's just going to hit a ceiling and stop (which wouldn't seem like a leak to me).
<igc> morning
<lifeless> hi igc
<igc> hi lifeless
#bzr 2009-11-19
<mkanat> mwhudson: Looks indeed like I was getting the assertion because of actually closing a connection before data came out of it.
<mwhudson> mkanat: oh right
<phoenixz> bzr missing returns a shell exit code 1 if there is branche divergence?
<spiv> phoenixz: that sounds right
<phoenixz> spiv: ah, since it was not documented in bzr help missing.. I was already wondering about this behaviour
<lifeless> we should doc it
<spiv> Similar to how diff will return non-zero if there are differences.
<spiv> The docs should say so, though.
<phoenixz> spiv: what manual?
<phoenixz> spiv: bzr help missing doesnt have it documented..
<phoenixz> spiv: http://doc.bazaar-vcs.org/bzr-0.10/bzr_man.htm also doesn't show
<spiv> phoenixz: bzr help missing probably should, and maybe other places too.
<spiv> Wow, 0.10 is seriously old.
<spiv> Is that really the version you are using?
<spiv> phoenixz: by "should" I mean, "probably doesn't yet, but that is something for us to fix"
<phoenixz> spiv: eh, no, its just a manual I quickly looked up :)
<poolie> lifeless: nice page about pmtu
<poolie> the historic problem is what i thought it was, but the auto adaption is new to me, and clever
<poolie> also " Just remember: The glass is neither half full nor half empty, it is merely the wrong size. " sounds like you :)
<poolie> but him spelling 'microseconds' as 'uS' is like nails on a blackboard
<lifeless> ;)
<poolie> http://en.wikipedia.org/wiki/Siemens_(unit)
<poolie> lifeless: more to the point: if you suspect bad window behaviour with streaming, it would be interesting to capture the packets and graph/print/analyse the window flags
<lifeless> poolie: yes, spm has tools to do this
<poolie> it seems like we should be able to do it at our end?
<spm> tcmpdump + tcpflow + xplot ftw
<spm> garh. s/tcpflow/tcptrace/
<poolie> rly tcmpdump?
<spm> man. I so can't type today... tcpdump :-)
<spm> wireshark does the window graphing; but I find the above more versatile and ... obvious
<spm> poolie: eg: http://tcptrace.org/manual/node12_mn.html
<igc> hi poolie
<igc> hi spiv
<mwhudson> mkanat: are you on ubuntu one?
<mkanat> mwhudson: Nope.
<mwhudson> oh, this log chunk is only 28k
<mwhudson> mkanat: what's your email address?
<mkanat> mwhudson: mkanat at everythingsolved
<mkanat> dooot coooooom
<mkanat> â«
<mwhudson> mkanat: you should have mail
<mkanat> Sweet.
<mkanat> Indeeed.
<rubbs> Hello,
<rubbs> I'm interested in squashing some documentation bugs
<rubbs> I need some advice though
<rubbs> First, where should I pull a branch down from? bzr or bzr-alldocs?
<spiv> igc: ^
<rubbs> and should I just pull one down and hack away? or should I talk some things over with a maintainer first?
<igc> rubbs: hi
<igc> rubbs: which docs did you want to fix first?
<rubbs> igc: hello are you Mr. Clatworthy?
<igc> rubbs: I am
<rubbs> igc: cool I'm Pat Regan, I was the newbie on the mailing list who expressed intrest...
<rubbs> the first one I was thinking was bug 59608
<ubottu> Launchpad bug 59608 in bzr "'bzr ignore' undocumented behaviour and misleading tutorial" [Medium,Confirmed] https://launchpad.net/bugs/59608
<rubbs> but I'm thinking it might have already been taken care of.
<igc> rubbs: most of the doc is maintained inside the main bzr code base
<spm> mkanat: fwiw; that's an extract from a fail that starts from 20091118-05:21:13.665; next restarted @ 20091118-05:42:53.336. We have others :-) lots of others! but that's the smallest to start with.
<spm> mkanat: and hi, btw :-)
<mkanat> spm: Thanks!
<mkanat> spm: Hello. :-)
<igc> rubbs: so you want to grab lp:bzr
<rubbs> Ok, got one grabbed
<igc> rubbs: are you using explorer or the command line tool?
<spm> mkanat: fwiw, if you need any further assist; ping me or a general 'losa ping' to summon myself or one of my fellows
<rubbs> igc: mostly commandline, but I've got qbzr tools installed too
<mkanat> spm: Awesome.
<igc> rubbs: cool
<igc> rubbs: the doc for each command is inside bzrlib/builtins.py
<igc> well, most commands at least
<rubbs> igc: ok
<igc> look for cmd_ignore (say)
<mkanat> spm: I'm hoping that I can reproduce the problem locally, but if I can't, then those logs are going to be critical, for sure.
<spm> sure. at this stage all that's beeen done is a purely random IP s/r.
<mkanat> s/r = search and replace?
<igc> rubbs: the tutorials are under the doc/en directory
<rubbs> igc: k, found it
<spm> sorry - yes.
<mkanat> spm: No problem. :-)
<rubbs> igc: ok, found those too.
<igc> rubbs: have you submitted a merge proposal using Launchpad before?
<rubbs> igc: no I haven't. This would be my first ever contribution to anything really.
<igc> rubbs: no problem. We're here to help
<rubbs> great!
<igc> rubbs: the basic summary is ...
<igc> (1) make you changes
<spm> mkanat: fwiw, had another restart just a few ago. this one actually gave us a debug return: http://pastebin.ubuntu.com/322088/ so you can see some of the requests... hang. fwiw.
<igc> (2) commit
<igc> (3) push the branch to Launchpad
<igc> (4) submit a merge proposal
<mkanat> spm: So these are happening pretty frequently then.
<rubbs> igc: ok, that makes sense. Not much different than a centralized with local commits workflow then
<spm> mkanat: :-) you *could* say that. that codebrowse is referred to by us sysadmins as codebounce, is another clue ;-)
<mkanat> LOL
<mkanat> Interesting that there are so many /atom requests for exactly two projects right before the hang.
<spm> right
<spm> where it gets fun is when our nagios check url gets hungup as well.
<mkanat> Hahahaha, omg.
<igc> rubbs: I need to grab some lunch right now. If you have questions, spiv and many others can help so just ask
<igc> bbiab
<rubbs> igc: great thanks for all your help
<mwhudson> mkanat: sometimes some requests that usually take a few seconds hang around for minutes
<mwhudson> mkanat: i have basically no idea why
<mwhudson> mkanat: note that our loggerhead access branches over http
<mkanat> mwhudson: In terms of the port being open, or what?
<mwhudson> not the local filesystem
<mkanat> Ohh, interesting.
<mkanat> So there's going to be a lot more latency than on my systems.
<mkanat> I didn't even know loggerhead could do that.
<mwhudson> but i've never pinned this down to a real problem
<mwhudson> mkanat: well, not much more latency, it accesses the branches over gigE (i think) to apache serving static files
 * mkanat nods.
<mkanat> There's still pretty good latency in general over the http protocol.
<mwhudson> mkanat: as to it being possible, bzr is awesome sometimes :)
<mwhudson> open branch, give it to loggerhead
<mwhudson> loggerhead doesn't care about where the branch is from
<mkanat> That's pretty awesome.
<mkanat> Yeah, bzr's architecture seems pretty sweet, generally, from the outside.
<lifeless> thanks
<mkanat> :-)
<spm> heh
<mkanat> Hmm, on the memory leak one, I'm actually not currently getting it to go over a certain fixed size.
<mkanat> I'll have to try other things.
 * mkanat is also doing a Bugzilla release simultaneously, right now.
<mkanat> mwhudson: I was noticing that a few things seem slower than necessary.
<mkanat> mwhudson: Though I can't quite pin that down either.
 * mkanat just got a pause on mine, too, even on localhost.
<mkanat> Was pretty brief, though.
<mkanat> mwhudson: Okay, I can at least see which threads are hanging, from the logs.
<mwhudson> mkanat: cool
<mkanat> mwhudson: I can see the "Getting information for" but no "Rendering" for certain requests right before the hang.
<mwhudson> mkanat: are they building revision caches?
<mkanat> mwhudson: Yeah, two of them are.
<mkanat> I'll check the second hang.
<mwhudson> cool
<mkanat> The second one's more confusing. :-)
<mkanat> There's a lot happening right before that hang.
<mkanat> mwhudson: And yeah, I see what you mean about the long requests. Getting information for RevisionUI: 201.69120788574219 secs
<mkanat> mwhudson: Here's an interesting thing. All requests are fast shortly before the hang.
<mkanat> I mean, *until* shortly before the hang.
<mwhudson> so "something" happens, and then suddenly requests are slow, and then we're in a death spiral?
<mwhudson> sounds about right
<mkanat> mwhudson: Yeah, that seems like what's going on.
<mkanat> mwhudson: And it's never rendering that takes a long time, it's always getting information, from what I can see.
<mwhudson> mkanat: now, please tell me what it is that happens
<mwhudson> :-)
<mkanat> LOL
<mwhudson> mkanat: my /theory/ is that it's basically thrashing
<mwhudson> too much going on at once, too many threads competing for cpu, performance falls into the toilet
<mwhudson> it would be good to confirm/deny
<mwhudson> mkanat: if you want to enhance logging, we can get new code into production pretty fast for this
<mwhudson> (<24 hrs)
<mkanat> mwhudson: Okay, awesome.
<mkanat> mwhudson: I might want to do that for the memory leak if I don't get anything.
<mkanat> mwhudson: Just like a "process increased by X size after this request" sort of thing.
<mwhudson> mkanat: go wild :)
<mwhudson> we could even try getting meliae dumps i guess
<mwhudson> but they will be, uh, moderately large
<mkanat> Hahahaha.
<mkanat> Yeah, I would imagine.
<mkanat> I think it might be better to just narrow down where it's happening first than try to look through a memory analyzer or profiler for the whole process over like, days and days.
<mwhudson> from my side, i view the hangs as a much more serious and mysterious problem than the leak
<mkanat> Okay.
<mkanat> I'll focus on that.
 * mkanat had just started to anyway.
<mkanat> And the htdig that I'm running against my local repo to try to reproduce the memory leak could go on for hours or days before I get anything, anyhow.
<mkanat> mwhudson: BTW, as far as a cache that everything could access, memcached seems like a reasonable possibility too.
 * mkanat hasn't played much with CouchDB though.
<mwhudson> mkanat: yeah, possibly
<mwhudson> mkanat: a disk backend would be plenty fast enough though
<mkanat> Anyhow, back to analysis.
<mkanat> mwhudson: Okay. :-)
<mwhudson> mkanat: a more serious problem is the serialization of the graph
<mwhudson> mkanat: we basically deserialize the graph in one lump
<mwhudson> and that's crack, it would be really good to stop doing that
<mwhudson> mkanat: i guess the memory leak problem will in all likelyhood come back into prominence for us if we fix the hanging problem :-p
<mkanat> mwhudson: Wow, yeah, I imagine that kills performance for huge projects.
 * mkanat nods.
<mwhudson> mkanat: i marshal the data and gzip it
<mwhudson> mkanat: loading it for launchpad takes ~0.2s
<mwhudson> so it's not terrible
<mkanat> Okay.
<mwhudson> but still crack :)
<Peng> I can make it slower if you want. >.>
<mkanat> mwhudson: If I see one thread do "Getting information" on an identical request three times in a row with no Rendering, does that mean the connection broke before it rendered?
<mwhudson> mkanat: not necessarily
<mwhudson> it means the requests are piling up :(
<mkanat> mwhudson: Hmmm. Maybe I'm missing a bit on the architecture here. How does a thread get multiple "Getting information" requests without rendering the previous requests?
<mwhudson> mkanat: er
<mwhudson> mkanat: can you point me to a line number in the logfile?
<mkanat> mwhudson: INF [20091118-05:42:04.440] [1084594512] loggerhead.~munin-custom-plugins/munin/munin-plugins-tomcat: Getting information for ChangeLogUI: 3.7736661434173584 secs
<mkanat> mwhudson: That's the line. I have the log file a bit hacked up at the moment.
<mkanat> mwhudson: At least, that's where it starts.
<mwhudson> mkanat: the requests are being handled by different threads i think
<mkanat> mwhudson: Oh, are the numbers in brackets not thread ids?
<mwhudson> INF [20091118-05:42:07.532] [1093282128] loggerhead.~munin-custom-p...
<mwhudson>                              ^^^^^^^^^^ thread id doing the logging
<mkanat> mwhudson: Yeah, that's what I thought.
 * mwhudson looks a bit closer
<mkanat> mwhudson: I know that all those in a row aren't the same thread, but if you highlight the thread id, you'll see that it makes several information requests and doesn't render them all, and it doesn't really do it in order either.
<mkanat> mwhudson: I can investigate this on my own too, if I'm taking up too much of your time.
<mkanat> mwhudson: I'm perfectly capable of figuring out everything by digging through the code. :-)
<mwhudson> mkanat: that's pretty whack
<mkanat> Yeah!
<mkanat> That's what I'm saying! :-D
<mkanat> mwhudson: Another hung thread does the same thing.
<mkanat> 1088797008
<mwhudson> mkanat: i would _guess_ that this perhaps means that the client is no longer listening
<mkanat> mwhudson: Yeah, some of those "Getting information" requests take so long, there could be a timeout.
<mwhudson> (we run loggerhead behind apache, which might make a difference here)
<mkanat> mwhudson: I was just about to ask.
<mwhudson> mkanat: oh right, yes, so you should know this: our ProxyTimeout is 20s i think
<mwhudson> (maybe 30)
<mkanat> mwhudson: Ah, okay. :-)
<mkanat> mwhudson: So all these bad threads are getting SIGPIPEd or something. But apparently they keep on living.
<mwhudson> well python ignores sigpipe
<mwhudson> but you should get an error writing to the socket sure
 * mkanat nods.
<mwhudson> (and i think you do, sometimes)
<mkanat> I've seen it in my own logs, yeah.
<mwhudson> maybe one or more of: paste, apache, python, linux, the universe is screwing us here
<mkanat> LOL
<mkanat> Yeah, it's possible.
<mkanat> mwhudson: So python ignores the broken socket, and the thread then...? I guess I should go look at the code at this point.
<spm> <mwhudson> mkanat: if you want to enhance logging, we can get new code into production pretty fast for this <== actually TBH, us losas will fall all over each other to speedily get ANY changes in
<mkanat> spm: Hahahaha, okay. :-)
<mwhudson> mkanat: what i would have written by now if i had an infinite amount of time would be a stateful log parser
<mkanat> mwhudson: I could probably write that pretty quickly. That's a Perly sort of job.
<mkanat> And I've written so many state-machine parsers now...
<mwhudson> mkanat: most request go through a predictable pattern (starting to process, using branch url, ..., rendering) and it would be cool to be able to say how many threads at a particular time were in a particular state
<mkanat> mwhudson: Oh, that would be interesting for sure.
<mwhudson> and also find threads that don't go through that pattern
<mkanat> mwhudson: I'll see if I can put together a little script here.
<mwhudson> mkanat: that'd be awesome
<mwhudson> then maybe we can fling existing logs at it rather than having to ship them to you and see if any interesting patterns show up
<spm> wfm
<mkanat> mwhudson: Well, I don't know how consumable by the external world said parser will be, but if it's going to be so consumed, I will consider that. :-)
<mwhudson> mkanat: we don't have to tell anyone else about it :-)
<mkanat> lol, okay.
<mkanat> It'll be easier than parsing text stack traces. :-)
<mkanat> (That's the last stateful parser I wrote.)
<mwhudson> should be
<mkanat> mwhudson: BTW, what log is this that I'm getting? Because it looks different than my normal loggerhead logs.
<mwhudson> mkanat: the entry point we use and all the log setup is in the launchpad-loggerhead branch
<mkanat> mwhudson: Ahh, okay.
<mkanat> So this will be a launchpad-loggerhead log parser, then.
<mkanat> Not for the standard loggerhead logs.
<mwhudson> yes
<mkanat> Works for me.
<mwhudson> some of the goodnees in launchpad-loggerhead should probably be moved to loggerhead
<mwhudson> not sure that the log setup counts as goodness mind...
<mkanat> I dunnow, these logs are more readable, at least.
<rubbs> OK, dumb question. I've just made some changes for some documentation, how do I push it to LP so I can ask for a merge review?
<lifeless> bzr push lp:~username/project/branchname
 * rubbs slaps forehead. should have remembered that. thanks
<rubbs> Ok, so I've uploaded the branch. And I see where to click for a merge proposal. Is their any sort of standard way of going about this? Should I talk it over with people or just post and let people see it?
<rubbs> Sorry for all the newbie questions, I've just never done this before.
<spiv> rubbs: feel free to just propose it
<spiv> rubbs: no, please ask any questions, that's totally fine
<rubbs> spiv: great thanks!
<spiv> rubbs: if you're unsure you can ask here or on the mailing list before proposing
<rubbs> spiv: great! thanks for being patient. I've always good help from this channel.
<spiv> rubbs: but generally a merge proposal is a great venue for a conversation about a branch :)
<rubbs> spiv: great to know
<distatica> Hey folks, I have a working redmine setup on my web server. I am using it to display my repository status. If I have nothing on the server then it's fine to do a push, and everything works... however I can't then redo a push because I get told transport does not support update; and that branches have diverged. How do I handle this? I just want to put up a copy of my repo, at whatever state it's in, with it's revision history. Do I have to delete t
<spiv> distatica: you got cut off
<distatica> what point?
<spiv> "to delete t"
<spiv> But you probably don't want a working tree on the server.
<distatica> Do I have to delete the directory completely on the server and push again every time?Do I have to delete the directory completely on the server and push again every time?
<spiv> The revision history is all present in the .bzr directory.
<distatica> then I'm not sure what I want to do, just upload the whole directory via scp?
<spiv> If you want to upload a copy of the current state of the tree to a server, the bzr-upload plugin is a good way to do that.
<spiv> distatica: just "bzr push"
<rubbs> spiv: thanks for all your help. I've done a merge proposal.
<rubbs> igc: thanks for all your help too.
<spiv> distatica: and probably "bzr remove-tree" once on the server to get stop the warnings
<mkanat> spm: Are those log times in UTC?
<distatica> that's what I'm using, for the first time, but then I have to login and delete or else my client complains
<distatica> hmm
<spm> mkanat: good Q; that server is on BST; but that may == UTC atm. looking....
<spiv> I'm curious about how you created the copy of the branch on the server in the first place though, "bzr push" to a remote host won't create working trees.
<spm> mkanat: yes. atm, that's UTC
<mkanat> spm: Okay.
<distatica> spiv: I use --create-prefix with push, that does it doesn't it?
<spiv> No, that's something else.
<spiv> That's about whether you can push to a/b/c if the directory a/b doesn't exist yet.
<distatica> bzr push --create-prefix sftp://name@host.net/~/public_html/code/myproj
<distatica> that's what I use, myproj doesn't exist.
<distatica> then in redmine, I point it to there for the repo.
<spiv> That seems fine (although if code/ exists then --create-prefix is redundant but harmless)
<distatica> code can't exist
<distatica> because if it does, I get the errors
<distatica> oh interesting
<distatica> if I use that full line, it works
<distatica> if I just do 'bzr push' it doesn't.
<distatica> I thought push just used my last information..
<spiv> It uses the "remembered" location.
<distatica> I'm confused
<spiv> The first time you push a branch, it'll remember that location.  But an already remembered location won't be overwritten unless you specify --remember
<distatica> oh, how can I see what I'm attemptign to push to?
<spiv> bzr will tell you when it is using a remembered location, it'll say something like  "Using saved push location: ..."
<spiv> You can also run "bzr info"
<distatica> aha
<distatica> that's it, pushing to another directory, heh
<distatica> oh beautiful, now everything is working. Thank you very much.
<spiv> Not a problem.
<spiv> rubbs: oh, I almost forgot: please fill out the contributor agreement: <http://www.canonical.com/contributors>.  I don't remember if it's a requirement for docs rather than code, but if you don't object then it's probably simplest.
<lifeless> spiv: to check if ~FOO has signed, are you started at ~FOO and their groups, or at the group we care about?
<spiv> lifeless: I look at ~FOO and check their groups, but I also check the wiki page
<mkanat> mwhudson: I have the parser, now it's just a matter of output and what we do with the parsed input.
<mwhudson> mkanat: cool
<mwhudson> mkanat: well, how about "what state are all the threads in when codebrowse was restarted" ?
<mkanat> mwhudson: Yeah, that can be done.
<mkanat> mwhudson: Here's the fully-parsed log that you sent me: http://pastebin.ubuntu.com/322153/
<mkanat> mwhudson: It doesn't include lines that don't involve some sort of action.
<mkanat> mwhudson: It lists threads in reverse time order, but then the actions within the threads in forward time order.
<mkanat> mwhudson: I did it all by creating objects, so changing the output format should be pretty easy.
<mwhudson> mkanat: cool
<mwhudson> mkanat: my brain has stopped working for the day, btw :)
<mkanat> mwhudson: Hahahaha, no problem.
<mkanat> mwhudson: It seems to at least possibly hold up your theory. You can see that a lot of threads built a revision graph cache as one of their last actions.
<mkanat> mwhudson: Though I suppose those completed, so that doesn't help. :-)
<mwhudson> mkanat: yeah
<mkanat> mwhudson: Code's here: bzr://bzr.everythingsolved.com/loggerparse/trunk FWIW.
<mwhudson> cool
<mwhudson> i'll look tomorrow :)
 * mwhudson runs away from the computer
<mkanat> Okay.
<mkanat> LOL
<spm> night mwhudson!
<mkanat> Night mwhudson. :-)
<distatica> Hey folks, I've been working on a little problem for a bit now, could use some advice. When I redirect from one of my controllers I get the error that headers are sent. I've checked now for whitespace and debug statements and have solved those. I am using Searchable Behavior, and I have various models to be searched (LocalListing, Classified, etc)
<distatica> I have one search controller with one action (currently) to handle the request. If the $type and $query vars (and corresponding post vars) are empty I redirect to /search/ this is where my error occurs. I have narrowed this as close as var $uses = array('LocalListing') located in my search controller. I understand that I should include my controllers model name in that array, however I don't have one.  Commenting out this statement fixes things (e
<jelmer> distatica: Are you sure this is the right channel?
<distatica> It should be noted, when debug=0 the problems disappear.
<distatica> oh goodness
<distatica> sorry
<jelmer> no worries :-)
<JohnAlbin> Besides lp, are there any publicly-available bzr hosting solutions?
<jelmer> JohnAlbin, sourceforge does, and I believe savannah as well
<distatica> bzr hosting? like launchpad?
<jelmer> JohnAlbin, and anything that support sftp/ftp can be used (although a bit slower than the smart server)
<Kamping_Kaiser> depends what 'like launchpad'
<Kamping_Kaiser> means
<distatica> I wasn't really sure, I thought John was looking for a place to host bzr projects. I use sftp+redmine as well, and that works on many web hosts.
<distatica> oh geez
<distatica> I completely missed the lp, I'm on a role. :/
<distatica> thought it was a nick
 * JohnAlbin is googling savannah and redmine, atm.
<JohnAlbin> thanks!
<distatica> redmine you have to run though, it's not hosted. You need a web host that will let you do a little compiling and supports ruby
<JohnAlbin> ah, ok.
<mkanat> spm: Can I get more logs from around restarts?
<mkanat> spm: It's hard to say that something is a pattern with just two logs. :-)
<mkanat> But I see a few patterns.
<spm> mkanat: heh. no worries. will do; what are you after; cause the others are possibly quite large?
<mkanat> spm: Well, mostly I'd just like to see the last five minutes before the hang.
<mkanat> s/crash/hang/
<spm> oki; that's easy. will round up to nearest 10 I 'spect; easier on my aching regexified eyes
<mkanat> That's fine.
<spm> oki, gimme a few and I'll grep that for you
<mkanat> Okay. :-)
<mkanat> Also, wow, loggerhead is not coping with all the requests it's getting.
<mkanat> DEB [20091118-05:42:40.758] [47447192702192] paste.httpserver.ThreadPool: Added task (14 tasks queued)
<spm> harumph. file size == 0. messed something up....
<mkanat> spm: If you'd rather have it crash than hang, there's a max_zombie_threads_before_die option for Paste that might help.
<mwhudson> oh man, if you can belt paste into being a bit more sane that would also be good
<mwhudson> (or suggest a better container)
<mkanat> Yeah, there's also hung_thread_limit.
<mwhudson> paste is really not expecting threads to be cpu bound though
<mwhudson> and the default zombie_thread_timeout is like 1800 seconds
<spm> crash/hang - all equally bad from our perspective. no real preference
<mkanat> hung_thread_limit might help--it's supposed to be used to kill threads when they do a job for longer than X seconds.
<mkanat> Though that would screw with building the revision graph.
<mwhudson> mkanat: indeed
<mwhudson> mkanat: we kill threads after 300 s
<mwhudson> ~ish
<mwhudson> 300s of inactivity
<mkanat> A workaround for the hang might be to set hung_thread_limit to 300s.
<mkanat> Although you might still get 300s hangs.
<mwhudson> i think we do?
<mkanat> [mkanat@es-compy loggerhead]$ grep -R hung_thread_limit *
<mkanat> [mkanat@es-compy loggerhead]$
<mwhudson> mkanat: not loggerhead
<mwhudson> launchpad-loggerhead
<mkanat> mwhudson: Ohh.
<mwhudson> mkanat: and in fact we sometimes do recover from the hangs
<mwhudson> mkanat: but far too slowly
<spm> way too slowly
<mkanat> Ahh, okay.
<spm> and usually die "harder" within the next 30 mins or so fwiw. unscientific observation
<mwhudson> mkanat: i had this vague idea that you could push off the revcache generation, not just caching to another process
<mwhudson> then you could just kill threads after 30s and be fine with that
<mkanat> mwhudson: That would be a good workaround, yeah.
<mkanat> mwhudson: What's weird is that everything gets slow as soon as the revcache generation starts, and then it's all slow after that, even though they've been built.
<mkanat> I'm mostly just musing aloud, I'm still investigating.
<mwhudson> mkanat: hm
<JohnAlbin> Hmmâ¦ looks like SourceForge is on 1.10. Guess I'll use lp. :-)
<mkanat> mwhudson: It's only RevisionUI that builds the graph, right?
<mwhudson> mkanat: no
<mwhudson> basically any branch access will
<mwhudson> mkanat: look at history,py
<mkanat> mwhudson: Thanks.
 * spiv is done for the day
<spm> g'night spiv!
<mkanat> What I really wish I could get is a traceback of every thread when it's hung.
<spm> that... that's achievable. gdb attach dump goodness I assume?
<mkanat> spm: Well, it's in Python, so it won't be quite the same.
<mkanat> spm: Unless gdb can give me a python traceback. :-)
<spm> mkanat: it can! mwhudson ^^  we use your magic .gdbinit on that one?
<mkanat> spm: Really? Because that would save me all the trouble of log analysis.
<spm> really? in that case, no we cna't. :-P
<mwhudson> mkanat: http://pastebin.ubuntu.com/322211/
<mkanat> spm: lol
<mwhudson> stick this in .gdbinit
<mwhudson> oh
<mwhudson> or do you want this on prod?
<mkanat> mwhudson: Yeah, on prod, when it's hung, before it's restarted.
<mwhudson> spm: in your court i guess
<mwhudson> all the bits are there i think
<mkanat> The log analyzer unfortunately can't tell me which threads are actually still attempting to fulfill their requests and are just in a wait state during the hang.
<mkanat> Because I can't tell the difference between "client gave up and went away" and "thread is waiting for data".
<spm> mwhudson: wfm; lets try that then.
<spm> mkanat: next batch of logs enoute anyway. fwiw.
<mkanat> spm: Okay, cool.
<mkanat> I'll see if I can make it hang locally.
<spm> bbs
<mkanat> spm: How do you know when there's been a hang? It seems like the restarts happen sometimes just seconds after the last request to the system.
<spm> mkanat: 1stly we'll get a nagios check fail
<spm> times out - from memory
<spm> will try the thread-debug trick - see if that dumps anything useful
<spm> often that also hangs tho
<spm> try a local manual nagios check - 10secs limit - that time out == considered dead. restart.
<mkanat> Hmm.
<mkanat> Okay.
<spm> is one of those... greatest good for greatest numbers cases.
 * mkanat nods.
<spm> it sucks for those whose sessions we just KO'd; but....
<mkanat> So the hang itself likely happens long before you actually kill the process.
<mkanat> It may in fact not even be hanging, just becoming really slow.
<mkanat> I have a theory, even. If building the revision graph is really taking 4-5 minutes for each thread....
<mkanat> And we get 5 busy threads building revision graphs, then paste won't spawn any more threads.
<spm> sure. from our perspective the difference is ... not that significant tho
<spm> hang vs slow as in
<spm> mkanat: we got one! attaching now.
<mkanat> spm: Awesome!!
<spm> well.. no, but yes :-)
<mkanat> Hahaha. :-)
<spm> argh. what's the easy way to attach to a process; do the bt/pydump goodness without having to page all the time?
<mkanat> Oh...
 * mkanat tries to remember the command.
<mkanat> spm: Maybe if your output isn't a terminal it just won't ask you to page at all?
<spm> hrm. tricky....
<spm> gargh; we're about to lose codehosting anyway - doing a h/w upgrade on it. 2 mins....
<spm> mkanat: oki; my bad; I'll do some docco reading and be ready for the next one.
<mkanat> spm: Agh, okay. :-)
<spm> mkanat: max, may I make you known and introduce you to mthaddon, tom, he's another LOSA and normally starts around this time of the day/night/wherever
<mkanat> Great. :-)
<mkanat> Hey mthaddon.
<mthaddon> o/
<mwhudson> mkanat: btw re bug 156453 i think the problem is likely to be connected to the insane number of branches our loggerhead sees
<ubottu> Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,Confirmed] https://launchpad.net/bugs/156453
<mkanat> mwhudson: Could be, though I ran on a limited number of branches (five) and still saw a leak.
<mkanat> mwhudson: If you see the leak faster than me, it could be that there is more than one leak.
<BasicOSX> everything ok with LP?
<BasicOSX> bzr: ERROR: Invalid http response for http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/branch/branch.conf: Unable to handle http code 503: Service Temporarily Unavailable
<spm> BasicOSX: ahh. I didn't update the topic here. my bad. Codehost is offline for a h/w update. ~ 4 hours unf.
* spm changed the topic of #bzr to: LP Codehosting offline for H/W update 0800-1200 UTC | Bazaar version control system | 2.0.2 and 2.1.0b3 have gone gold! time to build those installers | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Current pilot: spiv
<RenatoSilva> where can I find info about bzr branch formats? google search just returns crap :P
<bialix> RenatoSilva: what kind of info you need?
<RenatoSilva> bialix: I-have-no-idea kind :)
<bialix> cool
<rogererens> I find the drawings in the Workflows chapter of the User Guide (command line) not as clear as they might be. Where can I give some feedback on the documentation?
<dalin> oh that's why nothing works
<LarstiQ> rogererens: launchpad is down for a hw upgrade atm, but the mailing list at https://launchpad.net/~bzr-doc would be a good bet
<JohnAlbin> o_O
 * JohnAlbin looks at the channel topic.
<JohnAlbin> wait. is LP codehosting down right now?
<LarstiQ> yes, the topic says so :p
<JohnAlbin> I assume that's why I'm getting this error: "ssh: connect to host bazaar.launchpad.net port 22: Connection refused". bah.
<LarstiQ> yes
 * JohnAlbin starts watching http://twitter.com/launchpadstatus for updates
<rogererens> LarstiQ: thanks!
<RenatoSilva> why does everyone uses twitter
<RenatoSilva> *use
<mkanat> mwhudson: Okay, pretty much figured it out. No idea what to do about it yet, that's Phase 2. :-) Phase 1 was figuring out what the heck was going on, for sure.
<mwhudson> mkanat: cool
<mwhudson> mkanat: what is going on?
<mkanat> mwhudson: You were pretty much right, except that it doesn't actually hang.
<mwhudson> ok it's just severely degraded?
<mkanat> mwhudson: Generating the revision graph for a very large branch simultaneously several times in various threads slows loggerhead to a crawl.
<mkanat> Yeah.
<mwhudson> mkanat: btw
<mwhudson> mkanat: where are you?
<mkanat> mwhudson: Mountain View.
<mwhudson> i'm sure you should sleep at some point
 * mkanat shrugs. :-)
<mwhudson> oh not too insanely late i guess
<mkanat> My girlfriend's still at work, I'd probably be waiting up for her anyway. :-)
<mwhudson> time for me to zzz anyway
<mkanat> mwhudson: Anyhow I suspect that just opening a few revisions on a launchpad branch that hasn't been graphed yet will cause it.
<mkanat> launchpad itself, bzr itself, mysql -- those seem to be the only ones large enough to cause it.
<mkanat> I'll send off an email about it to you and Francis.
<mwhudson> thanks, sounds like a good result for day 1
<RenatoSilva> bialix: can't find anything about branch formats in bzr docs
<bialix> RenatoSilva: bzr help formats ?
 * bialix still does not understand what RenatoSilva looking for
<bialix> RenatoSilva: what you looking for?
<bialix> definition of formats?
<bialix> or understanding what's under the hood?
<mkanat> mwhudson: Welcome. :-)
<RenatoSilva> bialix: I am just one that has no idea about it and is curious about all those weird format specs
<RenatoSilva> bialix: bzr help formats tells about rich-root but does not explain or points the user to somewhere else
<bialix> bzr help current-formats
<RenatoSilva> bialix: in general, it just says 2a ig good and you should be using it, it's not new to me
<bialix> bzr help other-fromats
<RenatoSilva> bialix: I have run bzr help current-formats already
<bialix> RenatoSilva: bzr core devs think that understanding of deeper internals is not for mere mortals
<RenatoSilva> bialix: I'm still reading it but it doesn't seem to include any explanation of what is rich-root
<bialix> so there is no detailed spec on repo format
<bialix> compare to git where you need to understand all internals first you even start using it
<RenatoSilva> bialix: the format names are out of order, if there should be any
<bialix> rich-root is repository format variant which store unique id for root of your tree
<bialix> RenatoSilva: open .bzr/checkout/dirstate file and look at it
<RenatoSilva> bialix: e.g are B+trees in 1.9 an improvement (included by all further formats), or an specific feature of that format?
<bialix> RenatoSilva: in bzr you need to remember that there is 3 different beasts: branch, repository and working tree
<bialix> that's complicate understanding a lot
<bialix> rich-root is the "feature" of repository
<bialix> RenatoSilva: if you really want to understand all gory details you need to deep into .bzr/ directory, inspect files there and then try to read the code which handles it
<bialix> B+trees index introduced in 1.9, yes
<bialix> it may be using in all later formats, e.g. 2a
<RenatoSilva> bialix: ok I just suggest to order help current-formats
<bialix> they are sorted for me
<RenatoSilva> bialix: ok, so each entry in the help explains improvements for later use, not specific features (it's not a format shop, it's a log)
<bialix> it's format zoo, not format shop
<bialix> you may call it a log
<bialix> does not really matter
<RenatoSilva> I mean, I thought it was a menu showing each format, so that you choose which one fits your needs with their special features, but it's clear now
<RenatoSilva> bialix: sorry it's ordered, except 2a is displayed 1st
<bialix> RenatoSilva: http://pastebin.com/d78d7b288
<lifeless> RenatoSilva: 2a is the one you should use
<RenatoSilva> bialix: in the first place that's what I wanted, and overview of the current formats etc
<bialix> RenatoSilva: there was decision helper from lifeless: use either default format or what your upstream use. if you're using bzr-svn -- use rich-root
<bialix> lifeless: I have big doubts
<RenatoSilva> bialix: I just thought I would find it in the docs, not bzr help
<RenatoSilva> bialix: so, thanks :)
<bialix> most docs generated from help
<lifeless> bialix: about 2a? I saw your comment about merge, but thats a working tree thing, not repository layer
<bialix> it seems these topics are not found their way to docs yet
<bialix> lifeless: wt thing?
<lifeless> the same id for '' issue
<lifeless> sorry, different id for ''
<bialix> Bug 484706?
<ubottu> Launchpad bug 484706 in bzr "merge 2 unrelated branches in rich-root format cause path conflict for the same file-id" [Low,Confirmed] https://launchpad.net/bugs/484706
<RenatoSilva> bialix: about your paste, I see 2a in the top, and yours is missing it
<lifeless> yeah
<bialix> RenatoSilva: this is from bzr 2.1.0b3
<RenatoSilva> bialix: which removed 2a from the help?
<bialix> RenatoSilva: lol
<bialix> I dunno
<bialix> 2a listed as default
<bialix> but yes it hould be there
<bialix> but yes it should be there
<bialix> time for filing a bug?
<bialix> ghaa! 2a now listed in other-formats
<RenatoSilva> bialix: 2.0.2: http://pastie.org/705698.txt
<bialix> I think it's a bug
<bialix> lifeless: does 2a will not default format in 2.1?
<RenatoSilva> even if not default (o.O), I think it should be there
<lifeless> bialix: I don't think we'll change the default for a while now
<lifeless> bialix: so 2a should still be the default
<lifeless> bialix: do you have a plugin that changes the default perhaps/
<lifeless> ?
<bialix> RenatoSilva: please, file a bug about this topics?
<bialix> oh
<bialix> yes
<bialix> I am
<bialix> sorry guys
<bialix> my bad
<RenatoSilva> that plugin also removes the 2a text?
<lifeless> its a side effect
<lifeless> current-formats is dynamic
<bialix> cool
<RenatoSilva> why would it remove it, for what reason
<RenatoSilva> just because it is not default? but none of them are default except one of course
<bialix> RenatoSilva: I have plugin format1 which forces usgae of pack-0.92 as default format
<RenatoSilva> and they're all listed there
<bialix> RenatoSilva: I have plugin format1 which forces usage of pack-0.92 as default format
<RenatoSilva> bialix: 0.92 is a very old format I suppose
<bialix> yes, but I need it
<bialix> for my work
<bialix> some our machines have installed bzr 1.2
<RenatoSilva> bialix: but the plugin should not remove the 2a text, should it?
<RenatoSilva> bialix: 1.2 oohh
<bialix> RenatoSilva: no, plugin does not working with help text, but the text itslef generated dynamically
<RenatoSilva> bialix: is it you that sends some msgs twice, or is your irc client? :)
<bialix> so there is some side effects
<bialix> it's me
<RenatoSilva> bialix: so it it a bug or not?
<bialix> no
<bialix> it's not bug in bzr
<RenatoSilva> *is it, ok so cancel my report
<bialix> at least it's not worth to file it.
<RenatoSilva> imho it is a bug, but ok
<bialix> resolution on this bug would be: bialix is dumb
<bialix> it's bug from plugin, so maybe I should fix it in my plugin
<RenatoSilva> ah ok
 * RenatoSilva is curious about checking what formats his local branches are using
<RenatoSilva> bzr format is not a command :(
<RenatoSilva> bzr info maybe, lmt
<RenatoSilva> oh, why is it 0.92 here too?
<bialix> branches not auto-magically upgraded
<RenatoSilva> I have other one here 'unnamed' o.O
<bialix> you have to upgrade each branch manually
<bialix> bzr info -v
<bialix> unnnamed -- means a mix of different fomats of branch/repo and wt
<RenatoSilva> bialix: but 0.92 sounds like I created the branch in the time of bzr 0.92 (?)
<bialix> 0.92 was default format until bzr 2.0
<RenatoSilva> why?
<bialix> so any branch created by default in this format
<bialix> why? what whay?
<bialix> why it was default?
<bialix> maybe for backward-compatibility reasons
<RenatoSilva> oh I see, and it's fine to break it in big releases (2.x), nice :)
<bialix> yep
<bialix> furthermore it's backward-incompatible break
<RenatoSilva> bzr info -v: Format:  control: Meta directory format 1, working tree: Working tree format 6, branch: Branch format 7, repository: Packs 6 (uses btree indexes, requires bzr 1.9)
<bialix> once you upgrade to rich-root (2a) you can't go back to poor-roots
<RenatoSilva> is there any rich-root explanations for dummies? :)
<bialix> lol
<RenatoSilva> bialix: about bz info, can't get format 1,2, 3,4...
<bialix> RenatoSilva: most likely you have 2a branch ion shared repo which is 1.9
<bialix> or something like that
<RenatoSilva> I'd expect to see the format names displayed in help rather than ordinal specs
<bialix> what is ordinal specs?
<RenatoSilva> the names, format 1, 2, 3, 4
<RenatoSilva> bialix: Format:  control: Meta directory format 1, working tree: Working tree format 6, branch: Branch format 7, repository: Packs 6 (uses btree indexes, requires bzr 1.9)
<bialix> it's internal
<bialix> they are internal names
<bialix> formats like pack-0.92 or 2a is combine names
<bialix> s/is/are/
<bialix> because you have sum of 3 formats (Mets directory format 1 is not changed for years)
<RenatoSilva> bialix: in LP there's a section in the branch "Repository format:  Packs 6 (uses btree indexes, requires bzr 1.9)"
<bialix> it's eq to 1.9 format
<RenatoSilva> wouldn't one be interested in the "storage formats" like displayed in bzr help current-formats?
<RenatoSilva> rather that this specific internal info?
<bialix> heh
<bialix> this is question not to me
<bialix> the strings you see are hardcoded now forever
<bialix> you can see them in .bzr/branch/format
<bialix> .bzr/repository/format
<bialix> .bzr/checkout/format
<bialix> rhey are identify of specific format
<RenatoSilva> I mean in LP
<bialix> well, I dunno
 * bialix -> lunch
<RenatoSilva> thanks for help bialix
* mthaddon changed the topic of #bzr to: Bazaar version control system | 2.0.2 and 2.1.0b3 have gone gold! time to build those installers | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Current pilot: spiv
<RenatoSilva> lp-users-editable bzr wiki is recent?
<gioele> hello
<gioele> I proposed to merge a branch of mine into bzr. I got some comments, changed the code and pushed the updated branch. What should I do now to make to tell the reviewers (and launchpad) that I updated the branch?
<RenatoSilva> I'd resubmit the merge proposal and/or subscribe the reviewers to the branch (try also #launchpad)
<Glenjamin> hi guys, i'm getting a bunch of NoSuchRevision exceptions when trying to diff local trees which are checkouts from an SVN repository
<Glenjamin> is there any way to resolve these, or failing that just remove all the Bzr metadata from the SVN repo and start afresh
<salgado> lifeless, still around?
<boogiepets> hi all
<boogiepets> i have a question on bazaar explorer
<boogiepets> when i hit the "Commit" button on the toolbar
<boogiepets> the "Commit" window pops up
<boogiepets> which is "always on top"
<boogiepets> why is that?
<boogiepets> i am used to inspecting the diff while i am preparing to commit
<boogiepets> in order to write details about the commit in the "Message" area
<boogiepets> with the "Commit" window always on top i have to scroll it in order to see the diff window which is rather annoying
<boogiepets> anyone willing to help?
<boogiepets> is there any way to change this behaviour?
<bialix> boogiepets: there is diff button in commit window
<bialix> boogiepets: are you using explorer + bzr-gtk
<bialix> ?
<boogiepets> yes, exactly
<bialix> sorry, I dunno then
<bialix> are you mysqler?
<boogiepets> nope
<boogiepets> the "Diff" button is indeed there
<bialix> then install qbzr and use it as your gui widgets for explorer
<boogiepets> but when i press it, the diff window pops behind the commit window
<bialix> hmm
<bialix> we have one bug report in qbzr about such weird behavior
<boogiepets> hmmmm, okay i'll try qbzr although i was getting quite fond with bazaar explorer
<bialix> there is still no understanding what's going on
<boogiepets> exactly the same thing?
<boogiepets> commit window "alwasy on top"?
<bialix> boogiepets: explorer will use qbzr widgets
<bialix> lemme find bug report
<boogiepets> soorrrrry
<boogiepets> just a mo
<boogiepets> i am using nautilus and bzr-gtk
<boogiepets> i am in Ubuntu 9.04 environment
<bialix> boogiepets: in Explorer: Tools -> Options and then select Suite -> qbzr
<bialix> bug 421039
<ubottu> Launchpad bug 421039 in qbzr "Diff windows launched from qci are always in the background" [High,Confirmed] https://launchpad.net/bugs/421039
<bialix> boogiepets: ^
<bialix> check if you encounter the same bug, please
<bialix> add the comments there about your system and library versions'
<boogiepets> OK, for me that was "Edit -> Preferences"
<boogiepets> and qbzr was already selected
<bialix> will be nice if Gary can figure out what's the problem
<boogiepets> i see that gtk provides a different window on commit
<bialix> boogiepets: ok, so you're using qbzr in fact
<boogiepets> but i like the qbzr one more
<boogiepets> yes correct
<bialix> yes, bzr-gtk and qbzr are 2 different plugins
<boogiepets> allright, installing the various things got me confused
<boogiepets> so i am using qbzr at the "Suite" option
<boogiepets> i'll check the bug report now
<bialix> ok, bbl
<boogiepets> ok, posted comment on launchpad
<boogiepets> would really like to see this fixed
<boogiepets> thanks bialix
<boogiepets> see ya
<NET||abuse> hey guys.
<NET||abuse> i'm trying to use bzr as a way of keeping graphics work, collections of photos that people drop onto a public samba share, in sync with my local copy on my windows graphics station.
<NET||abuse> i've just added 34 meg of stuff to the repo, and syncing up to the public shrae, which i'll trigger an update on when it's finished so the files on the public share are synced.
<NET||abuse> the problem is that it takes FOREVER!
<NET||abuse> 34 megs will transfer on our network in under a minute.
<LarstiQ> NET||abuse: how long is forever?
<NET||abuse> I've been waiting a good 10 minutes at this point.
<LarstiQ> NET||abuse: and what version of bzr, and what transports?
<NET||abuse> and i'ts only 36% in Build phase: Adding file contents
<NET||abuse> on windows bzr 1.18.1
<NET||abuse> transports? network shares, smb
<NET||abuse> is that what you mean?
<LarstiQ> NET||abuse: hmm, I guess that gives me enough info
 * LarstiQ was after sftp://, bzr+ssh:// etc
<LarstiQ> in `bzr push bzr+ssh://host/path/`
<NET||abuse> it's a dapper drake ahh :)
<LarstiQ> but it seems you're treating it as a local filesystem
<LarstiQ> which will mean it creates a workingtree
<NET||abuse> in windows it's bzr push P:\graphicdesign\sitedesign\
<NET||abuse> though i'm using hte tortoisebzr interface right now :)
<LarstiQ> ok
<LarstiQ> NET||abuse: what format is it in? `bzr info` will tell you
<NET||abuse> standalone tree (format: pack-0.92)
<LarstiQ> NET||abuse: ok, you might want to try 2a
<LarstiQ> NET||abuse: and if you don't need the working tree, getting rid of that will help a lot
<NET||abuse> well, the idea is that other people on the network can drop files into the network share, which is a working copy, then on the share working copy, i just do a nightly bzr add, bzr commit and then on my local copy, i do a bzr pull
<NET||abuse> or bzr add; bzr commit; bzr merge; bzr commit; bzr push
<LarstiQ> NET||abuse: ok, so you absolutely need the working tree then
<NET||abuse> and one final bzr up on the share again .
<LarstiQ> NET||abuse: are you the only one who interacts with it via bzr?
<NET||abuse> yeh. it's to keep stuff on my graphic design station in sync with what's on that share, so other pople have access to what i've produced
<NET||abuse> at the moment yeh.
<LarstiQ> ok
<NET||abuse> i'm the only bzr user.
<NET||abuse> i just check for new stuff being dropped in periodically.
<LarstiQ> NET||abuse: then please try `bzr upgrade --2a` and see what the effect is of that
<LarstiQ> if it's still slow, why needs figuring out
<NET||abuse> hehe, i seem to have accidentally duplicated my directories.. haha,, i had p:\garphicdesign\sitename.com  then i did bzr push with the tortoisebzr gui, and it pushed to p:\graphicdesign\graphicwork\   which created a new branch, that's weird...
<NET||abuse> LarstiQ, that would be more of a reason it took so long, it actually branched the whole repo of 1.43GB, not just the 34MB of new images i added.
<NET||abuse> i just didn't realise it was doing that.
<NET||abuse> still,, what's the advantage of the 2a version?
<NET||abuse> is it just hte archiving schema? what does it do better?
<LarstiQ> NET||abuse: the important part here being a more efficient storage, let me look up the link
<NET||abuse> hmm, cool. ok.
<NET||abuse> why does it not create that format by default? is my bzr version on windows just too old?
<LarstiQ> it creates it by default from bzr version 2.0.0
<NET||abuse> ah,, but my windows bzr install is only bzr 1.18.1
<LarstiQ> http://bazaar-vcs.org/Benchmarks?highlight=%28benchmark%29 is what I was thinking of iirc
<LarstiQ> NET||abuse: right, but 1.18 can read and write 2a
<LarstiQ> but it hadn't been made the default yet
<LarstiQ> so when the switch was made, there were a couple of older clients that could handle the format too
<NET||abuse> ahh, ok
<NET||abuse> might see if i can get a 2.x client version for my windows box then.
<NET||abuse> my linux laptop is ubuntu karmic, which is packaged with 2.0.1 , is that the most recent stable?
<LarstiQ> NET||abuse: it is right now, 2.0.2 is on it's way to release
<NET||abuse> cool.
<NET||abuse> have to say, it's getting better than when i first used it.
<NET||abuse> or at least i'm getting more comfortable with it..
<LarstiQ> that's the idea with software development ;)
<NET||abuse> switching from svn is tricky :)
<NET||abuse> in terms of changing your mindset on how things should work.
 * LarstiQ nods
<NET||abuse> i use bzr mostly for my personal projects now, in work we are still svn centric, the main projects are svn + trac versioned.
<NET||abuse> have to say, svn is good in that your certain it's going to work.
<NET||abuse> i've had a few bugs during bzr usage, but mostly they're solved with things like updated repo formats, or i just ask someone in here :)
<LarstiQ> svns maturity (and thus 3rd party support) is certainly a feature
<NET||abuse> aha,,, i imagine bzr or git will probably make it's way to primary use in our office soon.
<NET||abuse> right, i need lunch :)
<NET||abuse> oh, one more thing, i need a good workflow for managing web dev projects, i design sites and code php or python,
<NET||abuse> at the moment i develop locally, tracking in bzr, then push the branch up to a working copy on my server, then update the working copy on the server and just cp -rf ./dir1 /var/vhosts/sitexyz/
<NET||abuse> for each directory of stuff that needs copying..
<RenatoSilva> how to extend bug tracker support for commit --fixes?
<NET||abuse> i'm wondering about a better deployment management strategy.
<LarstiQ> NET||abuse: I'd use bzr-upload
<LarstiQ> NET||abuse: http://bazaar-vcs.org/BazaarForWebDevs http://bazaar-vcs.org/BazaarUploadForWebDev
<RenatoSilva> how to extend bug tracker support for commit --fixes? can I define new prefixes? like bzr bugs fb=http://foo.bar
<LarstiQ> RenatoSilva: yes, see `bzr help bugs`
<RenatoSilva> thanks!
<RenatoSilva> but why bugzilla_squid_url = http://www.squid-cache.org/bugs
<RenatoSilva> why not be free to create a template like
<RenatoSilva> bugs_prefix = http://www.anyone.org/this_work/this_way?bug_id=%s
<RenatoSilva> so that you bzr commit --fixes=prefix:123
<LarstiQ> RenatoSilva: as `bzr help bugs` says, you can do that with bugtracker_prefix_url = http://www.anyone.org/this_work/this_way?bug_id={id}
<RenatoSilva> LarstiQ: oh! didn't read it all after this part: "If your bug tracker can't be described by one of the schemes described below then you can write a plugin to support it."
<LarstiQ> RenatoSilva: the sentence before that: along with a template mechanism for other bugtrackers with simple URL schemes.
<LarstiQ> RenatoSilva: maybe that should be "this will cover most bugtrackers"?
<RenatoSilva> why would not that template mechanish doesn't work with some bug tracker?
<RenatoSilva> s/mechanish doesn't work /mechanism work
<LarstiQ> RenatoSilva: because some are convoluted and you can't just plug in a bug number
<RenatoSilva> ah. Do you know one?
<LarstiQ> RenatoSilva: not off the top of my head, I may have repressed knowledge of such a beast
<maxb> Hrm, didn't qbzr display branch nicks before the most recent version?
<maxb> the truncation of branch names in the tree is also less than welcome
<maxb> Hm, the branch nicks were lost in a refactor merged yesterday
<MvG> Hi! I've got a thing here that feels like a bug, but I'd like your opinion on it. It's about file system encoding.
<MvG> I'm running trac-bzr as a fcgi process, and it seems that locale information (LC_CTYPE in particular) don't get passed along. So python has no reliable clue about the current filesystem encoding, i.e. sys.getfilesystemencoding() doesn't give the 'UTF-8' it should. Not bzr's fault so far.
<MvG> Now when bzr does list directories, e.g. in transport.local.list_dir, the os.listdir tries to convert byte strings to unicode, but fails on non-ascii chars. For these names, it returns raw 8-bit strings. list_dir applies url escaping to these, and the end result is a bunch of url-escaped utf-8 names. Fine so far.
<MvG> Trouble starts when I use one of these names to e.g. clone a transport for a subdir and listing that subdir. In that case, the url gets decoded to a unicode name using utf-8, resulÃ¶ting in the correct unicode name. Feeding that name to os.listdir causes a UnicodeEncodeError, as the name isn't ascii, and python doesn't know how to convert it to ascii.
<MvG> So I wonder, shouldn't the url given for a local repository on a byte-oriented filesystem (i.e. *nix) be byte-oriented as well, instead of unicode-oriented?
<MvG> There is a simple correspondence between 8-bit decoded urls and 8-bit filesystem names. And any name returned by the python os module can be easily reverted to its 8-bit form using sys.getfilesystemencoding().
<MvG> What do you think? Bug? Feature request? Or simple misconfiguration, as python should know the file system encoding?
<MvG> Out of curiosity: is there some document anywhere about how to set up bzr access over ssh in a safe and secure way? Like http://svnbook.red-bean.com/en/1.4/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth for ssh? What's e.g. launchpad doing to keep people from writing all over their system? Custom in-house plugins, or something available to the public?
<MvG> Is "bzr serve --directory=/some/dir" guaranteed to restrict access to said directory?
<bialix> maxb: hello
<maxb> hello
<bialix> can you elaborate on "the truncation of branch names in the tree is also less than welcome"?
<bialix> maxb: can you test my fix for Bug 485133
<ubottu> Launchpad bug 485133 in qbzr "Reference to undefined name 'revids_load' in log.py" [High,In progress] https://launchpad.net/bugs/485133
<bialix> ?
<maxb> 1: I'd rather see my long branch names in full, even if they are long
<maxb> 2: I will try later, but I don't really know what I did to provoke it in the first place, so it may be difficult
<bialix> maxb: I've added truncation long ago on 20 symbols
<bialix> we can move this into config
<maxb> Indeed, I have no idea why I only just noticed it
<bialix> but I can suggest you where in the code you can change the limit
<maxb> Also, it only seems to apply to branch names, not tag names, which is a bit inconsistent
<bialix> about nick and tags and bugs: this is indeed regression from garyvdm
<bialix> Gary!
<bialix> yes, only branch names truncated, because I had evidence of 120 chars long nick
<bialix> btw, this is branch nicks, not branch names
<bialix> so you can do: bzr nick "my very very very very very very very long nick" and guess what happnes
<bialix> maxb: you can change branch nick with `bzr nick` command
<maxb> yes. But equally you can do: bzr tag my-very-very-very-very-very-very-very-very-very-very-long-tag
<bialix> tags is psecial
<bialix> sorry
<LeoNerd> Surely a certain amount of "you're doing it wrong" applies if you need names -that- long..?
<bialix> tags is special
<bialix> maxb: truncation done in loggraphprovider.py around line 367
<bialix>                 tag = bi.branch.nick
<bialix>                 if len(tag) > 20:
<bialix>                     tag = tag[:20]+'...'
<maxb> LeoNerd: Arguably there's a certain amount of "you're doing it wrong" if you're using CVS, but we are :-)
<bialix> but yes, we're not very consistent here
<LeoNerd> maxb: Oh.. is this for cvs->bzr branch conversion?
<maxb> yup
<LeoNerd> Heh.. :) Might have guessed...
<bialix> maxb: really?
<bialix> scary
<maxb> Yes it is, that is why I am attempting to drag my team kicking and screaming out of the dark ages and to bzr
<bialix> maxb: about truncation: I won't mind if you file this wish as bug report
<jam> MvG: "bzr serve --directory=/foo/bar" does guarantee to not serve outside of /some/dir
<bialix> hi jam
<jam> jelmer: if you are around... "bzr branch lp:bzr-svn" still seems to be broken for me...
<jam> hi bialix
<jam> I don't know if you and mwh, et al sorted out a plan for fixing it?
<MvG> jam: thx!
<jelmer> jam: I'll have a look
<jam> MvG: as for trac-bzr, it definitely needs to know the fs is utf-8
<jam> I don't know how to tell it that, though.
<MvG> jam: Found out, at least for my case: reconfigured my mod_fastcgi to set the LANG environment variable.
<MvG> I guess it's not worth the effort to work around a possible misconfiguration on the bzr side.
<jam> MvG: it is hard to do, because we are relying on the underlying python implementation for a lot of things
<MvG> It would be possible, but probably would require case distinctions for different os.
<MvG> Never mind, and thanks for your opinion.
<jam> MvG: arguably it would be nice if python defaulted to UTF-8 as the fs rather than ASCII on platforms that didn't give other indications.
<MvG> In some cases yes, in others no...
<jam> jelmer: I'm not sure if you followed mwh's discussion of how it happened
<jam> but basically, your dev focus used to be a mirrored branch
<jam> so all your lp branches are stacked on it
<MvG> Oh, and by the way, jam, thanks for approving my trac-bzr team membership!
<jam> when you changed it to hosted, then the newly created branch got stacked elsewhere, and things got circular
<jam> MvG: np, you've been doing a lot of work there anyway
<MvG> jam: Do you know how the trac-bzr development usually works? Can I simply start triaging bugs or committing changes, or should there be some kind of review or similar?
<jam> MvG: I think trac-bzr is pretty 'loose' in changes
<jam> I don't know that anyone is actually maintaining trunk
<jam> well, actively maintaining
<MvG> In that case I'll start merging my minor fixes soon, and try to get some kind of review on my quoting branch once I've got my latest ideas coded...
<MvG> There seems to be a team mailing list, but I couldn't find any messages in the archive. Is that because there were none, or is lp broken?
<MvG> https://lists.launchpad.net/trac-bzr-team/
<mzz> I really should remove myself from that team, it's not like I actually know the code anymore
<jam> MvG: I believe it is because there were none
<jam> mzz: I'm sure you know it better than *I* do :)
<mzz> jam: you might be surprised!
<jam> mzz: since I've never read it at all...
<jam> at best we would be equal :)
<mzz> I don't even remember if any code I wrote is in this incarnation of the plugin
<bialix> oh! trac-bzr hackers here!
<MvG> quote so.
<mzz> MvG: good luck with your changes though. At the time I actually hacked on this getting trac to play ball was not fun.
<mzz> (I'm hoping it has improved)
<MvG> I'm only touching the most prominent issues so far.
<MvG> Nothing seems impossible yet... ;-)
<bialix> I'm still using old version of trac-bzr with trac 0.10.5
<bialix> with bzrlib from bzr 1.5
<bialix> then something becomes broken
<bialix> I really hope that I can upgrade my trac setup soon
<bialix> MvG: does new improvements to trac-bzr will require upgrade to trac 0.11?
<MvG> mzz: but now that you mention it, get_previous is causing me trouble lately (https://bugs.launchpad.net/trac-bzr/+bug/484983) and as that code seems to be from you in large parts, do you think you can remember your intention there and explain it to me, so I can fix it properly?
<mzz> well, I can try
<MvG> bialix: good question. Don't have a trac 0.10 around, so I wonÃ't be able to test with 0.10, so I can make no guarantees...
<MvG> do you consider 0.10 support important?
<MvG> If so, it might be worth a branch...
<gioele> MvG: Trac 0.10 is very widely deployed
<MvG> Because I assume not all my changes will play nicely with 0.10. If I start fixing the Wiki macro (https://bugs.launchpad.net/trac-bzr/+bug/484640) using genshi, that's for sure.
<mzz> MvG: I'm guessing that's incredibly evil code I wrote to hack around a performance problem, but let me read my changelog entries and see if I remember anything
<bialix> I won't object to upgrade to 0.11 and support only it if it helps to make trac-bzr better
<ubott2> Launchpad bug 484983 in trac-bzr "BzrDirNode.get_previous broken" [Undecided,New]
<bialix> just in 2007 when I've installed it on my work it was difficult to use 0.11 on Windows
<gioele> MvG: anyway, if the trac-bzr is not going to be released soon, maybe it makes more sense to concentrate on 0.11 only
<ubott2> Launchpad bug 484640 in trac-bzr "Branches wiki macro is defunct" [Undecided,New]
<MvG> gioele: Don't see a "release" soon. There are quite a number of open bugs, and judging from the fact that the ones I encountered weren't already reported for the most part, I assume there's a lot of work ahead.
<gioele> MvG: go ahead and forget my remarks about 0.10.x ;)
<MvG> But as there is such an active trac-bzr discussion here at the moment: how would you like this syntax for changesets: [branches,name,42] to refer to revno 42 or the branches/name branch? The key ingredient is the substitution of / by , as trac doesn't like slashes in revnos.
<mzz> MvG: did you spot http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/annotate/head%3A/HACKING#L50 ?
<MvG> mzz: not yet.
<mzz> MvG: it is likely trac changed substantially since I wrote that function and just removing it is now sane
<mzz> MvG: I think I wrote that for two reasons (and it's actually doing two different things depending on how it gets called): to quickly get a reasonable "previous" link when browsing changesets, and to generally be faster than going through get_history by only loading a single changeset instead of the complete branch history
<Adys> how do I show a diff from one specific rev to another?
<mzz> but I'm still re-reading
<mzz> Adys: bzr di -rfirstrev..secondrev
<Adys> thanks
<bialix> hello amanica_
<mzz> MvG: after skimming get_history I suspect you're right and get_previous can just be killed, but do poke around a bit to make sure performance isn't stupid anywhere
<MvG> mzz: It's the part about "avoiding get_history" for which I don't understand how it works, and which would affect performance.
<MvG> Right now it does use get_history, I guess.
<mzz> MvG: iirc if you just remove the function the default implementation calls get_history
<amanica_> hi bialix
<bialix> how are you?
<amanica_> not bad thanks, almost recovered from flu
<amanica_> you?
<mzz> MvG: I think I wrote a specialized implementation mainly (perhaps exclusively) for performance reasons: bzr ended up doing something involving loading lots of trees that was slow, and I thought I could get away with loading a single known revision by id instead, which was much faster
<bialix> amanica_: too much work, too little time for hacking
<mzz> MvG: but that's years ago, get_history probably got smarter, and it's usually calling into a completely different bzr repository now
<MvG> You mean different repo format?
<mzz> MvG: so if removing get_previous works *and* performs reasonably, I'm pretty sure that's the right thing to do
<amanica_> bialix: yup, me too. also trying to catch up to the bzr mailing list
<mzz> MvG: yep
<MvG> I'm not sure my setup is suitable to seriously test performance: I have only a limited number of commits, and quite a number of other factors influencing performance.
<mzz> MvG: again, it's been *ages*, but I think the point was that there were a couple of trac webui pages that called get_previous to get something like a "previous changeset" link, while get_history was only called for pages like a log view page (that actually displays more than one log entry)
<bialix> maxb: several of your reported bugs in qbzr just fixed. thanks for reports!
<MvG> otoh I'm pretty sure your idea can't work: give a revid, to find the previous rev where that thing changed, you have to do one of two things:
<MvG> either take the previous revision of the whole branch, find the last modified revisoon of every child, and take the latest of these,
<MvG> or take preceeding revisions one after the other in reverse chronological order until you hit one that touches the dir in question or its content.
<MvG> Both involve some kind of loop which I don't see in your implementation, but which might be faster than a full get_history.
<mzz> MvG: so get_history ended up calling into a bzr api that efficiently extracts a lot of history (in batches) (which made the revision log page a lot faster) while get_previous avoided that.
<mzz> MvG: but at that point I was much more interested in getting it fast than in making sure all links everywhere in the webui behaved consistently.
<MvG> mzz: Still is that way, and the proken "Previous Chang" link is what got me started to investigate.
<mzz> MvG: and since that time the entire thing got a lot smarter about caching etc (I think all of BranchCache was added later)
<mzz> MvG: so if it performs acceptably on branches with a nontrivial amount of history you should just kill the function, I think.
<MvG> OK, thanks mzz, I'll have another look now, with this info at the back of my head, and will see if I can work out a good fix or will simply drop the method.
<mzz> MvG: just make sure you test on a nontrivial branch (few 100 revisions), if what I remember about this is correct that matters
<mzz> well, mattered :)
<mzz> MvG: and don't worry about "other factors affecting performance", this was an order of magnitude thing, anything less than that is not worth specializing get_previous for
<mzz> it's *supposed* to do the same thing as get_history, anything else is me cheating
<mzz> and now you've made me remember about http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/annotate/head%3A/HACKING#L85 :(
<MvG> mzz: I already made close aquaintance with that __del__ method: https://bugs.launchpad.net/trac-bzr/+bug/484324
<ubottu> Launchpad bug 484324 in trac-bzr "memory leak due to uncollectable BzrRepository" [Undecided,New]
<mzz> MvG: yeah, I think I saw that one in my bug mail :(
<MvG> I guess I should have a read through HACKING, see what it says and what might need updating when I commit stuff.
<MvG> Had a close look at get_history. Looks like that's really what is needed, and in case the caller closes the generator after retrieving a single result, the performance impact shouldn't be too high.
<mzz> MvG: at the time I wrote get_previous there *was* a noticable performance impact. But I suspect that's simply no longer the case (since someone who cared more about the revision log view than I did at that time optimized it, or I did it myself later)
<MvG> mzz: Considering your useful input here, I'd hate to see you leave the team, as you stated somewhere up there.
<mzz> MvG: as for the __del__ method: I wonder if you could create a (non-proxy) weakref every time you add a branch with a callback that closes that branch. Although I'm not sure where to store that weakref (on the branch would probably work, but that's ugly)
<mzz> MvG: actually, I think you could give your LockedBranches a weakref callback (triggered by the BzrRepository owning it going away) that calls unlock instead of using __del__
<MvG> I'm not sure I understood you correctly, but I fear this might cause branches to get collected while I still have use for them.
<MvG> any benefit in the weakref callback over the del as I implemented it in LockedBranches?
<mzz> MvG: it's not __del__ :) weakrefs don't break the cycle collector like __del__ does.
<MvG> __del__ doesn't break a thing is it's not in a cycle. Therefore my new approach works.
<mzz> MvG: the practical difference would be that LockedBranches.unlock gets called immediately once the owning BzrRepository goes away, independently of any other (cyclical) references LockedBranches is involved in.
<mzz> MvG: so it seems a bit safer, since if anything manages to form a cycle involving LockedBranches you'll be back where you started if it uses __del__.
<mzz> but hey, I added the original __del__, I can't complain no matter which way you go here :)
 * MvG is reading up on weakref callbacks
<mzz> they're easy. Sec, lemme branch
<MvG> mzz: I guess what troubles me most is that the weakref on the repo object would /form/ a cycle, even as it's one with a weakref in it so it can be broken, and there shouldn't be a del method.
<MvG> And I'm not sure if the callback gets executed if the object owning the weakref becomes collectable before.
<MvG> I.e. whether my LockedBranches might get finalized without the callback being ever triggered.
<MvG> Any objectsions to me updating the trac-bzr trunk repo to 2a format?
<MvG> would allow stacked branches...
<mzz> MvG: heh, only I can't test this because I don't have trac installed
<Lo-lan-do> Hi all
<mzz> MvG: weakrefs are always safer than __del__ as far as cycles goes. If LockedBranches gets finalized before its BzrRepository the weakref wouldn't get called back, but that can't happen unless someone screws with BzrRepository._locked_branches.
<Lo-lan-do> jelmer: Ping? Would you have an hour or so in the coming days? I'd like to get bzr-git finished for git push, and I have the frustrating feeling we're *almost* there but not quite.
<jelmer> Lo-lan-do, hi
<jelmer> Lo-lan-do: Yeah
<Lo-lan-do> :-)
<MvG> mzz: Why can't that happen? After all, both become collectable at the same time.
<Lo-lan-do> jelmer: When would it be convenient for you?
<mzz> MvG: see lp:~marienz/trac-bzr/bug484324 (untested!)
<jelmer> Lo-lan-do, now would be good I think
<Lo-lan-do> Yay
<mzz> MvG: the BzrRepository has a strong ref to its LockedBranches, so the LockedBranches refcount won't go to 0 before the BzrRepository
<jelmer> Lo-lan-do: Is now good for you as well?
<Lo-lan-do> jelmer: Sure. Shall we move to private?
<jelmer> yeah
<MvG> The BzrRepository refcount won't go to 0 "the normal way" either, because it's part of a cycle. Does the cycle collector really work with refcounts and all that? Or simply clean up all parts of a detected cycle and everything reachable only from it? And how about future python implementations?
<MvG> I just don't feel safe here, it's relying a lot on implementation details.
<MvG> At least feels that way to me, as I'm still relatively new to Python.
<mzz> MvG: __del__ is just way scarier as far as implementation details goes than weakref is, because weakrefs don't get access to the object that just died.
<MvG> I had the impression __del__ gets access just before the object dies.
<MvG> Which is why __del__ causes trouble in cycles: Python refuses to break the cycle as long as any __del__ might rely on any part of it.
<mzz> MvG: __del__ is capable of "reviving" the dying object, which makes it quite icky. If you can structure so you can use a weakref instead of __del__ that is normally preferable.
<MvG> weakref is all right for me, but relying on the callback seems bad.
<mzz> MvG: how so?
<MvG> As I pointed out, I'm not confident the callback will get executed at all.
<MvG> I see no spec clearly stating it will.
<mzz> MvG: can you describe a way to make it not execute?
<mzz> MvG: preferably one where __del__ *will* :)
<MvG> Write my own python interpreter, and do so in such a way that the gc first collects all unreachable objects, then finalizes them all, keeping track of weakrefs, and then calls callbacks only if their owners are still alive...
<MvG> I guess current standard python implementations don't behave this way, but unless it's specified that no python is allowed to behave this way, I don't feel safe.
<MvG> I know __del__ is guaranteed to be called before the object gets collected, and that all outgoing references of the object will stay intact.
<MvG> That's a clean and reliable promise, and one I can work with.
<mzz> MvG: where are you seeing any guarantees that __del__ gets called that don't apply to weakrefs?
<mzz> there are *very* few clean and reliable promises as far as __del__ is concerned.
<mzz> "It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits"
<mzz> also "Circular references which are garbage are detected when the option cycle detector is enabled (itâs on by default), but can only be cleaned up if there are no Python-level __del__() methods involved"
<MvG> OK, you made a point there.
<MvG> mzz: I guess I have an idea that might make me feel safe as well: ensure that the object containing the weakref stays reachable until the callback gets executed.
<MvG> Will code that later, gotta east something first...
<mzz> MvG: you already have that. BzrRepository has a strong ref to LockedBranches.
<MvG> But BzrRepository itself isn't reachable any more.
<mzz> MvG: no, but that's the whole point.
<mzz> MvG: let me turn that around. With your current code if LockedBranches manages to go away before the BzrRepository does your __del__ would run too early, so you'd also be broken.
<MvG> So as BzrRepository isn't reachable, and it's the only one with a reference to LockedBranches, and as it doesn't have a __del__ method so it isn't expected to run any code, then I'm not sure I'd consider LockedBranches reachable.
<MvG> No, only if the BzrRepository were to /use/ the branches later on.
<MvG> So the order of finalization doesn't matter, as long as neither one is going to run any other code.
<MvG> Gotta go, will be back later on...
<ibrandt> Greetings All.  My company uses Bazaar internally, but we're going to be enhancing and contributing to a project that is otherwise versioned in Git.  The thinking is we'd produce numerous internal revisions in Bazaar, culminating in the occasional upstream patch.  I was wondering if anyone had any tips for this sort of a workflow?  Our current plan is to checkout a working copy of our project from our shared Bazaar repo, and then clone the Gi
<ibrandt> project into a subfolder of that working copy.  Work the subfolder primarily with bzr, but upstream updates and such can fetched with git.  I'm not sure if we'd want to bzr add the .git repo, or bzr ignore it?
<LarstiQ> ibrandt: or use bzr-git
 * Tak agree
<jam> ibrandt: http://bazaar-vcs.org/TrackingUpstream
<jam> ibrandt: you may want to look at "Converting and ignoring history"
<jam> it talks about cvs, but I imagine it would be about the same for git
<ibrandt> Ah, okay.  Thanks!  I'll read up.
<LarstiQ> ibrandt: and linked off from that, http://bazaar-vcs.org/BzrForeignBranches/Git
<distatica> Anyone here run qbzr on debian lenny? I have backports; and the launchpad site in my sources.list, but when I try to install it says that I need python-central 0.6.11 but 0.6.8 is installed. I could just remove python-central and attempt to download and install 0.6.11 but this can lead to more problems; wonder if someone knows a better route to take.
<jam> distatica: I would guess that the dependency isn't a strong one, but just whatever recipe was copied when they made the package
<lifeless> moin
<lifeless> jelmer: +1 to adding gagern to bzr-trac?
<jelmer> lifeless: I think you mean trac-bzr :-) (bzr-trac is an unfriendly fork)
<lifeless> $garh
<jelmer> lifeless, no objections here, although I'm not really involved with trac-bzr anymore
<lifeless> me neither
<lifeless> but I figure two not involved people saying yes is better than noone saying no
<jelmer> lifeless: I agree, I think it would be hard to find people actually involved atm
<lifeless> MvG: hi
<MvG> lifeless: hi as well!
<MvG> Oh, you been talking about me! :-D
<lifeless> MvG: yah
<MvG> jam already approved my team mambership...
<lifeless> just wanted to say that trac-bzr doesn't really have anyone caring about it in terms of 'maintainers'
<lifeless> so don't block on reviews
<lifeless> if you don't get a review for a branch in (say) 2 days, I think you should land it.
<MvG> glad to hear that.
<MvG> Should I request reviews over the launchpad merge request thingy?
<lifeless> yup
<MvG> gladly.
<lifeless> hmm, lets see if trunk has any subscribers
<MvG> I'm thinking about a branch for 0.10 compatibility. What do you say?
<lifeless> hah, the owner isn't subscribed. \o/ thumper: <- when can we do this search and fix?
<thumper> lifeless: I'll get back to you shortly?
<lifeless> thumper: :P
<lifeless> MvG: I have no opinion. I don't know where trac is at, lifecycle status, userbase that will want bzr for trac 0.10 etc
<thumper> lifeless: a call
<MvG> 0.10 is widely deployed, and 0.11 introduced some serious changes.
<lifeless> MvG: https://code.edge.launchpad.net/~trac-bzr-team/trac-bzr/trunk/+merges you might like to review the branches that are need review and not from you
<MvG> good idea. but tomorrow - its getting late around here...
<lifeless> MvG: no rush
<lifeless> MvG: just saying :)
<MvG> :-)
<MvG> I guess I'll add a bunch of branches of my own tomorrow.
<LarstiQ> MvG: considering the reality of trac deployment, I'd vote for a 0.10 branhc
<LarstiQ> MvG: unless you keep trunk 0.10 compatible that is
<LarstiQ> either works, whatever is least hassle
<LarstiQ> MvG: and good night ;)
<MvG> LarstiQ: Have no 0.10 here to test, and I believe that with respect to url quoting and stuff there might be a lot of changes, so I doubt I'll stay compatible.
<MvG> Thus branch and backport as much as feasible, but no more.
 * LarstiQ nods
<distatica> jam: Sorry for the delayed response, helping my son do a puzzle. So how should I proceed then? I tried installing qbzr via the tar and sudo python setup.py install; however when I run bzr I get: Unable to load plugin 'qbzr' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'
<LarstiQ> MvG: I run a 0.10 trac, though not actively with bzr. If you ping me I can test though.
<jam> distatica: can you run "bzr -Derror" so you can see what is failing?
<jam> Like, do you have pyqt and other such dependencies installed?
<distatica> Yeah, but I might be missing something I didn't notice.
<distatica> or the wrong package was installed.
<MvG> LarstiQ: Thanks for the offer. Will ghet back to it when I have two more commits or so in my quoting branch.
<LarstiQ> MvG: k
<jam> distatica: it could be version skew, depending on what version of bzr you have installed, too
<distatica> however, when I run bzr -Derror it just prints the help, bzr -D error says error is a command not found
<distatica> hmm
<MvG> By the way, how would you deal with the questioon of backwards compatibility? If I change the revno format, do I still have to accept old IDs?
<LarstiQ> distatica: no space between -D and error
<Lo-lan-do> distatica: try "bzr -Derror qbzr", or howewer you're supposed to run qbzr
<LarstiQ> MvG: in general I'd say yes, but that needs more thought for the specific change
 * LarstiQ goes to bed
 * MvG too
<MvG> Thx!
<distatica> hmm, that error just shows me that it's not starting, and that it fails when trying to call qbzr
<amanica_> Lo-lan-do: with only qbzr you can run each command seperately, see http://bazaar-vcs.org/QBzr
<Lo-lan-do> distatica: There's probably some log in .bazaar
<distatica> one file, ignore
<Lo-lan-do> Oh, it's ~/.bzr.log, sorry
<hersonls> hi, where i found how export repo with python?
<hersonls> the python api
<amanica> hersonls: I think you can only export a branch at a time see: bzr help export
<amanica> I think it would be nice to be able to export a repo though
<hersonls> amanica, i need ceate a python script to export without bzr comand, understand?
<amanica> aah ok
<amanica> I may not be able to help now, mabe somebody else can
<amanica> you can maybe look in builtins.py
<amanica> there you can see how the "branches" command finds branches, and also check there how the "export" command exports them. hth
<hersonls> amanica, ok
<hersonls> amanica, i belived have documentation for this
<jam> hersonls: define "export"
<jam> do you want just the files on disk
<jam> similar to "bzr export ../foo.tar.gz" or "bzr export ../to_dir"
<jam> or are you asking to have the history?
<jam> amanica: and 'bzr branches' is in bzrtools, not core (yet)
<hersonls> similar to "bzr export ../foo.tar.gz" or "bzr export ../to_dir"
<amanica> jam: whoops, I thought it made it into the core already
<jam> hersonls: then you'll want to look at 'builtins.py' for the "cmd_export" code
<jam> I think it is generally "Tree.export('path')" but I haven't looked in a long time.
<hersonls> jam, amanica hey
<hersonls> >>> from bzrlib import export :)
<hersonls> export(tree, dest, format=None, root=None, subdir=None, filtered=False)
<hersonls> tanks
<amanica> cool
<hersonls> amanica, tanks
<amanica> np
<mwhudson> is there a 2.1.0b3 release branch?
<mwhudson> or just a tag on the 2.1 branch?
<poolie> hello all
<poolie> mwhudson: i think the plan is now that it's just tagged on the 2.1 branch
<mwhudson> (i should probably know this already but well)
<mwhudson> okidoke
<jam> mwhudson: 2.1 branch
<jam> at least, I'm trying it out
<rogererens> Can .bzrignore files contain comment lines (in order to explain why some paths/files are ignored)?
<mwhudson> jam: cool
<jam> rogererens: with #
<mwhudson> of course i remembered the odd push -r behaviour again...
<jam> mwhudson: pushing something older than target does nothing?
<mwhudson> jam: no much odder than that
<mwhudson> jam: https://bugs.edge.launchpad.net/bzr/+bug/484516
<ubottu> Launchpad bug 484516 in bzr "bzr push -r $revspec ../foo creates branch with working tree from tip, not that of $revspec" [Undecided,New]
<jam> ah, yeah that's pretty strage
<jam> strange
<jam> I think afc argued that we should never update the wt w/ push
<jam> as it was "inconsistent"...
<jam> I don't ever use it
<jam> as cd ../target ; bzr pull works just fine
<mwhudson> i was using this to create a new branch at a tag
<mwhudson> i guess bzr branch . ../target -r tag:whatever works too
<jam> mwhudson: yeah, I think it is a bug and should certainly be fixed, just never run into it because I don't use 'push' to do that sort of thing
<rogererens> jam: # to start a comment line; is it also possible to have inline comment? adding # to the end of line seems to wreck the regex
<jam> rogererens: I think only a separate comment line
<rogererens> jam: thx
<jam> yeah, we have:
<jam> if not line or line.startswith('#'):
<jam>     continue
<jam> but nothing about pulling a # comment out of the middle of the line
<mwhudson> so if there isn't a 2.1.0b3 release branch, is there a 2.0.2 release branch?
<jam> mwhudson: there is, but we're switching to just using a tag on the 2.0 branch when 2.0.3 comes out
<jam> well, I guess *I*'ll be switching to that unless I get punted as RM
 * jam realizes I've been approaching RM all wrong. I should be extolling the virtues of how wondrous it is to be RM, so someone will take over for me :)
<amanica> lol
<lamont> how do I abort a merge (that had conflicts)?
<Lo-lan-do> revert?
<lamont> sounds like it would have worked if I hadn't helped it along first.. OTOH, it wasn't quite where I wanted it anyway, so I'm now back to thinking that I know where I am
<stefano-k> hi all
<stefano-k> I read in bzr planet that the bazaar documentation is now translated in japanese too... do you know how to contribute to translate it (in Italian)?
<servilio> jelmer: is there a bug tracker for bzr-svn? can't remember
<jelmer> servilio: launchpad.net/bzr-svn
<servilio> jelmer: just there, lapsus mentis, sorry
<servilio> jelmer: but just to check, I've just installed it and didn't complain about subvertpy not being available
<servilio> it is not listed as a dependency in setup.py
<servilio> is this intentional?
<nivya> I'd like to have bzr version control on my server  and access it from my laptop. I have bzr installed on both server and client. How to tell bzr to create a project and store files on the server?
<Peng> stefano-k: Well... I don't know if there is any documentation on it, but if you get a copy of lp:bzr you can probably mostly figure it out.
<Peng> Heh.
<nivya> what's the best bzr gui client out there?
<servilio> nivya: bzr-explorer
<poolie> hi jam
<jam> hi poolie
<poolie> hi, nm, i sent you mail
<jam> poolie: I might ask you to run a snapshot for me. I'm trying here, but it seems to get stuck in the "waiting-for-shutdown" state.
<jam> I'll give it a bit longer
<jam> I wonder if I need to change the admin password back
<jam> I doubt it., but maybe
<poolie> jam, doesn't it proceed automatically from that state?
<Peng> Heh, branching MySQL without a format conversion took an hour and 200 MB of RAM.
<poolie> ie request the snapshot, then os shutdown, snapshot, instance shutdown or reboot should happen automaticalyl?
<poolie> Peng: locally? over the network?
<Peng> poolie: Over the (not overly fast) network.
<poolie> k
<poolie> there is a lot of data there
<poolie> if you set debug_flags=hpss it will print some stats at the end
<jam> poolie: he's comparing it to w/ a conversion
<jam> which took hours 200+MB and didn't finish
<jam> well, downloaded 300-400MB IIRC
<jam> and IIRC it takes at least 5-600 MB to download all of mysql in 1.9 format
<jam> drops to around 200 in 2a
<Peng> poolie: Yeah, but it also puts a ton of information in .bzr.log, no? I'd love to see the stats, but not the other stuff.
<igc> morning
<igc> hi jam, poolie
<poolie> hi igc
<Peng> Currently, pulling revisions 1001-2500 with a conversion is stuck after downloading about 250 MB.
<lifeless> Peng: cpu high?
<jam> hi igc
<Peng> lifeless: No, it hasn't done a damn thing in hours. Most of it has been swapped out by now.
<igc> hi jam - how the trip back?
<igc> was
<jam> igc: trip back went smooth. Long, but smooth
<jam> and not as long as the way out :)
<Peng> lifeless: Eventually it'll exit saying "Connection closed".
<jam> I guess LAX was a bit of a pain 2-hr layover and I had maybe 5min before boarding because you have to go through security again
<Peng> jam: FYI, the 1.14 repo is 475 MB.
<Peng> jam: No clue how that translated to bandwidth.
<jam> Peng: which branch?
<jam> lp:mysql ?
<Peng> jam: mysql-5.1.
<jam> IIRC mysql/6.0 is bigger
<Peng> I think that's lp:mysql.
<jam> Peng: sounds about right
<jam> Peng: du -ksh mysql/.bzr is 629MB here, w/ 5.1 and 6.0 present
 * Peng looks up -k
<Peng> Oh, neat.
<jam> Peng: it is an old habit. I used to work on Unix boxes that have 512byte blocks rather than 1k blocks
<jam> and having to divide by 2 all the time was annoying
<mwhudson> like os x 10.2 ...
<lifeless> uhm
<lifeless> -k changes the rounding figure
<Peng> jam: The 6.0 branch is pretty old.
<lifeless> using it will give wrong answers if the fs is 512 byte blocks
<jam> lifeless: it gives the right answer to "how many kb are there"
<jam> it gives the wrong answer for "how many blocks are used"
<lifeless> jam: it gives the wrong answer to how many kb are there
<lifeless> by file-count * block-size-error
<jam> lifeless: it gives a much closer to how many 'kb' there are than du without it on 512 byte blocks
<jam> :0
<jam> :)
<jam> sure for 100s of files it may round each one incorrectly
<jam> still much easier to parse as a human
<Peng> jam: (It hasn't been committed to since 2009-05-16, and accessible since 2009-10-29.)
<jam> that was before -h
<jam> Peng: sure, I'm not sure where 6.0 series development really is
<lifeless> jam: or -b I guess
<jam> lifeless: yeah
<jam> peng: but I'm sure its active since guilhembi has been reporting bugs for using bzr w/ 6.0 development
<Peng> jam: There are some recently-modified branches on https://code.edge.launchpad.net/mysql-server. I just got 5.1 because I didn't know which were most important.
<jam> Peng: I'm pretty sure 5.1 is their focus, though I thought they released 5.4?
<jam> 6.0 was sort of like py3k, IIRC
<jam> 'the future stuff'
<Peng> Python 3 got released. :P
<Peng> jam: 5.4 branch hasn't been touched in 17 weeks.
<jam> Peng: there are releases of 6.0, for what mysql considers releases
<Peng> (Note: I know nothing about MySQL.)
<jam> I don't think there is a General Availability, but I don't really track it
<jam> mysql-server/cluster-6.4 was touched just yesterday
<jam> anyway, I'm glad you got the data
<jam> its time for me to EOD
<Peng> jam: Yeah, but I wanted to look up WTF it was before getting a copy, and didn't feel like doing so right then. :P
<bjp> hey, if i have several projects in a directory, and i use bzr-init to create a shared repo in that directory, whats the best way to add the subdirectory projects to the new shared repo?
<jam> bjp: they are already branches?
<jam> bzr reconfigure --use-shared IIRC
<bjp> yes
<bjp> cool
<bialix> jam: ping
<Peng> bialix: He might've left about 15 minutes before you joined.
<bialix> perhaps
 * bialix sighs
#bzr 2009-11-20
<dOxxx> evening...
<dOxxx> Would it be acceptable to modify start_bzr_subprocess and finish_bzr_subprocess to not raise TestSkipped if python 2.6's Popen.send_signal method is available?
<lifeless> dOxxx: I don't follow
 * igc bbiab
<dOxxx> lifeless: start_bzr_subprocess raises TestSkipped if os.kill isn't available, as on win32. However, with ptyon 2.6, the subprocess.Popen class has a send_signal method which maps SIGTERM to the TerminateProcess Win32 function.
<dOxxx> lifeless: to make more tests run on win32, I was wondering if it would be acceptable to add an alternate codepath that used Popen.send_signal if it was available
<lifeless> yes
<lifeless> thats makes sense
<lifeless> simply not raising TestSkipped did not make sense.
<ricardo_br> Is there any command in bazaar to remove those backup files? ex:database.php.~1~
<mwhudson> ricardo_br: it's a bit more than you're asking for but bzr clean-tree --ignored will kill them
<ricardo_br> mwhudson : it's almost it, but I have some ignored folders that I don't want to delete (some project folders), is there any linux command that I can use?
<mwhudson> ricardo_br: well 'find . -name \*~ -print0 | xargs -0 rm' will do it i guess
<ricardo_br> mwhudson: wow, I really need to study these shell commands, it worked, thanks
<mwhudson> ricardo_br: find | xargs is both very handy and somewhat crazy :-)
<ricardo_br> well, I read the first part of the xargs' man page and it really scared me (xargs - build and execute command lines from standard input), A few time ago I was using windows I must admit
<mwhudson> ricardo_br: you know the saying "unix *is* user friendly, it's just picky about who its friends are" ?
<Peng> Oh wow! My original "bzr pull" isn't entirely dead.
 * igc lunch
<ricardo_br> mwhudson: no I don't know this one, probably I'm that slow second cousin
<mkanat> ricardo_br: I think you want bzr clean-tree --detritus by the way.
<ricardo_br>  mkanat: thank you! It's exactly what I'm looking for, I don't have to be friend with unix anymore
<mkanat> :-)
<mwhudson> oh right
<mkanat> mwhudson: Did you see my long email?
<mwhudson> mkanat: yes, it's been on my "to reply" list for about 7 hours now :)
<mkanat> mwhudson: Hahaha, okay. :-)
<mwhudson> mkanat: another team in launchpad trying spawning
<mwhudson> mkanat: the scars are ugly and fresh
<mkanat> mwhudson: For loggerhead?
<mwhudson> no, for some u1 related thing
<mwhudson> mkanat: they went back to using paste
<mkanat> Okay.
<mkanat> Well, Spawning does say it's still a beta.
<mwhudson> ehh, i guess i should reply to the mail
<mwhudson> then have a conversation
<mwhudson> not the other way around :-)
<mkanat> mwhudson: Okay. :-)
<mkanat> mwhudson: Spawning was, of course, just a random idea without any research yet. :-)
<mkanat> mwhudson: The more general idea being "scale better". :-)
<mwhudson> mkanat: yes, i think that's basically the best idea
<mwhudson> lifeless: can you remember the problems with spawning?
<mwhudson> i have this vague recollection was that it wasn't very specific, it just didn't work very well
<mwhudson> and was too magical
<lifeless> yes
<lifeless> it died  inthe ass for u1
<lifeless> it does things like monitor for module changes and reload() when a foo.py changes (just thing what apt-get install will do to it :P)
<lifeless> s/thing /think /
<lifeless> my suggestion if you want cpu concurrency for loggerhead is haproxy
<lifeless> or squid
<lifeless> just add another backend service and tell the frontend stuff to send to both.
<lifeless> simple, easy to admin, no code changes needed.
<mwhudson> yeppers
<mkanat> lifeless: That was my idea as well.
<mkanat> We just need a way to share the revision cache between processes and then we're set.
<mkanat> That scales across cores and machines as well.
<dOxxx> holy cow, it's an utter mission compiling python extensions for x64 on windows
<AfC> Once upon a time there was someone doing distributed bugs (with bzr, I think, but no matter)
<AfC> does anyone have a suggestion for listing bugs _in tree_ of a project (ie not in a distributed bug database, but in a project tree) so that commits to code are done along with commits to {TODO, BUGS, bugs/filename.txt, ?}
<mkanat> AfC: Not particularly. (Somebody else might.) It has always seemed to me that one of the major purposes of bug-tracking was central coordination, whereas development and branching really should be distributed.
<mwhudson> AfC: "bugseveryehwere"
<mwhudson> AfC: http://bugseverywhere.org/be/show/HomePage
<rubbs> Ok, so I've submitted a patch last night on a documentation bug, and got some feedback. I made changes according to the suggestions, and pushed up the results. I then made a comment, but taged it with the "resubmit" vote. I've just now realized that it wasn't a tag but a review vote.
<rubbs> what do I do now?
<rubbs> is there anyway to delete that comment with the "resubmit" vote?
<AfC> mwhudson: that was what I was thinking of
<mwhudson> AfC: all abentley's fault iirc
<AfC> mwhudson: right
<AfC> mkanat: well, not really. What good is a centralized [only] bug database if you're not on the internet?
<AfC> If you take distributed == disconnected you empower a lot more than just branches.
<mkanat> AfC: Yeah, to some degree. I think it depends on the project.
<AfC> mwhudson: do you know if Aaron is [still] using bugseverywhere?
<mwhudson> AfC: not much, i think
<mwhudson> AfC: but here he is, you can ask him :-)
<AfC> mkanat: again, not really. If you the coder are frequently off the global network, then a bug database not locally accessible isn't any help to your development efforts
<AfC> abentley: mwhudson mentioned a project of yours you once worked on, "bugseverywhere"; I was curious what your current opinion of it is?
<mkanat> AfC: Sure, but that's a separate issue, I think.
<AfC> mkanat: that's the issue I'm trying to redress
<mkanat> AfC: Though not totally.
<mkanat> AfC: Fair enough. :-)
<mkanat> AfC: There are desktop clients for some trackers that will do offline work.
<fullermd> Doesn't whatsitsname include bug stuff...
<AfC> mkanat: no web hosted centralized only bug database is any use to me as an open source developer, because both I and my collaborators are only intermittently on the internet
<abentley> AfC: I think it's still a useful idea, but the tool could use some work to become more forgiving.
<fullermd> Fossil, that's it.  The thing the SQLite guy did.
<mkanat> AfC: That's a situation I haven't thought of much, I have to admit.
<mkanat> AfC: Where I am, it's almost impossible to get away from the Internet. :-)
<fullermd> http://www.fossil-scm.org/index.html/doc/tip/www/bugtheory.wiki
<abentley> AfC: Chris Ball maintains it now, and there's a small community around it, which is better than I ever did.
<AfC> abentley: fair enough
<lifeless> theres another distributed bug db
<fullermd> (note that I haven't done more than read about it, so I don't know how or how well it works in practice)
 * AfC pulls the plug on his wireless internet connection to conserve battery
<AfC> mkanat: [see? :)]
<AfC> lifeless: oh?
<lifeless> AfC: I'll mail you
<lifeless> some web3 thing - the sharecropper argument, they made a distributed db and wrote a bug tracker on it
<AfC> lifeless: you have an idea of a google phrase to hunt for?
<mkanat> mwhudson: Anyhow, an email response would probably be good since that's how we arrange the go-ahead for me to do further work.
<mwhudson> mkanat: my email is a bit of a ramble tbh so far
<mwhudson> oh well
<mkanat> mwhudson: Honestly, I'd almost just love to help you out in my free time, except that that doesn't exist, and when it does, I don't use it to code. :-D
<mkanat> mwhudson: That's OK. :-)
<AfC> lifeless: ok, thanks!
<lifeless> http://www.stackfoundry.com/dbug/ could be interesting too
 * AfC ends essentially off topic conversation
<mkanat> AfC: I have to admit I found it interesting, since I'm one of the primary developers of a bug-tracking system.
<mkanat> I haven't yet seen a pressing *broad* need for distribution in bug-tracking, but that doesn't mean it isn't necessary, useful, or going to become one of those two things.
<mkanat> AfC: So if you find any of those to be particularly useful or interesting, I'd be interested to know.
<lifeless> AfC: http://code.bestpractical.com/project/Prophet
<lifeless> http://syncwith.us/sd/bugs
<AfC> lifeless: thanks Robert. Will look.
<lifeless> I make no assertions
<lifeless> it crossed my radar a while back and seemed interesting
<lifeless> though it looks like they use git now for the bts, rather than prophet, which doesn't fit my memory
<AfC> lifeless: NO WARRANTIES :)
<AfC> lifeless: k
 * AfC hibernates [or, reboots and fscks assuming the thing crashes again]
<mwhudson> mkanat: mail sent
<mkanat> mwhudson: Thank you. :-)
 * mwhudson tries to remember why the backend server for codebrowse takes path based urls, not id based ones
<mwhudson> oh, maybe because we tie access control up with the translation from name -> id
<mwhudson> man
<RenatoSilva> verterok_: hi
<RenatoSilva> dOxxx: hi
<mwhudson> we need a much smarter frontend :(
<dOxxx> RenatoSilva: heya
<lifeless> mkanat: I wouldn't share the caches
<lifeless> mkanat: tell the front end how much of the path to hash to the same backends on
<RenatoSilva> dOxxx: hi, thanks for fixing that test bug. Even formely deactivated AVG was still working. I ended up uninstalling AVG, now the tests pass fine :)
<mkanat> lifeless: That would be OK, too.
<mwhudson> hm, the frontend we already have could do that
<mkanat> lifeless: We're also discussing the possibility of just removing the cache entirely.
<mwhudson> seeing as it has the branch id to hand
<abentley> mwhudson: Are you using your router from the sprint?  I'm using my eee as a router again!
<mwhudson> well
<mwhudson> yes
<mwhudson> abentley: yes, finally
<mwhudson> abentley: argh
<mwhudson> abentley: because of the xx:45 disconnects?
<lifeless> mkanat: I've suggested that that is a good idea :)
<RenatoSilva> what's the arg for bzr selftest <plugin> that makes it faster?
<lifeless> RenatoSilva: -s bp.pluginname
<abentley> mwhudson: That, and increasingly-agonizing internet connectivity in general.
<lifeless> RenatoSilva: note that this prefix is buggy
<mwhudson> abentley: what did you have before?
<lifeless> RenatoSilva: because it excludes interface conformance tests (which may not apply to you). But if they do apply to you using that doesn't test the whole plugin.
<abentley> mwhudson: wrt54g
<mkanat> mwhudson: I replied, but if the list is moderated, you'll have to clear my reply, since I'm not on the list.
<mwhudson> abentley: huh, i thought they were ok
<mwhudson> mkanat: i think it is
<RenatoSilva> lifeless: interface conformance tests?
<abentley> mwhudson: I've used this one for years.  Maybe the love is gone.
<mkanat> My WRT-54G is pretty much OK, though I have DD-WRT on it.
<mwhudson> abentley: or maybe your ire needs to be sent further upstream
<RenatoSilva> lifeless: can't find any info about "bp" in bzr help selftest
<abentley> mwhudson: I tried that, but elmo wasn't having it.
<mwhudson> but i guess changing router is a good first thing to try
<mwhudson> abentley: maybe not that far :-)
 * rubbs does a little dance. His first patch ever was just accepted
<abentley> mwhudson: I went to the vanguard on #is, but elmo joined the conversation.
<mwhudson> abentley: i meant your isp
<abentley> mwhudson: mtr showed packet loss at the entry point to canonical, so I went to #is.  elmo explained that this doesn't really prove a problem, because routers will often discard ICMP datagrams.
<mwhudson> abentley: oh right
<mkanat> rubbs: 'Grats!
<rubbs> mkanat: thanks!
<RenatoSilva> anyone else getting this error? http://img69.imageshack.us/img69/9431/qterror.png
<spm> mkanat: fyi; we were arrrgggghhh!ing yesterday over the pager in gdb? rtfm reveals: (gdb) set pagination off :-)
<mkanat> spm: Ahhh. :-)
<spm> doncha hate it when the solution is the obvious one!
<mkanat> :-)
<mwhudson> spm: set height 0 also does that i think
<spm> mwhudson: so it does.! ta! "The number of lines GDB thinks are in a page. Use 0 to keep GDB from pausing."
 * mwhudson stops for the day
<spm> night mwhudson, have a great w/e!
<mwhudson> spm: well i'm working tomorrow :)
<mwhudson> swap day for a couple of weeks
<spm> ahhh. fair enough. that'll learn you for having a honeymoon :-P
<mwhudson> yeah
<dOxxx> what version of pycrypto and paramiko does bzr use?
<lifeless> whatever you have installed
<lifeless> [was that what you meant to ask?]
<dOxxx> lifeless: sorry, it's late and I'm not thinking straight. what version of pycrypto and paramiko does the windows installer bundle?
<lifeless> no idea; I thought pycrypto was built in now, and its likely latest released paramiko
<dOxxx> lifeless: The problem I'm having is that in order to use ssh while running bzr from source, I need to have paramiko and pycrypto installed for the version of python I'm using. However, I'm getting deprecation warnings about the sha and md5 modules.
<dOxxx> lifeless: Is it because I'm using python 2.6?
<dOxxx> hmm bzr from windows installer bundles python 2.5, that's probably why I don't see the warnings when I'm using that
<lifeless> dOxxx: I'm pretty sure we fixed all our deprecated warnings
<lifeless> what bzr are you using?
<dOxxx> lifeless: latest from bzr.dev. these deprecation warnings are coming from pycrypto v2.0.1. if I try pycrypto v2.1.0b1, I get different deprecation warnings about RandomPool
<lifeless> oh
<lifeless> :(
<dOxxx> they're only warnings, stuff still works, it just irks me when I'm running selftest every couple of minutes to test a change and I have to mentally filter out these warnings
<lifeless> yeah
<lifeless> you could fix it :)
<dOxxx> bleh
<dOxxx> :)
<dOxxx> not at 1am ;)
<dOxxx> good night!
<fullermd> Yes, stock pyrcrpto has warnings with py2.6.
<dOxxx> ah
 * fullermd khan speel...
<fullermd> There are patches floating around.  I know there's one on LP somewhere for Ubuntu.  The FreeBSD port has one.
<dOxxx> hmm maybe I'll scrounge around tomorrow
<dOxxx> thanks for the info
<fullermd> (neither being platform-specific; it's pure py)
<dOxxx> good night :)
<MvG> LarstiQ: When you find the time, can you try whether lp:~gagern/trac-bzr/quoting works on trac 0.10? I fear it won't...
 * igc dinner
<eMerzh> hi ... i have pbm to access a repository behind a proxy... what should i look to?
<eMerzh> i've well my http_proxy variable defined
<bialix> jam: when you'll have a couple of free minutes -- I have a question
<Garagoth> Hello.
<Garagoth> I wanted to try Bazaar, but once I installed it, it fails... 'bzr version' gives me a traceback with message: 'UnboundLocalError: local variable 'version' referenced before assignment'
<Garagoth> Could anyone help me with that?
<LarstiQ> that sounds rather broken
<LarstiQ> Garagoth: could you pastebin the full traceback?
<Peng> Garagoth: Pastebin the traceback.
<Peng> D'oh~
<LarstiQ> MvG: hmm, I'm getting TracError: Unsupported version control system "bzr"
<LarstiQ> MvG: but unsure why
<igc> night all
<LarstiQ> night igc!
<Peng> igc: Good night. :)
<Garagoth> pastebin ?
<Peng> Garagoth: Paste it on http://paste.ubuntu.com/ or a similar site and give us the URL.
<LarstiQ> ubottu: paste?
<ubottu> Sorry, I don't know anything about paste?
<LarstiQ> hmm
<igc> Hi LarstiQ! Nice to hear from you
<igc> Thanks Peng
<LarstiQ> igc: likewise :)
<MvG> LarstiQ: Never mind, I'm just about to set up a dedicated apache config on my desktop in order to test trac-bzr, I'll set up one with 0.10 as well.
<Garagoth> http://paste.ubuntu.com/323262/
<LarstiQ> MvG: oh, ok
<LarstiQ> Garagoth: ehm, your python install seems to be broken
<Garagoth> LarstiQ: Ok, what is wrong with it?
<Peng> Garagoth: What distro are you on?
<Garagoth> Archlinux
<Peng> Garagoth: Or, um, OS in general?
<Peng> Oh.
<LarstiQ> j~.~.~.
<LarstiQ> gah
<Peng> Garagoth: 1.) There's a bug in Python's platform module, 2.) You have a weird /etc/*release or /etc/*version file; otherwise the bug wouldn't be exposed.
<Peng> Garagoth: To be more specific, it's empty.
<Garagoth> Peng: Both release and version are empty.
<Peng> Garagoth: Yes, well, that would be your problem.
<Garagoth> Ok. version now works.
<Peng> Note to self: File Python bug: platform._parse_release_file UnboundLocalError if the file is empty.
<Peng> (Or if the first line is.)
<Garagoth> release is still empty... but I had a test version file not from my distro ;-)
<Peng> Anyway, I was eating pizza and/or watching TV. See ya.
<Garagoth> Thanks for info.
<Garagoth> and help/
<Garagoth> Now I have another issue... http://paste.ubuntu.com/323273/
<bialix> LarstiQ: hi
<bialix> LarstiQ: I have some experience with trac-bzr, so I might help maybe
<Garagoth> Anyone with fast-import experience? http://paste.ubuntu.com/323273/
<bialix> Garagoth: are you using the latest version of fast-impor from trunk?
<Garagoth> revision-id: ian.clatworthy@canonical.com-20091106080627-0n409tg6rrj2hhb0
<Garagoth> date: 2009-11-06 18:06:27 +1000
<Garagoth> build-date: 2009-11-20 13:50:32 +0100
<Garagoth> revno: 260
<Garagoth> branch-nick: bzr-fastimport
<bialix> I don't know what is build-date
<bialix> anyway this is most likely bug in the plugin
<Garagoth> Looks like date when i branched this repository
<bialix> fast-import author is igc, he said goodnight half hour ago
<bialix> you may want to file a bug
<bialix> or try to use more recent/older revision
<bialix> sorry, can't say more
<Garagoth> Mm. Thanks.
<Garagoth> plugin version is 0.9.0dev
<bialix> 0.9.0dev means unreleased-yet version
<bialix> it can has bugs inside
<bialix> your traceback is cleanly bug
<bialix> revno 260 -- is the latest version in trunk
<bialix> Garagoth: you really need to file a bug report
<Garagoth> Ok, I will.
<jam> morning bialix, what's your question?
<bialix> hi jam
<bialix> jam: https://code.launchpad.net/~jameinel/qbzr/bug_430232_early_qapp_trunk
<bialix> this branch seems is not needed anymore?
<bialix> we have your fix in the trunk, I'm not sure what the purpose of this branch
<bialix> if it really no needed, can you mark it as merged or abandoned?
<bialix> jam ^
<jam> bialix: Sure, though I would have thought the fix would have been merged from there
<jam> anyway, I can mark it merged
<bialix> jam: it strange but trunk has different your revision with slightly different commit message
<jam> I might have done it 2 times or something
<bialix> and with the same revno
<jam> no big deal
<bialix> thanks jam!
<jam> or maybe did an uncommit?
<jam> anyway
<jam> done
<bialix> thanks
<bialix> jam: and while I've got a bit of your attention, can I point on Bug 485771?
<ubottu> Launchpad bug 485771 in bzr "[win32][2.1.0b3] windows command-line parser replace \ with /" [Undecided,Confirmed] https://launchpad.net/bugs/485771
<bialix> I can imagine why it works as it works now, but I have reasons to think it's not right
<jam> bialix: so... I think there is a "has_glob" function in 'glob', that you can use to tell if we need to try and expand a command line param
<jam> however note that if you do "bzr commit -m "foo\bar"  it will 'just work'
<jam> also note that with the proposed patch, "bzr commit -m foo\bar" is going to warn/prompt you...
<jam> anyway, I forget the specific function, but certainly we could only try to expand things that have ? or * in them.
<bialix> hmmm
<bialix> I think I want to write a patch to disable glob with env variable
<bialix> jam: BZR_GLOB=0 will be OK for you?
<jam> so caveat the discussion about it breaking scripts, etc
<jam> it seems ok
<jam> I might put "BZR_WIN32_GLOB=0"
<jam> or... BZR_WIN32_NOGLOB=1
<bialix> so many choices
<bialix> flkip a coin?
<jam> anyway, I'll let you work out the details
<jam> yeah
<bialix> BZR_WIN32_NOGLOB and any non-empty value
<bialix> that sounds sane for me
<bialix> something like there is done for NO_PROXY?
<bialix> thx for suggestion, I'll try to make a patch this weekend
<bialix> jam: is there planned b4?
<jam> bialix: yeah, I'm pretty sure, and certainly at least an rc1
<jam> so rc1 => 2.1.0 final won't have many changes, but current => rc1 can
<bialix> I just need to have some gap to make sure NOGLOB patch will be landed for 2.1
<jam> basically at rc1 it goes 'stable'
<jam> you've got ~2 months
<bialix> more than enough :-)
<jam> bialix: I think not globbing when there isn't a glob character is also a worthwhile fix, on-top of a _NOGLOB variable.
<bialix> on-top?
<jam> bialix: do both, not just noglob
<bialix> ah, understand
<jam> noglob is useful, but it is a big hammer that people have to think about to turn on
<jam> rather than have things "just work" most of the time
<bialix> jam: ok, I understand, but noglob is simpler to write right now, do what I mean needs some thinking
<bialix> jam: another your branch @ qbzr: https://code.launchpad.net/~jameinel/qbzr/progress
<bialix> do you recall what is it off hands?
<jam> bialix: I think qannotate just showed "loading" and that patch adds a progress bar
<jam> so that you could see how close it was to done
<jam> the progress  bar was commented out in the code
<jam> I just uncommented it, etc.
<jam> I don't know where that widget is used, etc.
<jam> I haven't focused on it in a while
<jam> but it was nicer at the time
<bialix> jam: ok thanks, I'll try to get a closer look on your changes, a bit later
<Garagoth> Hmm. I'm trying to fast-export an svn repository (to import it to Bazaar later), but exporting fails with: Can't create a character converter from 'UTF-8' to native encoding
<bialix> Garagoth: svn-import does not work for you?
<Garagoth> Not tried that yet.
<Garagoth> Is it part of bzr-svn ?
<bialix> yep, it's from bzr-svn
<Garagoth> Ok.. let me build that...
<konnertz> hi, i do a bzr st in my child branch and get
<konnertz> pending merges:
<konnertz> Peter Smith 2009-11-11 More stuff for ...
<konnertz> This info is available only in my parent branch , right?
<konnertz> so why is it shown to me?
<Lo-lan-do> You merged it but didn't commit it?
<konnertz> i should add, Peter is somebody else with his own branch and he is the main person reviewing the changes i bzr send to the main repo
<konnertz> so imo either he has merged all his changes to central repo or not
<konnertz> and if not, i dont need to see them!?
<Garagoth> bialix: bzr svn-import seems to work.
<Garagoth> Thanks.
<konnertz> is it understandable what i mean?
<konnertz> I cant do anything to clear the status
<Garagoth> bialix: I spoke too early... 'bzr: ERROR: Must end write group before releasing write lock on CHKInventoryRepository('file:///warlock/Bazaar/mudlib/mudlib/.bzr/repository/')
<bialix> Garagoth: something weird with your bzr
<bialix> Garagoth: what version of bzr you are using?
<Garagoth> 2.0.2
<Tak> when I do `bzr annotate` , I get a lot of revisions like "41.2.30" - is there any way to go from that to a "normal" revspec? (i.e. the ones shown in `bzr log`)
<bialix> Garagoth: and bzr-svn? 1.0.1?
<Garagoth> yes.
<Lo-lan-do> Tak: 41.2.30 is a normal revspec
<Lo-lan-do> Tak: It's just a revision that was committed as part of a merge
<bialix> Garagoth: something weird, but I have no idea what exactly.
<Lo-lan-do> Tak: You can see it if you "bzr log -n 2"
<Tak> hmm
<Garagoth> bialix: http://paste.ubuntu.com/323424/
<Garagoth> trace from that error, from .bzr.log
<bialix> Garagoth: it lloks like bzr-svn incorrectly working with bzr internals
<bialix> Garagoth: it seems it's not your day today :-/
<Garagoth> bialix: Should I post a bug report about this?
<bialix> yes, pleasd
<bialix> yes, please
<Garagoth> that would be third today... first day of bzr, and...
<bialix> Garagoth: don't give up!
<bialix> Garagoth: does there is something non-stadard in your system? filesystem?
<Garagoth> Ha. I have 219 svn revisions to import, each of about 80MB when targzipped...
<bialix> *non-standard
<Garagoth> filesystem is ext3
<Garagoth> on raid5
<Garagoth> and lvm on top of it
<bialix> Garagoth: does you svn repo have many branches?
<Garagoth> not a single one.
<bialix> can you try then just simple: bzr branch URL/to/svn
<bialix> what is lvm?
<Garagoth> logical volume manager
<smagoun> Is there a way to revert/uncommit a specific revision? Say my current tree is at r100, I want to revert r98. The catch is that r98 includes binary files, so I can't just do 'bzr diff -r97..98 > foo.patch && patch -R < foo.patch' or so.
<Garagoth> it is used to make 'partitions' on disks...
<Garagoth> bialix: bzr branch started similarly as svn-import (it scanned all revisions), and now it hangs on copying revision 0
<Garagoth> and svn repo starts from revision 1 ...
<bialix> Garagoth: my bad, use URL/to/svn/trunk
<bialix> smagoun: bzr merge -rN..N-1
<Garagoth> ah, no, there is revision 0, sorry. It is empty.
<smagoun> bialix: nifty, I'll try that. Thanks
<Garagoth> bialix: You mean URL to working copy or what...?
<bialix> Garagoth: no, I mean svn repo
<bialix> using your traceback from paste it should be like this: file:///repository/svn/mudlib/trunk
<Garagoth> bialix: There is no such thing.
<bialix> Garagoth: file:///repository/svn/mudlib/ <-- is it correct URL to your svn repo you want to convert?
<Garagoth> in repository/svn/mudlib I have:
<Garagoth> conf  dav  db  format  hooks  locks
<bialix> Garagoth: that's ok
<bialix> svn has inside virtual fs
<smagoun> bialix: so that didn't work - it tried to merge from a remote branch which I had previously merged into r50 or so of my current branch). "Merging from remembered submit location bzr:ssh://bazaar.launchpad.net/blahblah"
<jam> konnertz: doesn't "bzr revert" clear the status?
<bialix> smagoun: use . as merge source
<Tak> Lo-lan-do: cool, that helps - thanks! ( http://img265.imageshack.us/img265/5346/bzrannotatemerge.png )
<Garagoth> bialix: bzr: ERROR: Not a branch: "/repository/svn/mudlib/trunk".
<smagoun> bialix: seems to have done the trick - thank you
<smagoun> !
<bialix> Garagoth: I'm not very good in svn, but what URL you may use to run svn co ... ?
<Garagoth> Hmm... I was using it by svnserve... and I belive it was just: mudlib
<Garagoth> bialix: as svnserve was running from /repository/svn
<Garagoth> bialix: Yup. URL I was using was: svn://127.0.0.1/mudlib
<bialix> ok
<bialix> so run: bzr branch svn://127.0.0.1/mudlib
<Garagoth> Ahm. First I have to run svnserve.
<Garagoth> argh. Just a moment, I will set it up...
<Peng> What's the point of using svn://localhost? Why not just file://?
 * Peng sees backlog. Oh.
 * bialix not very good in svn
<bialix> Peng: can you suggest something? I'm almost out of ideas how to help Garagoth
<Garagoth> Peng: That is why I was trying with file://repository/svn/mudlib/ ...
<Tak> does svn+file://... work?
<Garagoth> Tak: in which command?
<Tak> bzr branch
<bialix> Garagoth: bzr branch svn+file
<Garagoth> bzr: ERROR: Invalid url supplied to transport: "svn+file:/repository/svn/mudlib"
<gdoubleu> I was trying to use svn+file yesterday when testing a checkout of a svn repo, but got the same error
<gdoubleu> https://bugs.launchpad.net/bzr-svn/+bug/485496
<ubottu> Launchpad bug 485496 in bzr-svn "checkout using svn+file protocol fails with invalid url error" [Undecided,New]
<Garagoth> but with file:///
<Garagoth> it started, but just hung at revision 0
<Garagoth> hang?
<Peng> Garagoth: Hung? How long? Was it really hung or was it still working?
<Peng> Garagoth: Is this a small repo or not?
<Garagoth> Peng: revision 0 is empty. Revision 1 has some data. It was copying revision 0 for 5 minutes or so, then I interrupted it.
<Garagoth> svn-import went thru rev 0 in less then second, completed rev 1, 2, and failed on rev 3
<konnertz> jam, ok yes it does. But there is a change in parent branch, i fetch with bzr merge
<konnertz> raising a criss-cross merge msg
<jam> konnertz: if you "bzr merge" you have to "bzr commit" that before it is recorded locally
<konnertz> i resolve the conflict manually
<konnertz> and the bzr st shows me the pending merge
<jam> criss-cross warning isn't harmfull, though doing "bzr merge --weave" will likely result in fewer conflicts in that situation
<jam> konnertz: you haven't committed the merge yet
<jam> so it will continue to tell you about it until you do
<konnertz> i see , moment
<konnertz> ok, bzr st is clear and bzr merge nothing to do,
<Lo-lan-do> jam: I was under the impression that --lca was more recommended than --weave, did I miss something?
<jam> Lo-lan-do: --weave was badly broken ~ 1 year ago, I've fixed it
<konnertz> now there's a bla.xy~1~ file
<jam> *I* prefer --weave to --lca
<jam> abentley probably would say the opposite
<Lo-lan-do> Heh
<jam> they have slightly different characteristics
<Lo-lan-do> Okay, I'll remember to try it next time I get criss-cross conflicts.
<jam> edge case handling, etc
<konnertz> ok same content as current file, i deleted
<abentley> Lo-lan-do: When two sides have resolved a merge differently, weave arbitrarily picks one side, lca conflicts.
<konnertz> i see, i'll check the other merge alg. next time
<Lo-lan-do> abentley: I see.
<Lo-lan-do> abentley: Which side is picked, if you remember offhand?
<abentley> Lo-lan-do: I don't remember which side is picked.  jam is likely to.
<jam> Lo-lan-do: things tend to depend on the order things were inserted into the weave. so merging a=>b may give a different result than b=>a.
<jam> However, IIRC there are also differences when you have 'multi-layered' crisscross issues
<jam> where weave takes into account more history than lca
<jam> which only looks at the immediate lca ancestors
<Lo-lan-do> That's way above my level of understanding of the innards of merges, but thanks anyway :-)
<jam> Lo-lan-do: as a short point: http://paste.ubuntu.com/323450/
<jam> D supersedes both B & C, so if there is a conflict between D & E
<jam> but the line in E clearly comes from B or C
<jam> then D should win
<jam> "clearly" I think is at least partially up for debate
<Lo-lan-do> Sounds reasonable.
<jam> --lca only looks at D & E, so it can't directly tell
<jam> However, Aaron's comment is that if D picks B and E picks C
<jam> then weave may not conflict
<jam> and just "pick B" or something
<jam> if you look at: http://revctrl.org/CrissCrossMerge#orderingambiguities%3Aordering
<Lo-lan-do> Hmm.
<jam> under "Simple Weave Merge" it describes one of the "accidentally clean" failures of weave merging
<Garagoth> bialix, Peng: FYI, svn-import svn://127.0.0.1/mudlib failed with same error on revision 3
<jam> I'm not positive if "bzr merge --weave" suffers from this, but it probably does
<bialix> Garagoth: jelmer is the author of bzr-svn and main wizard of it.
<bialix> I'd ask him about your problem
<Garagoth> bialix: And where can I find him...?
<Peng> I want to push 2 (unstacked) copies of the same branch to LP. Any way to do it without having to upload everything twice?
<bialix> Garagoth: usually he appears on this channel very often, but rightn now IIUC he's on UDS
<Peng> Hmm. Does LP mind if I stack on something other than the development focus branch?
<bialix> try to send mail to main bzr ML
<Garagoth> bialix: I am im middle of reporting a bug in bzr-svn, shall I continue?
<bialix> yes, he will receive that too
<Garagoth> ok
<bialix> Garagoth: jelmer just entered the building! magic!
<bialix> hi jelmer, we waiting you :-)
<Garagoth> Hmmm.... now svn-import (another try) hangs in revision 0... uses 96% of cpu, some io...
<Garagoth> jelmer: Hi. Could you please have a look at: http://paste.ubuntu.com/323424/
<jelmer> bialix: uhm.. hi :-)
<bialix> :-D
<jelmer> Garagoth, is this using the latest version of bzr-svn?
<Garagoth> 1.0.1
<jelmer> Garagoth, is the repository you're trying to import public?
<Garagoth> No.
<jelmer> Garagoth: The error you are seeing is masking the actual error
<jelmer> Garagoth: in fetch.py:1290 please put "pass" rather than self.target.unlock() and try again
<Peng> FYI: The answer is no, it does not mind. Probably; I haven't fully tested it. That makes sense, since the development focus branch can be changed, and IIRC old stacked branches will not be updated.
<jelmer> jam: hi
<jam> hey jelmer
<jelmer> jam: Is there a particular reason why bzr only supports stacking on the source branch from the UI?
<jelmer> jam: Preventing users from shooting themselves in the foot?
<jam> no clearly defined way of specifying something else?
<jam> not really sure
 * Peng has steel boots on to prevent that. :)
<jam> jelmer: 'bzr push --stacked-on ..."  allows you to specify a location
<jam> I assume you could do something similar for 'bzr branch'
<jam> however, I think the goal is to limit stacking a bit
<jam> since the branch must always be available ,etc.
<Garagoth> jelmer: Ok, will try in a moment... I lifted memory limits and executed it again, now it is thinking very hard on revision 3...
<Garagoth> Hm, went to 4th rev
<jelmer> jam: Thanks
<Garagoth> jelmer: Maybe it run out of memory (had 512MB limit), not it allocated 930 MB and is still working.
<Garagoth> jelmer: Is that possible?
<jelmer> could be - how much data is in that repo?
<Garagoth> jelmer: rev1 is 57MB, rev2 is 5MB, rev3 is 2MB
<bialix> Garagoth: so what was non-standard in your system! memory limiter
<bialix> I feel this
<bialix> too much very strange errors here and there
<bialix> Garagoth: maybe without hard limits you can manage fast-import to work too
<Garagoth> bialix: Well, that is why I increased it to 1GB
<Garagoth> But anyway, error is VERY misleading
<jelmer> Garagoth, odd, it shouldn't be using that much memory in that case
<bialix> because you have out of memory and error reporter failed to create right leading message :-)
<Garagoth> jelmer: Well, stands still at 750MB virtual mem and 200MB res
<Garagoth> maybe not that still. 762MB now.
<jam> bialix: lp:///~jameinel/bzr/2.1.0b4-485771-win32-nostar-noglob
<jam> once it finishes pushing
<Garagoth> Hm, just finished with rev 4, started copying rev 5
<Garagoth> jelmer: Do you want that error from paste.ubuntu filed as a bug report?
<bialix> jam: cool, thanks!
<Peng> What makes a branch stacked? Presence of stacked_on_location in branch.conf?
<Peng> Anything else?
<jelmer> Garagoth, what was the actual error you got when you replaced that line?
<Garagoth> jelmer: What do you mean: replaced that line?
<jam> bialix: looking at the code, it was clearly wrong
<jam> as it would replace all '\' with '/' even in quoted messages, etc.
<bialix> ouch!
<jam> https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b4-485771-win32-nostar-noglob/+merge/15094
<Garagoth> jelmer: I pasted what I found in .bzr.log, on console I only got last message (BzrError: Must end write group before releasing write lock ...)
<Peng> I think my stacking experiment failed.
<jelmer> Garagoth: see my comment earlier
<bialix> jam: bb:approve :-)
<jelmer> <jelmer> Garagoth: The error you are seeing is masking the actual error
<jelmer>  Garagoth: in fetch.py:1290 please put "pass" rather than self.target.unlock() and try again
<MvG> "pydoc -p", the python documentation http server, fails to serve documentation for e.g. bzrlib.branch. Is it just me, is pydoc broken, or is bzr doing something particularly fishy?
<Garagoth> jelmer: Ahm. Just a sec, I will lower memory limit back to 512MB and try again. Can I simply edit file in /usr/lib/python... ?
<Peng> Never mind. "bzr check" is just confusing: It gives the local repository URL even when checking revisions in the stacked-on repo.
<Peng> fallback repo. Whatever.
<jelmer> Garagoth: Yeah
<bialix> MvG: I'd say bzrlib
<MvG> OK, probably not worth fixing, so I'll stick to ascii pydoc.
<Garagoth> jelmer: Ok. Thais might take a while, I'm waiting for current process to interrupt (it does not end immediately on Ctrl-C) and the run again, revs 1 and 2 take about 5 minutes to import...
<Garagoth> jelmer: And it allocated 850 virt, 200 res at this moment...
<Garagoth> jelmer: in MB
<bialix> MvG: you may find useful http://starship.python.net/crew/mwh/bzrlibapi/
<bialix> MvG: IIRC there is problems with lazy_imports which used pretty heavily inside bzrlib
<MvG> bialix: That link indeed looks useful, thanks!
<bialix> :-)
 * bialix hopes to look at new trac-bzr soon
<MvG> bialix: just trying to fix "view changeset by revis, without naming a branch" behaviour...
<Garagoth> jelmer: Why it is spending so much time on copying revisio 0? It is empty...
<bialix> MvG: I just need to get some free time to upgrade our trac install at work, my remark just "sigh"
<MvG> As of an hour ago, I've got a working apache setup running on my local machine and serving both trac 0.10 and trac 0.11... And in CGI mode, which will make development faster than with the fcgi I used before, where I had to restart apache after every modification.
<jelmer> Garagoth, it should be fairly quick processing rev0
<Garagoth> jelmer: strange. First try I ever made was fast. Each of next ones takes forever.
<bialix> MvG: so I can try to hope that 0.10 will be supported more or less well?
<bialix> cool
<Garagoth> jelmer: And it allocated 478MB already
<Garagoth> still at rev 0
<Garagoth> Aha!
<Garagoth> jelmer: Failed with: MemoryError
<jelmer> Garagoth: Still at rev0 ?
<jelmer> Garagoth, There is something going very wrong there....
<MvG> bialix: YOu at least have a chance that all improvements I do that will work for 0.10 are incorporated into a 0.10 branch, and that I won't commit stuff to that branch that doesn't work for 0.10. At least in cases where "works" is easy to see.
<Garagoth> jelmer: Ok, what can I show to you then?
<bialix> MvG: cool, thank you!
<Garagoth> jelmer: http://paste.ubuntu.com/323495/
<jelmer> Garagoth, that doesn't help much unfortunately
<jelmer> Garagoth, what distro are you using?
<Garagoth> Archlinix
<Garagoth> Archlinux*
<jelmer> Garagoth: does "bzr selftest bzrlib.plugins.svn" work?
<Garagoth> jelmer: executing...
<Garagoth> 240 tests done, 84MB allocated...
<jelmer> vila: ping
<Garagoth> jelmer: Ran 1288 tests in 200.115s, OK (known_failures=2), 46 tests skipped, tests passed.
<CoffeeIV> I am moving a working directory (checked out) and the branch it was checked out from, to a new directory.  Is the .bzr/branch/branch.conf the only file I have to edit to point the working directory to the new branch ?
<maxb> I think so
<CoffeeIV> ok . . . I made backups so I guess I will try it and find out
<abentley> jam: I'm pretty sure weave merge does suffer from it.  I'm pretty sure mysql wanted that.
<jam> abentley: so the specific cases I debugged were cases where there was a double-criss-cross and the fallback had a clear resolution on one side
<jam> but yes, that could also be true
<abentley> jam: Oh, I thought that each side of the criss-cross kept resolving the conflicts in their favour, and they wanted a merge that would do that automatically.
<echos> How do I remove a symbolic link from commit tree?
<echos> I'm using bzr remove but it doesn't seem to be working at all
<echos> I'm getting ERROR: * is not in the same branch as *
<maxb> That's a really weird error
<maxb> Oh
<maxb> Are you removing part of the error and replacing it with * for IRC?
<maxb> Please don't
<jam> echos: rm symlink ; bzr rm
<jam> 'bzr rm' should remove any file that was versioned but is no longer present
<Saktoth> Hey folks. Any idea what this means? Im totally clueless:
<Saktoth> C:\Program Files\2awr>bzr up
<Saktoth> Unable to load plugin u'rebase'. It requested API version (2, 0, 0) of module <m
<Saktoth> odule 'bzrlib' from 'C:\Program Files\Bazaar\lib\library.zip\bzrlib\__init__.pyo
<Saktoth> '> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 0)
<Saktoth> bzr: ERROR: No WorkingTree exists for "file:///C:/Program%20Files/2awr/.bzr/chec
<Saktoth> kout/".
<lifeless> it means you need a newer bzr-rebase plugin. Its called bzr-rewrite now.
<Saktoth> How do i get that? Get the test release? Latest stable? or do i need to download the plugin seperately?
<joaopinto> hello
<jml> hey
<jml> we're writing useful Python code snippets into a gobby session
<jml> at desktop-code-snip-party
<ub3rst4r> hi, i was wondering what the difference between update and merge is, and why i have to do merge instead update when i go to work on the code
<fullermd> Update updates your working tree to match its branch.  Merge brings changes over from another branch.
<ub3rst4r> k
<ub3rst4r> so why do i need to use merge?
<mwhudson> hm!
<mwhudson> abentley: are you still here?
<fullermd> I...   don't know.  That's like asking "why do I have to drive downtown?"  If you have to go downtown, then you have to because you have to; if you don't, you don't...
<ub3rst4r> i thought there was a way on launchpad to change how to manage the code when working with multiple accounts
<mwhudson> if you have people doing development in parallel you're likely to have to merge at some point
<mwhudson> unless you all use checkouts
<ub3rst4r> i sort of dont understand it
<ub3rst4r> do u need to run the merge command everytime u go to work on the code?
<fullermd> Well, merge/update/etc don't really have anything to do with LP...  's all about what branches you have where.
<mwhudson> ub3rst4r: i work in the 'feature branches' model
<mwhudson> so all commits to trunk are merges
<ub3rst4r> ?
<mwhudson> ub3rst4r: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/organizing_your_workspace.html#feature-branches
<mwhudson> ub3rst4r: reading this whole page may do you a lot of good, i'd guess
<fullermd> You may want to look over http://bazaar-vcs.org/MatthewFuller/AboutPushPullMerge as well; it sounds like you're not really clear on which pieces you're putting where.
#bzr 2009-11-21
<mwhudson> btw, the bzrlib changes to enforce test isolation break 50 or so lauchpad tests
<mwhudson> keeping up the tradition that it's test infrastructure changes that usually inhibit launchpad's attempts to upgrade bzr
<lifeless> mwhudson: sorry :)
<lifeless> mwhudson: OTOH test isolation is pretty important
<mwhudson> yeah
<lifeless> mwhudson: btw, its saturday
<mwhudson> in fact it's doing a good job of highlighting bits of launchpad that we'd need to fix to allow running the test suite in parallel on one machine
<mwhudson> lifeless: swap day
<ub3rst4r> ahh i c
<ub3rst4r> so i should use pull to update the code when ive been working on it?
<mwhudson> without a better description of what
<mwhudson> argh
<mwhudson> ub3rst4r: i think " That's like asking "why do I have to drive downtown?"  If you have to go downtown, then you have to because you have to; if you don't, you don't" applies to that question too
<fullermd> The long answer is "it depends on what you're trying to do".  The short one is "If you _can_, yes, probably"
<ub3rst4r> thanks
 * mwhudson has a hating multiple inheritance moment
<fullermd> That's no way to honor thy father and thy mother.
<lifeless> mwhudson: how is it doing that ? [highlighting]
<mwhudson> lifeless: because many (not all) of the isolation violations are where the tests are accessing hard coded paths
<mwhudson> of course lots of the others are tests that create temporary directories by means other than the test infrastructure
<lifeless> mwhudson: :)
<MTecknology> I wish I could revision control puzzles - My mom was almost done with one and I knocked it on the floor
<GastonBorys> hi people
<GastonBorys> how should I do to work group with bazaar?
<bob2> have you read the workflow section of the documentation?
<GastonBorys> yes, but i'm not understand everything
<bob2> which bits?
<GastonBorys> when i change same file and do commit, later sould be make a push
<GastonBorys> okey, so perfect here... but later?
<GastonBorys> how can i do a merge from other computer
<GastonBorys> bzr merge
<GastonBorys> bzr commit
<GastonBorys> this is all?
<mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/464174 is stabbing me in the face :(
<ubottu> Launchpad bug 464174 in bzr "TestWithMemoryTransport sets $BZR_HOME to a unicode string" [Undecided,New]
<MTecknology> I'm happy I no longer use clarke
<Kamping_Kaiser> is there something equivilent to 'bzr revision' (eg, i just want the currentn commit number)
<lifeless> bzr revno
<Kamping_Kaiser> fab, thanks a lot :)
<nyu> hi
<nyu> how do I join two branches with no common ancestor?  (and no common files)
<LarstiQ> nyu: merge -r 0..-1
<nyu> LarstiQ: what's -1?
<nyu> last rev?
<LarstiQ> nyu: yes, and 0 is the null revision
<LarstiQ> nyu: - indexes from the end, so `bzr log -r -3..-1` would show you the log of the last 3 mainline revisisons
<nyu> great, thanks
<maxb> The BzrMigration page notes three possibilities for svn to bzr conversion: svn2bzr - two forks thereof, and bzr-svn. Is there guidance on how to choose which to use?
<bob2> do you want on-going bidirectional support?
<maxb> It's not a hard requirement
<maxb> I can arrange for a stop-the-world migration if the end result is better
<nyu> maxb: I recommend fast-export-from-svn
<nyu> bidirection support with bzr-svn may result in data corruption
<maxb> nyu: thankyou that looks promising.
<LarstiQ> nyu: oh?
<nyu> LarstiQ: I hit this twice
<maxb> nyu: More details please? :-)
<nyu> maxb: I filed a bug in LP
<chx_> hi. i was wondering whether it would be possible / feasible / desirable to integrate trac-bzr-loggerhead together.
<chx_>  a post commit hook that posts to trac and an apache rewirte rule so that the commit linking to the bzr source viewer ties into loggerhead instead.
<OldAl> Anyone out there on the "ether"?
<OldAl> Speifically, is Patrick Regan there?
<jpds> OldAl: That would be rubbs.
<rubbs> jpds: that's right. Sorry for being late. OldAl found me in a private chate
<jpds> rubbs: Oh right, sorry.
<rubbs> jpds: no problem. You didn't know. and I didn't show "publicly" that I found him.
<OldAl> So there are people in the bzr chat room!
#bzr 2009-11-22
<OldAl> I see Patrick is still online - is that correct?  I am still in the bzr chat room.
<Peng> Am I doing something dumb, or is BzrDir.create_branch_and_repo('foo') supposed to raise a KeyError?
<Peng> (Seems the format argument is less than optional.)
<lifeless> Peng: I imagine you're doing something unusual
<lifeless> or its broken
<Peng> D'oh. Of course it works now when I try to reproduce it. :|
 * Peng watches get_parent_map try to figure out that the repo is empty.
<Peng> I can't reproduce it now. :\
<Peng> The target *may* have already had a .bzr directory in an odd state.
<Peng> No, wait, that raises a different error.
<Peng> Here's the traceback, FWIW: http://paste.pocoo.org/show/152176/
<lifeless> untested code path I imagine
<lifeless> file a bug please
<Peng> lifeless: filed bug #486535, fwiw
<ubottu> Launchpad bug 486535 in bzr "BzrDir._find_or_create_repository KeyError (bzr+ssh + stacking policy?)" [Undecided,New] https://launchpad.net/bugs/486535
<OldAl> Anyone there?
<OldAl> pidgin tells me there are 116 people in room, but there does not seem to be any activity, viz people coming or going, nor do I see my nick on the list...
<mwhudson> it's usually pretty quiet on the weekend
<lifeless> OldAl: it doesn't matter who is here or not
<lifeless> OldAl: everyone might be here, and noone able to answer your question. Just Ask.
<OldAl> ah, geat!
<OldAl> I only want to ascertain that I have connected to #bzr chat room.
<lifeless> pidgin is correct, you are connected ;)
<OldAl> where are you from, lifeless?
<OldAl> I am from Canberra
<OldAl> May I put you down as a buddy?
<lifeless> IRC isn't like IM networks
<lifeless> there isn't the same social-network / buddies aspect
<OldAl> Here is a question - when I connect, I get a message: (15:51:49) NickServ: (notice) OldAl is not a registered nickname.  So, should I a) ignore it b) register and if so where?
<lifeless> http://freenode.net/
<OldAl> But I have registered on freenode.net - else I would not be here, would I?
<lifeless> what do you mean by upgrade :)
<lifeless> sorry
<lifeless> by registered
<OldAl> Well, I did fill out some details and was able to connect under an OldAl nick, but it showed my real given name...
<OldAl> so I suspect that it was not complete or something.
<bob2> you register your nick by talking to nickserv using your irc client
<bob2> pidgin is not a very useful irc client
<lifeless> OldAl: so each time you connect you need to login
<lifeless> and that message says you haven't actually registered a usercode
<OldAl> OK, so what is the button to press to start registration?
<lifeless> http://freenode.net/faq.shtml#nicksetup
<OldAl> and, lifeless, did you have to type in "OldAl:" in your previous message?
<lifeless> no
<OldAl> so what is the smart way of getting that?
<lifeless> getting what ?
<bob2> irc clients tab complete nicks, so you type o<tab>
<OldAl> lifeless: OK :
<OldAl> lifeless: That's a great help.
<OldAl> lifeless: Many thanks for that.
<OldAl> lifeless: I do appreciate your help.  Will read up the FAQ on registration of a user name.
<lifeless> so actually, I was answering 'did I need to have OldAl present at the start of the message' with 'no'.
<lifeless> not how I went about putting it there :)\
<OldAl> lifeless: You wrote parts of FAQ for pidgin?
<lifeless> nope
<OldAl> lifeless: Oh, I was at cross purposes there - I am now using the tab - great "invention".
<OldAl> lifeless: Since my nick is apparently not registered. how can I talk to you?  Is it a temporary "registration"?
<bob2> this isn't IM
<bob2> registration just means that a) you're allowed in some channels that forbid unregistered users and b) you can kick off other people who use your nick
<OldAl> lifeless: Well, I don't know IM.
<lifeless> for a) bob2 meant 'not allowed in'...
<lifeless> OldAl: imagine that this is a table in a restraunt
<lifeless> when you are connected, you are at the table. And everyone here can hear everyone else.
<OldAl> lifeless: yap
<OldAl> fine
<lifeless> *if* you get an 'official' name badge, then you can grab someone and talk to them privately, and sit at some tables that require people to have official names
<OldAl> lifeless: But I have chatted with people already, in separate "table" (or room), as it were.
<mneptok> lifeless: missed you at UDS :(
<lifeless> mneptok: Swings and roundabouts
<lifeless> had stuff going on I would have had to shove around, and no specific things I needed to be at UDS for this time
<mneptok> and i thought we had something *special*
<mneptok> *sniff*
<lifeless> we do
<lifeless> I hear you made an unrepeatable quote
<lifeless> so bad only its existence hit the Quotes page
<mneptok> it wasn't that bad.
<mneptok> Keybuk likes to paint me as a greater rogue than i am. i think it's part of his rich fantasy life.
<lifeless> it wasn't Keybuk :)
<mneptok> hrmf. he said he had added it.
<mneptok> trying to make himself more attractive to me, i s'pose.
<lifeless> I think I'd need to go check I guess.
<mneptok> not that his rugged good looks and commit rights don't make him attractive enough.
<mwhudson> mneptok: i even clicked a link in your blog and didn't regret it too much!
<mneptok> mwhudson: oh nice! you got that Thorazine scrip and lobotomy you were asking for!
<mneptok> (or you're just insanely drunk)
<mwhudson> c'mon, the police aren't that bad
<mwhudson> (i am disturbingly hungover for 20:00 though :/)
<lifeless> mwhudson: hungover or drunk ?
<mwhudson> lifeless: hungover
<lifeless> wow
<mwhudson> i didn't even drink _that_ much last night :/
<mwhudson> getting old, it's terrible
<lifeless> sneaks up on ya
<mneptok> i have t-shirts older than both of you.
<chx_> hi. i was wondering whether it would be possible / feasible / desirable to integrate trac-bzr-loggerhead together.  I guess a post commit hook that posts to trac and an apache rewirte rule so that the commit linking to the bzr source viewer ties into loggerhead instead?
<lifeless> chx_: I don't know what that means
<lifeless> nor have any idea about whether it would be good or bad to do it.
<chx_> well, currently we use svn and commit messages (re #1234) post followups to tickets
<chx_> that's awesome
<chx_> The other part of the svn integration in trac is the source code browser
<chx_> that's what i was considering replacing with loggerhead.
<lifeless> so loggerhead showing svn?
<chx_> no, we are migrating to bzr
<chx_> oh now we are talking... anyone from Canonical here ?
<lifeless> yes
<lifeless> loggerhead can show svn btw
<lifeless> wonders of bzr-svn :)
<chx_> lifeless: pm?
<lifeless> I guess
<mneptok> oh no! the *bad* Monty!
 * mneptok hides
<lifeless> mneptok: does that make you the Full one?
<mneptok> lifeless: not if you can't be bothered to visit UDS.
<lifeless> mneptok: Sif a matter of botherment.
<kgoetz> stupid python, stop making bzr complain about my locale :(
<lifeless> kgoetz: install the locale data for it :)
<kgoetz> lifeless: I'm not aware of any en_AU.UTF-8 python packages ;)
<lifeless> kgoetz: its generally just missing langpacks, if you're on Ubuntu
<lifeless> or it can be a missing langpack on a server.
<kgoetz> nothing leaps out at me from the debian stable repos, so I might just put up with it
<lifeless> kgoetz: a ew questions
<lifeless> is it local or when pushing/pulling?
<kgoetz> its local. and the install is pretty minimal - its netinstall of debian+a handful of packages
<lifeless> check your local is being created
<lifeless> kgoetz: also please file a bug if this is happening with bzr installed from a package; we shouldn't behave wrong from a package
<kgoetz> lifeless: I don't follow - 'your local is being created'?
<kgoetz> oh, *smacks self*
<lifeless> kgoetz: I'll be afk for a bit, but it sounds like you've found a cluebat?
<kgoetz> lifeless: checking local setup atm.
<kgoetz> dpkg-reconfigure locales to the rescue.
<OldAl> Why is it so quiet here?
<OldAl> nobody wants to chat about bzr?
<kgoetz> OldAl: seems no one needs support ;) it is sunday...
<OldAl> kgoetz: No, it is not support - just signs of life!
<OldAl> kgoetz: and just tell me, is this the bzr chatroom? (I expect so, but just to be sure. yes/no will do :) )
<kgoetz> OldAl: I'm looking at my screen+scrollback, and i see lots of conversation
<OldAl> Well, it must be #bzr, I hope.
<OldAl> kgoetz: Sunday or not, I've just completed registering my nick - or so I hope.
<kgoetz> it would seem your identified, so yes, your registered
<OldAl> kgoetz: Thanks for that.
<kgoetz> *you're
<kgoetz> np. /whois OldAl to see
<OldAl> kgoetz: I will log off and leave you in peace!  Thanks for helping me to check what is going on
<kgoetz> OldAl: catch you nex time :)
<OldAl> me_too: Like your nick...
<OldAl> me_too: Are you watching the screen of bzr?
<OldAl> menesis: Hi there!
<OldAl> Actually it is a bit late for me - down under Canberra, the time is past midnight
<OldAl> Noldorin: Alex, where are you? (I am in Australia, Canberra)
<OldAl> Noldorin: irc informs me that you are on bzr, so ...
<matt_p> Hi, where is a downloadable version of the User Reference?
<matt_p> It can be viewed as a HTML, but there is no PDF version...
<GaryvdM> matt_p: http://doc.bazaar-vcs.org/bzr.2.0/downloads/
<GaryvdM> or http://doc.bazaar-vcs.org/bzr.dev/downloads/
<matt_p> GaryvdM: http://doc.bazaar-vcs.org/bzr.2.0/downloads/pdf-en/
<matt_p> GaryvdM: There is only the Quick Ref.
<matt_p> I need this: http://doc.bazaar-vcs.org/bzr.2.0/en/user-reference/index.html
<GaryvdM> http://doc.bazaar-vcs.org/bzr.2.0/downloads/pdf-en/bzr-en-user-guide.pdf ?
<matt_p> GaryvdM: It is User Guide, not User Reference
<GaryvdM> matt_p: It's the same thing as far as I can tell.
<matt_p> GaryvdM: So you mean that this http://doc.bazaar-vcs.org/bzr.2.0/en/user-guide/index.html and this http://doc.bazaar-vcs.org/bzr.2.0/en/user-reference/index.html are the same documents? :-)
<GaryvdM> matt_p: Sorry - I'm wrong. It's not the same.
<GaryvdM> matt_p: Sorry  - I don't know then.
<GaryvdM> matt_p: igc will know. But he will probably be asleep now. He is in Austraila
<matt_p> GaryvdM: OK, thanks.
<matt_p> Oh, I have a second question... I use Bzr and I understand its concepts as a user. But what is the right relation between branches and repositories? (Shared) repo contains the revisons in their physical forms and the branches only point to the relevant revisions?
<GaryvdM> matt_p: Yes. A branch has just a pointer to the latest revision, tags, and config
<gioele> matt_p: yes, repositories holds all the information: file contents, deltas, other common info
<GaryvdM> matt_p: A stand alone branch has a repository
<GaryvdM> *has it's own repository
<gioele> matt_p: http://bazaar-vcs.org/CategoryTerm
<GaryvdM> gioele: Nice collaboration :-)
<gioele> GaryvdM: :)
<matt_p> GaryvdM, gioele: great, thank you.
<gioele> matt_p: in particular the first sentence of http://bazaar-vcs.org/Branch
<pitseleh> hi, i'm trying to host a bazaar server
<pitseleh> so i start the server with bzr-2.6  server --directory=/mnt/md1/public/Glen/Repos
<pitseleh> and i can branch from it fine
<pitseleh> but when i try to push it tells me operation not possible: readonly transport
<pitseleh> pushing to bzr://ip/myrepo
<pitseleh> i'm obviously missing a step..
<GaryvdM> pitseleh: you need bzr server --allow-writes
<pitseleh> GaryvdM: ah, thanks for that :)
<pitseleh> works perfectly :D, wonderful
<Lo-lan-do> Hi jelmer :-)
<jelmer> hey Lo-lan-do
<Lo-lan-do> For some reason my changes don't work anymore.
<Lo-lan-do> (Even given the stretched value of "work" IÂ used)
<jelmer> Lo-lan-do: it might be nice to have some tests for this code first and figure out the right approach
<Lo-lan-do> Probably, yes.  Is there a tutorial on that, or should IÂ just read the existing tests?
<Lo-lan-do> Also, it might be a bit complex, since I'm trying to do git+ssh:// with a git clientâ¦
<jelmer> Lo-lan-do: There isn't anything like that at the moment, in fact I don't think we have any tests for the server side
<jelmer> you should be able to test with the git:// server though, since the protocol should be the same
<jelmer> testing with ssh will be trickier
<Lo-lan-do> I think maybe the "git proxy" configuration could help
<Lo-lan-do> Actually, $GIT_SSHÂ pointing at a custom script can do the trick :-)
<jelmer> Lo-lan-do: isn't that kinda hard to set up in the tests though?
<Lo-lan-do> I don't think so.  It's just an environment variable.
<Lo-lan-do> And a 30-line shell script.
<Lo-lan-do> http://pastebin.com/f1db8ac6c
<Lo-lan-do> Stick that in a script, point $GIT_SSHÂ at it, and there you go, git+ssh:// without ssh :-)
<Lo-lan-do> I'm off to dinner, but I'll probably start doing unit tests afterwards.
<eli_> hi, when you do 'bzr init' and then 'bzr add' it should add all subdirs. correct?
<eli_> the part is that when i do 'bzr status' i get a good chunck of unknown objects
<Lo-lan-do> Objects that were created later on?
<eli_> even doing 'bzr add foldername' and then do 'bzr status' the foldername will still show up under unknown
<eli_> nope, the objects are already there
<eli_> it only adds two directories out of about 10
<eli_> that is not how bzr normally acts. right?
<beuno> eli_, that is not expected behavior, no
<LarstiQ> it should either add or ignore, no unknowns
<eli_> hmm
<eli_> it even treats .bzrignore as an unknown
<LarstiQ> that can happen
<eli_> i'm using version 2.0.1
<LarstiQ> if you manually create the file
<LarstiQ> without using `bzr ignore`
<LarstiQ> eli_: it's not perchance already versioned? (Different vcs maybe)
<eli_> you mean having .svn in the subdirs?
<LarstiQ> eli_: oh, that might explain it
<LarstiQ> eli_: if you also have bzr-svn installed that is
<eli_> LarstiQ, i think your suggestion may have hit it.
<eli_> It was not .svn, there were .bzr in each subdir
<LarstiQ> yeah
<eli_> bingo, adding everything now :)
<eli_> Thanks!
<LarstiQ> that is indeed a case I forgot that will result in unknown dirs :)
<LarstiQ> eli_: cheers!
<eli_> is there a way to list just the unkowns in bzr?
<LarstiQ> `bzr ls --unknowns`
<LarstiQ> optionally with -R
<eli_> excellent. bzr is already proving much more handy than hg and svn :)
<LarstiQ> I'm glad to hear that :)
<LarstiQ> though a bit surprised perhaps, how is hg lacking?
<eli_> hg is creates larger histories than bzr. at least in my case
<chx_> So yeah i was trying to research hg vs bzr vs git (not in speed) for recetn versions and ... hmm...
<GaryvdM> chx_: and ?
<chx_> empty/
<chx_> i cant find anything
<LarstiQ> chx_: http://bazaar-vcs.org/Benchmarks ?
<chx_> as said, not in speed
<chx_> we can simply take it granted they are all fast.
<LarstiQ> chx_: no, this is disk space
<GaryvdM> chx_: http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html
<GaryvdM> chx_: Both my url, and LarstiQ's are up to date documents.
<chx_> oh
<chx_> the latter is very nice
<chx_> how come i couldnt find it this with google
<LarstiQ> chx_: what did you google on?
<GaryvdM> I found it with http://www.google.com/search?q=why+bzr , But I knew the name of the doc.
<chx_> bzr git comparison
<chx_> bzr vs git
<chx_> I am reading this
<chx_> and though i myself am using bzr since long, i find interesting pieces
<chx_> how do i create a bound branch?
<GaryvdM> chx_ bzr checkout
<chx_> oh that
<chx_> i see.
<GaryvdM> chx_: or if you allready have a branch, bzr bind
<chx_> nice
<chx_> another question , hardlinks
<chx_>   --hardlink            Hard-link working tree files where possible.
<chx_> i see that
<chx_> this hardlinks files inside .bzr i presume?
<GaryvdM> I'm not sure
<Peng> It explicitly says "working tree files", so probably not.
<LarstiQ> 'working tree' suggest otherwise, but I don't know what it does
<LarstiQ> hey Peng ;)
<chx_> huh that would be nice but challenging what happens if someone edits one such file...?
<Peng> chx_: Yeah. If your text editor doesn't break links, it won't work for you. That's why it's not the default.
<chx_> Peng: and which editors breaks...?
<Peng> chx_: No idea!
<LarstiQ> vim breaks hardlinks, so that should work
<LarstiQ> I'm sure emacs can too
<chx_> it would need to save the file under a diff name , rm the oriiginal and mv back
<chx_> i presume that's not hard.
<Peng> It's a nice way of making the write a bit safer, too.
<eli_> is there a way to have bzr to not create histories of binary files?
<eli_> rather than an outright ignore?
<eli_> for example, i have several subdirs with binaries and scripts
<eli_> i would like to version control the scripts
<eli_> but not the binaries.
<eli_> but, if i do push or pull with bzr i'd like to have the binaries move between systems
<eli_> probably sounds like a dream, but that would well for me
<LarstiQ> nope, something is either versioned or not.
<LarstiQ> (likewise, there is no 'precious' class of unknowns)
<LarstiQ> eli_: you fear the binaries would take up a lot of space?
<eli_> yep
<eli_> tons
<eli_> but i do need them synced between two computers
<eli_> and keep version control on the scripts
<LarstiQ> can the binaries be generated from something else?
<eli_> nope, the binaries are data files. they are not dynamically generated
<LarstiQ> ok
<LarstiQ> could you maybe version them in a separate branch?
<LarstiQ> and have symlinks in the original?
<eli_> that would seperate out the binaries from the scripts
<eli_> generating the symlinks would be the next complication. we're talking +10,000 binaries
<LarstiQ> woha
<eli_> yeah, lots
<LarstiQ> not your typical usecase :)
<eli_> nope ;)
<eli_> would it be possible to do a layer of rsync with bzr?
<eli_> rsync for the binaries
<LarstiQ> you could maybe hack up a plugin (based push-and-update?) to do something like that
<eli_> and bzr for version control
<LarstiQ> eli_: yeah
<eli_> even with the binaries in the same dirs as the scripts?
<LarstiQ> yes
<eli_> hmmm
<eli_> that would work then
<LarstiQ> it would be a plugin tailored to your workflow
<LarstiQ> (or more general if you wish)
<eli_> i know quite a few people in my field who would use such a workflow
<eli_> ill write it up then
<eli_> thanks for your help in brainstorming on this :)
<eli_> adios!
<LarstiQ> eli_: http://doc.bazaar-vcs.org/plugins/en/push_and_update-plugin.html is what I'd start with
<eli_> Thanks
<eli_> will looks into
<maxb> I am not familiar with the bzr test system. Can anyone suggest what I should look into when a test 'fails'  because it starts thinking normal progress messages are errors?
<maxb> errors:
<maxb> 'All changes applied successfully.\nCommitting to: /tmp/testbzr-LDqLMO.tmp/bzrlib.plugins.rebase.test_blackbox.TestRebaseSimple.test_rebase_merge/work/main/feature/\nCommitted revision 3.\nAll changes applied successfully.\nCommitting to: /tmp/testbzr-LDqLMO.tmp/bzrlib.plugins.rebase.test_blackbox.TestRebaseSimple.test_rebase_merge/work/main/feature/\nCommitted revision 3.\nAll changes applied successfully.\nCommitting to: /tmp/testbzr-LDqLMO.tmp/bzrlib.plugins.re
<maxb> base.test_blackbox.TestRebaseSimple.test_rebase_merge/work/main/feature/\nCommitted revision 4.\nAll changes applied successfully.\nCommitting to: /tmp/testbzr-LDqLMO.tmp/bzrlib.plugins.rebase.test_blackbox.TestRebaseSimple.test_rebase_merge/work/main/feature/\nCommitted revision 5.\n'
<LarstiQ> that's a bit unreadable
<LarstiQ> maxb: but blackbox tests especially look at the output the cli produces
<LarstiQ> if that doesn't match with what the test expect, it flags
<lifeless> maxb: ask 'is the new output what I want'?
<lifeless> maxb: if yes, change the test. If no, change your code.
<maxb> hmm. I wonder why I am getting stderr output when before there was none at all
<maxb> All I've done is change rebase parent selection logic
<igc> morning
<OldAl> igc: good morning.
<OldAl> poolie: top of the morning, to you too.
<poolie> hello
<OldAl> poolie: Strange, but have no questions to  ask right now...
<igc> hi poolie
<poolie> hi igc
<poolie> spiv, hi?
<igc> OldAl: so pull, merge and push are all in handled in the one qbzr module IIRC
<igc> OldAl: bound branch or otherwise, pull is the way to update a local mirror
<igc> so it's pretty useful
<OldAl> igc: I am sure it is.
<igc> OldAl: so starting on a small change to qpull is a good, safe way of beginning qbzr hacking
<OldAl> Have 'they' (who?) used gtk or Qt for the GUI of qrun?
<OldAl> I would prefer to put my hands into Qt rather than gtk
<igc> OldAl: any command startng with 'q' is Qt based, not Gtk
<OldAl> igc: Ah, great!
<OldAl> igc: that puts my mind at ease on that score.
<igc> OldAL: one more social thing: in open source, we value self-selection over central assignment
<igc> so me assigning bits of work to people isn't the way to go
<OldAl> igc: I know tha well.
<OldAl> igc: Why not suggest stuff to start on - individually.  Nobody should mind suggestions...
<igc> instead, I ask for volunteers, people enter changes in our bug/wishlist tracker and assign them to themselves instead
<OldAl> igc: not if they want to work on it.
<igc> OldAl: sure, individual suggestion for people keen to get started in excellent
<igc> that's why I'm suggesting you working on qpul first :-)
<igc> OldAl: I'll raise the minor bug I'm thnking of now
<OldAl> igc: I gather that and am happy to look at.  But then there is a bigger question of how to get
<OldAl> igc: things to speed up in the "documentation" group and I thought I would make a suggestion - to you :)
<OldAl> igc: But I don't want to do it in public before I suss out if you would be agreable.
<OldAl> igc: No conspiracies - but just that I don't want to be too big a PITA with suggesting something that my appear as extra work.
<OldAl> igc: If you are satisfied with the response, that is fine: if not, then there is a suggestion that I want to make, if agreeable to YOU, as it would affect you if you accept it.
<igc> OldAl: here's the bug you could work on: bug 486843
<ubottu> Launchpad bug 486843 in qbzr ""learning help" in qpull is too verbose" [Undecided,New] https://launchpad.net/bugs/486843
<igc> OldAl: don't worry about public suggestions being a PITA
<igc> OldAl: even if I don't agree, someone else may step up and do it or refine your idea
<igc> OldAl: if in any doubt, favour open communication over private emails and IRC chats
<OldAl> ubottu: Thanks for the bug 486843. "Being too verbose" is my problem, usually. I do feel that verbosity is superior to lack of clarity.
<ubottu> Launchpad bug 486843 in qbzr ""learning help" in qpull is too verbose" [Undecided,New] https://launchpad.net/bugs/486843
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<OldAl> ubottu: So who is the midget inside of you? (Reminds me of a chess playing "machine")
<igc> OldAl: ubottu really is code, not a person
<OldAl> igc: I am in agreement with "public" preference to "private".  Alas, some things, like disabilities, may want to be kept private.
<igc> OldAl: very useful though - just say "bug xxx" and ubutto will display the bug summary
<igc> OldAl: right. Personal stuff is best kept personal
<igc> and private
<OldAl> igc: xxx is the number?
<igc> yep
<igc> just #xxx might be enough as well
<igc> iirc
<OldAl> igc: Actually, I don't mind to talk about *my* disabilities, but what I do - or do not do - affect the disabilities of others and that I want to keep private.
<OldAl> igc: also things like my experience and qualifications - it is rather a long list and requires explanation, but I feel it would be helpful to know for people that may try to get something useful done by me...
<OldAl> igc: Basically, again I try not to be a PITA, seldom successfully.
<OldAl> igc: Clarify: my tries at avoiding being a PITA are seldom successful.
<igc> OldAl: so my suggestion is to create a Wiki page or blog with your experience and skills. See http://ianclatworthy.wordpress.com/about/ for an example
<OldAl> igc: Just looked at your blog. Impressive! I guess for me it would be easiest to make something vaguely similar in my home page on PCUG and just pass on the open address, which, however, is not obvious to casual visitors (like there are no links to it in the face page.)
<OldAl> igc: clarification: PCUG is the PC Users Group in Canberra, very supportive of ONE OS, though not from the bunch of people who run the Internet Service, the admins.  (The admins are very supportive of their independence of any elected bodies of PCUG :) )
<OldAl> igc: My last  sentence is clear as mud...
<igc> OldAl: sure. Or add http://bazaar-vcs.org/OldAl
<OldAl> igc: OK, that is simpler!  Easier to see for anyone that may be interested in my experience and qualifications.  Will give it a good run!
<OldAl> igc: Thanks - have a call from my real boss!
<spiv> Good morning.
<igc> hi spiv
<poolie> hello spiv
<poolie> spiv, enquiring minds want to know about the patch pilot project :)
<lifeless> poolie: well I'm on this week
<lifeless> in my personal time
<poolie> i know
<poolie> i am obliquely asking spiv to send a mail about how the first week went
<spiv> poolie: composing mail about that :)
<poolie> :)
<poolie> thanks for doing it this week lifeless
<lifeless> spiv: be sure to call for more folk
<spiv> lifeless: good idea
<jdub> what's the sanest way to get a recent bzr for RHEL? EPEL appears to have 1.3
<jdub> somehow this system has 1.5, but i dunno where from
<lifeless> jdub: wget the tar
<mlh> jdub: IF you wanted an rpm ANd you were comfortablish with src.rpms, you could try the src.rpm for F12 (which is bzr 2.0.2)
#bzr 2010-11-22
* spiv changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila | Hooray for jelmer
<spiv> poolie: btw, remembering a conversation from Thursday, removing say the old CHK1 and CHK2 formats would cut about 30s (of 10m) from selftest (forking on 4 cores).
<lifeless> spiv: I had a branch to drop a bunch of formats way back... doit
<spiv> poolie: and also, the subunit tools failed to help me determine that :(
<lifeless> spiv: they did?
<lifeless> spiv: there was a timing bug with --parallel that mgz fixed
<spiv> lifeless: yeah, I need to dig, but e.g. the obvious subunit-filter --match invocation seemed to drop way more tests than is reasonable.
<poolie> spiv, i kind of suspect they will become buggy once they're moved out
<poolie> thanks for the data
<spiv> poolie: well, they are old dev formats: I was thinking of deleting them entirely.
<poolie> there are options: do nothing; just delete them; move them to a plugin; leave them in but untested by default
<poolie> i think that's best too
<lifeless> exactly, nuke and forget
<spiv> I think I'd be against in-but-untested.
<poolie> i don't think splitting to a plugin will be worth the current and ongoing work
<poolie> make sure it's in whatsnew
<poolie> and maybe post to the blog
<spiv> Right: we have old releases for anyone sufficiently desperate.
<poolie> with clear text about them only being dev formats
<lifeless> we've done this before with less drama :)
<lifeless> just noting
<init> hello
<init> question: is it possible to get CIA working with bzr_access?
<poolie> i think so; not sure
<poolie> a link to a zip holding an MS Write file
<poolie> :?
<poolie> spiv, i'm thinking of doing a 2.2.2 this week
<poolie> night all
<peitschie_> night poolie
<zyga> lifeless, ping
<zyga> lifeless, could you please review my merge of testtools.TestCase, testscenarios.TestWithScenarios and django.test.TestCase (+TransactionTestCase)
<dstuart> Quick question, I have two separate active subversion instances that I wish to use bzr to merge the changes into one consolidated branch and then push back to only one of the subversion servers. Is this possible?
<lifeless> zyga: link ?
<zyga> lifeless, just a second
<zyga> lifeless, https://code.launchpad.net/~zkrynicki/django-testscenarios/0.2/+merge/41474
<zyga> lifeless, you can just look at the part relevant to init.py where the code actually lives\\
<zyga> lifeless, and disregard everything else
<zyga> lifeless, http://bazaar.launchpad.net/~zkrynicki/django-testscenarios/0.2/annotate/head%3A/django_testscenarios/__init__.py
<lifeless> zyga: cool stuff, I've added what comments I have to it.
<zyga> lifeless, thanks :)
<zyga> lifeless, actually there is no redundancy there, django cheated a little bit in how it setups testing environment
<zyga> lifeless, that made it not work with trivial inheritance
<zyga> lifeless, or perhaps I misunderstood you somehow
<lifeless> zyga: Well, I saw that the methods are different
<lifeless> but they are about 80% the same
<zyga> lifeless, you mean the if scenarios part?
<lifeless> yah
<lifeless> if you ever need to change it, you've got two places to do it
<zyga> I see what you mean, I did not find any way to make it shorter that would still work with django, there's a nasty interplay of __calL__ and run() that happens otherwise
<lifeless> yeah
<lifeless> I could tell :)
<sladen> bzr commit  locally tells me that it can't lock a remote lockfile
<lifeless> testtools has a nice thing called RunTest which could in principle handle the scenarios glue for you - and the django transaction stuff, but its likely a little complex to get established
<sladen> lifeless tells me this is because I don't have a full branch
<sladen> so two questions (a) what's the workaround to turn whatever I have into something that I can commit to
<sladen>         and (b) what would be the best jargon to file a bug that users should not need to know the difference and it should always "just work"
<jam> sladen: if you did "bzr co --lightweight" you explicitly asked for something that did not have a branch of its own (--lightweight)
<jam> bzr reconfigure --standalone ? will probably get you a full branch locally
<jam> probably you'll want to check "bzr help reconfigure" as there are a few options
<sladen> jam: don't recall having done --lightwieght at any point, hence puzzled
<sladen> jam: bzr: ERROR: ... is already standalone.
<lifeless> sladen: I said 'you hav a checkout of some sort' - I don't have a crystal ball to infer lightweight or not
<lifeless> sladen: I contrasted that with 'struely independent branch'
<lifeless> sladen: truely independent is not a synonym for full.
<lifeless> sladen: did you do 'bzr co'
<jam> sladen: sorry, "checkout" implies that commiting here will commit there
<jam> if you have a non lightweight checkout, then you can "bzr unbind".
<lifeless> sladen: As for a bug, there is already a general thing to overhaul the user experience vis-a-vis  workflow and defaults, I don't think a point item will help
<sladen> jam: bzr unbind worked
<lifeless> this is almost certainly another of the 'git is different to the rest of the world' issues.
<sladen> lifeless: I think the users need to stop thinking that bzr is git, and the developers need to stop thinking that every usability/weird design issue is down to "not git" :)
<lifeless> sladen: they don't think that.
<lifeless> this area needs improvement.
<lifeless> The specific expectation that checkout would be anything other than what it was for 30 years of non-D VCS is a bitkeeper inherited behaviour in git
<sladen> lifeless: for me, that is the difference between VCS and DVCS
<sladen> that things "just work" locally when in the past you got all sorts of conflicts, edit-wars, I-commited-last-damnit that VCS gets you
<Tak> so if you do: git checkout git://github.com/foo/bar , it just works? ;-)
<sladen> Tak: is "just works" in that case committing the change /and/ pushing it back to github ?
<lifeless> sladen: if you're using bzr, yes.
<sladen> `*sudder*
<sladen> shudder
<lifeless> thats exactly what bzr checkout git://github.com/foo/bar does
<sladen> that seems awefully SVN and un DVCS-like, but I dare say it's been doing that for five years
<sladen> jam: lifeless: Tak: thank you for the bzr unbind  hint
<Tak> well, if you want "dvcs-like" behavior, you read the manual and use the branch command instead, just like new git users have to read the manual and find out that they have no idea what the checkout command is supposed to do
<lifeless> sladen: so there are two reasons checkout does what it does
<lifeless> sladen: firstly, centralised -workflow- is actually very useful. Rebasing-on-push is a rather terrible idea, if you accept (as I think most folk do) that rebase turns tested code into untested code.
<lifeless> sladen: secondly, for many users coming to bzr, CVS, or SVN, or other centralised only tools are the prior experience, and checkout being the same gives them a solid onramp.
<lifeless> sladen: its a real shame that git is so fundamentally different here, because that adds a tension between help one set, or help another.
<lifeless> sladen: but like I say, there's a more general 'help folk through things' effort as part of a ui overhaul.
<sladen> lifeless: nod.  converting/helping SVN users is a use-case here
<jam> lifeless: what TZ are you in now? (real-world, and effective, I guess)
<jam> I keep seeing you online with *far* too much overlap with my TZ :)
<lifeless> jam: GMT+15 or so
<lifeless> I should be in +13
<zyga> lifeless, are you working on rebase/rewrite plugin for bzr?
<lifeless> zyga: me? no, I'm not doing anything on bzr these days.
<zyga> lifeless, buggers, I wish you did
<lifeless> zyga: jelmer might in the new year
<lifeless> who knows
<zyga> lifeless, I noticed you assigned yourself to one of the bzr bugs about this
<lifeless> its probably stale
<lifeless> one of the problems with the 'assigned' state in volunteer structures.
<axle3d> hay, i want to download a specific branch, LATEST revision with bzr. I already know how to download the branch, but how can i only get the latest revision?
<jelmer> axle3d: you would just like to check out the latest revision, not any of the history?
<jelmer> axle3d: "bzr export" should do that for you.
<spiv> Good morning
<spiv> jam: and especially good morning to you!
<jam> morning spiv, good to see you around
<poolie> hi jam, spiv
<spiv> jam: I'm really looking forward to commit-on-stacked and shallow branches happening
<mwhudson> is there an easy way to find all revids that touched a file?
<mwhudson> tiny repo, ~100 revs, so don't care about performance
<Peng> bzr log --show-ids some_file | grep ...um...I forget the string...
<mwhudson> from the api :)
<mwhudson> i guess i'll read the log source
<spiv> mwhudson: 'bzr touching-revisions'?
<Peng> Aww, no fun.
<Peng> mwhudson: subprocess.call()! :D
<mwhudson> spiv: hm, thanks
<mwhudson> only mainline?
<mwhudson> don't actually care in this case i guess
<jam> mwhudson: depends whether you consider "I merged your changes, but otherwise didn't touch the content" to be a change
<jam> 'bzr log' does
<jam> otherwise
<jam> revs = repo.all_revision_ids()
<jam> file_id = ??
<jam> possible_keys = [(file_id, r) for r in revs]
<jam> real_keys = repo.texts.get_parent_map(possible_keys)
<jam> there are other possibilities
<jam> if you want just the changes in the ancestry of the given tip, etc
<spiv> jam: that's not strictly right
<spiv> jam: a (file_id, rev_id) text may be associated with a revision other than rev_id
<spiv> I think...
<jam> spiv: only in the presence of ghosts
<jam> otherwise a revision must introduce a text with its revid
<jam> spiv: and IIRC, only bzr-svn cheats this way
<jam> and jelmer has been trying to figure out if it should
<jam> the latest version doesn't, but suffers from the mismatched inventories, etc.
<spiv> Yes, certainly ghosts.  I think perhaps there's also some data from relatively old bzr versions that don't adhere to that strict policy, but that we still consider valid.  I have vague memories of all this from my past adventures with reconcile.
<jam> spiv: right, reconcile was meant to fix those. Also, there is the bug that it doesn't track deletions.
<jam> so the other way to do it is to iter the changes to inventories
<mwhudson> how do i get bzr builddeb to use the pristine tar info to recreate the orig.tar.gz?
<mwhudson> ah: make sure the upstream tag is in the branches ancestry
<mwhudson> (which i thought i'd done, but goofed)
#bzr 2010-11-23
<poolie> hi mwhudson
<poolie> i'm going to try to fix some outstanding lp branches today
<poolie> typing very slowly :)
<poolie> hi vila ?
<poolie> did you implicitly fix bug 307316, or is that a dupe of something you know about?
<ubot5> Launchpad bug 307316 in Bazaar "Contents conflicts in checkouts end up in .OTHER being added to the repository (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/307316
<vila> poolie: almost there (~20min), I wasn't subscribed to this one, probably fixed, will check
<vila> hi all !
<fullermd> Oh, it must be time for me to leave...
<vila> peitschie: so, bug #307316 has not been fixed. I don't have plans to fix it either :-/ There are two main issues here, one is the names switching between THIS and OTHER (but that's just a reflexion on what happens underneath), the other is renaming into .OTHER a versioned file
<ubot5> Launchpad bug 307316 in Bazaar "Contents conflicts in checkouts end up in .OTHER being added to the repository (affected: 1, heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/307316
<vila> meh
<vila> sorry peitschie, that was for poolie  :-/
<vila> fullermd: no comment !
<vila> :)
<fullermd> Hey!  That was a comment!
<vila> first typo of the day...
<vila> bah, I wanted to type tyop.... if I can't even make typos on demand now...
<spiv> Â«C'est ne pas une commentÂ»  ;)
<vila> hehe, un commentaire :) Literally 'comment' in French means 'how' :)
<spiv> vila: merci :)
<vila> de rien :)
<peitschie> vila: I was scratchin my head for a little there lol :)
<poolie> vila, hi
<mkanat> It seems to me like loggerhead has a lot of stuff that really ought to be in bzrlib.
<mkanat> poolie: I think that at some point, a worthwhile project would be to de-duplicate loggerhead and bzrlib code.
<mkanat> A lot of what loggerhead's backend code does is create wrappers around bzrlib objects with caches on them.
<mkanat> A lot of that is probably historical, from when bzr was much slower than it is now, and I'd bet that bzr even has these caches itself in some cases, now.
<mkanat> So we're probably duplicating bzr's existing memory usage.
<mkanat> And making it thread-safe.
<spiv> mkanat: +1
<mkanat> :-)
<Peng> On horrible old repo formats, bzrlib probably isn't as fast or cachy.
<mkanat> Yeah, true, but in that case, we'd just say "loggerhead will be painfully slow until you upgrade your repo".
<Peng> Yup.
<mkanat> It would be way better than, "loggerhead will always consume huge amounts of RAM and probably break". :-)
<Peng> Definitely.
<mkanat> I'd love to eliminate as much as possible of the History object from loggerhead.
<mkanat> Like, is it still slow to call repository.get_inventory(revid) over and over on the same revid?
<mkanat> Hmm, I suppose it still is.
<mkanat> And we're getting a whole inventory just to get a single file's id, or something.
<mkanat> Is this really the fastest and best way to get a file's text? http://pastie.org/1319718
<mkanat> And name.
<Peng> haha, os.path!
<Peng> ...Actually, that probably makes sense...
<mkanat> Although actually, I think we don't even need the file name.
<mkanat> We just pass it to highlight(), and I don't see what highlight does with it, if anything.
<Peng> mkanat: Type detection based on teh file extension.
<mkanat> Ohhh.
<Peng> Pesumably.
<Peng> Presumably*
<mkanat> Right, that makes sense.
<Peng> Not sure how necessary it is, though, since it analyzes the content too. But I think being able to use the file extension is supposed to make it more efficient or something.
<mkanat> Okay.
 * Peng shrugs
 * Peng doesn't really know how Pygments works
<mkanat> Is that really the best way to get the text, though? iter a whole inventory just so that I can get a revision tree, and then get the text from the revision tree?
 * Peng is happy that way.
<mkanat> Hahahaha.
<Peng> Noo idea!
 * mkanat looks at bzrlib.repository some more.
<spiv> mkanat: Repository.iter_files_bytes is probably a slightly better way to get the contents of a file
<mkanat> spiv: Okay, that's the impression I was getting from the bzrlib docs.
<spiv> mkanat: and the best way to get a file name is probably inv[file_id].name
<mkanat> spiv: Okay. So I do need a whole inventory for that?
<spiv> mkanat: where inv is retrieved via Repository.get_inventory or iter_inventories
<spiv> mkanat: well, in 2a that won't need to read in the whole inventory
<mkanat> All right. We have stuff that does that already.
<mkanat> Which should probably be in bzrlib--get_path(revid, file_id)
<spiv> 2a fixes a lot of problems we used to have where you couldn't avoid reading the entire inventory
<hrw> morning
<spiv> So if loggerhead is caching stuff to work around that sort of problem, I'd definitely try removing the cache and seeing how it goes.
<mkanat> spiv: Okay.
<spiv> mkanat: note that inv[file_id].name is not the full path of the file in the tree
<mkanat> spiv: Okay. Just its name? That's actually all I want.
<spiv> mkanat: just the file's name in its directory
<mkanat> Great.
<spiv> Getting the full path is more complex (and so more expensive)
<spiv> (I mean, more complex for bzrlib to do, I know there's an equally simple API for it somewhere)
 * mkanat nods.
<spiv> So if loggerhead is calculating the full path... then it's wasting effort.
<mkanat> Yeah. It was doing it because it already had an inventory cache.
<spiv> I'd definitely be interested to hear how loggerhead goes if you rip that cache out.
<hrw> I have a problem. I have one branch up to r128 and second which is r129-136. during merge it gives me text conflicts. so I decided to check which rev has a problem. "bzr merge -r129 ../merge-1.53" told me that there are text conflicts on debian/control and debian/changelog - but r129 changes only debian/rules ;(
<mkanat> spiv: Okay. :-) It's not much work, I suppose I could try it. I just have to learn and locate the proper bzrlib methods.
<mkanat> spiv: BTW, iter_file_bytes is not documented in Repository?
<spiv> mkanat: iter_files_bytes
<hrw> first branch is lp:ubuntu/armel-cross-toolchain-base and second is lp:~hrw/ubuntu/natty/armel-cross-toolchain-base/1.53-rebased/
<mkanat> Ahh, thanks. :-)
<hrw> can someone take a look at tell me what is wrong?
<mkanat> spiv: Also, we're doing this: http://pastie.org/1319780
<mkanat> spiv: Is that really necessary, or is there some self-decoding text retriever?
<spiv> mkanat: bzr stores files as a sequence of bytes, and doesn't know what encoding they are in :(
<mkanat> spiv: Okay. So I'm guessing the internal "annotate" does something like this as well?
<spiv> mkanat: so if you want to display them as text you basically just have to guess the encoding :(
 * mkanat goes to read bzr cat.
<spiv> mkanat: the internal annotate probably just relies on \n always being the line delimiter, and then hoping that the terminal encoding matches the file encoding.
<spiv> mkanat: I'm not sure.
 * mkanat nods.
<spiv> hrw: compare the two branches with e.g. 'bzr qlog branch1 branch2'
<hrw> ok
<spiv> hrw: you'll see that actually 1.53-rebased appears to have branched off revision 2 of the other one
<mkanat> spiv: Okay, yeah, annotate has in it to deal with encoding, too.
<mkanat> *has code
<spiv> hrw: i.e. only the first two revisions are common, and the rest need to be merged.
<spiv> hrw: it appears these two branches are what we call "parallel imports"
<hrw> spiv: they are
<hrw> spiv: I use git-bzr-ng to import bzr into git, do all work and then 'bzr git-import' + 'bzr push'
<Peng> @_@
<spiv> hrw: unfortunately it's late here so I'm off to bed.  Hopefully someone else can help you out from here.
<Peng> spiv: Good night. :)
<hrw> spiv: sweet dreams then
<hrw> looks like I need to find out how to emulate "git am" in bzr
<jelmer> hrw: There is "bzr git-apply"
<jelmer> hrw: It's part of the bzr-git plugin.
<hrw> jelmer: cool
<hrw> lovely
<hrw> jelmer: thx a lot
<hrw> All changes applied successfully.
<hrw> uf.
<jelmer> hrw: np. Please report bugs if you find any; the parser seems to be a bit stricter than "git am" at the moment, and I've only tested it with a small number of files so far (~100)
<mkanat> spiv: What's the standard way that I'm supposed to concatenate all of iter_files_bytes to get a single string?
<jelmer> It just uses "patch" under the hood at the moment, it should be possible to make it use bzr's merge code at some point.
<Kamping_Kaiser> is someone aware of an up to date  comparison of metadata maintained by bzr vs that of git?
<hrw> jelmer: for my use of bzr it is enough
<hrw> but other thing.. if I do "bzr branch lp:soemthing;cd soemthing;bzr merge lp:other" then 'bzr log' does not shows merged tree even with --include-merges option. why? I have to commit merges?
<jelmer> Kamping_Kaiser: bzr has file ids (rename tracking), revision ids, revision properties, ghost parent revisions, git has submodules
<jelmer> hrw: yes, merge does not imply a commit
<hrw> ok
<hrw> now it is time to recreate another branches ;(
<Kamping_Kaiser> jelmer: ok. i'll investigate submodiles to find out what they do. thanks
<hrw> Kamping_Kaiser: submodules are similar to svn:externals
<jelmer> Kamping_Kaiser: they're like nested trees
<jelmer> Kamping_Kaiser: what's the background of the question?
<Kamping_Kaiser> jelmer: ultimately i'm wondering if there is data loss transfering between bzr and git
<jelmer> Kamping_Kaiser: git -> bzr is lossless, except where submodules are involved, the other way around is lossful.
<Kamping_Kaiser> jelmer: ok. and the things that get lost are the bits you mentioned above?
<jelmer> Kamping_Kaiser: yep
<Kamping_Kaiser> jelmer: i'm suppried there is no rename tracking in git. the other parts i don't understand well enough to hae an opinion on
<jelmer> Kamping_Kaiser: git infers renames on the fly
<Kamping_Kaiser> ah
<jelmer> in other words, renames in git are a representation issue
<Kamping_Kaiser> right.
<hrw> jelmer: bzr->git is lossful? what do you lose?
<jelmer> hrw: see above
<hrw> ahmm renames
<mkanat> Kamping_Kaiser: Part of the basic philosophy of git is that it's not tracking files, just content and a bunch of changes to that content.
<mkanat> Kamping_Kaiser: So the fact that files have names is pretty much a strange, incidental fact. :-)
<jelmer> Kamping_Kaiser: ah, there's another one. directories are implicit too, so empty directories (or directories with empty directories) are lost.
<Kamping_Kaiser> mkanat: hm, i seem to recall hearing that before. hopefully it stays in my brain this time
<Kamping_Kaiser> jelmer: hm, ok
<hrw> jelmer: thanks a lot for "bzr git-apply" - you made my live (as git user) much much easier
<hrw> now if there is a command to request merge review...
<jelmer> hrw: glad to hear it's useful. I use it to apply patches from git-using contributors on a project that's maintained in parallel in bzr and git.
<jelmer> hrw: I think there's "bzr lp-propose"
<hrw> found - lp-propose-merge
<mkanat> spiv: I'll have to get you the info on the difference with and without cache on a later day. But I will let you know if I remember, when I'm done switching things around.
<awilkins> Anyone have a hand in the Bazaar plugin for Hudson?
<ambv> hey there
<ambv> does anyone happen to be involved in configglue development?
<hrw> have a nice rest of day
<jelmer> ambv: no, what is configglue?
<ambv> it's a Canonical project that blends ConfigParser with optparse, adding validation and a consistent API.
<jelmer> ambv: perhaps ask in the ubuntu one channel, it seems to've come out of ubuntu one.
<ambv> jelmer: believe it or not, there's #configglue
<ambv> haha
<ambv> thanks anyway :)
<poolie> hi all
<jam> hi poolie, how's it going?
 * jelmer waves to poolie, jam
<poolie> jam, hi
<poolie> and jelmer
<spiv> Good morning.
<poolie> hi there spiv
<chx> Hi. Is there a plugin or something I could deploy that would automatically to try bzr up in case a commit fails on a bound branch ? too often i run a commit , turn to something else because it takes a while to commit over the network and forget that it failed jsut because someone else changed something else at a totally different place
<poolie> chx, i don't think so, but it should be fairly easy to add
<chx> poolie: what should i rtfm?
<chx> maybe it can be even a shell script? something with return values. maybe. a pluginwould be better.
<poolie> how about just a shell script or alias that does 'bzr update && bzr commit "$@"'
<chx> hrm, probably.
#bzr 2010-11-24
 * maxb gets very confused that some _*_pyx.h are autogenerated and some are not
<poolie> really?
<poolie> i thought they all should be
<poolie> if some are versioned that's probably a mistake
<maxb> Turns out there are some _*_pyx.h that are human-authored
<lifeless> we were going to commit them as well, for folk without pyrex.
<lifeless> I don't think that that has happened.
<poolie> i'm not convinced that is worthwhile (any more)
<poolie> it seems mostly useful for people on unix but without an apt/port like system through which they can install it
<poolie> which is a pretty thin slice
<poolie> s/it/pyrex
<vila> hi all !
<fullermd> You're way too chipper for mornings.  You're obviously on powerful drugs.  I want to know where you got them, and how much they cost.
<vila> first dose free, as usual, as to where I got them... I wish I knew :D  I lack them for the last two days and couldn't find any substitute...
<spm> vila: but isn't coffee freely available over your part of the world? with croissant even? ;-)
<vila> spm: ha right, morning expressossss are a pre-requisite (keep forgetting to mention them) but croissants... hmm, I've lost ~10kg in the last months, part of it is certainly because I *avoided* croissants ;D
<spm> heh
<lifeless> vila: congrats!
<lifeless> vila: but did you have to ship it to me?!
<vila> lifeless: thanks, very appreciated, so sorry for the side-effects :-/
<vila> lifeless: still, my main effort was to eat fruits instead of junk between meals, surprisingly effective... Not the only effort but apparently the most important one...
<fullermd> Wait, vila's shipping croissants around?
<vila> bah, no, croissants are not anymore what they used to be in the goold ol' times at 5AM on Sundays...
<poolie> hello vila!
<vila> poolie: hey !
<poolie> hi there
<hrw> hi
<hrw> hi jelmer
<jelmer> hi hrw
<hrw> jelmer: I think that I found a bug in bzr git-apply
<hrw> jelmer: if patch creates new file then it is not created on bzr side after 'bzr git-apply'
<hrw> jelmer: will retest it first
<jelmer> hrw: No need, I can confirm it doesn't do that.
<hrw> ok, good to know
<hrw> jelmer: should I open lp bug for it?
 * hrw -> finding other way to import git -> bzr
<jelmer> hrw: Please do
<jelmer> hrw: importing from git -> bzr should also be possible using bzr-git's pull, that's the same mechanism Launchpad uses for imports.
<hrw> jelmer: this gave me parallel import with r2 as common one. result was really hard to merge
<jelmer> hrw: hmm, it shouldn't do that (if you use bzr-git for other stuff too)
<hrw> bug 680833
<ubot5> Launchpad bug 680833 in bzr-git (Ubuntu) ""git-apply" does not add new files (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/680833
<jelmer> hrw: thanks
<hrw> np
<jelmer> hrw: can I ask about your use case? Are you trying to contribute to a bzr-maintained project?
<hrw> jelmer: I have 4 packages in ubuntu and they are kept in bzr repo on LP. I started developing them in local git repo and keeps it that way (rebase etc). when I think that changes are ready for review I am migrating changes to bzr and push for review.
<jelmer> hrw: ah
<hrw> jelmer: as git user I have problems with switching to bzr
<zyga> lifeless, around?
<jelmer> hrw: bzr push should give you a way to do that once it's finished (it'll store bzr metadata it can't represent in git in a git note)
<Tarantulafudge> I forget, what should I do when I have differing revisions?
<Tarantulafudge> merge?
<jelmer> Tarantulafudge: if you have diverged branches, yes
<Tarantulafudge> any tips?
<Tarantulafudge> do I pull the tree first?
<hmeland> You don't pull "a tree", you pull "a branch"... but to merge, first make your tree into one of the revisions you want to merge (e.g. by using pull or update), then merge the other revision, resolve any conflicts, and finally commit the merge.
<vila> maxb: around ? I'm confused about 'python-docutils does not seem to be a particularly heavy-weight dep', I don't want to add this package to the ppa, why should I care whether it's heavy-weight or not ?
<maxb> vila: You suggested creating an additional metapackage which was bzr-pqm-dependencies-minus-python-docutils. I didn't understand why that would be useful
<vila> haaa
<vila> oh, it was because I thought all the deps except python-docutils may be in the bzr Build-Deps, and I wanted to avoid duplication but I may not fully understand Build-Deps ::-/
<maxb> I'm not sure we're both talking about the same thing when we say Build-Deps
<vila> indeed :)
<vila> *you* know what it means, big difference :D
<vila> so nvm
<vila> as long as we agree on the package name, I'm happy to put it in the ppa as a first step
<maxb> I mean the Build-Depends: field found in Debian source packages
<vila> right
<vila> and I thought those deps should be fulfilled for a package to be built, which we need (I think) before running make check
<vila> since we build the extensions as part of 'make check'
<vila> pff, I'm not even sure pycurl should be there... yet we want it for selftest (so far)
<vila> ok, still a grey area indeed
<vila> so let's keep them separate to start with
<vila> maxb: thanks for your feedback
<vila> maxb: (and the teddybear'ing ;)
<chx> hi. if i have something like 17233.1.24 in bzr blame, how can i find the revision it was merged in...? it does not look it's 17233
<vila> chx: no, 17233 is the revision it was forked from, you want -rmainline:17233.1.24
<vila> chx: 'bzr qblame' may be easier in this case though
<chx> bzr: ERROR: Unsupported protocol for url "mainline:17233.1.24"
<chx> i tried bzr log -r mainline:17233.1.24  with and without the space after -r
<chx>  bzr help revisionspec does not list mainline either
<vila> chx: damn, too recent addition :(
<chx> I have bzr 2.2.1
<vila> chx: it's in trunk, you're using ... right
<chx> even that's not recent enough????
<vila> chx: try 'bzr qblame' from the qbzr plugin then
<vila> chx: what can I answer ? No, if it's not in 2.2.1 but in trunk, 2.2.1 is not recent enough :) Sorry :-/
<chx> bah, i just ran bzr log -n0 and searched it out
<chx> my sysadmin will kill me if i ask qt to be deployed
<vila> ha
<chx> that's a bit too much.
<vila> hmm, there is a bzr log incantation that will be faster than log -n0 but it escapes me at the moment
<mgz> hey vila.
<vila> mgz: hey !
<vila> mgz: is there something you need before landing the python-testtools-0.9.5 related mps ?
<mgz> just approval I think.
<vila> mgz: done !
<mgz> debian can catch up on test tools before the next beta is released if I understand maxb correctly.
<mgz> thanks vila, will land now then.
<vila> mgz: they will have an additional incentive otherwise :D
<vila> mgz: that's too bad I misunderstood you there, I was convinced they were only waiting for the pqm update :-/
<mgz> that was the blocker.
<mgz> as I'm inconvieniencing other people, wanted to double check before hitting the go button though.
<vila> maxb: bzr-landing-dependencies is now in the bzr/proposed ppa, when copying to bzr/ppa, should I use 'Rebuild the copied sources' or 'Copy existing binaries' ?
<vila> maxb: (I would do the former but I don't want to change the existing practices either)
<vila> mgz: shouldn't that *unblock* some failing babune tests instead ?
<mgz> yeah, it will mean I can finish and land my fix for the exception encoding issue
<mgz> then I think we're down to three failing tests on windows, and a few on mac
<vila> ha right, I should have a look at those highly suspicious  lp_api failures...
<mgz> hm, great review by poolie on zearin's capitalisation branch
<jelmer> 'evening Martin, Vincent
<vila> jelmer: hello
<maxb> mgz: lifeless has indicated he will take care of getting a new testtools into Debian in time
<maxb> vila: If you wanted to do it in the web ui, it's "Copy existing binaries", however, if you have hydrazine to hand, I'd just run 'lp-promote-ppa -s bzr-landing-dependencies bzr/proposed bzr/ppa'
<vila> maxb: cool, thanks !
<vila> maxb: and done
<jam> have a good week, vila, I'm off for Thanksgiving. I might poke my head in, but probably not when you're around
<vila> jam: happy Thanksgiving !
<mgz> hm I thought bug 681005 was a dupe of a fixed bug, but then noticed it's reported on 1.0.4 so perhaps bzr-svn still has something that needs fixing Jelmer?
<ubot5> Launchpad bug 681005 in Bazaar Subversion Plugin "svn update (dup-of: 537387)" [Undecided,New] https://launchpad.net/bugs/681005
<ubot5> Launchpad bug 537387 in Bazaar Subversion Plugin "TypeError: update() got an unexpected keyword argument 'revision' in svn checkout (affected: 5, heat: 5)" [Medium,Fix released] https://launchpad.net/bugs/537387
<jelmer> mgz: hmm
<jelmer> mgz: I'll have a look, thanks
<poolie> mgz, thanks for saying os
<poolie> *so
<peitschie> mornin all :)
<poolie> hi spiv, jam
<peitschie> hi poolie
<spiv> Hi poolie.
<spiv> Looks like jam is off for Thanksgiving.
<poolie> oh of course he is
<zyga> boo
<zyga> bzr rebase just ate my commits
<zyga> there was a conflict which I resolved
<zyga> but afterwards the whole next revision (after bzr rebase-continue
<zyga> ) just disappeared
<zyga> is there any way to find it in the repositiory?
<zyga> the previous head
<zyga> jelmer, ^^
<spiv> "bzr heads", from the bzrtools plugin
<zyga> spiv, spits out just the rebased head
<zyga> spiv, I remade the changes (differently though, too much effort last time, too late)
<spiv> heads --all, perhaps.
<zyga> spiv, that's it
<poolie> spiv, so you're piloting this week?
<poolie> try to do a better job than i did :)
<zyga> spiv, you saved an hour of hacking, thanks :)
<spiv> poolie: :)
<poolie> spiv does bug 636930 require upgrading the client, or also the server?
<ubot5> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 13, heat: 151)" [High,In progress] https://launchpad.net/bugs/636930
<spiv> poolie: whichever side is actually performing the conversion; in the case of fetching from a smart server, that's the server side.
<spiv> poolie: so there's a couple of things in that bug:
<spiv> poolie: the original reported traceback is client side
<spiv> poolie: but Launchpad performs upgrades on behalf of users when they click the link on Launchpad, so that's Launchpad-side
<spiv> And cross-format fetches that aren't upgrades are also affected.
<spiv> So to cover all cases server and client need to be upgraded.
<poolie> k
<poolie> i'll just paste that if you don't mind
<spiv> Sure!
#bzr 2010-11-25
<maxb> vila: Does bzr-landing-dependencies have a bzr branch?
<maxb> So are we on for 2.2 today?
<fullermd> Man, you're behind.  I've had 2.2 for months   ;)
<GungaDin> Hi
<thumper> hi
<thumper> didn't someone start a gitorious fork using bzr?
<thumper> anyone know the status of it?
<GungaDin> Is it possible to generate a diff/patch by simulating a merge ?
<spiv> GungaDin: 'bzr merge --preview'
<GungaDin> can that be used with patch?
<thumper> GungaDin: I believe so
<beuno> or bzr send?
<beuno> hai thumper!
<thumper> hi beuno
<thumper> GungaDin: what are you trying to achieve?
<GungaDin> to patch the changes of a merge.
<GungaDin> I don't want the history tracked. just need to patch.
<thumper> GungaDin: you can do that with bzr
<thumper> if you merge the branch
<thumper> then I think you do bzr revert .
<thumper> don't forget the dot
<thumper> and I think that merges the content without the history
<thumper> but I'd like lifeless or spiv to check that
<spiv> bzr revert --forget-merges
<spiv> thumper: 'bzr revert .' is the opposite :)
<thumper> good thing I checked then :)
<thumper> spiv: so with --forget-merges it keeps the file changes?
<spiv> GungaDin: So do 'bzr merge' followed by 'bzr revert --forget-merges'
<spiv> thumper: yes
<thumper> cool
<thumper> thanks
<GungaDin> cool. thx
<vila> hi all !
<Peng> Good morning. :)
<mgz> morning vila.
<vila> :)
<vila> mgz: do you have a way to reproduce bug #681047 ?
<ubot5> Launchpad bug 681047 in Bazaar "Random failures on SFTPTransport tests on windows (affected: 1, heat: 6)" [Low,Confirmed] https://launchpad.net/bugs/681047
<mgz> nope, only seen it on babune, as I don't have paramiko installed locally
<vila> mgz: hmm. Do you agree that get_bytes()/get() may be a cause ?
<mgz> looked like a good thing to fix, but I'd be suprised if it were the cause
<vila> mgz: taking into account that paramiko do some internals sleep()
<mgz> I'm pretty sure that refcounting means the file is closed at the end of that statement
<mgz> http://babune.ladeuil.net:24842/job/selftest-windows/242/ <- last run has one of the sftp failures
<mgz> ...also has an lsprof thing I don't think I seen before
<mgz> http://babune.ladeuil.net:24842/job/selftest-windows/242/testReport/junit/bzrlib.tests.test_lsprof/TestStatsSave/test_stats_save_to_pickle/ <- any ideas on this?
<vila> EOF during a file read... sounds a bit like the bucket I put many random failures into: vbox having trouble /bug with fs updates/caching >-/
<vila> which is so vague I don't dare mentioning it usually...
<mgz> was guessing something like that
<vila> The scary thing with this scenario is that it implies a very stealth bug with a very low occurrence rate which more or less means it will never be fixed :(
<vila> On the other hand, the fact that the pattern is common to so many various OSes can hardly be caused by bzr itself (since it doesn't occur on real hardware...)
<vila> mgz: by the way, it's nice to have clearer failures in the other cases ;)
<vila> maxb: I have only a local branch for bzr-landing-dependencies so far, that's bad, but I don't know where to put it, defining an lp project for it sounds too heavy-weight, keeping a local branch too light, ideas welcome
<spiv> vila: +junk until you decide?
<vila> right
<vila> done: lp:~vila/+junk/bzr-landing-dependencies
<vila> thanks to bzr for reminding at first push, I don't have to note it anywhere...
<maxb> vila: you should be able to push it to lp:~bzr/ubuntu/hardy/bzr-landing-dependencies/bzr-ppa
<vila> maxb: brilliant
<vila> done
<vila> maxb: where is this defined ?
<vila> I mean, what are the rules there (especially the 'bzr-ppa' part) ?
<maxb> the bzr-ppa part is nothing more than convention established by me
<vila> lol :) Best doc ever ! Ask and you should receive an answer :D
<maxb> there was an email thread a while back where I proposed and then did a rename of all the extant ppa packaging branches
<vila> ok, then, what is allowed under lp:~bzr/ubuntu/hardy/ (this is <user>/<distro>/<series> right ?) ?
<maxb> the rest of the 5-component name is launchpad's schema for identifying source package branches
<maxb> so, person/distro/series/package
<vila> even if bzr-landing-dependencies is not  (yet?) an "blessed" package ?
<maxb> handily using the accidental? feature that even PPA package names work there
<vila> ooooh, so it's not that arbitrary then, it should catch tyops :D
<DaffyDuck_`> If I use a shared repo (init-repo), and create a bunch of branches within it. Is it safe to remove branches from the shared repository if they turn out to be dead-ends, or are the repostitory files and branch files weaved together?
<Peng> DaffyDuck_`: Nuke branches to your heart's content. All of the important data is in the shared repo itself. Note that this means the revisions unique to that branch won't be deleted.
<Peng> (Unless something has changed significantly recently...)
<DaffyDuck_`> Peng: Thanks. I trust that if it has had that behavior, it still does. :)
<Peng> DaffyDuck_`: Check if something has a .bzr/repository to be sure.
<DaffyDuck_`> Yeah; my plan was to run "bzr info" to see if it mentions being a part of a repository before nuking anything.
<Peng> Yeah, that works too. :P
<mvo> hey, could someone help me please with a rather odd error message? I work on "bzr+ssh://bazaar.launchpad.net/%2Bbranch/vmbuilder/" (lp:vmbuilder) and do "bzr merge lp:~mvo/vmbuilder/add-natty". now it tells me:
<mvo> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/0.12/".
<mvo> where does it get this from? I'm pretty sure that lp:~mvo/vmbuilder/add-natty is a branch of lp:vmbuilder
<jelmer> mvo: Hi
<mvo> hey jelmer
<jelmer> mvo: I suspect lp:~mvo/vmbuilder/add-natty was originally stacked on that other branch but the other branch has been renamed
<jelmer> or perhaps removed
<mvo> should I just apply the diff or is there a better workaround?
<jelmer> mvo: do you know what happened to the original 0.12 branch?
<mvo> I have no idea :(
<jelmer> If it's still around under another name, or if it was merged into another branch then you should be able to fix the stacked-on location
<jelmer> You can see the reference to the 0.12 branch here: http://bazaar.launchpad.net/~mvo/vmbuilder/add-natty/.bzr/branch/branch.conf
<mvo> can I just mug around in that file to point to a different one?
<jelmer> mvo: yep
 * mvo puts his cowboy hat on and tries it
<jelmer> I thought launchpad prevented removing branches that had other branches stacked on them, but apparently there isn't complete coverage.
<mvo> this is rather odd - I just pushed my local branch to lp as add-natty2 and it said that it reated it as a stacked branch on top of 0.12 as well. but this one I can merge to trunk
<mvo> worth a bugreport?
<jelmer> mvo: Yeah, I think so
<mvo> bug #681431
<ubot5> Launchpad bug 681431 in Bazaar "confusing error when original stacked branch becomes invalid later (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/681431
<mvo> probably needs adjustment, maybe its code-hosting instead of bzr? or both?
<mvo> thanks for your help, I was able to workaround it now
<lvh> Hey. I'd like to integrate Roundup with bzr. I'm hosting bzr on a server with bzr+ssh. Closing/referencing tickets seems easy, since those are commit hooks. I'm wondering about *assigning* tickets: I'd like to assign them when someone branches off.
<lvh> If I understand correctly there's no hook for that at the moment.
<lvh> (And unlike in SVN a branch doesn't imply a commit. I like that, but it makes this somewhat unfortunate.)
<lvh> Perhaps a push hook? Does the hook know who committed?
<lvh> I'm looking at http://wiki.bazaar.canonical.com/BzrHooks, it mentions bzr 1.0 hooks. Is that hopelessly outdated?
<mvo> hm, hm, there is  https://launchpad.net/vmbuilder/0.12 and claims the 0.12 series points to lp:vmbuilder
<maxb> mvo: Note the difference between ~ubuntu-virt/vmbuilder/0.12 and ~vmbuilder-dev/vmbuilder/0.12
<mvo> ohhhh
<maxb> Do you need to rescue an existing branch, or have you completely worked around it by repushing a local copy?
<mvo> for the initial one I worked around by pushing my local copy, but I would like to e.g. branch the "packaging" branch which is not possible now
<mvo> currently
<maxb> mvo: Do you have write access to the problem branch?
<jelmer> lvh: Yeah, I don't think the wiki has been updated - try "bzr help hooks" ?
<mvo> not the packaging one :/ to trunk though
<lvh> jelmer: Ooooooh. Nice.
<mvo> the one I wanted to work on next is lp~soren/vmbuilder/packaging
<lvh> jelmer: Thanks
<mvo> but that is not owned by me
<maxb> mvo: hmm. In that case we need a losa or someone who does. Or, in a pinch, you can copy the branch content locally and fix it up on your local machine
<soren> mvo: What do you want to do to it?
<mvo> soren: make it work again (i.e. make it possible to branch it again). see https://bugs.launchpad.net/launchpad-code/+bug/681431
<ubot5> Launchpad bug 681431 in Bazaar "confusing error when original stacked branch becomes invalid later (affected: 1, heat: 6)" [Undecided,New]
<mvo> soren: it appears its unhappy because its stacked on location changed
<soren> mvo: I'm not even sure I have a local checkout of it.
<soren> mvo: Let me know if I can help.
<maxb> soren: Could you download a script I wrote for this purpose? http://j.maxb.eu/~maxb/bzr-set-stacked-url
<mvo> oh, nice
<lvh> jelmer: None of these hooks appear to know which user did it though
<mvo> soren: once I have that branch I will update it to include the current packaging and push it as ~vmbuilder-dev so that its in sync again (I guess you don't mind :)
<maxb> Then you can run bzr-set-stacked-url lp:~soren/vmbuilder/packaging lp:~vmbuilder-dev/vmbuilder/0.12
<soren> I'm cooking dinner right now, actually.
<jelmer> lvh: you can check who committed the revision that was pushed?
<soren> mvo: Can you ping me about it this evening or tomorrow? I'd be happy to help get this sorted out.
<lvh> jelmer: I suppose I could use bzr's notion of who did it and not ssh's notion of who did it and it'd even be more correct
<lvh> jelmer: Right
<maxb> soren, mvo: I'll sort it via scping the branch and push it to lp:~maxb/vmbuilder/packaging
<mvo> soren: will do, maybe I find find a LOSA in the meatime to fix it up, but if not, I will ping you
<mvo> maxb: cool! many thanks .)
<soren> mvo: Lovely.
<lvh> jelmer: post pull and push are client-only, so either I need cooperative clients or something else
<jelmer> lvh: you can't really rely on anything but the client as bzr supports "dumb" push
<lvh> jelmer: I'm working under the assumption everyone does everything over bzr+ssh
<maxb> mvo: pushed
<lvh> post-branch-init looks promising
 * mvo hugs maxb
<lvh> jelmer: If I understand correctly http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.BranchInitHookParams.html isn't linkable to the bzr concept of a person, because there are no commits made. Does that sound right?
<jelmer> lvh: yeah
<lvh> Hm, unfortunate, but I guess I'll live :-) Thanks jelmer :-)
* 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: spiv | Release Manager: vila, 2.2.2 has gone gold, packagers of the bzr world, unite ! | Hooray for jelmer
<maxb> Hrm. PQM seems to only be accessible under pqm.bazaar-vcs.org, there appears to be no pqm.bazaar.canonical.com
<maxb> This doesn't feel like the sort of thing to file on Launchpad. Maybe a Canonicalite could log a suggestion or RT for the Canonical sysadmins?
<vila> maxb: why ?
<maxb> Consistency. AFAIK every other bazaar resource has moved off bazaar-vcs.org
<vila> Well, the other ones are targeted at users, whereas pqm is only targeted at committers... which I strongly suspect won't upgrade their configs :D
<vila> ..not mentioning the docs...
<vila> maxb: and since there are plans to migrate from pqm to tarmac, I'd rather keep the energy focused on that instead
<maxb> ah, ok
<vila> maxb: I'm about to EOD, but I plan to look at what needs to be done for the MRE regarding 2.2.2 (or the SRU otherwise) first thing tomorrow, I may ask you silly questions then, be prepared ;D
<maxb> vila: We pop it in the PPA, say, "look, it passes, please rubberstamp that this SRU has met our MRE conditions, thanks"
<vila> maxb: you're just great :D
<maxb> Then we validate the package in maverick-proposed did actually build correctly, and say "it works, please promote to maverick-updates"
<vila> right, so I need to setup the right branches on my side and document the above
<vila> This sounds like a good summary, but 'validate .. in maverick-proposed' is still a bit obscure to me, ha, no, we do nothing more for that than pointing to the right package branch ?
<vila> i.e. let me try
<vila> lp:~bzr/ubuntu/maverick/bzr/bzr-ppa ?
<vila> or bzr-proposed ?
<vila> nah, bzr-ppa when available right ?
<maxb> yes.... but no :-)
<maxb> We probably want to prepare the SRU on top of the existing ubuntu packaging branch
<maxb> And then just happen to commit equivalent changes onto the PPA branch
<maxb> Also, we need to assess the list of bugs fixed by this SRU to prepare an appropriate debian/changelog entry
<maxb> Also I've been refining the debian/rules invocations to run the testsuite in the maverick bzr-ppa package, so some of that needs to be ported onto the ubuntu branch
<maxb> I'd can do that tonight if you like
<maxb> vila: ^
<vila> maxb: whatever works for you, I'd be happy to only look as well as being your hands there
<vila> maxb: I'm off now, but I will read the log
<maxb> ok
<ccxCZ> did I misunderstand, or is bzr merge --interactive broken when it does not record the commit as merge?
<ccxCZ> it's plain commit in my history
<maxb> ccxCZ: I could believe that it might be deliberate
<maxb> Recorded merges are supposed to denote complete merges of that line of history, whereas if you omit chunks, that's not really the case
<ccxCZ> well certainly it's not documented in help and now my history messed up :/
 * maxb reads the source code
<maxb> It rather does look like this is the case
<ccxCZ> ok I'll remerge that
<ccxCZ> but it's kind of nasty, since one might want to cherrypick
<maxb> ccxCZ: Well that's rather the point. An interactive merge by definition is a cherrypick of sorts, and cherrypicks are never recorded as full merges.
<Ng> does bzr use launchpad's edge server to decode lp:foo locations?
<Ng> hmm, I mean "is it hard coded to do that", because the machine I'm using clearly is trying to use edge for that
<maxb> Ng: I believe it has done in some versions of bzr. Not sure if it still does, though
<elmo> yeah, it's known and known as a bug
<elmo> also not sure if/when it's been fixed
 * maxb cries at the mess of parallel imports for bzr UDD packaging
<lifeless> Ng: https://bugs.launchpad.net/bzr/+bug/583667
<ubot5> Launchpad bug 583667 in Bazaar "bzr talks to edge API servers to propose merges (but not for lp: url lookups) (affected: 1, heat: 1)" [High,Confirmed]
<Ng> ta all
<lifeless> Ng: what version do you have?
<Ng> lifeless: 2.0.4
<lifeless> I suspect that still uses edge for lp:
<maxb> Ng: This changed in 2.2. Might be worth upgrading, for the steady stream of bugfixes since then
<elmo> the bzr --whoami thing is blocking us
<elmo> or, at least, that's why we're still on 2.0.4
<maxb> What is the --whoami thing?
<elmo> maxb: https://bugs.launchpad.net/bzr/+bug/616878
<ubot5> Launchpad bug 616878 in Bazaar "bzr commit error because of no identity (affected: 3, heat: 43)" [Medium,Confirmed]
<maxb> elmo: Is your /etc-in-bzr via etckeeper?
<elmo> maxb: our setup pre-dates etckeeper, but it's the same idea
<maxb> jelmer: for the 2.2.2 maverick SRU, shall we just leave the testsuite not using the compiled extensions, since we have not settled how we want to fix that, do you think?
<jelmer> maxb: Yeah, I think that's a good point. Let's not make any unnecessary last minute changes.
<maxb> jelmer: Right. I am planning to put the "run bundled plugin tests" change in, though, since I've already run that through the PPA to validate it
<maxb> Rather madly, I think bug 659590 is actually the most important fix in 2.2.2 for Ubuntu
<ubot5> Launchpad bug 659590 in bzr (Ubuntu) "dput sftp upload hangs after all files successfully uploaded (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/659590
<maxb> Hrm.
<maxb> According to the SRU process we need to release 2.3b4 and get it into natty before we can SRU 2.2.2
<maxb> AAAAAAAAAARRRRRGHH
<maxb> Our MicroReleaseException is broken
<maxb> We cannot run the testsuite during package build, because bzr is in main, but python-testtools is in universe.
<jelmer> maxb: :-((
<jelmer> maxb: We should really try to get python-testtools into main.
<jelmer> maxb: But I guess that's not something we could do for this SRU..
<maxb> I think I'm about ready to throw my hands up in horror and say "SRU? What's that? We have a lovely ~bzr PPA for you to use!"
<lifeless> (
<lifeless> :(
<maxb> Speaking of which, uploadded 2.2.2 to bzr/proposed now
#bzr 2010-11-26
<poolie> hi lifeless, jelmer, maxb, spiv
<poolie> urk, this scrollback looks bad
<jelmer> g'morning poolie
<fullermd> That'll teach you to scroll back.
<poolie> maxb: thanks for the 2.2.2 upload
<poolie> that was superbly quick
<poolie> maxb, maybe we should take this back to the TB?
<maxb> Well. The MRE was well reasoned. Running the testsuite makes sense.
<maxb> It's just we can't, because of dependencies.
<maxb> If we care (I'm not sure I do) about putting every micro release of bzr into the relevant ubuntu updates, then I think we need to sort out a MIR of python-testtools for natty
<jelmer> I think we should.
<poolie> i care about getting at least some bugfix releases into ubuntu
<maxb> And for maverick, I think someone needs to have a discussion with the SRU team on whether they will consider allowing the testsuite to be run in a PPA to be "good enough"
<spiv> testtools is a good library, I think having it in main in future makes senes.
<spiv> sense, rather.
<poolie> if we can't do that, perhaps either it's not worth doing them at all, or the SRU process is wrong in this case
<poolie> > whether they will consider allowing the testsuite to be run in a PPA to be "good enough"
<maxb> The SRU process is primarily built for cherrypicked backports of single fixes
<poolie> that sounds like a good pragmatic approach
<poolie> i know
<poolie> however, i know mark's very keen on getting things just like this in to previous releases
<poolie> if it's done in a very safe way of course
<maxb> I've kicked off a test build in https://launchpad.net/~maxb/+archive/ppa
<maxb> However, I personally don't have the energy/motivation to get involved with the MIR or SRU team discussions I conjectured above
<jelmer> maxb: I'm going to send in a request to become a PerPackageUploader, I might look at the MIR.
<poolie> i sent one too, but it apparently stalled because i didn't go to the irc meeting
<poolie> jelmer, that would be great
<poolie> maxb, i'll continue the SRU discussion
<poolie> i wonder if sudo works :_)
<fullermd> Didn't we have a discussion $YEARS ago about exit status on pull?
<lifeless> yes
<lifeless> i awas there
<fullermd> I thought it went toward adding information.
<maxb> As in, indication whether anything was actually pulled or not?
<fullermd> Yah.
<maxb> The problem with this is that there's no way you can change behaviour here without breaking people's shell scripts and causing wailing and gnashing of teeth
<maxb> It seems like just checking the revno before and after would be better
<fullermd> Well, it just broke my partly-written shell script   :p
<maxb> s/better/achieve the same without compatibility issues/
<lifeless> maxb: we have major/micro to permit improvements
<maxb> Well, yes, 2.0 would have been the logical place to do such a thing
<fullermd> Don't worry, we have a VCS.  It's like a little time machine; we can just roll back to before 2.0...
<poolie> we can change this in 2.3
<poolie> just describe it in news and whatsnew, make it as little disruption as possible, and do it
<lifeless> poolie: I'd love it if you could schedule https://bugs.launchpad.net/bzr/+bug/583667 for doing sometime fairly soon
<ubot5> Launchpad bug 583667 in Bazaar "bzr talks to edge API servers to propose merges (but not for lp: url lookups) (affected: 1, heat: 1)" [High,Confirmed]
<poolie> ooh
<poolie> schedule it, or do it?
<poolie> :-P
<poolie> sounds pretty easy though
<lifeless> poolie: if you're not doing it yourself, schedule. I'd love to see it done ;)
<poolie> what's the actual problem?
<poolie> just tidyness?
<poolie> ah, the blog explains?
<lifeless> we can't redirect API clients
<lifeless> yes, it does
<lifeless> we can't easily serve edge from the main cluster either
<lifeless> due to a couple of issues
<poolie> i trust you but i am surprised
<lifeless> there is some machinery in zope
<lifeless> but we're using a mangled implementation because we adopted so early
<poolie> :/
<lifeless> gary is unsure that it would work, and sure that it would require effort
<poolie> this kind of sucks because everybody who tried to write an api client has been told "use edge"
<lifeless> that was, sadly, bad advice
<lifeless> the wadl served from a domain has the domain embedded in it
<poolie> of course it's great we're going to move away from using a separate url space for this
<lifeless> so we can't just redirect in apache
<poolie> we can't configure the main cluster to serve api.edge.l.n as well as api.l.n?
<lifeless> no, see under zope machinery
<lifeless> the objects that are published would be the same as for the main site
<lifeless> but have to be on the site the request was received
<lifeless> this fights some global state
<poolie> ok
<poolie> thanks for raising it then
<poolie> and for the blog post
<poolie> from the initial bug report against bzr, it was not at all obvious this would be urgent
<lifeless> we're going to have to keep the cluster until we've got every user migrated, or near enough to every
<lifeless> so I would say urgent
<lifeless> but nice to do
<lifeless> bzr would get better response by miving as well
<poolie> my only reluctance is about updating very old series
<poolie> cf recent threads about ceasing updates for 2.0 except for critical issues
<poolie> it would be pretty unfortunate to have that break
<lifeless> poolie: it would be unfortunate
<lifeless> my /preference/ would be to get everything on lpnet (see for instance ng's query about edge this morning)
<lifeless> but if thats particularly risky/problematic, staying on edge until you stop supporting 2.0 is fine.
<poolie> i think if you kept it alive until at least the end of karmic (bzr 2.0.x) in april that would be ok
<poolie> assuming nobody is still using hardy's original bzr
<sqwishy> Is there a simple way to have a branch not store binary deltas?
<poolie> what do you mean?
<sqwishy> So when someone changes a binary file, it doesn't retain older versions of it.
<sqwishy> :>
<sqwishy> Basically, I have a project that will need potentially 10MB > binary resources that could be changed several timed. I'd like for them to be in the bzr repo with the code because then everything is in one place and can be updated easily.
<poolie> sqwishy: sorry, no, we don't support that at the moment
<poolie> i suggest you either
<poolie> 1- put them in a bzr branch but from time to time kill its history and make a new branch
<poolie> 2- download it by some other means like rsync
<lifeless> poolie: right, the goal is to shrink with all due haste, not to be cavalier
<sqwishy> Yeah, the project is in python so people don't run a build script to run the thing. There is no great place to put an automatic rsync fetchery thingy because scripts aren't run to build the app.
<sqwishy> I might have to try and think of something clever.
<poolie> spiv i'm going to finish up now
<poolie> suggest you do too :)
<spiv> poolie: Heh :)
<spiv> Just finishing up writing some tests :)
<vila> hi all !
<vila> maxb: ping
<vila> maxb: I've seen your mail about the MRE
<vila> So basically we need python-testtools. Getting it into main may be the best solution long term wise.
<vila> Embedding a private version, while frowned upon in debian may be a workaround ? (I'm not holding my breath here :) but I think it's worth mentioning
<vila> Now, where does it break precisely ? We are not releasing it, we need it to validate our code only, can't we find a way ?
 * vila reboots
<loxs> I have 2 separate bazaar repositories. Is there some way to move a file from one to the other with all its history?
<augdawg> when i try bzr branch, it always  asks me for my password. i hav tried telling it to unlck the keychain, but it wont work. can anyone help?
<jelmer> augdawg: Are you referring to the GNOME keychain?
<jelmer> augdawg: bzr-gtk's keychain support will only use existing credentials, it won't add new ones.
<augdawg_> sorry jelmer, the wifi went offline briefly in my home.
<jelmer> <jelmer> augdawg: Are you referring to the GNOME keychain?
<jelmer>  AfC ajmitch apw ahasenack augdawg
<jelmer>  augdawg: bzr-gtk's keychain support will only use existing credentials, it won't add new ones.
<jelmer> Argh, xchat inserted the tab completion suggestions there. Sorry about the highlights :-(
<augdawg_> i mean that it wont let me tell it to unlock my keychain for branching stuff off launchpad
<AfC> jelmer: nice one
<jelmer> augdawg_: ah, this is for ssh? bzr just calls out to the main ssh binary to talk to Launchpad over bzr+ssh
<augdawg_> so what does this mean?
<vila> augdawg: that means the problem is with your ssh setup, what does 'ssh-add -l' says ?
<vila> augdawg: or rather, to start, what does 'ssh -v bazaar.launchpad.net' tells you ?
<maxb> vila: Hi.  Yes, we need python-testtools. For natty the answer is to get a Main Inclusion Report done and approved.
<vila> maxb: hi !
<vila> So, *why* precisely do we need it ?
<maxb> To run 'bzr selftest'
<vila> ..and this must succeed without any piece external to main ?
<maxb> Any build in the Ubuntu archive must obey the component dependency model
<maxb> main only sees main. restricted sees main + itself. universe sees main + itself. multiverse sees everything
<vila> and where did that fail ? I mean, we started running the tests some time ago
<maxb> Yeah...... in PPAs. Enforcing this restriction is optional and usually disabled in PPAs
<vila> ok, thanks for the clarification
<vila> So indeed, that's bye bye MRE for maverick
<vila> So, what's a 'Marin Inclusion Report' and who will do it ? python-testtools devs ?
<vila> s/Marin/Main/
<maxb> A main inclusion report is a document justifying that a package is sufficently well maintained and will not put an undue burden on the Ubuntu Security Team if included in main
<maxb> https://wiki.ubuntu.com/MainInclusionProcess
<vila> great
<vila> as for who should do that, I think the answer is: the bzr RM
<vila> .. or he will never really learn how this works :D
<vila> jml: ping
<jml> hi
<vila> jml: err, where are you these days ? May be in your ... oh no! Great !
<vila> jml: so, bzr has applied for Micro Release Exception with a pre-requisite of running the tests as part of the build
<vila> jml: it turns out that python-testtools is not part of the main archive so we are blocked for maverick
<vila> jml: What are your plans regarding inclusion of python-testtools in the main archive ?
<jml> vila: none as yet.
<jml> vila: whether we are in main or not doesn't matter much to me.
<vila> jml: ok
<cbz> is jelmer around?
<jelmer> cbz: sortof
<jelmer> cbz: Hi
<cbz> hi jelmer - using bzr-svn on windows it complains that it cannot create something because it is a simlink, in the repository itself it appears to be a dirctory in which a bunch of external items are to be pulled in
<jelmer> cbz: if you check out the repository using the "normal" svn client do you get a symlink?
<cbz> no - svn creates a normal directory
<cbz> actually no - it's created a file with a name inside
<cbz> in one case
<cbz> in the other case it created a directory
<jelmer> cbz: is this a public repo?
<cbz> no, unfortunately not
<cbz> it looks like the directory that it bitches about is the one defined as a home for a bunch of svn:externals
<jelmer> what exactly is the error message?
<jelmer> cbz: ^
<cbz> bzr: ERROR: Unable to create symlink 'test/selenium/vendor' on this platform
<cbz> thats for the file that svn creates as a file containing "link ../target/dir"
<cbz> whichi presume is actually a symlink to a directory
<jelmer> cbz: That file would be created as a symlink on unix by the svn client
<cbz> yes
<cbz> I get an identical error message for another directory which as far as i can tell is only referenced by svn:externals
<cbz> svn will create the directory and populate it
<cbz> bzr-svn throws an error message
<jelmer> cbz: this is unrelated to bzr-svn, it's bug 81689 IIRC
<ubot5> Launchpad bug 81689 in Bazaar "Branches with symlinks can't be checked out on Windows (affected: 21, heat: 58)" [Medium,Confirmed] https://launchpad.net/bugs/81689
<cbz> The second issue does not appear to be symlink related
<jelmer> what's the error you're getting?
<jelmer> ah, it's identical - sorry
<jelmer> can you check with "svn cat" what the contents of the problematic file are in that second case ?
<jml> jelmer: btw, are you familiar with http://twistedmatrix.com/trac/wiki/BazaarMirror#CommittingaBazaarbranchtoaSubversionbranch
<cbz> jelmer: svn says it's a directory (which it is). I think it doesn't exist in the repository, svn:externals just refers to it and so svn is able to create it
<jelmer> jml: No, I wasn't aware of that. Thanks for the link
<jelmer> cbz: bzr-svn ignores svn:externals at the moment
<jml> jelmer: basically, it would be nice if there were fewer warnings about bzr/svn gotchas on that page
<jelmer> cbz: There might be something strange going on there, such as svn checkout removing it because the svn:externals directory overwrites it.
<kiko> jelmer, do you know why bzr diff -r submit: needs to hit the server?
<jelmer> kiko: If the submit branch is a remote branch (it commonly is) it will need to check what the tip revision of the submit branch is.
<jelmer> kiko: There are probably some other (less common) situations in which it can require remote access (if the local branch is a lightweight checkout, for example).
<kiko> jelmer, is there a shortcut to ask bzr to give me the changes between my current tip and the tip of the remote branch as it was when I last pulled a revision
<kiko> without hitting the server
<jelmer> kiko: Not without manually keeping a local copy of the remote branch at the moment (or tagging the last remote revision, or something like that).
<jelmer> kiko: When colocated branches land it should be a lot easier to do this sort of thing, much in the same way that git supports it ("remote refs")
<kiko> right
<jelmer> jml: the bzr metadata shouldn't really be an issue anymore. With a recent enough svn (>= 1.5) we no longer store the metadata in file properties.
<jelmer> jml: I've considered printing a warning if we would end up writing to file properties
<jml> jelmer: if we asked for confirmation, that would probably settle some fears in #twisted
<jml> printing is a little chancy
<jelmer> jml: bzr usually doesn't do interactive stuff (uncommit is the exception that confirms the rule). I guess we could require a configuration option though.
<jml> jelmer: or warn, quit and say that you need to specify a particular option
<jelmer> at this point repositories without custom revision property support should be really rare
<jelmer> jml: That'd be reasonable. Care to file a bug ? :-)
<jml> jelmer: sure, more than happy to. (once I finish dealing with my current silly self-imposed distraction)
<fabio_kreusch> I have a bzr repository on format 2a, and I'm trying to do a split. So I do 'bzr split path', then ''bzr join --reference path' and 'bzr commit', and everything is fine. But after that, whenever I try to access the repository, I get this message:
<fabio_kreusch> The method _generate_inventory is not supported on objects of type CHKInventoryRepository
<fabio_kreusch> any thoughts?
<kiko> sounds like a bug :)
<fabio_kreusch> I have found on launchpad this https://bugs.launchpad.net/bzr/+bug/515947
<ubot5> Launchpad bug 515947 in Bazaar "cannot commit in the containing tree which has by-reference joined trees [2a] (affected: 1, heat: 0)" [Low,Confirmed]
<fabio_kreusch> yep
<fabio_kreusch> that's the one
<fabio_kreusch> but
<fabio_kreusch> what should I do than?
<fabio_kreusch> On that thread John Meinel says that --reference should not be compatible with 2a
<fabio_kreusch> but what should I do than so that I'm able to split my repo?
<maxb> Hrm
<maxb> Looks like Gary accidentally marked lp:qbzr as not supporting bzrlib 2.3
<maxb> fabio_kreusch: I'm pretty sure --reference should be totally incompatible with 2a
<maxb> Hence, you can use 'bzr split', but you can't use 'bzr join --reference'
<fabio_kreusch> maxb: what I want to do is to have subtrees, can't I do that with 2a than?
<jelmer> fabio_kreusch: no, 2a doesn't support nested trees.
<lamont> bzr: ERROR: Unable to determine your name. <-- we did fix 2.3 so it doesn't consider that an error anymore, right?
<jelmer> lamont: I haven't seen a fix for that yet.
<lamont> gar
#bzr 2010-11-27
<nilg> hi I've done a merge using bzr merge and I've pushed the result on my private branch. Is it possible to turn this merge into a rebase? Or to revert and redo the operation using rebase but I'm afraid to loose my work in the middle?
<mathrick> hey, is bzr supposed to be able to invoke the editor on win32 for commit messages?
<fullermd> I'd assume so...
<fullermd> Alternate less helpful but more fun answer: We wouldn't want to assume windows users can _type_...
<mathrick> that only works on vista+ :)
#bzr 2010-11-28
<ovnicraft> hello guys, i am reading http://doc.bazaar.canonical.com/developers/colocated-branches.html
<ovnicraft> this is supported now in LP?
<ovnicraft> why when was designing bzr dont think get in the core colocated branches?
<mathrick> ovnicraft: because you can't get everything right from the beginning, and also because it wasn't clear it was a good idea at all
<mathrick> directory-per-branch has the advantage of being a very explicit and understandable model
<peitschie> mornin all :)
<spiv> Good morning :)
<poolie> hi all
<lifeless> hai
<poolie> happy holidays :)
<lifeless> thanks :)
<poolie> i hear hacking on bzr is very relaxing :-}
<lifeless> I am, in a meta sense: check lp:testrepository
<poolie> i like your persistence post
<poolie> i don't have anything specific to add other than an upvote
<poolie> oh, one thing: istm if you are going to have an architecture guide doc, this approach ought to be described in it
<poolie> at least by the point it's implemented
<poolie> whether it's worth having a doc or just oral tradition is up to you
<poolie> (you plural)
<lifeless> thanks
#bzr 2011-11-21
<spiv> poolie: I do get the sense that either the subunit protocol or the implementation of it has awful failure modes
<poolie> yeah basicalyl that
<wgz> ...I just realised I tyoped 'Pageant' in the thread title on the bazaar list
<poolie> jelmer, i'm getting a failure in
<poolie> ERROR: bzrlib.tests.per_tree.test_inv.TestInventory.test_canonical_invalid_child(GitWorkingTreeFormat)
<poolie> with tip of bzr-git
<poolie> do you want me to report it?
<poolie> (other than on irc :)
<spiv> poolie: I suppose if you were to design a protocol to be reasonably robust about failing well in the case of corrupted/interleaved output you'd want somethign like "length-prefixed chunks with some sort of redundant check bytes on the prefix"
<poolie> i think it is in a bit of an uncanny valley between "tolerates random insertion and modification and picks out what structure it can" and "binary protocol must be passed byte-for-byte"
<poolie> some parts are one and some the other
<poolie> and in failure modes you get kind of the worst of both worlds
<spiv> Or even just a chunk sequence number (which would mitigate against being interleaved with another valid subunit stream, if that's a realistic concern?)
<jelmer> poolie: there's still about 500 failures like that in bzr-git, because roundtripping and various other bits aren't complete
<jelmer> poolie: so you're welcome to file a bugreport, but I should get to that issue eventually without one too
<spiv> Ugh, yes, that sounds like a taking all the downsides of Postel's Law without many of the upsides!
<jelmer> poolie: for bzr-svn it's different, if you see failures like this with that then I'm very interested in bug reports
<poolie> spiv yeah it is inconsistently liberal
<poolie> jelmer, ok, i was a bit overoptimistic and thought i'd run my tests without bzr-git skipped
<wgz> it's basically impossible to write good ctypes code
<wgz> I try a different style every time I need to do something, and have never come across one I like.
<thomi|work> wgz: I just tried that debug version of pageant, and it fixes the issue. Are you interested in it's output at all? Any chance you could provide a version that doesn't show the debug info?
<poolie> hi thomi|work
<thomi|work> hi poolie
<Noldorin> poolie, well, any thoughts?
<poolie> Noldorin, i have many thoughts
<poolie> but if you asked a question, i didn't see it
<Noldorin> poolie, heh yes, i'm sure you do. i did. should have your name highlighted above :-)
<Noldorin> if you have a log...
<poolie> oh about download types?
<poolie> oh i didn't realize that was you, hi
<Noldorin> no prob, hi :-)
<poolie> so, let's see
<poolie> actually, let's go to #launchpad-dev?
<poolie> Noldorin, anyhow
<poolie> there are two things i can think of to do first
<poolie> one is help you get lp running locally
<poolie> the other is to talk about how this change could be put in
<Noldorin> poolie, sorry, we can go there if you like
<vila> hi all !
<fullermd> Geez, that's cheerful.  Must be post-coffee...
<vila> :)
<poolie> hi vila
<mgz> morning!
<vila> mgz: hey ! otp right now, but I'd be happy to discuss bug #892992 later
<ubot5> Launchpad bug 892992 in Bazaar "bzrlib.tests.test_config.TestStackCrossSectionsExpand.test_cross_related_sections failure" [High,Confirmed] https://launchpad.net/bugs/892992
<mgz> vila: yeah, just saw that in bugmail
<poolie> o/ mgz
<poolie> vila, so bzr remerge is a bit dangerous
 * vila nods
<poolie> perhaps it should default to only doing conflicted files
<poolie> or maybe only named files
<vila> yup
<vila> I think it didn't because we have cases where the same file where involved in several conflicts or some conflicts may be related and soring them out was hard
<vila> afaik, I've fixed all cases where the same file were involved in several conflicts so it may be possible to be do it right now
<poolie> hm
<poolie> so that could be done separately, and probably should be
<vila> otherwise, that will be a limitation requiring that all other conflicts (not .po related) should resolved first
<poolie> ok
<poolie> so that sounds pretty good
<poolie> you perhaps should explain in more detail on the bug how the proposed fix will work
<poolie> so slangasek is clear
<vila> yup
<poolie> hm
<poolie> the other thing we really need which i have saliently failed to do yet
<poolie> is a restfulclient update
<poolie> every time lp does a fastdowntime it bumps the importer
<poolie> mostly avoidably
<vila> right, I've recorded the corresponding failures so far.
<vila> Some are related to restfulclient, but not all.
<vila> So having a way to list/remove them still sounds like a good idea, you could get the restfulclient ones from that
<poolie> what do you mean?
<poolie> vila, i would love if bzr gardner worked in a colo
<vila> it should and will ;)
<vila> err, it probably doesn't yet is what I meant
<poolie> i understand
<poolie> hi mgz, how's it going?
<mgz> hey poolie, well.
<poolie> i was going to chat with you but it's getting pretty late
<mgz> we didn't settle an exact time to move our 1-1 to I don't think, maybe we should do that at least now
<poolie> mgz, vila, jelmer, i was wondering the other day what to do at the rally
<poolie> maybe bfbia
<poolie> maybe showing more branch content in the lp ui
<poolie> maybe we should also have a more specifically bzr focussed event
<mgz> I thought it'd be a good chance to look at some of the udd workflow/quilt things
<poolie> oh, yeah, that would be a really nice thing to work on too
<poolie> especially with all the platform people
<vila> +1 on reserving at least part of the event to be bzr-focused
<mgz> now I've worked out what bfbia is, that's also what you were saying :)
<poolie> mm
<poolie> that's a bit more specific
<vila> otherwise, getting launchpad running in an lxc container whould be very helpful to help debug the importer
<poolie> mm
<poolie> does it have to be lxc?
<poolie> it's pretty trivial to get it going in a schroot
<poolie> you know schroots :)
<poolie> and you avoid some amount of lxc flakiness
<vila> right, but lp declares a bunch a specific hosts too
<vila> and not polluting the host (as opposed to guest, gee synonyms) will make it easier to manage
<poolie> hm?
<poolie> you're talking about putting them into /etc/hosts?
<poolie> you could run the udd importer from a separate schroot
<poolie> then the real host won't need to know the name of anything
 * vila blinks
<vila> I should know that /etc/hosts is part of the chroot don't I ?
<mgz> ah, I missed thomi|work after I went to bed last night
<mgz> thomi|work: I am a little interested in the output, and have forwarded the fix upstream (other changes on trunk may also have avoided the bug for you)
<mgz> I'll put up a build without the debug output later, but hopefully putty will do a new release relatively soon too
<jelmer> mgz: wrt our discussion yesterday, would it perhaps make sense to make the iter_revisions / iter_files_bytes HPSS calls take a compression ("bz2", "zlib") argument?
<spiv> jelmer: sounds ok to me (although I'd be a touch concerned about the load that might add to a server)
<jelmer> hi spiv
<jelmer> spiv: do you know why get_parent_map uses bz2 rather than anything else?
<spiv> jelmer: in the most ideal of worlds the server would be able to send that those records directly from the repository's internal storage format already compressed without needing to do any processing at all
<jelmer> spiv: ah, I see
<spiv> (perhaps not for iter_files_bytes, but iter_revisions in principle should just be sending a record stream)
<spiv> jelmer: get_parent_map uses bz2 because that's what lifeless chose to make it do :)
<spiv> jelmer: so ask him :)
<jelmer> spiv: will do, thanks :)
<spiv> (I suspect the answer is something like: that for the relatively small amounts of data involved the CPU load on the server probably isn't a big deal vs the savings in round-trips and thus making the server repeat work re-reading indices)
<spiv> But lifeless being lifeless I expect he measured :)
<spiv> jelmer: hmm
<mgz> spiv: that ideal is the same I was wishing after last night :)
<spiv> jelmer: so iter_files_bytes could also be built on record streams
<jelmer> spiv: the server side implementation already relies on get_record_stream
<spiv> jelmer: and the record stream APIs already have a way to express âhey I'd prefer stuff optimised for repo format Xâ
<spiv> jelmer: but the limitation you'll need to work around is that at the moment the queries to generate record streams aren't very flexible:
<mgz> I'm reasonable sure bz2 was smaller when it was added, but I'm curious how much that's still true, the cost is pretty high
<spiv> jelmer: it's easy to say âgive me all revisions+inventories+texts+signatures+chks for {list of revisions, full ancestry of list of revisions}"
<spiv> jelmer: but atm it doesn't really provide for âno, really, I just want the full texts for everything in the tree of rev Xâ, for instance
<jelmer> mgz: hmm, yeah. I just used bzip2 for consistency (because get_parent_map uses it), but perhaps I should give it some more thought.
<spiv> jelmer: which is what my half-done (but working as a prototype) brHPSS for stacked branches branch helps fix.
<spiv> jelmer: or rather, that branch just adds a rather useful special case in a slightly hacky way
<spiv> jelmer: but the general idea of using record streams even more is a good approach I think
<spiv> (That particular special case also sort-of addresses the âlook up all the inventory and CHK pages server-side and just send me what I needâ rather than making the client traverse the revision->inventory->chk pages->texts links)
<jelmer> spiv: yeah, it would definitely be nice to have the server handle those lookups
<spiv> So a problem with just providing an HPSS iter_files_bytes for lightweight checkouts that for large trees (i.e. many files, deep directories) it still requires the client to get full inventory (so finding all the chk pages), which currently needs umpteen round trips.
<spiv> Ideally you'd use something like the texts-for-rev hack that unlanded branch adds and use that
<jelmer> spiv: your texts-for-rev branch was what got me into all of this :-)
<spiv> Except we don't have great tools for consuming record streams apart from inserting them into an acutal repo
<spiv> And for the lightweight checkout case we'd be happy enough to just build the inventory object in memory, and then unpack the text records directly to the filesystem as we receive them
<spiv> But the infrastructure to do that doesn't really exist yet AFAIK, although it's in principle possible.
<jelmer> spiv: the lightweight checkout case is what I've been looking at so far - having a streaming Repository.iter_files_byes (done, but using bz2) and a working Repository.get_inventory should be sufficient for that afaict
<spiv> (You could in the interim write the stream out to a temporary repo and delete it after the tree build)
<jelmer> (checkout uses Repository.iter_files_bytes)
<spiv> What precisely is Repository.get_inventory going to send over the wire for CHK repos?
<spiv> Perhaps just a full inventory in the HPSS inventory-delta format?
<jelmer> That's a good question
<spiv> Because sending just the 'inventory' record isn't going to do you much good :)
<jelmer> right, the other alternative would be using .serializer.write_inventory_to_string
<spiv> "Hi, have the name of the chk root page, kthxbye"
<jelmer> but that's going to use the old XML serializer which we want to get away from
<spiv> Ugh, no
<spiv> That also reinforces the rich-root and subtree watershed
<spiv> Whereas inventory-deltas are a touch nicer IIRC
<spiv> There's also code to encode a full inventory as an inv delta (it's needed for some corner case I forget)
<spiv> s/also/already/
<spiv> So I'd suggest reusing that.
<jelmer> I'll have a look at that, thanks.
<spiv> Also, it'll push you more in the direction of record streams :)
<spiv> Which is really where we want to be, I think
<spiv> They are intended to be an abstraction that works well both as an internal API and over the wire.
<jelmer> yeah, they're quite reasonalbe
<jelmer> the Repository.iter_revisions / Repository.iter_files_bytes HPSS calls are both very much oriented towards record streams (don't return in a specified order, allow for absent records)
<spiv> So I'd try to keep in mind that there are separate concerns:
<spiv> 1) How to deliver records over the wire: record streams.  2) How to efficiently ask the server which records to send for a given use case: case-by-case improvements needed :)
<spiv> Incidentally, I reckon if you finish my branch so that 'bzr branch --stacked HPSS_URL' becomes fast, it will be a great thing to recommend for many uses people currently use lightweight checkouts for
<spiv> (Not all, but certainly some)
<spiv> I suspect there are folks that would rather have a real branch than a checkout, so long as they don't have to pay the full cost of all history (and having a bit more data cached locally, data that's actually relevant to making e.g. 'bzr diff' run fast, is also a plus)
<spiv> Folks that just want a really cheap readonly mirror of something that they want to be able to update to the current tip periodically will of course be better off with a lightweight checkout
<spiv> But I know I'd love to be able to do e.g. 'bzr branch --stacked lp:gcc' and have it get me a usable branch in time and bandwidth not much more than the size of the eventual tree on disk.
<jelmer> spiv: I can't agree more
<jelmer> vila: I'm getting build failures with sphinx on precise, have you seen those?
<jelmer> s/build/test/
<jelmer> TypeError: expected string or Unicode object, NoneType found
<jelmer> while trying to pickle something
<mgz> hm, I don't get bzr-builddeb bug mail.
<jelmer> mgz: you can subscribe :)
<mgz> I'm used to mail magically appearing :)
<fullermd> I certainly get mail all the time as if by supernatural agency.  But I'm pretty sure it's more of the infernal than divine sort...
<vila> jelmer: meh, those will be... interesting, do you have more info ?
<vila> jelmer: not seen on babune apparently, may be the dependencies are not installed there
 * vila tries to remember what bell is ringing...
<jelmer> vila: e.g. http://pastebin.ubuntu.com/745133/
<jelmer> vila: you were at the front door wondering why there was nobody there ? :)
<vila> LOL
<vila> I've never seen the bottom of this traceback but the top of it... well, sphinx internals have evolved so I'm not that surprised (a bit disappointed though :-/)
<vila> sphinx or docutils
<vila> hmm, and oneiric /usr/lib/pymodules/python2.7/sphinx/environment.py is different as line 250 doesn't match the one you're reporting for precise...
<jelmer> I have 1.0.8+dfsg-2
<vila> I have... no sphinx in my schroot precise ;)
<vila> jelmer: where do you get that ? On your local setup or in some build env ?
<mgz> is the OOM from commiting something small in repo with big files repacking related?
<jam> mgz: most likely
<jam> "bzr commit" takes less memory than "bzr pack"
<jam> though bzr-2.4 should do better in that regard
<jam> (lower peak during pack)
<jelmer> vila: this is on my local setup
<jam> mgz: I meant to mention it, but then deleted the email before responding :)
<jam> jelmer: my comment was a basic comment about your hpss series of changes, not specific to one patch
<jam> I might have just missed the testing
<vila> jelmer: ok, file a bug then, we strictly support sphinx only for the host that generates doc.bazaar.canonical.com, but the plan is still to switch to sphinx... when time permits
<jam> I wasn't looking super close, but I thought a few of them didn't have any changes in a test_* file.
<jelmer> jam: All of them should be updated at least bzrlib.tests.test_smart *and* bzrlib.tests.test_remote. I'll double-check
<jelmer> *updating
<GRiD> hi
<mgz> hey GRiD
<vila> jelmer: hmm, saying only doc.b.c.c is the only place where we care about sphinx may be over-optimistic, iirc, windows and osx installers build their own doc
<vila> jelmer: filing a bug is even more the way to go
<jelmer> vila: will do
<jelmer> vila: looks like it's caused by lazy_regex
 * vila pulls his remaining hairs
<mgz> ehehe
<jelmer> I'm submitting a patch to make lazy regex compiled expressions pickleable
 * fullermd makes a note to keep his head away from vila.
 * vila notes the backup plan
<mgz> jelmer: just thunk on __reduce__ maybe?
<vila> jelmer: won't it be simpler to delay importing the real 're' and just get rid of lazy regexp in this context ?
<mgz> it's worth not making lazy regexprs blow up pickle anyway
<vila> hmm, may be, but I don't think we use pickle anywhere close regexps in bzr otherwise, whatever is simpler is fine by me
<jelmer> mgz: re registers a custom type handler, so __reduce__ doesn't get called as far as I can tell
<mgz> jelmer, just something like this isn't enough?
<mgz> def __reduce__(self): return (re.compile, (self.pattern,),)
<jelmer> mgz: hmm, that's a good point
<jelmer> mgz: I was looking at unpickling back to a lazy compiled regex, but that's not really necessary
<mgz> in practice, return (_real_re_compile, self._regex_args) ...but need to fold in kwargs first
 * jelmer settles for __getstate__ / __setstate__ instead
<lifeless> jelmer: pickle, really?
<mgz> need a break for food before finishing this off
<trashbird1240> hello
<trashbird1240> I accidentally pushed a branch to a repository root
<trashbird1240> can I undo it somehow?
<trashbird1240> (or have I not done anything harmful?)
<jelmer> lifeless: I'm afraid so
<jelmer> trashbird1240: you can remove the branch from that location by using "bzr rmbranch LOCATION"
<jelmer> that should keep the repository intact
<trashbird1240> jelmer: okay, let me try it
<jelmer> lifeless: (this was for the benefit of sphinx, not because I'm planning to use pickle myself)
<trashbird1240> wait: is LOCATION a directory? url?  what is it?
<jelmer> trashbird1240: local file path or url
<trashbird1240> okay, so my branch (the one that I accidentally pushed ) is called "dynamics"
<trashbird1240> do I go to the root of the repository and use "bzr rmbranch dynamics"?
<trashbird1240> let me check the help...
<jelmer> trashbird1240: presumably if you ran "bzr push FOO" you would now run "bzr rmbranch FOO"
<glyph> trashbird1240: branches aren't called things
<glyph> trashbird1240: they have URLs :)
<trashbird1240> okay, bzr remove-branch gave me no output, so I presume it worked ;)
<trashbird1240> I pushed to a local directory
<jelmer> trashbird1240: if you run it again, it should tell you there is no branch to remove
<trashbird1240> i.e. the repository is in /var/www/<place where my brancehs go>
<trashbird1240> OK...
<trashbird1240> bingo
<trashbird1240> I got "not a branch"
<trashbird1240> Thanks!
<glyph> jelmer: so uh, if I do 'bzr branch . foo', is it going to treat the repository in the branch as a shared repository?
<glyph> (assuming no shared repository exists above .)
<jelmer> glyph: only if the repository in . is marked as shared
<jelmer> (created with "bzr init-repo")
<glyph> jelmer: interesting
<glyph> jelmer: is there a series of commands that will make that happen, or do I have to mess with files in .bzr?
<glyph> ('touch .bzr/repository/shared-storage' if I understand the magic correctly?)
<jelmer> glyph: touch .bzr/repository/shared-storage
<jelmer> though "bzr reconfigure" might also have an option that will do that for you
<glyph> jelmer: no option I can see in the --help
<lifeless> jelmer: sphinx *pickles* stuff? wtf?
<jelmer> glyph: I can't either, so I've filed bug 893312
<ubot5> Launchpad bug 893312 in Bazaar "reconfigure can not make a repository shared or unshared" [Medium,Confirmed] https://launchpad.net/bugs/893312
<jelmer> lifeless: the build() method in sphinx pickles the build environment and saves it to disk
<lifeless> jelmer: aieeeeeeeeeeeeeeeeee I'm blind
<salgado> hi.  I thought there was an easy way of committing the result of a merge using the message of the last merged revision, but I can't seem to find it?
<jelmer> lifeless: :)
<jelmer> salgado: I'm not aware of one..
<jelmer> salgado: it should be pretty easy to write a hook that does that though
<lamalex> lifeless, ping- are you around?
<salgado> jelmer, oh, ok, thanks.  I might give it a go at some point :)
<lifeless> lamalex: hi
<lamalex> lifeless, im trying to use testtools but im getting a goofy error i dont really understand when i run my tests with python -m testtools.run
<lamalex> http://paste.ubuntu.com/745394/
<lifeless> your test isn't importable
<lifeless> probably you have the name 'foo.py'
<lifeless> 'foo.py' is not importable.
<lifeless> 'foo' is
<lifeless> ah - launchpad-tests.py
<lifeless> rename that launcher_tests.py; testtools.run launchpad_tests
<lamalex> launcher
<lamalex> but really?
<lamalex> it's a python file
<lamalex> why wouldn't it end in .py
<lamalex> like every other python file
<lifeless> it should
<salgado>  /afk
<lamalex> is launchpad_tests a class name/
<lifeless> no, its a module name
<lifeless> launcher_tests
<lifeless> do this
<lifeless> $ python
<lifeless> >>> import launcher_tests
<lifeless> it will fail
<lamalex> ah ok
<lamalex> i got it
<lifeless> jelmer: so for clarity - sphinx upstream went insane, right ?
<lifeless> jelmer: can we get it rolled back in precise? And send some stormtroopers to the authors?
<jelmer> lifeless: they're not pickling the entire docs, just some bits of the configuration
<jelmer> lifeless: it's not that bad, is it?
<lifeless> jelmer: you tell me, how do they handle the config changing?
<lifeless> 2-way diff?
<lifeless> 3-way?
<jelmer> lifeless: I have no idea
<lifeless> It seems like a likely source of failure-to-update bugs
<lifeless> as well as making the sphinx environment suspectible to arbitrary code execution, so becomes security sensitive
<lifeless> so yeah, I think its pretty bad
<lifeless> admittedly not as bad as the python json modules default-arbitrary-code-execution facility
<jelmer> lifeless: hmm, /usr/lib/pymodules/python2.7/sphinx/environment.py:66
<jelmer> # This is increased every time an environment attribute is added
<jelmer> # or changed to properly invalidate pickle files.
<jelmer> ENV_VERSION = 39
<jelmer> lifeless: I don't think there are situations where we open random pickle files though
<jelmer> s/don't think/know/
<jelmer> ehm, know there aren't
<lifeless> if I can alter your pickle file, I can make you run arbitrary code.
<lifeless> Its precisely as safe as 'eval <arbitrary file>'
<jelmer> lifeless: sure
<jelmer> lifeless: but this is just data generated by a local version of sphinx, stored for later reevaluation
<lifeless> jelmer: I understand that; I don't understand why they need that, and it is insecure
<jelmer> lifeless: whether it is insecure depends on how they use the pickle file, and in the overall setup, who can write to it
<spiv> lifeless: configuring sphinx already involves arbitrary code
<spiv> lifeless: so I'm not sure it's any less safe security-wise, but that certainly means its unsafe for robust pickling :)
<lifeless> spiv: :)
<lifeless> jelmer: its fundamentally not my problem, at least I know now to avoid sphinx for all my projects.
<lifeless> jelmer: yes, I am willing to not use a tool because it uses pickle.
<spiv> (or perhaps my hazy memory of how sphinx works is wrong, but I have a pretty strong gut feeling that pickles are a bad idea here)
<mwhudson> spiv: -here
<jelmer> lifeless: I don't like pickles either, but I don't see how it is necessarily a security issue.
<spiv> mwhudson: hmm, I'm not *entirely* against pickles
<mwhudson> spiv: i like them in burgers, i guess?
<spiv> mwhudson: there's a very occasional quick hack where they can be tolerable ;)
<spiv> Hah
 * mwhudson is making changes that take a few minutes to test, please excuse ongoing silliness
<lifeless> I think pickle is fine when you can be absolutely sure noone else can ever under any circumstance compromise the pickle.
<spiv> mwhudson: you can't be sillier than all out for 47 :P
<lifeless> e.g. when its a tempfile() you immediately unlink :)
<mwhudson> spiv: hah
<lifeless> bbs
<mwhudson> i think the idea that you can serialize arbitrary objects is a fairly hair-raising one
<mwhudson> spiv: even ponting scored some runs last time though
#bzr 2011-11-22
<poolie> hi there mgz
<vila> hello  there !
<mgz> morning!
<poolie> hi mgz, jelmer, vila
<poolie> shall we talk?
 * vila mumbles
<mgz> I'm on.
<lifeless> jelmer: hi, around /
<hrw> hi
<hrw> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 23: ordinal not in range(128)
<hrw> I got this during merge
<hrw> http://pastebin.com/1VqWu9Ag to be exact
<mgz> hrw: not a very useful traceback that, sec
<hrw> mgz: I know.
<mgz> what's merge_changelog.py ? It's not the changelog-merge plugin.
<mgz> ah, in bzr-builddeb
<hrw> moment
<hrw> /usr/share/pyshared/bzrlib/plugins/builddeb/merge_changelog.py
<mgz> what's your line 73 in that?
<hrw> 2.7.9ubuntu1 version from precise
<hrw> gnome-terminal suxx when it comes to copy/paste ;(
<hrw>             _logger.warning('%s', stderr)
<hrw>             # Relay the warning from dpkg-mergechangelogs to the user.  We
<mgz> okay, I have that on the tag too.
<hrw> I merged lp:ubuntu/gcc-4.6 into lp:~hrw/ubuntu/precise/gcc-4.6/cross-fixes
<mgz> hrw: file a bug, looks like the log statement is just slightly borked
<hrw> ok, thx
<mgz> I think all you lost was the detail output from dpkg-mergechangelogs', base_filename, this_filename, other_filename], stdout=sub
<mgz> ...bad paste
<hrw> mgz: bzr diff after merge tells me that whole changelog was dropped
<mgz> I want to say do `bzr remerge debian/changlog` but I'm not certain that will do the right thing with builddeb
<hrw> may try
<hrw> did not
<mgz> same problem, or different one?
<hrw> http://paste.ubuntu.com/745683/
<mgz> ta.
<mgz> okay, that's good.
<hrw> so bug against bzr-builddeb?
<mgz> yeah, but I can give you a patch to try now so you can see the output
<hrw> ok
<hrw> btw - how to tell bzr that I solved conflicts in files?
<mgz> ...hm, simplest thing is problably, change the logger line to:
<jelmer> hrw: "bzr resolved"
<jelmer> lifeless: hi
<hrw> jelmer: thx
<mgz>     _logger.warning('%s', stderr.decode("utf-8","replace"))
<mgz> just for now
<mgz> I'll work out how to make the logging module do something sane later
<lifeless> jelmer: nvm - see #subunit
<mgz> hrw: so, if you want try editing merge_changelog.py with that and then remerge
<hrw> debian/changelog is not conflicted
<hrw> dpkg-mergechangelogs: ostrzeÅ¼enie: /tmp/tmpKJKi6cdeb_changelog_merge/changelog.this(l0): oczekiwano first heading, a znaleziono koniec pliku
<hrw> dpkg-mergechangelogs: bÅÄd: ss-970814-1 is not a valid version
<hrw> All changes applied successfully.
<hrw> shit. forgot LC_ALL=C
<hrw> anyway still 10K -
<mgz> it's okay, the messages are for your benefit :)
<hrw> btw - are there plans for 'bzr diff --stat'?
<hrw> bzr diff|diffstat is longer to write ;)
<poolie> that would be good
<mgz> okay, so one issue is the logging is borked, the other seems to be that a failure from dpkg isn't resulting in a conflict you could try and resolve via other means
<mgz> jelmer may know more.
<hrw> poolie: and may give 'bzr log --stat' which in git land is one of my favorite
<jelmer> are we standing up?
<mgz> I am!
<hrw> ok, /me -> reporting bug
<mgz> ...we did it at 8 I'm afraid jelmer
<mgz> hrw: thanks, include all your bits, especially the ostrzeâenie parts
<hrw> sure
<mgz> jelmer: we need a part 2 to get your update maybe
<jelmer> mgz: oh crap, I didn't realize we had a DST change :-(
<mgz> we were ignoring it the last few weeks as poolie wasn't around, which was probably confusing
<poolie> ah oops
<poolie> i can try to be away next tuesday :)
<mgz> ehehe
<hrw> mgz: bug 893495
<ubot5> Launchpad bug 893495 in bzr-builddeb (Ubuntu) "UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 23: ordinal not in range(128)" [Undecided,New] https://launchpad.net/bugs/893495
<vila> jelmer: the pad is at http://pad.ubuntu.com/bdhvpZX7Hn if you want to update it
<vila> jelmer: if you don't, just tell me and I'll post it to the ml
<hrw> mgz: I hope that I did not forgot anything
<mgz> hrw: thanks, that should do (though you used LANG=C so it hides why the logging failed!)
<hrw> mgz: no, message is same but now more people may understand it
<mgz> hrw: attaching the changelog.this might help understand why dpkg is failing, it gets removed but...
<hrw> mgz: there is no 'changelog.this' or changelog.BASE etc
<mgz> hrw: yes, that's good, but the reason logging failed was because your locale has non-ascii error messages
<mgz> hrw: yes, because the merge wrongly reports it succeeded
<hrw> mgz: ok, will add
<hrw> added comment
<mgz> if you `bzr --no-plugins remerge debian/changelog` what happens?
 * mgz hasn't played enough with bzr-builddeb yet to know all its tricks
<hrw> debian/changelog is not conflicted
<hrw> Text conflict in debian/changelog
<hrw> 1 conflicts encountered.
<hrw> mgz: cool!
<mgz> that's better, do you now have a .THIS?
<mgz> just attaching the raw changelog with conflict markers may be useful.
<hrw> I have BASE/THIS/OTHER
<hrw> attached all of them
<mgz> great!
<mgz> hopefully you can now manually resolve the conflict and continue working.
<hrw> yep
<hrw> thx for help
<mgz> ...and naturally dpkg-mergechangelog works fine on those files for me, so the bug is somewhere else
<hrw> mgz: I will push my branch to LP so you can try it on your system
<jelmer> vila: updated
<vila> hehe, you mean updat*ing* :)
<hrw> mgz: pushed, remember to use r71 not head
<jelmer> vila: no, really done now :)
<vila> ok :) Thanks !
<mgz> I guess changelog.this is 0 bytes in /tmp it's not clear how that happened
<mgz> also I get *some* output like that, and one of the three copies has to have content or you wouldn't get the complaint about the version number from 1997
<jelmer> vila: hpss-branch-store branch submitted :)
<mgz> the great thing about unix tool naming conventions is you can accidentally have your hand over the wrong place on the keyboard, and you'll still end up running something
<mgz> I wanted vi back, and got information about my disk usage instead, thanks unix!
<jelmer> :)
<vila> jelmer: reviewed, small tweaks, but big +1 overall and many thanks
<jelmer> vila: that was quick :) Thanks
<vila> jelmer: hehe, the context was paged in, it helped ;)
<vila> jelmer: and I trust the tests are robust enough :)
<jelmer> :-)
<jelmer> sigh, this is the last time I'm buying cheap post-it notes. My real-life kanban board is coming apart
<mgz> jelmer: I wouldn't blame the post-its
<mgz> the number of mps you've submitted would tax any glue
<mgz> the board must be about ready to collapse
<jelmer> mgz: I hope not. I'm using one of the load-carrying walls here.. ;-)
<jelmer> mgz: you seem to have a couple of approved branches, btw
<mgz> jelmer: thinking of commit messages is hard?
<mgz> I mean, sure, I'll get them landed. :)
<LeoNerd> I sometimes find the trick with commit messages is managing to get them brief enough
<LeoNerd> I have a tendancy sometimes to waffle on a bit
<mgz> jelmer: what's the protocol for unprivating? bug 876511 is interesting and doesn't seem to have any personal info.
<ubot5> Error: Launchpad bug 876511 could not be found
<mgz> how little you know, ubot5
<jelmer> mgz: :)
<jelmer> LeoNerd: Hah, I have the opposite
<jelmer> LeoNerd: which is also problematic
<jelmer> mgz: basically, if it doesn't contain any private info, feel free to unprivatize it
<jelmer> I think apport creates private bugs by default
<mgz> some part of the testament code is getting a bytestring and thinking it's unicode
<jelmer> that's bad
<mgz> I'm not sure which though :)
<mgz> what does tree.list_files return for paths?
<mgz> revision-ids would be possible but... seems unlikely
<mgz> revprops is the other candidate
<mgz> list_files uses os.listdir which is always a bad sign.
<jelmer> vila: I'm not sure I understand your last comment on hpss-branch-store
<vila> the one about adding comments ?
<jelmer> vila: yeah, about RemoteBranchStack and cmdline overrides
<vila> these stacks are... weird/obscure, the comments intend to clarify why they exist at all
<jelmer> vila: what kind of comment would you like me to add?
<vila> the ones I pasted should be enough to raise awareness that there is something going on with these stacks
<jelmer> vila: but do you want me to add comments to hpss-branch-store, or were you just providing context?
<vila> just adding comments before the classes
<vila> so people don't think they can use them
<vila> they are a symptom that something else need to be fixed
<jelmer> vila: actually, I'm not sure I understand why the other stores aren't in there
<jelmer> vila: it seems like the global and location stores would apply for remote branches too
<vila> doing so means the local user can enforce some policies on the remote server
<jelmer> vila: the policies aren't sent to the remote server, so nothing will be done that the user isn't already allowed to
<jelmer> vila: i.e. I have lines like this in my locations.conf:
<jelmer> [bzr+ssh://bazaar.launchpad.net/*]
<jelmer> child_submit_to = merge@code.launchpad.net
<vila> the policy depends on the config option
<jelmer> vila: can you give an example of where it would be problematic?
<vila> for some options it's ok to give control to the user, for some others, the actual code don't give this control
<vila> don't turn the tables :)
<vila> I'm merely respecting what the code does ;)
<vila> another way to look at it is to think about the *server* locations.conf and bazaar.conf files which lp doesn't define but that other servers can
<vila> and think about the (weird and maybe useless) case where a server can be accessed as a smart server *and* as a dumb server
<jelmer> vila: The existing code does look at locations.conf
<vila> for the options I mentioned in the comments ?
<jelmer> vila: no, but for other options - like child_submit_to, or remote_ssh_path
<vila> right, these stacks aren't used for the other options :)
<mgz> nope, can't repo it, filenames and properties seem fine
<jelmer> vila: I don't see how remote_branch.get_config_stack().get("child_submit_to") can look in locations.conf
<vila> argh, then your proposal is bogus and I failed to see that
<jelmer> vila: how do you imagine it will be able to look in locations.conf ?
<vila> it should use a BranchStack but query the branch for the right store
<jelmer> vila: that's what I was proposing earlier :)
<vila> yeah and I agreed with that, I missed it when reviewing, lack of tests too
<jelmer> vila: I still don't really see where your comments about branch_only_stacks come in
<vila> you're right in to the trap
<vila> you used the wrong stack
<vila> well, somehow
<jelmer> vila: used the wrong stack where?
<vila> RemoteBranch.get_config_stack() should use config.BranchStack(),
<vila> and config.BranchStack should ask the branch for the right store
<vila> RemoteBranchStack should be used only for stacked_on_location
<vila> and I don't know if RemoteBzrdir.get_config_stack() should be defined at all... it's likely to cause the same kind of confusion
<vila> jelmer: does that make sense ?
<jelmer> vila: yep
<vila> jelmer: pfew, thanks :)
<vila> these are existing grey areas that concern only those two options afaik
<vila> which I why I defined these stacks without using them yet as a reminder that these options are... special
<vila> .. in the existing code I mean
<jelmer> vila: I think Remote{Branch,Control}Stack is a really confusing name in this case though
<vila> yeah, in this other proposal I was naming them control_stack_only and remote_branch_only
<vila> or rather control_only_stack and branch_only_stack, anyway, 'only' is the important part ;)
<vila> even cmdline_overrides shouldn't apply there... I think :)
<vila> the specific aspect that is not clear in the actual config scheme is option policy, stacks helps a bit, but really, what defines an option policy is which stack is used to handle them in the code,
<vila> some options are handled with GlobalStack, some are handled with BranchStack for example
<jelmer> vila: updated
<jelmer> vila: I've now just changed BranchStore to call Branch._get_config_store(), and bzrlib.remote doesn't have anything related to stacks anymore
<vila> reading already
<vila> right, bzr config -d lp:xxx now displays bazaar.conf content, I should have thought to check that
<jelmer> I thought it always did that?
<jelmer> that seems right to me
<vila> taking your previous example, `bzr config  child_submit_to` would be broken if it was
<jelmer> vila: ah, sorry. You mean it only displays bazaar.conf content
<vila> no, I mean it now displays branch.conf *and* bazaar.conf (nothing relevant in locations.conf so nothing is displayed) instead of only branch.conf
<jelmer> vila: it never displayed just branch.conf
<jelmer> vila: if I only have bzr_remote_path set in bazaar.conf it would previously show that too
<vila> jelmer: it did with revno 6284 if your proposal
<vila> s/if/in/
<vila> when doing  ./bzr config -d lp:~jelmer/bzr/switch-colocated
<jelmer> vila: r6284 of my proposal is wrong :)
<vila> yes
<vila> oh, sorry, I was so unclear
<vila> what I meant is that I could have use that to see 6284 was wrong
<jelmer> ah
<vila> because it wasn't displaying bazaar.conf anymore
<vila> jelmer: done, some last nits if you feel like taking them into account
<vila> well, at least the news entry one :)
 * vila lunch
<jelmer> vila: merci et bon appetit :)
 * jelmer has a somewhat limited French vocabulary
<vila> jelmer: you've already got the most important ones :) ... "Je vous aime" can help in many situations too ;-D
<jelmer> hehe
<jelmer> French is the main language of one of the other projects I'm involved in (OpenChange), so I do read quite a bit of it.
<mull> jelmer, hi, thanks for looking at my fastimport patch; I've just proposed a merge.  Feel free to ping me here if you have questions.
<jelmer> mull: thanks. I've just followed up
<mull> ok.  oops, I had completely forgotten that I left an "assert" in there... that's not ideal
<mgz> have, that's a nice suprise,
<mgz> 5 second runtime down to 2 second runtime
<mgz> that will make a 0.0001% to the build process
<GRiD> hm. in general, a bzr import from mercurial (on google code) to launchpad should work? looks like bzr 2.5.0 according to this error log.
<jelmer> GRiD: it's still in beta, and far behind git/svn imports
<GRiD> jelmer, ok. well, i used the standard launchpad interface for doing the import. is it worth filing a launchpad bug?
<GRiD> actually, i see there is one. bug #806904
<ubot5> Launchpad bug 806904 in Launchpad itself "Mercurial import fails from Google code" [High,Triaged] https://launchpad.net/bugs/806904
<mull> jelmer, now I know why I wrote the code how I did... when you say "bzr fast-export x..y", revisions up to and including x are _already_ chopped off
<mull> so my code was getting the parent of revision x+1
<mull> funny that I couldn't remember that 24 hours later, and it took writing the test case to realize
<Noldorin> hi folks
<jelmer> hi Noldorin
<Noldorin> hi jelmer
<Noldorin> how's it going?
<jelmer> Noldorin: I'm alright. how are you?
<Noldorin> jelmer, pretty good. going to have a go at a small patch poolie and i were talking about
<poolie> hi all
<thomi|work_> wgz: sorry for the delay: http://pastebin.com/Bi1ZseQL
<wgz> thomi|work_: thanks, it does look like 0.61 triggered a lot of this pain then, because the 'ours' old and new values are different there
<wgz> thomi|work_: <http://float.endofinternet.org/temp/pageant.zip> is a non-debug pageant with the fix
#bzr 2011-11-23
<meth> is there something like tig for bzr ?
<treaves> If there is not, no one here would know, as no one here would know - or care - what 'big' is.
<treaves> ^big^tig
<poolie> http://jonas.nitro.dk/tig/
<poolie> a curses gui
<poolie> no, i'd recommend using the actual gui
<poolie> qbzr/bzr explorer
<poolie> looks useful
<spiv> Or even the actual cli :)
<thomi|work_> wgz: thanks!
<mgz> morning all
* jelmer 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: mgz
<mgz> argh, the command hooks again
<mgz> these tests are all broken
<mgz> ha, and fixing the test makes it fail spectacularly.
<jelmer> mgz: :-S
<mgz> what's the best help we have on using scenarios? I just poke around the code base looking for examples each time
<mgz> and have no idea of the best way of doing things.
<mgz> ...using scenarios here is probably a dodgy idea, but amusing.
<jelmer> mgz: that's what I do too..
<jelmer> mgz, vila: Could I persuade either of you to have a look at my lazy-regex-pickle branch?
<mgz> ...that's actually what I was going to do before I got distracted
<mgz> I wonder if 246 tests is too many... :)
<jelmer> 246 tests for what ? :)
<mgz> option help :D
<jelmer> hmmok :)
<CaMason> hi guys. Is there a viable way to squash commits (without a merge operation)?
<CaMason> so for `A-B-C-D-E-F`, I'd like `A-----D----`
<CaMason> I figure I can do the second part with 3 uncommits, followed by a commit. But I couldn't go any further back
<CaMason> I suppose I could `bzr diff -r A..C > squashA.patch` & `bzr diff -r D..F squashB.patch`, uncommit back to A, then patch, commit, patch, commit
<mgz> shelve works
<mgz> avoids messing around with patches
<CaMason> uncommit F-D, shelve, uncommit C-A, commit, unshelve, commit?
<mgz> right.
<CaMason> I could also re-order with shelving too
<CaMason> great. That completley complements our Git workflow
<mgz> jelmer: could you set aside some time this week to team up on reviewing MvG's lazy import branch?
<jelmer> mgz: sure
<jelmer> mgz: that reminds me, could we perhaps talk through some of the HPSS reviews?
<mgz> sounds like a good thing to do at the same time.
<jelmer> cool
<mgz> I'm working from town tomorrow, so how about we say Friday, or do you think we can fit it all in the rest of today?
<jelmer> friday works for me
<beuno> o/
<beuno> quick quesiton
<beuno> how would I run a plugin's command from python?
<beuno> I'm integration qbzr into an IDE written in python
<beuno> and I want the context manu to bring up qbzr's commit dialog
<mgz> do you want to yield execution to qbzr?
<mgz> if not, use subprocess.call
<mgz> otherwise, there are a couple of steps, but it's similar to calling a bzrlib command
<beuno> I guess I could just subprocess it
<mgz> you'll need to work with the qt main loop otherwise, which may or may not be an issue for you.
<beuno> it's a QT app, but also, I ahve zero experience with QT  :)
<mgz> ah, you're doing the qt creator integration?
<mgz> or a different qt ide... you said written in python...
<mgz> starting with subprocess isn't bad, but I recommend a post to the bazaar list with some details, as something more integrated may be preferable
<beuno> different
<beuno> ninja-idea
<beuno> yeah, I'll get the basics with subprocess
<beuno> and email the list
<poolie> goofd morning, hi beuno
<jelmer> hey poolie
<poolie> hi there
<lifeless> â¥ jelmer
<jelmer> hi lifeless, what's with the question mark?
<james_w> heh
<poolie> haha
<poolie> hi james
<lifeless> jelmer: hah, surely your utf8 setup works ;)
<jelmer> lifeless: hah, I see it now.. :)
<jelmer> lifeless: glad you like it
#bzr 2011-11-24
<poolie> lifeless, any reason in particular for the hearts today?
<lifeless> bzr+ssh bzr-search support
<poolie> ah :)
<james_w> hi poolie
<poolie> hi james
<poolie> class OutOfTea(errors.BzrError):
<poolie> :)
<fullermd> Being out of tea sounds more like a solution than a problem to me...   :p
<poolie> page KombuchaKip :)
<poolie> it's an example error in jelmer's test code
 * KombuchaKip lol
<Noldorin> hey poo
<Noldorin> poolie*
<mwhudson> :-)
<sobersabre> hi.
<sobersabre> Is it possible to install bzr 2.5 on python 2.5 ?
<sobersabre> (from source)
<poolie> hi sobersabre, no, i think bzr 2.5 needs python2.6
<poolie> but 2.4.x will be ok
<wgz> bus time
<poolie> hi wgz
<sobersabre> poolie: thanks. I did manage to install 2.4 on py2.5
<poolie> good
<mgz> morning!
<MacSlow> hey there folks
<mgz> hey
<poolie> hi mgz, vila
<poolie> hi mrevell
<mrevell> Hey there poolie and everyone else.
<mgz> really must finish option stuff this morning
<poolie> ok
<poolie> mgz i should go, but could you look at https://answers.launchpad.net/bzr/+question/179852
<poolie> and maybe some others
<poolie> i have loggerhead just about baked serving tgzs
<poolie> i thought of you :)
<mgz> poolie: will do
<mgz> ah, I'd never run an ssh server on a windows box
<poolie> i would like to just hook up 'bzr serve --ssh'
<poolie> how hard can it be? :/
<mgz> not very I imagine, on nix at least :)
<poolie> :)
<poolie> well, using paramiko
<poolie> trying to take care of some of the hookup issues people have
<poolie> on windows
<mgz> I agree we need a better server answer, I do bzr+http with apache doing the access control
<mgz> and that's not trivial to set up correctly.
<mgz> jelmer: you landed a proposal I wanted to comment on too fast ;_;
<mgz> but I was stuck thinking of a better suggestion, so maybe it's not really that bad
<poolie> ok, night europe
<mgz> night poolie!
<mgz> ah, you're working on the config test failures vila?
<mgz> I was just looking at that
<vila> I have a fix
<vila> It's so silly...
<vila> mgz: By the way, hi ! ;)
<mgz> the tests look dodgy, they use a relative url like "/home/user/project", which naturally doesn't resolve anywhere sensible on windows
<vila> it doesn't have to
<vila> it's the caller responsibility to provide an appropriate location and the code base already ensures that
<mgz> but the location stack resolves it using abspath
<vila> for unclear reasons I felt the need to add a location = urlutils.normalize_url(location) which broke these tests
<mgz> which looks at the real filesystem
<mgz> right
<mgz> that's the issue.
<vila> removing that code doesn't break any test and make the windows ones pass
<vila> I probably had another issue while adding that and addressed this issue in the end
<mgz> okay, that's fine then.
<mgz> I don't think I need to say that LocationStack should be clear about if it wants a url or a file path, and isn't currently :)
<vila> I wanted to talk with you
<vila> but thought I should reload the context
<mgz> okay, fresh page.
<vila> and I knew these lines were in scope, so, I tried removing this suspicious call first...
<vila> and my sub-conscience won :)
<vila> hmm
<vila> yeah, this could be clarified...
<vila> s/could/should/
<mgz> so, I have a design twinge that path functions should be clear about whether they look at the local filesystem or not
<mgz> you were basically caught out here by 'normalize_url' looking safe and cuddly, but actually calls abspath which depends on the filesystem and cwd
<vila> I think there is a FIXME in the location config code saying that we accept synonyms for local paths as file: urls which is an issue in itself
<vila> yeah, I vaguely remember adding that because I suspected some relative paths bogus handling
<vila> mgz: https://code.launchpad.net/~vila/bzr/892992-locations-on-windows/+merge/83299
<vila> yeah, in addition to looking safe it silently made the section matching fail, hence the test failures
<vila> this hints that I should have tests more specifically targeting the section matching
<vila> in other news, for unknown reasons the osx slave suddenly decided that it was 'Unable to locate a Java Runtime to invoke.'
<vila> huh ?
<mgz> rubber stamped.
<mgz> blame java!
<vila> dong a software update brought a java *update* and solved the issue but the root cause for this error message is puzzling
<vila> was the precious version disabled ? How ?
<vila> nobody is tweaking this osx slave (except me ;)
<mgz> macs are mysterious objects of wonderment and quizzling
<vila> mgz: thanks !
<mgz> best not approached, or you may come to regret it..
<vila> hehe
<vila> mgz: by the way, regarding your option help tests, try bzr-diffstat, istm one option escapes your check
<vila> the plugin overrides cmd_diff, that may explain the why, but I didn't dig enough to propose a how
<mgz> the global --file option at least is unchecked, which doesn't hurt much
<mgz> and plugins (including builtin ones) aren't either, but would be nice to provide an easy way for them to subclass the test an opt in.
<mgz> how would a plugin enumerate all the commands it registered?
<vila> some plugins already uses a list *to* register
<vila> :)
<vila> slangasek: ping, see bug #884270
<ubot5> Launchpad bug 884270 in Ubuntu Distributed Development "bzr should do smarter merging of .po files" [High,In progress] https://launchpad.net/bugs/884270
<mgz> vila: pqm gave failed your branch?
<vila> mgz: no, it landed it, what made you believe that ?
 * vila forces a run on babune windows slave 
<mgz> ...launchpad being slow, sorry
<vila> no worries, just curious
<mgz> confused by looking during the window between the PQM page showing no jobs, but the review page still having the branch as approved
<vila> oh yeah, I know that one
<vila> sometimes the pqm page shows the end of the previous submission but never for long
<vila> mgz: down to 7 failures (with 3 being spurious not ?)
<mgz> those are all the windows/sftp rename race
<vila> good, down to one root cause then
<mgz> which is now bug 891602
<ubot5> Launchpad bug 891602 in Bazaar "PermissionDenied test failures on windows with sftp" [High,Confirmed] https://launchpad.net/bugs/891602
<jelmer> hmm, more feature flags work this evening
<wgz> ...are you trying to create more of a backlog for the poor patch pilot when he wakes up in the morning?
<jelmer> I'm just worried he'll run out of things to review.
<wgz> ah, now I'm back home I can run my auto-ignore launchpad tag spam imap script
<wgz> which is nice as they've now removed all the tags that accidentally got added earlier...
<thumper> an interesting data point
<thumper> $ bzr branch lp:nux/1.0 nux-1.0
<thumper> Branched 497 revision(s).
<thumper> HPSS calls: 30 (0 vfs)
<thumper> $ bzr co lp:nux/1.0 nux-1.0-checkout
<thumper> HPSS calls: 48 (15 vfs)
<thumper> checkout really that much more expensive in round trips?
<jelmer> thumper: hi
<thumper> hi jelmer
<poolie> hi all
<jelmer> thumper: hmm, thatÃÃÂ really odd
<jelmer> it should basically just be "bzr branch" + "bzr bind"
<poolie> hi jelmer
<KombuchaKip> Are there any plans to hook the Nautilus rename command into the bzr rename functionality when using the plugin for Nautilus on a repository?
<beuno> KombuchaKip, I don't think so, there isn't a lot of activity around bzr-gtk
<beuno> jelmer may know
<poolie> i doubt anyone is specifically planning to do it
<poolie> it seems like a sensible thing to do though
<poolie> iirc hg dropped their nautilus support
<KombuchaKip> beuno: Oh really? I didn't know that. Is the plugin dead? I created this bug report about it. https://bugs.launchpad.net/bzr-gtk/+bug/797438
<ubot5> Ubuntu bug 797438 in Bazaar GTK+ Frontends "nautilus-bzr plugin does not hook rename" [Medium,Triaged]
<poolie> do you want to try a patch for it?
<poolie> it's not dead
<poolie> right now i'm trying to get tarball downloads from loggerhead hooked in to launchpad
<KombuchaKip> poolie: Sure I'd try a patch for it.
<poolie> almost there
<KombuchaKip> poolie: I'll be around, just buzz me whenever you're ready. I am using bzr from the PPA.
<jelmer> hi beuno, KombuchaKip
<jelmer> KombuchaKip: IÃ've done some work recently to port nautilus-bzr to the new Nautilus plugin API
<beuno> o/ jelmer
<beuno> o/ poolie
<poolie> hey there
<KombuchaKip> jelmer: Ah, so that's why its sort of idle right now. I forgot that everything has to be moved to Gnome 3.
 * KombuchaKip enjoys channels with relations to Ubuntu much better than others because the people are nice.
<jelmer> KombuchaKip: it would indeed be nice to hook into the Nautilus rename command, but unfortunately the Nautilus extensions don provide that sort of hook yet
<spiv> jelmer: I guess there's always inotifyâ¦ ;)
<jelmer> spiv: heh
<KombuchaKip> jelmer: I figured that was probably why it wasn't done, because it seemed intuitively straight forward since other commands are hooked. So I suppose we have to wait until Nautilus provides an API for that. Maybe you could add a comment for that at the end of this here? https://bugs.launchpad.net/bzr-gtk/+bug/797438
<ubot5> Ubuntu bug 797438 in Bazaar GTK+ Frontends "nautilus-bzr plugin does not hook rename" [Medium,Triaged]
<poolie> hey spiv
<KombuchaKip> jelmer: I'd do it myself, but I have no experience with the API.
<poolie> i did some lp fixes after gdd, don't know if you saw
<poolie> 'less awful search results' basically
<jelmer> KombuchaKip: thereÃ's already a comment from me there to that extend :)
<KombuchaKip> jelmer: Ah, I understand it now. I just saw that.
<spiv> poolie: I did!
<KombuchaKip> jelmer: I wonder if upstream knows.
<spiv> poolie: (if you're talking about the meta description stuff)
<poolie> yeah, schema.org tags, that kind of thing
<KombuchaKip> poolie: How do you plan to patch it if apparently nautilus-python doesn't have a way to track file renames?
#bzr 2011-11-25
<jelmer> KombuchaKip: I think that would have to be a part of it
<KombuchaKip> jelmer: So basically poor poolie's got his work cut out for him.
<jelmer> KombuchaKip: heh
<jelmer> KombuchaKip: weren't you volunteering to do the work ? ;-)
<KombuchaKip> jelmer: Hey man, happy to test it when he's got it written ;)
<jelmer> KombuchaKip: :)
<jelmer> spiv: I do actually wonder if a bzr background daemon would be a good idea
<spiv> jelmer: it's a really nice idea in principle
<jelmer> apart from automatically updating the dirstate on inotify changes it could take e.g. care of caching some of the data for nautilus-bzr and providing that
<spiv> jelmer: in practice I think it'll be a bit tricky because I doubt the way the OS observes and reports filesystem changes is trivial to map cleanly to what the user thinks they're doing
<jelmer> spiv: right, you wouldn't want to actually track the nasty stuff word does to its files..
<fullermd> With a shotgun, maybe   ;p
<spiv> jelmer: e.g. you'd want to deal nicely with apps that do "save" as "write to tmp dot file, atomic rename over new file", vs. "open existing file for write, write new contents (and maybe truncate?)", and goodness knows what other variationss
<spiv> jelmer: I think it's probably tractable, at least for the majority of important cases
<jelmer> spiv: thfair enough
<spiv> So long as you don't want to try to do something like "auto-commit on every write", anyway
<spiv> Which really wants to be an app-level hook, not OS level, for this sort of reason.
<spiv> But for tracking renames, deletes, and *maybe* some kinds of adds, it seems like it could work.
<spiv> (And potentially for tracking "hey this file has changed, you can assume it's dirstate info is stale now" for optimisation purposes, not sure that's really worth it though)
<jelmer> spiv: yeah, thatÃÃ's the bit I was wondering about. it might have a significant impact in big trees
<mwhudson> autocommit on every write would be shotgun inspiring
<jelmer> IIRC the webdav support in mod_dav_svn can do that for you
<mwhudson> yes
<mwhudson> it was fairly shotgun inspiring, iirc :)
<mwhudson> well, under some circs anyway
<spiv> mwhudson: ISTR at least one emacs user on the list saying they have it hooked up to do that
<spiv> mwhudson: and then they like to rebase -i or some other lossy operation to turn that into a pretty history later.
<mwhudson> spiv: gosh
<spiv> I can sort of see the appeal, even if I wouldn't do that myself :)
<spiv> It's certainly an intriguing way to think about revision control
<spiv> Why shouldn't the scope of your revision control tool include your individual saves, or even individual edits?
<spiv> (And if it does, what should the UI look like?)
<spiv> It certainly makes the difference between "record what I did" and "publish intelligible changes" a bit more important to describe
<spiv> I think to an extent the fact it's currently easy to assume that "what I did" is so close to "what I want to share with others" does encourage the mindset that a little bit of rebasing to go from the former to the latter is the obvious thing to do.
<slangasek> vila: bug #884270> well, I don't currently have any branches needing merging :)
<ubot5> Launchpad bug 884270 in Ubuntu Distributed Development "bzr should do smarter merging of .po files" [High,In progress] https://launchpad.net/bugs/884270
<poolie> hey slangasek
<poolie> he'll be asleep
<poolie> he oughta anyhow
<fullermd> Well, he says that about _me_ all the time...
<slangasek> yes, he pinged me when I was asleep, so :)
<poolie> spiv could you look over https://code.launchpad.net/~mbp/loggerhead/240580-tarball/+merge/83364 ?
<spiv> poolie: seems ok at a glance, I'd be concerned about memory consumption but I see that's already a known issue
<poolie> yeah
<poolie> it makes some efforts to only stream things and not hold the whole tarball in memory
<poolie> i think streaming individual files is out of scope for this
<poolie> and indeed something i plan to go back to right after landing it-
<spm> if we have a lightweight checkout; is the proper method of resyncing that back to it's master (basically we only have a readonly copy); simply to delete and re-check?
<fullermd> Why do you need to resync?
<spm> this is part of an automated rollout/update script; so ensuring it's up to date
<fullermd> Sounds more like a call for update then.
<spm> gnngh. I thought i tried that and it barfed on me.
<spm> no, I did a bzr pull.
<spm> that failed.
<fullermd> Yeah, that would very probably not be what you want  ;p
<spm> do what i mean, not what I ask
<spm> :-)
<fullermd> I think darcs can do that.  It takes a few months though.
<spm> right, that works much cleaner. ta fullermd
<fullermd> Oxygen consumption for the day: justified!
<spm> heh
<poolie> two screenfulls of active reviews!
<poolie> hi vila?
<vila> poolie: hey ! (sry, forgot to say hi)
<poolie> np :)
<poolie> hi jam?
<jam> hi poolie
<poolie> vila, would you mind trying to help https://answers.launchpad.net/bzr/+question/179594
<mgz> morning all.
<poolie> hi mgz
<vila> poolie: meh, I don't understand what the question is there ;)
<vila> mgz: _o/
<poolie> well, that's why i'm finding it hard to deaol with it at 9pm friday
<poolie> :)
<vila> deaol == deal + eod, a sure sign you need to go enjoy your week-end ! ;-D
<vila> (that was a gracious tip from a tyop expert ;)
<poolie> jelmer, hi, it would be nice to do a followup that removes some copypaste from the hpss code
<jelmer> hi poolie
<jelmer> poolie: which copypaste specifically, just the catching of UnknownSmartMethod, followed by _ensure_real call, etc ?
<poolie> yes, that sort of thing
<poolie> not necessarily all of them at once
<poolie> it just does seem pretty duplicative
<mgz> was going to bug jelmer a bit about that in our review blitz today,
<mgz> you've already done a good job on the queue overnight though poolie :)
<poolie> thanks
<poolie> i thought i ought to
<jelmer> poolie: yes, thanks very much for the reviews
<poolie> also, the unconscionably long delayed download tarball patch from xaav is going to be live soon
<jelmer> poolie: I'll see if I can add a decorator
<poolie> something like thta
<mgz> the other thing I wonder about with the hpss changes if we want to start wrapping everything useful, rather than aiming at a curated subset, doesn't that take it all the way to a general RPC interface?
<mgz> not that I'm sure the reduced surface area is very helpful currently, it's pretty trivial to dos a smart server
<spiv> In the ideal world, I think we'd have relatively few RPCs, but ones that are powerful enough to efficiently satisfy all the needs
<mgz> but it seems like the boilerplate isn't of much benefit right now.
<mgz> spiv: that's my general feeling as well, but we don't seem very near that.
<spiv> e.g. rather than get_revisions, it would be nice if that were somehow expressed as get_stream
<spiv> (Or get_record_stream, whatever it is called)
<poolie> ok, that's enough for today
<spiv> Which is in one sense not really any different (what's the real difference between one more RPC and more kind of value for get_stream's argument?)
<poolie> good night all
<mgz> night poolie!
<spiv> Good night!
<spiv> But it feels a bit better to me, somehow
<spiv> Especially as there's the potential to e.g. have iter_inventories reuse the same stuff
<spiv> One thing that would help would be to make bzrlib's own internal APIs for the basic objects (Repository, Branch, perhaps a few others) narrower, or at least built on a narrow subset
<spiv> Another instance was the bug about maybe adding RPCs to accelerate CommitBuilder.  Again I think in a perfect world that would be built on this hypothetical subset
<spiv> (But that's a case I haven't looked at closely at all, so that's just an intuition rather than a carefully considered opinion.)
<mgz> narrow and clearly defined interfaces conflicts with the recent history of feature additions, though
<spiv> Well, in the case of repository (a relatively easy case), what does it really need apart from locking, get_parent_map (and maybe a few other rev graph primitives?) and get_record_stream (with a sufficiently flexible way to describe which stream you need)?
<spiv> And initialize and maybe config, I guess.
<spiv> Oh, and insert_record_stream, of course :)
<spiv> Branch I suppose adds config (including nick), tags, its intrinsic state (last revision info)
<spiv> You need some way to either ask Branch to look up revids/revnos w.r.t. to its ancestry, or to ask a Repo to do that w.r.t. to that particular Branch's ancestry.
<spiv> (e.g. to resolve a dotted revno to revid and vice versa)
<mgz> hm, so get_signature_text and set_signature_text would instead use stream with params to say which repo bits they wanted?
<spiv> mgz: right!
<spiv> And there's possibly some special cases to reduce round trips
<spiv> (e.g. ideally we could initialize a branch+repo+bzrdir, and have it all write-locked ready for insert_record_stream etc, in one RPC)
<spiv> mgz: in fact, set_signature_text almost certainly could and should use insert_record_stream today
 * spiv -> afk
<mgz> on the future feature front, a git-annex-y interface to repo would be neat
<jelmer> spiv: sorry, was off getting some groceries
<jelmer> spiv: thanks for your thoughts :)
<jelmer> mgz: what do you mean with a git-annex-y interface exactly?
<mgz> jelmer: a way for people to keep big files that can't be usefully versioned along with their repos
<mgz> however slimlined bzr makes storing uncompressable, unmergable blobs, you'll never want the entire history of a video render copied around with the rest of the branch
<mgz> without a certain amount of manual what lives where control like git-annex has, there's no way to satisfy the opposing needs
<jelmer> mgz: still up for some peer-reviewing today?
<jelmer> I'm not sure if there is actually much left
<jelmer> ah, John's client-reconnect work
<mgz> yeah, there are a few bits, and I especially got a headset thingy yesterday too,
<mgz> so that needs testing out :)
<jelmer> heh
 * jelmer stumbles onto mumble
<jelmer> bzr: ERROR: Permission denied: "/root/foo/.bzr/branch-format": [Errno 13] Keine Berechtigung: u'/root/foo/.bzr/branch-format'
<mgz> that's a german error without any non-ascii charas
<jelmer> bzr: ERROR: Permission denied: "/root/ÃÂ«/.bzr/branch-format": [Errno 13] Keine Berechtigung: u'/root/\xeb/.bzr/branch-format'
<mgz> I think german is less non-ascii-ish than many other languages
<mgz> 'Keine Berechtigung' needs a sharp-s or something to tickle it
<mgz> ...did you type A-tilde, left arrows or is that a decode bug as well?
<jelmer> No, I typed an e-umlaut
<jelmer> mgz: http://pad.lv/894442
<ubot5> Launchpad bug 894442 in Launchpad itself "Dynamic bug listings are too sparse" [High,Triaged]
<mgz> right, I'm going to grab some food
<jelmer> food, now there's an idea
<mgz> I realised I was actually really hungry, and it's nearly 3 :)
<jelmer> yeah, it's nearly 4 here and I haven't had lunch..
<mgz> all fooded up.
<jelmer> \o/
<mterry> Hey bzr+Ubuntu folks!  You need to file a MIR for subunit in Ubuntu.  Your latest uploads are blocking on building until python-subunit enters main
<mterry> I'll review after you file.  Just ping me
<vila> mterry: huh ? When did python-subunit *left* main ?
<mterry> vila, I don't believe it's ever been in it
<vila> mterry: I'm not the one doing the uploads but I remember the MIR have been filed releases ago
<mterry> https://launchpad.net/ubuntu/+source/subunit
<vila> python-subunit and subunit are different iiuc
<mterry> vila, subunit is the source package
<mterry> vila, but I see what you are talking about: https://bugs.launchpad.net/ubuntu/+source/subunit/+bug/780767
<ubot5> Ubuntu bug 780767 in subunit (Ubuntu) "[MIR] subunit" [Undecided,Fix released]
<vila> jelmer: ^ ?
<vila> ha, jelmer knows already then
<jelmer> vila: hi
<jelmer> mterry: hi
<mterry> yup, left comment and changed bug status
<mterry> vila, thanks
<vila> mterry: thanks for raising the issue
<jelmer> mterry: somebody in #ubuntu-devel mentioned that the promotion to main wouldn't actually happen until somebody in main (or seed) depended on it
<mterry> jelmer, well that's the case now  :)
<mterry> jelmer, or are you saying that it has been promoted but won't "show up" until it's seeded?
<mterry> whatever, it'll sort itself out now one way or the other
<jelmer> mterry: that's my understanding (and why I uploaded with this dependency, despite the fact that subunit wasn't in main yet)
<jelmer> mterry: that's great, thanks :-)
<mgz> vila: do you want to look at jam's client reconnection branch again, or are you okay with us trying to land it now?
<vila> mgz: I'm ok with you ;-)
<mgz> ...there are various fun conflicts to resolve first, but jelmer is having a conflict day already
<lamalex> lifeless, is there any sort of glib runner for testtools?
<lamalex> i started working on one but vaguely remember thumper mentioning one existed in some form
<lamalex> jml, ^^^
<jml> lamalex: there's tribunal
<jml> lamalex: testtools is runner-agnostic though, you can use whatever works with standard unittest
<cr3> hi folks, I'm trying to import bzrlib.plugins.loom.branch on lucid and I get: ImportError: No module named loom.branch.
<cr3> I'm using the bzr ppa and I should have the latest updates: http://pastebin.ubuntu.com/749515/
<mgz> cr3: from outside the context of bzrlib?
<mgz> you'd need to call bzrlib.plugin.load_plugins() first to get the import paths right.
<cr3> mgz: thanks, that worked swimingly
#bzr 2011-11-26
<Noldorin> hi poolie
<Noldorin> does anyone know if Markdown support has landed yet?
<andyla> hi everyone, can someone please help me with this question: we are using bzr for a software project at uni. someday, I accidentally  checked in a huge (~1.5gb) data file. nobody really noted that so we kept working on the project and kept committing new code. But now, everytime we want to branch the repo it takes ages to get it - probably because of this data file.
<andyla> of course I remove the file from version control when i noticed it's in there - but as this doesn't  remove the file from history, it still takes forever to get a branch. Is there a way to get rid off the file in history but to keep every other change?
<andyla> I looked for that nearly everywhere, but didn't find a "nice" solution. I would really appreciate your help with this.
<beuno> andyla, there isn't a nice solution for this
<jelmer> hi beuno, andyla
<jelmer> andyla: you should be able to uncommit until the revision from before the big file was added, and then replay the other revisions
<andyla> thanks jelmer - sorry i didn't reply immediately, i almost gave up hope. im gonna find out if your solution
<andyla>  works for me. thanks a lot
<Noldorin> hi poolie
<jelmer> hi Noldorin
<KombuchaKip> jelmer: Heard back from Adam: https://bugs.launchpad.net/bzr-gtk/+bug/797438
<ubot5> Ubuntu bug 797438 in Bazaar GTK+ Frontends "nautilus-bzr plugin does not hook rename" [Medium,Triaged]
<jelmer> KombuchaKip: thanks
<KombuchaKip> jelmer: np.
<jelmer> KombuchaKip: to be honest, I think for nautilus-bzr we should first be focussing on actually getting nautilus-bzr working properly before we look at fixes like this
<KombuchaKip> jelmer: True. Launchpad is patient enough and that bug can sit there until someone is ready to deal with it, like dirty dishes.
<Noldorin> hi jelmer
#bzr 2011-11-27
<Noldorin> jelmer, how's progress on work?
<odin_> hi I am getting some bzr error, "ERROR you have edited foobar.install instead of foobar-huh.install, please undo/merge changes"
<odin_> makes no sense, "bzr status ." does not indicate anything on these files
<odin_> I just want it to accept the current tree as the new version and commit all
<odin_> no one else is working on this tree, and as far as I know this is the only copy that has been checked out
<jelmer> odin_: I don't think that's an error from bzr itself. Perhaps it is from a plugin you have loaded?
<odin_> well I am only using normal commands
<odin_> it will be a ubuntu package management plugin
<jelmer> odin_: can you pastebin the output of "bzr plugins" ?
<odin_> status/add/commit/push
<jelmer> that error message isn't in the bzr codebase, so it must be from some plugin
<jelmer> odin_: do you mean bzr-builddeb?
<odin_> pastebin.com/WkNcZdik  (typed in)
<odin_> I am not using bzr-builddeb at this time, just status/add/commit/push
<odin_> bzr status .  # is clean
<jelmer> what's the eaxct error message you get, and for which command?
<odin_> opps my bad
<odin_> there is a safety measure in the script that stops you from editing the wrong files
<odin_> the script front-ends  status/add/commit/push to allow 1 debian/* to target 4+ versions of ubuntu
<jelmer> aha
<jelmer> no wonder the error string wasn't in the bzr codebase :_)
<Wellark> hi!
<Wellark> where can I find documentation how daily PPA's are configured in launchpaD?
<jelmer> Wellark: hi
<jelmer> Wellark: see https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted
<Wellark> jelmer: thanks!
<LeoNerd> Can there -please- be a flag to  bzr up  something like  --abort-if-diverged  so that  bzr up  becomes an error on divergant history, rather than doing a reverse merge..?
<LeoNerd> I get very annoyed by this latter behaviour
<LeoNerd> Then I can put that in my aliases file, and on divergant history it'll require me instead to rebase
<darKoram> howdy from Austin Texas.  My first time on #bzr
<lifeless> LeoNerd: you can use bzr pull instead, which has that behavior
<LeoNerd> Hrm.. hard habit to get out of I guess. I tend to just "bzr up" most of the time
<LeoNerd> Mostly because after "bzr co", up will work whereas pull will not
<LeoNerd> Because you have to type the URL a total of 3 times before all the commands remember it
<lifeless> LeoNerd: well, if you want to rebase rather than merging, you explicitly don't want bzr co to work after pull does anything, right ?
<LeoNerd> Hrm?
<LeoNerd> No, usually I  bzr co  to make my checkout initially
<LeoNerd> rather than branch
<lifeless> I didn't suggest you stop using bzr co
<LeoNerd> If you co then a plain "bzr pull" claims it doesn't know what to pull from
<LeoNerd> So the first time you type it you have to put the URL in again
<lifeless> thats true
<LeoNerd> I've started to get into a habit of immediately after bzr co, cd'ing into the workdir, then doing bzr missing <Alt+.><Enter>bzr pull <Alt+.><Enter>bzr push <Alt+.><Enter>
<LeoNerd> just to reuse the bash history of the URL, and save some typing
<LeoNerd> Otherwise it's an annoyingly inconvenient  bzr info  then copypaste the URL off the screen
<LeoNerd> I still don't know why those can't be prefilled
<jelmer> LeoNerd: doesn't "bzr pull :master" work?
<LeoNerd> I've never heard of that.. what does it do?
<jelmer> LeoNerd: sorry, :bound
<jelmer> LeoNerd: see "bzr help location-alias"
<jelmer> LeoNerd: it's an alias for the location of the master branch
<jelmer> LeoNerd: that said, I agree we should fix "bzr up". The current behaviour might be useful in some cases, but is also a bit surprising.
<darKoram> I recently created a bzr repo for my development work and uploaded it to Launchpad.  I'm now having serious problems with the drive it was on and need to re-format it.  Is there anything i need to do to make sure pulling back down from lp goes smoothly afterwards?
<jelmer> darKoram: no, you should be able to just run "bzr branch lp:YOURBRANCH /local/path" later, presuming you pushed the branch to launchpad before your disk was corrupted.
<darKoram> ok... gonna try it.  Thanks!
<poolie> hi all
<poolie> lifeless, incidentally the auto reconnect stuff should now be landed in bzr trunk
<poolie> i think it will need to be tested there for a while before it can go into stable series though
<poolie> but, that should make things a bit easier for lp
<jelmer> poolie: it hasn't yet, that's the branch that's making PQM
<jelmer> hang
<poolie> :/
<poolie> interesting
<poolie> maybe pqm ought to run it under a timeout
<jelmer> yeah, that would help for cases this like
<jelmer> otoh, it's not really common for this to happen
<jelmer> poolie: and we're migrating to tarmac anyway, right ? :-)
<poolie> right
<poolie> maybe i should pilot it this week
#bzr 2012-11-19
<mgz> morning!
<jam> w7z: poke
<jam> w7z, mgz: We seem to now be on a 0.5s echo, just hearing ourselves from you
<ritz_> wrt https://bugs.launchpad.net/udd/+bug/848064 and https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/1078395
<ubot5> Ubuntu bug 888615 in Bazaar "duplicate for #848064 UDD branch freshness checker breaks on incomplete history" [High,Confirmed]
<ubot5> Ubuntu bug 1078395 in bzr (Ubuntu) "bzr: ERROR: Revision * not present in *" [Medium,New]
<ritz_> how do I fix this bug ?
<ritz_> is this an issue with lp, or with bzr ?
<mgz> neither really, it's in udd
<mgz> see lp:udd
<mgz> some specific packages have had workarounds manually applied for things like that, but requires someone to dig in and find which bit of the history is problematic and blacklist it
<mgz> you can do that yourself, if sufficiently brave, xnox managed it
<ritz_> mgz , hmm in which case if I understand correctly, the fix is it reimport and this is to be done by upstream
<ritz_> mgz how does one do this ?
<mgz> it varies, the push --overwrite issue can generally be fixed by a reimport
<mgz> having missing or oddly broken history generally means you need to add some configuration to exclude the bust bits
<mgz> it is possible to run udd locally and try a branch import, which will give you extensive logs
<mgz> or I could fetch a real log for a specific package from jubany for you
<mgz> this is more the realm of #launchpad, though there aren't that many people who've done the magic incantations previously
<ritz_> mgz hmm neither have I . Assuming I am new to this and mildly retarded. Where should I start for docs/examples/fixes/code ?
<mgz> ritz_: though, the specific lp:ubuntu/precise/duplicity branch being borked may well not be package importer related directly, might be something launchpad/stacking specific
<ritz_> mgz I am hitting for more than one pkg which bothers me
<ritz_> and as per barry, bzr is looking for contributors
<mgz> ritz: this probably needs some launchpad-side debugging to work out exactly what's wrong with the branch, which needs someone with superpowers using sftp to inspect the branch, I can't do this
<ritz_> mgz hmmm, who would be the person for this ?
<ritz_> or would udd mailing list be good ?
<mgz> mailing list is good, or irc when australia is awake
<mgz> ah, and with some tricks can get more info over http
<mgz> so...
<mgz> curl -L http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/duplicity/precise/.bzr/branch/branch.conf
<mgz> tells you what the branch is stacked on
<mgz> which is then stacked on raring
<mgz> which is non-borked
<mgz> and on the package import, there's a very stale lock that's making life unhappy it seems
<ritz_> hmmm
<ritz_> is this on the server ?
<ritz_> hmm, http://doc.bazaar.canonical.com/beta/en/user-guide/stacked.html
<ritz_> something like git tagging
<ritz_> hmmm ,Packaging branch status: OUT-OF-DATE
<ritz_> ./.bzr/branch/lock:     directory
<ritz_> ./.bzr/branch-lock:     directory
<ritz_> ./.bzr/checkout/lock:   directory
<ritz_> ./.bzr/repository/lock: directory
<ritz_> are we talking about these ^^^ ?
<mgz> ritz_: sort of, but specifically some local branches on the machine the importer runs on
<mgz> have broken it and requeued the package, will see if that gives a useful error
<ritz_> this is also seen with pidgin package. Do I raise another lp/bug against udd for this ?
<mgz> that looks like something else from the log
<mgz> and the borkedness of the branches on launchpad may be unrelated anyway
<mgz> ritz_: see http://package-import.ubuntu.com/status/pidgin.html
<mgz> looks like a history issue, but not one we have a bug filed for yet, so go ahead and do that (against lp:udd)
<mgz> ritz_: and now duplicity.html also exists
<ritz_> mgz another question, does running bzr branch lp:/ubuntu/precise/xyz pick the latest xyz source ( assuming we have a proposed and security branch)
<mgz> the latest landed stuff, yes, rather than what was present at release
<mgz> I'm not sure of the exact flow of changes with srus and -proposed and such like
<ritz_> mgz thank you. filed https://bugs.launchpad.net/udd/+bug/1080801
<ubot5> Ubuntu bug 1080801 in Ubuntu Distributed Development "branching pidgin fails " [Undecided,New]
<ritz_> I assume this is to be marked against udd alone, and not ubuntu(pidgin)
<mgz> ritz_: I'm not sure how ubuntu wants to handle those kinds of things, not being able to branch the thing at all rather than it just being out of date does make life more difficult
<ritz_> mgz thanks. kindda of late here. heading to bed
<mgz> ritz_: have a good evening/sleep :)
<ritz_> thank you
#bzr 2012-11-20
<w7z> sort of morning
<euphogeeza> Hi All. I have bzr installed on a windows box and trying to get post-commit emails working. I think I have everything in place but no mails are being sent.
<euphogeeza> I thought I'd look in the trace (log?) but can't find it.
<euphogeeza> If I do a "bzr help commands" at the command prompt I am getting "failed to open trace file [Errno: 13] Permission denied".
<euphogeeza> Is this trace file == the log file?
<euphogeeza> ...and where should it be?
<euphogeeza> If I don't know where to look I can't check the permissions :-(
<euphogeeza> I set the BZR_LOG environment variable (with "SET BZR_LOG=<path>") and now get "failed to open trace file [Errno: 22] Invalid argument".
<LarstiQ> euphogeeza: `bzr version` will tell you where the log file resides
<LarstiQ> euphogeeza: look for the 'Bazaar log file' line
<euphogeeza> LarstiQ: OK Thanks. I'll go look...
<euphogeeza> LarstiQ: OK I see the path "D:\Server Data\BZR" is listed...
<LarstiQ> euphogeeza: that's a slightly weird path for the log
<LarstiQ> euphogeeza: is BZR_HOME set?
<LarstiQ> because that might influence the path
<euphogeeza> LarstiQ: yes and BZR_LOG. I tried to force bzr to write to a location which I knew.
<euphogeeza> LarstiQ: both set to "D:\Server Data\BZR"
<euphogeeza> LarstiQ: ...no log file created though.
<LarstiQ> euphogeeza: so if you're setting BZR_LOG, try "D:\Server Data\BZR\.bzr.log"
<euphogeeza> LarstiQ: trying it now...
<euphogeeza> LarstiQ: :-( still no log file created. Where is the default location that the log file, if BZR_LOG is not set?
<LarstiQ> euphogeeza: home = osutils._get_home_dir(); return os.path.join(home, '.bzr.log')
<LarstiQ> which on windows is *looks up*
<LarstiQ> pff
<LarstiQ> euphogeeza: quite a bit of code
<LarstiQ> euphogeeza: if you unset BZR_LOG and BZR_HOME, what does it show?
<jml> we wrote this â http://paste.ubuntu.com/1372760/ â to figure out the timestamp of the first commit made in a branch that then got merged into trunk.
<jml> is there a faster way of doing it?
<euphogeeza> LarstiQ: I unset BZR_LOG only, then bzr version => "D:\Server Data\"\.bzr.log ???
<euphogeeza> I unset BZR_HOME also, and bzr version now returns: d:\local_data\<username>My Documents\.bzr.log
<LarstiQ> euphogeeza: aha to the latter
<LarstiQ> euphogeeza: to the former, wait, are the " included?
<LarstiQ> euphogeeza: that would be problematic
<euphogeeza> LarstiQ: yes. I have now found the .bzr.log. Yey!
<LarstiQ> euphogeeza: good :)
<euphogeeza> LarstiQ: I now have something to look at while trying to find the reason for post commit emails not being sent. Some thing for tomorrow. Many thanks for your help.
<LarstiQ> euphogeeza: np
<jml> http://paste.ubuntu.com/1372793/ <- two versions of getting the timestamp of the first revno of a branch
<jml> I wonder which is faster / better
<jml> james_w: ^^
<jml> it cheats
<james_w> jml, cunning
<james_w> no idea which is better
<jml> I wonder if any of the experts in bzr internals monitor this channel any more.
<LarstiQ> they do, but not as intensively as in the past
<LarstiQ> jml: Graph.find_lca?
<jml> LarstiQ: I want the non-leftmost revision immediately after the lca, I think
 * LarstiQ nods
<jml> Ideally, if there were some way of retrieving when 'bzr branch' were run, that would be even better.
<LarstiQ> jml: something with a pre_command hook?
<jml> LarstiQ: yeah, maybe that might be a good thing to do in future.
<LarstiQ> jml: I'm too exhausted to come up with a better response, sorry :/
<jml> LarstiQ: no worries
<jml> LarstiQ: thanks for the help
<aquarius> I have a repo on a server I own which I push to via ssh. What's the easiest way that I can, on that server, when a new rev is pushed to trunk, automatically export trunk to a folder? (for deployment) I don't need jenkins or other super-complex stuff like that just yet :)
#bzr 2012-11-21
<bob2> aquarius, with a hook
<aquarius> bob2: I couldn't find anything about running hooks on the server -- client hooks I understand, but server hooks didn't seem to be documented anywhere I could find -- but that likely means I just didn't find it :)
<mgz> morning
<jelmer> hey mgz :)
<LarstiQ> aquarius: they work basically the same way as local hooks
<LarstiQ> aquarius: they're just configured on the server
<LarstiQ> aquarius: (also note separately there is bzr-upload which can be nice for deployments)
<aquarius> LarstiQ: I'm not sure *how* to configure a hook on the server; perhaps I'm just stupid :( Hooks are configured in plugins; plugins go in my ~/.bazaar folder. The server's a server: it doesn't have a home directory.
<LarstiQ> aquarius: it does :)
<LarstiQ> aquarius: are you using bzr+ssh or something else?
<aquarius> bzr+ssh, yep
<LarstiQ> aquarius: then it sets up an ssh connection and runs the bzr on the other side, as the user you're logging in with
<aquarius> right. So I can install the plugin which runs the hook in server:/home/myuserid/.bazaar but then it'll only run the plugin when *I* push to trunk.
<aquarius> I would like the plugin to run when a new rev is pushed to trunk, regardless of who does it, without having to have every user on the server install the plugin.
<aquarius> (and without having to do magic sshness to make everyone on teh server actually ssh in as some sort of "bazaar" user)
<LarstiQ> aquarius: or you could install it in bzrlib/plugins/ for example, and (iirc), set the config in .bzr/branch/branch.conf
<aquarius> aha, set the config in .bzr/branch/branch.conf, that sounds like the sort of thing I want. I didn't find any references to that at all, although I'm probably just looking in the wrong place!
 * aquarius googles :)
<LarstiQ> iirc there are also inotify watchers, which saves you from having to create a new .bzr/branch/branch.conf for new branches
<LarstiQ> of course, if you are in full control you could also handle it in the plugin
<LarstiQ> aquarius: unfortunately things are a bit more complex than with say svn :/
 * LarstiQ back to math
<aquarius> LarstiQ: ah, I'm OK without the inotify stuff; what I specifically want to do is, when a new rev hits trunk, bzr export it into a folder (this is to deploy our staging server direct from trunk). I don't need to do that for many different branches.
<aquarius> This looks like the right approach. Thanks!
#bzr 2012-11-22
<mwhudson> remerge --weave is quite exciting ;)
<bob2> haha
<idnar> so what's the latest on bzr and colocated branches? is bzr-colo still the thing to use?
<lifeless> probably
<jelmer> idnar: yeah, the support for colocated branches in bzr core was never finished
<bob2> :(
<kinkie> Hi all, sorry for jumping in with a quick question: is there a way to push to a remote repo some local commits which is not a commit? (e.g. some form of push) Thanks!
<mgz>  kinkie: that doesn't make sense to me, what exactly are you trying to achieve?
<kinkie> My main mode of developing is via a remote repo with local checkouts as I work in parallel on different systems. But sometimes I'm disconnected; in that case I favor to do local commits which I'd like to push when the main repo is available to me again
<kinkie> I can do it with a regular commit, but that's sometimes inconvenient. I'm just wondering if there's a way to push the local commits or to replay them somehow
<kinkie> have to go now, will read later
<mgz> kinkie: you can just push local commits as they are when you reconnect
<mgz> ah, I see, you need a commit without --local for that to happen
<fullermd> No, you can just push, assuming there's no divergeance.
<fullermd> You're off in the hairy corners of the boundbreckout mess of course.
<kinkie> fullermd: thanks, that's what I was looking for
<didrocks> hey
<didrocks> I tried to distro-patch bzr on raring
<jelmer> hi didrocks
<didrocks> adding the support for lp-propose to include the latest commit
<didrocks> however, it FTBFS (I built it on quantal :/)
<didrocks> hey jelmer! how are you? :)
<didrocks> https://launchpadlibrarian.net/123701411/buildlog_ubuntu-raring-i386.bzr_2.6.0~beta2-0ubuntu2_FAILEDTOBUILD.txt.gz
<jelmer> didrocks: I'm well thanks, hope you are too
<didrocks> it seems some obscure doc tool I don't know about :)
<didrocks> jelmer: yeah, quite busy, but good! :)
<jelmer> didrocks: I patched this for the Debian package, IIRC newer versions of python-docutils are slightly stricter
<didrocks> interesting
<didrocks> should I just steal your patch from Debian?
<jelmer> didrocks: see -r6570 of lp:bzr
<didrocks> jelmer: thanks a lot! you save more a bunch of time :)
<jml> how can I see what properties a revision has?
<jml> from the cmd line, idieally
<jelmer> jml: bzr cat-revision, though that will spit out the raw form
<jml> jelmer: thanks.
<jml> jam: how do I actually use meliae?
<jml> oh hey, I found this: http://jam-bazaar.blogspot.co.uk/2009/11/memory-debugging-with-meliae.html
<mgz> yeah, that's helpful, really you still need to have a reasonable idea of the layout of things to understand what the dumps mean
<jml> hmm.
<jml> is there a visualizer for meliae output?
<jml> hmrmrmmm
<jml> oh, right.
<lifeless> jml: runsnakerun
#bzr 2012-11-23
<Merwin> Hi guys. I'm stuck with Bazaar. I moved abzr colocated repo from a dir to an other, and now it doesn't work in the new one
<Merwin> (openassur)thibaut@PC-Thibaut:~/OpenAssur/addons-opas$ bzr revno
<Merwin> bzr: ERROR: Not a branch: "/home/thibaut/OpenAssur/addons-opas/.bzr/branches/trunk/
<Merwin> I changed the path in .bzr/branch/location/ because it pointed to the old one.
<Merwin> bzr colo-fixup give me the same error :-(
<mgz> morning
<Wiz_KeeD> hello guys!
<Wiz_KeeD> can anyone tell me how i can download a branch from local to the dev server?
<mgz> there are lots of ways to upload a branch, which is best depends on exactly what you're trying to do
<Wiz_KeeD> hello mgz and thank you for answering
<Wiz_KeeD> well...
<mgz> you can either push the branch over sftp, or if you really just care about the tree, use something like the bzr-upload plugin
<Wiz_KeeD> i have a development server to which i have ssh and root access
<Wiz_KeeD> and i have the branch on my laptop
<Wiz_KeeD> both running ubuntu
<mgz> what's easy then is to install bzr on the server and push using bzr+ssh, just remember that won't create a working tree on the server by itself
<Wiz_KeeD> i cannot access my laptop from the dev environment since i have no access to the intranet
<Wiz_KeeD> i have bzr installed on the dev server
<Wiz_KeeD> how do i do that mgz? :O and what's actually a working tree?
<Wiz_KeeD> as in i cannot revert to older version and such?
<Wiz_KeeD> i can only pull?
<mgz> you can do pretty much anything you'd do locally over bzr+ssh
<Wiz_KeeD> then what's the problem?
<Wiz_KeeD> any tutorial or suggestions on how i can do that?
<Wiz_KeeD> i find it highly unpractical and unprofessional to just copy paste the files when i have bzr on both environments
<mgz> see: http://doc.bazaar.canonical.com/beta/en/user-guide/core_concepts.html
<mgz> then read `bzr help push`
<mgz> but if what you really want is the contents of the tree in a specific place on the dev server to say, actually get the code run, you may want to look at bzr-upload instead
<mgz> push mirrors the repository and the branch, but does not update the tree
<Wiz_KeeD> it's my lack of knowledge
<Wiz_KeeD> that's at play here
<Wiz_KeeD> i do want the contents of the code in a specific place where it is loaded by a framework
<mgz> try getting that plugin and experimenting with it then
<Wiz_KeeD> hmm so i have to install that plugin
<Wiz_KeeD> can't i create a repository on the dev and push from local?
<Wiz_KeeD> i'd love to take the tutorial from 0 but right now i'm in a bit of a hurry
<mgz> as I said at the start, you can do this in a bunch of different ways, I'm trying to poke you towards the one that's closest to what you actually need
<mgz> if you're basically doing deployment of the code to your server, using bzr-upload is likely the easiest to set up correctly
<Wiz_KeeD> this is the plugin right http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html
<Wiz_KeeD> yes that's it, deployment of code to the server
<Wiz_KeeD> sorry for being such a douche
<mgz> Wiz_KeeD: actually no, I was talking about https://launchpad.net/bzr-upload but you can try that one if you like
<Wiz_KeeD> that is for the case where bzr is not installed on the dev server
<mgz> it works for that, but is also fine for just mirroring your tree. is probably the closest to what you do now.
<Wiz_KeeD> https://launchpad.net/bzr-push-and-update
<Wiz_KeeD> so for developing locally and updating the changes to the server when done which one of the two would you recommend considering my precarious knowledge and the fact that the server has bzr on it and i have ssh access?
<mgz> feel free to try the push and update one, mirroring the branch as well might be handy.
<Wiz_KeeD> i think i'll go with the bzr-upload you said
<Wiz_KeeD> how do i install the plugin
<Wiz_KeeD> i'm looking at this and i can't understand http://doc.bazaar.canonical.com/plugins/en/plugin-installation.html
<Wiz_KeeD> i have no plugin directory
<mgz> simplest way is `mkdir ~/.bazaar/plugins` then `bzr branch lp:bzr-upload ~/.bazaar/plugins/upload`
<Wiz_KeeD> hmm, let me try
<Wiz_KeeD> ok done that
<Wiz_KeeD> it shows in plugins now
<Wiz_KeeD> it's ready to work?
<mgz> should be.
<Wiz_KeeD> where's the documentation for this
<mgz> `bzr help upload` also on the plugin doc page on the web page you were looking at earlier
<mgz> I'm presuming you have sftp as you have ssh
<Wiz_KeeD> that idk :-s is that kind of like a ssl for ftp?
<Wiz_KeeD> found this though
<Wiz_KeeD> http://wiki.bazaar.canonical.com/BazaarUploadForWebDev
<Wiz_KeeD> i am making a sftp user right now mgz
<Wiz_KeeD> another option without using sftp and such?
<Wiz_KeeD> like idk, make the repository on the dev and pull, make changes and push back? would that be sane? and it would avoid using ssh or sftp
<mgz> well, just running update after push is enough if having the branch in place is acceptable
<mgz> the other plugin you looked at did say it boiled down to push followed by `ssh LOC bzr update`
<Wiz_KeeD> mgz, a friend suggested i just do bzr+ssh//user@hostname/full/path
<mgz> that's not an action, it's a location.
<mgz> also, you probably want to stick your username in locations.conf rather than in the url
<Wiz_KeeD> i didn't fully understand sorry
<mgz> pushing over ssh then updating the tree is fine, you just need to do both bits.
<Wiz_KeeD> is there something wrong with pushing?
<Wiz_KeeD> which both bits?
<mgz> literally, `bzr push bzr+ssh//hostname/~/path && ssh hostname bzr checkout "~/path"` then switch checkout to update atfer the first time
<mgz> huh, bzr-ch is a project... I guess our docs don't explain you don't need to create a project just to translate our docs... not in chinese yet at any rate
<Wiz_KeeD> mgz, ok, what if i transfer the branch to the development server, pull the files on my local, make changes and push them back?
<Wiz_KeeD> how's that?
<mgz> I don't follow. Did you try what I suggested and it didn't work in some regard?
<mgz> you just need to create a tree on the remote side then keep it updated, if you want to go down the branch mirroring route.
<mgz> I hate to be all perl about this, but there is more than one way to do it, just pick one and do that.
<Wiz_KeeD> i see
<Wiz_KeeD> i've placed the repository on the dev server and now i want to pull it
<Wiz_KeeD> how do i do that? bzr branch hostname...
<Wiz_KeeD> ?
<mgz> 'pull' optionally with --remember.
<Wiz_KeeD> pull from where, i need to install the branch on my local
<Wiz_KeeD> from the dev server
<mgz> I don't see how you're solving the working tree update.
<mgz> I don't know where you've put things so can't tell you what paths to use.
<Wiz_KeeD> hm
<Wiz_KeeD> On my local ubuntu where i develop i have the files in /opt/openerp/projects/project-name and on the development server i have them in /opt/openerp/project-name
<Wiz_KeeD> i have transfered the branches from local to the development server via bzr upload
<Wiz_KeeD> and now i'd like to pull the branches fom the dev to the localhost so when i do push and pull it will automatically make the neccesairy changes
<fullermd> OK, now I'm all confused about who's confused   :p
<Wiz_KeeD> have i've been clear enough?
<bobweaver> hello there I am having a weired problem  http://paste.ubuntu.com/1380291/
<bobweaver> as you can see there is room on the drive
<bobweaver> looking at log now
<vila> bobweaver: not enough on /tmp ?
<vila> try setting TMP (or is it TMPDIR) to somewhere else while running the command may be
<bobweaver> nope friend also suggested that I removed /tmp adn still nothing
<bobweaver> ok I will try that
<bobweaver> back to normal
<bobweaver> thanks vila
#bzr 2012-11-24
<Tracon> I've been trying to find a solution to this, but have been unsuccessful.  When I run "bzr upload ftp://username@mydomain.com/path/to/folder" (obviously substituting my real information), the upload just hangs when it encounters a file 100kb or greater.  I have no problem using Filezilla to upload these files.  How could I get Bazaar to successfully upload them?
<Logan_> Can any UDDers please perform this? $ requeue_package.py --full initramfs-tools
#bzr 2013-11-19
<Wiz_KeeD> Hey guys
<Wiz_KeeD> What if I make major changes to a file that is revisioned by bzr and then I just wans to push and update a small modification on the same file but not the other work I did?
<Wiz_KeeD> So I make changes I commit, Change, commit, change, commit...then make a small adjustment and commit that?
<Wiz_KeeD> only that
<bgardner> Wiz_KeeD: I'm not a bzr guru, but that seems unlikely to be possible.
<Wiz_KeeD> I see
<Wiz_KeeD> thanks :(
<Peng> Create a separate branch?
<Peng> If you haven't committed the otehr stuff yet, you can use bzr shelve (from bzrtools) or bzr record (from bzr-record ;)
<LeoNerd> You could also create a separate branch and 'replay', but beware of replay's rudeness
<Wiz_KeeD> hmm
<Wiz_KeeD> that is a good thought
<Wiz_KeeD> you guys are helpful :D
<lfaraone> Do code contributions to bzr require a CLA?
<bgardner> lfaraone: Yes
<bgardner> lfaraone: See the entry for Bazaar for contact info: http://www.canonical.com/contributors
#bzr 2013-11-20
<KombuchaKip> Thoughts? https://bugs.launchpad.net/bzr/+bug/1077521
<ubot5> Ubuntu bug 1077521 in Bazaar "Bzr not ready for digital media asset management" [Wishlist,Confirmed]
<Sebboh> Months ago, I did bzr branch lp:leo-editor, or something like that.  Today I want to update my working copy with the latest changes from the same place I got the content from originally.  Unfortunately, I tried a few commands and left my workspace in some modified state.
<Sebboh> How can I discard every local change and update to the latest revision?
<Sebboh> After doing a bzr revert, bzr status still shows modified: .. and then lists what seems to be every file, with an * after each one.
<fullermd> That would be +/-x, so some mismatch with the FS.
<Sebboh> When you say +/-x, does that mean the executable bit doesn't match?
<spiv> Right.
<spiv> I'd have expected bzr revert to fix that, though :/
<spiv> But if it doesn't, you could manually flip the x bit on those files.
<Sebboh> It can't.  Fake filesystem, ignores calls to chmod.  :)  I'll move the repo to a proper filesystem and try again...
<fullermd> That would be why revert doesn't get it to expected  :)
<spiv> Ah, no wonder bzr revert can't fix it then :)
<Sebboh> (virtualbox host<-->guest filesystem sharing between win7 host and debian guest. Work computer.. :P )
<Sebboh> Yes. :)
<Sebboh> incidentally, bzr is much faster on ext4.
<Sebboh> hardlinks?
#bzr 2013-11-21
<Wiz_KeeD> hey guys
<Wiz_KeeD> how do i push a single file towards a repository, so I made multiple commits (3) and the last one changed file x that I would like to push alone
<Wiz_KeeD> is that possible?
<Peng> Cherrypicking and pushing one revision but not its ancestors? Not really.
<Peng> Look up cherrypicking. You can do it, but you'd effectively be creating a new, otherwise-identical revision that's a child of -4.
<Peng> .... unless this has been made easier recently.
<Wiz_KeeD> I see what you are saying Peng, thought about that myself but figured there might be a way to avoid it
<Wiz_KeeD> maybe I should keep the experimental commits on a separate branch from the production one where all the commits are "safe"
<Peng> That sounds like a good idea.
<Wiz_KeeD> though I've never done a merge in my life :))
<Peng> You should, it's fun.
<Wiz_KeeD> mergin? i don't think so :)) especially on bit projects
<cmars> hi
<cmars> what does it mean when bzr says "Merging branch abc into xyz would be pointless"?
<cmars> i am fairly certain that the branches do differ
<cmars> nevermind, it was a tarmac issue
#bzr 2013-11-22
<Wiz_KeeD> Hey guys
<Wiz_KeeD> I did a mistake and commited the wrong values
<Wiz_KeeD> then I did bzr uncommit which reverted to the previous revision, but now I see that bzr status indicates I have uncommited files "Which indicate the changes from the commited version are still there"
<Wiz_KeeD> How do I update the tree so it's exactly like the previous revision? bzr update doesn't work
<Wiz_KeeD> Ah..i think bzr-revert --no-backup
<fullermd> Uncommit just moves you back to before the commit, it doesn't change the WT files.
<Wiz_KeeD> yeah figured that out XD
<Wiz_KeeD> so revert updates the wt to the current revision
<Wiz_KeeD> if no -r is specified
<Wiz_KeeD> I guess that solved it
<Wiz_KeeD> phew!
<Wiz_KeeD> did a boo-boo on the production server :(
<fullermd> It wasn't a boo-boo.  It was an experiment.  That somebody OTHER than you screwed up, and you had to clean up.
<Wiz_KeeD> too bad i'm not only person working on the project XD
<Wiz_KeeD> let's not forget about the mean l33t h4x0rz!
<LeoNerd> Bah.. I -really- hate when  bzr up  decides the branches have diverged and so does a merge instead. How can I turn that off, so it just rejects it?
<LeoNerd> In 99.9% of the time I want to rebase in that situation
<computa_mike> I have a question about BZR - If I change the date updated or modified for a file, does Bzr record that information - or can I force it to?
<LeoNerd> I don't believe bzr tracks ctime/mtime
<computa_mike> LeoNerd: That's what I've found so far playing with BZR - I was just wondering if there was some magic flag I could use or a different client etc.
#bzr 2013-11-23
<tom95> hi, I'm desperately trying to get "bzr rebase" on my ubuntu 14.04 installation. Do you have any idea where to get it from? The packages I found so far where only compatible with older versions of bzr and installing from source didn't make it be recognized by bzr for some reason.
<LeoNerd> I believe it's in  bzr-rewrite
<tom95> LeoNerd: yes, I found packages for bzr-rewrite, but they requested a bzr older than mine
<tom95> so they failed to install
<LeoNerd> Hmm
<tom95> sorry, I had connection problem, have I maybe missed an answer?
<LeoNerd> Nop
#bzr 2014-11-18
<Harzilein> hi
<Harzilein> is there a frontend command to resolve "directory services" style repo locations to urls?
<malami> Hi, I have a question about branches. I'm a git user and it's been a while since I used Bazaar. I want to commit to a release branch, so I did bzr branch lp:project/version. I supposed I would just make a change, commit and push. But when I run git status right after the branch command, it shows me a ton of changed files. What am I missing? (I can commit to trunk just fine this way)
<malami> nevermind, I fetched the branch on a Samba share (don't ask) and all the files had +x file attr, that's why they showed as changes. I did a bzr revert and all is well now.
#bzr 2014-11-20
<fdassdff> Question about bzr
<fdassdff> I want a directory that I can throw random python scripts into and be able to do version control
<fdassdff> But it's not really part of an overall "project"
<fdassdff> Is there a way to set that up?
<Peng> "bzr init" in the directory?
<fdassdff> Peng, and then what's the process to register files and have them reflected in the version control?
<fdassdff> The bzr quick reference card assumes that I'm going to be working on an overall project
<Peng> What's "an overall project"?
<fdassdff> For example, the doc here: http://doc.bazaar.canonical.com/bzr.2.6/en/_static/en/bzr-en-quick-reference.pdf says I should do "bzr init myproject" to create a new project
<fdassdff> But I'm not working on a project, I've just got some python scripts that I mess with every so often and I want to be able to roll back any changes that I make if they turn out to be bad
<fullermd> "my random crap" is a project...
<Peng> "bzr init directory_with_some_python_scripts" then.
<Peng> if the directory already exists, you can cd to it and "bzr init".
<fdassdff> Ah ok
<Peng> The proceed like normal, "bzr add"ing your files and such.
<fdassdff> That makes sense I guess
<fdassdff> I wasn't expecting it to work like that
<Peng> There isn't a concept of a Project -- that's just what that guide called it.
<fdassdff> The only times that I've used it have been in conjunction with launchpad
<fullermd> Yeah, bzr doc "project" doesn't have anything to do with LP "Project".
<Peng> You don't have to interact with Launchpad at all if you don't want to :)
<fullermd> (For that matter, LP Project doesn't have anything to do with bzr, except insofar as it can include 0..n bzr branches)
<fdassdff> Thanks both of you
<fdassdff> I appreciate the help for a newbie
#bzr 2015-11-20
<orbisvicis> how can I determine if uri is bzr repo ?
<mgz> `bzr info url`
<orbisvicis> that does seem the fastest way, thanks
#bzr 2016-11-26
<jelmer> vila: I'm hitting more test failures in sid, looks like this is because pycurl is now stricter
<vila> jelmer: seen that too :-/ but heads down on the ci infra
<vila> jelmer: I have, I think, a fix for the gettext/lazy_regexp issue though
<vila> jelmer: I didn't did the pycurl one, stricter for what ?
<jelmer> vila: basically, when you do proxy requests, they now require that you pass in "http://" URLs for the proxy rather than ignoring the scheme as they did before
<jelmer> https://github.com/curl/curl/issues/1015
<jelmer> so it should hopefulyl just be sufficient to replace http+pycurl with just http before calling pycurl
<vila> jelmer: the wording in that issue is weird... anyway, having a look as I agree s/+pycurl// may be the thing
<jelmer> filed https://bugs.launchpad.net/bzr/+bug/1645017
<ubot5`> Ubuntu bug 1645017 in Bazaar "proxy tests fail with newer versions of pycurl" [Undecided,New]
<vila> thanks !
<vila> jelmer: hmm, looks like _unqualified_scheme is already used, needs to search if some proxy specific thing is going on
<jelmer> vila: yeah, I think I found it
<jelmer> vila: we set 'all_proxy' in the tests to a URL like http+pycurl://joe:bar@127.0.0.1:35245/
<jelmer> and then that gets picked up directly by pycurl
<jelmer> os.environ['all_proxy'] I mean
<vila> hmm, where ?
<jelmer> vila: bzrlib.tests.test_http
<jelmer> vila: it calls self.overrideEnv('all_proxy', ) in many places
<jelmer> self.overrideEnv('all_proxy', ...) is all over the place :)
<vila> rhaa, of course, damn it, was climbing the wrong tree. Hmm, but there are ... several tests failing. But yeah, for setting env vars +pycurl shouldn't be there
<vila> yeah
 * vila tries hard to page-in the whole context
<vila> it's... surprising that this even works, I'm missing some bits, +pycurl should be used to select the client, I'm confused about why/how it's used for the server... (given that the pycurl client will filter +pycurl)
<vila> or was it just all along that pycurl filtered +pycurl and doesn't anymore in which case ... it's overrideEnv calls that needs to be fixed
<vila> right, that seems to fix it
<vila> down to 7 failures
<fullermd> See, if you'd just gone with perl in the first place...
<vila> go f...
<vila> err
<vila> go for the win ?
<vila> go fullermd ?
<vila> ;-)
<vila> down to 1 failure
<fullermd> O:->
<vila> pycurl.error: (8, '')
<vila> what on earth is that one ;-)
<fullermd> Is...   that another emoticon?
<vila> haaaa, indeed, so, probably need to skip that test (they no humor ;)
<vila> they *have*
<vila> TestInvalidStatusServer /me sighs
<vila> jelmer: patch so far: https://pastebin.canonical.com/171950/
<vila> jelmer: ftr, this means this is a test-only issue
<vila> 'E_FTP_WEIRD_SERVER_REPLY': 8, seriously ?
<fullermd> As FTP goes, that sounds extremely sane.
 * fullermd is on a campaign to wipe FTP off the face of the 'net.
<vila> fullermd: that takes you way too long ! :-p
<fullermd> Man, you ain't _even_ joking...
<fullermd> It's amazing.  The only real fault of telnet is that it's plaintext, and that was sufficient to practically extinctify it in just a couple years, mostly last millennium.
<vila> we're dealing with a sabotaged hhtp (ha ha, I'm feeling younger ;) server sending:          self.wfile.write("Invalid status line\r\n")
<fullermd> FTP is plaintext as well, plus horrific eldritch horror of protocol design, and we can't seem to kill the stupid thing.
<vila> nah, too damn useful to setup insecure servers, let's put it on IOT gateways
<vila> Ran 764 tests in 2.206s
<vila> OK (known_failures=4)
<vila> 89 tests skipped
<vila> jelmer: with https://pastebin.canonical.com/171952/
<jelmer> vila: That's a canonical only pastebin :)
<vila> vila: you idiot
<vila> https://paste.ubuntu.com/23538838/
<vila> rhaa, didn't press the button on the lp bug...
<jelmer> vila: thanks!
<vila> jelmer: can I ask you to fix the debian side while I sort out proper branches for bzr itself (which I'll be able to land when I'm done setting up the ci stuff...) ?
<jelmer> vila: yeah
<jelmer> working on it now
<vila> oh and sorting the mess on the 2.7 and dev branches which still haven't received the post-release cleanups :-/
<vila> jelmer: thanks a ton !
<fullermd> vila touched it!  We all saw him touch it!  Now he's on the hook!
<wasnt-me> who ?
<jelmer> :)
<jelmer> vila: new upload on its way
<vila> jelmer: thanks !
<vila> I'll try to followup on the ubuntu side before 2.7.12-7 enter zesty ...
<jelmer> should be a matter of requesting a sync :)
<vila> jelmer: right, but that's almost all I know of the process :-/ I still lack practice ... I'm not even sure I know where to ask (but I know who I can ask that question so I should be able to do that ;-)
<vila> jelmer: upload rejected ?
<jelmer> vila: yeah, with a weird error. I'm going to try again
<vila> jelmer: ack
#bzr 2016-11-27
<vila> jelmer: went any better ?
<jelmer> vila: building again now
<vila> jelmer: ack !
<jelmer> vila: another upload attempted..
<jelmer> vila: ACCEPTED
 * vila breathes again
 * vila is even more confused by 'rmadison -u debian bzr' output...
<vila> -u debian is the only place where I ever seen several lines for a... series (what the name ?): 3 lines for unstable
<jelmer> vila: different architectures?
<vila> source, all
<vila> vs
<vila>  python2.7 | 2.7.12-7                | zesty-proposed   | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
<vila> may be because there are different versions instead:
<vila> bzr        | 2.7.0+bzr6619-1 | unstable        | source, all
<vila> bzr        | 2.7.0+bzr6619-2 | unstable        | source, all
<vila> bzr        | 2.7.0+bzr6619-3 | buildd-unstable | source, all
<vila> bzr        | 2.7.0+bzr6619-3 | unstable        | source, all
<vila> which maybe specific to unstable (holding several versions ?)
<vila> apt-cache policy bzr
<vila> bzr:
<vila>   Installed: 2.7.0+bzr6619-2
<vila>   Candidate: 2.7.0+bzr6619-3
<vila> jelmer: \o/
<vila> jelmer: CI is missing some firewall config but I ran local tests up to landing (but failing as expected) https://code.launchpad.net/~vila/bzr/1579093-paramako-compat/+merge/311890
